エンリッチメントフロー - Entity Enricher ドキュメント

エンリッチメントフロー

Entity Enricher が単一のエンティティを処理する流れを、入力から分類、並列モデル実行、構造化出力までステップごとに解説します。

パイプラインの概要

入力
エンティティ JSON
+ スキーマ
classification
任意の
型チェック
並列モデル
Claude
財務
規制
一般
GPT-4
財務
規制
一般
検証
型チェック
自己修正
出力
構造化
モデルごとの JSON

ステップ1: エンリッチメントを設定する

Workflow Editorページを開き、エンリッチメントを設定します。ワークフローステッパーが、Sample Data、Schema、Enrichment、Resultsというパイプラインの各ステージをガイドします。スキーマがdatabase syncにリンクされている場合はDatabase Readyステップも加わり、実行による変更がデータベース向けにキューされたことを確認します(または保存が拒否された理由を説明します)。

スキーマパネル(左)

サンプルJSONを貼り付けてスキーマを自動生成し、インタラクティブなプロパティツリーを探索しましょう。プロパティを編集し、エキスパティーズドメインを追加し、フィールドを検索キーまたは保持対象としてマークできます。

エンリッチメントパネル(右)

エンリッチメントのオプション(戦略、モデル、言語、分類、加えてレスポンススキーマと厳格な構造化出力の切り替え)を設定し、エンティティ検索キー(名称、ウェブサイト、国など)を入力してエンティティを特定します。

結果パネル

各モデルのリアルタイムの進捗と結果を表示します。複数のモデルを使用する場合、フュージョン用に「結果をマージ」ボタンが表示されます。

トークンを消費する前に確認される内容

使える結果を返しようがないリクエストもあります。それに気づく最も安上がりなタイミングは、最初の LLM 呼び出しの前です。そのため、2 つの契約を事前に検証します。

入力コントラクト

スキーマは、入力に何が含まれていなければならないかを規定します。どのエンティティであるかを示すキーフィールド、指定する配列の各要素のキー、そしてpreserveが指定されたすべてのフィールドの値です(与えられていないものを保持することはできません)。いずれかが欠けているリクエストは、すべての違反を一度に列挙した単一のエラーとともに拒否されます。さらにスキーマの完全なコントラクトも返されるため、拒否のたびに要件を一つずつ発見するのではなく、一度で修正できます。このコントラクトは保存済みのすべてのスキーマで公開されるため、クライアントは送信前に確認できます。

クローズド配列のコントラクト

項目を指定した配列は厳密にエンリッチメントされます。モデルは各項目について把握している内容を埋めるだけで、項目を追加することも削除することもできません。明細を 5 件送れば、5 件が返ります。モデルが扱えなかった項目は失われることなくそのまま再挿入され、モデルが作り出した項目は破棄されます。空のままにした配列は開かれたままです — モデルが事実を発見するということであり、それこそが狙いです。

ステップ2: 事前classification(任意)

分類モデルを選択した場合、まず高速で低コストなLLM呼び出しが実行され、エンティティがスキーマのタイプに一致するかを検証します。これにより、エンティティが一致しない場合にエンリッチメントでトークンを無駄にすることを防ぎます。詳しくは分類のドキュメントをご覧ください。

非ブロッキング: 何らかの理由でクラシフィケーションが失敗しても、エンリッチメントは通常どおり続行されます。クラシフィケーションはあくまで補助的なもので、エンリッチメントのプロンプトにコンテキストを追加しますが、パイプラインをブロックすることはありません。

ステップ3: 戦略の実行

選択された各モデルは、指定した戦略を使ってエンティティを処理します。指定がない場合は、スキーマの構造から自動的に選ばれた戦略が既定で使われ、その内容は実行の開始時に報告されます。複数のモデルを選択した場合、それらはプロバイダーをまたいで並列に実行され(Claude と GPT-4 は同時に実行されます)、同一プロバイダーのモデルはレート制限を守るため順次実行されます。

マルチ専門領域の例(3領域)
1
expertiseごとにschemaを分割
プロパティはexpertise domainごとにグループ化されます。財務フィールド、規制フィールド、一般フィールドなどです。
2
並列LLM呼び出しを実行
各 expertise は、関連する schema プロパティのみを含む専用の prompt を受け取ります。すべて同時に実行されます。
3
結果を段階的にマージ
各専門領域が完了するたびに、その出力が蓄積された結果にマージされます。部分的な結果をリアルタイムで確認できます。
4
保持ロジックを適用
'preserve' とマークされたフィールドは元の値が復元され、入力データはそのまま保たれます。配列内では、エンリッチメントされた項目は位置ではなくキーフィールドによって入力項目と突き合わされるため、順序が入れ替わった応答でも正しい値が復元されます。

