在设计一个特定于领域的企业级会话式问答系统来回答客户问题时，Conviva 发现要么/要么的方法是不够的。
译自 Improving LLM Output by Combining RAG and Fine-Tuning，作者 Haijie Wu; Junhwi Kim。
大语言模型 (LLM) 和会话式 AI 具有让应用程序更易于使用的巨大潜力，特别是对于新用户而言。它们可以回答有关产品的问题、协同操作平台、总结数据，并采取更多措施来帮助用户快速上手。
虽然对使用 LLM 充满极大热情，但对于这项技术是否“已为企业做好准备”也存在很多疑虑。具体来说，科技行业想知道如何最好地针对特定用例和特定领域知识定制这些工具。尝试使用现成的 LLM 模型或 ChatGPT 可能会导致随机答案和幻觉，因为它们没有特定于产品的领域知识。这可能会导致企业客户失去信任，或者更糟的是，导致他们根据不正确的建议做出错误的决策。
在 Conviva，我们很高兴使用 LLM 来简化客户使用我们产品的方式。作为背景，Conviva 为全球许多领先的媒体和娱乐公司提供质量体验监控。客户与我们的交互式深入钻取系统进行交互，以实时了解其用户的体验质量。传统上，新用户必须参考我们的产品文档或与客户服务专家联系来回答“语义”问题；例如，如何定义特定的 体验质量 (QoE) 指标？特定客户端属性或 /维度是什么意思？特定 QoE 指标的良好值范围是什么？
2023 年夏季，我们决定构建和运营一个名为 Conviva PromptAI 的会话式问答解决方案。这个会话式协同操作工具每天被 20 多家企业级客户的 100 多名用户使用。
在设计 Conviva PromptAI 时，我们有三个关键的顶级问题需要回答：
- 我们应该托管我们自己的 LLM 还是使用第三方服务的 API？
- 我们应该使用哪种语言模型？
- 我们如何最好地向 LLM 教授我们的领域？微调？检索增强生成 (RAG)？其他？
我们分享我们的经验和教训，希望它对踏上类似旅程的其他企业更广泛地有用。
托管还是使用 API？
我们的第一个问题是使用 开源 LLM 模型还是像 OpenAI 这样的云服务解决方案。一般来说，OpenAI 的模型 (GPT-4) 的准确性高于其开源对应模型。但是，开源模型提供了对超参数的更大控制、微调的能力以及轻松组合不同模型的更好方法。
我们的核心产品有很多需要专门制作的模型和配置。我们还希望继续投资 LLM 技术，这需要高度的控制和灵活性。这些因素促使我们选择开源路径并托管我们自己的模型，而不是使用第三方服务。
什么是正确的语言模型？
在决定利用开源 LLM 之后，下一个障碍是选择满足我们需求的理想模型。当我们的项目去年启动时，我们选择了 Llama2 70B。当时，Llama2 作为最强大的开源 LLM 脱颖而出，因为它提供了我们需要的广泛的通用性能。我们特别选择了 70B 变体，而不是较小的对应变体，即 7B 和 13B 模型，因为它提供了更全面、更详细的解释，并针对我们的上下文进行了定制。
在决定哪种 LLM 最适合你的用例时，比较基准分数（例如 MMLU 或 HellaSwag）会有所帮助。自从我们选择 Llama2 以来，随着其他开放 LLM 的引入，格局已经发生了变化，例如 Mixtral 8x7B、DBRX 和 Grok-1.5。我们目前正在评估这些替代方案，但目前我们不认为切换有重大价值，因为领域适应存在更严峻的挑战。
微调、RAG 还是两者兼而有之？
有三种自然选择可以教授 LLM 指导其答案所需的上下文领域知识：
- 提示工程
- 检索增强生成 (RAG)
- 微调
我们的目标是帮助客户，因此，让用户执行提示工程不是一个选择：由于用户甚至可能不知道如何表述提示，因此我们不能指望提示工程提供所需的的用户体验！因此，RAG 和微调是我们唯一的选择。
要了解差异，请考虑将 LLM 的训练视为学生备考。RAG 就像参加开卷考试。LLM 可以使用任何检索机制（例如网络浏览或数据库查询）访问相关信息。微调就像参加闭卷考试。LLM 需要在微调过程中记忆新知识，并且它根据其记忆回答问题。
下表总结了这两种规范方法的优缺点。
RAG模型(检索增强生成) | 微调模型 | |
|---|---|---|
构建训练集的工作量 | 零 | 非常高 |
准确性 | 受到检索性能的限制,可能会虚构细节信息,准确性不太好 | 不太擅长处理详细信息,可能会产生幻觉 |
数据新鲜度 | 容易 | 维持数据新鲜度代价高昂,需要重新训练 |
RAG 易于上手，并且可以使用开箱即用的预训练模型。
如果用户询问“缓冲比率的定义是什么？”，则有关其他指标的信息对于回答它没有帮助。RAG 将用户问题转换为嵌入，然后搜索预填充的向量数据库以查找“类似于”用户问题的文档。然后，这些文档作为 LLM 提示中上下文的一部分提供，以回答用户的问题。
但是，RAG 在提供正确答案方面仍然存在局限性。当用户的问题与文档中的内容没有直接关系时，尤其如此。
考虑一种情况，用户询问他们应该监控的前五项指标。在实践中，每个指标可能都有特定的文档，但可能没有直接对指标进行排名的单一文档。因此，检索过程难以有效地使用相似性分数来识别用于回答问题的正确指标。
RAG 不适合需要检查几乎所有可用文档才能找到答案的问题。它基于这样的假设：只需要少数文档即可回答任何给定问题。
RAG 和微调的比较RAG 和微调的比较：RAG（左）无法检索适当的文档来回答问题。但是，微调（右）可以帮助从所有文档中提取知识来回答问题。
微调更擅长从所有可用文档中提取知识来回答问题。然而，我们发现微调并非没有自己的问题。在某些情况下，微调在处理非常详细的信息时不如 RAG 准确。虽然这可以归因于我们的训练数据集，但创建一个正确的训练数据集来仅通过微调来克服这是一个实际问题。其次，微调在根据最新可用内容刷新信息方面很弱。最后但并非最不重要的一点是，微调非常耗费资源。它本质上是一个训练过程，因此需要大量的机器资源。对于没有足够 GPU 的公司来说，这可能会成为阻碍。该过程也需要很长时间，并且需要大量的尝试和错误。
我们的方法：将微调与 RAG 相结合
我们的实验使我们意识到，就它们本身而言，微调和 RAG 是不够的。为了获得两全其美的效果，我们采用了一种混合方法，将微调与 RAG 相结合。
此表总结了这三种方法的优缺点。
RAG模型(检索增强生成) | 微调模型 | 我们的方法 | |
|---|---|---|---|
构建训练集的工作量 | 零 | 非常高 | RAG 合成微调数据 |
准确性 | 受到检索性能的限制,可能会虚构细节信息,准确性不太好 | 不太擅长处理详细信息,可能会产生幻觉 | 使用微调提高检索准确性 |
数据新鲜度 | 容易 | 维持数据新鲜度代价高昂,需要重新训练 | 使用RAG获取最新信息 |
我们方法背后的高级思想是通过微调模型来改进检索过程。如前所述，微调面临的挑战之一是创建训练数据集。但是，一旦我们为 RAG 准备了文档，我们就可以直接将它们用于微调。我们还通过利用 LLM 来改写现有文档来合成更多数据。
下图显示了合并 RAG 和微调模型的整体工作流程。对于给定的用户问题，微调后的 LLM 会推测性地生成一个初始答案。然后使用此响应来获取相关文档。最后，LLM 创建一个结合检索到的文档和原始用户问题的答案。添加微调模型极大地提高了检索的准确性和最终答案的质量。
合并 RAG 和微调工作流
在推出系统时，我们还实施了一个简单的用户评分机制，以收集内部专家和客户对响应的满意度数据。通过合并方法，我们在内部用户测试中看到了显著的改进结果，这让我们对其更高的质量充满信心。
结论
PromptAI 已显著提升了我们为客户提供的价值。我们的用户现在无需浏览大量文档，而是可以直接询问他们的需求，并在 PromptAI 的帮助下专注于解决问题。
正如他们所说，事实胜于雄辩，我们收到的反馈就是最终的验证。正如一位客户所说，“
在直播活动期间，我没有时间查看仪表板——我需要向某人询问为什么会出现这种情况，并相信这是正确的。我希望看到它朝这个方向发展。”
这项创新得益于 LLM 的最新创新和高保真开源模型的可用性。虽然我们的经验表明，使其适用于用例并适应领域知识需要一些“提升”，但投资回报率是值得的。
我们希望通过分享我们的关键学习和设计选择，能够激发和帮助其他踏上类似旅程的企业利用 LLM 的力量。
Vyas Sekar 也为本文做出了贡献。
