RAG 和传统搜索的差别，先给结论：要一个能直接读的答案、并且需要出处，选 RAG；要精确找到某份文件、某个条款、某一页，传统搜索仍然更省事。AI 在这两套体系里的位置完全不同，前者是组织答案的引擎，后者更多是排序与召回的工具。下面从匹配对象、答案形态、权限更新、失败模式四个维度展开。
先给结论：按问题形态选
问题如果是「这份制度里请假怎么算」，RAG 更合适，它能把散落在三份文件里的段落拼成一段话。问题如果是「找到 2024 年第三版采购管理办法的原文」，传统搜索更快，因为它只需要把文档摆到你面前。
再补一条判断：需要跨文档推理、需要把表格和正文合起来解释，走 RAG；需要穷举、需要确认有没有漏，走搜索加分页浏览。两者的目标不同，一个是回答，一个是定位。
匹配对象：词项与语义块
传统搜索以词为中心，靠倒排索引找包含关键词的文档，再用链接和点击行为排序。它的强项是精确，输入单号、型号、人名，几乎不会跑偏；弱项是同义表达，用户说「报销多久到账」，文档里写的是「费用核销时限」，词面对不上就找不到。
RAG 先把文档切成块，转成向量存进索引，检索时比对的是语义相似度。用户换一种说法也能召回，代价是对精确标识不敏感，单号这类内容反而要额外加一层关键词过滤，否则会召回一堆语义相近但完全无关的段落。
| 维度 | 传统搜索 | RAG |
|---|---|---|
| 匹配对象 | 词项，靠倒排索引找包含关键词的文档 | 语义块，比对向量相似度 |
| 强项 | 精确，单号、型号、人名几乎不会跑偏 | 同义表达也能召回，换个说法照样命中 |
| 弱项 | 词面对不上就找不到，比如「报销多久到账」对「费用核销时限」 | 对精确标识不敏感，单号要另加关键词过滤 |
答案形态：链接列表与带出处的一段话
搜索返回的是一列链接，用户自己判断哪条有用；RAG 返回的是一段组织好的话，后面挂几个出处。前者把判断权交给用户，后者把判断权部分交给了模型，所以出处的可靠性变成核心指标。
出处不能只是装饰。比较稳的做法是要求每个结论句都能点到原文片段，点不开就不写。做不到这一点，RAG 的输出看起来流畅，实际无法核对，在内部知识库场景里很快会失去信任。
更新与权限的差别
搜索的更新相对简单，文档进了索引就能被搜到，权限在查询时按用户身份过滤。RAG 多了一步切块和向量化，文档更新后要重新切、重新算，否则会检索到旧版本。增量更新做得不好，是 RAG 项目最常见的翻车点。
权限也更麻烦。切块之后，一个块可能混了不同密级的段落，检索时按块过滤会漏，按文档过滤又会把整篇挡掉。实践里要在切块阶段就带上权限标签，并且让生成环节再校验一次，不能只靠检索层。
失败模式完全不同
搜索失败的表现是「搜不到」，用户会换关键词再试，成本低、可感知。RAG 失败的表现是「答得很像但答错了」，用户如果不核对出处，根本发现不了，这是它最危险的地方。
所以 RAG 需要额外的守门机制：召回为空时明确说没找到，而不是让模型自由发挥；召回内容冲突时并列呈现，而不是挑一个；涉及数字和时限时强制标出来源。这些规则写进系统提示，比事后抽查更有效。
混合做法怎么搭
成熟系统通常是混合的：先用关键词检索保证精确命中，再用向量检索补语义召回，两路结果合并后重排，最后交给模型组织答案。单号、型号这类查询直接走精确通道，不进入生成环节。
前端也要混合。给一个对话入口，同时保留筛选、排序、原文预览。用户看到答案后想核对，一键跳到原文对应段落，这个体验比再问一遍模型可靠得多。
做原型时不必一开始就自建，直接用 DeepSeek 或 Kimi 的接口把链路跑通，先验证召回和引用的质量，再决定要不要投入索引和部署的工程。
- 要答案要出处：走 RAG
- 要找原文要穷举：走传统搜索
- 精确标识：关键词通道优先，别只靠向量
- 更新：文档变更要重切重算，增量别偷懒
- 守门：召回为空就说没找到，别让模型补
RAG 和传统搜索快问快答三则
- 有了 RAG 还需要关键词搜索吗？：需要。精确匹配和穷举场景它替代不了，两路合并才稳。
- 文档很少也要做 RAG 吗？：几十页以内可以先做结构化目录加搜索，向量索引的维护成本可能不划算。
- 怎么判断答得对不对？：抽查出处能否点开、数字是否与原文一致，比看语言流畅度可靠得多。
知识库要不要自己建，可以对照自建知识库和用 SaaS 差在哪里的成本口径；模型选通用还是行业版，见通用模型和行业模型差在哪；导览类场景的用法可以参考智能导览的个性化是怎么做。