ステップ4: 検証と自己修正

各 LLM の応答は、リアルタイムで schema に対して検証されます。出力が期待される型や制約に一致しない場合、システムは自動的にエラーを LLM に返して修正させます。

自動的に修正される内容:
数値ではなく文字列
「42.2」は42.2になります
インデックス付きオブジェクトを配列として
{"0": "a", "1": "b"} は ["a", "b"] になります
文字列の null
「null」や「None」は実際のnullになります
モデルが判定できなかった値
値を捏造するのではなく宣言します。該当するパスは null になります

LLM 呼び出しごとに最大 5 回まで自動リトライします。各リトライには具体的な検証エラーが含まれるため、LLM は何を修正すべきかを正確に把握できます。修正は外科的で、誤って返された葉ノードだけを再度問い合わせ、回答全体をやり直すことはありません。

このリストに含まれないものにも注意してください。モデルが判定できなかった値は、再試行すべきエラーではありません。どのフィールドも欠落した状態で返る可能性があり、モデルは見つけられなかった項目を明示します。つまり「不明」は失敗ではなく 1 つの回答です。値の欠落が許容されるかどうかは、後段でエンティティがデータベースに登録される際に判断されます。モデルに推測させて決めるわけではありません。

ソースの段階で出力を強制

2つのオプションのトグルは、レスポンスが返ってくる前に出力を制約するようプロバイダーに要求するため、そもそも修正が必要なレスポンスが減ります。どちらもそれをサポートするモデルにのみ適用され、すべては上記の検証・リトライループにフォールバックします。

レスポンススキーマ
プロバイダーのネイティブなレスポンススキーマチャネルでスキーマを送信し、JSON をサーバー側で強制します。デフォルトはオフです。対応可能なモデルは、それ以外の場合はツールコールチャネルを使用します。
厳格な構造化出力
使用される構造化チャネルにおいて、デコードを schema に制約します(ドリフトなし)。デフォルトで有効ですが、強制できない model では静かに無視されます。

ステップ5: リアルタイムストリーミング

Entity Enricher は Server-Sent Events(SSE)を使用して進捗をリアルタイムでストリーミングします。すべてのモデルの完了を待つ必要はなく、各専門領域やモデルが完了するにつれて結果が段階的に表示されます。

イベントタイムライン(2つのモデル、3つの専門領域を用いた例)
0.0sstartedジョブを開始します。2件のモデルがキューに追加されました
0.1sclassification_started事前チェックを開始します
0.8sclassification_completedエンティティが「match」として確認されました(95%)
0.9smodel_startedClaude と GPT-4 が並行して開始します
1.2sexpertise_completedClaude: 財務情報が完了し、部分的な結果がストリーミングされました
1.5sexpertise_completedClaude: 一般情報が完了し、結果が更新されました
1.8sexpertise_completedClaude:規制対応が完了し、全結果の準備ができました
1.9smodel_completedClaude が完全な構造化出力を伴って完了しました
2.5smodel_completedGPT-4 が完全な構造化出力で完了しました
2.5scompletedすべてのモデルが完了し、ストリームが閉じます

ステップ6: 結果の確認

各モデルには、構造化された JSON 出力、expertise ごとの進捗バッジ、トークン使用量、コスト、処理時間を表示する専用の結果パネルがあります。マルチ expertise 戦略を使用する場合、各ドメインが完了するにつれて expertise バッジがリアルタイムで更新されます。

modelごとに表示される内容:
  • ステータスバッジ — 待機中、実行中、成功、失敗、または部分的
  • expertiseバッジ — domainごとの進捗を示す色付きのピル(青=実行中、緑=完了、赤=失敗)
  • プログレッシブ JSON — 各エキスパティーズの完了後に出力が更新されます
  • メトリクス — 処理時間、トークン数、USD建てのコスト
  • 進捗ログ — すべてのイベントにタイムスタンプ付きのエントリー

部分的な成功への対応

マルチ expertise domain 戦略を使用する場合、一部の expertise domain が失敗し、他が成功することがあります。Entity Enricher はすべてを破棄するのではなく、成功した expertise domain のマージ済み出力を「Partial」ステータスで返します。その後、enrichment 全体を再実行せずに、失敗した expertise domain のみを再試行できます。

例: 3つのexpertiseのうち2つが成功した場合、成功したdomainをカバーする構造化された出力が得られます。失敗したexpertiseは再試行でき、その結果は既存の出力にマージされます。

次に何が起こりますか?

enrichmentが完了すると、結果は今後の参照用にHistoryページに保存されます。複数のmodelを使用した場合は、Multi-Model Fusionを使って結果を統合できます。