大規模な​社内文書を​扱うRAG

初期構成では、実験とパイプラインにVertex AI、文書処理とチェーン制御にLangChain、生成にGeminiとPaLM、ベクトルストアにQdrantを使用しました。元資料がイタリア語であるため、多言語エンベディングモデルを選んでいます。

取り込みと評価

文書はCloud Storageに置き、Vertex AI Pipelinesで取り込み、段落とサブチャンクへの分割、エンベディング、BM25索引の作成を実行します。評価は別パイプラインに分け、上位15文書での再現率とQ&A精度を測定しました。採用したプロンプト、temperatureなどのパラメータは、推論系から参照できる成果物として保存します。

推論

フロントエンドからバックエンドを呼び出し、そこで検索とプロンプト構成を行います。Qdrantはセマンティック検索とメタデータによる絞り込みを担い、Firestoreには会話履歴を保存します。検索したチャンクをコンテキストへ加え、モデルが回答と参照元を返す構成です。

講演では、独自に組んだ検索層の一部をVertex AI Vector Searchへ置き換える案も挙がりました。当時Vertex AI Searchと呼ばれていた製品は、現在Gemini Enterprise Agent PlatformのAgent Searchへ展開されています。現在の名称と2024年の実装は分けて捉える必要があります。

チームは段落チャンクから質問と回答の組を生成し、学習、検証、テストに使う約2,000問を構成しました。正解データ不足を補う実用的な方法ですが、生成した評価セット自体を確認しなければ、測定対象と同じモデルの誤りを評価側でも繰り返すおそれがあります。

分割は段落境界を優先し、長い段落のみLangChainの反復型スプリッターで細分化しました。意味の異なる複数段落が1チャンクに混ざることを避ける設計です。1,000文字という結果は、この文書集合と質問群で得た値であり、あらゆるRAGに共通する初期値ではありません。

文書数が少ない間は、更新のたびにエンベディング索引を再構築する運用でも対応できます。更新量が増えた段階で、差分取り込みとパラメータ化したパイプラインを導入します。Vertex AI Pipelinesの成果物はCloud Storageへ保存し、Qdrantではチャンクごとのメタデータを保持して検索と絞り込みに利用しました。

文書が更新されたらどうするか

文書集合が小さい間は、エンベディング索引を作り直す方法が単純で確実です。文書数と更新頻度が上がった段階で差分パイプラインを導入し、チャンク分割とエンベディングのパラメータを明示的に管理します。

複雑なスプレッドシートをどう分割するか

Pandasなどで各シートを前処理し、セル同士の意味が残るよう文章や区切り文字を加えて直列化する案が示されました。セルの関係をモデルが読める構造にするには、入力時のプロンプト設計も必要です。

成果物とメタデータをどこへ保存するか

Vertex AI Pipelinesは実験成果物をCloud Storageへ保存します。Qdrantではチャンクと一緒にメタデータを保持できるため、ファイル名以外の条件でもセマンティック検索と絞り込みができます。

補足質問の文脈をどう維持するか

それまでの会話を要約する方法と、会話全体を次のプロンプトへ含める方法が挙げられました。どちらもモデルの入力長に制約され、この部分は検討中と説明されています。

この事例から持ち帰れるのは、個別の数値より検証の進め方です。検索と生成を別々に測り、変更点を一つずつ増やし、総合指標が少し下がっても製品に必要な知識は残します。検証3の用語チャンクは、その判断をよく示しています。

2024年時点の次候補はGemini 1.5 Pro、Vertex AI Auto SxS、Vertex AI Vector Searchでした。現在これらを試す場合は、講演当時の名称や提供状況ではなく、最新のGoogle Cloudドキュメントを出発点にする必要があります。

本稿はMedium版の記事を日英で再編集したものです。アーキテクチャと指標の一次資料は、リンク先の講演です。