文書抽出プロジェクトでは、多くの場合、単純なループから始まります。誤ったフィールドを見つけ、プロンプトやスキーマを調整し、その文書を再実行して結果を確認する、という流れです。しかし、フィールドや文書形式が増えるにつれて、このアプローチは信頼できなくなります。ある変更が 1 つのフィールドを修正しても、他の場所で回帰を引き起こす可能性があります。あるレイアウトでは機能しても、別のレイアウトでは失敗するかもしれません。あるいは、LLM 実行間の通常の変動によって、単に良く見えるだけかもしれません。
Databricks ブログは、最近のプロジェクトでの経験を共有しています。このプロジェクトでは、数十種類の PDF レイアウトにわたるパートナー提出の注文書から、約 40 の構造化フィールドを抽出する必要がありました。レビュー担当者は、抽出値が下流に進む前に修正と承認を行い、評価のための人手レビュー済みの正解データを提供しました。課題は、ai_extract にフィールドを返させることではなく、システム全体を劣化させずに抽出を改善することでした。例えば、リビジョンフィールドがリビジョン番号や空白ではなく「ORIGINAL」のようなステータス用語を返すことがありました。小さなスキーマ変更でそのフィールドのエラーは約半分に減りましたが、全フィールドの合計抽出エラーは 9% 増加しました。教訓は明確です。1 つのフィールドを改善しても、抽出システム全体が改善するとは限りません。
この問題に対処するため、チームは 3 つの問いを中心にワークフローを構築しました。何を変更すべきか。どのようにバージョン管理するか。昇格に十分な証拠は何か。まず、ai_extract の適切なレバーを選択します。ai_extract は、解析済み文書、JSON スキーマ、オプションのグローバル指示の 3 つの入力を受け取ります。スキーマは出力フィールドとフィールド固有の抽出ルールを定義し、グローバル指示は文書全体に適用されるガイダンスを提供します。チームは、ルールが 1 つのフィールドを定義する場合はスキーマに、文書の解釈方法を定義する場合はプロンプトに配置することを推奨しています。例えば、先頭のゼロを保持する、ステータス用語を除外する、識別子を最初の無効文字で停止する、値が存在しない場合は null を返す、といったフィールドレベルのルールはスキーマの説明に含めます。一方、文書やドメインのコンテキスト、ソースの優先順位（ヘッダーをフッターより優先するなど）、クロスフィールドの整合性ルール、行を配列に結合する指示、ソースとして使用すべきでない文書領域は、グローバルプロンプトに適しています。
次に、すべての変換に LLM が必要なわけではありません。大文字小文字の変換、区切り文字の削除、ゼロ埋め、および「TELEVISION」を「TV」にマッピングするような操作は、可能な限り SQL やその他の決定論的変換で処理すべきです。原則は、モデルで文書を解釈し、コードで出力を正規化することです。文書構造が複雑な場合、例えば大規模なスキーマ、繰り返し行項目、複雑な表、複数ページのレイアウトでは、ai_extract バージョン 2.1 の precision mode が役立ちます。プロンプトとスキーマを一定に保った場合、precision mode は繰り返し構造で最も効果を発揮し、過剰抽出（正解が空白であるべきところにモデルが値を返すこと）を減らす傾向があります。失敗の原因を診断することが重要です。モデルがフィールドの意味を誤解している場合は、プロンプトまたはスキーマを変更します。モデルがフィールドを理解しているがデータ構造に苦労している場合は、precision mode をテストします。
第三に、citations を利用してフィールドが誤っている理由を理解します。citations はフィールドレベルのバウンディングボックスを提供し、ソース文書内の要素スパンにマッピングできます。これにより、抽出エラー（モデルが誤った領域を選択した、フィールドを誤解した、またはソースでサポートされていない値を返した）とラベリングの相違（モデルが正しい位置から抽出したが、期待される回答が異なるレビュー担当者の慣例に従っている）を区別するのに役立ちます。これらには異なる修正が必要です。抽出エラーにはスキーマやプロンプトの変更が必要な場合がありますが、ラベリングの相違はレビューガイドラインで期待される慣例を定義することで解決すべきです。信頼度スコアは、低信頼度のフィールドを優先的にレビューするなどのランキング信号として使用できますが、自動的な品質ゲートとしては使用すべきではありません。高信頼度の結果でも誤っている可能性があります。
次に、プロンプトとスキーマのバージョン管理です。プロンプトとスキーマをノートブックにハードコードすると、小さな文言変更にコードのデプロイが必要になり、以前のバージョンの再構築が難しく、新しいバージョンが古いバージョンより優れているという証拠もありません。MLflow Prompt Registry を使用すると、プロンプトとスキーマをパイプラインコードから独立した、設定可能で再利用可能な定義としてバージョン管理できます。重要なのは、プロンプトとスキーマの両方をバージョン管理することです。フィールドの説明は、グローバル指示と同様に抽出に影響を与えるためです。プロンプトのみをバージョン管理すると、抽出ロジックの半分は追跡されていないコード変更として残ります。
簡単なエイリアス戦略としては、@prod を現在承認されているバージョン、@candidate を評価中のバージョン、@scr_* を並行して比較される実験バージョンに使用できます。パイプラインはエイリアスによってアクティブなバージョンをロードし、解決されたプロンプトとスキーマを ai_extract に渡します。候補が承認されると、mlflow.genai.set_prompt_alias を使用して @prod を新しいバージョンに移動できます。パイプラインはコードを変更せずに次回の実行でそれを解決します。ロールバックするには、両方のエイリアスを以前に記録されたバージョンに戻すだけです。基になるバージョンはレジストリに残ります。これにより、抽出設定がそれを実行するコードから分離されます。
最後に、昇格前に評価します。チームはレビュー担当者の承認結果を再利用可能な評価データセットにまとめ、ソース文書や予測とペアにして基準ビューを形成しました。候補バージョンは、固定された人手レビュー済みの基準で比較され、精度、カバレッジ、実行間の変動を追跡します。これにより、改善が局所的ではなくシステム全体にわたることが保証されます。ワークフロー全体は、抽出の改善提案から本番デプロイまでの再現可能なパスを形成し、変更がシステム全体を改善するという証拠を提供します。
チームがこれらすべてのステップを自分で実装する必要はないことに注意してください。Genie Code for document processing は、Lakeflow ジョブ（ai_parse_document、ai_classify、および citations と信頼度スコアを備えた ai_extract を含む）を構築し、このワークフローの核心を自動化します。ラベル付きテーブルに対してフィールドごとにスコアリングし、修正案（多くの場合、より正確なフィールド説明）をレビュー可能な差分として提示し、変更を受け入れるたびに評価を再実行して前後の結果を表示します。例えば、Genie Code に「ラベル付きテーブルに対して抽出を評価し、どのフィールドが最も弱いか教えてください」と依頼し、続けて「リビジョンフィールドの精度を上げられるはずです。スキーマと指示を反復的に改善し、評価を再実行して前後の結果を見せてください」と依頼できます。基本原理を理解することは依然として重要です。それは、Genie Code が提案する変更を判断し、結果が昇格に十分かどうかを決定し、MLflow Prompt Registry でプロンプトとスキーマをバージョン管理するなどしてワークフローを本番環境に拡張するのに役立ちます。