2024年半ばには、感動と興奮をもたらすAIデモの作成は簡単になるでしょう。優秀な開発者、巧妙なプロンプト実験、そして強力な基盤モデルへのいくつかのAPI呼び出しがあれば、午後のうちに特注のAIボットを構築できることがよくあります。次のようなライブラリを追加します。ランチェーンまたはラマインデックスRAG を使用してカスタム データを追加することで、LLM を拡張できます。午後の作業が週末のプロジェクトになるかもしれません。

ただし、本番環境に移行するのは別の問題です。信頼性が高く、観察可能で、調整可能で、パフォーマンスの高い大規模なシステムが必要になります。人為的なデモ シナリオを超えて、実際の顧客行動の全範囲を表すより広範なプロンプトに対するアプリケーションの応答を考慮することが不可欠です。LLM は、事前トレーニング データセットに含まれていないことが多い、ドメイン固有の豊富な知識コーパスにアクセスする必要がある場合があります。最後に、精度が重要なユース ケースに AI を適用する場合は、幻覚を検出、監視、および軽減する必要があります。

これらすべての問題を解決するのは困難に思えるかもしれませんが、RAG ベースのアプリケーションをそれぞれの概念的な部分に分解し、必要に応じてそれぞれをターゲットを絞った反復的なアプローチで改善することで、より管理しやすくなります。この記事は、まさにそれを行うのに役立ちます。この記事では、取得時に下流で発生する手法ではなく、RAG ドキュメント処理パイプラインを作成するために使用される手法にのみ焦点を当てます。そうすることで、生成 AI アプリケーション開発者がプロトタイプから実稼働までの道のりに適切に備えられるように支援することを目指しています。

現代のデータレイク: AI インフラストラクチャの重心

AI の時代では、データが堀であるとよく言われます。そのため、本番レベルの RAG アプリケーションを構築するには、独自のコーパスを構成する大量のデータを保存、バージョン管理、処理、評価、およびクエリするための適切なデータ インフラストラクチャが必要です。MinIO は AI に対してデータ ファーストのアプローチを採用しているため、このタイプのプロジェクトに対するデフォルトの初期インフラストラクチャの推奨事項は、最新のデータ レイクとベクター データベースをセットアップすることです。途中で他の補助ツールを接続する必要がある場合もありますが、これら 2 つのインフラストラクチャ ユニットは基礎的なものです。これらは、RAG アプリケーションを本番環境に導入する際にその後に発生するほぼすべてのタスクの中心として機能します。

MinIO上に構築された最新のデータレイクリファレンスアーキテクチャは、 こここのアーキテクチャがすべてのAI/MLワークロードをどのようにサポートするかを示す関連論文は、 ここ。

RAG: ドキュメント パイプラインの手順

評価

実稼働レベルの RAG アプリケーションを構築するための重要な初期ステップは、評価フレームワーク (単に eval と呼ばれることが多い) を設定することです。eval がなければ、システムのパフォーマンスがどの程度優れているかを確実に把握したり、どのコンポーネントを調整する必要があるかを把握したり、実際に進歩しているかどうかを判断したりすることはできません。さらに、eval は、解決しようとしている問題を明確にするための強制機能として機能します。最も一般的な評価手法は次のとおりです。

• ヒューリスティックなコードベースの評価- 出力トークン数、キーワードの有無、JSON の有効性など、さまざまな基準を使用してプログラムで出力をスコアリングします。これらは、従来のユニット テスト用の正規表現とアサーション ライブラリを使用して決定論的に評価できることがよくあります。

  
  

• アルゴリズム コードベースの評価- さまざまなよく知られたデータ サイエンス メトリックを使用して出力をスコアリングします。たとえば、プロンプトをランキングの問題として再構成することで、正規化割引累積ゲイン (NDCG) や平均逆順位 (MRR) などの推奨システムの一般的なスコアリング関数を使用できます。逆に、プロンプトを分類の問題としてフレーム化できる場合は、精度、再現率、F1 スコアが適切である可能性があります。最後に、BLEU、ROUGE、セマンティック回答類似性 (SAS) などの尺度を使用して、セマンティック出力を既知のグラウンド トゥルースと比較できます。

  
  

