すべてのプロダクト
Search
ドキュメントセンター

Platform For AI:ナレッジベース管理

最終更新日:Mar 01, 2026

LangStudio アプリケーションフローでナレッジベースノードを使用するには、まずナレッジベースを作成する必要があります。ナレッジベースの作成は一度だけで、複数のアプリケーションフローで再利用できます。ナレッジベースは、検索拡張生成 (RAG) アーキテクチャにおいて、外部のプライベートデータソースとして機能します。Object Storage Service (OSS) からソースドキュメントを読み取り、データを前処理してチャンク化し、チャンクをベクトルに変換します。生成されたインデックスは、ベクトルデータベースに格納されます。このトピックでは、ナレッジベースの作成、設定、および使用方法について説明します。

仕組み

LangStudio のナレッジベースの主な機能は、OSS データソースのファイルを大規模言語モデルが取得できる形式に変換することです。このワークフローは、3 つのコアステップで構成されます。

  1. データの読み取りとチャンク化:指定した OSS パスからソースファイルを読み取ります。

    • 非構造化ドキュメント:解析され、より小さく意味的に完全なテキストチャンクに分割されます。

    • 構造化データ:行ごとにチャンク化されます。

    • イメージ:チャンク化されず、全体として処理されます。

  2. ベクトル化 (埋め込み):埋め込みモデルを呼び出し、各データチャンクまたはイメージを、その意味内容を表す数値ベクトルに変換します。

  3. ストレージとインデックス作成: システムは生成されたベクトルデータをベクトルデータベースに保存し、効率的な取得のためのインデックスを作成します。

クイックスタート:ナレッジベースの作成と使用

