AutoRAG pipeline optimization in Red Hat OpenShift AI

Red Hat OpenShift AI中的AutoRAG流程优化

组件 | 文章简介

2026年9月22日

7分钟阅读

人工智能

Matt Sykes

AI事业部产品市场经理

子模式 | 社交分享集

组件 | 社交分享

分享

子模式 | 订阅

组件 | 社交图标

订阅RSS

组件 | 图标

© Red Hat, Inc. CC-BY-4.0授权

子模式 | 结果导航

组布局

组件 | 导航链接

• 返回所有文章

组件 | 通用内容

如果你是AI或机器学习工程师，你一定见过经典演示：将一份干净的PDF导入原型，使用标准教程代码构建向量数据库索引，然后提交一个简单问题。模型返回完美答案，众人点头，项目随即获批。

然后它会遭遇企业现实。

生产环境运行六个月后，当知识库扩展到数千份多列技术手册、表格财务报告、扫描法律合同和不断变化的内部政策时，检索准确性急剧下降。用户开始截图捕捉细微的幻觉，答案跳过关键技术限制，基础设施成本上升引发平台工程团队的警报。

在修复准确性下降的压力下，工程团队往往选择最简单的方案：扩大检索范围。他们加倍增加分块大小，提取20个候选片段，用昂贵的前沿大型语言模型（LLMs）替换紧凑型模型，希望单纯扩大规模就能解决问题。

系统并未明显变得更智能。相反，延迟激增，GPU内存使用量飙升，模型准确性下降。这种在准确性与不断上升的计算成本之间艰难权衡的困境，是企业级检索增强生成（RAG）的主要瓶颈。

要解决RAG退化问题，需要在索引和检索架构上进行实证测试。在本指南中，我们将探讨企业级RAG性能为何崩溃，以及膨胀的上下文窗口如何推高GPU账单。然后，我们将分析Red Hat OpenShift AI中通过AutoRAG实现的自动化流程优化，如何帮助你在不超额消耗计算资源的情况下提升目标准确性。

如果你想探索底层代码和架构蓝图，请查阅我们的技术电子书《面向企业的RAG工程》。

企业数据现实与演示幻象的对比

标准教程假设一个简单线性流程：

图1：图示基本线性RAG流程中的文档摄入、向量嵌入和提示生成

这假设数据是干净的，答案存在于单一文本块中，更多上下文意味着更好答案。企业数据打破了这三项假设：

• 复杂文档布局：基础解析器将多列布局扁平化为混乱文本。多页表格丢失行列关联，扫描页面则完全缺乏文本层。

• 上下文碎片化：答案很少出现在单一片段中。解决单个查询通常需要从入职指南、法律备忘录和技术规格中整合事实。

• 快速变化的知识：企业数据持续更新。静态嵌入和未管理的向量存储会迅速暴露过时或矛盾的细节。

为何扩大上下文会破坏质量和预算

当流程失效时，扩大上下文窗口会触发两种主要故障模式：

注意力退化

大语言模型（LLMs）通过注意力机制处理标记。将过大且相关性较低的文本块填充到上下文窗口中会引入上下文噪声。模型存在位置偏差问题，当关键信息位于提示的开头或结尾时表现优于被埋藏在中间时。

尽管近期的长上下文模型在处理简单事实查询方面有所改进，但位置偏差仍会损害性能，尤其当答案需要整合窗口中分散的多个事实时。Databricks的可验证研究证实，随着上下文超出理想阈值，大多数模型的RAG准确性会出现下降。

刘等人发现，扩展上下文窗口的模型并未比短窗口模型更稳健地利用这些窗口。后续的多针检索研究显示，当前前沿模型在长上下文中处理单一事实查询表现优异，但当答案需要整合窗口中分散的多个事实时，性能下降问题依然存在。

财务和延迟影响（键值（KV）缓存经济学）

模型在生成输出前需要处理每个提示标记，导致首个令牌生成时间（TTFT）增加。将上下文从384个标记扩展到16,000个标记会显著消耗GPU上的KV缓存内存，减少可用缓存空间，迫使团队需要部署更大规模的多GPU集群以维持基本并发性。

如Anthropic在《Introducing Contextual Retrieval》研究中指出，强行扩展上下文窗口会显著增加查询成本和延迟，但无法保证检索准确性提升。保持提示上下文紧凑并使用针对性的块优化，可显著提高每GPU的请求吞吐量，大幅降低推理成本。

解耦的RAG管道架构：三管道设计

为防止计算浪费和质量下降，将RAG拆分为三个独立管道：

