Mistral OCRの実力とは？新しいOCRモデルがもたらす変革と課題

ライセンスの選択肢がいいね！この開発を続けるために十分なお金を稼げることを願ってるよ。

＞Mistral OCRはすごいモデルだけど、OCRって難しい問題で、LLMでハルシネーションや欠落したテキストが出るリスクが大きいよね。多くのLLMを使っての合意範囲を選ぶのはどうかな？

なんで同じ訓練データを使ってるのにハルシネーションが合意されないの？って疑問だよね。

ハルシネーションはモデルが何かを知らないことの表れだと思う。音に支配される訓練重みが影響して、複数のモデルで同じプロンプトを扱ったほうが安定した結果が得られるかも。

この前の記事では、複数のLLMが同じことについてハルシネーションを起こすことがあるから、訓練データが不十分だとハルシネーションが消えないって話だったよ。

ハルシネーションって結局、モデルが出す出力の一部だと思う。だから、数学の観点から見れば、正しい答えとハルシネーションに違いはないってことだよね。

統計的な単語パターンの予測に過ぎないんじゃない？モデルは真実や事実を検証できないし、判断しようとするのは結局、自分で納得する状態を見つけるだけだと思う。

悪くはない！でもまだハルシネーションがあるね。難しい画像の例もあって、真ん中のブロックでは完璧だけど、次のブロックが最悪だよ。文を重複させたり、存在しない単語を作ったりするのはダメだよね。

＞完璧だね！でも、U+25CBの円を使うんじゃなくて、U+00BAの序数インディケーターにするべきだと思う。細かいけど、ミスは気になるよ。

ちょっと関係ないけど、AppleのLiveTextで画像から文字をコピーしたら、違う文字が入っちゃったことがあって。OCRが正確じゃないと問題になるよね。

ちょっとした指摘だけど、U+25CB ○ WHITE CIRCLEを使うのは完璧とは言えないんじゃない？本来はU+00BA º MASCULINE ORDINAL INDICATORとか、スーパースクリプトの｢o｣や度記号を使うべきだと思う。それをコンテキストに応じて選べるはずだけど。

人間でもそれは推論モデルの話だよねｗ。

OCRソフトは使用言語を解析して、認識言語のヒューリスティックを使って文字認識を導くんだよね。推論モデルは必要ないと思うけど、逆に推論モデルが誤りに気づくべきだね。ただLLMトークナイゼーションがそれを難しくするかも。

OCRの後には言語とテーマの検出があった方がいいと思うし、最後に適切な辞書を選んだスペル・文法チェッカーも必要だと思う。これって、OCRじゃなくて古典的なスペルと文法のチェックの問題じゃないか？

間違った文字が認識されてるから、これはOCRの問題だよ。元の画像でスペルや句読点の間違いを直すんじゃなくて、OCRの精度が低いから問題が起こってる。特に｢白い円｣の文字は、元の序数記号を推測するのが難しいから、元の画像を見る必要があるし。

その後の文法・スペルチェックが、正確な文字を解読したのか、誤って解読したのかによって変わるよね。スペル・文法のチェックが後者を修正できるなら、正当だと思うけど。

OneNoteの画像からテキストをコピーする機能が最近変なOCR結果を出すようになったんだ。はっきりした印刷ページの画像からも、｢cornprising｣じゃなくて｢comprising｣になるとか。これは見た目も似てるから気づきにくいよね。

また別のテストとして、英語のテキストで試してみたよ。これはニュージーランドの1854-55年の議会での議論の画像なんだけど、誤りがいくつかあったよ。たとえば、｢emundations｣は本来｢emendations｣なんだけど、あと｢expedited｣とか、意味が変わるものもあるから注意が必要だよね。

OCRがもう解決した問題だって喜びたいけど、ハルシネーションも問題だから、Tesseractと同じで手動の校正が必要だと思う。自分のプロジェクトでどれだけ改善されるか試してみないとね。

使用ケースによるね。自分の場合は、スキャンしたPDFのページから長文の概要を取るために数百万のページを処理してる。たまに間違いがあってもプロジェクトには影響しないから。自分は例外的だと思うけど、可能な限り正確な解決策を望んでるよ。

両方やって出力の違いを比べて競合部分を特定するってことかな？

今考えてるのは、2つのOCRモデルを使って結果を比べてエラーをチェックすること。こんな値段ならやらない手はないよね。

PDF解析能力とLLMの学習データセットの質に相関って誰か知ってる？科学論文がPDFで、今までテキストやトークンへの変換が悪かったなら、トレーニングで大きな改善が期待できる？

あなたの例、そんなに難しくないと思うけど。

あいつはいつもハルシネートするだけだね。

これは本当にワクワクするね。論文や教科書を読みやすくする趣味のプロジェクトを考えてたんだけど、残念ながらOCRや図の抽出技術がまだ足りなかった。これ、ゲームチェンジャーだよ。図の参照を実際の図と関連付けられるから、ページをめくる手間が減るUIが作れる。HTMLへのクリーンな変換もできるから、知らない単語をクリックして意味を見たり、LLMが生成したチェックポイントの質問を挿入する機能も追加できるね。Andy MatuschakのOrbitをPDFに自動統合できるか試してみたい。可能性がいっぱい。

＞このUIがあれば、参照図を探す面倒が解消されるね。実際、私もこの問題にずっと悩んでた。で、sioyekっていうのを見つけたら、リンクにカーソルを合わせると小さなウィンドウがポップアップするのが良かった。 PDFファイルのフォーマットが正しければ、OCRでこの体験がもっと良くなるね。UIコンポーネントはもうあるってことさ。

