Mistral OCR 4を公開
(mistral.ai)- Mistral AIが公開したMistral OCR 4は、文書からテキストだけを抽出するOCRを超え、バウンディングボックス、ブロック分類、インライン信頼度スコアまであわせて返す文書理解モデル
- 10の言語グループにまたがる170言語と単一コンテナでのセルフホスティングをサポートし、データ主権・コンプライアンスが重要な組織の文書収集パイプラインに適している
- 人手による選好評価では平均72%の勝率を記録し、OlmOCRBench 85.20、OmniDocBench 93.07など公開・内部評価でも高いスコアを示した
- ただし、正解データの誤り、等価な数式表記、複数カラムの読み順、ヘッダー・フッター処理といった採点上の限界があるため、ベンチマークスコアは実際の文書評価とあわせて見る必要がある
- APIは1,000ページあたり**$4**、Batch APIは**$2**、Document AIは**$5**で、素の抽出にはOCR 4で十分だが、構造化JSON・画像注釈・カスタムプロンプトが必要ならDocument AIの経路が適している
OCR 4が返す構造化文書表現
- OCR 4はさまざまな文書のコンテンツを抽出して構造化し、前世代のようにクリーンなテキストや表変換にとどまらず、構造化表現も提供する
- 各ブロックにはバウンディングボックス、ブロック種別、ページ・単語単位のインライン信頼度スコアが含まれる
- ダウンストリームシステムは、文書の内容だけでなく各要素の位置、役割、信頼水準まで活用できる
- 主な活用フローは次のとおり
- RAG向け意味単位チャンク化: 整理・分類されたブロックを検索単位として使用
- エージェント向け構造プリミティブ: フォーム入力、請求書処理、コンプライアンス点検を支援
- コネクタ向け構造化コンテンツ: 収集・インデックス化パイプラインに一貫した型付き出力を提供
形式、言語、デプロイ方式
- 入力形式にはPDF、DOC、PPT、OpenDocumentなど一般的なエンタープライズ文書形式が含まれる
- 10の言語グループにまたがる170言語をサポートし、多くのシステムが弱い専門言語・低リソース言語も対象に含まれる
- モデルは単一コンテナでデプロイできるほど小さく、コスト重視・高スループット環境に適している
- 完全なセルフホスティング実行をサポートするため、データ主権要件がある組織は文書データを自社インフラ内に保持できる
- 自己管理型デプロイはエンタープライズ顧客向けに提供される
価格と利用経路
- 開発者はAPIでモデルを統合でき、チームはMistral StudioのDocument AIを通じて同じエンジンをノーコードアプリケーションとして利用できる
- 価格は次のとおり
- OCR 4 API: 1,000ページあたり $4
- Batch API 50%割引適用時: 1,000ページあたり $2
- Document AI: 1,000ページあたり $5
- OCR 4はMistral Search Toolkitの収集コンポーネントとして統合され、RAGやエンタープライズ検索向けの収集・検索・評価ワークフローに引用可能な入力を提供する
評価結果とベンチマークの限界
- OCR 4の評価は、AIネイティブOCRモデル、汎用フロンティアモデル、エンタープライズ文書サービス、Mistral OCR 3との比較で行われた
- 人手による選好評価は実利用を反映するため、12以上の言語による600件超の文書で構成され、独立した注釈者が各競合システムの出力とOCR 4の出力を文書ごとにブラインド比較した
- 注釈者は、テストされたすべてのシステムに対して大半の文書でOCR 4をより好んだ
- 平均勝率は72%
- 公開OlmOCRBenchでは、テストされたモデル中で最高の総合スコア85.20を記録した
- 内部Crawl Multilingual evaluationでは**.98**を記録し、AIネイティブ・エンタープライズソリューションを上回った
- OmniDocBenchのスコアは93.07だが、OlmOCRBenchとOmniDocBenchにはいずれも一部の出力採点方式に既知の限界がある
- 監査された不一致の多くは、モデルの誤りというよりベンチマークの比較方式に起因していた
- 正解データの誤り: 参照注釈に欠落・追加テキスト、隠れた領域の転写、誤字が含まれることがある
- 等価な数式表記: 描画結果が同じLaTeXでも、文字列が異なれば不一致として計算される
- 数式の分割: 1つの数式として出力するか複数のインライン断片に分けるかで正解マッチングがぶれる
- 複数カラムの読み順: カラム境界で分割された単語やカラム順の仮定により、正しい抽出でも失敗と採点されることがある
- ブロック種別の帰属: ヘッダー・フッターを出力から除去した後でも、ページタイトルのような文字列をテストが誤ってフラグすることがある
- こうした産物は数学、科学、複数カラム文書に集中し、誤った出力に報酬を与えるというより、正しい出力により頻繁に減点を与えている
- 競合各社のスコアはすべて内部再現結果のため、実導入前には自社文書で直接評価するのが安全である
多言語性能
- 内部多言語評価でOCR 4は8つの言語グループすべてで優位だった
- English
- Western Europe
- Eastern Europe
- Middle Eastern
- Chinese
- East Asian
- Southeast Asian
- Hindi, Japanese, Georgian, Bengali, Armenian, Hebrew, Greek, Gujarati, Tamil, Malayalam, Kannada, Telugu などの専門言語
- 差が最も大きかったのは専門言語・低リソース言語で、多くの競合システムが大きく性能を落とす領域でも、OCR 4は高い精度を維持した
推奨ユースケースと対象外範囲
- OCR 4は高スループットパイプラインと対話型文書ワークフローの両方をサポートする
- 推奨ユースケースは次のとおり
- 複雑な多言語文書の文書解析・抽出
- RAG向けの構造化・分類・引用可能コンテンツ生成
- Search Toolkitと組み合わせた検索パイプライン入力
- フォーム入力、請求書処理、コンプライアンス点検といったエージェントワークフロー
- 信頼度スコアを活用した人手検証ベースの構造化データパイプライン
- エンタープライズ検索とナレッジベース向けのデータソースコンポーネント
- 初期ユーザーはOCR 4を、請求書の構造化フィールド変換、企業アーカイブのデジタル化、技術・科学レポートのクリーンなテキスト抽出、エンタープライズ検索に適用している
- OCR 4は文書理解モデルであり、意思決定者ではない
- 医療診断、法的助言や判断、高リスクの金融判断、安全性が重要なシステム、リアルタイム・低遅延処理、生の音声・動画といった非文書入力は想定していない
OCR 4 APIとDocument AIの選択基準
- OCR 4は単一のAPIエンドポイントとして提供され、すべてのリクエストは同じ基本OCRモデルを実行する
- 基本応答には常に抽出コンテンツ、バウンディングボックス、ブロック種別、信頼度スコア、Markdown構造テキストが含まれる
- 純粋抽出モードは次のような場合に適している
- 高速かつ正確な文書抽出をアプリケーション、エージェント、データパイプラインに直接組み込む
- 生の応答、バウンディングボックス、ブロック種別、信頼度スコアを直接使ってカスタム後処理ロジックを構築する
- Batch APIでスループットとコストを制御する高スループット・バッチ収集
- 厳格なデータプライバシー、主権、コンプライアンス要件に合わせたセルフホスティング
- Document AI機能は同じエンドポイントに追加パラメータを入れて有効化する
- 文書とともにJSONスキーマを渡すと、OCR出力が
mistral-small-2603に入力され、指定した仕様に合う構造化JSONを生成する - 画像注釈スキーマを渡すと、検出された画像ごとに追加のビジョン言語モデル呼び出しで構造化JSONを生成する
- JSONスキーマとともにカスタムプロンプトを使い、文書全体の抽出コンテンツの解釈や要約を誘導できる
- ビジネスユーザー、ソリューションチーム、パイロットプロジェクトは、別個の後処理パースロジックなしで構造化結果を作成できる
- 文書とともにJSONスキーマを渡すと、OCR出力が
- 生の抽出コンテンツが必要ならOCR 4をそのまま使い、構造化形式への再加工・ドメインフィールド注釈・カスタム指示処理が必要ならDocument AIパラメータを追加する
提供チャネルと始め方
- Mistral OCRv4とOCRv4ベースのDocument AIはAPI、Mistral Studio、Amazon SageMaker、Microsoft Foundryで利用できる
- Snowflake Parse Documentのサポートは近日提供予定
- 機密情報を自社インフラ内に保持する必要がある組織向けに、OCR 4はセルフホスティングオプションも提供する
- 開始リソースは次のとおり
- Getting Started with OCR 4 Cookbook: 最初の抽出、バウンディングボックス操作、ブロック分類を扱う
- OCR4 in Production webinar: 7月7日午後6時 CETにデモとQ&Aを実施
- Contact Sales: 追加情報の問い合わせ
1件のコメント
Hacker Newsの意見
US Postal Serviceはいつも技術的驚異のように感じる。
はるかに原始的な技術でも何十億通もの郵便物を識別して仕分けしているうえ、アメリカの住所は信じがたいほど非標準的で、同じ住所を複数の書き方で書いても同じ場所に届くことがある。
この分野には公開知識も多いのだろうが、USPSの規模で何年もやってきたことを考えると、OCRの発表を見るたびにすでに解かれた問題のように見える。
1970年代で、インターネットも中央データベースもなかったが、郵便サービスは配達に成功した。
父が社会福祉活動を活発にしていて、青少年サッカーチームも運営していたため、地域では名前だけでもかなり知られていたからだ。
今では携帯電話の助けなしに人や場所を見つけられないことが多く、配達員もおしゃべりをやめない。
そんな手紙は技術的な処理工程も、おそらく人のネットワークも通り抜けられない気がする。
それで手紙が正しい郵便局まで届くと、残りは早朝に配達員たちが処理していた。
その住所が何を意味するのか推測するのはかなり面白く、特に年配の職員たちは、なぜ特定の場所の住所がそういう書かれ方をするのか事情を知っていたり、居住者の名前だけを見て住所を推測したりしていた。
Carmel-by-the-Seaには道路番号がなく、Florida Keysの住所はしばしば単にマイル標識番号だったりする。
配達できるのは、そのルートを担当する人が慣れているからだ。
ナンバープレート認識に焦点を当てた公開モデルがあるのか気になる。
古いモデルはいくつか見つけたが、このOCRモデルのように新たに開発中のものがあるのか知りたい。
実際にこの用途で使ってみて性能を確認することもできそうだ。
リンク先ページの動画は予想と違っていた。
MistralはヨーロッパのAI企業だと思っていたのに、動画がSan Franciscoで撮影されていて、登場する3人もヨーロッパ人には見えず意外だった。
グローバル組織なのは良いが、パリのオフィスとヨーロッパ風のアクセントを予想していた。
質問は多く、財布のひもは非常に固い一方で、アメリカ人は違う。
おそらく営業エンジニアリングもあるだろう。
時差が8〜10時間あるので、実質的に避けようがない。
以前勤めていた会社は代わりにVancouverオフィスがあり、同じ時間帯だった。
大半はオーストラリア拠点なのに、https://www.blackmagicdesign.com/company/officesのオフィス一覧の順序や会社ページを見ると、アメリカ企業のように見える。
そういう意味では、アメリカの資金とヨーロッパの人材という両方の利点をうまく活用している。
このモデルがhttps://github.com/baidu/Unlimited-OCRと比べてどの程度の順位になるのか興味深い。
1000ページあたり4ドルなら安いが、以前のバージョンはどれも「社内ベンチマークPDF 4本で98%精度」といった具合で、実際には市場のほぼすべての代替案より劣っていたので、またベンチマークするのをためらってしまう。
今回もOlmOCRBenchとOmniDocBenchには「既知の限界」があるとして、社内ベンチマークの代表値を前面に出している。
https://getomni.ai/blog/benchmarking-open-source-models-for-ocr
すべてのAI研究所は、ベンチマークの棒グラフで切り詰めたy軸を使うのを本当にやめるべきだ。
https://mistral.ai/_astro/cm-engish_ZhlvoT.webp?dpl=6a3a94bd1f38530b2974c539
Malayalamでテストしたが、普通の筆跡は正確だった一方で、少し違うスタイルはKannadaとして検出された。
必要ならサンプルを渡せるし、Sarvamは同じサンプルをテキストエラー1つだけ残して99%の精度で処理した。
たとえばIndian Englishや、ローマ字で書かれたインド系表現が混ざった文書、それに図や表のような複雑なレイアウトがある文書でどうなのか知りたい。
インドのサービスには関心があったが、思ったより価格が少し高く見えてためらっている。
もちろん、私の記憶違いかもしれない。
12月の以前のOCR v3モデルと比べて、バウンディングボックス以外の違いはほとんど説明されておらず、価格は2倍だ: https://mistral.ai/news/mistral-ocr-3/
当時は別のベンチマークを使っていた。
「範囲外の用途に関する注意。OCR 4は文書理解モデルであり、意思決定者ではない。医療診断、法的助言や判断、高リスクの金融意思決定、安全性が重要なシステム、リアルタイム/低遅延が求められる処理、非文書入力（生の音声、動画など）のためのものではない。」
次の会議で「なるほど、でも携帯電話の写真みたいな非文書入力で高リスクの金融意思決定に使ったらどうだろう？」と提案する「革新的な」管理職がもう楽しみだ
来週あたりにはHNで誰かがこの「アイデア」をコメントするはずだと断言できる
もっと性能の高いモデルが何十個もあるのに、それよりひどい結果しか出ないはずだ
これは質問に答えるモデルではなく、テキスト変換用だ
単に反AIの論点を無理やり作りたいように見える
Mistralはこの点をやや正直に示しているだけで、おそらく何でもできる専門家のように見える汎用ユーザーツール（チャット）で観客を驚かせる必要がない、あるいは望んでいないのだろう
実際、そうしたツールもかなりの頻度で複数の特化モデルをつないだ形になっている
ここでやりたいことは、Pythonスクリプトをいくつか書けば実現できる
Voxtralで音声プロンプトをテキストに変換し、追加のシステムプロンプトと一緒にMistral Large 3へ渡してOCR用のプロンプトとファイルパスを作らせ、その後ループでファイルを見つけてOCR 3に投げ、さらにMistral Large 3で解釈して意思決定に変えればいい
こういう構成は一般的で、むしろすべてを単一モデルで処理するほうが珍しい
最近Opus 4.8でOCRを試した
厳密には適切なツールではないが、必要だったのは領収書から日付を抽出することだけだった
日付の約20%を間違えたのに、すべて「高い信頼度」と評価していた
たぶんOCR特化モデルを使うべきだったのだろう
昔、白黒スキャナに付属していたシェアウェアOCRツールでも20%の誤りよりはましだった気がする
別の古いOCRツールを使っているようで、テスト結果も悪かった
一方でGemini APIではモデルが直接OCRを行っていて、精度はずっと高かった
小型の1〜4B視覚言語モデルよりはるかに優れている
Opusが失敗したのなら、そうした小型モデルの大半も失敗する可能性が高い
Opus 4.8で最近、かなりひどい手書きが混じったPDFを何百件もスキャンしたが、自分ですら読めなかった記録1件を除けば100%成功だった