このセクションでは、ドキュメントタイプのナレッジベースを作成し、ワークフローで使用するためのクイックガイドを提供します。

  1. ナレッジベースの作成LangStudio に移動し、ワークスペースを選択します。 Knowledge Base タブで、Create Knowledge Base をクリックします。 次の主要なパラメーターを設定し、他のパラメーターはデフォルト値のままにして、[OK] をクリックします。

    パラメーター

    説明

    Basic Configuration

    Name

    ナレッジベースのカスタム名を入力します。例:test_kg

    Data Source OSS Path

    ナレッジベースのソースファイルが格納されている場所。例:oss://examplebucket.oss-cn-hangzhou-internal.aliyuncs.com/test/original/

    Output OSS Path

    ドキュメント解析から生成された中間結果とインデックス情報を格納します。最終的な出力は、選択したベクトルデータベースのタイプによって異なります。例:oss://examplebucket.oss-cn-hangzhou-internal.aliyuncs.com/test/output/

    重要

    ランタイムに設定されている [インスタンス RAM ロール] が PAI デフォルトロールである場合、このパラメーターを 現在のワークスペースのデフォルトストレージパス の OSS バケット内のディレクトリに設定することをお勧めします。

    Type

    [ドキュメント] を選択します。

    Embedding Model and Database

    Embedding Type

    Alibaba Cloud Model Studio Service を選択し (事前に接続を作成しておく必要があります。接続設定をご参照ください)、次に作成した接続とモデルを選択します。

    Vector Database Type

    クイックテストには [FAISS] を選択します。

  2. ファイルのアップロード

    1. Knowledge Base タブで、作成したナレッジベースをクリックします。Overview ページで、[ドキュメント] タブに切り替えます。このタブには、ナレッジベースのデータソースに指定された OSS パスからのドキュメントが表示されます。

    2. ページで Upload ボタンをクリックするか、データソースの OSS パスにファイルを直接アップロードすることで、ファイルを追加または更新できます。 たとえば、ページから rag_test_doc.txt をアップロードできます。 サポートされているファイル形式の詳細については、「ナレッジベースのタイプ」をご参照ください。

      image

  3. インデックスの更新。ファイルをアップロードした後、右上隅にある Update Index をクリックし、表示されるページで計算リソースとネットワークを設定します。インデックス更新タスクが完了すると、ファイルステータスが「インデックス済み」に変わります。その後、ファイルをクリックしてドキュメントチャンクをプレビューできます。イメージナレッジベースの場合、代わりにイメージのリストが返されます。

    説明

    すでに Milvus に保存されているドキュメントチャンクについては、個別にステータスを有効または無効に設定できます。無効化されたチャンクは取得されません。

    image

  4. 取得テスト。 インデックスが更新されたら、Recall Test タブに切り替え、質問を入力し、取得パラメーターを調整してパフォーマンスをテストします。

    image

  5. アプリケーションフローでナレッジベースを使用する。テストが完了したら、アプリケーションフローでナレッジベースから情報を取得できます。ナレッジベースノードでは、クエリ書き換えと結果のリランキング機能を有効にし、ノードの実行詳細で書き換えられたクエリを表示できます。

    image

    結果は List[Dict] で、各辞書にはドキュメントチャンクの content と入力クエリとの類似度 score が含まれます。

    [
      {
        "score": 0.8057173490524292,
        "content": "パンデミックによる不確実性のため、XX銀行は中国または中国本土の経済動向と予測に基づき、貸付金、前渡金、および非信用資産の減損損失引当金を積極的に増加させました。また、引当金カバー率を向上させるために、不良資産の償却と処分を増加させました。2020年には、純利益は289億2800万人民元に達し、前年比2.6%増となり、収益性は徐々に改善しました。\n(百万元) 2020 2019 変化率 (%)\n経営成績と収益性\n営業収益 153,542 137,958 11.3\n減損損失前営業利益 107,327 95,816 12.0\n純利益 28,928 28,195 2.6\n経費率(1)(%) 29.11 29.61 0.50 パーセントポイント低下\n総資産利益率 (%) 0.69 0.77 0.08 パーセントポイント低下\n加重平均自己資本利益率 (%) 9.58 11.30 1.72 パーセントポイント低下\n純金利マージン(2)(%) 2.53 2.62 0.09 パーセントポイント低下\n注: (1) 経費率 = 営業経費および管理費 / 営業収益。",
        "id": "49f04c4cb1d48cbad130647bd0d75f***1cf07c4aeb7a5d9a1f3bda950a6b86e",
        "metadata": {
          "page_label": "40",
          "file_name": "2021-02-04_XX_Insurance_Group_Co_Ltd_XX_China_XX_2020_Annual_Report.pdf",
          "file_path": "oss://my-bucket-name/datasets/chatglm-fintech/2021-02-04__XX_Insurance_Group_Co_Ltd__601318__China_XX__2020_Annual_Report.pdf",
          "file_type": "application/pdf",
          "file_size": 7982999,
          "creation_date": "2024-10-10",
          "last_modified_date": "2024-10-10"
        }
      },
      {
        "score": 0.7708036303520203,
        "content": "72億人民元、前年比5.2%増。\n2020\n(百万元) 生命保険・健康保険事業、損害保険事業、銀行事業、信託事業、証券事業、その他資産管理事業、テクノロジー事業、その他事業および連結消去、グループ連結\n親会社の株主に帰属する純利益 95,018 16,083 16,766 2,476 2,959 5,737 7,936 (3,876) 143,099\n少数株主持分 1,054 76 12,162 3 143 974 1,567 281 16,260\n純利益 (A) 96,072 16,159 28,928 2,479 3,102 6,711 9,503 (3,595) 159,359\n除外項目:\n 短期投資の変動(1)(B) 10,308 – – – – – – – 10,308\n 割引率変更の影響 (C) (7,902) – – – – – – – (7,902)\n 経営陣が日常の営業収益および支出の一部ではないとして除外した一時的な重要項目およびその他 (D) – – – – – – 1,282 – 1,282\n営業利益 (E=A-B-C-D) 93,666 16,159 28,928 2,479 3,102 6,711 8,221 (3,595) 155,670\n親会社の株主に帰属する営業利益 92,672 16,",
        "id": "8066c16048bd722d030a85ee8b1***36d5f31624b28f1c0c15943855c5ae5c9f",
        "metadata": {
          "page_label": "19",
          "file_name": "2021-02-04_XX_Insurance_Group_Co_Ltd_XXX_China_XX_2020_Annual_Report.pdf",
          "file_path": "oss://my-bucket-name/datasets/chatglm-fintech/2021-02-04__XX_Insurance_Group_Co_Ltd__601318__China_XX__2020_Annual_Report.pdf",
          "file_type": "application/pdf",
          "file_size": 7982999,
          "creation_date": "2024-10-10",
          "last_modified_date": "2024-10-10"
        }
      }
    ]

