Pipeline steps
==============

AIパイプラインの各ステップは、その操作タイプとオプションの構成オブジェクトによって定義されます。オペレーション名を文字列として\ ``aidb.create_pipeline()``
の\ ``step_N``
パラメーターに渡し、構成をJSONBとして対応する\ ``step_N_options``
パラメーターに渡します。

.. code:: sql

   SELECT aidb.create_pipeline(
       name              => my_pipeline,
       source            => my_source_table,
       source_key_column => id,
       source_data_column => content,
       step_1            => ChunkText,
       step_1_options    => aidb.chunk_text_config(desired_length => 120, max_length => 150),
       step_2            => KnowledgeBase,
       step_2_options    => aidb.knowledge_base_config(model => bert, data_format => Text)
   );

以下で説明するヘルパーファンクションを使用して、各操作タイプの\ ``step_N_options``
値を構築します。すべてのヘルパーファンクションは、\ ``JSONB``
構成オブジェクトを結果ます。

中間ストレージ
--------------

すべてのステップは、自分の出力を次のステップまたは最後のステップの場合、パイプラインの最終宛先に渡すことに加えて、自分自身の出力を専用のテーブルに永続化できます。これは、マルチステップパイプラインのデバッグ、またはパイプラインの外部で中間結果チャンクテキストなどを再利用する場合に役立ちます。デフォルトではオフになっています。

そのステップの\ ``step_N_options`` の\ ``intermediate_destination``
キーで設定します。ステップ構成ヘルパー\ ``aidb.chunk_text_config()``
、\ ``aidb.pdf_parse_config()``
などにはまだパラメーターがないため、ヘルパー自分の出力とともにプレーンJSONとして追加し、\ ``||``
演算子とマージします。

.. code:: sql

   step_1_options => aidb.chunk_text_config(desired_length => 100) || jsonb_build_object(
       intermediate_destination, jsonb_build_object(enabled, true)
   )

または、\ ``jsonb_build_object()``
を使用してオプションオブジェクト全体を直接ビルドします。

.. code:: sql

   step_1_options => jsonb_build_object(
       desired_length, 100,
       intermediate_destination, jsonb_build_object(enabled, true)
   )

.. csv-table::
  :header: Key,Type,Default,Description
  :widths: 15,12,12,20
  :align: left
  :class: longtable

  `enabled`,BOOLEAN,Required,このステップの中間ストレージをオンにします。
  `destination`,TEXT,NULL,ステップの出力を保存するテーブル。省略すると`pipeline_<name>_step_<N>`として自動生成されます。

最も単純なフォームは、それをオンにして、AIDBにテーブルに名前を付けます。

.. code:: json

   {"enabled": true}

または、宛先テーブルに明示的に名前を付けます。

.. code:: json

   {"enabled": true, "destination": "my_custom_chunk_storage"}

宛先テーブルは、他のパイプライン宛先テーブル\ ``source_id``
、\ ``part_ids`` 、およびステップの出力を保持する\ ``value``
列と同じ形状です。

パイプラインの **last** ステップで\ ``intermediate_destination``
を設定しても、テーブルを作成してそれに書き込みますが、
:ref:`promoteb.retrieve_text() <promoteb.retrieve_text()>` の\ ``intermediate_steps``
列がそれを表面化することはありません。そのルックアップは、最後の「次のステップ」がないため、最後のステップの前のステップのみを考慮します。自分の出力が中間になる前に。読み取る必要がある場合は、代わりに宛先テーブルを直接照会します。これは\ ``KnowledgeBase``
にとって最も重要であり、これは常にパイプラインの最後のステップである必要があります。したがって、中間ストレージを有効にする理由はほとんどありません。

!!!note ``intermediate_destination`` は、\ ``enabled``
キーおよびオプションで\ ``destination``
を持つオブジェクトである必要があります。他のJSONタイプは、パイプラインの作成時にエラーを発生します。

::

   ERROR:  Invalid options for step 1: intermediate_destination must be an object with keys enabled and optionally destination; got a string

.. ::
   完全な例については、 :ref:`エンドツーエンドの例 中間ストレージを使用したマルチステップパイプライン <エンドツーエンドの例 中間ストレージを使用したマルチステップパイプライン>` を参照してください。クエリー時に中間結果を読み取るには、これが`deduplicate` との相互作用を含む、 :ref:`promoteb.retrieve_text() <promoteb.retrieve_text()>` および :ref:`重複排除と中間結果 <重複排除と中間結果>` を参照してください。

ChunkText
---------

LLMコンテキストウィンドウ内に収まるように、テキストを小さなセグメントに分割します。

**ヘルパーファンクション** ``aidb.chunk_text_config()``

