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

エンリッチメントフロー

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

パイプラインの概要

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

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

スキーマエディターのページを開き、エンリッチメントを設定します。ワークフローのステッパーが、サンプルデータ、スキーマ、エンリッチメント、結果の各パイプライン段階をガイドします。

スキーマパネル(左)

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

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

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

結果パネル

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

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

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

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

ステップ3: 戦略の実行

選択された各 model は、選んだストラテジーを使用して entity を処理します。複数の model を選択した場合、それらはprovider をまたいで並列に実行され(Claude と GPT-4 は同時に実行)、同じ provider の model はレート制限を尊重するため順次実行されます。

マルチ専門領域の例(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になります
必須フィールドがありません
エラーが送り返され、LLM がそれらを補完します

LLM 呼び出しごとに最大 5 回の自動リトライを行います。各リトライには具体的な検証エラーが含まれるため、LLM は修正すべき箇所を正確に把握できます。

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

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は再試行でき、その結果は既存の出力にマージされます。

次に何が起こりますか?

エンリッチメントが完了すると、結果は今後の参照用にRecordsページに保存されます。複数のモデルを使用した場合は、マルチモデルフュージョンを使用して結果を統合できます。