• 索引管道（批量/定时）：解析原始文件，提取元数据，标准化布局，分割内容，生成嵌入向量并填充向量库。使用Docling将复杂布局转换为结构化Markdown。

• 检索管道（持续/实时）：执行查询时的混合搜索（密集向量和稀疏关键词），重排候选结果，实施基于角色的访问控制（RBAC），构建提示并运行模型生成。基于vLLM、llm-d（用于分布式KV缓存感知推理路由）和AI防护机制构建。

• 维护管道（事件驱动/持续）：在后台持续运行，处理更新、删除、被遗忘权（RTBF）请求、重新嵌入以及使用MLflow进行语料库漂移检测。

图2：Red Hat解耦的索引、检索和维护RAG管道架构图。

RAG评估指标测量

评估企业级RAG时很快会遇到复杂性。仅抽查几个样本提示无法扩展——你需要客观可复现的数据集来衡量实际进展。Red Hat AI中的Gen AI studio使用AutoRAG自动化质量测量，覆盖三个核心生产指标：

• 上下文正确性：衡量检索到的块是否包含必要事实且不包含过多噪声。低分值表明存在索引问题，如布局解析失败、块大小不优或嵌入模型不匹配。

• 答案忠实度：衡量生成输出是否严格基于检索到的上下文，而没有产生幻觉。当忠实度得分较低但上下文正确性得分较高时，表明提示构造或模型推理能力存在问题。

• 答案正确性：衡量输出是否直接回应用户意图，并与真实事实准确对应。

由于忠实度和正确性等指标依赖LLM作为评判者，选择合适的模型并监控评判者偏移是关键的运维任务。Red Hat AI整合了EvalHub（评估控制平面）、LM-Eval（基准框架）和SDG Hub（合成数据生成）以在不同运行中标准化这些测量。

借助AutoRAG的实证优化

手动调整解析方式、分块大小、嵌入模型、混合比例、重排序候选项和LLM的流水线会产生数百种独特组合。手动测试这些组合需要数月时间，迫使许多团队只能发布未经优化的默认配置。

Red Hat OpenShift AI 3.5（通过gen AI studio）中的AutoRAG自动化了这一工作流程。

AutoRAG执行步骤

• 上传数据：上传具有代表性的文档和评估数据集（手动创建或通过SDG Hub生成）。此过程的结果将形成未来测试和验证的基准线。

• 定义约束条件：选择候选基础模型、嵌入选项以及目标延迟或成本限制。此步骤确定了平衡性能、速度和预算的关键运营边界条件。

• 自动搜索：AutoRAG在解析、分块、嵌入、混合搜索、重排序和生成设置之间测试组合。这种自动化搜索生成丰富的多候选性能数据，以突出显示在各项指标上表现最佳的配置。

• 帕累托前沿分析：显示一个对比排行榜，将准确性与计算成本和延迟进行映射。这种排名可视化帮助工程师更快地做出数据驱动的架构权衡决策。

在无需猜测的情况下评估流水线权衡

在查看帕累托前沿的候选配置时，低成本选项值得仔细检查。某种流水线配置可能在计算成本的几分之一内实现高答案忠实度，这在纸面上看起来很有吸引力。然而，答案忠实度仅衡量输出是否基于检索器提供的上下文；它不衡量该上下文是否包含正确的事实。

当高答案忠实度与低上下文正确性结合时，系统会发生静默检索失败：检索器返回了错误的段落，模型基于这些有缺陷的段落忠实地生成答案。输出看起来良好，似乎有充分依据，但最终是错误的。这是最可能逃过初步检测的故障模式，这就是为什么必须将答案正确性与忠实度一起评估，以捕捉到幻觉或错误的结论。

查询经济学的动态

在企业部署中，查询成本取决于整个推理生命周期中的总计算消耗：

• GPU计算小时数（自托管）：在OpenShift AI上运行嵌入模型、交叉编码重排序器和生成基础模型所需的硬件资源。

• 上下文令牌体积：过大的数据块在每次请求中会额外处理数千个提示词。这会增加KV缓存内存使用量，降低请求并发性，并显著增加每个查询的GPU处理时间。

结合精确的小块数据与交叉编码器重排序器的配置方案，能持续提供更优的成本效益。通过在信息到达主LLM前过滤无关上下文，这些流程显著减少输入令牌数量，在降低GPU内存占用和延迟的同时，提升整体答案质量并降低每条回复的成本。

使用RAFT和智能体工作流进行模型定制

当下文准确性较高但答案忠实度仍较低时，LLM面前已有正确的事实信息，但缺乏解读这些信息的领域逻辑。这意味着当提示工程达到极限时，需要进行模型定制。

