给个人知识库补上出处

把一个文件夹里的文档交给模型，然后要求“只根据资料回答”，听起来已经很接近个人知识库了。真正开始使用时，问题往往出现在更细的地方：检索到的段落缺少标题，旧版本和新版本混在一起，回答里的链接无法指出具体证据。

这份 DIY 笔记从二十篇公开技术文档起步，目标是完成一个有出处、能够拒绝猜测的阅读助手。这里没有跑分结论，只有一套可以逐步检查的搭建方法。

先把引用当作数据

RAG 论文把检索与生成结合起来处理知识密集任务。本文借用的是这个基本方向，后面的目录结构、检查清单和练习阈值都是本站的设计选择。

第一步不急着选向量库。先给每份文档一个稳定编号，并保存来源、版本与段落锚点。一个最小片段可以长这样：

{
  "documentId": "mcp-architecture-2026-07-28",
  "section": "Primitives",
  "sourceUrl": "https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture",
  "retrievedAt": "2026-10-21",
  "text": "此处存放实际抓取并核对的片段"
}

示例中的片段文字是占位说明，不能直接作为证据入库。实际处理时要保留抓取原文和清洗记录，使“这句话来自哪里”成为程序能够回答的问题。

给切分方法做一个小实验

我会先尝试按标题切分，再为过长章节增加长度上限。代码块、表格和列表尽量保持完整。如果把一个参数表切成两半，模型拿到参数名却没有说明，检索命中也未必能帮助回答。

为这个练习准备三类问题：能由一个段落回答的，必须联合两份文档的，以及资料里根本没有答案的。最后一类尤其有用，因为系统不应该把“搜到一些相近词”当作“已经找到证据”。

把检索失败和生成失败拆开看

当回答不对时，先保存当次检索结果，暂时不改提示词。若证据没有进入候选集合，修正方向通常在索引、过滤或查询表达；若证据已经存在却被误读，再查看上下文组织与回答约束。

flowchart LR
  Q[问题] --> R[检索候选片段]
  R --> F[版本与权限过滤]
  F --> E[检查证据覆盖]
  E --> G[组织回答与引用]

练习里的“证据覆盖”不必是一个神秘分数。可以让答案的每个关键结论对应至少一个片段编号，再由程序检查编号确实属于本次检索结果。这只能检查引用关系，不能证明结论本身正确；重要内容仍需要人工核对。

给知识库留一个更新入口

同一份规范出现新版时，不要让两个版本的片段共享一个模糊编号。保留版本信息，并让查询显式选择“当前版本”或“历史比较”。删除文档时，也检查向量索引、文本存储和引用目录是否一起更新。

这个项目可以从一张检索结果页开始验收：问题在上方，候选片段在中间，答案与引用在下方。先让人看清依据，再给界面增加更漂亮的聊天气泡。

相关笔记：上下文也需要预算。