10月28日、Databricksが「From spot fixes to measured gains: improving document extraction accuracy with ai_extract and MLflow Prompt Registry」と題した記事を公開した。ai_extractとMLflow Prompt Registryを組み合わせ、文書抽出の精度改善を「勘頼り」から「計測に基づくプロセス」へ移行する方法を詳しく解説している。「1フィールドを直したら全体が壊れた」という実体験から始まるこの記事は、LLMベースの抽出システムを運用するチームにとって実践的な指針となる内容だ。
「1フィールドの改善が全体を壊す」問題
PDFから構造化フィールドを抽出するシステムを運用していると、陥りがちなループがある。誤ったフィールドを見つけ、プロンプトやスキーマを微調整し、再実行して確認する——この繰り返しだ。
Databricksが実際に直面したプロジェクトでは、数十種類のPDFレイアウトから約40の構造化フィールドを抽出していた。revisionフィールドが数値の代わりにORIGINALといったステータス文字列を返す問題が発生し、スキーマを小修正したところ、そのフィールドのエラーは約半減した。しかし全フィールドのエラー総数は9%増加した。
「1フィールドの改善が抽出システム全体の改善を意味しない」——この教訓が出発点だ。記事で提案されているのは、この問題を構造的に解決するワークフローであり、その核心は「変更・バージョン管理・評価」の3点にある。以降ではそれぞれを順に掘り下げる。
ai_extractの正しいレバーを選ぶ
ai_extractは「パース済みドキュメント」「JSONスキーマ」「グローバル指示（オプション）」の3つを入力として受け取る。スキーマとグローバル指示は役割が異なる。
- スキーマ：各フィールドの型・ルール・制約を定義する。enumで値域を制限したり、説明文で「先頭のゼロを保持する」「
ORIGINALなどのステータス語は除外する」「値がなければnullを返す」といった細則を記述する。 - グローバル指示：ドキュメント全体に適用するロジック（ヘッダーとフッターの優先順位、禁止ソース領域の指定、複数行をまとめて配列にする指示など）を書く。
判断基準はシンプルだ。「1つのフィールドの定義なら→スキーマ、ドキュメントの解釈方法なら→グローバル指示」。
precision modeとcitationsの活用
スキーマとプロンプトが正しくても、複雑な表や複数ページにわたるレイアウトでは値のずれが起きる。ai_extractのprecision modeは、こうした構造的な問題に効く。記事では「モデルがフィールドの意味を誤解しているならプロンプト修正、データ構造の把握で躓いているならprecision modeを試す」と使い分けを明確にしている。
citations機能は、抽出値が誤っている原因を診断するのに使う。フィールド単位のバウンディングボックスで「どこから値を拾ってきたか」を追跡でき、「モデルが誤った場所から抽出した（→プロンプト修正）」と「正しい場所から抽出したが、レビュアーの表記慣習と異なる（→レビューガイドラインの修正）」を区別できる。
MLflow Prompt Registryでプロンプトとスキーマを一緒にバージョン管理する
プロンプトをノートブックにハードコードすると、小さな変更でもコードデプロイが必要になり、以前のバージョンの再現も難しい。MLflow Prompt Registryを使うと、プロンプトとスキーマをパイプラインコードから切り離して管理できる。
記事が強調するのは「プロンプトだけでなくスキーマも一緒にバージョン管理する」点だ。フィールドの説明文もグローバル指示と同様に抽出結果に影響する。スキーマを追跡しなければ、抽出ロジックの半分が未追跡のコード変更として残る。
エイリアスの運用例：
@prod：現在の承認済みバージョン@candidate：評価中のバージョン@scr_*：並行比較中の実験バージョン
パイプラインはエイリアスで能動的バージョンを解決するため、候補を昇格させるときもmlflow.genai.set_prompt_aliasを呼ぶだけでよく、パイプラインコードの変更は不要だ。ロールバックも同様に、両エイリアスを前バージョンに戻すだけで完了する。
固定したground truthで候補を評価する
バージョン履歴は「何が変わったか」を示すが、「変更が良かったか」は示さない。人間がレビュー・承認した数百枚のPDFを固定テストセットとして用意し、本番プロンプトと候補プロンプトを同一条件で比較する。
LLMの実行ゆらぎを考慮する
1回の評価で候補がわずかに高スコアを出しても、それは改善とは言えない。本番構成を3〜5回固定テストセットで実行し、平均精度と標準偏差（σ）を計算する。このσがノイズフロアだ。記事では「候補の改善幅が2σを超えない限りは結論を出さない」ポリシーを推奨している。
accuracyだけでなくcoverageも追う
accuracyは分母の定義次第で見かけ上の改善が生じる。例えば、モデルが難しいフィールドを空白で返せば、そのミスが分母から消えてaccuracyが上がったように見える。
実際のプロジェクトでは、revisionフィールドの修正を「レビュアーが値を入力したケースのみ」でスコアリングすると改善幅は3ポイント未満だった。しかし「正解が空白であるケースも含めた全エラー」で計測すると、エラーは約半減していた。改善の大部分は「値がないところで正しく空白を返せるようになった」ことによるものだった。
accuracyが上がってもcoverageが大きく下がっている場合は、昇格前に調査が必要だ。
Genie Codeによる自動化
記事ではGenie Code for document processingを使えば、上記のワークフローの中核（評価→改善提案→再評価のヒルクライミングループ）を自動化できると紹介している。例えば「評価してどのフィールドが弱いか教えて」「revisionフィールドの精度を上げるためにスキーマと指示を繰り返し改善して、ビフォーアフターを見せて」といった自然言語の指示で動く。
Genie CodeはDatabricksが提供するAIアシスタント機能群の一つであり、ノートブックやSQLエディタ上でのコード生成・説明・デバッグを担うDatabricks Assistantと同じ文脈に位置づけられる。文書処理に特化した形でそのケイパビリティを拡張したものが、今回紹介されているGenie Codeの文書処理向け機能だ。
ただし記事は「仕組みを理解することは依然として重要」と述べている。Genie Codeが提案した変更の妥当性を判断したり、MLflow Prompt Registryでの本番運用への拡張を行うには、基礎的な理解が前提となる。
詳細はFrom spot fixes to measured gains: improving document extraction accuracy with ai_extract and MLflow Prompt Registryを参照していただきたい。
