检索增强生成（RAG）为组织带来了显著机遇：将生成式AI的能力应用于企业专有数据，有效减少大型语言模型（LLM）在回答时出现的“幻觉”现象。其核心机制在于，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流水线时，需提前考虑诸多操作与性能因素，否则最终交付的体验可能难以令用户和开发团队满意。需要关注的方面包括：

• 如同对待任何应用程序一样，必须跟踪指标，确保RAG流水线在SLO（服务水平目标）和SLI（服务水平指标）的框架内运行。
• 问题和回答不应随意丢弃——其中蕴含着关于系统行为和用户偏好的宝贵信息。
• 成本需要持续跟踪与审核。
• 还需要对RAG流水线进行一致评估，确保LLM的回答准确无误，并已获取足够的上下文来回答提问。

那么，具体如何落地这些目标？将RAG流水线推向生产时，有哪些模式和实践可供参考？这个主题确实广泛，我们先从高层次探讨这些考量因素，鼓励大家进一步阅读和探索。

RAG性能与监控

构建RAG流水线时，为具体用例选择合适的提示技术至关重要——这可能是产出真实有价值的答案与给出误导、令人沮丧的答案之间的分水岭。因此，提示开发需要深入了解底层数据，同时具备一个能够客观衡量LLM答案的基准框架，并对其进行严格的真实性测试。选择基准框架时，不仅要清楚哪些指标重要，还需明确这些指标的测量方法。一旦上线生产，记录所有LLM交互变得至关重要——只有这样才能有效管控成本、延迟和响应质量等数据点。

RAG基准测试与评估

基准测试与评估必须在投入生产之前完成，这是降低提供低质量或有害服务风险的首要步骤。市面上存在许多现成的基准框架，通常围绕特定问题集和RAG上下文中的真实答案进行设计。选择合适的框架，需考虑以下因素：

• 兼容性：框架需与团队技能、应用程序代码及组织政策相匹配。这是一项跨职能的整合，必须与你的决策保持一致。例如，如果你选择仅使用本地托管的LLM，那么框架也应能适应这一环境。
• 指标灵活性：你需要能够自由选择评估指标，因为这些指标对你而言真正关键。
• 集成便利：生成的评估输出应能轻松集成到现有的可观测性或安全工具中。LLM是应用程序的核心功能，不应被视为独立系统。

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

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

虽然RAG基准测试主要出于功能原因衡量答案质量，但设立预生产阶段能够大大降低幻觉、偏见甚至训练数据中毒的风险——因为基准数据集代表了绝对真相，可以清晰地暴露LLM输出中的异常。

RAG日志记录

LLM在生成内容时可能不产生日志文件，但这并不意味着无法记录与LLM交互的宝贵细节。具体记录哪些内容取决于业务优先级，但至少应捕获以下数据：

• 用户提供的问询（例如“我每年能获得多少带薪休假？”）
• LLM生成的回答（例如“根据政策，您每年有23天的带薪休假，来源：HR政策，第10页。”）
• 提交给LLM的时间戳、首次响应时间以及LLM完成响应的时间
• 从提交到首次响应的延迟时间
• LLM模型名称、版本及提供方
• 调用时配置的LLM模型温度（对调试幻觉有帮助）
• 端点或实例（用于区分生产与开发环境）

以下字段也可能提供协助：

• 提示与答案的成本——按令牌计量，基于模型提供方给出的单位成本
• 业务流程（客户支持、工程知识库等）
• 提交给LLM的提示（可带或不带上下文，因为可能希望将上下文导入单独字段，这对调试答案语气、幻觉和准确性问题均有帮助）
• LLM响应的情感（可通过情感模型实现）

在RAG流水线达到生产状态之前就开始记录操作数据，这一点至关重要——它能消除潜在盲点，充分管控成本与客户满意度，还能验证基准测试中观察到的结果是否能在现实世界中复现。

创建统一的RAG数据平台

在新兴技术领域，最常见的模式之一是为每个细微需求使用不同的工具。点解决方案往往只满足系统的一个需求，系统所有者或架构师还需寻找剩余需求的解决方案。这本身并非坏事——试图满足过多不同目标，可能哪个都无法实现。但当你考虑到数据是任何系统中最有价值的资产时，将数据集中在一个统一平台上，确实能让这份最有价值的资产更易于使用和管理。当数据与更大系统中其他部分生成的数据所提供的上下文一起分析时，还会产生全新的见解与意义。

用于RAG的Elastic Search AI框架

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

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

• Elastic是为GenAI构建上下文的最佳存储与检索引擎。单个API端点内同时提供词汇和语义搜索功能，允许RBAC执行和复杂的重新排名，从而实现高效的上下文窗口。
• Elastic是全球无数项目和团队的事实标准日志平台，也是Elastic可观察性和Elastic安全解决方案的底层数据平台。将LLM日志数据纳入其中，不过是利用了这种原生能力。
• Elastic Search AI平台能够托管所需的变压器模型，使内容向量化从而具备语义可搜索性——无需依赖外部模型托管工具和服务。这是通过ELSER稀疏向量模型以及自定义模型导入功能实现的。
• Elastic可以作为基准测试数据的内容存储，包括问题、答案和真实数据——评估框架可以使用与RAG流水线相同的库来实现，进一步简化复杂性，确保测试框架与应用程序实现保持一致。
• 作为基准测试数据的目的地，Elastic允许进行细粒度分析和全面的结果可视化。这些基准测试结果还能与实时日志数据结合，呈现整体流水线健康状况，识别功能偏差，并利用Elastic的警报功能确保异常不被遗漏。
• 最后，Elastic可以轻松聚合常见问题，使基准测试配置更贴近现实世界数据——考虑到基准测试本质上是一种回归活动，这一步对于保证其可信度和相关性至关重要。了解用户最常问的问题还能缓存这些答案，实现即时响应，无需每次都调用LLM。

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

结论

周密细致的RAG实施能够带来巨大收益，但如果忽视RAG流水线的持续管理生命周期，许多优势可能会被抵消。Elastic Search AI平台简化了强大且安全的RAG流水线的部署，支持GenAI的采用，同时最大限度地降低了与这些早期技术相关的风险。