为什么大量公司上了 RAG却很少真正做成过去两年几乎每家有点规模的公司都做过一版「企业知识库问答」。Demo 演示效果惊艳立项顺利三个月后上线然后——用户用了两周就不用了。这篇文章回答三个问题Demo 到生产之间到底断在哪里做成的团队和没做成的团队根因差别是什么以及RAG 这套架构本身有哪些绕不过去的缺陷缩写对照表缩写英文全称中文RAGRetrieval-Augmented Generation检索增强生成LLMLarge Language Model大语言模型POCProof of Concept概念验证 / 试点demoROIReturn on Investment投资回报率BM25Best Matching 25一种经典的关键词检索排序算法ACLAccess Control List访问控制列表权限SQLStructured Query Language结构化查询语言OCROptical Character Recognition光学字符识别PIIPersonally Identifiable Information个人身份信息RecallkRecall at k前 k 个检索结果的召回率HyDEHypothetical Document Embeddings假设性文档嵌入一种查询改写技巧SFTSupervised Fine-Tuning监督微调一、先看清楚Demo 为什么那么容易成功要理解失败得先理解那个「成功的 Demo」是怎么来的。典型的 POCProof of Concept概念验证长这样语料精挑细选的20 份干净文档PDF 排版规整没有扫描件没有表格截图问题由读过这些文档的人现场提出评判产品经理看了一眼答案「嗯说得挺对」。这三条每一条都在系统性地制造假象20 份文档时检索几乎不会错。语料小到把所有内容塞进上下文都行检索模块实际上没被考验出题人读过语料所以他问的每个问题都有答案。真实用户会问语料里根本没有的东西「说得挺对」不是指标。没有人去数100 个真实问题里答对几个、答错几个、答错的那几个用户能不能自己发现。生产环境把这三个前提全部反转20 份变 20 万份出题人变成不了解语料边界的一线员工「挺对」变成「我得逐条核对才敢用」。Demo 验证的是「技术链路能跑通」而项目的成败取决于「在脏语料上对真实问题的答对率」——这两件事之间隔着整个工程。二、真正的瓶颈不在生成而在检索这是最普遍、也最贵的一个误解团队把 80% 的精力花在 prompt 和换模型上而真正决定天花板的是前面那一步。失败点 1口语化提问与文档措辞对不上失败点 2正确的片段压根没被召回失败点 3召回了但排在第 30 位被截断失败点 4切块切碎了表格上下文自相矛盾失败点 5模型脑补填补缺失信息用户提问查询理解改写 / 意图识别检索向量 关键词重排 Rerank拼装上下文LLM 生成带引用的答案关键结论生成质量的上限被检索召回率死死锁住。如果正确的那段文字压根没进上下文再强的模型也只能要么说不知道体验差要么编更糟。一笔简单的账设检索的 Recall5前 5 条命中正确依据的概率 70%生成环节完美无缺那么端到端正确率的上限就是70%。而多数真实问题需要多个依据同时到位若一个问题需要 3 条事实每条独立召回率 90%则三条同时召回的概率是0.9 × 0.9 × 0.9 ≈73%。也就是说单点看起来还不错的 90%在复合问题上会迅速塌到 70% 出头。这就是为什么用户感觉「简单问题还行稍微复杂一点就不靠谱」。向量相似 ≠ 相关向量检索的本质是语义相似度但用户的真实意图经常需要精确匹配用户提问向量检索为什么会翻车「错误码 ORA-01555 怎么处理」错误码是无语义的符号串嵌入模型对它几乎没有分辨力「2025 版报销政策」2024 版和 2025 版文本高度相似向量几乎分不开「哪些机型不支持 5G」否定词在嵌入里被稀释检索回来的全是「支持 5G」的段落「A 产品和 B 产品的差异」需要两篇文档同时召回单一查询向量偏向其中一篇这就是混合检索BM25 关键词 向量 重排Rerank几乎是生产系统标配的原因——纯向量方案是 Demo 阶段的产物。三、根因一语料才是产品但没有人对它负责技术团队默认「文档是现成的我们只管接进来」。而企业知识库的真实状态是自相矛盾2019 年的制度和 2024 年的制度都在库里都没标失效重复冗余同一份政策有 v1、v2、终版、终版最终、终版真的最终格式灾难扫描件 PDF、表格截图、PPT 里的关键流程图——OCR光学字符识别之后全是乱码权限混杂HR 的薪酬细则和全员手册躺在同一个索引里。RAG 在这里有一个放大效应它把一份没人看的过期文档变成了一个语气笃定、格式规整、看起来很权威的答案。原来员工翻到旧文档还知道看一眼日期现在系统直接告诉他「根据规定报销上限为 500 元」——而那是 2019 年的标准。垃圾进自信的垃圾出。Garbage in, confident garbage out.权限问题更棘手且只有两种失败方式全部建进一个索引按最严权限过滤查询时按用户身份动态过滤 重排企业文档带 ACL 访问控制列表索引怎么建检索时越权普通员工问出高管薪酬→ 数据泄露事故大部分内容检索不到用户问什么都是未找到→ 系统没用被弃用可用但工程量常被低估 3~5 倍语料治理不是 IT 项目是知识管理项目。没有一个业务侧的「内容负责人」去下线过期文档、标注权威版本、补充元数据后面所有的算法优化都是在给一堆矛盾的材料排序。四、根因二有一整类问题RAG 在结构上就答不了这是最被低估的一条。RAG 的机制是「检索 top-k 个片段 → 让模型基于片段作答」这决定了它天然只能回答答案已经写在某一段文字里的问题。问题类型例子为什么 RAG 结构上做不到聚合统计「上季度有多少客户流失」答案不在任何一段文字里需要对结构化数据做 SQL 聚合全局归纳「所有故障报告的共性主题是什么」top-k 只能看到几十段看不到全量语料多跳推理「负责 A 项目的人他的上级是谁」需要先查 A→人再查人→上级单轮检索无法串联否定 / 缺失「哪些合同没有保密条款」检索找得到存在什么找不到不存在什么时效 / 权威「现行的差旅标准是」相似度不理解最新和生效中新旧版本一起召回计算推演「按这个折旧率第 5 年账面价值」需要执行计算不是检索致命之处在于用户不知道这条边界在哪里。他不会因为「这是聚合类问题」就换个工具他只会问出来拿到一个语气同样笃定的错误答案然后得出结论——「这系统不靠谱」。做成的团队会在检索之前加一层意图路由事实查找统计聚合全局归纳多跳推理超出范围用户提问意图分类RAG 检索问答文本转 SQL查数据仓库GraphRAG / 预计算摘要Agent 多轮检索明确拒答并给出正确入口带引用的答案「明确拒答」那一支是区分玩具和产品的分水岭。一个敢说「这个问题我答不了请去 XX 系统查」的助手比一个什么都答、但有 30% 在胡说的助手有用得多。五、根因三没有评测就没有迭代问一个正在做 RAG 的团队「你把 chunk size 从 512 改成 256效果是变好还是变坏」大多数团队答不上来——因为他们没有可量化的评测集。没有评测会直接导致三个后果调优变成玄学。换嵌入模型、改切块、加重排每一次都靠「我感觉好像好点了」无法定位。答案错了是检索没召回、重排排错了、还是模型幻觉三个环节要分段测无法防止回退。修好了 A 问题悄悄弄坏了 B 问题上线才发现。最小可用的评测应该分两层层次指标回答什么问题检索层Recallk、命中率正确依据到底进没进上下文生成层忠实度答案是否有依据支撑、正确率、拒答率拿到依据后有没有编该拒答时拒了吗成本没有想象中高由业务专家标注100~200 条真实问题及其正确依据就足以支撑起整个迭代循环。这件事没有捷径——把 60% 做到 90% 靠的是二十次有依据的迭代而不是一次「换个更强的模型」。六、根因四信任经济学是不对称的这条决定了「技术指标不错」的系统为什么照样没人用。用户真正在意的不是准确率是「省下的时间」。而这里有一个残酷的算式如果用户无法判断哪个答案是对的他就必须逐条核对每一个答案。此时哪怕系统准确率 95%用户的核对成本没有下降——净收益接近零。再加上一条不对称性100 个正确答案建立的信任是线性的1 个笃定的错误答案尤其发生在法务、财务、医疗场景摧毁的信任是断崖式的。所以体验设计上有两件事的优先级高于模型调优强制引用Citation每句结论都能一键跳到原文出处把「核对」的成本从「重新搜一遍」降到「瞄一眼」——这是把净收益从 0 拉回正数的关键敢于说不知道宁可拒答不可编造。校准过的「不确定」比虚假的笃定值钱得多。七、根因五组织与 ROI 的错配技术之外还有三个反复出现的组织病灶买平台而不是解问题。「我们采购了向量数据库」不是一个目标。成功的项目往往起点极窄一个部门、一类问题、一批语料——比如只做售后工单的产品手册查询成功指标是「上线」而不是「被使用」。立项 KPI 写的是「Q3 上线智能问答」于是团队在 Q3 交付了一个没人用的系统项目「成功」了没人对答案质量负责。IT 管基础设施业务管内容算法管模型——三方都尽责但「用户问了一个问题得到错误答案」这件事没有 owner。八、诚实地说RAG 这套架构本身的缺陷前面讲的是「用错了」这一节讲「它本来就有的问题」切块Chunking是个有损的权宜之计。它存在的唯一理由是早期上下文窗口太小。切块会切断表格、剥离标题层级、破坏交叉引用——一份结构化文档被拍平成互不相关的碎片top-k 是固定预算问题难度却是可变的。简单问题 3 段足够复杂问题 30 段不够而 k 通常是个写死的常数单一向量装不下多面语义。一段同时讲「价格」和「续约条款」的文字被压成一个向量后两个方面都表达得不充分嵌入模型不认识你的黑话。通用语料训练出的嵌入对企业内部缩写、产品代号、专有工艺词的分辨力很差相似度不理解权威性、时效性和正确性。一份被推翻的旧方案和现行方案在向量空间里可能挨得极近检索器与生成器是分开训练的没有端到端优化——检索器不知道什么样的片段对生成最有用上下文塞得越多未必越好。信息淹没在中间位置容易被忽略lost-in-the-middle注意力被无关片段稀释。这些缺陷催生了后续的各种改良——混合检索、重排、查询改写如 HyDEHypothetical Document Embeddings假设性文档嵌入、GraphRAG、Agentic Search让模型自己多轮检索、长上下文直接塞入等等。但要清楚这些是在补结构性的短板不是锦上添花。九、做成和没做成差别就在这一句话如果把所有根因压缩成一句做成的团队把它当作「一个带 LLM 前端的搜索产品」没做成的团队把它当作「一个带搜索后端的 LLM 产品」。这个视角差异会一路决定下面每一个选择维度当作 LLM 项目多数失败当作搜索产品多数成功团队重心Prompt 工程、换更强的模型检索质量、语料治理首要指标答案「读起来」好不好Recallk、任务完成率、核对耗时语料「给我一个文件夹就行」有专人治理、去重、标注时效与权威范围全公司知识库一步到位一个部门、一类问题做深做透边界外问题硬答路由到 SQL / Agent或明确拒答评测上线前人工试几十条常驻黄金评测集分段量化交互一个聊天框引用、溯源、置信度、反馈回路落地时优先级最高的五件事把范围砍窄——一个部门、一类问题、一批语料混合检索 重排——别用纯向量方案上生产意图路由 敢拒答——把 RAG 答不了的问题挡在外面从第一天就建评测集——100 条真实问题分段测检索和生成答案必须可溯源——引用不是装饰是让净收益为正的前提。十、什么时候根本不该用 RAG场景更合适的方案语料很小几十份文档、总量能进上下文直接长上下文塞入别建检索链路要改变模型的风格、格式、语气微调SFTSupervised Fine-Tuning监督微调问题主要是统计、聚合、报表文本转 SQL查数据仓库需要全局归纳、跨文档主题分析GraphRAG 或预计算摘要事实必须 100% 准确、零容错确定性系统 人工复核LLM 只做辅助知识更新极快分钟级直接调 API 取实时数据别进索引小结Demo 成功和产品成功之间隔着「脏语料 不了解边界的真实用户 可量化的评测」这三关生成质量的天花板是检索召回率——精力花在 prompt 上而不是检索上是最常见的资源错配语料是产品不是素材没有内容 owner算法优化就是给矛盾材料排序有一整类问题聚合、全局、多跳、否定、时效RAG 结构上答不了必须靠意图路由挡在外面而不是硬答没有评测集就没有迭代「换个更强的模型」代替不了二十次有依据的调优信任是不对称的一次笃定的错误抵得过一百次正确——所以引用和拒答的优先级高于调参。一句话记住RAG 的难点从来不在 G生成而在 R检索和它背后那堆没人管的文档。相关笔记English version ·AI 核心概念梳理LLM / Prompt / Agent / RAG / MCP / Skill / Context / Harness