Applied AI, agents & RAG

The gap we get called about

The demo worked. Then real users arrived, asked things the corpus never covered, and the system answered anyway. Almost always this is a retrieval problem rather than a model problem — the reasoning is in RAG without the hallucinations.

How we build it

• Retrieval first: structural chunking, metadata filters and hybrid search, tuned until the needed context is actually in the top-k.
• Verified citations: answers quote their sources and the quotes are checked against the retrieved text, so unverifiable claims fail closed.
• A real refusal path: "that isn't in the documentation" is a correct answer, rewarded in evaluation and shown as a normal outcome.
• Evals in CI: a graded question set covering the awkward cases, run on every change so a prompt tweak cannot quietly break nine other answers.
• Cost and latency controls: caching, model routing and token budgets, measured per feature rather than guessed at.

Model-agnostic, deliberately

The pipeline is not a wrapper around one vendor's API. Providers move quickly and prices move with them; swapping should be a configuration change. Where your data already lives in Postgres we keep the vectors there too, for the reasons in in defence of boring databases.

How an engagement runs

The first phase is almost always a retrieval audit rather than a build. We take the questions your users actually ask, run them through retrieval, and read what comes back before any model sees it. That single exercise usually explains the failures and settles which model to use — because the answer is rarely the model.

From there: structural chunking, hybrid search, verified citations, an explicit refusal path, and a graded eval suite wired into CI so a prompt change cannot quietly break nine other answers. Most features reach production in four to ten weeks.

Common questions

Which model providers do you build on?

Whichever fits, and the pipeline is deliberately model-agnostic so swapping is a configuration change rather than a rewrite. Providers and prices move quickly; being locked to one is a risk we design out from the start.

Do we need a vector database?

Usually not. If your data already lives in Postgres, pgvector keeps the embeddings next to the rows they describe — same transaction, same backup, one system to operate. We reach for a dedicated store when a measured constraint calls for it.

How do you stop it inventing things?

Retrieval quality first, then verified citations — answers must quote their sources and the quotes are checked against the retrieved text, so unverifiable claims fail closed. A refusal path is built in and rewarded in evaluation, because a system with nowhere to say no will always answer.