Chatbots that cite their sources instead of inventing them.
Your answers already exist, buried in contracts, tickets and PDFs nobody reads. Retrieval puts the right passage in front of the model; a citation lets anyone check it.
Grounding is a retrieval problem, not a prompt trick.
Nobody wants a chatbot. They want the answer that is already in the handbook, without reading the handbook, and they want to know the answer came from somewhere real. That is retrieval work: find the right passage, hand it to the model, show the reader where it came from.
So the interesting decisions are upstream of the model. How the corpus is chunked, what the embeddings are computed over, whether a vector database earns its place next to your Postgres, and what the system does when retrieval comes back with nothing useful.
We have no RAG engagement we can point you at, so this page is a technical point of view rather than a reference. Read the section below, argue with it, and judge whether the reasoning holds up. That is a fairer test than a logo.
Our support team answers the same questions all day.
A grounded assistant over the documents that already contain those answers, citing the passage so an agent can verify it in one click.
We tried a chatbot and it made things up.
Hallucination is usually a retrieval failure wearing a prompt costume. We fix what gets found first, then constrain the answer to the passages that were found.
Our documents change every week.
A re-index path that runs on a schedule and on change, with the chunking strategy applied the same way every time, so yesterday's wording stops being served today.
We don't know if we need a vector database.
Often you don't. Postgres with pgvector carries a surprising amount of corpus before Qdrant is the better answer, and we will tell you which side you're on.
Scope, spelled out.
Corpus inventory
A list of every source worth indexing, its format, its owner and how often it changes, before anyone writes ingestion code.
Chunking strategy
How documents get split, what overlap they carry and which metadata rides along, chosen against your document shapes rather than a tutorial default.
Embeddings and the index
Embedding choice, the vector database or pgvector table behind it, and a rebuild path that does not require downtime.
Retrieval scorecard
A set of gold questions with known-correct passages, so recall is a measured number rather than a demo that happened to go well.
Grounded answer layer
The model answers only from retrieved passages, cites them inline, and says it doesn't know when nothing relevant came back.
Chat surface and handoff
A chat interface in your product or site, with an escalation path to a human the moment the assistant is out of its depth.
n8n workflow automation
Where the assistant should act rather than answer, we wire it through n8n or Make.com instead of building a bespoke orchestrator.
What actually happens, week by week.
Inventory
We list the sources, their formats and their owners, and cut the ones nobody trusts anyway.
Chunk & embed
Chunking strategy and embedding choice tested on your real documents, not on a sample that flatters us.
Gold questions
You write questions with known answers. We measure whether retrieval finds the right passage.
Grounding
The answer layer goes in: citations inline, and a refusal path when retrieval returns nothing.
Re-index
A refresh schedule, a change trigger and a rebuild that runs without taking the assistant down.
The tools we actually use here.
Retrieval is mostly a database problem with a model on the end. The list leans on Postgres, vectors and the orchestration; the provider is the least interesting line on it.
Deliverables, outcomes and who this is for.
- Corpus inventory and source list
- Documented chunking strategy
- Vector index or pgvector schema
- Gold-question retrieval scorecard
- Grounded chat surface with citations
- Re-index and refresh runbook
- Answers that cite a real passage
- A measured recall figure, not a demo
- An assistant that admits ignorance
- Corpus refresh without downtime
Teams whose answers are already written down somewhere, and whose users keep asking anyway.
How we'd approach it, since we can't point at one.
Chunking is where most systems fail
The default is to split on a fixed character count. That breaks tables, splits a clause from its condition, and orphans the heading that gave it meaning. We chunk on structure first: sections, list items, table rows. The heading path rides along as metadata, and we overlap only where a sentence straddles a boundary.
What a retrieval scorecard looks like
Before the answer layer exists, you write questions your users actually ask and mark which passage holds the answer. Retrieval is then scored on whether that passage comes back, and where in the ranking. Fix retrieval to an agreed number and the model's job gets easy. Skip it, and you tune prompts in the dark.
Three things that go wrong in practice
One: the corpus holds documents that contradict each other and nobody decided which wins, so the assistant confidently picks. Two: retrieval works and the model still answers from what it already knew, because nothing constrains it to the passages. Three: the index goes stale and serves a wrong answer with a citation.
When Postgres is enough, and when it isn't
If the corpus is one product's documentation, pgvector inside the Postgres you already run is the cheaper answer: one database, one backup, one place to reason about consistency. Reach for Qdrant when you need filtered search across many tenants, re-indexing at volume, or hybrid keyword and vector ranking.
Questions we get on the first call.
Correctness gets measured twice, at two layers. Retrieval first, scored against gold questions where you already know which passage holds the answer, because an answer built on the wrong passage was never going to be right. Then the answer itself, read by your own team against those same questions. Both numbers get written down before launch.
Nobody can price that without seeing the corpus first, us included. Re-embedding only touches documents that changed, so the recurring cost tracks your edit rate rather than your total corpus size. The larger line is usually storage plus the person who owns the source list. Budget for the owner.
Wherever you decide, and that decision comes before any code. Usually it stays in your own infrastructure: your Postgres, your object storage, your cloud account. Only the passage needed to answer a question travels to the model provider, and the rest never leaves. If nothing may leave at all, say so on the first call.
Yes, and it should. When retrieval returns nothing above the relevance threshold, the assistant is instructed to say it has no grounded answer and hand the user to a person or a search box. Teams find this uncomfortable to sign off. It is the difference between an assistant and a liability.
Start with Postgres. If you already run it, pgvector adds vector search without adding an operational surface, one backup story and one place for consistency. Move to Qdrant or Pinecone when you need heavy metadata filtering, hybrid keyword and vector ranking, or re-indexing that would make your primary database sweat. Most first versions never get there.
More in AI Development & Integration.
Put your documents behind an assistant that cites them.
Bring a handful of questions your users keep asking and the documents that should answer them. If retrieval is the wrong tool, we'll say so.