機能詳細

ナレッジベースのタイプ

ナレッジベースは、ドキュメント、構造化データ、イメージの 3 種類に分類されます。ファイル形式に対応するナレッジベースのタイプを選択してください。

  • ドキュメント.html.htm.pdf.txt.docx.md、および .pptx をサポートします。

  • 構造化データ: .jsonl.csv.xlsx、および .xls をサポートします。

  • 画像: .jpg.jpeg.png、および .bmp をサポートします。

特別な設定:

  • ドキュメントタイプのナレッジベースでは、Chunk Configuration で以下のフィールドを設定する必要があります。詳細については、「チャンキングパラメーターのチューニング」をご参照ください。

    • Chunk Size各テキストチャンクの最大文字数を指定します。デフォルト値は 1024 です。

    • Chunk Overlap隣接するテキストチャンク間で重複する文字数を指定します。これにより、取得された情報の一貫性が確保されます。デフォルト値は 200 文字です。

  • 構造化データのナレッジベースにはField Settingsが必要です。animal.csv などのファイルをアップロードするか、手動でフィールドを追加し、インデックス作成用と取得用に個別に指定することができます。

ベクトルデータベースの選択

  • 本番環境:大規模なベクトルデータの処理をサポートするため、本番環境では Milvus または Elasticsearch の使用を推奨します。

  • テスト環境: FAISS は個別のデータベースを必要としないため、使用を推奨します (ナレッジベースファイルと生成されたマニフェストは Output OSS Path に保存されます)。機能テストや少量のファイルの処理に適しています。ファイル量が大きいと、取得と処理のパフォーマンスに大きな影響を与えます。

    説明

    イメージナレッジベースは FAISS をサポートしていません。

インデックス更新戦略

更新方法

説明

注意事項

手動更新

コンソールで手動でUpdate Indexをクリックします。このメソッドは、ファイルが頻繁に変更されないシナリオに適しています。

各更新では、データソース内のファイルに対して完全または増分処理が実行されます。

自動更新

コンソールで自動更新を有効にすると、システムは EventBridge にイベントルールを自動的に作成し、OSS ファイルの変更メッセージを転送してインデックスタスクを自動的に作成します。

重要

自動更新サービス中にメッセージ料金が発生します。

  • 設定が有効になるまで数分の遅延があります。OSS ファイルを操作する前に 3 分間待ってください。

  • 現在サポートされているリージョン:杭州、上海、北京、ウランチャブ、深セン。

定期更新

DataWorks の定期タスクを設定して、毎日など指定した頻度でインデックスを更新します。

この機能は DataWorks サービスに依存します。DataWorks の定期タスクは通常、翌日 (T+1) に有効になります。つまり、今日行われた設定は明日初めて実行されます。

設定方法は以下の通りです:

手動更新

ファイルをアップロードした後、右上隅のUpdate Indexをクリックします。 その後、PAI フロータスクが送信され、OSS データソース内のファイルが前処理、チャンク化、ベクター化されてインデックスが構築されます。 このタスクのパラメーターは次のとおりです。

パラメーター

説明

計算リソース

ワークフローノードタスクの実行に必要な計算リソース。パブリックリソースを使用するか、リソースクォータを通じてLingjun リソースと一般的なコンピューティングリソースを使用できます。

  • イメージナレッジベースのインデックスを更新する場合、ノード数は 2 より大きくする必要があります。

  • 複雑な PDF から高品質なチャートを抽出する場合、インデックス更新時にドライバーバージョンが 550 以上の GPU リソースを使用することを推奨します。これらのリソースとドライバー要件を満たすタスクに対して、システムは自動的にモデルを呼び出してチャート検出または OCR を実行します。イメージは出力パスの chunk_images ディレクトリに格納されます。アプリケーションフローで使用されると、テキスト内のイメージは HTML の <img> タグ (例:<img src="temporary signed URL">) に置き換えられます。

