企业官网建设流程全解析

最早提出一个人把 AI 知识库跑起来的时候，有朋友直接问我：总共三百多张知识卡，值得折腾吗？我当时的回答是：值不值，要看这些卡片能不能被反复使用。先说我说的“395 张卡”是什么意思——它是我花两年多时间整理出来的最小知识单元，不是网上下载的整本 PDF，也不是随手丢进收藏夹的网页剪藏。而“17 把秤”是指我搭完知识库后设计的一套评估体系，用 17 个可量化指标，反复衡量这套 RAG 系统到底好不好用。这篇文章就把完整思路、工具选型、指标设计和踩坑记录写清楚。哪怕你手上只有一台普通电脑，也完全可以用类似流程，把个人笔记变成真正能回答问题的 AI 知识库。

很多教程一上来就教你怎么装软件、怎么上传文件，但从来不问你准备怎么判断它“好不好用”。这是我个人觉得最该先补上的一课。下面我会把自己走过的路完整拆开讲，包括为什么拆层、怎么设计指标、怎样根据指标做优化，以及单人维护一套知识库时会遇到哪些坑。

1. 一个人建 AI 知识库，到底在建什么

1.1 知识库不是“大模型聊天窗口”，而是你自己的答案来源

先澄清一个概念误区：把大模型接上聊天页面，再传几个文档进去，这不叫知识库。真正的知识库，核心是 RAG，也就是检索增强生成。流程可以简单理解为：你提问后，系统先在你自己的资料库里找出可能相关的片段，再把这些片段连同问题一起交给大模型，让模型基于这些片段组织答案。

如果没有这个检索步骤，大模型面对“我上次整理的那篇技术方案里，对部署环境的约束条件是什么”这种问题，基本只能胡说八道。通用模型并不知道你上个月写过的方案，更不知道你收藏的文章里哪一段提到过什么。知识库解决的就是这个具体问题：让内容不再躺在硬盘里，而是变成可以被逐段检索、逐条引用、按需取用的信息资产。

一个人建 AI 知识库，本质是要搭一套“只属于自己的检索问答系统”。规模不需要像企业级那么夸张，但该有的环节一个都不能少：内容清洗、分块、向量化、建索引、检索、重排、生成、评估。这听起来好像很复杂，实际做下来会发现，真正花时间的地方不是安装工具，而是把内容整理成机器能理解的形态。

1.2 我的 395 张卡是怎么来的

有人可能会问：为什么用“卡片”这个词，不用“文档”？因为文档太宽泛了。一份上百页的技术文档里什么都有，模型没法精准找到你问的那一句。我整理知识库时遵循的是一个原则：一卡一主题。

最初，我把自己近三年的笔记全部倒出来，里面有项目复盘、读书摘录、工具教程、会议记录、踩坑心得，甚至还有一些临时备忘。我花了差不多两个周末，把颗粒度太粗的内容拆开，把散落各处但讲同一件事的内容合并，最后得到 395 张相对独立的知识卡。每张卡只讲一个核心主题，长度大多控制在三百字到六百字之间。比如一张卡讲“如何设置 Dify 知识库的分段标识符”，另一张卡讲“本地向量库在导入大量 PDF 时为什么会卡住”，这两件事不会混在同一张卡里。

这个整理过程没有任何 AI 技巧，全靠手动判断，但它决定了知识库的下限。如果源头内容混乱，后面无论你换多强的模型、多好的向量库，检索结果都会跟着乱。所以我强烈建议：建库之前，先花时间把内容原子化，让每一条资料回答“一个什么问题”这件事足够清晰。

1.3 为什么我为知识库专门配了 17 把“秤”

很多人在建库时会陷入一种自我感觉良好的状态：随便找两个问题试一下，感觉答案挺像那么回事，就宣称知识库已经建成了。可一旦真实使用，会发现有些问题能答上来，有些问题答非所问，甚至引用了一段完全无关的内容。问题出在哪里？没有人说得清，因为没有度量。

我做知识库的第二步，不是急着接大模型，而是先定下一套评估体系。整套体系一共 17 个指标，所以被我戏称为“17 把秤”。这 17 把秤分成三组：第一组负责秤“搜得准不准”，对应检索质量；第二组负责秤“答得好不好”，对应生成质量；第三组负责秤“以后还能不能持续维护”，对应工程可持续性。

