Dharma-AI、2Bパラメータで文書からJSON抽出するモデルを公開

何が発表されたのか

Dharma-AIは、文書画像と「欲しい項目の指定」を入力すると、構造化されたJSONを返すモデル「Dharma Field Extractor」を公開した。パラメータ数は2B(約20億)で、請求書や身分証、医療依頼書、契約書といった文書種別を問わず、同じチェックポイントで処理できるとしている。

背景として同社は4月に、文書OCRに特化した「DharmaOCR-LITE」を発表している。OCRはページ上の文字を元のレイアウトに沿って書き出すもので、契約書を端から端まで読むような用途に向く。一方、業務ではページ全体ではなく「請求書の明細行」「患者名・検査種別・日付」といった特定の項目だけを、後続システムが読める形で取り出したい場面が多い。その部分を専門モデルで置き換えるのが狙いとなる。

2つの指定モード

依頼方法は2つある。スキーマを渡さない「オープン」では、モデルがレイアウトと文脈から、ラベルと値の組や表の見出し行といった構造を判断し、見つけた項目をキーバリューとして返す。文書に何が入っているか分からない場面で使う想定である。

もう一つが「スキーマ指定」で、項目名と型(string、number、boolean)をシステム側のキー名で指定すると、その通りのキーで値が返る。表を指定すれば行・列単位で埋め、文書に存在しない項目は値を創作せずnullを返す。出力はスキーマに厳密に従い、余計なフィールドが付かないため、そのまま次のシステムに渡せる。

どちらを使うかは、出力先の形が決まっているかどうかで選ぶことになる。既存のデータベースや社内レコードの列名が決まっているなら、スキーマ指定の方が後工程のコードを書かずに済む。

どう学習させたか

ベースは DharmaOCR-LITE v1.1(2B)で、論文版から最適化したモデルにSFT(教師あり微調整)とDPO(直接選好最適化)を施し、OCRに特化させたチェックポイントである。そこにLoRAアダプタを追加学習した。学習例は43,384件で、2つの依頼モードの両方をカバーする。

データは3系統に分かれる。公開ウェブから集めた英語の多分野文書、社内で用意したポルトガル語のブラジル文書、そして他の欧州・アジア言語をより小さな割合で含む多言語データである。いずれもフィールド単位でアノテーションされており、レシート、商業請求書、帳票、銀行明細、ID文書、合成文書と、単一の書式に偏らない構成にしている。

ベンチマークの結果

評価は546文書・3シナリオ・1,638ケースで行われた。シナリオは、スキーマなしで全項目を抽出するもの、実在する項目だけを並べた部分スキーマ、存在しない項目をわざと含めたスキーマの3つである。スコアはフィールド単位F1(表内の位置まで含めたパスで照合)に、一致した値のレーベンシュタイン類似度と、有効なJSONとして返った割合を掛けたものになる。

汎用のフロンティアモデル4構成と比べ、品質差は1.8ポイント(Claude Opus 5、最小)から9.3ポイント(GPT-5.6 Luna、最大)だったとしている。コストは約6分の1(GPT-5.6 Luna)から約147分の1(GPT-5.6 Sol)とする。同社のモデルはトークン課金ではなく、L40S 1台を時給2.24ドルとして換算したGPU時間で算出しており、同社自身が「販売価格ではない」と断っている点には注意したい。

未知データと留意点

学習に使っていない公開データセットのSROIEとFUNSDでも検証している。SROIEのレシートでは18項目すべてを正解し、空欄2つはnullで返した。FUNSDの複写申込書では、12個の真偽値チェック項目のうち実際にチェックされている1つだけをtrue、残り11個をfalseと判定したとしている。

ただしこれはベンダー自身による評価であり、比較条件の違いは結果の解釈に影響しうる。フロンティアモデル側は推論の強度をlowに固定し、Claude Opus 5のみadaptive effortを使ったと明記されている。また学習データは英語とポルトガル語が中心で、日本語文書はベンチマークに含まれていない。日本語での精度は現時点で公表されていない。