VPC 設定

内部ネットワーク経由でベクトルデータベースまたは埋め込みサービスにアクセスする場合、選択した VPC がこれらのサービスの VPC と同じであるか、接続されていることを確認してください。

埋め込み設定

  • 最大同時実行数 (イメージナレッジベースの場合):埋め込みサービスへの同時リクエスト数。Model Studio のマルチモーダルモデルサービスはリクエストを毎分 120 に制限しているため、この同時実行数を増やすとスロットリングがトリガーされる可能性があります。

  • バッチサイズ (ドキュメント/構造化データナレッジベースの場合):ベクトル化中に各バッチで処理されるテキストチャンクの数。モデルサービスの QPS 制限に基づいて適切な値を設定すると、処理速度が向上します。

自動更新

  1. EventBridge コンソールに移動して EventBridge をアクティブ化します。

  2. 自動インデックス更新を設定するには、ナレッジベースの詳細ページに移動します。Overview タブの右下隅にある Automatic File Indexing エリアで [編集] をクリックします。image

  3. 計算リソースと VPC を設定し、[OK] をクリックします。これにより、ファイルの変更が自動的にインデックスタスクをトリガーするため、手動でトリガーする必要はなくなります。

    重要

    ここで設定された計算リソースは、ファイルが更新されるときにのみ使用されます。リソース料金は、ファイルが更新されるときにのみ発生します。

  4. OSS ファイルの変更

    • ファイルの自動更新を設定した後、ルールが有効になるまで数分かかります。ファイルを変更する前に、少なくとも 3 分待つことを推奨します。

    • OSS API を使用してファイルを削除する場合、バージョンを指定する必要があります。そうしないと、変更メッセージがトリガーされません。

    • コンソールでファイルを削除するには、ファイルを選択し、下部にある [完全に削除] をクリックします。

      image

  5. インデックスタスクの表示。ファイルが変更された後、約 3 分待ちます。その後、[操作レコード] リストで自動的にトリガーされたインデックス構築タスクを確認できます。

定期更新

重要

時間指定スケジューリング機能は DataWorks に依存します。サービスをアクティブ化していることを確認してください。サービスがアクティブ化されていない場合は、「DataWorks サービスのアクティブ化」をご参照ください。

ナレッジベースの詳細ページで、右上隅の [その他] > Configure Scheduling をクリックします。次に、構成を完了し、[送信] をクリックします。

image

  • スケジューリング設定と定期タスクの表示

    フォームを送信すると、システムは DataWorks のデータ開発センターにスケジュールされたワークフローを自動的に作成し、DataWorks のオペレーションセンターで定期タスクとして公開します。この定期タスクは翌日 (T+1) に有効になり、設定した時間にナレッジベースを更新します。ナレッジベースのスケジューリング設定ページで、スケジューリング設定と定期タスクを表示できます。

    image

  • 時間指定スケジューリングのパラメーター説明

    • スケジューリングサイクル: 本番環境でノードが実行される頻度を定義します。この設定により、定期インスタンスの数とその実行時間が決まります。

    • スケジュール時刻:ノードが実行される特定の時刻を定義します。

    • タイムアウト定義:ノードがタイムアウトして失敗するまでの最大実行時間を定義します。

    • 有効日: ノードが自動的に実行されるようにスケジュールされる時間範囲を定義します。この範囲外では、ノードは自動的にスケジュールされません。

    • スケジューリングリソースグループ: DataWorks の時間指定スケジューリング機能用のリソースグループです。リソースグループがない場合は、ドロップダウンリストの [今すぐ作成] をクリックして作成します。リソースグループを作成したら、現在のワークスペースにアタッチします。

      image

    スケジューリングパラメーターの詳細については、「時間プロパティ設定の説明」をご参照ください。