• モデルベースの評価- 1つのモデルを使用して別のモデルの出力をスコアリングします。裁判官としてのLLMの審査論文。この手法は人気が高まっており、スケールアップも人間よりもはるかに安価です。ただし、プロジェクトをプロトタイプから本番環境に移行する初期段階では、評価者 (この場合、法学修士) が基盤システム自体と同様の制限やバイアスの影響を受けることが多いため、確実に実装するのは難しい場合があります。この分野の研究、ツール、ベスト プラクティスは急速に進化しているので、注意深く見守ってください。

  
  

• 人間による評価- ドメインの専門家である人間に最善の回答を求めるのが、一般的には最も効果的な方法です。この方法は時間がかかり、費用もかかりますが、洞察力を得たり、初期評価データセットを構築したりするのに非常に役立つため、無視すべきではありません。作業からさらに効果を得たい場合には、自動評価を正しく行う人間の専門家が生成した評価を合成バリエーションで補足する論文。

どの評価手法を使用するかを決定する際には、カスタムベンチマーク評価データセット（Hugging Faceのリーダーボードでよく使用される一般的なデータセット）の作成を検討してください。 MMLUデータセットだけでは不十分です。カスタム評価データセットには、ドメイン固有で実際の顧客がアプリケーションに入力するプロンプトの種類を代表するさまざまなプロンプトとその理想的な応答が含まれます。理想的には、評価データセットの作成を支援できる人間の専門家が利用できますが、利用できない場合は自分で作成することを検討してください。どのようなプロンプトが想定されるかを推測することに自信がない場合は、動作仮説を立てて、それが検証されたものとして先に進みます。後でより多くのデータが利用可能になったら、仮説を継続的に修正できます。

評価データセットの各行の入力プロンプトに制約を適用して、LLMが具体的な判断タイプ（バイナリ、カテゴリ、ランキング、数値、テキスト）で応答するようにすることを検討してください。判断タイプを組み合わせることで、評価を適度に多様化し、出力の偏りを減らすことができます。他の条件が同じであれば、評価テストケースが多いほど良いですが、この段階では量よりも質に重点を置くことをお勧めします。 LIMA: 調整には少ないほど良いこの論文では、1,000 行の小さな評価データセットでも、それが実際のより広い母集団の代表的なサンプルであれば、出力の品質を大幅に向上できることが示唆されています。RAG アプリケーションでは、数十から数百行で構成される評価データセットを使用することで、パフォーマンスが向上することが実証されています。

アドホックベースで手動で評価を開始することもできますが、評価スコアリングプロセスの実行を自動化するためにCI/CDパイプラインを実装するまでにあまり長く待たないでください。毎日、またはソースコードリポジトリと監視ツールに接続されたトリガーで評価を実行することは、一般的にML-opsのベストプラクティスと考えられています。次のようなオープンソースのRAG評価フレームワークの使用を検討してください。ラガまたはディープエバルすぐに使い始めるのに役立ちます。データ レイクを、バージョン管理された評価データセットと、評価が実行されるたびに生成されるさまざまな出力メトリックの両方を含むテーブルの信頼できるソースとして使用します。このデータは、プロジェクトの後半で戦略的かつ的を絞った改善を行うために役立つ貴重な洞察を提供します。

データ抽出装置

最初にプロトタイプ作成を開始するときに使用する RAG コーパスは、実稼働環境に到達するのに十分であることはほとんどありません。LLM が幻覚、省略、問題のある種類のバイアスを削減できるように、コーパスを継続的に追加データで拡張する必要がある可能性があります。これは通常、上流データを下流のドキュメント パイプラインでさらに処理できる形式に変換する抽出器とローダーを構築することによって、ケースバイケースで行われます。

必要以上のデータを収集して大海を沸騰させようとするリスクはわずかにありますが、会社がアクセスできる質の高い情報のソースについて、独創的で既成概念にとらわれない考え方をすることが重要です。明らかな可能性としては、企業の OLTP やデータ ウェアハウスに保存されている構造化データから洞察を抽出することが挙げられます。適切に匿名化され、機密情報が除去されている限り、企業のブログ投稿、ホワイト ペーパー、公開された調査、顧客サポートの問い合わせなどのソースも検討する必要があります。たとえ少量でも質の高いドメイン内データをコーパスに追加することによるパフォーマンスへのプラスの影響は、いくら強調してもし過ぎることはありません。そのため、時間をかけて探索、実験、反復することを恐れないでください。ここでは、質の高いドメイン内コーパスをブートストラップするためによく使用される手法をいくつか紹介します。

