DocLang とは
ほとんどの文書フォーマットは、表示 (レンダリング) を前提に設計されています。PDF はピクセルをどこに描画するかを記述し、HTML はページのレイアウト方法をブラウザーに指示しますが、いずれも文書に「何が書かれているか」を言語モデルに伝えるものではありません。これらを AI 向けに変換するパーサーは、結局のところ読み取り順序を推測し、テーブルを文字列に平坦化し、図やメタデータを取りこぼしてしまいます。 DocLang は LLM のトークナイザー向けに設計された制約付きの XML フォーマットで、各要素が単一のモデルトークンに対応します。すべての要素が意味的な役割、バウンディングボックスの座標、読み取り順序における位置を保持し、テーブルは完全なグリッド構造をそのまま維持します。DocLang は製品ではなく仕様であるため、どのパーサーでも生成でき、どのツールでも利用できます。ワーキンググループは IBM、NVIDIA、Red Hat、ABBYY、HumanSignal、Forgis によって設立され、仕様は LF AI & Data のプロジェクトとして Joint Development Foundation Projects のもとで策定されています。FineParser が DocLang を出力する理由
Plain text は構造を捨ててしまうため、model に渡すコストは安く済みます。一方、HTML や Markdown は構造を保持できるものの、その構造を記述するために多くの tokens を消費します。DocLang なら、はるかに少ないコストで構造を保持できます。DocLang の OTSL スキームでエンコードした テーブル は構造を表す tokens が 5 つで済むのに対し、同等の HTML では 28 個必要です。 さらに DocLang は、コンテンツの種類ごとに正規の表現形式を 1 つだけ定めています。そのため、DocLang に対応するツールであれば、同じドキュメントから常に同じ出力が得られます。FineParser の出力に合わせて書いたコードは他のあらゆる DocLang の producer でもそのまま動作し、後からパーサーを変更してもドキュメントの可搬性は保たれます。例
次の DocLang フラグメントは、見出しと小さなテーブルを記述しており、それぞれにページ上のバウンディングボックスが指定されています。<location> 要素は、バウンディングボックスの四隅の座標を示します。テーブル内では、<ched/> が列ヘッダーセル、<fcel/> がデータセルを表し、<nl/> が行の終わりを示します。
ファイル
FineParser は、DocLang を markup を含む単一の.doclang ファイルとして出力します。DocLang 仕様では、markup と抽出された画像やその他のアセットをまとめた ZIP パッケージである .dclx archive も定義されていますが、FineParser はこの形式を生成しません。
詳細情報
doclang.ai のサイトでは、プロジェクトの概要とインタラクティブなビューアーをご覧いただけます。完全な仕様とリファレンスツールキットは、GitHub の doclang-project リポジトリ で公開されており、DocLang ファイルの検証とパッケージ化に使用するdoclang Python パッケージも提供されています。