将生成式AI项目投入运营：在生产环境中部署和管理RAG流水线的最佳实践

在生产环境中使用RAG：将生成式AI项目投入运营

检索增强生成（Retrieval Augmented Generation, RAG）为组织提供了一个机会，可以通过应用生成式AI（Generative AI, GenAI）功能来利用大型语言模型（LLMs）处理自己的专有数据。使用RAG可以减少风险，因为我们依赖于受控数据集作为模型回答的基础，而不是依赖可能不可靠、不相关或错误的训练数据。然而，您必须持续管理RAG流水线，以确保答案是基于事实和准确的。本文将探讨在生产环境中部署RAG功能时需要注意的关键点，并演示Elastic Search AI平台如何提供所需的见解，让您安心运行RAG流水线。

定义RAG流水线

一个典型的RAG实现包括用户提供的问题被发送到一个LLM，并附带上下文信息。这个上下文需要提供相关的信息，以便LLM生成答案。上下文是通过评估用户问题与向量存储内容的匹配结果生成的，确保结果在语义上与问题一致。在Elastic Search AI平台的情况下，上下文还可以是混合搜索的结果，包括词汇搜索、文档过滤和访问控制规则。在一次离散操作中执行混合搜索操作的能力，使开发者能够通过结合语义轴和词汇搜索轴的结果，构建尽可能相关的LLM上下文。此外，过滤器和访问控制规则限制了要搜索的数据集，以遵守RBAC（基于角色的访问控制）规则，提高性能并维护数据安全。

LLM接收问题，解释上下文，然后用一个答案进行回应，这个答案通常是上下文的总结或相关陈述的综合。问题和上下文的组合被称为提示（prompt），提示还为LLM提供了其角色和如何回答的指导。开发者创建一个称为提示模板的工件，将所有这些值逻辑地组合在一起，可以重复使用并微调，以确保正确的结果。

因此，RAG实现可以看作是由以下元素组成的流水线：

1. 用户提供的问题
2. 搜索生成的上下文
3. 提示模板
4. LLM生成的答案

生产环境注意事项

在实施RAG流水线时，需要考虑多个操作和性能因素，以确保交付的体验符合最终用户和开发团队的期望。

1. 需要跟踪指标，像任何应用程序一样，以确保RAG流水线在SLO（服务水平目标）和SLI（服务水平指标）目标内运行。
2. 问题和答案不应被丢弃，因为它们包含关于系统行为和用户偏好的宝贵信息。
3. 成本应被持续跟踪和审查。
4. 需要一致地评估RAG流水线，以确保LLM的回答是准确的，并且它们被提供了足够的上下文来回答这些问题。

那么，具体如何实现这些目标呢？在将RAG流水线投入生产时，需要考虑哪些模式和实践？显然，这是一个非常广泛的话题，但我们将从高层次上讨论这些考虑因素，以鼓励进一步阅读和探索。

RAG性能与监控

在构建RAG流水线时，为您的用例确定正确的提示技术至关重要，因为这可能是产生真实有价值的答案与误导和令人沮丧的答案之间的区别。因此，提示开发需要对底层数据有足够的了解，并有一个能够客观衡量LLM答案的基准框架，并对其进行严格的真实性测试。选择基准框架需要了解哪些指标不仅重要，而且需要如何测量这些指标。一旦投入生产，记录所有LLM交互变得至关重要，以确保管理和控制数据点，如成本、延迟和响应质量。

RAG基准测试与评估

首先是基准测试和评估，因为这必须在投入生产之前进行，以减少提供不良或有害服务的风险。有许多可用的基准框架，它们通常围绕一个问题集和来自RAG上下文的基础知识的真实答案进行选择。选择正确的框架取决于几个关键因素：

1. 框架应与您团队的技能、应用程序代码和组织政策兼容。这是一个跨职能的整合，应与您的决策一致。例如，如果您选择仅使用本地托管的LLMs，那么框架应适应这一点。
2. 您需要有选择评估指标的灵活性，这些指标对您来说很重要。
3. 生成的评估输出应易于集成到现有的可观察性或安全工具中，因为LLMs是应用程序的关键功能，不应视为独立系统。

这些问题/答案对代表了对数据和用例的基本理解，并将用于评估整个流水线的性能。重要的是，问题集应包含用户最有可能提出的相关问题，或至少是可能提出的问题类型。答案不应是文档的简单复制粘贴，而应是一个或多个事实的总结，充分回答问题，因为这才是LLM在回答问题时可能会生成的内容。

基准问题将通过RAG流水线传递，并生成两个输出来通知任何评估指标：LLM响应和上下文。在大多数情况下，框架将评估LLM响应的准确性或正确性，并测量答案的语义相似性。答案还可以与上下文进行比较，以确保其包含的任何陈述都能在问题派生的搜索结果中找到依据。进一步的指标可以通过将基准、上下文和问题考虑在内来计算答案的相关性。