• ドキュメント抽出- 独自の PDF、オフィス ドキュメント、プレゼンテーション、マークダウン ファイルは、豊富な情報源になります。このデータを抽出するためのオープン ソースおよび SaaS ツールの広範なエコシステムが存在します。一般的に、データ抽出ツールは、ファイル タイプ固有 (JSON、CSV、docx など)、OCR ベース、または機械学習とコンピューター ビジョン アルゴリズムを活用しています。最初はシンプルに開始し、必要に応じて複雑さを追加します。

  
  

• API 抽出- パブリック API とプライベート API は、ドメイン内知識の豊富なソースになります。さらに、適切に設計された JSON および XML ベースの Web API にはすでにいくつかの構造が組み込まれているため、ペイロード内の関連プロパティをターゲットに抽出し、無関係と見なされるものを破棄することが容易になります。手頃な価格のローコードおよびノーコードの API コネクタの広大なエコシステムが存在するため、使用する API ごとにカスタム ETL を作成する必要がなくなります。これは、専任のデータ エンジニア チームなしでは維持および拡張が難しいアプローチです。

  
  

• Web スクレイパー- Web ページは、ツリーのような DOM 構造を持つ半構造化データと見なされます。必要な情報、その場所、およびページ レイアウトがわかっていれば、十分に文書化された API がなくても、このデータを使用するスクレイパーをすばやく構築できます。Web スクレイピングに有益な抽象化を提供するスクリプト ライブラリやローコード ツールが多数存在します。

  
  

• Web クローラー- Web クローラーは Web ページをトラバースし、再帰的な URL リストを構築できます。この方法をスクレイピングと組み合わせて、基準に基づいて情報をスキャン、要約、フィルタリングできます。さらに重要なスケールでは、この手法を使用して独自のナレッジ グラフを作成できます。

  
  

データ収集にどのような手法を使用するとしても、ハッキングされた 1 回限りのスクリプトを作成する衝動を抑えてください。代わりに、データ エンジニアリングのベスト プラクティスを適用して、データ レイク内のテーブルにデータを配置する、繰り返し可能でフォールト トレラントな ETL パイプラインとして抽出器を展開します。これらのパイプラインを実行するたびに、ソース URL や抽出時間などの重要なメタデータ要素がキャプチャされ、各コンテンツとともにラベル付けされるようにしてください。メタデータ キャプチャは、下流のデータのクリーニング、フィルタリング、重複排除、デバッグ、および帰属に非常に役立ちます。

チャンキング

チャンキングは、大きなテキスト サンプルを LLM のコンテキスト ウィンドウ内に収まる小さな個別の部分に縮小します。コンテキスト ウィンドウは大きくなり、推論中により多くのコンテンツのチャンクを詰め込むことができるようになりましたが、チャンキングは、精度、再現率、計算効率の適切なバランスをとるための重要な戦略であり続けます。

効果的なチャンク化には、適切なチャンク サイズを選択する必要があります。チャンク サイズが大きいほど、コンテキスト ウィンドウ内に存在するチャンクの総数が少なくなるという犠牲を払って、テキストのコンテキストと意味が保持される傾向があります。逆に、チャンク サイズが小さいほど、LLM のコンテキスト ウィンドウに詰め込めるコンテンツのチャンクの数が多くなります。ただし、追加のガードレールがないと、各コンテンツは周囲のコンテキストから削除されたときに品質が低下するリスクがあります。

チャンク サイズに加えて、さまざまなチャンキング戦略と方法を評価する必要もあります。検討すべき標準的なチャンキング方法をいくつか紹介します。