.. csv-table::
  :header: Parameter,Type,Default,Description
  :widths: 15,12,12,20
  :align: left
  :class: longtable

  `desired_length`,`INTEGER`,Required,ターゲットチャンクサイズ。単位は`strategy`に依存します。
  `max_length`,`INTEGER`,`NULL`,最大チャンクサイズ。省略した場合、`desired_length`は厳密な上限です。
  `overlap_length`,`INTEGER`,`NULL`,連続するチャンク間でオーバーラップするコンテンツの量。デフォルト0オーバーラップなし。
  `strategy`,`TEXT`,`NULL`,文字ベースの場合は`'chars'`デフォルト、ワードベースのチャンクの場合は`'words'`。

**基本的なチャンクの例**

.. code:: sql

   SELECT aidb.create_pipeline(
       name               => chunk_pipeline,
       source             => source_table,
       source_key_column  => id,
       source_data_column => content,
       step_1             => ChunkText,
       step_1_options     => aidb.chunk_text_config(
           desired_length => 100,
           max_length     => 150,
           overlap_length => 20,
           strategy       => words
       )
   );

結果
^^^^

``ChunkText`` は、 ``part_id``
列を導入することにより、データの形状を変換します。各ソース行は、チャンクごとに1つずつ、複数の出力行を生成する場合があります。

ParseHtml
---------

HTML文字列から可読テキストを抽出し、論理構造を保持しながらタグを削除します。

**ヘルパーファンクション** ``aidb.html_parse_config()``

.. csv-table::
  :header: Parameter,Type,Default,Description
  :widths: 15,12,12,20
  :align: left
  :class: longtable

  `method`,`TEXT`,`NULL`,プレーンテキスト抽出の場合は`'StructuredPlaintext'`デフォルト、または階層を保持する場合は`'StructuredMarkdown'`。

.. code:: sql

   SELECT aidb.create_pipeline(
       name               => html_pipeline,
       source             => web_data_table,
       source_key_column  => id,
       source_data_column => html_content,
       step_1             => ParseHtml,
       step_1_options     => aidb.html_parse_config(method => StructuredMarkdown),
       step_2             => ChunkText,
       step_2_options     => aidb.chunk_text_config(desired_length => 120)
   );

.. _結果-1:

結果
^^^^

``ParseHtml``
は結果のネストを解除しません。各ソース行は、元の行の対応関係が保持された状態で、抽出されたテキストを含む出力行を1つだけ生成します。
``ChunkText``
とペアにして、上記の例のように、抽出されたテキストをより小さなセグメントに分割します。

ParsePdf
--------

非準拠または複雑なファイルを処理するオプションを使用して、バイナリPDFデータからテキストを抽出します。

**ヘルパーファンクション** ``aidb.pdf_parse_config()``

.. csv-table::
  :header: Parameter,Type,Default,Description
  :widths: 15,12,12,20
  :align: left
  :class: longtable

  `method`,`TEXT`,`NULL`,`'Structured'` デフォルト — PDF仕様を使用してテキストブロックを識別します。
  `allow_partial_parsing`,`BOOLEAN`,`NULL`,`true`デフォルトの場合、個々のページでエラーが発生した場合に解析を続行します。

結果の\ ``part_id``
列は、各テキストブロックが抽出されたページインデックスにマップします。

.. code:: sql

   SELECT aidb.create_pipeline(
       name               => pdf_pipeline,
       source             => pdf_files_table,
       source_key_column  => id,
       source_data_column => pdf_data,
       step_1             => ParsePdf,
       step_1_options     => aidb.pdf_parse_config(
           method                => Structured,
           allow_partial_parsing => true
       ),
       step_2             => KnowledgeBase,
       step_2_options     => aidb.knowledge_base_config(model => bert, data_format => Text)
   );

.. _結果-2:

結果
^^^^

``ParsePdf``
は結果のネストを解除します。マルチページPDFはページごとに1行を生成し、それぞれにページインデックスに対応する\ ``part_id``
があります。

PdfToImage
----------

PDFドキュメントの各ページを画像に変換します。
ソースPDFがスキャンされた文書、画像の多いレイアウト、またはテキストレイヤーが存在しないまたは信頼できないPDFである場合、この手順を使用します。
レンダリングされたページ画像は、テキスト抽出のために\ ``PerformOcr``
ステップに直接渡すことができます。

ネイティブテキストレイヤーを含むデジタル生成PDFの場合、代わりに\ ``ParsePdf``
を使用します。より速く、OCRモデルは必要ありません。

**オプション形式** オプションをJSONリテラルとして渡します。

