テンプレートOCRがデモで完璧に動作するのは、デモのレイアウトが決して変わらないからです。しかし実際の業務では、ベンダーが請求書のレイアウトを変更したり、スキャンが2度回転したり、行項目テーブルの行数が変わったりすることで、抽出結果が静かに誤ります。従来のインテリジェント文書処理プラットフォーム（ABBYY、Kofax、Rossum、AWS Textractなど）はより高度なテンプレートを構築できますが、依然としてデータの位置を記述することに依存しています。
テンプレートライブラリの真のコストは稼働後に現れます：異なるレイアウトごとに個別のテンプレートが必要で、中規模の買掛金部門は数百ものベンダーフォーマットを扱います。各テンプレートは構築、テスト、保守が必要な小さなソフトウェア成果物です。新規ベンダーはテンプレートが描かれ検証されるまで処理できず、テンプレートはベンダーのリデザインで静かに壊れ、後処理ルールが積み重なってパイプラインが複雑化します。ストレートスルー処理率はテンプレートがカバーするレイアウトでは高いものの、レイアウトが変わるとすぐにゼロに落ちます。機械学習による文書分類は自動的にレイアウトを認識してテンプレートを選択できますが、それでもレイアウトを作業単位とするため、同じ限界を継承します。
真の代替手段は座標による記述をやめ、人間のようにドキュメントを読むことです。LlamaParseなどのエージェント型OCRは、レイアウト認識型コンピュータビジョンでページを実際の構成要素（ヘッダー、行項目テーブル、ロゴ、署名など）に分割し、各要素を最適なモデルにルーティングします（印刷テキストは高速OCR、手書きやスタンプはビジョン言語モデル、密集テーブルは表構造用モデル）。ゾーンを定義する必要はなく、新しいベンダーの請求書が来ても再描画する必要はありません。システムは矩形を探すのではなく、請求書番号がどこにあってもそれを探します。
このアーキテクチャ変更により、テンプレート保守の全負荷がなくなります：テンプレートライブラリなし、オンボーディング遅延なし、ドリフトなし。初めて見るベンダーも昨日処理したベンダーも、同じドキュメント処理プラットフォームを設定変更なしで通過します。以下の比較は、テンプレートOCRとエージェント型OCRの実際のイベントでの違いを示しています：新しいベンダーの請求書到着時、テンプレートOCRは誰かがテンプレートを描くまで処理できませんが、エージェント型OCRは最初の請求書から処理可能。行項目テーブルが1行または60行の場合、テンプレートOCRの固定グリッドは想定外の行数で溢れたり欠落したりしますが、エージェント型OCRはテーブル領域を検出して完全に読み取ります。ページが回転または傾いた場合、テンプレートOCRの座標マッピングはスクランブルしますが、エージェント型OCRは画像化されたページ上でレイアウト検出を実行するため、フィールドがターゲットからずれることはありません。ベンダーが来四半期にリデザインした場合、テンプレートはその日に壊れますが、エージェント型OCRには壊れるテンプレートがありません。
さらにエージェント型OCRはテンプレートでは不可能な信頼度信号を提供します：各フィールドは抽出時にスコアを持ち、低信頼度の値は静かにシステムに流れ込むのではなく、レビュー用にフラグ付けされます。これにより、本当に不確かな5%のみを人間にルーティングし、残りはストレートスルー処理できます。LlamaParseはこのアプローチで90以上のファイル形式に対応し、10億以上のドキュメントを処理してきました。スタックにベンダー別テンプレートは一切ありません。
テンプレートはフォーマットの変動が保守速度を超えるワークフローで最も害を及ぼします。買掛金処理では数百の請求書レイアウトがテンプレートライブラリをフルタイムの保守作業に変えますが、エージェント型OCRは新規ベンダーの最初の請求書を設定なしで処理します。送金通知や医療給付説明書（EOB）は支払い元ごとにフォーマットが異なり、固定ゾーンではフィールドを追跡できません。物流文書（船荷証券、パッキングリスト、商業送り状）は国境、運送業者、言語を越え、標準レイアウトがありません。構造に基づいて文書を読むことが、これほどの変動に耐える唯一のアプローチです。
テンプレートOCRの時代は終わりつつあります。ドキュメントの種類が少なく安定していた頃は、いくつかのゾーンを描いて予測可能なストリームを処理すればよかったのです。しかし今やベンダーは独自のスケジュールでリデザインし、文書タイプは増加し、レイアウト変化の速度はテンプレートを保守できる速度を超えています。このギャップをより多くのテンプレートで埋めようとするのは敗北の戦略であり、最も大きなテンプレートライブラリを持つチームがその影響を最も感じています。問題を生み出したアーキテクチャは問題を解決できません。なぜなら問題はアーキテクチャそのものだからです。