突破 RAG 瓶颈：利用 Ray Data 和 Docling 实现可扩展的文档处理

企业团队在构建生成式 AI（gen AI）应用（例如检索增强生成（RAG））时，经常会遇到“数据瓶颈”问题，因为传统的文档处理工具无法高效处理数以千计的复杂文档。这篇博客文章探讨了如何借助统一的基础架构来消除这些障碍，该架构将用于高速流式处理的 Ray Data 与用于精准文档解析的 Docling 相结合。通过在红帽 OpenShift AI 或 Anyscale 等平台上扩展这些工具，企业组织可以在数小时（而不是数天）内将杂乱无章的非结构化数据转化为切实可行的见解，从而为下一波 AI 创新浪潮奠定信任和可靠性的基石。

Anyscale 是 Ray 背后的企业，Ray 是一个分布式计算框架，现已成为 PyTorch 基金会的一部分。Anyscale 还提供 AI 平台。 

红帽 OpenShift AI 为企业组织提供了一个可扩展的平台，用于开发和部署 AI。它利用 KubeRay 在 Kubernetes 上运行 Ray 集群，提供更高的可靠性和自动扩展能力。通过添加用于文档解析的 Docling，OpenShift AI 使团队能够在一个系统上管理各种 CPU 和 GPU 任务。这可以降低开销并加快 AI 应用的交付。 

RAG 数据瓶颈的残酷现实

若只看演示，您可能会觉得生成式 AI 的构建过程十分简单，但数据准备和处理的实际情况要复杂得多。想象一下，您的团队刚刚接手了数万份旧 PDF，而首席执行官希望这些 PDF 能尽快变得可搜索。面对海量的复杂文档（其中许多文档还包含表格和图片），处理环节可能会迅速演变为棘手的瓶颈，需要耗费数周时间才能解决。残酷的现实是，大多数 AI 项目都把绝大部分时间耗费在数据准备上，而非模型训练和调优上。

在许多情况下，RAG 开发过程中面临的最大障碍是：传统数据管道效率低下。 RAG 通过从知识库中检索相关上下文来提升大语言模型（LLM）的响应质量。文档经过处理（解析、分块、嵌入），然后存储在向量数据库中。查询时，系统会检索相关数据块并将它们作为上下文提供给 LLM，由于模型现在基于您所在企业组织的数据生成回答，回答准确性得到提升，如下所示：

传统数据处理框架通常无法满足 AI 的需求，因为它们无法有效协调数据处理流与解析和嵌入文档的不同计算要求。为了扩展 AI，企业团队必须转向统一的基础架构，在单个简化流程中处理 CPU 密集型解析任务和 GPU 密集型嵌入任务。

利用 Ray Data 和 Docling 实现规模化扩展

Ray Data 是专为 AI 和机器学习（ML）工作负载构建的分布式处理库。它的流式执行引擎能够在 CPU 和 GPU 任务之间构建数据传输管道，提升 GPU 利用率，同时保持内存使用量恒定。由于 Ray Data 是 Python 原生的，它消除了在不同语言环境之间转换数据所产生的序列化开销，从而加快了 RAG 管道的迭代周期。

Docling 则负责处理传统工具经常出错的复杂解析，帮助确保您的 AI 获得正确的上下文，进而生成有价值的回答。通过准确解析 PDF 中的表格和布局，Docling 有助于保留使 RAG 检索更加有效的语义结构。与 Ray Data 集成时，每个节点都运行一个 Docling 实例，该实例在内存中嵌入了专家 AI 模型（例如用于处理布局和表格的模型），从而实现高性能的分布式文档处理。

Ray Data 通过将数据集切分为多个数据块，并在集群中流式传输来实现大规模并行处理，从而简化大规模数据处理流程。在这种架构中，Ray Data 驱动程序负责管理执行计划，并序列化任务代码（例如 Docling 处理）以进行分发，而 Ray 工作节点则负责处理实际的计算工作。这些工作节点直接从存储中读取数据块，并将生成的 JSON 文件并行写入目标位置，因此驱动程序永远不会成为瓶颈，如以下架构中所示：

