个人AI知识库搭建全记录：395张知识卡与17个评估指标

最早提出一个人把 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自己可控的 RAG 流水线工作流清晰、支持知识库和检索调试社区资源多版本升级节奏快升级前必须备份和看变更记录AnythingLLM本地快速搭建安装简单、支持本地模型、桌面端易用深度定制能力有限复杂评估不如工作台方便Obsidian 搭配插件纯笔记用户资料管理友好零迁移成本缺乏完整 RAG 链路多数方案要配合外部服务自己写 Python 服务想完全掌控检索逻辑高度自由适合深度优化维护成本高不适合只想快速入库的人对一个人来说工具没有绝对最优只有当前阶段最合适。我选择 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.93MRR 提升到 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如果量超过十几张就会顺手跑一次入库流程然后用测试集里那八十多道题重新测一遍。所谓维护其实不是不停升级工具或换模型而是盯住数据变化和指标波动。有一次我在新增一批卡片后发现命中率反而下降了。我没有急着改底层的检索参数而是先把新增卡的内容重新看了一遍发现其中有几张卡没写清来源重复覆盖了旧知识卡的主题导致排序时同一主题片段互相抢占位置。我把重复卡合并后再跑测试集命中率就恢复正常了。这种问题靠换模型是解决不了的只能通过定期观察指标和检查数据质量来处理。如果你也想一个人尝试建这套系统我的建议是先别追求大而全。拿一两百张最常被自己翻找的资料卡起步把上面的所有流程走通哪怕一开始指标很难看也没关系。真正有价值的不是那个“看起来能答问题”的演示页面而是你搞清楚了每一条数据从原始笔记到最终问答结果之间到底经历了什么。这个过程走通了以后你的资料再多也只是重复同一个流程不会再觉得知识库建设是件多神秘的事。