给企业文档接入大模型时，常见问题是：应该搭建 RAG，还是拿内部资料去微调模型？两种方案都会影响最终回答，却解决着不同的问题。简单地说，RAG 负责在回答前“翻资料”，微调则更像训练模型“按某种方式做事”。
RAG 解决的是知识从哪里来
RAG 是检索增强生成。用户提问后，系统先从产品手册、规章制度或历史文档中找出相关片段，再把这些片段连同问题交给模型生成答案。
例如员工询问“差旅住宿标准是多少”，真正重要的是找到当前生效的制度条款，而不是让模型凭记忆回答。制度更新时，只需替换或重新索引文档，不必重新训练模型。答案还可以附上文件名称、章节和原文片段，方便用户核对。
RAG 的难点也很明确：文档是否清洁、切分是否合理、检索是否找对内容。检索阶段漏掉关键条款，后面的模型再聪明也很难补救。因此，做 RAG 不能只测试回答是否流畅，还要单独检查“正确资料有没有被召回”。
微调改变的是模型怎样回答
微调是用一批示例继续训练已有模型，让它学习特定任务的输出形式、语气或决策习惯。它适合的问题通常是：“模型知道相关信息，但总是不按我们需要的方式回答。”
比如客服回复必须先确认问题类型，再给出三步操作，最后提醒风险；或者文本分类必须稳定输出固定标签。准备质量一致的输入输出样例进行微调，可能比在每次提示词里反复说明规则更合适。
但微调不应被当成更新知识库的首选办法。把大量产品资料放进训练数据，并不意味着模型能逐条准确记住，更难在回答时指出依据。资料一旦变化，还要重新整理数据、训练和验证，维护链路会变长。
从成本和更新频率做选择
RAG 的主要投入在文档处理、向量检索、权限控制和日常索引更新。它会增加一次检索流程，系统结构更复杂，但知识可以频繁更新，也适合按部门或用户限制可见范围。
微调的投入集中在高质量样例、训练过程和版本评测。训练完成后，固定任务的提示词可能更短，输出风格也可能更稳定；代价是每次模型、规则或数据变化都要重新确认效果。
如果资料经常更新、答案需要引用来源，优先考虑 RAG。如果知识相对稳定，核心诉求是统一格式、语气或分类行为，可以评估微调。项目刚开始时，通常先用提示词和少量真实案例验证需求，再决定是否值得增加训练成本。
两种方案要用不同方式评估
评估 RAG，可以把过程拆成两段：先看检索结果是否包含回答所需的证据，再看模型是否忠实使用证据、有没有编造。测试问题应覆盖同义表达、模糊提问、无答案场景和权限边界。
评估微调，则要准备未参与训练的测试集，检查格式遵循、任务准确性、语气一致性，以及原本正常的能力是否退化。只挑几个“看起来不错”的示例容易误判，最好保留一套固定题目，在每次训练和模型升级后重复测试。
无论选择哪一种，都应允许系统在证据不足时明确说不知道。知识库问答的目标不是每次都生成答案，而是在可核对的范围内给出可靠答案。
实际项目往往是组合使用
RAG 和微调并不冲突。一个常见组合是：RAG 提供最新、可追溯的业务资料，微调让模型稳定遵循客服话术、字段格式或分类流程。前者提供“答什么”的依据，后者约束“怎么答”。
更稳妥的实施顺序是先整理问题集，用提示词做出基线；知识不足就接入 RAG，行为仍不稳定再考虑微调。这样每一步都对应明确问题，也能通过前后评测判断投入是否有效。技术选型最终不是比较哪个名词更先进，而是先确认瓶颈究竟在知识、检索，还是模型行为。