• 固定サイズ戦略- この方法では、コンテンツ チャンクのトークン数を固定し、それに応じてコンテンツを小さなチャンクに分解します。通常、この戦略を使用する場合は、コンテキストが失われすぎないように、隣接するチャンク間である程度の重複が推奨されます。これは最も簡単なチャンキング戦略であり、通常、より洗練された戦略に進む前の良い出発点となります。

  
  

• 動的サイズ戦略- この方法では、さまざまなコンテンツ特性を使用して、チャンクの開始位置と終了位置を決定します。簡単な例としては、句読点チャンカーがあります。これは、ピリオドや改行などの特定の文字の存在に基づいて文を分割します。句読点チャンカーは、単純な短いコンテンツ (ツイート、文字数制限のある製品の説明など) では十分に機能しますが、より長く複雑なコンテンツに使用すると、明らかな欠点があります。

  
  

• コンテンツ認識戦略- コンテンツ認識チャンカーは、抽出されるコンテンツとメタデータの種類に合わせて調整され、これらの特性を使用して各チャンクの開始位置と終了位置を決定します。例としては、ヘッダー タグを使用してチャンクの境界を区切る HTML ブログのチャンカーが挙げられます。別の例としては、各文のペアワイズ コサイン類似度スコアをその前の文と比較して、コンテキストが大幅に変化して新しいチャンクの区切りが必要になったかどうかを判断するセマンティック チャンカーが挙げられます。

  
  

RAG アプリケーションに最適なチャンク化戦略は、LLM のコンテキスト ウィンドウの長さ、基礎となるテキスト構造、テキストの長さ、およびコーパス内のコンテンツの複雑さに合わせて調整する必要があります。さまざまなチャンク化戦略を自由に試し、変更のたびに評価を実行して、特定の戦略でのアプリケーションのパフォーマンスをよりよく理解してください。データ レイク テーブルでチャンク化されたコンテンツのバージョンを管理し、各チャンクに系統情報があることを確認し、上流のデータ抽出ステップからの生のコンテンツとそれぞれのメタデータまでさかのぼって追跡できるようにします。

充実

多くの場合、RAG 中に取得するためにインデックス付けされたコンテンツ チャンクは、アプリケーションが運用中に遭遇する実際のプロンプトとはコンテキストが異なります。たとえば、AI 質問応答ボットを構築している場合、顧客のクエリに対する多数の正しい回答を含む独自の情報の膨大なコーパスがある可能性があります。ただし、生の形式では、コーパスが類似性に基づく埋め込み取得に最適な質問と回答のペアの形式で事前に整理されている可能性は低くなります。この例では、取得時に、受信する顧客の質問と意味的に類似する生のコンテンツのチャンクをコーパスから単純に検索すると、取得結果セットの関連性が最適ではない可能性があります。これは、コンテキストが異なるアイテム (つまり、質問と回答) の類似性を比較しているという事実の結果です。幸いなことに、解決策は比較的簡単です。LLMの力を使って、生のコンテンツチャンクである可能性のある回答を、仮説的な質問に再文脈化することで充実させることができます。その後、それらの仮説的な質問をベクターデータベースにインデックス化し、後で検索できるようにします。この技術は、仮想文書埋め込み (HyDE)は、文書処理パイプライン内でLLMを使用してデータを充実させる力を示しています。これは、よく知られているコンテンツでこの手法を使用した例です。 squad_v2 データセット:

 System Prompt: Given the provided snippet of text, generate three hypothetical questions that could be asked about it. Each question must be able to be answered using the information within the referenced snippet of text and only that information. Be concise. User Prompt: “At the 52nd Annual Grammy Awards, Beyoncé received ten nominations, including Album of the Year for I Am... Sasha Fierce, Record of the Year for "Halo", and Song of the Year for "Single Ladies (Put a Ring on It)", among others. She tied with Lauryn Hill for most Grammy nominations in a single year by a female artist. In 2010, Beyoncé was featured on Lady Gaga's single "Telephone" and its music video. The song topped the US Pop Songs chart, becoming the sixth number-one for both Beyoncé and Gaga, tying them with Mariah Carey for most number-ones since the Nielsen Top 40 airplay chart launched in 1992. "Telephone" received a Grammy Award nomination for Best Pop Collaboration with Vocals.” Response: Here are some questions that could be asked based on the provided text: * How many nominations did Beyoncé receive at the 52nd Annual Grammy Awards? * For which album was Beyoncé nominated for Album of the Year at the 52nd Annual Grammy Awards? * Which song earned Beyoncé a nomination for Record of the Year at the 52nd Annual Grammy Awards?

