Which AI Technique Solves My Problem?

The situation: you have a job for "AI": remember a customer, answer from your help articles, flag risky transactions, check that an answer matches the policy. The default today is to prompt an LLM for all of it. Sometimes that's right. Often a smaller, cheaper tool does the job better and gives the same answer every time.

We build SynapCores. The guidance here applies whichever stack you use. Already know your problem? Jump to the twelve guides.

Pick by the job: the decision table

Find your problem

Each guide starts from the problem and explains the technique inside it. Guides that aren't published yet are marked Coming soon.

Find things (vector search, plus SQL filters and graph)

• How to search by meaning instead of keywords
• How to find duplicate customer records, even with typosComing soon
• How to build "customers who bought this also bought" recommendationsComing soon (graph + vectors)

Write and answer (LLM, grounded in your data)

• How to ask your database questions in plain EnglishComing soon
• How to build a support chatbot that only answers from your help articles (with sources)Coming soon

Remember (agent memory: vectors to recall, NLI to check each write)

• How to make a chatbot remember previous conversations
• How to let several AI agents share one memoryComing soon

Check claims (NLI, with a similarity floor and exact rules)

• How to check if an AI answer is actually backed by your documents
• How to check if two sentences mean the same thing (or contradict each other)Coming soon
• How to automatically check sales and support calls for complianceComing soon

Predict and flag (traditional ML in the database)

• How to find unusual transactions in your data with SQL (plus a graph hop for rings)
• How to predict which customers will cancel, using SQLComing soon

New to the category? What Is an AI-Native Database? explains why these can run in one engine.

Four questions to ask

1. Is the output free text? Then an LLM is probably in the loop. Decide what checks its output.
2. Is the output a fixed label or a number, and do you have labelled history? Train a classifier or regressor. It will be cheaper and more consistent than prompting an LLM.
3. Do you need to find things, or to judge things? Finding is retrieval (vectors, keywords, SQL filters). Judging whether a claim holds against a source is NLI, an LLM judge or a human.
4. Can it be written as a rule? "Refund amount ≤ order total" is SQL, not AI. Use AI for what you can't write as a rule.

How they fit together

 question
    │
    ▼
 SQL filters + access control ── tenant, product, date, permissions
    │
    ▼
 retrieval ── vector similarity (+ keyword, + graph)      "what's on topic?"
    │
    ▼
 LLM ── drafts an answer from the retrieved passages        "write it"
    │
    ▼
 NLI ── each sentence vs its on-topic passages             "is it supported?"
    │
    ▼
 SQL / rules ── exact checks on numbers, dates, limits      "is it allowed?"
    │
    ▼
 ship / review / block, logged

A classifier usually sits beside this pipeline rather than in it: scoring churn risk, routing tickets, or flagging anomalous transactions that a person or an agent then explains.

Same text, four different signals

Here's what the techniques actually return on the same pairs of sentences. The numbers come from our recipes, run on SynapCores 2.3.1 and re-run on 2.3.2-ce (same values), with the default 384-dim embedding model and the nli-default NLI model (DeBERTa-v3-small).

Sources: rows 1–3 from recipe 037 (Step 3), row 4 from recipe 036 (Step 3), both observed on 2.3.1 and re-run on 2.3.2-ce with the same values.

What this shows:

• Similarity tells you topic, not truth. The contradiction in row 2 still scores 0.561. The wrong timeline in row 3 scores 0.779, higher than the contradiction.
• NLI tells you support, within limits. It nails rows 1 and 2. It misses the number mismatch in row 3, and it calls two unrelated sentences a contradiction in row 4.
• They fix each other's weak spots, partly. A similarity floor removes row 4 before NLI sees it. Row 3 needs neither: it needs an exact comparison of the numbers, in SQL or code.

How to Check If an AI Answer Is Actually Backed by Your Documents walks through these failures in detail.

A fair comparison

Everything in this table can run without SynapCores: an LLM API, pgvector, a Hugging Face cross-encoder and scikit-learn are a perfectly good stack. What an AI-native database changes is that the steps can run in one query over the same rows.

Try it: four signals in one query

This runs on SynapCores 2.3.2-ce with NLI enabled (see What Is an AI-Native Database? for setup). It computes similarity and all three NLI scores for each pair in one SELECT. The embeddings and the NLI model run inside the engine; nothing is sent out.

CREATE TABLE IF NOT EXISTS learn_pairs (
    id INT PRIMARY KEY,
    evidence TEXT,
    claim TEXT
);

INSERT INTO learn_pairs (id, evidence, claim) VALUES
  (1, 'Annual plans can be refunded in full within 30 days of purchase.',
      'You can get a full refund on an annual plan within 30 days of buying it.'),
  (2, 'After 30 days, annual plans are refunded pro rata for the unused full months.',
      'After that, annual plans cannot be refunded at all.'),
  (3, 'Refunds are issued to the original payment method within 5 to 10 business days.',
      'Refunds arrive within 24 hours.'),
  (4, 'The customer''s office is in Denver.',
      'The customer is learning to play the cello.');

Output on 2.3.2-ce: rows_affected = 4.

SELECT id,
       ROUND(COSINE_SIMILARITY(EMBED(evidence), EMBED(claim)), 3) AS similarity,
       ROUND(CAST(JSON_EXTRACT(NLI_CLASSIFY('nli-default', evidence, claim),
             '$.scores.entailment') AS DOUBLE), 3) AS entailment,
       ROUND(CAST(JSON_EXTRACT(NLI_CLASSIFY('nli-default', evidence, claim),
             '$.scores.contradiction') AS DOUBLE), 3) AS contradiction,
       ROUND(CAST(JSON_EXTRACT(NLI_CLASSIFY('nli-default', evidence, claim),
             '$.scores.neutral') AS DOUBLE), 3) AS neutral
FROM learn_pairs
ORDER BY id;

Output on 2.3.2-ce (build 563):

Then add the exact check that NLI can't do. Here, a rule reads the promised days from a typed column instead of the sentence:

CREATE TABLE IF NOT EXISTS learn_policy_limits (
    policy TEXT PRIMARY KEY,
    min_days INT,
    max_days INT
);

INSERT INTO learn_policy_limits (policy, min_days, max_days)
VALUES ('refund_payout', 5, 10);

SELECT policy,
       CASE WHEN 1 < min_days THEN 'CLAIM_TOO_FAST' ELSE 'OK' END AS claim_24h_check
FROM learn_policy_limits
WHERE policy = 'refund_payout';

Output on 2.3.2-ce:

In a real app the claimed value (1 day) comes from a quantity extractor, not a literal.

Clean up:

DROP TABLE IF EXISTS learn_pairs;
DROP TABLE IF EXISTS learn_policy_limits;

Where to go next

• Start here: How to Make a Chatbot Remember Previous Conversations
• Start here: How to Ask Your Database Questions in Plain EnglishComing soon
• The failures above, in detail: How to Check If an AI Answer Is Actually Backed by Your Documents

Run it yourself: recipe 037, How to Detect Hallucinations in RAG: a Per-Sentence NLI Gate in SQL, chains the whole pipeline above (similarity floor, NLI per sentence, ship / review / block) in SQL.