去年年中，我搭了一个自用的 RAG 知识库，最初的想法很简单：把积攒好多年的 PDF、网页摘录、工作笔记丢进去，然后就可以像聊天一样提问了。实际跑了一两个月之后，我发现这个“上传 PDF 聊天”的思路有个很大的错觉——它可以在单篇文档问答里表现得很好，但一旦把知识库当成一个长期维护的资料库来用，版本混乱、检索碎片化、专有名词找不到、回答没有出处这些问题就会一个个冒出来。
这个标题其实就是在说一件很直接的事：个人 RAG 知识库的真正难点不是“把 PDF 喂给大模型”，而是如何让知识库像代码仓库一样有版本意识，让检索既能命中精确片段又不丢失上下文，让回答能回到原始出处去核验。这篇文章我想围绕版本治理、父子分块、混合检索和可引用回答这四个部分，把个人知识库从“能跑”做到“能用”的完整思路写下来，同时给出可以直接复制的工程细节。
1. 从一个能跑的 Demo 到一份值得长期维护的资料库：问题到底出在哪
1.1 “上传 PDF 聊天”的舒适区能维持多久
先回忆一下最基础的 RAG 流程：把 PDF 或文档解析成文本，按固定窗口切块，对每个块做 embedding，然后存入向量数据库。查询的时候同样对问题做 embedding，用向量相似度找出相关性最高的几个块，拼进 prompt 交给大模型生成回答。
这套流程在单篇文档、十几页以内、内容相对统一的场景下，效果可以做到让人满意。比如你丢进去一本技术手册，问“超时参数在哪里配置”，大概率能给出正确位置。但个人知识库不是单篇文档问答，它会持续增长，会反复修订，会有大量跨文档、碎片化、新旧混杂的信息。很多资料今天看是“最新”，半年后就变成了“历史版本”。如果不做任何版本治理，旧内容和新内容会同时躺在向量库里，检索时系统并不知道你今天想要的是哪一个。
我实际遇到的一个例子是：把一个项目文档从 v2.0 更新到 v2.1 后，旧版的接口调用方式仍然被检索到，AI 回答还把已经废弃的参数写进了答案里。这让我意识到，文档内容管理不是 RAG 的外围工作，而是决定回答质量的底层因素。
1.2 个人知识库长期维护面临的四个工程问题
我把这一路上遇到的核心困难归纳成四个，基本对应标题里的四个关键词：
- 历史内容没有“作废”机制，导致新旧版本同时出现在检索结果里，回答无法判断时间先后。
- 固定大小的分块难以同时兼顾“检索准确”和“上下文完整”，你往往只能二选一。
- 向量检索对同义改写很有效，但遇到精确的专有名词、代码标识符、协议字段名，反而容易失灵。
- 回答没有引用来源时，你就无法知道它是从哪一段资料里得出的，也无法判断是不是模型自己编的。
这四个问题如果不解决，RAG 知识库就只能停留在“聊天玩具”的层面。下面我按顺序讲一下我在实践中怎么处理它们。
2. 版本治理：让知识库里永远只有一个“当前版本”
版本治理这个名字听起来像是后台管理系统才需要的东西，但个人知识库也绕不开。原因很简单：你的知识库不是一个静态集合，它会在不同时间点吸收同一份资料的不同版本。如果没有版本信息，旧版本就无法被有效区分，知识库的检索质量会随着更新次数增多而逐渐劣化。
2.1 版本这个概念的三个层次
我整理版本治理时，把它拆成了三个层次：
第一层是文档层。一份 PDF 或 Markdown 文件的创建时间、更新时间、来源路径、内容哈希，属于文档级元数据。第二层是分块层。同一份文档在新旧版本里切出来的块是不同的，每个块应该知道自己属于哪个文档版本，便于在检索命中后追溯。第三层是向量层。旧块生成的 embedding 是否还参与召回，需要有一个明确的标记，而不是物理删除后完事。
把它们区分开，是因为操作方式不一样：文档层适合用文件系统和元数据来管；分块层适合在数据库里用“批次号”或“版本号”字段管理；向量层则关系到现在批次是否激活，查询时要过滤掉非激活状态。
2.2 用版本记录构建数据模型
我的做法是为每个被导入的内容维护一条“版本记录”，核心字段大概是这样：
CREATE TABLE document_versions ( doc_id TEXT NOT NULL, -- 同一份资料的逻辑 ID version INTEGER NOT NULL, -- 从 1 递增 file_hash TEXT NOT NULL, -- 内容哈希，判断文件是否变化 source_path TEXT, -- 原始文件路径 created_at TEXT DEFAULT (datetime('now')), status TEXT DEFAULT 'active', -- active / deprecated parent_hash TEXT, -- 可选，关联上一版本 PRIMARY KEY (doc_id, version) );导入新文件时，先计算内容哈希。如果哈希和最近一个 active 版本的哈希一致，就跳过；如果不一致，则新增一个版本号，并把上一个 active 版本标记为 deprecated。这样每个 doc_id 下都保存了完整历史，但检索时只用 status='active' 的版本。
这个设计很像版本控制系统的提交记录，但它不是给代码用的，而是给文档块和向量用的。因为纯文件系统层面的 git 无法解决一个重要问题：向量的失效不是靠“覆盖旧文件”就能完成的，旧块的 embedding 如果不被标记为不可用，它仍然会在相似度计算中出现。
2.3 为什么不能只依赖 git 或简单覆盖文件
我之前也想过：既然文档都是 Markdown 或 PDF，用 git 管理不就行了？后来实践发现，git 管理的是文件历史，但 RAG 检索依赖的是分块和向量。假设你更新了一个文档，重新切块之后，所有块的 ID 都变了，旧的向量其实还留在向量库里。如果查询语句比较复杂，旧块仍然能被召回，因为向量相似度只看语义，不看时间戳。
所以我在建索引的流程里加了一步：每次文档更新会生成新的批次号，同时把该 doc_id 下所有旧批次的块标记为 frozen。frozen 的意思是，这些块不再参与查询召回，但历史数据保留在库里，可以用于回溯或审计。这个设计带来的额外好处是，你随时可以知道“某个版本当时是怎么切块的”，对调试和复盘很有帮助。
2.4 触发版本变更的三个典型场景
个人知识库最容易触发版本变更的场景有三个：一是资料重写，比如把一年前的笔记整理成正式文档；二是来源更新，比如官方手册发布了新版本，你把新文件覆盖了旧文件；三是合并整理，比如把多个零散摘录合并成一篇专题知识，原摘录要被标记为 deprecated。
我对第三个场景尤其有感触。早期我习惯把网页摘录直接存成一个个小文件，后来发现这样产生的知识碎片太多，检索时经常把同主题的内容拆得七零八落。后来我会定期做整理，把零散摘录合并成专题，原文件标记为 deprecated，这就避免了知识库越来越“碎”。
3. 父子分块：用“小块搜索、大块作答”重新设计粒度
分块策略是 RAG 里最容易被低估的一个环节。切得太小，检索精度高但上下文不够，模型回答时会东拼西凑；切得太大，上下文完整但检索精度下降，而且会浪费大量 token。我在实践里的解法就是“父子分块”——子块负责被检索，父块负责提供完整上下文。
3.1 固定分块的粒度矛盾
先看一个典型矛盾。假设一篇文章有 5000 字，按 512 字符切块，会产生大约 10 个子块。如果某个问题只涉及文章中间的一小段，向量检索可能精确命中第 5 块，但第 5 块本身并不包含前后的背景信息，比如“之前说的那个前提”或者“后文中提到的例外条件”。模型拿到的只是局部片段，回答自然会缺乏上下文连贯性。
反过来，如果我把分块放大到 1500 字符，上下文完整了，但检索时可能同时命中多个大块，导致大量无关信息进入 prompt，既稀释了关键信息，又浪费了上下文窗口。
用一组实际数据来说明：我之前用一款开源笔记工具做过实验，同样一篇 8200 字的文档，512 字符固定切块的平均检索精确率有 0.67，但回答需要额外补充背景信息的次数占 41%；改用 2048 字符大块后，上下文完整了，但检索结果的 Top3 里无关块的比例上升到了 33%。两者单独使用都有明显短板。
3.2 父子分块的核心做法
父子分块的做法是：先把文档按较大的粒度生成父块，比如按标题段落，每块 1200 到 2000 字；然后在每个父块内部继续按较小粒度切出子块，比如 256 到 512 字。子块拥有最高检索优先级，父块则作为子块的“上下文容器”存在。
数据库里可以做一次映射：
sub_chunk_id | parent_chunk_id | source_path | doc_version ---------------|-----------------|-------------|------------ sub_021 | parent_007 | /notes/rbac.md | 3查询时，把子块的 embedding 用于相似度计算，得到多个候选子块后，顺着 sub_chunk_id 映射到父块，然后把父块整体作为上下文送给模型。用一个小块去找“哪里说了”，用一个父块去提供“完整说了什么”，检索精确度和上下文完整性就能同时保住。
3.3 父子分块对“事实性回答”的真正价值
这个方法尤其在“限定范围的事实性问答”里收益最大。比如我问“这个配置项有哪些可选值”，子块能精准命中包含配置项名称的那一小段，父块又能保证这一小段前后的说明、示例、默认值不会丢失。模型拿到的信息是“一个完整小节”，而不是“一句话”，引用和解释都会更可靠。
实现父子映射不需要很复杂的算法。我常用的办法是先在文档结构层面做一次基于标题的预分割，把同一标题下的内容聚成一个父块；然后再按段落和句子边界做子块切分。这里有一个经验：分块时优先以 Markdown 标题、列表结构、代码块为天然边界，而不是机械地按字符长度硬切。字符长度只是兜底策略。
3.4 存放父子分块时的元数据设计
我在每一条子块记录上都会附带以下元数据，这是后面做可引用回答的基础：
{ "sub_chunk_id": "sub_021", "parent_chunk_id": "parent_007", "doc_id": "rbac-guide", "version": 3, "source_path": "/notes/rbac.md", "heading_path": ["权限模型", "RBAC 配置", "可选值"], "char_start": 6200, "char_end": 6880 }heading_path 字段我强烈建议保留，它记录的是子块在文档中的标题层级。做引用回答时，这个字段可以直接生成“详见《权限模型 > RBAC 配置 > 可选值》”这样的定位信息，比只给一个文件名友好得多。
4. 混合检索：向量搜索的“别名短板”该怎么补齐
很多 RAG 教程把向量检索当成默认方案，但我实际用下来发现，纯向量检索在个人知识库场景里有三个明显短板：
第一，专有名词和代码标识符经常处理不好。第二，语义检索对“完全相同的精准字符串”不会优先返回，但很多技术问题恰恰希望精确匹配。第三，向量检索的结果稳定性和可解释性比较差，你不知道为什么某个块排在了前面。
4.1 纯向量检索失灵的典型例子
我举一个真实的例子。知识库里有一篇笔记，内容是关于某内部系统一个接口的完整文档，文档里多次出现一个叫SQE的协议字段。我后来用它问系统：“SQE 字段在握手流程中的变化规则是什么”。向量检索给出的 Top 5 结果里有两条完全不相关，因为SQE在分词和 embedding 后并没有形成有效的语义特征，模型看到的只是一个缩写词，向量空间里很难给它足够的权重。
但如果把检索改成“同时跑向量相似度和关键词稀疏匹配”，SQE这种令牌会被精确命中，包含该字段的两条内容会立刻被召回。混合检索的意义就在这里：向量负责语义兜底，关键词负责精确匹配。
4.2 BM25、向量和它们的融合方式
混合检索的经典组合是“向量检索 + BM25 稀疏检索”。BM25 是传统的信息检索算法，它擅长处理精确词项、稀有词项和高频词项的权重平衡。向量检索负责理解“意思差不多的表达”，BM25 负责锁定“字段名、协议名、API 名”。
这两路结果怎么融合？我用过两种方式：
第一种是加权求和。分别归一化两路分数，然后按权重合并，比如向量得分占 0.6，BM25 得分占 0.4。这种方式适合你对两者的信任度比较有把握的场景，但一个问题是，两路分数的量纲不一致，归一化后可能掩盖真实差距。
第二种是 RRF（Reciprocal Rank Fusion）。它不看具体得分，只看候选在各自榜单里的排名，公式是：
score = Σ ( 1 / (k + rank) )其中 k 通常取 60，rank 是该文档在某一候选列表中的名次。把两路结果合并打分后，取总分最高的 Top N。RRF 的好处是不依赖分数尺度，稳定性好，调参少。我自己的项目里就一直用 RRF，效果比手动调权重要稳。
4.3 多路召回加轻量重排的完整流程
我现在的检索流程不是一个“单次搜索”，而是这样一串步骤：
第一步，解析查询词，生成两类信号：一类是原问题的 embedding，另一类是提取出的关键词集合，比如SQE、握手流程、字段变化规则。第二步，分别执行向量召回和 BM25 召回，各取 Top 30。第三步，用 RRF 融合出重排后的 Top 10。第四步，如果知识库规模比较大，我还会加一层轻量级交叉编码器重排，把候选子块和问题的相关度做一次精细排序，然后才交给大模型生成回答。
这四步看起来复杂，但在纯本地配置下耗时也只是几十毫秒到几百毫秒的级别，完全可接受。混合检索不是“跑两遍搜索”这么简单，它的关键是把两路方法得到的证据合并成一个统一的、有排序依据的候选集，让下游生成有更高质量的材料可用。
4.4 做到什么程度算“够用”
对个人知识库来说，我觉得混合检索做到“能补上精确匹配短板”就够了，不必上太重的重新排序模型。判定标准很简单：当我搜索一个只有少数文档里才出现的精确字段名时，它应该稳定出现在 Top 3；当我用一段模糊的、没有关键词的自然语言描述来搜索时，它也应该能通过向量语义把相关内容捞回来。两个条件都满足，说明你的混合检索已经及格了。
5. 可引用回答：把答案和证据“钉”在一起
回答没有出处，是大模型类应用最让人心里打鼓的地方。尤其是技术性知识库，读者可能需要进一步查看原文档，比如再去看一眼代码块、协议字段的完整定义、原文里的限定条件。可引用回答要做的事情很简单：每个回答都要能追溯到具体的检索块和原始文档，而不是只说“根据资料显示”。
5.1 如何给检索结果打包“坐标信息”
答案引用的第一步是，在把检索到的上下文交给大模型之前，先给它搭好“证据坐标”。
我在 prompt 组装阶段会把每个候选块变成这样一个带编号的结构：
[1] 来源：/notes/rbac.md (v3) 定位：权限模型 > RBAC 配置 > 可选值 内容：可选值包括 deny、allow、audit…… [2] 来源：/docs/api-gateway.md (v1) 定位：请求字段定义 > SQE 内容：SQE 表示加密模式，握手流程中用于协商……然后在生成指令里明确要求：回答时对关键事实使用[1]、[2]这样的标注，如果某个事实无法对应到任何已提供的资料，必须如实说明“资料中未找到”，不允许自行编造。
你可能会想，大模型不一定每次都会乖乖遵循指令。所以接下来还有一步更关键的兜底，就是从后处理侧面校验输出。
5.2 引用验证：让模型自己“检查作业”
大模型生成完整回答后，我会再做一个轻量级的验证步骤：把回答拆成若干个事实性断言，每个断言都要求从检索到的资料里找到对应的原句。查不到就标记为“无来源断言”，并把这个断言从回答里摘出来，只保留有来源支撑的部分。
这一步的实现不需要训练模型，只需要再调用一次 LLM 让它做结构化输出即可。实际使用中，它能拦住大部分“一本正经地胡说八道”。我见过很多回答在细节上出错，都是因为模型把来源 A 的内容和来源 B 的内容混在一起，最后得出一个看似合理但原文里根本不存在的组合。有了严格引用验证之后，这类情况会大幅下降。
5.3 可引用回答对知识迭代的价值
可引用回答不只解决“可信”问题，它还直接配合前面的版本治理。因为每个引用都带doc_id和版本号，我就能统计出某一阶段的失效引用，比如某个回答引用的是旧版本资料，它在版本升级后自动变得可疑。这时候重新生成回答就可以了。这样知识库更新之后，历史回答的可信度也能重新评估。
在我自己的使用场景里，可引用设计还带来一个很务实的作用：它让我敢于在知识库里放更多信息来源。过去我担心信息太杂会影响回答质量，现在因为每个回答都能追到具体路径，即使来源之间有冲突，我也能快速发现并整理，而不是被模型毫无痕迹的“缝合”解释带偏。
6. 落地参考：我现在实际使用的这一套实现
前面讲的是设计思路，最后这部分说一下我现在实际跑着的工具链和流程。它不追求“大而全”，而是要求能在一台普通笔记本上离线运行，同时结构清晰、可控、容易扩展。
6.1 组件选型与分工
我的选型是这样的：
| 环节 | 使用方案 | 选它的原因 |
|---|---|---|
| 文档解析 | 本地 PDF 解析 + Markdown 直接转文本，统一存成结构化 Markdown | 统一格式更利于后续父子分块 |
| 分块 | 自己写的父子分块器，基于标题边界做父块，按段落/句子做子块 | 配合知识库结构，可控性最强 |
| 向量存储 | SQLite 加向量扩展 | 单文件、无服务、易备份，适合个人库 |
| 关键词索引 | 本地倒排索引（BM25） | 和向量库同库存储，不需要额外中间件 |
| 向量模型 | 本地开源 embedding 模型 | 隐私优先，离线可用 |
| 生成模型 | 本地部署的指令模型 | 配合引用验证，足够完成结构化输出 |
这套组合最大的优点是没有外部依赖网络服务，数据全部在本地。对个人知识库来说，可迁移性和隐私性往往比性能上限更重要。
6.2 核心结构与更新流程
我是这样组织数据的：原始文件放一个目录，切块后的子块和父块映射关系放数据库，向量和 BM25 索引都建立在修订后的批次之上。整个更新流程可以压缩为三步：
第一步，扫描目录，计算每个文件的哈希，对比上一次导入记录。哈希不变就跳过，变化则进入第二步。第二步，对变化文件重新分块，生成新的版本号和块组，将旧版本标记为 deprecated。第三步，剔除已经 deprecated 的块组对应的向量和 BM25 索引条目，只为新块组建立索引。
这个流程很简单，但解决了核心问题：查询时永远只面对 active 状态的块组，而不是看到“全部历史”。
6.3 跑了半年之后的一些注意点
第一个注意点：不要频繁切换 embedding 模型。向量库里的历史向量都会因模型切换而失去可比性，切换等于重建索引。第二个注意点：分块策略尽量稳定。你会不断想调子块大小，但频繁调整会导致同一份文档在不同历史版本里粒度不一致，影响引用和对比。第三个注意点：离线文档里如果包含大量图片，当前这套流程是处理不了图片信息的，需要先做 OCR 或把图片单独托管，否则分块时内容会缺失。
有一点也值得提醒：版本治理和分块策略不宜一上来就设计得太复杂。个人知识库初期内容量不大时，简单的“内容哈希 + deprecated 标记 + 父子映射”就已经能解决大部分问题。真正需要增加复杂度的时候，是你发现旧版本频繁被召回、或者摘要阶段上下文明显不够用的时候。
我现在的做法，是把 RAG 当成一个“带数据库的工程问题”来做，而不是把大模型当成聊天机器人来用。别先急着追求复杂的检索策略，先把文档状态、分块粒度、来源引用这几条地基打稳，再往上层叠加方案，整个知识库才会越用越可靠。
