Grounded Answers
Search returns sources; sometimes the caller wants the ANSWER. POST /lmkit/v1/search/answer
is retrieval-augmented generation (RAG) as one managed call: it runs retrieval over a
tenant's collections and synthesizes a response on a local model, under one non-negotiable
rule: every claim is grounded in retrieved content and cited, and when the corpus does not
support an answer, the endpoint says so instead of inventing one. The end-to-end workflow,
including conversational sessions and the build-your-own shape, is the cookbook's
RAG recipe.
1Answer or search?#
| The caller needs | Use |
|---|---|
| Sources to present, rank, or post-process itself | POST /lmkit/v1/search/search (the toolbox is Querying and Relevance) |
| One answer a person will read, with receipts | POST /lmkit/v1/search/answer |
| An ongoing conversation over the corpus | POST /lmkit/v1/search/chat (section 4) |
| A strong model to synthesize from sources ITSELF (an agent, a copilot) | Search with context_expansion, then let the caller's model write; it knows its own conversation |
The last row matters: when the consumer is already a capable model, hand it sources, not prose. Grounded answers shine when the consumer is a person or a thin client. And for one document in one session, with no tenant and no index to stand up, the lighter door is Chat with Documents over the API.
2What grounding means here#
- Retrieval first: the answer is composed only from content retrieved for the question, under the same tenant settings, modes, and filters as any search (see Indexing Well).
- Citations attached: the response carries the source spans the answer rests on, so a reader can verify instead of trusting, and a UI can link straight to the evidence.
- Refusal over invention: when retrieval yields nothing that supports an answer, the endpoint declines. An honest "the corpus does not say" is the feature, not a failure mode; treat a refusal as a coverage signal about the index, not an error to retry.
Access follows the caller's grants like everywhere else (the Access Model): an answer can only draw from collections the key reaches.
3Getting good answers#
Answer quality is retrieval quality wearing prose. In order of leverage:
- Index well. Everything in Indexing Well applies unchanged; hybrid retrieval with a reranker gives the synthesizer better material to work from.
- Scope the question. Restrict to the relevant collections and metadata filters; a question aimed at everything retrieves noise from everywhere.
- Measure. Measuring Search Quality evaluates retrieval and answers SEPARATELY against the same golden set; when answers disappoint, the pair of numbers says whether retrieval or synthesis is the weak link.
4Grounded chat: the conversational shape#
POST /lmkit/v1/search/chat is the multi-turn form: a session scoped to chosen collections,
where EVERY turn retrieves supporting sources before answering, follow-up questions are
understood in context, and the same cited-or-declined rule applies per turn. Sessions are
managed explicitly: clear a session's history while keeping its scope, delete it when done, and
skip a reasoning phase mid-turn when the consumer wants the answer over the deliberation. This
is the endpoint behind "chat with your documents" experiences, including the
playground's own document chat.
5Related: documents similar to a document#
POST /lmkit/v1/search/documents/similar answers a different question with the same machinery:
not "what matches this query" but "what resembles THIS document", using the document vectors
maintained for semantic search. Reach for it for related-reading panels, duplicate candidate
detection, and clustering seeds.
6Stated plainly#
- Cited or declined: those are the only two outcomes, per answer and per chat turn.
- The synthesis model is local and the sources are yours; nothing consults the outside world.
- Refusals are information: they map what your corpus cannot yet answer, and the evaluation harness turns that map into numbers.