モデルが表のセルに一文字を足した。スキーマ検証では捕まえられなかった。

表の転記を求められたモデルは、ときにそれを「改善」します。悪意があるわけでも、頻繁でもありません。しかし確実に起きるため、専用の検査を作る必要がありました。

その検査を作るきっかけは小さな事例でした。貸付文書のあるセルは循環貸款（回転貸付）でした。モデルは循環貸款等を返しました。同じ語の後ろに「等」が付き、特定の金融商品が「回転貸付など」に変わっています。一文字です。出力をスキャンと見比べて流し読みしても気づきません。

通常の検証が捕まえられない理由

多くの表抽出はスキーマで検証されます。列はあるか、型は正しいか、行数は妥当か。スキーマはこの 3 つに答えて成功を報告します。列は列のまま、型は文字列のままだからです。誤りは、どの構造検証も表現できない場所にあります。

それを捕まえられる唯一の検査は原文との比較です。そこでモデルがセルを出力した後、検証器はより狭い問いを立てます。この正確な文字列は、この表が由来するページのテキストレイヤーに存在するか。「妥当な値か」ではありません。その問いが誤りを生んだのです。

出力ではこう現れます

文書が確認できたセルは通常の値として納品されます。確認できないセルは印を付けられ、納品全体もきれいな成功ではなく警告付きとして扱われます。マニフェストは具体を記録します。

{
  "outcome": "succeeded_with_warnings",
  "warnings": [
    "extra_fields:2",
    "unconfirmed_cells:个人关键信息"
  ],
  "source_pages": 7
}

これは当サイトの実在のマニフェストから識別子を除いたものです。3 つのことを示しています。抽出は使用可能、スキーマが求めていないフィールドが 2 つ生成された、1 列は原文と照合できなかった。これを受け取った人は、どの列を手で確認すべきか正確に分かります。

本番記録が示すもの

当サイトで記録された表の納品のうち、14 件中 13 件がきれいな成功ではなく警告付きでした。4 件は未確認セルを含んでいました。これを「問題だ」と示すのは簡単です。正直な読み方は、検査が設計どおり機能しているということであり、もう一方の選択肢——14 件すべてを成功と報告する——は少なくとも 4 件で嘘になります。

この教訓は表に限りません。文書にすでに存在するものをモデルに再現させる場合、構造検証は形が正しいことしか伝えず、内容が正しいかについては何も言いません。内容が重要なら、原文と比較するしかありません。

ではどうするか

1. 「未確認」は失敗ではなく問いとして扱う。そのセルは人の確認が必要で、シートの残り 99% は不要です。
2. 文書にない値を求めない。空欄を埋めるよう求められたモデルは必ず埋めます。
3. 警告の数と定義した列数を突き合わせる。余分なフィールドは、モデルが静かに範囲を広げた痕跡です。

自分の文書で挙動を確認したい場合、構造プレビューは無料です。クレジットを使う前に、検出された表と列を返します。