Field Extractorは項目の型と名前を指定し、表の入れ子も扱います。開発元は546文書での評価を公開し、費用比較はGPU時間とAPI料金の異なる算出条件を使っています。 文書処理では読取精度に加え、存在しない項目と欠損の扱いを確認します。公開ベンチマークの費用倍率を、そのまま販売価格や自社の削減率に使わないことが焦点です。 全文の読み取りから必要な項目の抽出へ Dharma-AIは11月4日、Hugging Face上の開発元記事でField Extractorを紹介しました。文書画像から、指定した項目を型付きのJSONとして取り出すモデルです。OCRで全文を読み取った後に、請求額や日付を別のコードで対応付ける負担を課題にしています。基盤は20億パラメーターのDharmaOCR-LITE v1.1です。OCR向けに学習したモデルへ追加の調整を行い、項目を網羅的に探す方式と、指定した構造を埋める方式を一つのモデルで扱います。汎用モデルへ長い指示を渡す方法との比較を示し、範囲を絞った専用モデルの有効性を検討しています。 存在しない項目を空値として返す設計 入力には、文書だけを渡す方法と、欲しい項目の構造を渡す方法があります。後者では文字列、数値、真偽値の型と項目名を指定し、表の各行も入れ子として返します。文書に存在しない項目にはnullを返す説明です。対象は、請求書や申請書などを業務システムへ取り込む担当者と見られます。全文を受け取る場合と比べ、次のシステムが使う形へ近づけられる可能性があります。評価は546文書を三つの要求条件で調べ、存在しない項目を指定する例も含めます。JSONの形式だけでなく、項目の位置と値の一致を組み合わせて採点します。形式が正しい出力でも、数値や項目の対応が正しいとは限りません。自社の帳票と表の構造で、欠損と読取誤りを分けて調べる必要があります。 自己運用費とAPI価格の比較条件を読む 開発元は、試験した汎用モデルより高い得点と低い処理費を報告しています。ただし、専用モデル側は単一のL40S上のGPU時間、相手側は計測したトークン量と公開API料金による比較です。原文は、示した費用が販売価格ではないと明記しています。自社運用では設備、処理量、待ち時間の条件が費用に影響します。導入側では、稼働しない時間や保守を含む費用と、外部APIの従量料金を同じ期間で比較することが論点になると見られます。また、英語とポルトガル語を中心とする学習データの構成が説明されています。別の言語や特殊な帳票でも同じ性能かは、自社の文書で確かめる必要があります。提供元の比較結果を、すべての文書での優位性へ広げないことが重要です。 下流システムへ入れる前の検査が残る 指定した形のJSONが得られても、業務システムへ直ちに確定値として登録できるとは限りません。必須項目の欠損、合計と内訳の不一致、読み取りにくい画像の扱いを決めることが考えられます。次の判断点は、人へ戻す条件と原文画像との対応です。どの項目がどの文書に由来するかを残せば、後から訂正しやすくなると見られます。ベンチマークの得点に加え、実際の確認と修正に要する作業を測る必要があります。抽出元の保管期間も運用の確認点になると見られます。