データセットの表示

インデックス更新タスクが正常に完了すると、システムは自動的にOutput OSS Pathをデータセットとして登録します。データセットはAI アセット管理 - データセットで表示できます。このデータセットはナレッジベースと同じ名前で、インデックス構築プロセスからの出力が含まれています。

image

ランタイムの設定

ドキュメントチャンクのプレビューや取得のテストなどの操作を実行するには、ランタイムを選択する必要があります。これらの操作には、ベクトルデータベースと埋め込みサービスへのアクセスが必要です。

次のランタイム設定に注意してください:

  • 内部ネットワークエンドポイント経由でベクトルデータベースまたは埋め込みサービスにアクセスする場合、ランタイムの VPC がデータベースとサービスの VPC と同じであるか、接続されていることを確認してください。

  • インスタンス RAM ロールにカスタムロールを選択する場合、そのロールに OSS アクセス権限を付与する必要があります。AliyunOSSFullAccess 権限を付与することを推奨します。詳細については、「RAM ロールへの権限付与」をご参照ください。

重要

ランタイムバージョンが 2.1.4 より前の場合、ドロップダウンリストに表示されないことがあります。この問題を解決するには、新しいランタイムを作成してください。

マルチバージョン管理

バージョンクローン機能を使用すると、v1 などのテスト済みのナレッジベースを新しい公式バージョンとして公開できます。これにより、開発環境と本番環境が分離されます。

バージョンのクローン作成に成功すると、ナレッジベースの詳細ページで異なるバージョンを切り替えて管理できます。また、アプリケーションフローのナレッジベース取得ノードで目的のバージョンを選択することもできます。

image

バージョンのクローンはインデックスの更新に似ています。この操作はワークフロータスクを送信します。操作レコードリストでタスクを表示できます。

image

取得パラメーターの設定

  • Top K: ナレッジベースから取得する関連テキストチャンクの最大数。値の範囲は 1 から 100 です。

  • スコアしきい値: 0 から 1 の範囲の類似性スコアのしきい値。このしきい値を超えるスコアを持つチャンクのみが返されます。値が高いほど、テキストとクエリ間の類似性要件が厳しくなります。

  • 取得パターン:デフォルトのパターンは Dense (ベクトル検索) です。ハイブリッド検索 (ベクトルとキーワード) を使用したい場合、ベクトルデータベースは Milvus 2.4.x 以降、または Elasticsearch である必要があります。取得パターンの選択方法の詳細については、「取得モードの選択」をご参照ください。

  • メタデータフィルター条件:メタデータを使用して取得範囲をフィルタリングし、精度を向上させます。詳細については、「メタデータの使用」をご参照ください。

  • クエリ書き換え:大規模言語モデルを使用して、曖昧、口語的、または文脈に依存するユーザークエリを最適化します。このプロセスは、クエリをより明確で完全なものにすることでユーザーの意図を明確にし、取得精度を向上させます。使用シナリオの詳細については、「クエリ書き換え」をご参照ください。

  • 結果のリランキング:リランキングモデルを使用して初期の取得結果を再順位付けし、最も関連性の高い結果を先頭に移動させます。使用シナリオの詳細については、「結果のリランキング」をご参照ください。

    説明

    結果のリランキングにはリランキングモデルが必要です。サポートされているモデルサービス接続タイプには、Model Studio 大規模言語モデルサービス、AI Search Open Platform モデルサービス、および一般的なリランカーモデルサービスが含まれます。

トラブルシューティング