長い形式やテーマ的に複雑なコンテンツで構成されたコーパスを扱う場合は、追加の前処理を行ってコンテンツ チャンクを事前に要約し、その意味的次元を減らすことを検討してください。取得時に、チャンク要約の埋め込みをクエリし、要約されていないテキストをコンテキスト ウィンドウ挿入に置き換えることができます。この方法は、大規模で複雑、または頻繁に変更されるコーパスに対して RAG を実行するときに関連性を高めます。

トークン化

2024 年の大規模言語モデルは、一般的には、書き言葉をネイティブに理解しないトランスフォーマーベースのニューラル ネットワークです。入力された生のテキストはトークンに変換され、その後、行列乗算演算に最適化された高次元の埋め込みベクトルが続きます。この入力プロセスは一般にエンコードと呼ばれます。逆の出力プロセスはデコードと呼ばれます。多くの LLM は、トレーニングに使用されたのと同じトークン化スキームを使用した推論にのみ機能します。したがって、選択したトークン化戦略の基本を理解することは不可欠です。これは、パフォーマンスに多くの微妙な影響を与える可能性があるためです。

単純な文字レベルおよび単語レベルのトークン化スキームもありますが、執筆時点では、最先端の LLM のほぼすべてがサブワード トークナイザーを使用しています。したがって、ここではそのカテゴリのトークナイザーにのみ焦点を当てます。

サブワード トークナイザーは、単語を再帰的に小さな単位に分割します。これにより、語彙数を増やしすぎずに語彙にない単語を理解できるようになります。これは、トレーニングのパフォーマンスと、LLM が未知のテキストに一般化する能力にとって重要な考慮事項です。

現在広く使用されているサブワード トークン化方法は、バイト ペア エンコーディング (BPE) です。大まかに言うと、BPE アルゴリズムは次のように機能します。

• 単語をサブワード単位のトークンに分割し、それらを語彙に追加します。各トークンは、トレーニング コーパス内の共通の隣接文字パターンの相対頻度によって制御されるサブワードを表します。

  
  

• 上記の手順の共通トークン ペアを、そのペアを表す単一のトークンに置き換え、それを語彙に追加します。

  
  

• 上記の手順を再帰的に繰り返します。

  
  

BPE トークン化は、多くのユースケースでうまく機能するため、一般的に RAG アプリケーションを開始するのに最適です。ただし、選択したモデルに使用される事前トレーニング コーパスの語彙に十分に表現されていない、高度に専門化されたドメイン言語が大量にあるとします。その場合は、代替のトークン化方法を調べるか、この記事の範囲外である微調整と低ランク適応を検討してください。前述の制約された語彙の問題は、医学、法律、またはあまり知られていないプログラミング言語などの専門分野向けに構築されたアプリケーションではパフォーマンスの低下として現れる可能性があります。より具体的には、高度に専門化された言語/専門用語を含むプロンプトで顕著になります。データ レイクに保存されている eval データセットを使用して、必要に応じてさまざまなトークン化スキームと、さまざまなモデルでのそれぞれのパフォーマンスを実験してください。トークナイザー、埋め込み、言語モデルは密接に結合されていることが多いため、1 つを変更すると、他の変更が必要になる場合があることに注意してください。

結論

MinIO オブジェクト ストア上に構築された最新のデータ レイクは、RAG ベースのアプリケーションを自信を持って本番環境に導入するための基礎インフラストラクチャを提供します。これを使用すると、データ レイク テーブル内に保存してバージョン管理できる評価とドメイン固有の評価データ セットを作成できます。これらの評価を使用して、RAG アプリケーション ドキュメント パイプラインの各コンポーネント (抽出機能、チャンカー、エンリッチメント、トークナイザー) を繰り返し評価し、段階的に改善して、本番環境レベルのドキュメント処理パイプラインを構築します。

ご質問がございましたら、お気軽にお問い合わせください。スラック！