关注我的老朋友应该还记得我上个月还在长篇大论地聊RAG知识库的工程细节。当时我说了一句话RAG的瓶颈从来不只在模型更在知识的纯度。结果没过多久我自己就被现实抽了一嘴巴——我特别关注的一位知乎答主突然销号了他写过的一系列硬核文章我还没来得及整理完就再也打不开了。这件事触发了我整个项目的新方向把“人物”的知识资产做一次彻底蒸馏沉淀成可复用、可检索、可长期演进的知识库。这不是简单的“存网页”或者“放PDF”而是把一个人的表达方式、论证框架、知识密度、实用案例全部抽出来重新组织成一个结构化系统。整个过程走完踩了无数坑也积累了很多第一手的实战心得。这篇就把整个思路和做法整理出来给同样想给知识做保存、给信息做提纯的朋友一个完整的参考。1. 为什么是“蒸馏”而不是“备份”或“收藏”1.1 存储是廉价的遗忘是昂贵的之前有人问我你直接把他的文章全存下来不就行了何必搞什么蒸馏存下来确实简单。但存下来之后呢几个月后你想用一个具体观点——比如他对“如何设计Agent工具调用边界”的分析——你面对的是一堆散乱的、上千字的、互相重复甚至矛盾的文章。你得一篇篇翻翻完还未必找得到。收藏是一种错觉真正让知识产生价值的是“取用”。所以这个项目从一开始我的定义就不是“做备份”而是“做提纯”。蒸馏这个词在这里不是比喻而是方法论把原始语料里高密度的知识、观点、案例、步骤抽出来把情绪、重复铺垫、无关信息、过时结论全部滤掉。剩下的浓缩物再重新组织和索引才是能反复使用的东西。1.2 知识蒸馏的教师-学生框架在这里怎么用模型蒸馏领域有个经典框架教师模型输出软标签学生模型学习压缩后的分布。我在做这个RAG项目时也借用了这个思想——整个资料体系里有两层蒸馏第一层是“语料蒸馏”把原始文本变成知识卡片。这对应的是把教师的全部输出转成精炼、结构化、可拼接的知识单元。第二层是“检索蒸馏”用户提问时不是把所有知识都塞给大模型而是通过检索把最相关的少量卡片抽取出来再让大模型基于这些卡片生成答案。这相当于推理时动态构建一个“迷你学生模型”。这两层蒸馏合起来才是完整的“人物知识蒸馏”。只做第一层最多算半个知识库只做第二层那跟普通直接喂给大模型没有区别。提示核心原则是——知识库的职责是“让对的知识在对的时间出现”而不是“把所有知识都塞进去”。2. 语料要怎么做减法从干瘪文档到高密度知识卡片2.1 第一步不是切分而是标记“知识类型”很多RAG教程一上来就教你怎么按字数切文本这是个很深的坑。纯按字数切等于把一篇逻辑完整的文章剁成肉馅——每一块看起来都是内容但拼不回去。我做的第一件事是通读一遍全部语料给内容打上类型标签。这个过程让我意识到一个核心矛盾不同知识类型的用户需求完全不同如果全部走同一个处理管线结果就是四不像。我把知识分成四类观点型作者对某个话题的立场、判断、预测。比如“Agent工具调用不应该让模型自由发挥必须有硬性校验层”。步骤型可执行的实操流程。比如“先用伪代码写流程再定义工具返回格式最后做边界测试”。案例型具体事件、数据、实证。比如“某次实验里温度调高到0.9之后模型输出重复率上升了15%”。原理型底层机制解释。比如“为什么RAG需要混合检索——向量检索擅长语义相似关键词检索擅长精确命中和专有名词”。每一种知识类型对应的切分策略、检索权重、生成时的引用方式都是不一样的。观点型要保留完整论证过程步骤型要拆成可执行清单案例型要保留时间、环境、数据原理型则要保留逻辑链条。这四类混在一个切分窗口里是RAG效果差的常见根源。就好比一本菜谱你把“糖醋汁配方”和“要不要把排骨先焯水”的逻辑搅在一起让人怎么读2.2 知识卡片的字段设计让每一片都能独立作战打标完成后我把所有语料切成了统一的“知识卡片”。每张卡片字段如下字段说明示例source_id原始来源编号zhihu-author-001source_type知识类型step / opinion / case / principletitle卡片标题工具调用校验层的三点设计content提纯后的核心内容不超过500字的高密度脚本tags主题标签Agent, Tool-use, Safetytimestamp原文发布时间/语境2024-05refs关联卡片IDzhihu-author-003quality_score人工初筛质量分0.95这个设计的核心理念是每张卡片都应该能独立回答一个问题而不是依赖上下文。内容字段不保留“我今天想聊聊”这种废词也不保留大段的情绪铺垫。一旦内容被检索出来它应该是可以直接拼进生成上下文的半成品。有个反直觉的点内容字段越短检索命中率越高。500字左右的卡片既能承载一个完整观点又不会稀释向量表征的语义精度。我试过把内容压到200字结果很多逻辑跳步导致上下文不连贯我也试过无脑保留800字以上结果大量无关细节冲淡了检索精度。500字是一个甜点区间。2.3 清洗与去重蒸馏的第一个核心动作原始文本直接进知识库等于把垃圾和黄金一起送进熔炉。我的清洗流程分了几步第一步去噪声。文章正文两侧的推荐引导、版权声明、评论区高赞语录全部剥离。这个过程不复杂但需要用正则表达式加上人工抽查配合完成不能全自动跑一遍就不管了。第二步去重复观点。同一个答主在不同月份、不同问题下大概率会反复表达同一个核心观点。比如“评估RAG系统要看召回率而非只看最终答案”这句话他可能说过五遍。我不需要五张重复卡片而是需要一张完整卡片加上五条“出处引用”。这既避免了向量库里的冗余冲突也保留了史料的完整性。第三步去错误与过时信息。我在通读时发现有几篇文章里引用的数据和他后来的实际结论存在冲突。这种情况下我以时间戳最新的卡片为准旧卡片不删除但打上“superseded”标记检索排序时会被降权。这比直接删掉更有价值——至少保留了观点演进的轨迹。由于原始语料量比较大首轮清洗不可能全做。我的经验是先用关键词和规则把明显噪声过滤掉然后对保留下来的核心主题文本做人工精读。你的精力应该全部花在最高价值的20%语料上而不是试图用工具处理100%的内容。3. 知识库的底盘向量化、索引结构与混合检索3.1 嵌入模型选型bge-m3还是OpenAI系列清洗和切分完成后就进入技术底盘的搭建。第一步是选嵌入模型。现在常用的选择有这几条路bge-m3中英双语泛化能力强本地可跑、OpenAI text-embedding-3-small云端调用便捷但需要注意数据出域、还有Cohere的embed-v3多语言效果好但要考虑网络条件。我这次的语料是中英混合的很多专业术语是英文上下文是中文bge-m3在这种场景下表现比较稳最后一个向量库里就是用bge-m3维度1024相似度计算用余弦距离。这里必须说清楚向量维度不是越大越好。维度大意味着表征更精细但也意味着更大的存储开销和更慢的检索速度。1024维处理小几万张知识卡片完全没问题。如果只是几千张卡片级别的个人知识库用768维甚至512维也够不必为了规格好看而堆维度。3.2 为什么我最终选择混合检索而不是纯向量纯向量检索的最大问题是专有名词和精确匹配的薄弱。比如你想搜“RAG瓶颈”向量检索能找到语义上相近的“检索增强生成的问题”但如果你输入的是人名、产品名、术语缩写比如“CoT”向量检索容易跑偏。所以这次我用的是混合检索向量召回加BM25关键词召回然后合并去重再做重排。BM25负责精确命中向量召回负责语义发散两者互补之后召回率明显提升。混合检索里一个容易忽略的点是向量权重和关键词权重的配比。我一开始设置成五五开结果发现大量长尾内容被无脑召回噪声很大。后来改成向量权重0.7、关键词权重0.3效果明显改善。原因是知识卡片本身已经做了蒸馏和打标语义密度很高向量检索的可靠性被放大了关键词只需要兜底处理专有名词即可。3.3 重排层的必要性检索只是前半场很多人做RAG到“召回Top5”就结束了然后直接把Top5拼进Prompt让模型生成。这样做的结果是召回里的前几条大概率是沾边的但未必是真正切题的。有些高度相关的内容被排到了第8、第9位。我加了重排层用rerank模型对召回结果重新打分。重排不是简单地把相似度从高到低排序而是结合查询语义和文档语义做精细匹配。实测下来加了重排之后生成答案的相关性提升非常明显——具体提升幅度我在后面会放测试数据。在实现上我建议重排层的候选集不要太小。如果总共只有三条候选重排根本没有空间。我的做法是向量召回25条、关键词召回15条合并去重后大概30条左右再交给重排模型挑出前5条。这个“粗召回-精重排”的漏斗结构是RAG效果稳定的关键。4. 从问答测试中看出门道最值得优化的地方不是模型4.1 基线评测直接问AI vs 蒸馏知识库整个系统搭完后我做了12组覆盖不同知识类型的测试问题对比三种模式A模式直接问大模型不提供任何检索上下文B模式接入了蒸馏后的RAG知识库但未加重排C模式接入了RAG知识库加重排测试结果表测试问题类型A模式无RAGB模式RAG无重排C模式RAG加重排观点型问题回答模糊没有原作者的论证风格能还原基本立场但细节偏少立场论证链条基本完整步骤型问题会编造通用流程步骤覆盖约70%顺序偶有错乱步骤完整顺序清晰可执行性高案例型问题容易编造数据数据命中时间戳偶有错位数据准确语境完整原理型问题能答大方向但深度不足深度明显提升逻辑略散逻辑链清晰因果分明这个结果有个重要启发RAG加进来的作用不是“让模型更聪明”而是“让模型有据可依”。模型在那里的推理能力是不变的但你给它的上下文质量变了最终答案的质量就天差地别。4.2 RAG瓶颈的真实位置在语料端不在算法端我在测试过程中最深的一个体会是很多人做RAG效果不好第一反应是换向量模型、调chunk参数、换重排模型但真正的瓶颈往往在更前面——语料本身的质量。蒸馏前和蒸馏后的对比最说明问题同样的向量模型、同样的检索参数蒸馏前的语料做出来的知识库回答经常跑偏、内容空泛蒸馏后的语料进入同一个管道回答的准确度和信息密度同步提升。检索算法的优化空间是有上限的但语料提纯带来的提升近乎没有上限。所以我的结论是RAG的“瓶颈”很大程度上是知识表示层面的瓶颈。你往库里放的全是原始噪音再好的检索器也只是在垃圾堆里寻宝。4.3 chunk_size和overlap的工程调优记录这条经验很适合分享给正在做RAG的朋友。最开始我用的是256字符切分结果一塌糊涂——知识卡片里的长逻辑链被切断了检索到的内容全是半截话。后来调整为1000字符分块overlap设120字符配合之前的卡片结构效果才稳定下来。为什么是1000?因为一张高密度的知识卡片通常在500字左右加上必要的上下文关联信息1000字符能保证一张卡片的语义完整性同时最多和下一张卡片发生一个小边界的重叠这个重叠量足够做上下文桥接但不会造成大范围重复。如果你用的是外部来源的原始长文档没做蒸馏处理我建议分块窗口直接设为1500字符左右overlap设200防止长段落逻辑被拦腰斩断。如果你的语料本身已经是结构化程度很高的知识卡片那800到1000就足够了。切分窗口不是一个全局固定的参数它要跟着你语料的“语义粒度”走。5. 从文本到知识网浅谈RAG知识库与结构知识库的边界5.1 为什么扁平向量库会撞墙蒸馏完之后我的库是一个典型的扁平RAG结构卡片向量关键词索引。它的优点明显——易构建、易维护、易扩展一个小几万卡片规模的库个人电脑上完全跑得动。但我也遇到了它的边界。比如一个问题按照答主的观点工具调用校验应该分几个层次纯向量检索能找出“校验层”相关内容但它很难回答“校验层跟安全层是什么关系”“这两者的依赖顺序是怎么演变的”——这些牵涉到知识的层级结构而扁平向量库编码这种关系的能力比较弱。5.2 什么时候该上KG和Ontology业界现在讨论很多的GraphRAG、知识图谱、Ontology RAG本质上都是同一个痛点把知识库从“一袋土豆”变成“一张网”。没有图谱的知识库适合回答“包含什么”的问题比如“他有没有讲过强化学习”有图谱的知识库还能回答“怎么关联”的问题比如“他的Agent设计原则跟他之前对模型幻觉问题的分析有什么联系”。我第一次接入图谱节点时选了一个比较轻的实现不搞完整的属性图只为知识卡片上的核心实体和关系建表。实体包括概念如“工具调用”“提示词注入”、方法如“混合检索”“重排机制”、案例如“某次Agent任务执行失败的分析”关系则包括“前提”“结果”“反例”“依托”等。接入图谱之后我最满意的一个应用场景是跨卡片追溯当用户问“这个答主对RAG的批评跟他早期对知识库的评价有什么关系”系统可以从图谱节点跳到观点演变路径上给出一个时间轴式的回答。这个能力是纯向量库很难做到的。5.3 关于“RAG知识库能不能存图片”这个问题最近总有人问“RAG知识库能存图片吗”。我的答案是能但你要想清楚图片在知识库里的角色是什么。如果你要存的是“含文字的截图”那直接用OCR提取文字后入文本卡片这是最简单可靠的路径。如果你要存的是“需要视觉语义理解的图片”比如架构图、数据图表那就要用多模态嵌入模型把图片向量化检索时用文本去匹配图片向量。还有一条路是给图片写高质量文字描述然后把描述向量化检索返回图片本身。我这次的项目里架构图类内容基本都走了“文字摘要原图引用”的方案原因很简单纯多模态向量化的检索精度目前还是比文字描述差一截。我的建议是文本内容为主的知识库图片一律走“OCR或描述化”的路线。真正值得多模态入库的是那些非图像不可的场景比如设计稿、手绘流程图、UI对比图。混用时要按知识类型切分好别把所有东西一股脑塞进同一个向量空间。6. 踩坑实录那些文档里不会写、但实测中一定会遇到的坑6.1 人名、作品名和简短术语的召回问题第一个坑是纯向量检索对简短术语的召回非常不稳定。我一开始把“Agent”作为查询词结果召回的向量千奇百怪有的甚至与智能体毫无关系只是因为语义向量空间中“Agent”和“自主”“决策”等词的余弦距离比较近。解决方式非常简单把术语表单独维护查询时先做术语表的精确匹配命中后直接把对应卡片加入候选集。这个“术语表自定义词典”版本的检索比任何调参都管用。6.2 卡片之间的“断链”问题切分后的卡片是独立存储的但很多知识是跨卡片的。比如一张卡片讲“工具调用的校验层设计”另一张讲“校验层失败的典型场景”如果检索时只命中第一张第二张就丢失了。我后来给卡片建了显式关联字段“related_ids”在建库时通过人工规则提取的方式把强关联卡片互相绑定。检索时如果命中的卡片带有关联ID我会把这些关联卡片的标题也放进候选集由重排层决定是否保留。这个机制让跨卡片追问能力提升了一大截。6.3 检索阈值设置的失误最初我把相似度阈值设到了0.8结果发现大量本应召回的低分卡片被挡在了门外重排层根本拿不到候选内容。后来我把阈值降到0.6用召回数量的上限来控噪效果反而更好。阈值的作用是过滤显而易见的噪声不应该承担质量把关的职责——质量把关交给重排层。6.4 运行环境的坑Mac本地的实践记录测的时候我顺便在Mac上建了一个小规模版本用来验证本地运行是否顺畅。结论是完全可行但有几点要注意。一是嵌入模型尽量用CPU能跑得动的中小尺寸模型。bge-m3在M系列芯片上以CPU模式运行速度是慢一些但配合小规模卡片库完全可接受。二是本地向量库我用的是轻量级的比如chroma、lancedb这类没必要上来就上Elasticsearch这类重型工具。三是苹果统一内存对向量检索有天然优势——几千张卡片的向量矩阵全放内存里没有压力加载速度比传统磁盘快得多。想复现这个项目的朋友如果数据量在几千到几万卡片之间一台MacBook配上本地嵌入模型加轻量向量库完全够用。7. 最后说给关注这件事的朋友们做这个项目的起因是那个答主被封号但从结果来看它把我一直想做的“知识提纯”工程往前推了一大步。说到底关注一个答主、收藏一篇文章、存一个PDF都太轻了轻到它们无法对抗时间的流逝、平台的变动、个人注意力的转移。真正的知识资产不是“我存过”而是“我能随时调用、复用、演化”。我在这套系统上得到的实际收益很简单以前我要想一个观点得回忆是在哪篇文章里看到的现在直接提问知识库把证据链递到我面前。这种感觉确实是不一样的。如果你也想给自己的知识来源做一次蒸馏我的建议是不要等积累大量内容之后才开始先用一个你关注的作者、一个你熟悉的话题跑通全流程。蒸馏的能力不是读出来的是处理真实语料练出来的。在这个过程中你会重新理解自己为什么关注那些人、收藏那些文章——很多时候你以为你收集的是信息其实你在收集的是某种密度而密度是可以被提纯和复用的。