检索增强微调（RAFT）通过将查询与相关数据块及有意设置的干扰数据块结合进行模型训练。模型学会提取相关信息并忽略无关噪声，从而提升对检索上下文的推理准确性。该流程使用SDG Hub（数据合成）、Training Hub（分布式微调或低秩适应（LoRA））和EvalHub（预推广评估）。

在使用ReAct（思考、行动、观察）等模式的自主智能体RAG工作流中，上下文窗口效率变得更加关键。每次检索到的观察结果都会追加到提示历史中。一个智能体连续进行5次检索调用时，每次迭代都需要重新处理不断扩展的提示历史。没有前缀缓存机制时，每次操作的预填充计算成本都会急剧上升。AutoRAG帮助每次检索调用传递紧凑且高精度的上下文，有效控制上下文增长。

要使这些解耦架构投入运行，企业团队通常会将职责分配给三个关键角色：

• 平台工程师（AI Hub）：管理GPU分配，使用llm-d进行分布式服务，配置RBAC，以及维护Open Container Initiative（OCI）审计工件。

• AI工程师（gen AI studio）：连接企业数据，使用Docling构建解析流水线，并运行AutoRAG优化。

• 机器学习工程师：将流水线自动化并扩展到生产环境，在MLflow中跟踪实验运行，通过AI防护机制执行安全策略，并监控语料库和模型漂移。

下一步行动

企业级AI的生产部署需要超越手动猜测和臃肿的上下文窗口。通过采用解耦的三流水线架构、建立持续的实证评估，并在Red Hat OpenShift AI 3.5中通过AutoRAG自动化流水线配置，您可以在控制计算成本的同时提供高精度答案。

在部署前想了解经过验证的实践经验？请阅读《Hope, Crash, Iterate：一位产品经理的AutoRAG之旅（第一部分）》，获取关于避免常见陷阱和构建AutoRAG工作流的实际经验的精彩第一手资料。

要开始评估上下文权衡并构建解耦的RAG流水线，请在gen AI studio中体验交互式AutoRAG演示。如需完整的技术蓝图，涵盖Docling的布局感知解析、指标驱动的评估工具、RAFT模型微调以及逐步的AutoRAG优化，请下载我们的电子书《为企业构建RAG：工程实践》。

Block | Dynamic pattern deluxe promo

Component | Band_header

Resource

适应性企业：为何AI准备等同于变革准备

这本电子书由Red Hat首席运营官兼首席安全官Michael Ferris撰写，帮助IT领导者应对当前面临的AI驱动的技术变革速度和颠覆性挑战。

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

获取资源

Deluxe mbox

Component | Card_header

关于作者

Subpattern | speaker

Card layout

Component | Image_embed

Component | Person

Matt Sykes

Subpattern | social_links

Matt目前在Red Hat人工智能事业部的产品营销团队任职，通过创意营销可视化塑造技术叙事。他负责现场沟通，并担任Red Hat人工智能博客和通讯的战略负责人，将复杂的AI功能转化为清晰且引人入胜的视觉内容。

在加入Red Hat之前，Matt曾领导Chatterbox Labs的营销、用户体验和设计团队，直至2025年12月被Red Hat收购。他专长于将设计与故事结合，使企业AI更加直观易用。

更多该作者的作品

类似内容推荐

Dynamic pattern

Blog post

为何Red Hat要通过OpenClaw Enterprise构建企业代理的开放基础

网络运维的智能体AI：基于成熟自动化做出更明智决策

Original podcast

Red Hat如何为可扩展AI清除IT债务

使用PyTorch标准化AI堆栈

Subpattern | card_flex

Subpattern | text_basic

继续探索

• 什么是智能体AI？文章

• 预测性AI与生成性AI对比 文章

• 构建生产级AI/ML环境的关键考量 电子书

• Ansible方式的生成性AI 视频

• 通过现代应用平台实现创新与转型 电子书

Keep Exploring mbox

Subpattern | simple_text

按频道浏览

查看所有频道

Pattern | raw_html

自动化

关于IT自动化在技术、团队和环境中的最新动态

人工智能

关于使客户能够随时随地运行AI工作负载的平台的最新消息

混合云

探索我们如何通过混合云构建更灵活的未来

安全

关于我们在不同环境和技术中降低风险的最新进展

边缘计算

关于简化边缘操作平台的最新动态

基础设施

关于全球领先的企业级Linux平台的最新消息

应用程序

深入了解我们解决最复杂应用挑战的方案

虚拟化

关于您本地或跨云工作负载的企业级虚拟化未来