DocumentEnricher、PageEnricher、ChunkEnricher
リクエストが求めたとき、1 つの文書・ページ・チャンクを要約しタグ付けするポート群。
プロトコル:
DocumentEnricher.id: EnricherIdDocumentEnricher.enrich(text: str) -> EnrichmentDocumentEnricherProvider.document_enrichers() -> tuple[DocumentEnricher, ...]PageEnricher.id: EnricherIdPageEnricher.enrich(text: str) -> EnrichmentPageEnricherProvider.page_enrichers() -> tuple[PageEnricher, ...]ChunkEnricher.id: EnricherIdChunkEnricher.enrich(text: str) -> EnrichmentChunkEnricherProvider.chunk_enrichers() -> tuple[ChunkEnricher, ...]
エンリッチャーは、テキストが何を述べているかと何についてかを答えます。Enrichment は
summary（テキスト自身の言語で書かれた散文）と tags（語彙がタクソノミーではなくエンリッチャー自身の
ものである LabelScore の並び）を運びます。どちらの部分も省略可能です。省かれた部分は「意見なし」であり、
空の Enrichment() は正当な答えです。言うことがない、という答えです。
これは注釈の格子における 3 つ目の戻り値の形で、ラベルとスパンの隣に並びます。要約はラベルではありません。 散文であって、集合からの選択ではないからです。タグはファセットのラベルではありません。事前に何も列挙して いないからです。そしてスパンでもありません。テキストがその語を含んでいる必要がないからです。単位の軸は 分類器のものと同じです。文書・ページ・チャンクごとに 1 つのポートがあり、1 つのクラスを 3 つのフック すべてから宣言できます。
分類と固有表現抽出がそれぞれのポートを得た後にモデルによるエンリッチメントに
残ったものは、まさにどちらの形でも運べないものでした。LabelScore を引き伸ばして文を持たせたり、
EntitySpan にテキストが含まない語を持たせたりすれば、要約を公表しながら、どのクライアントも要約として
読めないものを公開することになります。ADR-0029 の改訂トリガーはこのケース、つまりラベルでもスパンでも
ない戻り値の形を名指ししており、これがそれが求めたポートです
（ADR-0037）。
要約器とタグ付け器を分けず、両方の部分を 1 つのポートにしたのは、モデルは 1 回の呼び出しで両方を答え、 両方を求めるデプロイは 1 回だけ払うべきだからです。片方しか出せない実装はその片方を出し、もう片方を誰が 出すかはリクエストの順序が決めます。
入力は 1 つの単位の全文です。文書なら読み取れたすべてのページを順に連結したもの、ページならそのページの
テキスト、チャンクならそのチャンクのテキストです。エンリッチャーは自分で上限を適用します
（ADR-0033）。
indx_interfaces.excerpt が共有される「テキストの頭」の規則です。
各部分は別々に勝ち取られます。 要約を持つ最初の有効化済みエンリッチャーがその単位の要約を取り、 タグを持つ最初のものがタグを取ります。2 つ目のエンリッチャーは、最初のものが省いた部分を答えることで 異を唱えるのであって、置き換えることはありません。
ChunkEnricher はチャンク粒度を必要とし、リクエストが CHUNK を求めていなければ取得前に 422 で
拒否されます。未知の ID と、data_residency の下での external な実装も同じ形で、invalid_enricher
として拒否されます。理由は分類器のものと同じです。黙って飛ばされたエンリッチャーは、呼び出し側が与え
られたと信じて与えられなかった答えだからです。ID は分類器・抽出器のポートと 1 つの名前空間を共有します。
全部で 8 つです。
raise はログに残され、その単位は飛ばされます。device、cost_usd、builtin はプロトコルの外にあり、
既定値付きで読まれます。
- 要約はテキストが書かれている言語で書き、散文のままにする。空白の要約はモデルが拒否します。代わりに その部分を省いてください。
- タグは控えめに付け、順位を付ける。タグは主題についての主張であり、その信頼度は
LabelScoreと同じ 立場の自己申告です。 - 空の部分を出すくらいなら省く。
tags=()とタグなしは同じ答えであり、どちらも次のエンリッチャーに 発言させます。 - モジュールスコープを安価に保ち、エンジンは最初の呼び出しの背後で組み立てる。
- 動けないときは何も公表しない。エクストラなし、モデルなしなら、エンリッチャーなし。
システムの中の位置
Section titled “システムの中の位置”DocumentExecutor.encode は取得前に有効化された ID を解決し、レジデンシーを確認し、文書を読み、
チャンク粒度が求められていればチャンクに切り、有効化された各エンリッチャーにリクエストの順序で
各単位について尋ねます。
文書エンリッチャーの答えは文書ブロックの metadata に ENRICHMENT_METADATA_KEY（enrichment）
として、答えられた部分だけを持つ Enrichment のシリアライズ形で書かれます。ページエンリッチャーの答えは
同じキーで各ページブロックに書かれます。チャンクエンリッチャーの答えは、チャンクブロックがメタデータを
持たないため、文書ブロックの CHUNK_ENRICHMENT_METADATA_KEY（chunk_enrichment）にチャンクブロック ID を
キーとして乗ります
（ADR-0031）。
どちらのキーも予約されており、EncodeRequest.metadata はそれらを即座に拒否します。
トレースは、部分を勝ち取った各エンリッチャーを、答えたページと、facets としての部分名とともに
名指しします。POLICY_VERSION は動かず、機能スナップショット ID も動きません。snapshot.enrichers は
コンテンツハッシュの外にあるので、エンリッチャーをインストールしても未処理の計画は無効になりません。
2 つが同梱されます。indx-enrich-extractive は既定インストールが持つ床です。単位自身の語彙を最も多く運ぶ
文を、語の頻度で選び、そのまま文書の順に返します。近い文が 3 つで 1 つの要約にならないよう冗長性に
ペナルティを課します。タグは付けません。タグはテキストが含まなくてもよい語であり、それを作るにはモデルが要る
からです。indx-enrich-llm は llm エクストラと独自の INDX_ENRICH_LLM_* 接頭辞の背後で、チャットモデルに
1 回の呼び出しで両方の部分を尋ねます。