复盘七个失败AI项目：真正瓶颈不在模型，而在知识库建设

复盘了几个失败的 AI 项目发现问题不在模型在知识库。这句话不是标题党是我最近一个月真实干完的一件事。前前后后看了七个项目有三个是我自己参与过的四个是朋友拉我帮忙救火的行业跨度也挺大有做内部文档问答的有搞农业知识库的还有两个硬件相关FPGA 辅助设计、电机控制实验手册问答甚至还有一个照片修复类的。一开始每个人都觉得是模型不给力张嘴就是“换个更强的模型试试”“是不是该上更大的参数”结果我逐层排查下来真正卡脖子的地方几乎全在知识库。这篇复盘我把每个项目的失败细节、知识库链路里的坑以及最终验证过的重建方法都写出来希望能帮正在做 RAG 类产品、AI Agent 或者内部知识助手的同学少走一点弯路。1. 先说结论模型在大部分场景里根本没到瓶颈1.1 现代大模型的能力其实已经“溢出”了这三个多月我和团队密集测试了几十种模型从开源的中小尺寸模型到各家商用 API 都跑过。一个很真实的体感是对于绝大多数企业内部知识问答、资料检索、流程引导类场景模型本身的文本理解能力早就够用了。我自己测试过一批基于 bge 系列 embedding 和不同尺寸 LLM 的组合文本分类、要点抽取、改写润色这类任务7B 模型和 70B 模型的差距远没有想象中那么大很多时候差的只是措辞的精细度而不是对错。Transformer 架构这么多年迭代下来通用能力已经被喂得很饱了。问题恰恰出在一个反常识的地方模型越强对输入知识的质量越敏感。你给它的上下文是干净、准确的它就能给出漂亮的答案你给它的上下文是切片混乱、命中错误、字段残缺的它也能一本正经地把错误信息组织成流畅的答案。这也是为什么那些项目里模型一换再换用户该不满意还是不满意——因为烂的是输入不是生成器。1.2 失败项目的“模型无罪”判定标准复盘那七个项目时我用了两个很朴素的判断标准来确认模型到底有没有问题第一直接给模型一段精心整理、没有经过检索链路的文本让它回答指定问题。如果答案质量明显提升那说明生成模型本身没问题是喂给它的材料有问题。第二把用户原始问题直接交给模型让它给出“理想答案应该包含哪些要点”然后人工去知识库里找这些要点是否真实存在。如果在知识库里根本找不到对应信息那再换十个模型也是白搭。七个项目做完这两个检测有五个直接判了模型“无罪”剩下两个虽然是模型本身能力不足但仔细看完发现真正的根因还是知识库没有给模型提供足够细颗粒度的专业素材导致模型只能凭推理硬凑。1.3 追新模型是最昂贵的逃避很多人都以为项目失败是模型太笨于是四处托关系搞内测名额、花大价钱调 API。我在那些项目里确实看到有人连换三个模型费用翻了好几倍回答质量却没有任何实质变化。说白了追新模型是逃避知识库问题最体面的方式——因为你可以把责任推给“技术还不成熟”不用面对自己知识库一塌糊涂的尴尬。这里不绕弯子直接说结论如果知识库做得到位一个中等偏上的模型就能撑起 80% 的常见场景知识库做不好上再豪华的模型也只是在错误的地基上盖精装修。那些项目里唯一一个“模型确实背锅”的案例是照片修复类但那其实不是文本大模型的范畴而是算法选型方向错了跟 RAG 类项目完全是两码事。2. 失败项目里的知识库“千奇百怪的烂法”2.1 数据源阶段垃圾进垃圾出先看几个具体的失败画面。第一个做农业知识库的项目数据源是从各类公开网页抓下来的里面一半是重复的新闻稿四分之一是互相矛盾的种植建议剩下还有一些纯广告词。团队把抓下来的 HTML 直接转成文本连广告推荐语里的“本产品效果奇佳”都一起塞进了知识库。模型很冤枉它只是忠实地把广告词组织进了回答。还有一个做内部文档问答的项目公司文档从老旧的 wiki 导出格式混乱到爆炸。同一个名词有三种叫法“库存周转率”在一份表格里叫“周转天数”在另一份 PPT 里叫“库存周转天数”。文档里嵌着大量表格导出后表格的行列关系全丢了数字从“A 产品 2023 年 5000 件”变成了一行没有任何上下文的“5000”。这种数据源你不管用什么切片策略、什么 embedding 模型都不可能 retrieval 出正确的语义。数据源清洗不是可有可无的步骤它是知识库项目里最脏最累但价值最高的环节。橡皮擦干净了铅笔怎么画都清楚纸是花的画什么都白搭。那七个失败项目里有四个的数据源基本没做过专门清洗直接把原始文件倒进了切片器。这个比例非常惊人。2.2 切片策略拍脑袋定的 chunk 参数切片chunking是知识库链路里最容易被低估的一环。很多团队用的策略就是“固定 512 个字符切一刀”overlap 设 50跑完就上线。这种拍脑袋的参数在实际项目里基本都会出事。我复盘过一个用豆包工具链搭知识库的项目当时大家为了省事把 chunk size 设置得特别小好像是 256overlap 设了 64。结果就是很多概念被拦腰截断语义七零八落。用户问“模型微调的步骤是什么”系统检索出来的是 256 字的小碎片里面只有“步骤一”没有后面的内容模型只能根据残缺的上下文瞎编。后来我把切片策略改成了“标题感知 段落优先”保持 512 到 768 的切片长度overlap 控制在 80 到 120相同问题的准确率肉眼可见地涨了一截。切片这件事没有银弹它跟文档格式、语言风格、问题类型强相关。但有一条底线永远不要只依赖固定字符数切片一定要结合文档结构标题层级、段落边界、列表项来做智能切分。那些失败的 projects 里的共同问题就是完全无视结构把 PDF 里一个连续的大表格、一段带缩进的代码示例、一个完整的业务流程图描述硬生生切成几段。2.3 Embedding 选型中英文混合的场景被坑最惨Embedding 模型的选择是另一个大坑。很多项目直接用了面向英文优化的默认向量模型然后在中文业务场景里要求效果这基本上等同于让一个只懂英文的人去读中文合同能看懂标题已经算不错了。农业知识库项目就是典型。里面大量内容都是“玉米 病虫害 防治 药剂 用量”这种中英文夹杂的术语直接用默认 embedding 算相似度检索“小麦赤霉病用什么药”的时候召回来的全是“小麦 品种 选择”这类不相关的文档。后来我把 embedding 模型换成了针对中文优化的模型并且在下游检索阶段加了一路关键词召回作为兜底准确率提升非常明显。实际做项目时我不会只依赖一个 embedding 模型。更稳的方案是两路召回一路向量检索语义召回一路 BM25 或关键词匹配词汇召回最后做融合排序。那七个失败项目里五个都只有纯向量检索一旦用户的问法和知识库原文写法差异大一点召回质量立刻崩。这一条值得反复说因为它能救回大量“看起来没救了”的项目。2.4 检索链路top_k 和 threshold 的玄学检索链路里还有一个大量被忽视的细节就是 top_k 和相似度阈值threshold的配合。有的项目 top_k 设成 3用户问一个综合性的问题需要五个维度的信息拼在一起才能回答结果只召回三块碎片自然答不全。有的项目 threshold 设得太高稍微口语化一点的问法就直接过滤光了模型只能凭“幻觉”硬撑。我记得很清楚有个做铁路相关领域问答的项目具体不展开了用户问“你们支持哪些运输方式”知识库里明明有完整说明但因为用户说法跟原文差异较大向量检索出来的相似度只有 0.72又恰好在阈值的及格线以下结果系统直接放弃了召回。后来我把 top_k 调到 8threshold 降到 0.6 左右再配合重排序问题的回答质量一下子从“完全没用”变成了“基本能用”。我发现很多团队在做知识库时完全没有“召回也要有召回率”的概念光顾着看生成时的流畅度根本不去管生成前那一步有没有把该找的东西找回来。这属于认知层面的盲区比参数调不对更可怕。3. 重建知识库的正确姿势我验证过的不踩坑路径3.1 第一步先做数据资产盘点再谈技术那些失败项目的通病是上手太快。一听说要做 AI 助手立刻开始装工具、配模型、切文档结果数据质量一团糟最后全盘返工。正确的做法是先花一到两周做数据资产盘点知识库里的文档有哪些类型PDF、Word、Excel、PPT 分别占多少更新频率是多少有没有明确的责任人和更新机制我复盘过一个用老式 wiki 导出文档做知识库的项目盘点时发现 60% 的文本是过去三年的积压文档早就不符合当前业务流程了。把这些老文档清理掉或者降级归档之后回答准确率直接提升了 20 多个百分点。这个动作不需要任何技术含量但它产生的收益远超任何模型调优。数据盘点阶段可以拉一个简单的清单文档主体内容是否准确、是否有版本冲突是否包含与业务无关的广告、个人信息、空行乱码表格数据是否保留了行列语义还是已经被扁平化成无意义文本串是否有明确的分类目录还是所有文件堆在一个网盘里3.2 第二步用 Dify 搭一条可观测的知识库流水线工具选型方面我给中途接手救火的几个项目统一重新搭建或迁移到了 Dify 的知识库流水线。选用它的原因很直接它把文档解析、清洗、切片、向量化、检索、重排序这几个环节都做成了可视化节点每一步都能单独检查和调试这对排障来说太太太重要了。在 Dify 里我一般这么配置文档导入统一走“结构化解析”节点PDF 优先用版面解析而不是直接文本抽取清洗节点里做术语统一、空格压缩、乱码剔除切片节点采用“自定义分段”模式先按 Markdown 标题层级切一遍再把超长段落按 700 字符二次切分overlap 取 100向量化节点选择中文优化的 embedding 模型并为每个知识库单独配置索引检索节点开启混合检索同时保留关键词召回并对结果做 RRF 融合这套配置在几个项目里都验证过属于“抄作业”级别的可靠方案。配置完后最好把每个环节的中间结果保存下来比如切片后到底生成了多少条记录、每条记录对应原文的哪个区域这些信息在后续排查召回问题时非常关键。3.3 第三步奥卡姆剃刀式切片法切片策略我总结了一个“奥卡姆剃刀式”的做法规矩能用整段解决的不用碎块能用结构分割的不靠字数硬切。具体操作上我会先按 Markdown 标题把长文拆成若干次级文档块每个二级标题下是一个独立块。如果一个块仍然超过 900 字符再按段落边界做二次分割。overlap 不是越多越好中文语境里 80 到 120 个字符的 overlap 就足够了它的作用是让前后两块在有交叉引用的场景下不至于丢信息。我专门测过同一批农业资料在相同 embedding 前提下无结构固定切分法的检索命中率约 63%标题感知切分法的命中率提升到 87%而再加上段落边界约束后可以到 92% 左右。这个提升完全不需要换模型只是改变了喂给模型的“文件目录结构”。很多人总觉得切片越细越精确其实这是误解。切片过细会导致上下文信息密度太低模型要花大量注意力去猜测碎片之间的关系切片合理、边界清晰模型反而更容易理解。这就好比一本字典如果按“每页只能放 100 个字不能按字母分区”查询效率会直线下降。3.4 第四步Embedding 模型的本地化与降本Embedding 选型方面我的经验是尽量选择能本地部署的中文优化模型而不是每次查询都走外部 API。原因有二一是闭环可控数据不出内网安全合规压力小二是成本低知识库查询量上来之后自托管 embedding 的边际成本几乎可以忽略。我在几个项目里用的是 bge 系列里的中尺寸版本配合 Dify 流水线做向量化效果稳定。这里要注意embedding 模型一旦确定就不要频繁更换。换一个 embedding 模型意味着全库向量要重新生成而且新旧向量混在同一个索引里检索质量会崩。实际项目里常见的一种情况是团队初始用了某个社区模型后来发现排行榜上有一个新的更准于是全量重跑结果语义空间彻底错位。类似这类教训踩过的人应该不少。Embedding 模型排行只能作为参考不能作为选型的唯一依据。最靠谱的办法是收集你自己的五六十个高频问题人工写好标准答案然后用不同 embedding 模型跑一遍召回测试看谁在你的数据上表现最好。排行榜第一名到你行业数据上不一定是第一名。3.5 第五步检索参数从宽松到收紧检参调优的原则我建议从宽松开始再根据实际错误逐步收紧。第一轮把 top_k 设到 8threshold 设到 0.5 左右先保证召回率足够高不怕召回过量但要保证“该有的都有”。然后检查模型给出的答案里有多少内容来源是知识库里不存在的。如果幻觉明显再逐步提高 threshold或者引入重排序模型把低质量的召回排到后面去。我在救火的几个项目里常见的一个错误就是反着来一开始就把 threshold 设到 0.82追求“每次召回的都得是高度相关的”结果逼得模型在信息不足时硬答。知识库问答系统的逻辑应该是“宁可召回一堆候选让重排去裁决也不要连候选都不给模型”。召回阶段可以放宽重排阶段再精排这比把压力全部放在初次检索上要稳健得多。4. 那些失败项目教会我的评测与回流机制4.1 没有评测集就没有优化方向七个项目里六个人都没有建立标准评测集。问他们“你觉得现在的回答质量如何”回答都是“感觉还行吧”或者“有时还行有时不行”。这种状态没有资格谈优化因为你连“不行”的样本都收集不起来。重建知识库后我做的第一件事就是拉一个评测集。找业务同学整理出 50 到 100 条真实高频问题每条问题配好标准答案的要点以及答案来源应该在知识库的哪个文档、哪个段落。这个评测集一旦建好之后每一次调参数或换模型都能拿到具体的准确率数字而不是“我觉得好点了”。评测集也不用一次建得特别完美先 50 条跑起来边跑边补。重点是要覆盖不同提问风格包括口语化问法、术语问法、模糊问法、多条件组合问法。农业知识库项目里我补了 30 条口语化提问比如“玉米叶子黄了是咋回事”这类问题在正式文档里很难直接命中但恰恰是用户最常问的。4.2 构建回流闭环让用户帮你发现知识盲区知识库项目上线后很容易进入“吃老本”状态用户问的问题越来越偏知识库还是原来的内容准确率自然继续掉。解决思路是把用户反馈纳入一个闭环当用户在对话后点击“回答没用”时系统记录下这个问题和模型实际返回的答案定期把这些负反馈问题汇聚成新的评测集再由人工确认是不是知识库缺少对应内容缺了就补文档或补条目。这套回流机制在其中一个内部文档问答项目里效果非常明显。上线第一周用户的负反馈问题里 40% 都是知识库确实没有的内容。后来负责维护文档的同学专门建了一个“问答补充池”技术运营每周处理一次把缺失问题补进知识库。两个月之后同一批评测集的准确率从 74% 提升到了 91%。重要的不是那 17 个百分点的提升而是整个系统开始长脚了能自己发现问题、自己向正确方向迭代。这一点在我复盘的所有项目里都做得不好好几个人都觉得“上线了就等于完事了”。4.3 别忽视人工维护者这个角色很多团队做知识库把它当成一个纯技术交付物上线之后没有指定维护人。这是大忌。知识库是活的数据资产领域术语会变、业务逻辑会变、用户问法会变没有持续的维护再好的知识库半年后也会变成一堆过期资料的坟场。我在给那几个项目做的改进里最重要的一点就是逼着客户指定了一名“知识库管理员”他的职责包括每周看一次回流问题、每月加一次新文档、每季度清理一次过期内容。说实话这个角色的价值有时候比换一个更强的模型高得多。技术可以把一切都搭建得漂漂亮亮的但让内容保持新鲜永远是“人力 流程”的活。5. 常见问题与排查技巧实录5.1 用户问题明明在文档里为什么搜索不到这种情况十有八九是检索链路的召回问题。按我的排查顺序走先直接看知识库里有没有这段内容如果连原始内容都没有那就是知识库覆盖问题跟检索无关。如果原始内容存在那就检查分词和 embedding 是否匹配。确认切片是否把关键信息切散了比如“库存周转率计算公式”被切到两个切片里检索到的片段里只有概念没有公式。然后是阈值和 top_k 的调试。把 threshold 放到 0.5、top_k 提到 10看能不能召回能召回说明是参数太严不能召回再往 embedding 方向查。我在项目里还见过一种数据类型导致的老大难知识库里的表格被 PDF 解析成了单列文本比如“5000件”和“2023”被拆成两行等价于检索时根本找不到完整语义。这种情况只能回到解析环节重新处理表格调模型是没用的。5.2 模型回答得流畅但是答非所问出现这种问题要着重观察模型回答的内容来源。如果模型引用了知识库的内容但牛头不对马嘴多半是检索召回了错误片段也就是 embedding 的语义区分能力不够。此时可以尝试用包含关键词的混合检索作为补充或者换用带重排序的检索链路。如果模型回答的内容完全不在知识库里那就是“幻觉”问题。这往往是知识库覆盖不足、相关文档确实缺失而模型被逼无奈只能硬编。解决办法只有一个补知识库而不是换更大的模型。换大模型只会让圆谎能力更强把幻觉包装得更像真的。还有一个容易被忽略的点某些模型在长上下文中更容易被干扰信息带偏。如果 top_k 召回过多比如一次返回了 10 个片段里面有两三个无关信息模型会被带跑。我的做法是把重排序加回来压缩到 top 3 到 top 5 个最高质量的片段再喂给模型。这一步在很多 Dify 流水线里有现成的 rerank 节点开起来就行。5.3 知识库更新后效果反而变差了这种情况不罕见常见原因有两种一是更新后没有重新向量化新增内容导致新旧内容语义空间不一致二是某次大范围替换文档后切片边界大幅变化导致原有问题的召回位置整体偏移。排查方法是先查更新后的文档在原知识库索引里是否可见。Dify 这类工具支持单独查看索引状态确认后可以做一次全量重向量化。更高频的场景是用户在知识库里“追加了很多文件”但没有给这些文件设置合适的分类或标签导致混合检索时权重被新文件带偏。我一般会建议给知识库建立二级分类目录并按目录设置不同的检索权重比把所有文件一股脑倒进一个索引要可控得多。5.4 常见问题速查表现象优先排查方向常用解法常见问题答不出知识库覆盖是否完整补文档、建回流机制回答内容与问题无关检索召回错误调低 threshold、加混合检索回答流畅但编造事实模型幻觉 / 知识库缺失补知识库、压缩召回数量更新后效果下降索引未刷新 / 切片边界变化全量重向量化、检查文档结构中英文混合效果差Embedding 选型不匹配换中文优化模型、本地化部署表格数据答不准解析阶段丢了行列语义用结构化解析重新处理表格top_k 命中过多干扰召回太杂增加重排序、限制最终片段数这七条基本覆盖了我在失败项目复盘里遇到的大多数问题不少项目按这个表逐项检查一轮就能找到症结。6. 我最后想说的几个经验教训6.1 知识库要当产品做不当管道做经历过这几轮失败项目后我最大的感受是知识库不是一个一次性的技术管道而是一个需要持续运营的产品。好的知识库应该有自己的数据字典、清洗规则、切片规范、评测体系、回流闭环。它不是一个交付完就完事的工程模块而是整个 AI 应用的“数据底座”。以前大家总喜欢说“模型为本提示词为王”这话对了一半。对的那半是模型很重要错的那半是很多人忽略了模型吃的每一口饭都来自知识库。知识库这块地基如果打不稳上面任何花里胡哨的能力都是空中楼阁。6.2 先小成本验证再规模化铺开在复盘过程中我发现好几个项目一开始就把摊子铺得特别大十几个知识库同时上几十万文档一股脑导入结果一个问题都查不准。更明智的做法是选一个价值最高的场景先把知识库做深做透做出标杆效果再横向复制。我在指导其中一个项目时让他们先只做“新产品 FAQ”这一个知识库测试集 60 条问题调通切片、embedding、检索、重排的完整链路效果稳定后再复制到其他业务场景。这样不仅成功率高而且积累下来的这套评测方法和参数规范可以直接套用比一上来就全面开花要稳得多。6.3 一些可以拿来就用的参数建议最后分享几个我实测过比较稳的默认参数不是最优答案但至少是个及格线切片长度建议 512 到 768中文场景overlap 80 到 120embedding 优先中文优化模型top_k 初始 6 到 8threshold 初始 0.5 到 0.6开启混合检索向量 关键词开启重排序评测集 50 条起步每个知识库指定一名维护人。如果项目刚起步又不知道从哪里下手照着这套参数配再根据评测结果逐步调整大概率能少走很多弯路。知识库这件事说起来不复杂做起来全是细节。那些失败的 AI 项目真正败给模型的没几个大部分都是败给了对知识库的轻视。希望这篇复盘能给正在做类似项目的你提个醒也别等踩完坑再来后悔。