有人会觉得，一个人的个人知识库搞 17 个指标，是不是太过了？我的实际感受是，不过度。正因为一个人没有团队帮忙测试，才更需要用固定指标替代主观感觉。否则你改了分块策略，到底是变好还是变坏，单靠“试了两个问题”根本无法判断。有了这些秤，每一次改动都能看到量化变化，这是单人项目能不能长期推进的关键。

2. 工具选型：我把知识库拆成四层，而不是选一个“全家桶”

2.1 先理解知识库的四层结构

市面上有不少“一键搭建企业知识库”的产品，看起来很美，但大多数是黑盒。界面里让你填 API Key、传文件、点创建，然后它就给你一个聊天窗口。这种方式快速试用可以，但对于想长期维护、想深入优化的人，我并不推荐。

我更建议把 AI 知识库理解成四层结构：内容层、索引层、检索层、生成层。内容层负责存放和管理原始资料，也就是我那些 Markdown 格式的知识卡。索引层负责把卡片切分成合适的片段，然后调用嵌入模型把文本向量化，写入向量数据库。检索层负责在收到提问后，同时做向量检索和关键词检索，把候选片段捞回来，再进行重排。生成层负责把排序靠前的片段和用户问题一起打包成提示词，交给大模型生成答案，并把引用的来源标注清楚。

把这四层分开看，最大的好处是你可以知道问题到底出在哪一层。比如答案引用错了，可能是检索层召回了无关片段，也可能是生成层没按提示词要求只使用片段；如果检索速度慢，可能是向量库索引参数问题，不一定是模型问题。如果一开始就用全家桶，任何一个环节出错，你都没有调试入口。

2.2 内容层我保留了 Obsidian，它才是我的“母库”

我的知识卡原先就放在 Obsidian 里，用双链互相引用。搭建 AI 知识库时，我没有把这些卡片全部搬进一个专用系统，而是让 Obsidian 继续作为唯一的内容源头。

为什么这么选？因为知识库的第一生命力是内容更新。我平时阅读、思考、写复盘都在 Obsidian 里完成，这些内容天然就是可编辑的 Markdown 文件。如果我把内容复制到另一个封闭系统里，以后每次更新都要维护两份，一个人很快就会坚持不下去。

如果你没有用 Obsidian，用 Typora、Notion 甚至纯文件夹管理也完全可以。关键在于，原始资料必须使用开放格式保存，最好带明显的标题层级和元数据字段。做 AI 知识库最怕的是内容躺在 PDF 图片里，或者保存在一个无法批量导出的软件里。我的做法是：Obsidian 里的每张知识卡都保留一个唯一的文件名，并在文件头部写上 tags、date、source、summary 等元数据，以后扫描入库时可以自动读取。

2.3 索引层、检索层、生成层怎么配合

我的主流程用的是开源知识库工作台 Dify，部署在一台普通电脑上，向量数据单独放在本地向量数据库中。扫描 Obsidian 文件夹后，系统会读取每张卡片的正文和元数据，按规则切分，再调用嵌入模型把每个片段转成向量。

当时为什么没选 AnythingLLM 这类更轻量的工具单独走完所有流程？因为 Dify 提供了更完整的数据集管理能力，界面里能看到每个知识库分段、检索命中情况、引用来源，调试起来更顺手。AnythingLLM 我也没有完全放弃，它经常被我拿来当第二套对照环境。当某个问题在主流程里检索不到，我会拿同一个资料文件夹到 AnythingLLM 里重建一份索引，看看是资料本身的问题，还是主流程的配置问题。一个人没有测试团队，多一条对照路径就是多一种判断依据。

真正研发时不要急着在流程里接最强的商业大模型。先用一个便宜甚至免费的小模型把链路跑通，确认检索没有问题，再切换成效果好一点的模型。这样分开评估，才不会被模型风格的差异迷惑。很多人做的知识库问答效果差，其实问题出在检索而不是大模型，只是界面输出的答案把注意力都引向了聊天内容本身。

2.4 工具方案对比：别被“全家桶”绑架

我整理了一张对比表，方便你根据自己情况选择：

对一个人来说，工具没有绝对最优，只有当前阶段最合适。我选择 Dify 为主流程，是因为它能承接从内容索引到对话调试的全过程，而且可以在提示词编排上直接控制生成端行为。后面章节里提到的优化动作，都建立在“我能清楚看到每一次检索命中了哪些片段”这个前提上。如果做不到这一点，优化基本只能靠猜。

3. 把 395 张卡片变成能检索的内容资产

3.1 入库前的清洗，比想象中要花时间

按下“创建知识库”按钮之前，我用 Python 脚本把 Obsidian 文件夹扫了一遍，做了三类清洗。

