How to build search people will actually trust.

Running a knowledge graph alongside vector search and using it to reach documents the query's own wording would never find. In practice it adds two retrieval passes: one that expands the query with entities reached by traversing the graph, and one restricted to the documents that provide provenance for the facts crossed. The vector search still runs at full weight, so the graph is additive rather than a replacement.

It is a superset, so it is better on the specific question type where an answer requires a relationship no single passage states. It is worse on latency and cost, and it adds nothing at all for lookup questions, single-source corpora, or small collections. The honest way to decide is to count your content sources and sample twenty real questions for how many need two documents.

The record of which document asserts which fact. It matters because the common designs are wrong: a single document reference per fact breaks the second time two documents agree, and the fix is one row per document-fact pair with its own confidence. That is what makes corroboration countable and makes a fact retract only when its last supporter is removed.

Number the sources in the prompt, require numeric markers, then validate the markers against the sources you actually supplied and drop the ones that do not resolve. That is about fifteen lines of code and it eliminates the failure that costs the most credibility — a footnote pointing at nothing. Count the invented markers, too: a rising rate usually means retrieval is returning too little.

Because your first vocabulary is always wrong — nobody knows their own taxonomy before extracting it — and in most systems changing it means deleting entities, re-running extraction, or accepting an inconsistent graph. All three are bad enough that nobody changes it, so it freezes and the corpus grows past it. Making conformance a computed flag rather than a destructive operation makes change cheap enough to actually happen.