LLM 落地 RAG 还是 Finetune 方案选择问题？

大家好，欢迎来到IT知识分享网。

传统厂商在面对自身企业的具体场景下，切入LLM 整合业务应用的时候，主要有两种方案供选择，RAG 与 Finetune. 那么在企业级应用场景下，到底是应该选择RAG 还是Finetune 呢？下面由 Humanloop 公司联合创始人提供下图给出了答案.

Humanloop 公司提供

上图纵轴表示模型能力，横轴表示建设方案.

结论：一般面向具体应用场景，将 RAG 和 Finetune 结合起来使用，即使用Finetune 之后的模型构建 RAG.(小孩才做选择，成年人都要) 具体来讲，RAG 和Finetune 两种方案各有优缺点，他们赋予模型能力提升有相同也有不同的地方.

1.RAG

在面向具体场景实践过程中，RAG 是首先要被使用的方案；RAG 具有成本低（不需要投入硬件资源进行训练）、知识更新快速（知识库更新）、对领域知识整理成文档即可投入使用（数据要求低）、回答出现幻觉错误少 这些优点.

RAG 方案缺点局限于自身选择的技术路线：RAG 性能，受文档切分模型算法、文本Embedding、文本相似度检索 这些RAG 自身采用的技术方案带来的缺陷、RAG 方案有时候要写较长的提示词、RAG 方案利用的都是第三方训练好的开源模型、或接入的第三方模型API，模型相关能力没法进一步提升（如指令跟随能力）

2.Finetune

Finetune 一般使用高效参数微调技术如LoRA、P-tunning 等技术，具有和全量参数微调同等效果的同时，节省大量硬件和算力.当然DPO 这类对齐算法和LoRA 结合起来对模型微调也是广泛被选择的方案。

Finetune 技术能让模型具备复杂的指令遵循能力（如 依据上下文，输出固定格式数据json；电商场景下商品关键词扩写输出) ，情景对话能力增强、使LLM 模型原本不具备指令遵循能力加持，这时候往往需要对模型进行Finetune.

上面描述的相关场景 只使用 RAG 方案很难解决，Finetune 方案能做到支持；缺点是Finetune 方案需要投入硬件、算力资源、构造问答数据集合；而且有时候模型依然会出现幻觉错误等问题。

最后总结一下，本文对企业大模型落地过程中，RAG 与Finetune 方案选择问题进行了剖析，对比两种方案优缺点以及实际解决问题场景的差异；大家如在实际实践过程中，有什么问题欢迎在评论区进行探讨，谢谢大家。