第一类是去重。395 张卡里，有一批内容高度重复，比如同一件事在不同时间写了两遍，只是措辞不同。我按文件名和标题做了相似度比对，把明确的重复项合并删除，最终留下的都是信息增量明显的卡片。第二类是统一格式。有的卡片日期写“2023.08.15”，有的写“2023-08-15”，有的干脆没有日期；这些字段不统一，后期按时间筛选时会很痛苦。第三类是补摘要。我给每张卡在正文开头强制加了一行 summary，一句话说明这张卡到底想表达什么。

这里有一个很容易被忽略的坑：不要指望模型能帮你在入库时自动理解内容。虽然嵌入模型确实可以把整段文字编码成向量，但如果你没有给资料建立基本规范，脏数据造成的检索偏差会贯穿整个知识库生命周期。尤其是日期、标签、来源这三类信息，后期过滤和排序时特别有用，能补就尽早补。

3.2 分块策略：不是切得越短越好，也不是越长越好

知识库的检索精度，很大程度上由分块决定。我一开始图省事，把每张卡整体作为一条分段，不拆分，结果测试“某某项目里遇到过哪些推进阻力”这类问题时，经常检索不到最有价值的那一句，因为长向量中的信息被平均化了，相关句子被不相关内容稀释。

后来我改了方案，按照知识卡内部的小标题、段落边界和列表结构来切。比如一张卡如果讲“大语言模型应用的评估指标”，里面有检索指标和生成指标两个小节，就切成至少两条分段。再给每条分段加上完整的卡标题作为上下文前缀，比如把“评估指标 - 生成指标：忠实度”放在片段开头，而不是只保留孤零零的一段话。

同时我没有把分块长度设成固定的 500 字或 300 字，而是设了一个范围规则：优先按语义边界切，如果单块超过 600 字，再按句子边界切一次；如果内容太短，比如只有一句话，就合并到相邻上下文里。原因是检索时，查询词要能跟片段中的关键词有足够的语义重叠，过短的片段会因为缺少上下文导致语义不全，过长的片段又容易引入噪声，这个分寸只能在实测中找平衡。

3.3 元数据是你以后能不能精细化检索的分水岭

如果只把文本变成向量存进去，那你得到的其实是一个“盲索引”。它能告诉你哪几段话和问题在语义上接近，却很难告诉你这段话来自哪张卡、属于哪个标签、是什么时间创建的。

我给每条分段都保留了完整元数据链。分别有：知识卡编号、标题、一级分类、标签列表、创建时间、更新时间、来源文件路径、摘要 summary。这样做的价值在后续使用中会逐渐体现。比如我想让知识库只回答“项目复盘”相关内容，就可以在检索条件里加一条标签过滤；我想优先返回更新时间近的内容，也可以基于元数据对结果做加权。如果一开始没有保留这些字段，后面所有精细化操作都无从谈起。

我做入库脚本时，是让每个分段继承它所在知识卡的全部元数据。换句话说，一个知识卡被拆成三段，这三段都还带着原始文件名和原始标签，不会因为切分而丢失来源。这个设计每一条 RAG 流水线都应该具备，因为知识库最大的信任危机就是“内容引用了来源，但来源文件根本找不到”。

3.4 向量模型选择与首次冒烟检查

中文内容为主的个人知识库，嵌入模型的选择不能随便。刚开始我试过用偏英文的通用向量模型，结果用中文问同样一个问题，检索排序明显偏后，相关片段的排名经常掉到前五名以外。后来换成了对中文支持更好的开源嵌入模型，才稳定下来。

关于向量模型，我建议不要只盯着模型名称，要做一个小实验。准备二十个你最可能在知识库里问的问题，分别用两种模型建索引，再看召回效果。个人库的数据量不大，重建一次索引只需要几分钟，换模型的成本很低，但选错模型之后影响是持续的。需要说明的是，向量维度倒不是越大越好。768 维或 1024 维的开源模型足够应付几千条片段的个人库，更大的维度只会增加存储和检索耗时。

首次入库完成后，我还做了一次冒烟检查。我找了三个带有标准答案的问题，逐个问知识库，并打开调试面板看检索结果。其中有一个问题是：我在项目推进中最常犯的一个错误是什么？系统成功检索到了对应知识卡里的那个段落，并在回答末尾附上了来源标题。看到它能从 395 张卡里准确捞出一条结果时，我知道链路已经通了。不过这离真正可用还很远，因为少量测试通过只能说明流程跑通，不能说明质量稳定，这就轮到第 4 章的“17 把秤”上场了。

