#检索与上下文：让证据进入回答

核心概念 · RAG 是证据路径，不是单次向量查询

一个可靠的回答不只是“找到了相似文本”。它还要说明哪些资料被允许使用、当前版本是什么、哪些片段支撑了答案，以及资料变化后如何修正结果。

#先定义“回答可以靠什么被相信”

在设计检索前，先写下答案的证据合同：它要回答的问题、可以使用的来源、最低引用粒度，以及找不到合格证据时的表达方式。这样团队是在设计“可解释的回答”，不是在追逐某个相似度分数。

一个最小证据包应当让使用者看见：来源是什么、来自哪个版本、支撑答案的具体位置，以及这份资料为何适用于当前问题。具体如何保存和检索由 adapter 能力决定，但这些判断不应消失。

#证据包，不只是命中列表

检索阶段的产物应该是一个有限、可解释的证据包。它至少要保留：本次问题的范围、候选为何适用、每个关键片段来自哪个来源与修订、以及它是否足以支撑某个结论。下游模型或应用可以决定如何组织语言，但不能丢掉这些判断。

#0.x 目标行为必须保持什么

未来实现可以组合语义检索、关键词检索、过滤、重排或关系查询，但必须保持三项用户结果：只从合格资料中选择候选；结论能回到足够的证据；没有合格证据时结果明确降级。任何更换模型、索引或 adapter 的工作都不能默默弱化这三点。

#为什么不要把它缩成“向量数据库”

向量索引只覆盖检索中的一部分。它不能独立决定资料是否有效、旧版本如何撤回、关键词与语义检索如何协作，或引用要怎样回到原文。

lorebit 的 core 应拥有这些工作流责任；底层存储只负责自己声明过的能力。

#用户要检查什么

• 回答能否说明它依赖了哪些资料？
• 原始资料更新后，旧答案怎样失效或重建？
• 某一类索引不具备能力时，系统是否明确说明，而不是静默换一种行为？

#用一次对照检查设计

拿同一个客户问题分别配对一份当前规则和一份旧规则。设计应能解释为什么当前规则被选中、旧规则为何被排除，以及答案会附带哪一处原文。若只能说“当前规则更相似”，说明证据、版本或生命周期还没有进入工作流。

下一步：交付带证据的回答。