虽然RAG基准测试旨在出于功能原因衡量答案的质量，但实施一个预生产阶段可以显著减少幻觉、偏见，甚至训练数据中毒的风险，因为基准数据集代表绝对真相，并将突出LLM输出中的异常。

RAG日志记录

虽然LLM生成内容时可能不会产生日志文件，但这并不意味着无法记录与LLM交互的宝贵细节。决定具体需要记录什么取决于对您的业务重要的内容，但至少应捕捉以下数据：

1. 用户提供的问题（例如，我每年能获得多少带薪休假？）
2. LLM生成的答案（例如，“根据政策，您每年有23天的带薪休假，来源：HR政策，第10页。”）
3. 提交到LLM的时间戳、首次响应时间和LLM完成响应的时间
4. 从提交到首次响应的延迟时间
5. LLM模型名称、版本和提供者
6. 在调用时配置的LLM模型温度（有助于调试幻觉）
7. 端点或实例（用于区分生产和开发）

此外，您可能会发现以下字段有用：

1. 提示和答案的成本，以令牌计量，并基于模型提供者提供的单位成本
2. 业务流程（客户支持、工程知识库等）
3. 提交给LLM的提示（有或没有上下文，因为您可能希望将上下文导入单独的字段，这有助于调试或解决答案语气、幻觉和准确性问题）
4. LLM响应的情感（可以通过情感模型进行）

在RAG流水线达到生产状态之前记录操作数据至关重要，以消除任何潜在的盲点，充分管理成本和客户满意度，并验证基准测试中观察到的结果是否在现实世界中得到复制。

创建统一的RAG数据平台

在新兴技术中，最常见的模式之一是为每个细微需求使用多个工具。点解决方案往往解决系统的一个需求，但需要系统所有者或架构师寻找剩余需求的解决方案。这本质上并不坏，因为试图满足太多不同的目标可能导致没有一个目标完全实现。然而，当您考虑到数据是任何系统中最有价值的资产时，转向将数据集中在一个统一的平台上确实使您的最有价值资产更容易使用和管理。当数据与来自更大系统的其他部分生成的数据提供的上下文一起分析时，会产生新的见解和意义。

用于RAG的Elastic Search AI框架

Elastic可以在单个平台中解决RAG流水线的所有数据输入和输出需求，作为基础数据层，包括性能和监控框架生成的数据。以下是一个功能架构，展示了Elastic如何促进RAG流水线的每一步。

Elastic Search AI框架

Elastic Search AI平台在以下功能上独特地满足了流水线的需求：

1. Elastic是为GenAI构建上下文的最佳存储和检索引擎。使用单个API端点内的词汇和语义搜索功能的灵活性，允许RBAC执行和复杂的重新排名功能，以实现有效的上下文窗口。
2. Elastic是全球无数项目和团队的事实标准日志平台，并作为Elastic可观察性和Elastic安全解决方案的底层数据平台。添加LLM日志数据只是利用了这种本机能力。
3. Elastic Search AI平台能够托管所需的transformer模型，以使内容向量化，从而使其具有语义可搜索性，而无需外部模型托管工具和服务。这是通过利用Elastic提供的ELSER稀疏向量模型以及启用自定义模型导入来实现的。
4. Elastic可以作为基准测试设置数据的内容存储，包括问题、答案和真实数据——使得评估框架可以使用与RAG流水线相同的库来实现，进一步简化复杂性，并确保测试框架与应用程序实施一致。
5. 作为基准测试数据目的地的Elastic允许细粒度分析和全面的结果可视化。这些基准测试结果还可以与实时日志数据相结合，以表示整体流水线健康状况，并识别功能偏差，还可以进一步利用Elastic的警报功能，确保没有异常未被发现。
6. 最后，Elastic允许轻松聚合常见问题，以更好地通知基准测试配置，使其与现实世界数据紧密对齐。考虑到基准测试实际上是一种回归活动，这一步对于确保其可信和相关至关重要。了解用户最常提出的问题还可以缓存这些答案，以便即时响应，使得不必引用LLM。

通过将所有数据记录在Elastic中，配置可视化、仪表板和警报变得简单快捷，为您的团队提供顺利和主动运行流水线所需的可见性。

llm-log

llm-log

结论

通过仔细和周到的RAG实施可以带来巨大的好处，但如果不考虑RAG流水线的持续管理生命周期，许多这些好处可能会被抵消。Elastic Search AI平台简化了强大且安全的RAG流水线的部署，支持GenAI的采用，同时最大限度地减少与这些早期技术相关的风险。请务必注册Elastic Cloud的免费试用，以尽可能快速和轻松地将您的GenAI想法投入生产。