インデックス更新またはバージョンクローンタスクが失敗した場合は、次の手順でトラブルシューティングを行ってください:

  1. 操作履歴の表示: ナレッジベースの詳細ページで、Operation Records で失敗したタスクを見つけ、[タスクの表示] をクリックします。image

  2. タスクログの確認:システムは PAI ワークフローページにリダイレクトします。失敗したノードのログを確認してください。imageたとえば、ドキュメントナレッジベースのインデックスを更新するためのワークフロータスクには、次の 3 つのノードが含まれます。read-oss-file ノードを除き、各ノードは PAI-DLC タスクを作成します。ログの Job URL を使用して DLC タスクの詳細を表示することもできます。

    • read-oss-file: OSS ファイルを読み取ります。

    • rag-parse-chunk: ドキュメントの前処理とチャンク化を処理します。

    • rag-sync-index: テキストチャンクの埋め込みとベクトルデータベースへの同期を処理します。

取得の最適化

チャンクパラメーターの調整: 取得の基盤を構築

指導原則

  1. モデルのコンテキスト制限: チャンクサイズが埋め込みモデルのトークン制限を超えないようにして、情報の切り捨てを回避します。

  2. 情報の完全性:チャンクは完全なセマンティクスを含むのに十分な大きさであるべきですが、情報が多すぎて類似度計算の精度が低下するのを避けるために、十分に小さい必要があります。テキストが段落ごとに構成されている場合は、チャンク化を段落に合わせて設定し、恣意的な分割を避けることができます。

  3. 連続性の維持:チャンクサイズの 10% から 20% 程度の適切なオーバーラップサイズを設定し、チャンク境界で重要な情報が分割されることによるコンテキストの損失を効果的に防ぎます。

  4. 反復的な干渉の回避: 過度の重複は重複した情報を導入し、取得効率を低下させる可能性があります。情報の完全性と冗長性の間でバランスを見つける必要があります。

デバッグの提案

  • 反復的な最適化:チャンクサイズ 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 (ベクトル) 取得

  • 長所: 強力なセマンティック理解。同義語やコンテキストの関連付けなど、複雑なセマンティック関係をキャプチャできます。複雑なクエリに優しい。長いテキストやオープン ドメインの Q&A に適しています。

  • 短所: キーワードに敏感ではない。完全な用語の一致を見逃す可能性があります。有効性は埋め込みモデルの品質に依存します。

  • オープン ドメイン Q&A: 深いセマンティック理解を必要とするシナリオ (学術論文の取得、一般的な知識の Q&A など)。

  • 多義語/同義語のシナリオ: クエリとドキュメントは異なる単語を使用しているが、セマンティックに関連している (「心臓病」と「心筋梗塞」など)。

  • 長いテキストのマッチング: 技術文書や長いレポートから段落を取得するなど。

Sparse (キーワード) 取得

  • 長所: 正確なキーワードマッチング。結果は解釈性が高い。デバッグと最適化が容易。

  • 短所: セマンティクスを理解できない。同義語や一貫性のない表現をうまく処理できない。トークン化の品質に依存する。スペルやトークン化のエラーに敏感。

  • 構造化データ取得: データベースフィールドのクエリやテーブルデータのマッチングなど。

  • 明確なキーワードがあるシナリオ: ユーザーが正確な用語を入力する (「IPv6 アドレス形式」など)。

  • 低リソース言語: 高品質の事前トレーニング済みベクトルモデルを必要としない。リソースが少ない言語に適しています。

ハイブリッド取得

  • 長所: セマンティック理解とキーワードマッチングのバランスを取ります。より堅牢 (単一の取得モードが失敗しても有効性を維持)。通常、最良の結果を提供します。

  • 短所: 2 つの取得システムを同時に実行する必要があるため、計算コストが高くなります。融合の重みとパラメーターの調整が必要で、複雑です。

  • 複雑な混合要件: セマンティックマッチングと正確なキーワードマッチングの両方を満たす必要がある (医療 Q&A など、症状の説明を理解し、専門用語を照合する必要がある)。

  • 結果の多様性に対する高い要求: 単一モードによる結果の均質化を回避する (e コマース検索など、「価格に敏感」と「セマンティックに関連」の両方のユーザーニーズをカバーする必要がある)。

  • コールドスタート段階: 高品質のベクトルモデルが利用できない場合、キーワード結果を混合すると初期パフォーマンスが向上します。

メタデータの使用: 取得のフィルタリング

