検索拡張生成 (RAG) アーキテクチャでは、ナレッジベースは大規模言語モデル (LLM) にコンテキストを提供する外部のプライベートデータソースとして機能します。このデータの品質は、生成される結果の精度に直接影響します。ナレッジベースは一度作成すれば、複数のアプリケーションフローで再利用できるため、開発効率が大幅に向上します。ナレッジベースは、手動およびスケジュールされた更新もサポートしており、常に最新かつ正確な状態を保つことができます。
仕組み
ナレッジベースを作成してインデックスを更新すると、システムは PAI-DLC タスクを使用して OSS データソース内のファイルを処理するワークフローを開始します。このワークフローは、3 つのコアステップで構成されています:
前処理とチャンク化: システムは OSS 内の指定されたソースファイルを自動的に読み取ります。それらを前処理し、取得に適したテキストチャンクに分割します。構造化データは行ごとにチャンク化されます。画像はチャンク化されません。
ベクトル化 (埋め込み): システムは埋め込みモデルを呼び出して、各テキストチャンクまたは画像を、そのセマンティックな意味を表す数値ベクトルに変換します。
ストレージとインデックス作成: システムは生成されたベクトルデータをベクトルデータベースに保存し、効率的な取得のためのインデックスを作成します。
コアフロー: 作成から使用まで
ステップ 1: ナレッジベースの作成
LangStudio に移動し、ワークスペースを選択します。[ナレッジベース] タブで、[ナレッジベースの作成] をクリックします。以下で説明するようにパラメーターを設定します。
基本構成
パラメーター | 説明 |
ナレッジベース名 | ナレッジベースのカスタム名を入力します。 |
データソース OSS パス | ナレッジベースデータが配置されている OSS ディレクトリ。 |
出力 OSS パス | ドキュメント解析から生成された中間結果とインデックス情報を保存します。最終的な出力は、選択したベクトルデータベースのタイプによって異なります。 重要 ランタイムに設定された [インスタンス RAM ロール] が PAI のデフォルトロールである場合、このパラメーターには、現在の ワークスペースのデフォルトストレージパスと同じ OSS バケットを使用し、そのバケット内の任意のディレクトリを指定することをお勧めします。 |
ナレッジベースタイプ | ファイルに基づいてタイプを選択します。各タイプでサポートされているファイル形式は次のとおりです:
|
特定のタイプの設定
ドキュメントの解析とチャンク化の設定 (ドキュメントナレッジベース用)
テキストチャンクサイズ: 各テキストチャンクの最大文字数。デフォルトは 1024 文字です。
テキストチャンクの重複: 隣接するテキストチャンク間の重複文字数。これにより、取得の一貫性が確保されます。デフォルトは 200 文字です。重複サイズをチャンクサイズの 10% から 20% に設定することをお勧めします。
説明詳細については、「チャンク化パラメーターの調整」をご参照ください。
[フィールド設定] (構造化データナレッジベース用): animal.csv などのファイルをアップロードするか、手動でフィールドを追加します。インデックス作成と取得に使用するデータフィールドを指定できます。
埋め込みモデルとデータベース
ナレッジベースの埋め込みモデルサービスとベクトルデータベースを選択します。目的のオプションがドロップダウンリストにない場合は、作成できます。詳細については、「接続設定」をご参照ください。
ナレッジベースタイプ | サポートされている埋め込みタイプ | サポートされているベクトルデータベースタイプ |
ドキュメント |
|
|
構造化データ | ||
画像 |
|
|
ベクトルデータベースの推奨事項:
本番環境: Milvus と Elasticsearch の使用をお勧めします。これらは大規模なベクトルデータの処理をサポートしています。
テスト環境: FAISS は別のデータベースを必要としないため (ナレッジベースファイルと生成されたインデックスファイルは [出力 OSS パス] に保存されます)、使用をお勧めします。機能テストや小規模ファイルの処理に適しています。ファイルボリュームが大きいと、取得と処理のパフォーマンスに大きな影響を与えます。
ランタイム
ドキュメントチャンクのプレビューや取得テストなどの操作を実行するランタイムを選択します。これらの操作には、ベクトルデータベースと埋め込みサービスへのアクセスが必要です。
次のランタイム設定に注意してください:
内部エンドポイントを介してベクトルデータベースまたは埋め込みサービスにアクセスする場合、ランタイムの VPC がデータベースとサービスの VPC と同じであるか、VPC が接続されていることを確認してください。
インスタンス RAM ロールにカスタムロールを選択した場合、そのロールに OSS へのアクセス権限を付与する必要があります。AliyunOSSFullAccess 権限を付与することをお勧めします。詳細については、「RAM ロールへの権限付与」をご参照ください。
ランタイムバージョンが 2.1.4 より前の場合、ドロップダウンリストに表示されないことがあります。この問題を解決するには、新しいランタイムを作成してください。
ステップ 2: ファイルのアップロード
方法 1: ナレッジベースのデータソースとして設定されている OSS パスにファイルを直接アップロードします。
方法 2: [ナレッジベース] タブで、ターゲットナレッジベースの名前をクリックして詳細ページを開きます。[ドキュメント] または [画像] タブで、ファイルまたは画像をアップロードします。
ステップ 3: インデックスの構築
インデックスの更新。ファイルをアップロードした後、右上隅にある [インデックスの更新] をクリックします。これにより、PAI ワークフロータスクが送信され、DLC ジョブが実行されて OSS データソース内のファイルが前処理、チャンク化、ベクトル化され、インデックスが構築されます。タスクパラメーターは以下のとおりです:
パラメーター
説明
計算リソース
タスクの実行に必要な計算リソース。パブリックリソース、またはリソースクォータを介して Lingjun リソース および一般的な計算リソースを使用できます。
画像ナレッジベースのインデックスを更新する場合、ノード数は 2 より大きい必要があります。
複雑な PDF から高品質なチャートを抽出するには、インデックスを更新する際にドライバーバージョンが 550 以上の GPU リソースを使用することをお勧めします。システムは、リソースタイプとドライバーバージョンの要件を満たすタスクに対して、チャート認識または OCR のモデルを自動的に呼び出します。画像は出力パスの
chunk_imagesディレクトリに保存されます。アプリケーションフローで使用される場合、テキスト内の画像は<img>タグ (例:<img src="temporary_signed_URL">) に置き換えられます。
VPC 設定
内部ネットワークを介してベクトルデータベースまたは埋め込みサービスにアクセスする場合、選択した VPC がこれらのサービスの VPC と同じであるか、接続されていることを確認してください。
埋め込み設定
最大同時実行数 (画像ナレッジベース用): 埋め込みサービスへの同時リクエスト数。Model Studio マルチモーダルモデルサービスはリクエストを毎分 120 に制限しているため、この同時実行数を増やすとスロットリングがトリガーされる可能性があります。
バッチサイズ (ドキュメント/構造化データナレッジベース用): ベクトル化中に各バッチで処理されるテキストチャンクの数。モデルサービスの QPS 制限に基づいて適切な値を設定すると、処理速度が向上します。
ファイルチャンクまたは画像のプレビュー。インデックス更新タスクが成功した後、ドキュメントチャンクまたは画像をプレビューできます。
説明すでに Milvus に保存されているドキュメントチャンクについては、個別にステータスを有効または無効に設定できます。無効化されたチャンクは取得されません。
ステップ 4: 取得効果のテスト
インデックスを更新した後、[取得テスト] タブに切り替えます。クエリを入力し、取得パラメーターを調整して取得結果をテストします。画像ナレッジベースの場合、テストは画像のリストを返します。
取得パラメーター:
Top K: ナレッジベースから取得する関連テキストチャンクの最大数。値の範囲は 1 から 100 です。
スコアしきい値: 0 から 1 の範囲の類似性スコアのしきい値。このしきい値を超えるスコアを持つチャンクのみが返されます。値が高いほど、テキストとクエリ間の類似性要件が厳しくなります。
取得パターン: デフォルトのパターンは Dense (ベクトル検索) です。ハイブリッド検索 (ベクトルとキーワード) を使用したい場合、ベクトルデータベースは Milvus 2.4.x 以降、または Elasticsearch である必要があります。取得パターンの選択方法の詳細については、「取得パターンの選択」をご参照ください。
メタデータフィルター条件: メタデータを使用して取得範囲をフィルタリングし、精度を向上させます。詳細については、「メタデータの使用」をご参照ください。
クエリの再書き込み: LLM を使用して、曖昧、口語的、またはコンテキストに依存するユーザーのクエリを最適化します。このプロセスは、クエリをより明確かつ完全にすることでユーザーの意図を明確にし、取得精度を向上させます。使用シナリオの詳細については、「クエリの再書き込み」をご参照ください。
結果の再ランキング: 再ランキングモデルを使用して初期の取得結果を再ランキングし、最も関連性の高い結果を一番上に移動させます。使用シナリオの詳細については、「結果の再ランキング」をご参照ください。
説明結果の再ランキングには再ランキングモデルが必要です。サポートされているモデルサービス接続タイプには、Model Studio LLM サービス、OpenSearch モデルサービス、および汎用 Reranker モデルサービスが含まれます。
ステップ 5: アプリケーションフローでの使用
テストが完了したら、アプリケーションフローで情報取得のためにナレッジベースを使用できます。ナレッジベースノードでは、クエリの再書き込みと結果の再ランキング機能を有効にし、トレースで書き換えられたクエリを表示できます。
結果は List[Dict] で、各 Dict にはキー content と score が含まれており、それぞれドキュメントチャンクの内容と入力クエリとの類似性スコアを表します。
取得の最適化
チャンクパラメーターの調整: 取得の基盤を構築
指導原則
モデルのコンテキスト制限: チャンクサイズが埋め込みモデルのトークン制限を超えないようにして、情報の切り捨てを回避します。
情報の完全性: チャンクは完全なセマンティクスを含むのに十分な大きさである必要がありますが、情報が多すぎて類似性計算の精度が低下するのを避けるために十分に小さい必要があります。テキストが段落ごとに整理されている場合は、チャンク化を段落に合わせて設定し、恣意的な分割を避けることができます。
継続性の維持: チャンクサイズの 10% から 20% を推奨する適切な重複サイズを設定して、チャンク境界で重要な情報が分割されることによるコンテキストの損失を効果的に防ぎます。
反復的な干渉の回避: 過度の重複は重複した情報を導入し、取得効率を低下させる可能性があります。情報の完全性と冗長性の間でバランスを見つける必要があります。
デバッグの提案
反復的な最適化: チャンクサイズ 300、重複 50 などの初期値から始めます。次に、実際の取得と質疑応答 (Q&A) の結果に基づいてこれらの値を継続的に調整および実験し、データに最適な設定を見つけます。
自然言語の境界: テキストに章や段落などの明確な構造がある場合は、これらの自然言語の境界に基づいて分割を優先し、セマンティックな完全性を最大化します。
クイック最適化ガイド
問題 | 最適化の提案 |
無関係な取得結果 | チャンクサイズを大きくし、チャンクの重複を減らします。 |
結果のコンテキストが不整合 | チャンクの重複を増やします。 |
適切な一致が見つからない (低い取得率) | チャンクサイズをわずかに増やします。 |
高い計算またはストレージのオーバーヘッド | チャンクサイズを小さくし、チャンクの重複を減らします。 |
次の表に、さまざまな種類のテキストに推奨されるチャンクサイズと重複サイズを示します。
テキストタイプ | 推奨チャンクサイズ | 推奨チャンク重複 |
短いテキスト (FAQ、要約) | 100～300 | 20～50 |
通常のテキスト（ニュース、ブログ） | 300～600 | 50～100 |
技術文書 (API、論文) | 600 から 1024 | 100～200 |
長い文書 (法律、書籍) | 1024 から 2048 | 200～400 |
取得モードの選択: セマンティクスとキーワードのバランス
取得パターンは、システムがクエリをナレッジベース内のコンテンツとどのように照合するかを決定します。さまざまなパターンには独自の長所と短所があり、さまざまなシナリオに適しています。
Dense (ベクトル) 取得: セマンティクスの理解に優れています。クエリとドキュメントの両方をベクトルに変換し、これらのベクトル間の類似性を計算することでセマンティックな関連性を判断します。
Sparse (キーワード) 取得: 完全一致に優れています。BM25 などの従来の用語頻度モデルに基づいており、ドキュメント内のキーワードの頻度と位置に基づいて関連性を計算します。
ハイブリッド取得: 両方を組み合わせます。ベクトル取得とキーワード取得の結果をマージし、Reciprocal Rank Fusion (RRF) や線形重み付けやモデルアンサンブルなどの重み付け融合などのアルゴリズムを使用して再ランキングします。
取得モード | 長所と短所 | シナリオ |
Dense (ベクトル) 取得 |
|
|
Sparse (キーワード) 取得 |
|
|
ハイブリッド取得 |
|
|
メタデータの使用: 取得のフィルタリング
メタデータフィルタリングの価値
正確な取得、ノイズの低減: メタデータは、取得中のフィルター条件またはソート基準として使用できます。メタデータでフィルタリングすることで、無関係なドキュメントを除外し、生成モデルが無関係なコンテンツを受信するのを防ぐことができます。たとえば、ユーザーが「劉慈欣が書いた SF 小説を検索」と尋ねた場合、システムはメタデータ条件
author=Liu Cixinとcategory=sci-fiを使用して、最も関連性の高いドキュメントを直接特定できます。ユーザーエクスペリエンスの向上
パーソナライズされた推奨をサポート: メタデータを使用して、「SF」ドキュメントを好むなど、ユーザーの過去のプリファレンスに基づいてパーソナライズされた推奨を提供できます。
結果の解釈可能性の向上: 作成者、ソース、日付などのドキュメントメタデータを結果に含めることで、ユーザーはコンテンツの信頼性と関連性を判断しやすくなります。
多言語またはマルチモーダル拡張をサポート: 「言語」や「メディアタイプ」などのメタデータにより、複数の言語とテキストと画像の混合を含む複雑なナレッジベースを簡単に管理できます。
使用方法
機能の制限:
ランタイムイメージバージョン: 2.1.8 以降である必要があります。
ベクトルデータベース: Milvus と Elasticsearch のみがサポートされています。
ナレッジベースタイプ: ドキュメントまたは構造化データをサポートします。画像はサポートされていません。
メタデータ変数を設定します。Milvus のみを使用するナレッジベースの場合、[概要] タブの [メタデータ] セクションに移動し、[編集] をクリックして
authorなどの変数を設定します。システム予約フィールドは使用しないでください。
ドキュメントにタグを付けます。ドキュメントチャンクの詳細ページで、[メタデータの編集] をクリックして、
author=Alexなどのメタデータ変数と値を追加します。その後、概要ページに戻ってメタデータ参照ステータスと値の数を表示できます。
フィルターをテストします。[取得テスト] タブで、メタデータフィルター条件を追加してテストを実行します。
注: 画像で取得されたドキュメントは、ステップ 2 でタグ付けされたドキュメントです。
アプリケーションフローで使用します。ナレッジベースノードでメタデータフィルター条件を設定します。
クエリの再書き込みと結果の再ランキング: 取得チェーンの最適化
クエリの再書き込み
LLM を使用して、ユーザーの曖昧、口語的、またはコンテキストに依存するクエリを、より明確で、より完全で、独立した質問に書き換えます。これにより、後続の取得の精度が向上します。
推奨されるシナリオ:
ユーザーのクエリが曖昧または不完全である場合 (例: コンテキストなしの「彼はいつ生まれましたか?」)。
マルチターン対話で、クエリがコンテキストに依存する場合 (例: 「その後、彼は何をしましたか?」)。
取得機能または LLM が元のクエリを正確に理解するのに十分な能力がない場合。
セマンティック取得ではなく、BM25 などの従来の転置インデックス取得を使用している場合。
推奨されないシナリオ:
ユーザーのクエリがすでに非常に明確で具体的である場合。
LLM が強力で、元のクエリを正確に理解できる場合。
システムが低レイテンシーを必要とし、書き換えによる追加の遅延を許容できない場合。
結果の再ランキング
取得機能によって返された初期結果を再ランキングして、最も関連性の高いドキュメントを最初に表示し、ランキングの品質を向上させます。
推奨されるシナリオ:
BM25 や DPR などの初期取得機能からの結果の品質が不安定な場合。
検索または Q&A システムで Top-1 の精度が必要な場合など、取得結果のランキングが重要な場合。
推奨されないシナリオ:
システムリソースが限られており、追加の推論オーバーヘッドを処理できない場合。
初期取得機能がすでに十分に強力で、再ランキングによる改善が限定的な場合。
リアルタイム検索シナリオなど、応答時間が非常に重要な場合。
運用と管理
時間指定スケジューリングの設定: 自動更新
スケジュールされた更新機能は DataWorks に依存します。サービスを有効化していることを確認してください。サービスが有効化されていない場合は、「DataWorks サービスの有効化」をご参照ください。
ナレッジベースの詳細ページで、右上隅にある をクリックし、設定を完了して [送信] をクリックします。
スケジューリング設定と定期タスクの表示
フォームを送信すると、システムは DataWorks データ開発センターにナレッジベースのスケジュールされたワークフローを自動的に作成します。その後、システムはワークフローを DataWorks オペレーションセンターの定期タスクとして公開します。定期タスクは翌日 (T+1) に有効になります。DataWorks の定期タスクは、設定した時間にナレッジベースを更新します。ナレッジベースのスケジューリング設定ページで、スケジューリング設定と定期タスクを表示できます。
スケジュールされた更新パラメーター:
スケジューリングサイクル: 本番環境でノードが実行される頻度を定義します。この設定により、定期インスタンスの数とその実行時間が決まります。
スケジューリング時間: ノードが実行される特定の時間を定義します。
タイムアウト定義: ノードがタイムアウトして終了するまでに実行できる最大時間を定義します。
有効日: ノードが自動的に実行されるようにスケジュールされる時間範囲を定義します。この範囲外では、ノードは自動的にスケジュールされません。
スケジューリングリソースグループ: DataWorks の時間指定スケジューリング機能のリソースグループを指定します。DataWorks リソースグループを作成していない場合は、ドロップダウンリストで [今すぐ作成] をクリックして作成ページを開きます。リソースグループを作成した後、現在のワークスペースにアタッチします。
スケジューリングパラメーターの詳細については、「時間プロパティ設定の説明」をご参照ください。
マルチバージョン管理: 開発と本番の分離
バージョンクローン機能を使用すると、テスト済みのナレッジベース (v1 など) を新しい公式バージョンとして公開できます。これにより、開発環境が本番環境から分離されます。
バージョンのクローン作成に成功すると、ナレッジベースの詳細ページで異なるバージョンを切り替えて管理できます。また、アプリケーションフローのナレッジベース取得ノードで目的のバージョンを選択することもできます。
バージョンのクローン作成は、インデックスの更新に似ています。この操作はワークフロータスクを送信します。操作レコードでタスクを表示できます。
トラブルシューティング: ワークフロータスクの表示
インデックスを更新するか、バージョンをクローンした後、右上隅にある [操作レコード] をクリックします。ターゲットタスクを選択し、[操作] 列の [タスクの表示] をクリックして、実行情報、タスクログ、出力結果など、タスク内の各ノードの実行詳細を表示します。
たとえば、ドキュメントナレッジベースのインデックスを更新するためのワークフロータスクには、次の 3 つのノードが含まれます。read-oss-file ノードを除き、各ノードは PAI-DLC タスクを作成します。ログの Job URL を使用して DLC タスクの詳細を表示することもできます。
read-oss-file: OSS ファイルを読み取ります。
rag-parse-chunk: ドキュメントの前処理とチャンク化を処理します。
rag-sync-index: テキストチャンクの埋め込みとベクトルデータベースへの同期を処理します。
アセット管理: データセットの表示
インデックス更新タスクが成功すると、システムは [出力 OSS パス] をデータセットとして自動的に登録します。AI アセット管理 - データセットでデータセットを表示できます。このデータセットはナレッジベースと同じ名前を持ち、インデックス構築プロセスからの出力情報を記録します。