4. 17 把秤到底称什么

4.1 搜得准不准：6 个检索质量指标

知识库的第一步是检索，如果搜不到，后面生成什么都白搭。我给检索质量设计了六项指标：命中率、召回率、MRR、NDCG、检索失败率、查询耗时。

命中率考察的是：对于预先准备好的测试问题，正确答案对应的片段有没有出现在检索结果前五条里。如果没出现，说明检索链路根本就没把相关材料找回来。召回率则在更宽松的范围内进行判断，看相关知识被找回的比例。MRR 衡量的是正确答案排在第几位，它比命中率要求更严格，因为名次越靠前，后面的大模型越容易用到它。NDCG 是一个更综合的排序质量指标，不仅看有没有命中，还看排序是否合理，同时在多相关片段场景下比 MRR 更能反映真实效果。检索失败率指的是请求报错、超时等异常情况，这条指标管的是系统稳定性。查询耗时则直接影响使用体验，知识库如果每次都要等两三秒才出结果，你就会慢慢不想用。

这六项指标，我在初始状态下跑出来的数据并不好看。命中率只有 0.63，意味着十个测试问题里，有接近四个问题没能在前五条结果中捞到正确卡片。MRR 是 0.42，意味着正确答案平均排在三四名开外。这个结果给了我一个非常明确的方向：先把检索做好再谈回答润色。

4.2 答得好不好：6 个生成质量指标

检索做完了，接下来是大模型生成答案的质量。如果把检索比作挑食材，那生成质量就是厨师炒菜的水平。菜能不能吃、有没有炒糊、食客能不能下嘴，都需要指标来约束。

我用了六项：忠实度、答案相关度、引用覆盖率、引用准确率、幻觉率、回答完整性。忠实度指答案中的核心断言是否都能从检索片段中找到依据；答案相关度指回答有没有围绕问题展开，而不是答非所问；引用覆盖率和引用准确率分别考察：回答该引用来源时有没有引用，以及引用的来源是不是真能支撑结论。幻觉率专门统计那些内容里完全没有依据却被模型强行生成的断言，这是知识库最需要严防的指标。回答完整性则关心多步骤复杂问题有没有漏答。

初始测试里，幻觉率偏高，达到 0.14。也就是说一百个模型生成的断言里，大概有十四个是知识库里找不到支撑的。对于一个想把知识库当成长期资料助手的人来说，这个比例太高。读到这个数字的瞬间，我意识到不能只优化检索，还要在生成规则上限制模型，别让它自由发挥。

4.3 以后还能不能维护：5 个工程可持续指标

一个人建的知识库不是一次性项目，它会持续使用半年、一年。如果新资料进不来、旧资料改不动，那这套系统价值会迅速衰减。所以我还留了五把秤用来关注工程健康度：索引新增耗时、增量更新成功率、全量重建次数、平均检索延迟、版本升级回归成本。

增量更新成功率是个特别实在的指标。很多知识库在刚建好时是正常的，但过了一个月你想加入新的知识卡，上传以后系统却没有把它纳入检索，这种情况谁遇到谁知道。所以我会在每个新增批次后跑一条测试，检查新卡里的内容能不能被搜到。全量重建次数也能说明问题：如果系统总是需要把整个知识库推倒重来才能让新内容生效，那说明增量链路有问题，不能一直靠全量重建兜底。版本升级回归成本更偏向管理维度，工具软件每次升级后，我都会用固定测试集重新跑一遍，确保核心指标没有因为升级而崩掉。

4.4 一个人怎么积累测试集

谈到跑指标，很多人会问：我的知识库内容很个人，去哪里找一堆标准问题做测试？我的答案是：从自己真实的使用习惯中来。

我给自己定了一条规则：平时任何一次在知识库里问出有价值的问题，而答案确实帮我解决了问题时，我就把这个问题记录下来。同时记录我期望答案使用的卡片来源；如果参考答案是几天后自己手动翻资料找出来的，我也会把问题补进去，因为它说明检索当时没命中，正是知识库需要改进的缺口。

经过一段时间，我积累了一套八十多道题的测试集。每道题都带着正确答案应引用的知识卡编号或资料标题。这个规模对个人项目完全够用。跑一次评估不需要太久，也不会被当成负担。关键是测试集要稳定保留，不要今天改一题明天改一题，否则指标前后的对比就没有意义了。只有当资料本身确有过时内容时，我才会更新测试集，并且给变化留下版本记录。