メタデータフィルタリングの価値

  1. 正確な取得、ノイズの低減:メタデータは、取得中にフィルター条件またはソートに使用できます。これにより、無関係なドキュメントを除外し、生成モデルが無関係なコンテンツを受け取るのを防ぎます。たとえば、ユーザーが「劉慈欣が書いた SF 小説を探す」と尋ねた場合、システムはメタデータ条件 author=劉慈欣category=SF を使用して、最も関連性の高いドキュメントを直接特定できます。

  2. ユーザーエクスペリエンスの向上

    • パーソナライズされた推奨をサポート: メタデータを使用して、「SF」ドキュメントを好むなど、ユーザーの過去のプリファレンスに基づいてパーソナライズされた推奨を提供できます。

    • 結果の解釈可能性の向上: 作成者、ソース、日付などのドキュメントメタデータを結果に含めることで、ユーザーはコンテンツの信頼性と関連性を判断しやすくなります。

    • 多言語またはマルチモーダル拡張をサポート: 「言語」や「メディアタイプ」などのメタデータにより、複数の言語とテキストと画像の混合を含む複雑なナレッジベースを簡単に管理できます。

使用方法

重要

機能の制限:

  • ランタイムイメージバージョン: 2.1.8 以降である必要があります。

  • ベクトルデータベース: Milvus と Elasticsearch のみがサポートされています。

  • ナレッジベースタイプ: ドキュメントまたは構造化データをサポートします。画像はサポートされていません。

  1. メタデータ変数を設定します。 Milvus のみを使用するナレッジベースでは、Overview タブの Metadata セクションで [編集] をクリックして、author などの変数を設定できます。システム予約フィールドは使用しないでください。

    image

  2. ドキュメントのタグ付け。 ドキュメントチャンク詳細ページで、Edit Metadata をクリックして、author=Alex などのメタデータ変数と値を追加します。 その後、概要ページに戻ると、メタデータのリファレンスステータスと値の数を表示できます。

    image

  3. フィルターのテストRecall Test タブで、メタデータフィルター条件を追加し、テストを実行できます。

    image

    注: 画像で取得されたドキュメントは、ステップ 2 でタグ付けされたドキュメントです。

  4. アプリケーションフローで使用します。ナレッジベースノードでメタデータフィルター条件を設定します。

    image

クエリの再書き込みと結果の再ランキング: 取得チェーンの最適化

クエリの再書き込み

大規模言語モデルを使用して、ユーザーの曖昧、口語的、または文脈に依存するクエリを、より明確で、完全で、独立した質問に書き換えます。これにより、後続の取得の精度が向上します。

  • 推奨されるシナリオ:

    • ユーザーのクエリが曖昧または不完全である場合 (例: コンテキストなしの「彼はいつ生まれましたか?」)。

    • マルチターン対話で、クエリがコンテキストに依存する場合 (例: 「その後、彼は何をしましたか?」)。

    • 取得機能または LLM が元のクエリを正確に理解するのに十分な能力がない場合。

    • セマンティック取得ではなく、BM25 などの従来の転置インデックス取得を使用している場合。

  • 推奨されないシナリオ:

    • ユーザーのクエリがすでに非常に明確で具体的である場合。

    • LLM が強力で、元のクエリを正確に理解できる場合。

    • システムが低レイテンシーを必要とし、書き換えによる追加の遅延を許容できない場合。

結果の再ランキング

取得機能によって返された初期結果を再ランキングして、最も関連性の高いドキュメントを最初に表示し、ランキングの品質を向上させます。

  • 推奨されるシナリオ:

    • BM25 や DPR などの初期取得機能からの結果の品質が不安定な場合。

    • 検索や Q&A システムなど、Top-1 の精度が要求されるシナリオのように、取得結果のランキングが重要な場合。

  • 推奨されないシナリオ:

    • システムリソースが限られており、追加の推論オーバーヘッドを処理できない場合。

    • 初期取得機能がすでに十分に強力で、再ランキングによる改善が限定的な場合。

    • リアルタイム検索シナリオなど、応答時間が非常に重要な場合。