对比传统搜索：链接与答案
关键词搜索返回文档列表，用户自己找；RAG 直接给出答案并附出处。前者透明但费时，后者省事却要承担答错的风险。答案越具体，越需要引用与拒答兜底，否则用户会把错误当成结论，事后再澄清也很被动。
对比微调：知识还是行为
微调改变的是表达风格、格式与任务模式，很难可靠地注入频繁变化的事实；RAG 每次从最新语料取数。知识型需求优先做检索，行为型需求才考虑微调，两者也可以叠加，但边界要先分清，混用会让评测失去意义。
对比长上下文：成本与稳定
把整份文档塞进上下文，短期看省事，长期看成本高且容易丢信息。长文档里关键段落常被稀释，模型回答反而更飘。检索的价值在于先选片段再作答，把上下文控制在必要范围；如何取舍要看文档长度与问法。
对比人工知识库：维护方式
人工知识库靠人编写与审核，质量高但更新慢；RAG 直接从原始文档取数，更新快却依赖语料质量。实践中常把两者结合：高频问题用人工沉淀的标准答案，长尾问题交给检索，各自发挥长处，如何分工要按问题频次与风险来定。
适用与不适用
适合谁
- 知识更新快、问题重复度高的业务
- 需要答案可追溯的内部支持类场景
- 已有文档体系与权限管理基础的企业
不适合谁
- 知识几乎不变、问题数量极少的场景
- 文档质量差、长期无人维护的组织
典型场景
某软件公司的技术支持原本用关键词搜索文档，客户等待时间长。改为检索加生成后，答案直接附上文档段落与版本号，工程师一眼能核对。遇到检索不到的新问题时，系统提示转人工，并把该问题记入下月的语料补充清单。
可执行步骤
- 先统计问题的重复度与问题分布，并确认相关知识大概多久更新一次
- 先判断需求究竟是找事实还是改变表达方式，再决定用检索还是微调
- 用同一批真实问题对比传统搜索与 RAG，逐题记录耗时与准确率
- 为答案设置引用与拒答规则，并在每个关键环节保留人工兜底的入口
- 每季度复查一次语料的覆盖情况，及时补充高频未命中的问题与文档
常见坑
- 把知识更新的需求交给微调，模型记住了旧事实，改版之后长期答错，而且很难被发现出来。
- 只比回答速度，不比准确率与引用是否准确，选型结论必然失真，也会误导后续的预算安排。
- 把长上下文当作检索的替代品，成本上升而关键信息仍被稀释，回答质量并不会因此提升。
- 上线之后不补充语料，未命中的问题反复出现，用户会逐渐放弃使用，系统最终形同虚设。
自检与验收清单
- 是否统计过问题的重复度，以及知识的更新频率
- 需求属于知识型还是行为型，是否已经分清楚
- 是否用同一批真实问题做过完整、可复现的对比测试
- 答案是否附出处，并在关键环节保留人工入口
- 是否建立了按季度补充语料、复核答案的机制
常见问题
RAG 和微调能一起用吗？
可以。常见组合是检索负责提供事实，微调负责统一输出格式与术语风格。但要注意评测要分开做，否则无法判断效果来自检索改进还是模型变化，迭代会失去方向，也说不清下一步该改哪里。
长上下文会不会取代检索？
短期不会。上下文窗口变大降低了门槛，但成本、延迟与信息稀释问题仍在，权限过滤也更难做。对需要审计与权限的企业场景，检索仍是更可控的路径，长上下文可作为补充。
传统搜索还有必要保留吗？
有必要。精确查编号、查原文、查附件时，搜索比生成更直接，也不会出错。很多企业最终是搜索与问答并存，按问题类型分流，而不是用一种方式覆盖所有需求，分流的规则要写清楚。