夜雨聆风你的知识库总答不准，不是检索不行，而是文档从一开始就不是给机器用的
这半年我看了不少企业知识库项目，表面都在卷同一件事： 换更强的向量库、加 rerank、调 chunk、上混合检索。
但很多项目做了几轮，回答还是飘。 不是答非所问，就是召回一堆沾边但没用的内容。
我现在越来越明确一个判断： 多数知识库和 RAG 项目效果差，锅不在检索层，锅在源文档层。
说白了，很多企业文档从写出来那一刻，就不是给机器用的。 给人看也许还能凑合，给模型用，基本等于喂脏料。
你以为在优化检索，其实是在给坏语料擦屁股
RAG 这条链路里，检索当然重要。 但检索系统再聪明，也只能在你给它的语料池里捞东西。 如果池子本身就是浑的，后面再怎么调，也只是从脏水里挑相对干净的一勺。
最常见的脏，不是什么高深问题，就是这些：
标题全是“补充说明”“最终版”“会议纪要” 同一制度有五个版本，没人知道哪个还生效 表格是截图，PDF 里文字根本抽不出来 一段话脱离上下文，连产品名、时间、适用范围都没写 没有作者、部门、日期、标签这些元数据
这时候你去调召回、调 rerank，当然也有用。 但本质上还是在补救，不是在治本。
真正的问题，不是没做RAG，而是没做“机器可用化”
Anthropic 讲 Contextual Retrieval 时说得很直白：传统 RAG 在切 chunk 的时候，经常把上下文切没了，所以检索会失败。 微软那套 advanced RAG 也强调，清洗、版本跟踪、元数据提取、表格图片处理，本来就属于前置工程，不是后补动作。
这也是为什么我现在看知识库项目，第一眼不看你用哪家 embedding，先看三件事：
文档结构是不是稳定的 元数据是不是完整的 内容是不是按机器可检索方式重写过
很多团队前两层都没做，就直接上索引。 这跟厨房不洗菜，先研究火候，逻辑差不多。
什么叫“给机器重写文档”
不是让你把所有文档重写成论文。 而是把原来只服务人类阅读的内容，改造成也能被机器稳定消费的格式。
我会优先做这几件事：
一个主题只保留一个当前有效版本，历史版本明确归档 标题写清对象、动作、范围，不要再写“补充说明” 给每篇文档补齐日期、部门、产品线、权限等级等元数据 表格尽量结构化，不要把关键信息锁在截图里 长文按语义和业务场景拆段，不是机械按字数切块 给每段补上必要上下文，避免 chunk 单独拿出来就失真
这一步很土，但非常值钱。 因为它直接决定你后面检索出来的，到底是知识，还是噪音。
为什么很多团队最舍不得在这里下功夫
因为这活不性感。 它不像“我们接了某某模型”那么好讲，也不像“召回率提升 8%”那么好汇报。
但真相是，知识库项目最贵的，往往不是模型费。 而是文档治理欠下的历史债。 你前面不还，后面就会在召回、幻觉、人工复核上反复交学费。
所以我的建议很简单： 别再把知识库当成纯算法项目，先把它当成内容工程项目。 先把文档整理成机器能用的样子，再谈检索优化，顺序别反了。
我现在判断一个企业知识库靠不靠谱，已经很少先问“你们用什么 RAG 框架”，而是先问：
你们的源文档，真的适合给机器吃吗？
如果这一步没做，后面大概率都是局部修补。
你们团队现在的知识库问题，更像是检索不行，还是文档从源头就没整理成机器可用？
