Ray DataとDoclingが企業AIの最大の課題に取り組む

Zach Anderson
2026/2/27 16:58

新しい統合により、Ray Dataの分散処理とDoclingのドキュメント解析を組み合わせ、RAGアプリケーション向けに10,000以上の複雑なファイルを数日ではなく数時間で処理できるようになりました。

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