ZoteroのPDFビューアもこれを今やってるよ。PDFに注釈を付けたり、リファレンスマネージャーがあって助かってる。

リンク教えてくれてありがとう！似たようなことをやっている人がいるっていいね。

これって画像も扱うの？

入力に画像が含まれてるみたい。例の一つでは、ロゴが元の画像から切り取られて結果に含まれてるのが見えるね。

Gemini Flash 2.0と比較したベンチマークを実施したよ。詳しくはここを見てね：https://reducto.ai/blog/lvm-ocr-accuracy-mistral-gemini。要約すると、すごいモデルだけど、ドキュメント解析ではSOTA VLMに劣り、OCRや表構造で内容を誇張しがちなんだ。

個人的にもGemini Flashの方がいいと思った。

お金持ちの会社と比較してるからね。

キャッチフレーズで”世界最高のドキュメント理解API”を謳ってるからさ、マーケティングには期待しちゃうよね。

もしそう言っててクオリティが低いなら、その商品は見限るね。

それで？技術そのものの良し悪しで判断してるんだ。確かに公平ではないかもしれないけど、自分がOCRを選ぶ時はSOTAを選びたいから、こういう比較が役立つんだよね。

他の出力との比較も近々出すよ！

PDFを編集できるようになるなんて、とうとうそこまで技術が進んだんだね。

難しさじゃなくて、許容できるエラーの問題だと思う。自動運転は99%の精度じゃダメで、99.99%が必要だと思う。その精度を出すのは難しい。

99%の精度なんて大半の人にないって。自動運転のエラー許容の基準が低いのは当然だね。

99%の精度ってどう定義するの？成功率が高ければもっと合理的だと思う。毎日通勤してる人は1000回以上運転するだろうけど、数年に一回しか事故がないし、99%なら月一の事故になるよ。

過去10年間、PDFを95%以上の精度で編集できてるけどね。

OCRがほぼ解決されるところまで来てるのはワクワクするね。レガシー企業は新しいVLMに押し流されるだろう。でも、OCRの出力からビジネスでのプロセス開発にはまだ大きなギャップがあるよ。完全自動化を期待するのは幻想だから、時間と労力はかかるけど、未来は明るい！

自分のスタートアップでOCR技術を評価する際、ステークホルダーに“人間の介入”が避けられない、かつ有益であることを納得させるのが難しいっていう問題に直面した。PMは完全自動化を求めるけど、それはありえないと思う。チューニングコストを払わないと失敗することになるんだ。

その通りだね！私のスタートアップもこれを理由に作った。スタートアップや大企業で「完全自動化は無理」との声をたくさん聞いたよ。でも努力すれば生産的な精度には到達できる。正しいツールを用いればチューニングにかかる時間も短縮できるし、1-2週間で到達することも可能だよ。

やっぱり、耐障害性に依存する部分が大きいね。OCRが99.9%や99%、98%の信頼性を持つ場面はたくさんあると思うよ。優秀なプロダクトマネージャーなら、この限界を理解して上手く対応できるはず。

やっぱり避けられない“人間の手”が必要なんだと思う。こっちのコメントを見る限り、一般的なOCRはまだまだ不十分みたい。でも、あんまり大きな野望は持ってないから、自分にはちょっとした前処理で使えそう。どこがうまくいくか分かってれば、ちょいと手を加えて与えれば、ばっちり組み立てられそうだね。テストしてたら特定の部分で常に失敗してたけど、うまくいったところは他の方法よりめっちゃ上手くいったよ。

従来の純OCRを提供している業者は、こういうVLMにボコボコにされるだろうね。

価値を他で追加しない限り、彼らはコモディティ化されるだろうね。顧客にとってはいいニュースだ。

彼らは（あるいは簡単にできるはず）SLAの形で価値を加えていくね。正確さについて保障を提供することで、顧客には具体的な保証を与えて責任を移せるし、ベンダーもLLM OCRプロセスからさらに%の信頼性を得る技術やシステムに集中できる。こういうのは特に大きな企業が喜んで払うものだし、OCRは単なる歯車だから、信頼性や予測可能性が増すのはありがたい。加えて、EUの規制に完全に準拠していることを突き詰めるような付加価値も、業者が提供できる。

自分の課題は、OCRのためのバウンディングボックスをどうやって取得するかってことだ。

AWS Textractはこの点でうまく機能してるし、LLMを動かすよりかなり安いよ。

Textractは、少なくとも毎月最初の100万ページではこっちより高いし、Gemini Flashよりも大分高いよ。でも、確かにうまく機能してる - 試したオープンソースの純OCRソリューションよりは断然いいよ。

それは面白い課題だね。うまくいったのは、LLMに全ての抽出データの引用を生成させて、それを元のOCRコンテンツにマップし、バウンディングボックスを生成するシステムだよ。いくつかのエッジケースは確かにあって、時間をかけてヒューリスティクスのスイートを作ったけど、全体的にはすごくうまく機能してる。

なんでTextractを使わないでこれをするの？

私もその質問ありますね。

Checkrを顧客に持ってるなんてすごいけど、参照可能なの？

ところで、portkeyにはどんな’ダークパターン’があるの？

高精度が目標だけど、多モーダルアプローチは現実のパフォーマンスに影響を与える複雑さを持ちこむよ。詳細はレビューで解説してるよ：
「https://undatas.io/blog/posts/in-depth-review-of-mistral-ocr…」
ユースケースについては、エッジケースの扱いにどれだけ優れているかによるね…。