【ITニュース解説】Building an Enterprise GenAI Platform on OCI — Part 2: The Data Pipeline Nobody Talks About

大規模言語モデル（LLM）と検索拡張生成（RAG）システムを用いた企業向けAIプラットフォームを構築する際、多くの人がまずモデルや埋め込み（エンベディング）に注目しがちだが、実際にはその前段階にある「データパイプライン」の品質が、最終的なAIシステムの性能を決定する重要な要素となる。この経験は、理想的な設計図からすぐにベクトル生成へ進もうとしたときに直面した、7万を超える大量のドキュメントを限られた計算資源で確実に処理するという基本的な問題から始まった。

RAGシステムを構築する際には、多くの場合「ドキュメント → 埋め込み → ベクトルデータベース → LLM」という流れを想像する。しかし、この「ドキュメント」はどこから来たのか、7万ものドキュメントをどのように扱うのか、処理中にシステムが停止したらどうなるのか、埋め込み戦略が変わった場合に再処理はどうするのかといった、多くのデータライフサイクルに関する問題が浮上する。そのため、パイプラインを複数の独立したステージに分離し、各ステージが次のステージで利用できる成果物を生成するように設計する判断が非常に重要になった。

最初のステージはデータ収集である。DevOpsアシスタントのための技術知識を集めるため、OCI Computeインスタンスを使ってウェブスクレイピングを行った。ここで重要な決定は、Computeインスタンスをデータの永続的な保存場所としないことだった。Computeインスタンスは一時的なものであり、停止したりディスク容量に制限があったり、アプリケーションが変更されたり、パイプラインが失敗する可能性を考慮し、知識ベースのデータはそれらの機械に依存せず存続させる必要があった。そのため、OCI Object Storageをデータの永続化層として採用した。

データをComputeインスタンスのローカルディスクに保存する単純な方法は、プロトタイプ段階では手軽に見える。しかし、データの事前処理をOCI Data Scienceのような別のサービスへ移行する場合、ファイルの転送やストレージのマウント、エンドポイントの公開といった複雑な作業が発生する。そこで、ComputeインスタンスとData Scienceサービスが直接互いのことを知る必要がなく、OCI Object Storageを介してデータをやり取りする「疎結合」のアーキテクチャを採用した。これにより、各サービスが独立して進化できる柔軟なシステムが構築できた。

また、限られたComputeインスタンスのリソースに対応するため、数千のドキュメントを一度にメモリにロードするのではなく、ドキュメントを一つずつ処理し、クリーンアップ後にすぐにObject Storageにアップロードする「ストリーミング」処理を採用した。これにより、データセットのサイズに関わらず、メモリ使用量を一定に保つことができ、大規模データ処理における安定性を確保した。

OCI Object Storageは単なるファイル置き場ではなく、データパイプラインの異なるステージを繋ぐ「データバックボーン」として機能した。datasets/（生の取り込みデータ）、processed/（クリーンアップされチャンク化されたドキュメント）、features/（埋め込み生成物）といったプレフィックスを使い、データライフサイクルの各ステージを論理的に分離した。この中で特に重要だったのが「生データは決して変更しない」というルールである。処理ロジックが変わっても、元のデータセットを再スクレイピングすることなく、何度でも再処理できるようにすることで、パイプラインの再現性を確保した。

次に、取得したドキュメントをLLMが扱いやすい形に分割する「チャンク化」の工程に進んだ。LLMは非常に長いドキュメント全体を受け取るよりも、関連する情報を集約した小さな意味単位である「チャンク」の方が効率的に処理できるため、不必要なコンテキストの削減やトークン消費の抑制、推論の遅延短縮に繋がる。チャンクのサイズや、隣接するチャンク間で情報を少し重複させる「チャンクオーバーラップ」は、コンテキストを適切に保ちつつノイズを減らす上で重要であり、これらも最適な設定はドキュメントの種類や利用するモデルによって異なるトレードオフの関係にある。

7万ものチャンクを処理する段階では、少数のドキュメントでは問題なかったコードが、大量データでは通用しないことが明らかになった。全てのチャンクを一度にメモリにロードするのではなく、数百程度の小さな「バッチ（グループ）」に分割して順次処理する「バッチ処理」の採用が必須となった。これにより、常に処理対象のデータ量を一定に保ち、限られたインフラでも大規模データを安定して処理できるようになった。

パイプラインの進行中に、7万のチャンクが生成されたはずなのに、次のステージでは1000のチャンクしか認識されていないという予期せぬ問題が発生した。これはAIや埋め込みモデルの問題ではなく、クラウドAPIが大量のレスポンスを一度に返さず、分割して返す「ページネーション」という基本的な仕組みを実装し忘れていたことが原因だった。APIからのデータ取得時に全てのページを辿っていなかったため、データが途中で途切れてしまっていたのだ。この経験から、各ステージで処理されたレコード数や生成された成果物の数を検証する「データ品質チェック」の重要性を痛感した。入力と出力の数を比較するだけでも、目に見えない論理的なエラーを防ぎ、システムの健全性を保つ上で非常に有効な手段となる。

処理が複雑かつ重くなるにつれて、データ収集（スクレイピング）とデータ変換（事前処理）を同じComputeインスタンスで行うのではなく、それぞれに適したOCI Data Scienceのようなサービスに役割を分担させる「責務の分離」の必要性が高まった。これにより、各サービスが最適なリソースで効率的に稼働できるようになった。さらに、複数のOCIサービスが連携するようになると、サービス間の認証と認可を管理する「IAM（Identity and Access Management）」が設計に不可欠となる。設定ファイルに直接認証情報を書く代わりに、OCIリソース自体にIDを付与し、IAMポリシーでアクセス権限を管理する「リソースプリンシパル」の活用は、クラウドネイティブなワークロードにおいてセキュリティと管理性を向上させる。

ここまで見てきたように、LLMが実際に動く前に、データ取り込み、永続化、疎結合、生データの不変性、チャンク化、バッチ処理、ページネーション、データ検証、リソース分離、IAMといった、AIそのものとは異なる多くのデータエンジニアリング上の課題を解決してきた。RAGシステムはAIの問題であると同時に、データエンジニアリングの問題でもある。LLMの応答品質は、その前段階にある「データの品質」に強く依存している。欠落したデータや誤って切り詰められたデータは、いくら高性能なモデルや複雑なプロンプトエンジニアリングを使っても修正できない。

このプロジェクトを通じて、データパイプラインにおけるOCI Object Storageをアーキテクチャ上の境界として扱うこと、生データを変更せずに不変に保つこと、バッチ処理でメモリ使用量を制御すること、APIのページネーションを見落とさないこと、各ステージで入出力数を検証すること、ワークロードを責務に応じて分離すること、そしてクラウドのIAMをアプリケーションアーキテクチャの一部として扱うことの重要性を深く学んだ。これらの基礎が確立されて初めて、私たちは「言葉」を「ベクトル」に変換し、意味に基づいた検索を可能にする、より高度なAIの領域へと進むことができる。