.. csv-table::
  :header: Parameter,Type,Default,Description
  :widths: 15,12,12,20
  :align: left
  :class: longtable

  `dpi`,`INTEGER`,`300`,各ページのレンダリングに使用される1インチあたりのドット数の解像度。値が高いほど、より鮮明な画像が生成されますが、ファイルサイズが大きくなります。
  `first_page`,`INTEGER`,`NULL`,レンダリングする最初のページ1ベース。省略すると最初からレンダリングされます。
  `last_page`,`INTEGER`,`NULL`,レンダリングする最後のページ。1ベースを含みます。省略すると最後までレンダリングされます。
  `max_pages`,`INTEGER`,`NULL`,レンダリングするページの最大数。 `first_page`および`last_page`に関係なく、安全キャップとして機能します。
  `render_annotations`,`BOOLEAN`,`true`,レンダリングされた出力にPDFの注釈コメントやフォームフィールドなどを含めるかどうか。
  `format`,`JSONB`,"`{""type"": ""png""}`","出力画像フォーマット。受け入れられる値 `{""type"": ""png""}`、`{""type"": ""jpeg""}`。出力を`PerformOcr`に渡す場合は、`{""type"": ""png""}`を使用します。"

出力画像は、 ``format``
オプションに応じて、PNGまたはJPEG形式です。出力を\ ``PerformOcr``
ステップに渡すときは、\ ``"png"`` デフォルトを使用します — NVIDIA NIM
PaddleOCRには、PNGまたはJPEG入力が必要です。

``PerformOcr``
を含むパイプラインでこのステップを使用する前に、OCR対応モデルを登録します。

.. code:: sql

   SELECT aidb.create_model(
       my_paddle_ocr_model,
       nim_paddle_ocr,
       credentials => {"api_key": "<NVIDIA_NIM_API_KEY>"}::JSONB  -- or credentials_env to read this from an environment variable instead
   );

次に、パイプラインを作成します。

.. code:: sql

   SELECT aidb.create_pipeline(
       name               => pdf_ocr_pipeline,
       source             => pdf_files_table,
       source_key_column  => id,
       source_data_column => pdf_data,
       step_1             => PdfToImage,
       step_1_options     => {"dpi": 150}::json,
       step_2             => PerformOcr,
       step_2_options     => aidb.ocr_config(model => my_paddle_ocr_model),
       step_3             => KnowledgeBase,
       step_3_options     => aidb.knowledge_base_config(model => bert, data_format => Text)
   );

.. _結果-3:

結果
^^^^

``PdfToImage`` は結果のネストを解除します。ソースPDFの各ページは、
``format``
オプションに応じて、PNGまたはJPEG画像としてレンダリングされたページを含む1つの出力行を生成します。
``part_id`` 列は、ページインデックス0ベースにマップします。
この出力形状は、入力としてイメージバイトを想定する\ ``PerformOcr``
ステップと直接互換性があります。

PerformOcr
----------

NVIDIA NIM
PaddleOCRなどのOCR対応AIモデルを使用して、画像からテキストを抽出します。

**ヘルパーファンクション** ``aidb.ocr_config()``

.. csv-table::
  :header: Parameter,Type,Default,Description
  :widths: 15,12,12,20
  :align: left
  :class: longtable

  `model`,`TEXT`,Required,使用する登録済みのOCRモデルの名前。

この手順を使用する前に、OCR対応モデルを登録します。

.. code:: sql

   SELECT aidb.create_model(
       my_paddle_ocr_model,
       nim_paddle_ocr,
       credentials => {"api_key": "<NVIDIA_NIM_API_KEY>"}::JSONB  -- or credentials_env to read this from an environment variable instead
   );

次に、パイプラインでそれを参照します。

.. code:: sql

   SELECT aidb.create_pipeline(
       name               => ocr_pipeline,
       source             => images_table,
       source_key_column  => id,
       source_data_column => image_data,
       step_1             => PerformOcr,
       step_1_options     => aidb.ocr_config(model => my_paddle_ocr_model),
       step_2             => KnowledgeBase,
       step_2_options     => aidb.knowledge_base_config(model => bert, data_format => Text)
   );

.. _結果-4:

結果
^^^^

``PerformOcr``
は結果のネストを解除します。単一の画像から、検出されたテキストブロックごとに1つずつ、複数の行が生成される場合があります。
NVIDIA NIMプロバイダーは、現在\ ``png`` および\ ``jpeg``
形式のみをサポートしています。

SummarizeText
-------------

AI言語モデルを使用して、長いテキストの一節の簡潔な概要を生成します。

**ヘルパーファンクション** ``aidb.summarize_text_config()``

