Vector search returns noise when semantic similarity is mistaken for task relevance. Fabricated sources appear when citations are generated instead of verified against retrieved artifacts. Fix both by filtering scope before retrieval, using hybrid search and reranking where useful, and requiring every citation to map to stored evidence.
Last updated: June 20, 2026.
Why does vector search return noise?
Embedding similarity is not the same as answer relevance. A chunk can be semantically nearby but wrong for the user’s scope, time period, source type, or question intent. Without filters and inspection, noisy candidates become plausible answers.
The fix is not only “better embeddings.” Use:
| Control | What it catches |
|---|---|
| Tenant/library filters | Out-of-scope documents |
| Hybrid search | Exact terms and semantic matches |
| Reranking | Weak top-k ordering |
| Source timestamps | Stale candidates |
| Citation ids | Fabricated references |
| Retrieval trace | Why a candidate appeared |
Why do fabricated sources appear?
Fabricated citations appear when the model is allowed to invent references or source labels. A 2026 arXiv audit of 69,557 citation instances found citation fabrication varied widely by model, domain, and prompt framing (How LLMs Cite and Why It Matters). Another 2026 study audited non-existent citations at large scale across scholarly corpora (LLM hallucinations in the wild).
The product lesson is direct: do not ask the model to make citations. Give it retrieved source ids and require the final answer to cite only those ids.
How do you inspect the retrieval trace?
Inspect:
- User query.
- Rewritten query, if any.
- Tenant and library scope.
- Candidate ids and source titles.
- Candidate scores and ranks.
- Reranker output.
- Lifecycle state.
- Citation ids used in the answer.
If a citation does not map to a retrieved source artifact, reject the answer. If a source artifact maps to the wrong tenant, fix permission-aware retrieval first.
How do you fix noisy vector search?
Start with filters and evidence:
- Apply permissions before retrieval.
- Combine vector and full-text search for exact terms.
- Use a reranker for ambiguous queries.
- Tune chunking so answers do not straddle broken boundaries.
- Keep source titles, URLs, and citation spans attached.
- Show the candidate list to developers during debugging.
The MCP architecture docs define resources and tools; your memory server should use those primitives to return evidence the client can inspect.
How do you prevent fabricated citations?
Use stored citation ids. A citation should be a pointer to a source artifact, not a string generated by the model. If the answer includes a citation id that was not retrieved, fail the response or ask the agent to answer “not found.”
This is why Inspectable Agent Memory is a product requirement, not a nice-to-have. You cannot debug fabricated sources from a black box.
What should a grounded answer contract include?
Make the application enforce a contract before the final answer reaches the user:
| Field | Purpose |
|---|---|
| Retrieved source ids | Limits citations to real artifacts |
| Source titles and URLs | Lets users inspect evidence |
| Candidate rank and score | Helps developers debug noise |
| Lifecycle state | Keeps deleted or superseded facts out |
| Tenant and library scope | Prevents permission leaks |
| Answer citation map | Proves each cited claim has evidence |
If a source id is absent, the model should not invent one. If no source supports the claim, the correct answer is “I do not have source-backed evidence for that.”
This contract is also useful for evals. The test can check whether every citation id exists in the retrieved candidate list before judging answer quality.
It also gives support teams a concrete artifact. They can explain which source was retrieved, which source was missing, and whether the answer failed retrieval or citation enforcement.
What should you read next?
Read RAG returns wrong results, Permission-aware retrieval, and the Memory Failure-Mode Catalog.