Knowledge bases

Knowledge bases#

ナレッジベースKBには、エンベディングとその構成モデル、距離演算子、ベクトルインデックスが保存されます。パイプラインはそれに書き込み、 promoteb.retrieve_text() または promoteb.retrieve_key() を使用して名前で照会します。

ナレッジベースは、単一のパイプラインと ナレッジベース から始まります。同じナレッジベースに追加のパイプラインを接続できます。さまざまなソースまたは処理チェーンをすべて、1つの照会可能なベクトルテーブルへのエンベディングに貢献させます。

Page

What it covers

Multi-pipeline knowledge bases

Attach multiple pipelines to one KB; compatibility rules and deletion semantics

Hybrid search

Combining semantic search with relational filters and full-text search

Examples

End-to-end worked examples for table and volume sources

取得ファンクション#

パイプラインが実行されたら、 aidb.retrieve_text() またはaidb.retrieve_key() を使用してナレッジベースを照会します。どちらもベクトルの類似度を使用して、正確なキーワードではなく意味に基づいて結果を検索し、クエリ入力としてTEXT とBYTEA の両方をサポートしています。

検索機能の流れ#

取得ファンクションが呼び出されると、システムは内部で次の手順を実行します。

  • 埋め込み 入力クエリテキストまたは画像は、そのナレッジベース用に構成された特定の埋め込みモデルを使用してベクトルに変換されます。

  • 類似性検索 ベクトル類似性検索は、ナレッジベースの内部ベクトルテーブルに対して実行され、上位Kの最近傍を見つけます。

  • ソースルックアップテキストのみ retrieve_text の場合、システムはソーステーブルを識別し、一致したキーに対応する生のコンテンツを取得します。

promoteb.retrieve_text()#

このファンクションは、最も近いベクトル一致に関連付けられた実際のソーステキストを取得する必要がある場合に使用します。

  • プロセス ファンクションはクエリーを埋め込み、類似性検索を実行して、第2フェーズを実行して、pipeline_id を使用して元のテーブルからソーステキストをルックアップします。

  • 戻り値 以下を含む列のセット

  • key ソーステーブルの識別子

  • value 実際のソーステキスト

  • distance 類似性スコア。通常、低い値は、より近い一致を示します。

  • part_ids 一致した特定のチャンクまたはパーツを示すIDの配列。

  • pipeline_name データを提供したパイプラインの名前。

  • intermediate_steps intermediate_destination で構成されたステップ、ナレッジベースの前に発生するステップからのデータを含むJSONB列たとえば、ChunkText。パイプライン内のステップで中間ストレージが有効になっていない場合は空。これがdeduplicate とどのように相互作用するかについては、以下の 重複排除と中間結果 を参照してください。

promoteb.retrieve_key()#

このファンクションは、完全なソースコンテンツではなく、一致の一意の識別子のみが必要な高パフォーマンスの検索に使用します。

  • 戻り値 以下を含む列のセット

  • key ソーステーブルからの識別子

  • distance 類似度スコア。通常、低い値は、より近い一致を示します。

  • part_ids 一致した特定のチャンクまたはパーツを示すIDの配列。

  • pipeline_name データを提供したパイプラインの名前。

高度なクエリー 中間ステップの結合#

ChunkTextやParseHtmlなどの中間変換を含むパイプラインの場合、 part_ids 列を使用して取得結果を中間パイプラインテーブルと結合することにより、特定の変換済みセグメントにアクセスできます。これは、intermediate_steps 列の手動代替であり、 エンドツーエンドの例 中間ストレージを使用したマルチステップパイプライン が有効になっているステップでaidb.retrieve_text() が既に自動的に返しています。中間テーブルの追加列への結合など、intermediate_steps が提供しないものが必要な場合にのみ手動結合に手を伸ばします。

構文の例#

次のクエリは、取得結果を中間ステップテーブルと結合して、特定のチャンク値にアクセスします。

SELECT
    r.key,
    r.value,
    r.distance,
    r.part_ids,
    int_step.value AS chunked_content
FROM aidb.retrieve_text(my_kb, search query, 5) AS r
JOIN pipeline_my_pipeline_step_1 AS int_step
  ON int_step.source_id = r.key
  AND int_step.part_ids = (r.part_ids)[:1];

intermediate_steps と同様に、この結合は1つの行のみを参照しますdeduplicate 通過します — 次のセクションを参照してください。

重複排除と中間結果#

deduplicate aidb.retrieve_key() とaidb.retrieve_text() の両方のデフォルトtrue は、 ChunkText のようなステップがレコードをいくつかの独立した埋め込み部分に分割し、それらの部分のうちの複数の部分がクエリーと一致する場合でも、取得結果をソースレコードごとに1行に折りたたみます。 1つの部分のみが「勝ち」クエリーに最も近いものであり、そのpart_ids およびintermediate_steps は、そのソースレコードに対して返される唯一の部分です。

これは、チャンクまたは解析ステップで エンドツーエンドの例 中間ストレージを使用したマルチステップパイプライン を有効にするとすぐに重要になります。デフォルトのdeduplicate => true では、複数のチャンクが一致した場合でも、ソースレコードごとに一致するチャンクの中間コンテンツは one のみが表示されます。一致するすべての部分とそれぞれ独自のintermediate_steps エントリーを表示するには、 deduplicate => false で取得を呼び出します。

たとえば、パイプラインは、 intermediate_destination を有効にして動物に関する一連の短い記事をチャンク化するため、各チャンクのテキストはintermediate_steps で利用できます。デフォルトの重複排除で'ocean' を照会すると、whale 記事の最も一致するチャンクが勝ち、2番目のチャンクも一致した場合でも、他のwhale チャンクは表示されません。

Knowledge bases#

経験則として ソースレコードごとに1つの代表的な結果が必要な場合はdeduplicate => true デフォルトのままで、同じソースレコードから一致するすべてのチャンクまたは部分が必要な場合は常にdeduplicate => false を使用します。たとえば、長い文内のすべてのパッセージを表示する場合単一の最適なドキュメントだけでなく、クエリーにマッチしたドキュメント。

目次