Ray Data 與 Docling 解決企業 AI 最大痛點

Zach Anderson
2026年2月27日 16:58

新整合結合了 Ray Data 的分散式處理與 Docling 的文件解析功能,可在數小時內處理超過 10,000 個複雜檔案,用於 RAG 應用程式,而非數天。

建構 AI 應用程式的企業團隊剛獲得了解決最令人沮喪瓶頸的方案。Anyscale 詳細說明了如何結合 Ray Data 與 Docling,將數週的文件處理時間縮短為數小時——這項發展可能加速擁有大量文件檔案的公司的部署時程。

這項技術整合解決了業內人士所稱的檢索增強生成系統中的「資料瓶頸」。雖然示範讓生成式 AI 看起來簡單明瞭,但現實情況涉及處理數千份舊有 PDF、複雜表格和嵌入式圖片,而傳統處理工具對這些內容處理不佳。

實際改變了什麼

Ray Data 的串流執行引擎同時跨 CPU 和 GPU 任務進行資料管線處理。Python 原生架構消除了其他框架在語言環境之間轉換資料時所遭遇的序列化開銷。對於執行批次推論或預處理大規模資料集的團隊而言,這意味著更快的迭代週期。

Docling 處理了大多數傳統工具無法應對的解析複雜性——在保留語義結構的同時準確提取表格和版面配置。與 Ray Data 整合時,每個工作節點在記憶體中執行一個內嵌 AI 模型的 Docling 實例,實現大規模並行文件處理。

架構運作方式如下:Ray Data Driver 管理執行並序列化任務程式碼以進行分發。工作節點直接從儲存讀取資料區塊,並將處理後的 JSON 檔案寫入目的地。驅動程式永遠不會成為瓶頸,因為它不處理實際的資料吞吐量。

Kubernetes 基礎

KubeRay 在 Kubernetes 上編排 Ray 叢集,透明地處理從 10 個到 100 個節點的動態自動擴展。系統包含工作節點故障時的自動恢復功能——對於無法從頭重啟的大型擷取作業至關重要。

端到端流程將文件從物件儲存移動到解析和分塊,在 GPU 節點上生成嵌入向量,並寫入 Milvus 等向量資料庫。RAG 應用程式隨後查詢資料庫以向 LLM 提供情境。

包括 Pinterest、DoorDash 和 Instacart 在內的公司已經使用 Ray Data 進行最後一哩處理和模型訓練,顯示該技術已證明生產可行性。

超越簡單搜尋

這裡更廣泛的策略針對代理式 AI 工作流程,其中自主代理執行多步驟任務。隨著代理依賴精確文件代表使用者行事,處理資料的品質變得更加關鍵。建構可擴展架構的組織現在為具有多個順序 LLM 呼叫的進階推論鏈做好準備。

Red Hat OpenShift AI 和 Anyscale 平台提供符合企業治理要求的部署選項。開源基礎意味著團隊可以在沒有重大採購障礙的情況下開始測試。

對於目前在資料準備上花費的時間多於模型調整的 AI 團隊而言,這項整合提供了一條實用的前進道路。問題不在於分散式文件處理是否重要——而在於您的基礎設施是否能處理接下來會發生的事情。

圖片來源:Shutterstock