RAG 与模型微调：区别和选择方法

企业使用大模型时，可能遇到两类不同的问题：一类是回答缺少内部资料或最新信息；另一类是资料已经给了，回答格式、分类结果或任务表现仍不符合要求。两类问题不一定需要同一种处理方式。

RAG，即检索增强生成，会在回答前查找相关资料，再把找到的内容提供给模型。更新知识通常不需要重新训练基础模型，但仍需要维护资料和检索流程。AWS 对 RAG 的说明 ↗

这里讨论的模型微调主要指监督微调：使用带有输入和期望输出的训练样本，调整模型参数，使其更适合特定任务。它需要准备训练数据并检验结果，不是上传一批企业文档就完成了。AWS 模型定制说明 ↗

如果清楚的指令、示例和格式校验已经能满足要求，就没有必要仅为了“使用微调”而增加训练环节。反过来，模型拿到了资料却仍然答错，也不能只靠扩大知识库来解决。

知识库里存的是供系统查阅的资料，例如产品说明、操作手册和内部制度。每份资料需要有来源、版本和访问权限。新旧制度同时存在而未作区分时，系统可能找到一段文字，却用错了版本。

微调使用的则是任务样本。例如一项分类任务，需要有代表性的输入和经过核对的分类结果。样本中的错误、矛盾或缺漏需要处理，同时确认数据是否获准用于训练，以及是否包含敏感信息。

还需要单独保留一组验收题目，不参与训练或日常调试。题目除了正常情况，也应包含资料缺失、无权限和含义不清的问题。这样才能检查系统面对新问题时的表现，而不只是复现演示时的答案。

对于带检索的系统，可以同时保存检索结果和最终回答。如果正确资料根本没有被找到，要检查文档处理、检索条件或权限过滤；如果资料已经找到，回答却遗漏限制或曲解原文，就需要检查模型如何使用这些内容。

以查询产品说明为例：系统没有找到新版本，与找到了新版本却引用了旧参数，是两种不同的错误。如果只记录“回答不准确”，后续很难决定该改检索还是改回答生成。

比较候选方案时，应使用同一组验收题目和评分办法，并记录响应时间、单次调用成本以及人工修改的情况。一次表现出色的回答，不足以说明整个方案适合上线。

接入 RAG 后，回答仍可能出错。资料本身过期、检索遗漏或模型误读，都可能影响结果。能展示引用来源，也不意味着引用一定支持答案，需要检查原文。

做过微调，同样不代表模型记住了企业所有知识。企业资料持续变化时，仍要考虑知识更新和结果核验，不能把一次训练当作长期维护的替代品。

数据部署在自有服务器上，也不等于访问控制已经解决。哪些账号能读取资料、日志中保留什么、是否有外部调用，仍需要分别检查。其他项目公布的效果或成本数据，也不能直接当作本企业的预期收益。

一份有用的选型结论，应说明当前有哪些问题、试过哪些办法、使用了什么数据，以及哪些情况仍会失败。推荐某个方案时，也要说明上线后由谁更新资料、维护样本和处理异常。

业务负责人需要知道系统能完成哪些任务、什么时候会拒绝回答或转交人工；技术负责人则需要看到测试记录、成本和维护条件。如果基础方案已经达到要求，也可以明确记录暂不采用微调的理由。

相关服务：模型优化，可以提供现有资料类型、几个典型的错误回答，以及希望得到的结果。