エンリッチメントフロー

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

パイプラインの概要

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

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

「ワークフローエディター」ページを開いて、エンリッチメントを設定します。ワークフローステッパーが、サンプルデータ、スキーマ、エンリッチメント、結果というパイプラインの各ステージを案内します。スキーマが Database Sync にリンクされている場合は「データベース」ステップも表示され、実行による変更がデータベースへの反映用にキューへ登録されたこと(または保存が拒否された理由)を確認できます。

  1. 1破線のリンク: このステップは画面の遷移ではなく、実行の結果に従います
  2. 2スキーマが Database Sync にリンクされている場合のみ表示されます
部分的な保存が表面化するのは Database ステップだけです。変更がキューに入れば緑、エンティティは保存されたものの一部のリスト項目が取り込み時に破棄された場合はアンバー、受け入れゲートが拒否した場合は赤になります。いずれもモデル結果のパネルには表示されません。
スキーマパネル(左)

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

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

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

結果パネル

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

  1. 1ここに追加したすべてのモデルが、同じエンリッチメントを並列で実行します
  2. 2事前チェックはこのモデルで実行されます — 空欄の場合はチェックを行いません
  3. 3出力の強制に関するトグルは Advanced の下にあります
1つのパネルで実行全体が決まります。何を呼び出すか、何言語で行うか、その前(分類)と後(アービトレーション)に何を実行するか。選択内容はブラウザーに記憶されるため、次回の実行も同じ設定から始まります。

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

使える結果を返しようがないリクエストもあります。それに気づく最も安上がりなタイミングは、最初の 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 をサーバー側で強制します。既定はオンです。オフにすると、対応しているモデルでもツール呼び出しチャネルにフォールバックします。
厳格な構造化出力
使用される構造化チャネルにかかわらず、デコードをスキーマに制約します(逸脱なし)。既定ではオフで、強制できないモデルでは通知なく無視されます。
  1. 1どちらのトグルも、エンリッチメントパネル下部の「詳細設定」にあります
選択したモデルのいずれも対応できない場合、そのトグルはグレー表示になります。実行に費用をかける前に、設定が適用されるかどうかをパネルで確認できます。

ステップ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を使って結果を統合できます。