5. 看完秤的数据，我做了四次关键迭代

5.1 第一次迭代：分块策略从“整卡入库”改成“语义分段”

第一轮指标中最难看的是命中率。我把所有测试问题里没命中的几道拉出来看，发现一个共性：问题本身提出的概念，在卡片散落的位置没有形成足够独立的向量。尤其是那些既有背景介绍又有结论的卡片，被整卡向量化后，核心结论的语义被背景稀释了。

我改成按语义边界切分，每张卡被拆成多个片段，同时给每个片段保留上下文标题。改动完成后重新建索引，再跑同样测试集，命中率从 0.63 提升到了 0.81。这个变化让我确信，对个人笔记来说，分块的粒度调整远比换大模型参数来得重要。分块本身不是越精细越好，而是要让每一块在语义上足够专注，让人一看就知道这段在说什么。

5.2 第二次迭代：换掉对中文支持不佳的向量模型

命中率提升之后，MRR 依然不理想，原因是正确答案在结果里出现了，但排名不够靠前。我怀疑问题出在向量模型对中文语义的表示能力上。

我选了两个候选模型，用同一套测试集分别建了两份临时索引。实测结果很说明问题：候选模型在 MRR 上比原模型高了将近 0.1。我把主流程的嵌入模型切到候选模型后，MRR 从 0.61 提升到 0.68。表面上看只是零点几的变化，但反映到真实提问里，意味着正确答案从“排第三四条”变成了“稳定排第一二条”，生成侧拿到好材料的概率明显提高。这一步对个人项目来说几乎没有成本，因为数据量小，重建全库索引只需要几分钟，真正难的是你想不想得到要做这种对比实验。

5.3 第三次迭代：加入混合检索和重排

向量检索擅长找语义相近的内容，但有一个明显短板：如果问题里的关键信息和知识卡里的用词完全不同，语义相近这个判断可能会失效。典型场景是我问“怎么解决查询卡顿”，而资料里通篇写的是“首 token 延迟偏高”，两者意思接近但表达差异很大。

我给检索链路增加了两个环节。第一是混合检索，把关键词 BM25 检索和向量检索的结果合并起来。第二是重排，把合并后的候选片段交给一个重排模型，按照“与问题真实相关程度”重新打分排序。加上这两层之后，命中率提升到 0.93，MRR 提升到 0.76。代价是平均检索耗时增加了一些，从原来不到两百毫秒增加到五百毫秒级，但考虑到这是一个个人知识库，这个时间完全可接受。

这里要说一句：如果只是在一个小规模测试集上随便问问题，很难体会到混合检索和重排的价值，但当知识库内容超过几百段、而且问题类型五花八门时，单纯靠向量检索会漏掉太多基于关键词匹配的真实相关片段。重排不是锦上添花，而是保证排名质量的关键。

5.4 第四次迭代：让生成端学会“照章办事”

检索指标上去后，再回头生成质量指标。忠实度只有 0.72，幻觉率高达 0.14，这说明模型在生成答案时经常把自己脑子里的话和知识库片段混在一起。

我重新写了系统的提示词规则，核心要求有三条：第一，所有结论必须来自检索上下文，如果没有找到对应内容，直接回答“知识库中没有相关信息”，不要编造；第二，回答时逐条标注引用来源，让用户可以返回原始知识卡核对；第三，禁止在答案里补充检索上下文之外的经验推断或总结。

这一条改动对回答风格的影响极大。重新跑指标后，忠实度提升到 0.90 左右，幻觉率降到 0.04 以下，引用准确率也明显变好。可见很多知识库系统给人感觉不够可靠，并不完全是大模型能力不够，更大的原因是提示词把模型“放养”了。你越告诉它自由发挥，它越容易自由发挥出错误内容。

6. 单人维护中踩过的典型坑

6.1 升级之后保存知识库报 internal server error

这是我在使用某个开源知识库工作台时遇到过的最典型问题。现象是：某次升级版本后，打开已有知识库发现功能异常，点击保存配置或修改分段内容时，直接返回 internal server error，重启服务也没用。

排查思路是从日志开始的。拉起容器服务日志后，看到其中有一条错误指向前端提交的数据里包含一个后端不认识的字段。再往下看，发现是索引列表的元数据字段在新旧版本中结构不一致，升级脚本没有自动完成数据库迁移。

