PDF取り込みに革命！Gemini 2.0がすべてを変える理由
引用元：https://news.ycombinator.com/item?id=42952605
fintechで働いてるんだけど、PDF取り込みでOCRベンダーをGeminiに変えたんだよね。色々試した結果、Geminiがマジ使いやすくて、ほとんど手間がかからずに動いたから。マルチモーダルでコンテキストウィンドウが広いモデルって、使いやすさの点でマジで過小評価されてると思う。皮肉なことに、そのベンダーは特定のPDFのOCRで一番有名で成功してるんだけど、リクエストの多くが人間のチェックに回されてたんだよね。Geminiは専門じゃないのに、テストしたらGeminiに変えるのは当然だった。処理時間は平均12分から6秒に短縮、精度はベンダーの96％くらいで、価格はマジ安かった。4％の精度誤差は、手書きの”LLC”が”IIC”ってOCRされたりするくらいで、まあまあ許容範囲かな。プロンプトを改善すればもっと精度上がるかも。今のプロンプトはマジ簡単で”このPDFをこのJSONスキーマで指定された形式でOCRして”ってだけ。Geminiの開発体験はマジ簡単だった。ファイル”part”をプロンプトに追加するのも簡単だし、コンテキストウィンドウがめっちゃ広いから、メインの問題に集中できるし。マルチモーダルだから、PDFの画像とかデータとか、色んな問題に対応してくれるし。このブログのユースケース（バウンディングボックスの部分は除く）にはマジおすすめ！
マジそれな。特定のPDFに特化した従来のベンダーは、LLMにマジで駆逐されると思う。既製のプロバイダーを使う問題は、データスキーマに縛られること。LLMなら、スキーマを完全にコントロールできるから、もっとユニークなデータを解析・抽出できるんだよね。
問題は”PDFからこのデータを抽出できるか”から、”必要なデータを抽出するためにLLMをどうやって教え、パフォーマンスを検証し、自信を持って本番環境にデプロイするか”に移るんだ。
プロンプトにchain-of-thoughtを追加すれば、さらに精度を向上させられるよ。例えば、JSONスキーマの各フィールドに、事前にreasoningフィールドを持たせて、モデルがどうやってその答えにたどり着いたかをCoTできるようにするとか。さらにレベルを上げるなら、citationsもパフォーマンスが向上するし（バウンディングボックスと組み合わせると、human-in-the-loop toolingにマジ強力）。
＞問題は”PDFからこのデータを抽出できるか”から、”必要なデータを抽出するためにLLMをどうやって教え、パフォーマンスを検証し、自信を持って本番環境にデプロイするか”に移るんだ。
賢いベンダーならその分野にシフトするだろうね。彼らはLLMを使い、ファインチューン、複数のLLM、従来の方法、ランダムサンプルの人間の検証を組み合わせて、”パフォーマンスを検証し、自信を持って本番環境にデプロイ”するだけでなく、SLA付きでその信頼性を販売するだろう。
ソフトウェアは死んだ。今プロンプトじゃなくても、6ヶ月後にはプロンプトになるだろう。今のソフトウェアのほとんどは、単なるUIになるだけ。でもUIも死んだ。
そういう意見には疑問があるな。大規模な組織で複雑なシステムを扱ったことないのかな？
PDFを確実に解析できるようになったのはいいけど、そのデータをどう活用するかが問題だよね。データを保存したり、レビューが必要な人に確実に届けたりする必要がある。彼らはそのデータに基づいて意思決定する必要があり、複数の関係者からのインプットが必要になることもある。
そういったやり取りはすべて記録・保存され、最終的な決定とすべてのサポートドキュメントが複数のシステムで利用できるようにする必要がある。それにはETLとかガバナンスが必要になる。
LLMとプロンプトでは、それらすべてを置き換えることはできない。
今動かしてるシステムを批判するんじゃなくて、ライトコーンの観点で考えるべきだよ。物事がどこに向かっているのかを見るんだ。コードと人の両方で、大規模なシステム、コンパイラ、大規模なデータ処理システム、1万のビジネスユニットで働いてきた。
10万人の従業員がいる組織のために、Salesforceの代替品をプロンプトできる？
昨日、/r/singularityで、OAIのリード管理プラットフォームのスクリーンショットに畏敬の念を抱いたよ。日本のコンベンションでSalesForceへの直接的な脅威を意味するらしい。マジかよ。
加速主義者とかAI信者とかは、ソフトウェア開発の本質的な複雑さを本当に理解していないと思う。LLMはソフトウェア開発の銀の弾丸と見なされているけど、銀の弾丸がどうなるかは知ってるよね。
18ヶ月後にまたコメントして。
これは、親の述べた問題に対するAIが実際には銀の弾丸であり、わずか18か月後には彼らがどれほど間違っているかに気づくだろうということを意味する皮肉だと解釈していいのかな？もしそうなら、これらの問題がうまく解決されているのを見たことや、18か月のタイムラインで解決されているのを見たことはある？それについてもっと知りたいな。
銀の弾丸ってわけじゃないけど、状況はマジで変わるよね。一部分だけ見て判断する時代じゃないんだわ。流れ全体を見ないと！論文の結果だけ見て「ここがダメ、あそこがダメ」って言うのはナンセンス。Two Minute Papersの「次の論文に期待！」って taglineがマジそれ。
データモートとかベンダーロックインがないソフトウェアはマジでやばい。手軽なSaaSはLLMで作られたソフトウェアにマジで駆逐されると思う。
賢いベンダーならその領域にシフトするっしょー。LLMを自分たちで使う的な。今からシフトは遅いかもね。もう製品が市場に出てないと。
スキャンしたドキュメントのプライバシーってどうなってんの？
いろいろ試行錯誤した結果だけど
たまにしか使わない身としては、Geminiで毎週4,5ページの同じレイアウトの書類を半年くらいスキャンしてるんだけど、毎週結果が微妙に違うんだよね。
書類はバイリンガルだから影響あるのかもだけど、一貫性のなさに驚く。同じモデルでも、2,3回連続で実行すると違う結果になるし。
個人的には問題ないけど、Googleがモデルを調整するたびに企業がプロセスを調整するのは悪夢だよね。かといって、同じモデルを使い続けるのも、Googleにお金を払い続けることになるし。
温度がゼロなら、同じAPI/モデル使ってるならそんなはずないんだけどな。大手はAPIをアップデートする時は、名前とかバージョンを変えるはずだし。
マジレスすると、それは違うんだよねー。mixture of experts routingってやつは、バッチ処理の非決定性があるみたい。理由は公表されてないけど、自分で試したり、バグレポートとか探せばわかると思う。大手LLM APIの結果は、温度ゼロでも決定的なgreedy samplingにはならないんだよね。
温度がゼロで、weightsも変わらないなら、非決定的な動きはどこから来るの？
ルーティングが原因かもね。でも、ベンダーがGPU捨てて、固定小数点演算に最適化されたASICに切り替えてない限り、浮動小数点数は非可換だから、並列計算で生じるランダム性で結果は非決定的になる。
同じGPUアーキテクチャで、同じソフトウェアなのに、なんで実行ごとに計算順序が変わるの？
あと、固定小数点演算を考えるなら、整数アキュムレータを使って並列処理した結果を足し合わせればいいじゃん。
なんで同じCPUで同じソフトが、実行するたびに違う順番で命令を実行するんだろ？ CPUの各スレッドは同じ順番で処理されるよ。 ＞CPUの各スレッドは同じ順番で処理されるよ。 親コメントは、温度が影響するのは生成の時だけで、リクエストがどの”expert model”に渡されるかの選択は非決定的だって言ってるね。単一の重みセットではなく、MoEではいくつかの異なる重みセットが”expert”を構成してるらしい。それが本当かどうかは知らないけど。 それって意味あるのかな？ まずセマンティックセグメンテーションがあって、その後にTextractみたいな方法でテキスト抽出して、ハルシネーションを防ぐんじゃないの？ みんなOCRプロバイダー（azure、tesseract、AWS Textractとか）の精度が85%くらいなの忘れがち。 OCR会社としては、これは許されないことだと思うよ。図書館のオーラルヒストリープロジェクトでOCRを使って、ハルシネーションエラーを起こしたら、事実をフィクションに置き換えることになる。歴史を書き換えるってこと？ OCRみたいなものって温度設定はすごく低くするんじゃないの？ 昔の税務会計の仕事みたいだ。 ついに無料でファイリングできるようになったんだね。ってことは、今世紀中には実現するかも？ これはマジで大きな発見だわ。Geminiが抽出と同時にセマンティックチャンキングを、しかも安価でほぼ完璧な精度で、さらに脆いプロンプトの呪文🧙なしにできるなら、これはマジですごいことだね。 Gemini 2.0を使って抽出とチャンキングを行い、ローカルネットワークで管理するRAGに供給する場合、知識ベースから意味のある洞察を得るには、どのようなローカルホスト型LLMが必要かな？13Bパラメータのモデルで十分かな？ 細かい点だけど、セマンティックチャンキングをしてるのかな？それともPDF全体をコンテキストにロードしてるのかな？セマンティックチャンキングについては賛否両論あるよね。 PDF全体をコンテキストにロードするけど、その後のRAGのためのチャンク分割は自分の仕事になるんだよね。でも、固定サイズのブロックに分割したり、文や段落で区切ったりするのは理想的じゃないんだ。 固定サイズのチャンクが、抱えてるRAGプロジェクトの多くを阻害してるんだよね。もしこのセマンティックチャンキングが問題を解決してくれるなら、マジで嬉しい。現在は固定サイズチャンクRAGで78〜82％の成功率しか得られておらず、これは低すぎる。ユーザーはRAG検索で結果がゼロだと、ソースデータに結果がないと思い込んじゃうんだ。 SEC filingを適切にチャンク分割しようと頑張ってるんだけど、特に企業ファイリングに存在する奇妙で一貫性のない表形式に苦戦してるんだ。 Geminiのような今日のLLMは、Google/AWS/Azureが数年前から提供しているDocument Understandingサービス、特に既知のフォームを扱う場合に比べてどうなの？GoogleのはDocument AIだよね。 一番精度が高い解決策は、専用モデルの1つでOCRを実行し、そのテキストと元の画像をLLMに、＞”このOCR転写のエラーを修正して”みたいなプロンプトでフィードすることだとわかったよ。 もしテキストの内容が不快だったり、家庭でUF-6ガスを精製するレシピについて話していたりしたら、どうなるんだろう？処理を止めて説教モードに入るのかな？ OCRパイプラインの各段階で、ツールの使い方が全部間違ってるからコストがめっちゃ高くなってるよ。画像からテキストを抽出するのに、マルチモーダルモデルは使わない方がいいよ。完璧な高画質画像じゃないと、すぐ幻覚を見始めるからね。文書セクションのバウンディングボックスを検出する専用のオブジェクト検出モデルを使うべき。各テキストボックスを通常のOCRモデルに渡せば、信頼度スコアも得られるし。画像ボックスは、マルチモーダルモデルに渡して内容を説明させるといいよ。表には、GridFormerみたいな表抽出専用モデルを使う。全部XMLファイルにまとめる。Markdownは人間が読むものだからね。これで、オブジェクト検出モデルが認識するカテゴリごとにフラットなXMLマークアップで抽出できて、バウンディングボックス、文字、表セルごとに確率メタデータも付いてくる。このデータをLLMにプログラムで送り込んでテキスト処理すれば、XMLを使ってドキュメントのどの部分をLLMに送るか制御できる。RAGストアに入れるチャンクには、場所データと信頼度スコアをメタデータとして付与できる。俺は上記の方法で、ローカル環境で1日50万ページ処理できるシステムを200万円で作ったぜ。 どのサービスを元に計算してるか知らないけど、Geminiだと1ヶ月で1000万件以上の配送書類（PDFとPNG）を1000ドル以下で処理できたよ。精度は80～82％（人間は66％）。開発で一番時間がかかったのは、精度と取り込みパイプラインの確立。これは、PDF -> Storage Bucket -> Gemini -> JSONレスポンス -> Databaseっていうシンプルな流れだったよ。Geminiステップに再帰処理を追加して、抽出の出来具合を自己評価させ、一定以下の場合は抽出方法の指示を書き換えて再投入してみたけど、精度は変わらなかった。面白かったけどね。 ＞どのサービスを元に計算してるか知らないけど、Gemmini Geminiの性能に匹敵するモデルを見つけられるって前提だけどね。まだそんなのないと思う（変わるといいけど）。 この記事、めっちゃ共感できる！去年（multimodal 3.5 Sonnetが出た頃）に大量のPDFを処理したんだけど、精度がめっちゃ高かった（99％くらい）。GPTは使い物にならなかったけどね。 めっちゃクール！データベースにはどうやって保存してるの？ベクター？抽出したデータをどう活用してる？クエリシステムで引っ張り出せるようにしてる？ このケースでは、顧客は倉庫在庫管理システムにないデータが欲しかったから、JSONレスポンスを古典的なテーブル行スキーマ（1行=1ドキュメント）に変換して、配送データとして活用したよ！生のモデルレスポンスは監査用に保存して、ベクター埋め込みもして、いずれベクター検索やRAGに使うだろうって想定してる。「ついでに、今やらなくてもいつかやるだろうことをやっておこう」みたいな感じ。 ＞ Kind of like “while we’re here why don’t we do what you’re going to want to do at some point, even if it’s not your use-case now…” ＞ why do it now and introduce complexity and debt if you can do it later when you actually need it? ＞ [with] an accuracy rate of between 80-82% (humans were at 66%) なるほどねー、AIの実力って、人間と同じで答えがわかってるテストを作って試すしかないんだよね。だから精度評価が一番時間かかったんだ。AIを評価するために、手動で”正解データ”を作る必要があったからね。 ちょっと言わせて。決めつけすぎじゃない？限られたテーブル形式で成功したからって、それがPDF解析の唯一の方法みたいに言うのは違うと思うな。現実は、ズレまくったテーブルとか、ヘッダーがおかしかったり、線が抜けてたり、色で区切られてたり、セルが結合されてたり、Excelからインポートされたり、色々あるんだよ。ClaudeとかGeminiなら複雑なテーブルも解析できるのに、あなたのやり方じゃ無理だと思う。ルールが曖昧だからね。written languageみたいに。 関連ディスカッション：AI founders will learn the bitter lesson 決めつけすぎだって。 うわ、すごい攻撃的な返信だね。誰もあなたのこと無能だって言ってなくて、あなたの仮定を批判してるだけなのに。 Marker(https://www.github.com/VikParuchuri/marker)は、これと似たような感じで、レイアウトモデルを使ってブロックを識別し、それぞれを個別に処理するんだ。内部形式はブロックのツリーで、任意のフィールドを持てるけど、全部htmlにレンダリングできる。json、html、markdownに出力できる。 このプロジェクトでsxml [0] を皮肉なしに使いまくったよ。 インクの染みとかコピー機の故障とかがあるなら、別々に処理するより、他のテーブルで使われてる頭字語とか、もっと広いコンテキストから推測できた方が良くない? 自分のプロジェクトの情報を紹介してるスレッドで、別の人が自分のプロジェクトについて紹介してるのに、自分のプロジェクトを宣伝するのはどうかと思うよ。 markerってdoclingに何を追加するの？ Doclingはマジで良いプロジェクトだよね、盛り上がってて嬉しいわ。Markerの方がほとんどのドキュメント形式でdoclingより高品質になると思うよ、特に–use_llmフラグを使うとね。 これは良いコメントだね。このアプローチのもう一つの利点を挙げるよ。デジタルネイティブでOCRが必要ないPDFにも同じパイプラインが使えるんだ。オブジェクト検出のステップの後、バウンディングボックスから直接テキストを収集するから、テキストにエラーがないんだよね。Geminiを使うと、これを諦めることになる。 それってもう過去の話じゃん？AIの進化で、OCRのあんなにたくさんのステップや段階はもう要らないんだよ。XMLもいらない。MarkdownでAIモデルが十分に理解できるから。 うちが18ヶ月前に出した結果は、今のGeminiのベンチマークより良いのにコストはもっと低いんだよね。Markdownは良いとして、テキストが正しいかっていうモデルの信頼度に関するメタデータをどうやってエンコードするの？XMLには属性っていう便利なものがあって、LLMが読める形式で来歴を記録できるんだよね。セカンドデータベースも要らないし。 後でこのコメントを見つけられるようにコメントしとく。AIの盛り上がりをこの短いパラグラフで完璧に捉えてるね。 なんで昨日までの世界に甘んじる必要があるんだ？昨日までの世界は、精度が高くて、コストが低くて、ローカルにデプロイできるのに。今日の新しいツールを使って、車輪の再発明をして、全部クラウドに置いて、タダでハルシネーションを手に入れるのかよ… 昨日までの世界のツールって具体的に何のこと？PDFの解析でPythonの基本ライブラリで問題があったんだよね。最新のツールじゃないと正しく情報を解析できなかった。 GP（原文のコメントをした人）の言う通りだね。 それってコストが高いし、ハルシネーションを起こすし、ベンダーロックインされるじゃん。 なんでベンダーロックって言うの？構造化された出力をサポートしてGeminiと競合してるトップレベルのLLMが4、5個あるじゃん。LLMベンダーが構造化出力のためにパイプラインを構築したら、新しいモデルをすべてパイプラインに通すと思うよ。 ぶっちゃけ、Geminiがドキュメントベースのオブジェクト検出モデルを使ってないとは確信できないなー。少なくとも一部の箇所とか、ドキュメントのカテゴリによってはね（特にIDとか請求書、税務書類、発注書、配送書類とか、DocAIクラウドサービスの一部として以前にドキュメント抽出器を作成したことがあるような一般的なもの）。 この投稿から”苦い教訓”的な雰囲気を感じる。 苦い教訓ってほどでもないんじゃない？もし無限のメモリ、計算能力、データがあったら、長さNの入力に対してランクNのテンソルを使って終わりだよ。残念ながらN^Nはすぐに大きくなっちゃうから、ML計算を宇宙の熱的死を迎える前に完了させるために、いろいろ面白いエンジニアリングが必要になるんだよね。 ＞ほとんどのAI研究は、エージェントが利用できる計算量が一定であるかのように行われてきた（その場合、人間の知識を活用することがパフォーマンスを向上させる唯一の方法の1つになる）。しかし、典型的な研究プロジェクトよりもわずかに長い時間では、必然的にもっと多くの計算が利用可能になる。より短期間で違いを生む改善を模索して、研究者はドメインに関する人間の知識を活用しようとするが、長期的には計算の活用だけが重要になる。これら2つは対立する必要はないが、実際にはそうなる傾向がある。一方に費やす時間はもう一方に費やす時間ではない。一方のアプローチまたは他方への投資には心理的なコミットメントがある。そして、人間の知識アプローチは、計算を活用する一般的な方法を利用するのに適さない方法でメソッドを複雑にする傾向がある。” 数学的なトリック（畳み込みとかアテンションヘッド）なしでmnistを解くには、2.5e42の重みが必要になる。16ビットの重みを使うと仮定すると、5e42バイトになる。1ヨタバイトは10e24。 ちょっと細かいこと言いすぎじゃない？ビジネス上の決定は、コストだけじゃなくて、脆さ、メンテナンス、市場投入までの時間も考慮されるんだよ。Geminiのパフォーマンスに匹敵するものが作れるって決めつけてるし、Googleのエンジニアリングリソースとコストが今後も一定だっていう前提もおかしい。 すごいね。このプロジェクトについてもっと詳しく教えてくれない？1日に50万ページってすごい量だし、それだけのスループットが必要な理由も想像できる。 テーブル検出できるモデルで、実装が公開されてるものってGridformer以外に何か知ってる？ 何のオブジェクト検出モデルを使ってるの？ マジすごくね？ある会社が、エディタから構造化されたデータ（画像は除く）を取り出して、完全にグチャグチャな非構造化形式に変換する、普遍的に普及した形式を発明したんだぜ。で、それを構造化データに戻すには、高い金払って怪しい魔法が必要になるとか、ありえなくね？もっとコメントを表示（1）
パフォーマンスのためだよ。ちゃんと動かしたいなら、自分で同期させなきゃ。GPUは並列プロセッサが何万個もあって、めちゃくちゃ複雑なんだから。速く計算するように設計されてて、全部がいつも同じように動くとは限らないんだよね。
GPUでの推論は、(X1、X2、X3、… Xn)の並列処理みたいなもん。各Xは行列の並列処理で計算される。どこかに順番を保証する仕組みがない限り、適当に計算して浮動小数点誤差が出るんだよね。GPUの専門家じゃないから詳しくは知らないけど、最近のGPUはゲーム向けに最適化されてて、精度はそこまで重要じゃない。だから、GPUが急に性能を犠牲にしてまで決定性を保証するとは思えないな。
なんでニューロンの計算を複数のスレッドに分割するんだ？
そんなの遅くて複雑になるだけじゃない？
どうしてもそうしたいなら、複数ブロックで計算する部分だけ整数を使えばいいし、そんなに手間じゃないよ。
そもそも、GPUに非決定的なドット積の命令が組み込まれてるの？
”スケジューラを制御して、強制的に順番を決めないと無理。コードを知ってるだけじゃダメで、物理的な環境にも影響されるんだ。例えば、チップの温度がちょっと違うだけで、スレッドの割り当てや終わる順番が変わる可能性があるよ。”
＞なんでニューロンの計算を複数のスレッドに分割するんだ？
”入力の数によるけど、必ずしも分割する必要はない。でも、交換法則が使えると思えば、並列化が楽になるし、オーバーヘッドも減らせるんだ（スループットとメモリの両方で）。”
＞そもそも、GPUに非決定的なドット積の命令が組み込まれてるの？
”ないよ。任意の長さのベクトルを処理できるドット積命令なんてないから。ループを書く必要があって、それが並列処理になるんだ。”
どこかにRNGがないとそうならないと思うけど。MOE自体はランダム性を持たないし、エキスパートへのルーティングはモデルの重みの一部で、別のモデルじゃないと思う。
マルチモーダルモデルで抽出したテキストがハルシネーションを起こさないなんてありえないよね？
ベンダーの精度が96%で、価格がかなり安いってどうやってテストしたんだろ？
人間がランダムにサンプルテストした場合、エラーの分布の変動をどうやって調整するんだ？
全部確率的なんだよ。文字と信頼区間が返ってくる。Textractが間違った文字を返してきたら、それはハルシネーションなの？
毎回同じ結果が欲しいはずだし。ハルシネーションの一部って温度のランダム性じゃないの？
OCRはあったけど、エラーを修正するより手で入力した方が早かった。
本当の解決策は、IRSが税務申告書に会計データをあらかじめ入力しておくことだよ。でも、政府がそんなこと気にするわけないか。
だから、Geminiに可変サイズのチャンクを返すように依頼して、各チャンクが1つの完全なアイデアや概念になるように、論理的なセマンティックセグメントをarbitrarilyに分割せずに済むようにしたい。
これが可能になるかもしれないって希望が出てきたよ。
皮肉で聞いてるんじゃないんだ。LLMを不快な入力や未知の入力で動作させるタスクに使用した経験が少ないから、あらゆる種類の予測不可能な道徳的判断によってトリガーされ、求めていない出力が生成されてしまうんだ。
特定のテキストのキーワードを含むJSON出力を要求した場合、それが不快だと拒否される。どう対処すればいいの？もっとコメントを表示（2）
ブログ記事のコスト表だよ。1日50万ページだと、240日でハードウェアの固定費がソフトウェアの変動費を上回って、それ以降はクラウドで実行するのに1日100ドル余計にかかる。しかも、必要なモデルを全部入れるには、めっちゃ高性能なGPUが必要だった。コンピューティング利用率は5～10％で、データソースの成長率からすると、今後5年間は大丈夫ってこと。
| Model | Pages per Dollar |
|—————————–+——————|
| Gemini 2.0 Flash | ≈ 6,000 |
| Gemini 2.0 Flash Lite | ≈ 12,000* |
| Gemini 1.5 Flash | ≈ 10,000 |
| AWS Textract | ≈ 1,000 |
| Gemini 1.5 Pro | ≈ 700 |
| OpenAI 4o-mini | ≈ 450 |
| LlamaParse | ≈ 300 |
| OpenAI 4o | ≈ 200 |
| Anthropic claude-3-5-sonnet | ≈ 100 |
| Reducto | ≈ 100 |
| Chunkr | ≈ 100 |
それに、完全にローカル環境だから、社外秘のデータソースも全部使える。開発期間で一番長かったのは、精度と取り込みパイプラインの確立。PDF -> Storage Bucket -> Gemini -> JSON response -> Databaseっていうシンプルな流れだった。各社は、開発者のスキルレベルに合ったツールを構築すべき。モデルのローカルトレーニングが難しいなら、既製のソリューションを使えば、業界で一気に有利になれるよ。
マジでひどい。
本当に必要になるまでやらなくていいのに、複雑さと負債を増やすのはなぜ？
ただの流行に乗っかって、最大限に利用しようとしてるだけだよね。まあ、それもいいけど。
雪が降るまでスノーブーツを買わないのと同じ理由だよ。自分の環境、地形、規模、リスク、コストを把握してるから、スノーブーツが必要になる無数のケースを想定できるんだ。たとえ5月でスノーブーツがセール中だったとしてもね ;) ちょっとしたクローゼットのスペースと、家を出るときにドアをロックする手間くらい、どうってことないさ。
これって、誰かが検証したの？そうでなければ、どうやって精度を確かめたの？
最近HNでこんな記事が出てたよ。https://lukaspetersson.com/blog/2025/bitter-vertical/
＞You don’t use multimodal models to extract a wall of text from an image．They hallucinate constantly the second you get past perfect 100% high-fidelity images．
＞”画像からテキストの壁を抽出するために、マルチモーダルモデルを使用しないでください。完璧な１００％高忠実度の画像を過ぎると、絶えず幻覚を見ます。”
いや、そうじゃなくて、ネストされたJsonとかXmlで。金融ドキュメントなら精度は99%以上だよ。エラーチェックする方法も色々あるし。
＞This is using exactly the wrong tools at every stage of the OCR pipeline, and the cost is astronomical as a result．
＞”これは、OCRパイプラインのすべての段階でまったく間違ったツールを使用しており、その結果、コストが天文学的になります。”
どこでどう使うか知らないでコストの話はしない方がいいよ。何百万ものPDFを処理するなら問題だけど、1000くらいならGeminiとかを使った方がエンジニアリングの時間節約になるかも。1つのドキュメント処理で10ドル稼げるアプリもあるし、OCRコストなんて気にしない。
＞I’ve build a system that read 500k pages per day using the above completely locally on a machine that cost $20k．
＞”上記を使用して、１日に５０万ページを完全にローカルで、２万ドルのマシンで読み取るシステムを構築しました。”
著者のやり方は、彼にはうまくいったってだけで、万能じゃないんだよ。
https://news.ycombinator.com/item?id=42672790
- 25日前、263コメント
HNのディスカッションには面白いアイデアがたくさんあるよ、ありがとう!
1) 公開されてるテーブルベンチマークを無視するほど無能だとか
2) 低品質なデータを見たことないほど無能だとか
3) 利用可能なすべてのモデルに対して、検証データセットを作成しないほど無能だとか。
全部違うから。もしGeminiみたいなVLMが、いかにスペクタクルで予測不能に失敗するか知りたかったら、1時間400ドル＋税で教えてあげるよ。
＞My day rate is $400 + taxes per hour if you want to be run through each point
＞”各ポイントを実行する場合は、1時間あたり400ドル+税です。”
へー、すごいね。
最近、テーブルみたいな特定のブロックの精度を上げるためにGeminiを統合したんだ（最初のテキストを取得して、Geminiに渡して改善）。MarkerだけでもGeminiだけでも同じくらいの性能だけど、組み合わせるとベンチマークがかなり良くなるよ。
人間が見るレポートのレンダリングは、sxmlをmarkdownにレンダリングした後にpandocを呼び出すステップだった。ほら、powerpointもサポートしてる! - でも、どんな言語モデルでも最高のマークアップに簡単に変換できたんだ。
[0] https://en.wikipedia.org/wiki/SXMLもっとコメントを表示（3）
具体的には、Geminiとのハイブリッドモードでページを跨いでテーブルを結合したり、フォームの品質を上げたりしてる。
あと、順番がおかしいPDFのために並び替えモデルも動かしてる。
OCRもめっちゃ良くて、Suryaっていう独自のモデルを訓練してる - https://github.com/VikParuchuri/surya
参照とリンクも扱えるし、数式変換もどんどん良くなってるよ（インラインも含む）。
すでに最適化されたパイプラインがあるなら、そりゃ使い続ければ良いと思うよ。
でも、今日PDFを扱うなら、Geminiを使えば良いんじゃない？AIが理解しやすい形式を使うべきだよ。XMLファイルをどうこうするなんて考えなくて良い。
つまり、それを解くには5エクサヨタバイトが必要になる。
現在、全世界のストレージは約200ゼタバイト。
つまり、mnistを解くには、今後120年間は数学的なトリックが必要になる。
