先对号入座：「一个月出 Demo，三个月还停在 70 分」
先描述一种我们见过许多遍的节奏：项目头一个月，把文档传进去、接上大模型，演示效果相当惊艳——问什么都能答上七八成。老板拍板继续，随后怪事来了：接下来几个月，提示词改了一版又一版，检索参数调了一轮又一轮，效果却原地踏步。技术团队最后给出一个听上去很合理的解释：模型的上限就是这样。
复盘时我们几乎总能看到同一个病根：团队拥有功能迭代，却没有知识迭代。答错了，就去换模型、换框架、换参数，唯独没有人把「错在哪、为什么错、以后怎么不再错」沉淀成数据。错误发生过就消失了，下一次换个问法，同样的错再犯一遍。
70 分与 90 分之间隔的不是更聪明的模型，而是一套把失败样本变成改进资产的习惯。
同一个名字，三种完全不同的投入
市面上都叫「AI 知识库」的东西，在不同预算下交付的根本不是同一种产品。按我们看到的行情，大致分三档：
- 工具钱——文件上传、基础检索问答加一个聊天界面，本质是带对话框的文档搜索。适合「答案在哪份资料里」这类问题，一两个月就能见效。
- 系统钱——文档解析、混合检索、引用溯源、测试集和少量业务系统对接，回答开始可验证、可追责。客服、制度查询这类日常场景，到这一档基本够用。
- 工程钱——历史数据清洗、统一业务口径、权限审计、评测平台与长期知识治理。这已经不是买软件，而是给企业的知识修路。
矛盾大多出在预期与档位的错配：拿工具钱期待工程钱的效果，或者反过来，问题明明只需要工具钱，却被劝着上了重型方案。报价贵的未必更好——先想清楚自己要解决的是哪一类问题，再看交付清单，而不是看演示。
把错误变成资产：知识迭代闭环
真正拉开差距的，是项目能不能长出一条知识迭代的闭环。在我们自己的项目里，这条闭环长这样：
- 业务人员发现答案不对，随手记下失败样本；
- 给错误归因：是文档解析错了、没检索到、口径不一致，还是引用错了位置；
- 按归因改对应的那一层——改数据、改检索、改规则，或者干脆改流程；
- 上线前跑一遍固定测试题，确保修好一个问题的同时没有弄坏十个。
这套动作没有任何高技术含量，难的是坚持：它要求企业指定知识的更新责任人，要求项目组攒出一份不断变厚的测试集。我们判断一个知识库项目有没有前途，就看这两样东西在不在。
我们的做法：先画知识边界，再谈检索效果
所以客户问我们「知识库该怎么建」时，第一步永远不是演示产品，而是陪他们把边界画清楚：这些知识现在散落在哪几种载体里？每一类知识的对错由谁负责？多久更新一次？答错一次的代价有多大？
四个问题都有答案之后，该从哪一档起步、要不要接业务系统、由谁来长期维护，几乎都是水到渠成的选择题。先界定知识边界与更新责任人，再谈检索效果——顺序反了，买什么都救不回来。