AI 数据处理架构

• Ray 驱动程序：管理 ObjectRef 和执行计划，并将 Docling 代码序列化后分发给各个工作节点。
• 流式数据块：Ray 工作节点直接从输入存储中并行提取数据。
• 并行写入：每个工作节点将处理后的 JSON 输出直接写入存储，因此 Ray 驱动程序不会因数据吞吐量过大而不堪重负。

这一集成方案自动处理了所有分布式计算带来的复杂性，包括调度、故障恢复和内存管理。通过采用异构计算，由 CPU 负责解析，同时由 GPU 负责嵌入数据，从而在整个过程中更高效地利用昂贵的 GPU 资源。

借助红帽 OpenShift AI 实现企业级可靠性

OpenShift AI 通过 KubeRay 提供企业级基础平台，在 Kubernetes 上编排 Ray 集群，并内置可靠性与安全性功能。KubeRay 能够处理运营层面的复杂性，例如动态集群自动扩展、容错机制，以及工作节点故障时的自动恢复。这使得集群能够透明地从 10 个节点扩展到 100 个节点，以满足大型数据提取任务的需求。

端到端流程十分简单，如下图所示：

整个流程大致如下：

1. 文档（例如 PDF）存储在对象存储（例如 S3、PVC）中。
2. OpenShift AI 上的 Ray Data 管道读取这些文档，并将它们分发到各个工作节点。
3. Docling 在工作节点上解析文档，随后进行分块处理以供嵌入模型使用。
4. 在 GPU 节点上生成嵌入向量，并写入到 Milvus 等向量数据库中。
5. RAG 应用查询数据库，将检索到的上下文提供给 LLM，以生成准确的回答。

在 OpenShift AI 上运行，这可确保数据处理工作在 Kubernetes 集群内完成，有助于满足数据驻留要求，并支持在虚拟私有云或本地环境中进行部署。这种统一的基础架构允许您在同一平台上运行数据准备和模型服务，从而降低运营开销。

未来展望：转向代理式解决方案

企业 AI 的未来，取决于能否超越简单的搜索，迈向复杂的代理式解决方案。企业组织必须强化并进一步优化数据管道，以支持多步骤代理式工作流，在这些工作流中，自主代理利用 RAG 和检索增强微调（RAFT）来解决复杂问题。RAG 能够提供实时上下文，而 RAFT 则能“训练”模型更好地忽略不相关的噪声，通过将两者结合，团队能够构建出更准确、更可靠的代理。

当下投资于可扩展架构的企业，将能够更好地实施这些高级推理链，实现多次 LLM 调用的有序执行与最佳的资源分配。转向代理式 AI 这一趋势意味着，所处理数据的质量比以往任何时候都更加重要，因为代理依赖于精准的文档来代表用户执行任务。有了坚实的基础，这些富有创造性的 AI 实施才能达到企业级的一致性和安全标准。

归根结底，我们的目标是让这些 AI 代理能够轻松理解信息并据此采取行动。我们相信，生成式 AI 的成功始于通过具备企业级治理能力的开源基础，让复杂信息变得易于理解和使用。企业若能当下就建立起一个稳健且统一的平台，将有助于其代理式计划创造长期价值，并提升用户的信任度。

结语

红帽 OpenShift AI 和 Anyscale 提供将复杂文档转化为切实可行情报所需的工具。通过利用 Ray Data 和 Docling 消除数据处理瓶颈，我们帮助企业组织专注于最重要的事情，即解决现实世界中的问题。

报名参加 2026 年红帽全球峰会，与我们的团队交流，探索生产级 AI 的未来。您还可以在红帽开发人员沙盒中试用 OpenShift AI，获得全托管环境的 30 免费访问权限，在此环境中您可以测试这些工具。