.. csv-table::
  :header: Parameter,Type,Default,Description
  :widths: 15,12,12,20
  :align: left
  :class: longtable

  `model`,`TEXT`,Required,要約に使用する登録モデルの名前。
  `chunk_config`,`JSONB`,`NULL`,要約前に適用されるオプションのチャンク構成`aidb.chunk_text_config()`から 。
  `prompt`,`TEXT`,`NULL`,概要をガイドするカスタムプロンプト。省略すると標準のプロンプトを使用します。
  `strategy`,`TEXT`,`NULL`,`'append'`デフォルトはチャンクごとのサマリーを連結するか、 `'reduce'`はそれらを反復圧縮します。
  `reduction_factor`,`INTEGER`,`NULL`,`'reduce'`ストラテジーで使用されます。反復ごとにテキストをどの程度積極的に削減するかを制御しますデフォルトは3です。
  `inference_config`,`JSONB`,`NULL`,オプションの実行時推論設定`aidb.inference_config()`から。

.. code:: sql

   SELECT aidb.create_pipeline(
       name               => summary_pipeline,
       source             => articles_table,
       source_key_column  => id,
       source_data_column => body,
       step_1             => SummarizeText,
       step_1_options     => aidb.summarize_text_config(
           model        => my_t5_model,
           chunk_config => aidb.chunk_text_config(100, 120, 10, words),
           prompt       => Summarize the key points concisely,
           strategy     => reduce,
           reduction_factor => 3
       ),
       step_2             => KnowledgeBase,
       step_2_options     => aidb.knowledge_base_config(model => bert, data_format => Text)
   );

ナレッジベース
--------------

処理されたテキストまたは画像データをベクター埋め込みに変換し、検索可能なナレッジベースに保存します。このステップは、その出力が後続のステップで入力として使用できない\ ``VECTOR``
タイプであるため、常にパイプラインの **最後のステップ**
である必要があります。セマンティックまたはハイブリッド検索を使用したナレッジベースの照会については、
:ref:`Knowledge bases reference <Knowledge bases reference>` を参照してください。

**ヘルパーファンクション** ``aidb.knowledge_base_config()``

.. csv-table::
  :header: Parameter,Type,Default,Description
  :widths: 15,12,12,20
  :align: left
  :class: longtable

  `model`,`TEXT`,Required,埋め込みモデルの名前。
  `data_format`,`aidb.PipelineDataFormat`,Required,`'Text'`または`'Image'`。
  `distance_operator`,`aidb.DistanceOperator`,`NULL`,類似度メトリック `L2`デフォルト 、`InnerProduct`、`Cosine`、`L1`、`Hamming`、または`Jaccard`
  `vector_index`,`JSONB`,`NULL`,`aidb.vector_index_hnsw_config()`などのベクターインデックスヘルパーでビルドされたベクターインデックス構成。

.. code:: sql

   SELECT aidb.create_pipeline(
       name               => kb_pipeline,
       source             => source_table,
       source_key_column  => id,
       source_data_column => content,
       step_1             => KnowledgeBase,
       step_1_options     => aidb.knowledge_base_config(
           model             => bert,
           data_format       => Text,
           distance_operator => Cosine,
           vector_index      => aidb.vector_index_hnsw_config(m => 16, ef_construction => 64)
       )
   );

``aidb.knowledge_base_config_from_kb(data_format)``
を使用して、パイプラインを既存のナレッジベースに接続します。これにより、複数のパイプラインが1つのベクターテーブルを共有でき、ナレッジベースからモデル、距離演算子、およびベクターインデックスを継承します。
:ref:`Multi-pipeline knowledge bases <Multi-pipeline knowledge bases>`  を参照してください。

宛先テーブル
^^^^^^^^^^^^

KnowledgeBaseステップは、 ``destination``
パラメーターで名前付けの宛先テーブルを作成します。 ``destination``
が設定されていない場合、テーブルはデフォルトの\ ``pipeline_<pipeline_name>``
に設定されます。複数のパイプラインがナレッジベースを共有する場合、それらはすべて同じテーブルに書き込みます。

.. csv-table::
  :header: Column,Type,Description
  :widths: 12,12,25
  :align: left
  :class: longtable

  `id`,BIGSERIAL,主キー。
  `pipeline_id`,INT,元のパイプラインへの参照。
  `source_id`,TEXT,元のソースレコードのID。
  `part_ids`,BIGINT[],データがチャンクまたは解析された場合、セグメントを追跡します。
  `value`,VECTOR,pgvector埋め込み。

ナレッジベースビュー、取得機能、およびライフサイクル動作については、
:ref:`Knowledge bases reference <Knowledge bases reference>` および :ref:`Knowledge bases reference <Knowledge bases reference>` を参照してください。

完全なエンドツーエンドのワークフローで一緒に使用されるパイプラインステップを確認するには、
:ref:`Examples <Examples>` を参照してください。
