大規模言語モデルの効果が明らかに向上するにつれて、その関連アプリケーションが次々と登場し、ますます人気が高まる傾向を示しています。より広く懸念されている技術ルートの 1 つは、大規模言語モデル (LLM) + 知識想起 (知識検索) の方法です。これにより、プライベート ドメインの知識の質問応答の点で一般的な大規模言語モデルのいくつかの欠点を補い、問題を解決できます。一般的な大規模言語モデルの問題 言語モデルは、専門分野における根拠の欠如、幻覚、その他の質問に答えます。基本的なアイデアは、プライベート ドメインの知識ドキュメントをスライスしてベクトル化し、ベクトル検索を通じてそれらを呼び出し、帰納と要約のための大規模な言語モデルにコンテキストとして入力することです。
この技術的方向性の具体的な実践では、知識ベースは、知識の質問に答えるプロセスの知識想起ステップで重要な役割を果たす、反転とベクトルに基づく 2 つのインデックス方法と、通常のドキュメント インデックスまたはログ インデックスを使用して構築できます。 、知識のベクトル化にはディープ モデルのセマンティック機能が必要であり、ドキュメントのセグメント化、ベクトル モデルの展開、推論などの追加の手順が必要です。知識ベクトル化データベースの構築プロセスでは、元の文書の大きさだけでなく、セグメント化の粒度、ベクトル次元などの要素も考慮する必要があり、最終的にはベクトルデータベースによってインデックス付けされる知識項目の数が上限に達する可能性があります。非常に大きな大きさ。次の 2 つの側面によって引き起こされる可能性があります。
-
金融、医療、法律分野など、さまざまな業界で既存の文書の量が非常に多く、新規文書の量も膨大です。
-
想起効果を追求するために、文書のセグメント化では、文またはセグメントごとの多粒度の冗長ストレージが採用されることがよくあります。
これらの詳細は、知識ベクトル データベースの書き込みとクエリのパフォーマンスに特定の課題をもたらします。Amazon クラウド テクノロジーのサービスに基づいて、ベクトル化された知識ベースの構築と管理を最適化するために、次のような知識ベース構築プロセスが必要になります。図は次のように構成されます。
-
Lambda は、S3 バケットのハンドラーを通じてリアルタイムでトリガーされ、ナレッジ ファイル ストレージに対応する Glue ジョブを開始します。
-
ドキュメントの解析と分割は Glue ジョブで実行され、ベクトル化のために SageMaker の埋め込みモデルが呼び出されます。
-
一括経由で Amazon OpenSearch に挿入する
また、知識をベクトル化する方法やベクトル データベースを最適化する方法など、プロセス全体に関わるさまざまな側面に関するいくつかのベスト プラクティスと経験もまとめています。
知識のベクトル化
文書の分割
知識のベクトル化の前段階は知識を分割することであり、セマンティックな整合性の維持が最も重要な考慮事項です。2 つの側面から議論します。次の 2 つの焦点を選択する方法は、いくつかの経験をそれぞれ要約したものです。
a. フラグメントの分割方法
この部分の作業に関しては、Langchain は人気のある大規模言語モデル統合フレームワークとして、多数の Document Loader と Text Spiltters を提供しており、その一部は参考価値がありますが、その多くは反復的です。
現在、最もよく使用されている基本的な方法は、Langchain の RecursiveCharacterTextSplitter を使用することです。これは、Langchain のデフォルトのスプリッターです。このマルチレベル区切り文字リスト - ["\n\n", "\n", " ", ""] を使用して分割します。デフォルトでは、最初に段落に従って分割されます。分割結果が超過した場合は、chunk_size 要件が満たされるまで、次のレベルの区切り文字を使用して分割を続けます。
ただし、このアプローチは比較的大まかであり、依然として一部の重要なコンテンツが逆アセンブルされる可能性があります。他の一部のドキュメント形式では、さらに微妙な慣行が必要になる場合があります。
-
FAQ ファイルは、1 つの質問と 1 つの回答の粒度に従って分割する必要があります。後続のベクトル化された入力では、質問のみ、または質問と回答を使用できます。
-
Markdown ファイルの場合、「#」はタイトルを識別するために使用される特殊文字です。MarkdownHeaderTextSplitter をスプリッターとして使用すると、コンテンツとタイトルが対応して抽出されるようになります。
PDF ファイルには、より豊富な書式設定情報が含まれます。Langchain は多くのローダーを提供しますが、Langchain の PDFMinerPDFasHTMLLoader のセグメンテーション効果の方が優れており、PDF を HTML に変換し、HTML を通じて変換します。
ブロック分割。この方法では、各ブロックのフォント サイズ情報を保持できるため、各ブロックの内容の所属関係を推定でき、段落のタイトルを前のレベルの親タイトルに関連付けて、情報をより詳細にすることができます。完了。
b. フラグメント長のモデルサポート
分割されたフラグメントはベクトル化モデルを通じて推論する必要があるため、ベクトル化モデルの Max_seq_length 制限を考慮する必要があります。この制限を超えると、切り捨てや不完全なセマンティクスが発生する可能性があります。Embedding モデルは、サポートされている Max_seq_length から分けて、現在次の表に示す 2 種類があります (これら 4 つは実務経験のあるモデルです)。
| モデル名 |
Max_seq_length |
| パラフレーズ-多言語-mpnet-base-v2(sbert.net) |
128 |
| text2vec-base-chinese(text2vec) |
128 |
| text2vec-large-chinese(text2vec) |
512 |
| text-embedding-ada-002 (openai) |
8192 |
ここでの Max_seq_length はトークンの数を指し、文字数と等価ではありません。以前のテストの経験によれば、最初の 3 つのモデルのトークンは約 1.5 漢字です。chatglm などの大規模な言語モデルの場合、トークンは通常約 2 文字です。セグメント化中にトークンの数を計算するのが不便な場合は、この比率に従って単純に変換することで、切り捨てが発生しないようにすることができます。
最初の 3 つのモデルは Bert ベースの埋め込みモデルに属し、OpenAI の text-embedding-ada-002 モデルは GPT3 ベースのモデルです。前者は文章や短い段落のベクトル化に適しており、後者は OpenAI の SAAS インターフェイスは長いテキストのベクトル化に適していますが、プライベートで導入することはできません。
検証の選択は、リコール効果に基づいて行うことができます。現在の実際の経験から、text-embedding-ada-002 は中国語の類似性スコアをランク付けできますが、識別の程度が十分ではなく (濃度は約 0.7)、しきい値を介して類似の知識想起があるかどうかを直接判断するのには役立ちません。 。
また、長さ制限の問題を改善するもう一つの方法として、分割したフラグメントに番号を付け、隣接するフラグメントの番号も近いものを呼び出す際に、ベクトルデータベースの範囲検索を利用することで、呼び出しにより、呼び出されたコンテンツの意味上の整合性も保証できます。
ベクトル化されたモデルの選択
上記の 4 つのモデルは、テキストの長さに対するモデルのサポートの違いについてのみ言及しており、現時点ではその効果について信頼できる結論はありません。リーダーボードを使用して、各モデルのパフォーマンスを理解できます。リスト上のほとんどのモデルの評価は、依然として公開データセットのベンチマークに基づいています。ベンチマークの結論が実際の運用現場で正しいかどうかを確認する必要がありますケースバイケース。ただし、原則として、共有できる経験には次のような側面があります。
-
垂直フィールドにおける Finetune のモデルには、元のベクトル モデルに比べて明らかな利点があります。
-
現在のベクトル化モデルは、対称と非対称の 2 つのカテゴリに分類されます。微調整がない場合は、FAQ に対して対称的な呼び出し、つまりクエリから質問への呼び出しを使用することをお勧めします。文書断片の知識については、クエリから回答 (文書断片) までの再現である非対称再現モデルを使用することをお勧めします。
-
効果に明らかな違いがない場合は、ベクトル次元の短いモデルを選択するようにしてください。高次元ベクトル (openai の text-embedding-ada-002 など) は、検索パフォーマンスとコストの点でベクトル データベースに負担をかけます。 。
ベクトル化された並列処理
実際のビジネス シナリオでは、ドキュメントのサイズは 100 から 100 万程度になります。冗長多段階想起法によれば、対応する知識項目は最大１億個の規模に達する可能性がある。オフライン計算全体は大規模であるため、同時に実行する必要があります。そうしないと、知識の追加とベクトル検索効果の反復の要件を満たすことができません。手順は主に以下の 3 つの計算段階に分かれます。
ドキュメントの分割の並列化
計算の同時実行粒度はファイルレベルであり、処理されるファイル形式もTXTプレーンテキスト、Markdown、PDFなど多様であり、対応するセグメンテーションロジックも異なります。並列処理に Spark などのビッグ データ フレームワークを使用するのは適切ではありません。マルチプロセスの同時処理にマルチコア インスタンスを使用するのは原始的すぎるため、タスクの観察や追跡には不便です。したがって、処理には AWS Glue の Python シェル エンジンを選択できます。主な利点は次のとおりです。
-
ファイル粒度に従って同時実行を実行すると便利であり、同時実行の程度はシンプルで制御可能です。リトライやタイムアウトなどのメカニズムにより、タスクの追跡と観察が便利になり、ログは AWS CloudWatch に直接接続されます。
-
–Additional-python-modules パラメーターで指定できる依存関係パッケージをビルドして実行すると便利です。同時に、Glue Python オペレーティング環境には、すでに opensearch_py およびその他の依存関係が付属しています。
ベクトル化された推論の並列処理
分割された段落や文は文書数に比べて何倍にも膨らむため、ベクトルモデルの推論スループットがプロセス全体のスループットを決定します。ここでは、SageMaker Endpoint を使用してベクトル化されたモデルをデプロイします。一般的に、モデルのスループット機能を提供するために、GPU インスタンス推論、マルチノード エンドポイント/エンドポイントの弾力的なスケーラビリティ、およびサーバーサイド/クライアントサイドのバッチ推論機能が提供されます。これらのいくつかの効果的な対策。オフラインのベクトル知識ベース構築の場面に特有の、次の戦略を採用できます。
-
GPU インスタンスのデプロイメント: ベクトル化されたモデルの CPU インスタンスを推論できます。ただし、オフライン シナリオでは推論の同時実行性が高く、GPU のスループットは CPU に比べて約 20 倍向上します。したがって、GPU 推論はオフライン シナリオで使用でき、CPU 推論戦略はオンライン シナリオで使用できます。
-
マルチノード エンドポイントの一時的な大規模同時ベクトル生成の場合、マルチノード エンドポイントをデプロイすることで処理され、処理後に閉じることができます。
クライアント側のバッチ推論の使用: オフライン推論の場合、クライアント側のバッチ構築は非常に簡単です。サーバー側のバッチ推論を有効にする必要はありません。一般に、サーバー側のバッチには 50 ミリ秒や 100 ミリ秒などの待ち時間があり、推論の遅延が大きい大規模な言語モデルには効果的ですが、ベクトル化された推論には適していません。 。
OpenSearch バッチ インジェクション
Amazon OpenSearch の書き込み操作は、一括してバッチで実装できるため、単一の書き込みよりも大きな利点があります。
ベクトルデータベースの最適化
ベクトル データベースにどの近似検索アルゴリズムを選択するか、適切なクラスター サイズの選択、およびクラスター設定の最適化も、ナレッジ ベースの読み取りおよび書き込みパフォーマンスにとって重要です。次の側面を考慮する必要があります。
アルゴリズムの選択
OpenSearch では、HNSW (Hierarchical Navigable Small World) と IVF (Inverted File) という 2 つの k-NN アルゴリズムが提供されています。
k-NN 検索アルゴリズムを選択する際には、考慮すべき要素がいくつかあります。メモリが制限要因ではない場合は、HNSW アルゴリズムの使用を優先することをお勧めします。HNSW アルゴリズムはレイテンシとリコールの両方を保証できるためです。メモリ使用量を制御する必要がある場合は、HNSW のようなクエリ速度と品質を維持しながらメモリ使用量を削減する IVF アルゴリズムの使用を検討してください。ただし、メモリがより大きな制限要因である場合は、メモリ使用量をさらに削減するために HNSW または IVF アルゴリズムに PQ エンコーディングを追加することを検討してください。PQ エンコードを追加すると、精度が低下する可能性があることに注意してください。したがって、アルゴリズムと最適化方法を選択するときは、特定のアプリケーション要件を満たすために複数の要素を包括的に考慮する必要があります。
クラスターサイズの推定
アルゴリズムを選択した後、k-NN クラスター サイズを導出する公式に従って必要なメモリを計算できます。
バッチインジェクションの最適化
大量のデータをナレッジ ベクトル ライブラリに注入する場合、いくつかの重要なパフォーマンスの最適化に注意を払う必要があります。主な最適化戦略は次のとおりです。
-
更新間隔を無効にする
-
インデックススレッドを増やす
-
knn メモリ比率を増やす