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 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:

1. Index well. Everything in Indexing Well applies unchanged; hybrid retrieval with a reranker gives the synthesizer better material to work from.
2. Scope the question. Restrict to the relevant collections and metadata filters; a question aimed at everything retrieves noise from everywhere.
3. 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.

On a farm. A grounded chat session is a record of the identity store every node shares: its scope (cluster, tenant, collections, model and the retrieval and grounding defaults fixed at creation) and its conversation history, written by the node that answered the last turn. A follow-up, clear-history or delete that reaches a sibling node is served there: the sibling rebuilds the conversation from the recorded history (re-prefilling it, which costs that turn a little latency once) and records the new history in its turn, so a client behind a balancer without affinity keeps its dialogue. The session_id the server mints still opens with the creating node's six-character tag; the creating response names the node in X-LMKit-Node (every response does) and, on a fleet member, sets the lmk-node=<tag> cookie a cookie-aware balancer routes on, which keeps a dialogue's turns, and their warm prefixes, on one node when the balancer honours it (Behind a Reverse Proxy). skip-thinking acts on the node running the turn it is meant to skip, so it needs the same node as that turn. A session that expired or was deleted answers the 404 Unknown session. wherever the request lands; a session whose record cannot be read (the shared store unreachable) while its id names another node answers 421 Misdirected Request with { "error": "not_on_this_node", "node": "<tag>", "hint": ... } naming that node. Retrieval itself, search/answer and search/search, is stateless on every node of a fleet whose cluster runs on an external engine (Storage Engines and Deployment, Scaling Out).

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.