この動画は、検索拡張生成（RAG）システムにおける検索精度向上のためのメタデータフィルタリング手法を解説している。従来のRAGシステムでは異なるバージョンの文書から無作為にチャンクが取得されるため、LLMが混乱する問題があった。この課題に対し、LangExtractを使用して非構造化データから構造化メタデータを抽出し、それを用いた検索フィルタリングによって検索精度を大幅に改善する実装方法を具体的なコード例とともに紹介している。
検索拡張生成システムにおける文書バージョン問題
みなはん、検索拡張生成システムでこんな問題見たことあらへん？例えばな、異なるバージョンの文書があったとするやろ。テキストチャンクを作ってベクトルストアに保存するんやけど、クエリとか検索する時に、クエリに基づいてこれら全部の文書からチャンクを取得してまうねん。
そうなるとLLMは混乱してまうんや、だって異なる文書を区別する方法がないからな。簡単な解決策は、各チャンクに信頼できるメタデータを追加することやねん。でも問題は、どうやってそのメタデータを取得するかや。
LangExtractを使った構造化データ抽出
いくつか異なるアプローチがあるんやけど、シンプルなやつの一つは、テキスト文書に存在する非構造化データから直接メタデータを抽出することや。そのためにLangExtractみたいなもんを使えるねん。これは大規模言語モデルの力を使って非構造化データを構造化データに変換してくれるんや。
わしがLangExtractを気に入ってるんは、カスタムスキーマを定義できるからや。メタデータの品質をコントロールしたい時にめっちゃ役立つねん。
前にこれについて詳しい動画を作ったんやけど、今回の動画では検索拡張生成システムにメタデータを追加して、検索精度を向上させる方法を見せたるわ。
GoogleのオープンソースプロジェクトLangExtract
これはGoogleからのオープンソースプロジェクトや。正式なGoogleプロダクトやないけど、Geminiシリーズみたいな強力なLLMを使って非構造化文書から構造化データを抽出するんや。
めっちゃきれいな可視化ツールもついてるねん。最近、Olamaを通して実行できるローカルモデルを含む他のAPIプロバイダーのサポートも追加されたんや。
実装例：メタデータ強化RAGシステム
オーケー、今回の動画では、LangExtractを使って検索拡張生成システムを構築するで。これはメタデータを強化して、ユーザークエリを処理するためにLLMが使用する文書をフィルタリングするんや。
動画の残りの部分では、LangExtractを使って非構造化テキストファイルを構造化メタデータに変換する具体例と、このメタデータを使って検索拡張生成システムの結果をフィルタリングする方法を見ていくで。
セットアップとサンプルデータ準備
いくつかパッケージをインポートせなあかんねん。詳細は動画の説明欄に書いとくで。このコードはGitHubリンクから利用できるようにするわ。でも今は、APIキーを読み込むで。具体的には、Gemini 2.5 Flashを使うから、これが動作するためにはGemini APIキーを取得する必要があるねん。
次に、サンプルデータが必要やな。今回は、わしがサンプルデータを作ったで。いくつか異なる例があるねん。これはAPIリファレンス文書バージョン2.0や。レガシー文書もあるで。これは複数の異なるバージョンを持つ文書の例になるねん。
それから他にもいくつかファイルがあるで。これはストレージサービスガイドと認証エラーのトラブルシューティングガイドや。
これらの非構造化ファイルにはそれぞれID、タイトル、そして生の非構造化テキストがあるねん。これらをチャンクや文書として考えてや。
LangExtract処理パイプライン構築
次に、メイン処理パイプラインを作るで。このために、FixedLangExtractProcessorというクラスを作ったんや。これは、ユーザー定義スキーマに基づいて生テキストを構造化データに変換するLangExtractパイプラインを作成するベースになるねん。
これが一番重要な部分やで、メタデータの品質は抽出パイプラインがどれだけ良いかに依存するからな。LangExtractの動作をよく理解するために、前の動画も見てみてや。
抽出に必要な3つの要素
基本的に、3つの情報が必要やねん。一つは生テキスト。二つ目は、この生テキストから情報を抽出するスキーマを持つLLM呼び出し。
三つ目に提供する必要がある情報は、その構造化データが実際にどのように見えるかの非常に良い少数ショット例やねん。
ここが今回の例で使うプロンプトの例や。技術文書でこれらの特定のフィールドを抽出するで。サービス名、バージョン番号、文書カテゴリ、重複アイテムのレート制限が必要やねん。
これは具体的な使用ケースに大きく依存するねん。LLMがより良いメタデータを抽出するのを助けるために、少数ショット例も提供するで。
少数ショット例の重要性
これは、LLMに入力される例文書や例テキストやねん。ここから複数の異なることを抽出したいねん。サービスクラス、これがサービス名の抽出テキストで、この特定のフィールドに対して抽出される内容や。これらはデータから抽出したいアイテムやキーに対応してるねん。
例えば、バージョン名では支払いAPIバージョン3.0があると思うで。必要な情報は全て、この例文書や例テキストで提供されるんや。
メタデータ抽出の実行
次に、作成するLangExtractオブジェクトを通して文書を渡すで。ここにあるプロンプトと例を提供するねん。それから使いたいLLMを指定するんや。今はデフォルトでGemini 2.5 Flashを使いたいねん。でも他のプロプライエタリAPIやローカルモデルも使えるで。
抽出パスも設定できるねん。デフォルトでは1か2に設定するわ。パス数に関連するコストも考慮してや。パス数を増やすと、より多くのAPI呼び出しをすることになるけど、結果はもっと正確になるで。
外部ソースから来る文書をプロンプトと一緒に渡して、メタデータを抽出するんや。
データの正規化と処理
他にもいくつかの関数があって、データの正規化を確実にしてるねん。欠損フィールドがあれば、適切なデフォルト値を持てるようにしてるで。すべてが失敗した場合の正規表現ベースの抽出もあるねん。
一般的には、このメタデータ抽出を文書レベルで実行して、このメタデータを使ってチャンクを強化したいねん。
ベクトルストアへの統合
メタデータ抽出メカニズムができたら、次のステップは既存のチャンクにこのメタデータを追加して、ベクトルストアに保存することや。
これは、作成するメタデータと一緒にベクトルストアの作成とドキュメントの追加を担当するクラスやねん。すべての文書に対して、対応するメタデータフィルターを追加するんや。
この関数はクエリからメタデータフィルターを抽出するだけや。この例のセットアップでは、埋め込みベースのセマンティック検索は行ってへん。でも、特定のメタデータフィルターに基づいて初期検索を行って、フィルタリングされた文書に対して密な埋め込みベースの検索を使用する階層的アプローチでこれを使用する方法を見せたいねん。
そうすると検索空間を削減できるで。
メイン比較ループの実装
最後に、メイン比較ループを追加するねん。どのように動作するか説明したるわ。
まず、すべてのサンプル文書を読み込むで。次に、提供した文書からすべてのメタデータを抽出する抽出器を作るねん。すべてを正規化するで。欠損部分や欠損メタデータがあれば、それを補完するんや。
それからベクトルストアを作成して、文書をベクトルストアに追加するねん。メタデータによるフィルタリングと、それなしの両方で実行する4つの例クエリがあるで。今回は検索部分の実行方法だけを見せてるねん。これらの文書を後続の生成のためにLLMに渡すことができるで。
それぞれの場合で、作成するフィルターと、メタデータ抽出ありとなしの両方で返される文書を見るねん。
実行結果の分析
python lang_extract_rag.pyを実行するで。これが作成した例のPythonファイルや。プロセス全体を見てみよう。
最初に文書を読み込んで、今LangExtractを使ってメタデータ抽出を実行してるねん。これらはかなり小さい文書やから、それぞれに対して単一のチャンクが表示されるで。
最初の文書では5つの異なるエンティティを抽出した。2番目でも5つのエンティティを抽出。3番目では3つのエンティティ。最後の一つでもやっぱり3つのエンティティや。
これらがどのように見えるかを見てみよう。2番目の文書のサービスバージョンタイプはこんな感じや。タイプはリファレンス、バージョンは1.0や。これが3番目の文書。それから4番目の文書がある。
トラブルシューティングガイドで欠損してるバージョンの正規化を行ったから、デフォルトバージョンを割り当ててるねん。
クエリ結果の比較分析
でも結果を見てみよう。最初の質問は「バージョン2.0でOAuthを使って認証する方法は？」やった。小さなフィルターで。最初に生成されたのはバージョン2.0で、2番目のフィルターはサービスや。
それからバージョン2.0プラス認証APIのサービスを持つ文書があるねん。ここが実際に作成されたメタデータや。これらを使って文書をフィルタリングするから、結果的にこれが最終的な応答生成のためにLLMに渡される唯一の文書になるねん。
このメタデータベースのフィルタリングを使わへんかったら、4つの文書になってしまうねん。
2番目の質問は「認証のレート制限は何？」や。再びスマートフィルターで、認証サービスについて話してることがわかったねん。今回はAPIバージョンが欠損してるやろ？やから両方のバージョンを取得するけど、サービスタイプがあるから検索空間を4文書ではなく3文書に削減できるねん。
フィルターなしやと、また全部の文書を使うことになるで。
「401エラーをトラブルシューティングする方法は？」では、文書タイプがトラブルシューティングで、モデルが適切なフィルターを作成できてるねん。また検索空間を削減してるで。
同様に、4番目の質問では、これはストレージサービスや。この例では、モデルがLangExtractを使って適切なフィルターを作成できてることがわかるねん。
検索空間を3文書に削減できる例みたいなやつでは、まだ二次的な密な埋め込み空間やマルチベクトル表現ベースの検索システムが必要やけど、適切なメタデータフィルターを使うことで処理するデータ量を削減できて役に立つねん。
まとめ
これが、メタデータ生成のためのLangExtractみたいなシステムと、その後のフィルタリングを使う簡単な例やったで。コードは説明欄で利用できるようにするで。動画が気に入ったら、チャンネル登録を忘れんといてや。
とにかく、この動画が役に立ったと思ってもらえたら嬉しいわ。見てくれてありがとう、そしていつものように、次の動画でまた会おうな。
コメント