处理方式分几步：先备份数据和数据库文件；然后把服务切换到旧版本镜像，确认数据安全；接着根据日志错误定位到是知识库分段的某个扩展字段没有同步，手动把旧数据导出，修正字段结构后重新导入。如果你也遇到类似问题，我建议不要一上来就删除知识库重建，而是先检查容器日志，确认是数据层问题还是配置问题。很多升级后的内部错误都不是数据丢失，而是字段校验不匹配。

6.2 检索能捞到内容，答案却仍然在乱说

有时候你知道知识库确实找到了正确片段，因为调试界面里能看到命中的内容就在返回值里，但大模型最终给出的答案依然不对。这种问题通常会指向生成端的两个隐患。

一个原因是检索结果排序不够好，正确的片段虽然出现了，但被排在后面，模型在裁剪上下文时可能把低排序的片段截断了。另一个原因是你没有在提示词里强行规定“优先采用靠前片段且必须引用片段原文依据”。我后来在处理这个问题时，会先在检索调试页面看前几条内容顺序，再做一次重排，确认正确片段进入模型上下文的最前面几条。与此同时，也在提示词里加了更严格的要求，模型回答时如果写“根据库中内容”，就必须让这个结论能在某个引用片段里找到对应句子。

6.3 换了一种问法，就检索不到对应卡片

知识库检索最折磨人的问题之一，是关键词一换，原来能搜到的内容就找不到了。这种情况在单纯依赖向量检索时尤其常见。比如你卡片里写的是“容灾备份策略”，用户提问时用了“数据丢了怎么办”，两者的语义虽然相关，但向量模型不一定能精准映射。

我的解决办法就是前面提到的混合检索方案，让 BM25 关键词检索引擎兜底。如果用户在提问时用了某个罕见的专有名词或缩写，关键词检索能直接锁定包含该词的片段。同时，我会在测试集里专门准备一些改变说法的问题，专门测试系统在近义表达、口语表达和书面表达下的表现。对于向量模型覆盖不了的变体，持续调整测试集并观察失败样例，这比临时在知识库里加一堆同义词列表更有效。

6.4 新增了卡片，却感觉回答完全没变化

这是很多知识库都会出现的坑：你高高兴兴往 Obsidian 里新增了几十张资料卡，也执行了知识库同步，结果去问一个明显应该由新卡回答的问题，系统还是用旧内容应付你。

排查时要分清两个可能。一是增量更新流程没有真正生效，知识库可能只更新了文件列表，但没有重新切分或重新向量化新内容，所以检索索引里压根没有新片段。二是缓存问题，对话应用层用了旧的知识库 id 或旧的索引快照，导致你查的其实还是老数据。我的习惯是每次新增资料后，用一条只可能在新资料里出现的问题做冒烟测试，如果搜不到，就打开操作日志，检查新增分段是否真的进了向量库。单靠看界面上的“分段数量”有时不准确，要直接看分段列表里有没有新资料标题。

这里再分享一个细节：每次修改知识库的分块设置、向量模型或提示词后，我都不会只在测试集上跑一遍就结束，还会挑 5 个没有标准答案的随机问题做观察，把问答过程完整看一遍。这样做是为了防止“测试集过拟合”现象——系统可能在特定测试题上表现很好，但在真实未知问题上仍然脆弱。把固定指标和开放抽查结合起来，才是更稳的做法。

7. 一个人长期维护知识库，最重要的是什么

知识库搭完到现在，我已经养成了固定的维护节奏。每周新产生的内容，我会在周末花一点时间整理成卡片，放进 Obsidian；如果量超过十几张，就会顺手跑一次入库流程，然后用测试集里那八十多道题重新测一遍。所谓维护，其实不是不停升级工具或换模型，而是盯住数据变化和指标波动。

有一次我在新增一批卡片后，发现命中率反而下降了。我没有急着改底层的检索参数，而是先把新增卡的内容重新看了一遍，发现其中有几张卡没写清来源，重复覆盖了旧知识卡的主题，导致排序时同一主题片段互相抢占位置。我把重复卡合并后，再跑测试集，命中率就恢复正常了。这种问题靠换模型是解决不了的，只能通过定期观察指标和检查数据质量来处理。

如果你也想一个人尝试建这套系统，我的建议是先别追求大而全。拿一两百张最常被自己翻找的资料卡起步，把上面的所有流程走通，哪怕一开始指标很难看也没关系。真正有价值的，不是那个“看起来能答问题”的演示页面，而是你搞清楚了每一条数据从原始笔记到最终问答结果之间到底经历了什么。这个过程走通了，以后你的资料再多，也只是重复同一个流程，不会再觉得知识库建设是件多神秘的事。