AIプロダクトの精度が上がらない時、焦ってモデルを訓練してはいけない：Hamel Husainがまとめた13の実戦セッション

Hamel Husain（大規模モデル評価の第一線で活躍する実践者であり、AI Evals講座のメイン講師の一人）が「AIプロダクトエンジニアリング」に関する13のセッションを開催し、9.5時間分の内容を20分で読めるノートに凝縮した。本解説ではその13セッションを余すところなく解説する。各セッションの完全版録画はYouTubeまたはMavenで公開されており、各節の末尾に視聴リンクを掲載している。

大規模モデルを使いやすいプロダクトに仕上げるためには、調整できる要素が数多く存在する。本セッションで提示された優先順位は次の通りである：

1. 評価は土台である。評価とは、固定された一連のテストケースと、明確な採点方法の組み合わせである。システムのパフォーマンスを正確に測定できて初めて、その後の変更が改善なのか改悪なのかを判断できる。
2. まず検索とコンテキストを改善する。これは最も効果が現れやすい領域である。まずはモデルに投入する材料を正しく整えることから始める。
3. 次にシステムとハーネス（外殻）を改善する。ハーネス（harness）とは、モデルの外側に位置し、ツールの呼び出しやワークフローの管理を担うプログラム層を指す。この層には推論速度、ハードウェアコスト、実行環境も含まれる。
4. 事後訓練は最後に行う。前のステップをすべて試した後に、ようやくモデル自体の改変を検討する。評価、検索、ハーネスの改修で手を加えるのはコード、プロンプト、設定であり、費用が少なく済み、効果の現れが早く、問題が生じても元に戻しやすい。対して事後訓練はデータの準備、計算リソース、時間を要する。信頼できる評価系がなければ、訓練後にモデルが本当に向上したのか、それとも別の部分が悪化したのかを判断することすらできない。

具体的な課題に直面している場合は、該当する節へ直接ジャンプできる：

• 成果が安定せず、具体的にどこに誤りがあるか分からない：エラー分析、教育プラットフォームの教訓
• 分類タスクで大規模モデルを呼び出すコストが大きすぎる：モデルカスケード
• データ分析Agentのクエリ実行でエラーが多発する：データ分析Agent
• RAG検索で重要な詳細が欠落する、または的確にヒットしない：マルチベクトル検索、埋め込みモデルの選定、検索Agent
• PDFやスキャン文書のレイアウト解析が乱れる：OCRの選定
• Agentに長文を書き直させると重要な決定事項が欠落する：Subtext
• 回答の生成が遅く、ユーザーの待ち時間が長すぎる：推論レイテンシ
• オープンソースモデルの導入を検討しているがVRAMの計算が定まらない：オープンソースモデルの経済学
• Agentがコードを実行する際にセキュリティリスクや予期せぬクラッシュが発生する：Agentへのサンドボックス導入
• モデルのファインチューニングを検討しているが必要性に確信が持てない：事後訓練

評価：まず何が間違っているかを把握する

この層が解決するのは「変更に効果があったかをどう確認するか」である。プロンプトを調整したりビジネスロジックを変更したりするたびに、固定されたテストケースを実行し、スコアによってシステムが進歩したのか後退したのかを確認する。以下の4つの節では、優れた評価とはどのようなものか、いかにして真のエラーを先に見つけ出すか、精度を維持しながらコストを削減する方法、そしてあるチームが実際に直面した落とし穴について解説する。

データ分析Agent：最も多い失敗は計画であり、データの選択ミスではない

データ分析Agentは、企業のデータベースに接続し、自らクエリやコードを作成して「どのユーザー層の解約率が最も高いか」といったビジネス上の質問に回答する。こうした問題は従来データアナリストが担当しており、ナレッジワークにおいて大きな割合を占めるが、Agentの回答精度を適切に測定できるベンチマークはほとんど存在しなかった。

Shreya ShankarはデータAgentベンチマークであるData Agent Benchmark（DAB）を紹介した。実際のデータウェアハウスは雑多で乱雑であり、DABは意図的にその中の4種類の実務的な難しさを再現している：

• 複数データベースの統合：1回のタスクに必要なデータが、少なくとも2種類以上のデータベースシステムに分散している。
• 結合キーのフォーマットの不統一：たとえば（例示であり実データではない）同一のユーザーが、ユーザーテーブルでは USER_1001 と記録され、注文テーブルでは usr-1001 や 1001 となっているようなケースである。Agentはこれらが同一人物であると自ら判断しなければ、2つのテーブルを結合できない。
• 非構造化テキストの変換：重要な数値が自由記述のテキストの中に埋もれており、まず文章から抽出する必要がある。
• ドメイン知識：質問に正しく回答するためには、その業界特有の専門概念を理解している必要がある。

論文では、既存の5種類のベンチマーク（Text-to-SQL、テーブルQA、データサイエンス＆エンジニアリング、セマンティッククエリ処理、汎用ツール呼び出し）との比較を行っている。4つの項目すべてを網羅しているのはDABのみであり、特に前述の2項目はいずれの既存ベンチマークもカバーしていなかった。

DABは汎用ベンチマークであるため、自社プロダクト向けに構築する評価とは問う問題が異なるが、その失敗分析はデータAgentを構築する上で非常に有益である：Agentの誤りで最も多いのは、計画や実装自体の記述ミスであり、データの選択ミスではない。 Agentは着手時にまず計画を作成するが、作業の中盤でデータが計画時の前提と一致しなくなっても、そのまま当初の計画通りに進めてしまうことが頻繁にある。自身のデータAgentをデバッグする際には、この種のエラーに注目する価値がある。DABは公開提出を受け付けており、結果はDABリーダーボードで確認できる。新モデルのリリース時にチームによって更新されているため、注視に値する。

ShreyaによるDABの完全なセッションはYouTubeで視聴可能である。

モデルカスケード：確信のあるものは小モデルに、確信のないものだけ大モデルに渡す

大規模モデルの実用的なシナリオの多くは、本質的には分類タスクである。たとえばカスタマーサポートのチケットを緊急度に応じてタグ付けしたり、不適切なコンテンツを判定したりする処理である。大規模モデルは手軽に利用できるため、あらゆるリクエストを最も大きく高価なモデルに丸投げしてしまいがちだが、呼び出し量が増えるとコストが跳ね上がる。

Shreyaが紹介したBARGAIN（論文 arXiv:2509.02896）の目標は、設定した精度を維持しながら、分類作業の大部分を小モデルに移譲することである。ホワイトボードで実演されたシナリオはチケットの「はい／いいえ」判定である。gpt-5.6 solを直接使えば高精度だが高価すぎる。BARGAINのアプローチは、まず安価なgpt-5-nanoに判定させることである。小モデルは回答を出力すると同時に、確信度（その回答に対してどれだけ確信があるかを示す0から1の間の数値。例えば0.98は確信が非常に高く、0.55は当てずっぽうに近い）を出力する。さらに閾値 τ を設定する。確信度が τ より高ければ、小モデルが十分に確信していると判断してその回答をそのまま採用し、τ 以下であれば、そのデータを大モデルに渡して再判定させる。

閾値 τ を高く設定すると、より多くのサンプルが大モデルに送られるため結果はより正確になるが、コストも高くなる。低く設定すると、より多くのサンプルが小モデルで処理されてコストは抑えられるが、小モデルの誤判定が増える。注意すべきは、ここでの精度は最終的な結果が大モデルの判定と一致する割合であり、人間によるアノテーションと一致する割合ではないという点である。モデルカスケードの目的は、大モデルと同じ回答をより低いコストで得ることにあり、大モデル自体の判定が正しいかどうかは別の評価で検証すべき問題である。

本番導入前に、一定のサンプルを用いて閾値 τ を決定する手順は次の通りである：

1. 約500件のサンプルを抽出し、小モデルで一度実行して、各サンプルの回答と確信度を記録する。
2. 対照群として、大モデルにもその500件を判定させる。
3. 同じサンプル群を用いて、小モデルの確信度が高いほど、本当に大モデルとの一致頻度が高くなっているかを検証する。もし小モデルが「高確信」としている時でも大モデルと頻繁に不一致を起こすなら、確信度の信頼性は低く、確信度に基づいて振り分ける手法自体が成り立たない。
4. サンプル内に出現した各確信度を閾値として順にシミュレーションし、振り分け後の一致率とコストを計算して、目標（例えば大モデルと95%一致）を達成する閾値の中から最もコストが低いものを選択する。

論文では8つのデータセットでテストを行い、BARGAINは同種の手法と比較して最大86%多くのコストを削減できたと報告されている。

後続の研究であるTask Cascades論文では、さらに3つの最適化が加えられた：安価なモデルでも回答できるようにプロンプトを簡略化された問題へと書き換えること、ドキュメント全体を読まずに関連度の高い数段落のみを読んで入力tokenの消費を抑えること、そして複数のカスケードの組み合わせから精度目標を達成しつつ最小コストとなるパイプラインを探索することである。BARGAINのようなカスケードと比較して、平均でさらに48.5%のコスト削減を達成している。

詳細な解説はShreyaによるモデルカスケードの録画を参照されたい。

エラー分析：評価基準を書く前に、まずデータを見よ

システムのパフォーマンスが期待を下回った際によくある過ちは、データを全く見ずに評価ルーブリック（採点基準）を作成してしまうことである。頭の中の想像だけで列挙した問題は実際の運用では発生しないかもしれず、逆にタスクを失敗させている真因が含まれない恐れがある。

まず行うべきはエラー分析である。実際の実行トレース（trace：モデルがタスクを完了するまでの各ステップの入力、出力、ツール呼び出し）を1件ずつ読み込み、繰り返し発生するミスを失敗類型の分類表としてまとめる。例えば次節の指導案作成アシスタントにおける「1回で学習目標を2つ書いてしまう」というのが1つの失敗類型である。これは評価プロセスの中で最も人手を要する作業である。Shreyaが紹介したError Discoveryスキルは、この労力を大幅に軽減してくれる。人間がアノテーションを進める傍らで失敗類型の分類表を更新し、新しいパターンが見つかるたびに過去のログを振り返って同様の事例がないかをチェックする。これはアクティブラーニング（active learning）の考え方を採用したものであり、端的に言えば、ランダムにログを抽出して人間に見せるのではなく、すでにラベル付けされた内容に基づいて、新たな問題を暴き出す可能性が最も高いログや、人間の判断が最も必要なログを優先的に提示する仕組みである。

そのワークフローは3つのステップからなる：

1. ローカルレビュー画面の立ち上げ：Python標準ライブラリでローカルサーバーを起動し、単一ファイルのウェブページを連携させる。依存関係のインストールは不要である。ページ上では色、スペーシング、フォントを用いて役割、階層、本文とコードを区別し、長大な実行トレースを快適に読めるようにしている。
2. 最初のサンプル群の抽出：特徴量を抽出し、ログを6〜10個のグループにクラスタリングして、重複を排除しながらできる限り多様な15〜25件のサンプルを選んでレビューを開始する。そのうち60%〜70%は各グループの代表例、30%〜40%はランダムサンプリングである。
3. 人間とAgentの交代制プロセスの推進：人間は画面上でサンプルを読み、テキストをハイライトし、メモを記入して、Agentの提案を承認または却下する。Agentはこれらのラベルに基づいて失敗類型の分類表を更新し、次のサンプル群を選定して画面にプッシュする。

Agentには2つの動作モードがある。幅優先モードは未見の失敗類型を発見するために新たなサンプルを提案し、深さ優先モードは特定の失敗類型を徹底的に掘り下げるため、類型ごとにサブAgentを配置してより多くのログから類似の事例を探索する。最終的に、失敗類型の分類表、レビュー済みのサンプルセット、そしてカバレッジと収束状況のサマリーが得られる。

このスキルの具体的な使用法については、ShreyaによるError Discoveryのデモ動画を参照されたい。

教育プラットフォームの教訓：2人のアノテーターの一致率はランダム以下だった

Lucas Machado Rochaは評価を活用し、ブラジルの非営利教育プラットフォームNova Escola（月間アクティブユーザー約100万人、教師20万人を支援）の指導案生成アシスタントを改善した。彼のチームは2つの過ちを犯した。

第1に、エラー分析を行わずに評価基準を作成してしまったことである。結果として基準内の大半の項目は実際の出力では一度もエラーにならず、チームは使い道のないデータのアノテーションに無駄な工数を費やした。第2に、プロンプトの修正だけで解決できる問題に対して専用の評価器を作成してしまったことである。アシスタントが時に学習目標を2つ作成してしまうことがあり、正しい形式は1つだけであるべきだった。チームがプロンプトを修正したところ、問題は解消した。どのような失敗に対して自動評価器を構築する価値があるのかについては、Hamelが評価FAQの中でこのトレードオフについて詳しく論じている。

アノテーションの過程で、さらにもう1つの問題が浮き彫りになった。チームが2人のアノテーターを雇い、同一の指導案群に対してそれぞれ採点を行わせたところ、2人の意見の一致率がランダムに割り振った場合よりも低かったのである。2人が同じ指導案を真剣に読んでいるにもかかわらず結論がほぼ一致しなかったことは、問題がアノテーターにあるのではなく、チームが「何が良い指導案か」を明確に定義できておらず、各自が独自の解釈で採点していたことを示していた。チームは教育の専門家とともに評価基準を書き直し、データを再アノテーションした。

エラー分析によって失敗類型を特定した後、Lucasはeval skillsを用いて後続の作業の一部を自動化した。これには判定器（大規模モデルに評価基準に従って採点させるプログラム）の作成や、人間のアノテーション結果と照合して判定器の採点が正確かどうかを検証する処理が含まれる。判定器自体もモデルであるため、検証を行わなければそのスコアが信用できるかどうかが分からない。本番稼働後、彼らは本番トラフィックの2%を毎日この評価システムで実行し、プロンプトの変更やモデルの切り替えによって正常だった出力が悪化するといった性能低下を早期に検知している。

Lucasによる最初から最後までの実践の全容は、彼のセッション録画で確認できる。

検索とコンテキスト：多くの場合、問題はモデルに投入する材料にある

モデルが誤答する場合、その多くはモデルの知能不足ではなく、投入された材料が不適切であることに起因する。見つかっていない、詳細が欠落している、あるいはフォーマットがすでに乱れているといったケースである。この層は最も成果が出やすい部分である。以下の5つの節では、検索で詳細を保持する方法、検索Agentの評価と診断方法、埋め込みモデルの選び方、PDFを正しく読み取る方法、そしてドキュメントの改変時に重要情報を落とさない方法について解説する。

マルチベクトル検索：各tokenにベクトルを保持し、その上でコストを抑え込む

一般的なベクトル検索では、ドキュメント全体を1つのベクトル（テキストの意味を表現する数値の列）に圧縮し、検索時にはクエリのベクトルとドキュメントのベクトルの類似度を比較する。例えるなら、これは小説一冊を1行のあらすじに要約するようなものである。大まかな意味は残るが、具体的な数値、人名、パラメータといった詳細情報は平坦化されて失われてしまう。これが情報ボトルネックである。

Marek Galovicが解説したマルチベクトル検索は、このボトルネックを回避する手法である。クエリとドキュメント内のすべてのtokenに対して、それぞれ個別のベクトルを保持する。採点方法はMaxSimと呼ばれる。クエリ内の各tokenが、ドキュメント内のすべてのtokenの中から最も意味の近いものを探し、その最高スコアを記録する。そしてクエリ内の全tokenの最高スコアを合算したものが、そのドキュメントのスコアとなる。これにより、クエリ内のすべての単語がドキュメント内で自身の対応先を見つけることができ、圧縮時に詳細が失われることがない。

Marekのスライドによると、この手法はクロスドメイン検索や長文検索において、現時点で最高水準の性能を達成している。問題はコストである。ドキュメント内の全tokenのベクトルを保存する必要があり、比較時にはクエリの各tokenとドキュメントの各tokenを総当たりで比較するため、比較回数は双方の長さを掛け合わせた分だけ増大する。Marekの試算では、MaxSimの計算量は単一ベクトルの内積計算の約2000倍、ストレージ消費量は10〜100倍に達するため、長らく論文の中にとどまっていた。

これを大規模に実用化するため、Marekが解説した中核的な最適化がSMVEである。その核心的なアプローチは、まず安価なインデックスで大半のドキュメントをふるい落とし、残った少数に対してのみ高精度なMaxSimを実行することである。具体的には、各tokenのベクトルを多数のランダムな方向のベクトル空間に射影し、値の大きい上位8つのみを残す。1つのドキュメントの全tokenの結果を足し合わせることで、大半の位置がゼロであるスパースなベクトルが得られ、これを転置インデックスに格納する。転置インデックスは書籍の巻末索引のようなものであり、項目を引けばそれが含まれるページに直接飛ぶことができ、その単語が出現しないページを見る必要は一切ない。検索時には、クエリと共通の項目が全くないドキュメントは即座にスキップされ、計算負荷の高いMaxSimは残された少数の候補ドキュメントに対してのみ計算される。

Marekの報告によると、10億文書の規模においてp99レイテンシは100ミリ秒未満を達成した。すなわち、99%のクエリが100ミリ秒以内に応答を返す。彼のチームはさらにIso-ModernColBERTも公開した。これはGTE-ModernColBERT-v1の修正版であり、ベクトルの幾何学的分布がSMVEのランダム射影と適合するように設計されている。bf16精度で実行した場合に約3倍高速化され、ランキング品質の低下はほとんど見られない。

Marekによるマルチベクトル検索の完全版セッションはMavenで公開されている。

検索Agent：ボトルネックは検索器にあることが多い

検索Agentは、1回検索して回答を出すのではなく、何を検索すべきかを自ら決定し、結果を読み、何が不足しているかを判断して再検索を行い、数ラウンドの試行を経て初めて回答を導き出す。この種のAgentを開発する際には、適切な評価課題がない、どのステップで迷走したか分からない、そして問題が検索にあるのかモデルにあるのか切り分けられない、という3つの難題によく直面する。

Nandan Thakurのセッションでは、これら3つの難題に正確に対応する3つのプロジェクトが紹介された。

ORBIT：コストをかけずに複数ラウンドの検索を要する評価問題を合成する。 ラベル付きの評価問題がない場合、モデルにドキュメントを参照させて問題を作成させることが一般的だが、そうして作られた問題は1回の検索で正答できてしまうことが多い。ORBITは逆のアプローチを取る。ある対象のいくつかの特徴を記述するが、その名前は明かさず、何ラウンドも検索しなければ正答できない難易度になっているかを検証する。たとえば（例示であり実データではない）、「ある作家は海辺の小さな町で生まれ、処女作で新人賞を受賞した。後に映画監督へと転身したが、彼が監督した2作目の映画のタイトルは何か？」といった問題である。正答するには、まずこの人物が誰であるかを検索し、その上で彼の作品を検索しなければならない。

合成された問題には誤りが含まれる可能性があるため、すべての問題に対して検証が行われる。検索Agentは元のドキュメントと問題文中の記述を1項目ずつ照合しなければならず、別の独立した判定モデルもそれらのドキュメントのみを参照して同一の回答を導き出せなければならない。ORBITパイプラインは2万件の検証済み問題を生成したが、検索APIや有料の大規模モデルの利用コストはゼロであった。パイプライン全体が完全な合成によるものであるため、アノテーションデータを持たないチームでも利用可能であり、自社のコーパスにも同様の手法を適用できる。

Hawkeye：各実行がどのように展開したかを可視化する。 Hawkeyeは、検索Agentの各実行がステップごとにどのように展開したかを一目で把握できるようにする可視化分析インターフェースである。スライドに示されたデータの一例では、781回の実行のうち、正答が444回、誤答が46回、未回答が291回であった。正答した実行の平均検索ラウンド数は18.9ラウンドであったのに対し、未回答の実行は平均42.2ラウンドであった。つまり、多数のラウンドを検索しても結果が出ない実行は、大半が答えを見つけられないまま終わっている。このような全体像を把握することで、自身のAgentに対して適切な最大検索ラウンド数を設定し、上限に達したら打ち切ることが可能になる。Hawkeyeの論文は現在査読中であり、現時点では公開ツールはないが、普段使っているコーディングAgentにこの考え方に沿った同様の可視化ツールを作成させることができる。

BrowseComp-Plus：適切な文書を与えれば、モデルはほぼ全問正解する。 BrowseComp-Plusは、OpenAIのBrowseCompの再現可能なオープン版である。BrowseCompには見つけるのが難しい事実に関する問題が集められている。回答自体は短く検証しやすいが、何度も検索しなければ見つからない問題である。そこでの重要な発見は、精度を制限している主な要因はモデルではなく検索器であるということだった。検証手法として、同一のGPT-4.1に対して2つの条件下で回答させた。自らBM25（キーワードの出現頻度に基づいて文書をスコアリングする従来の検索手法）を用いて資料を探索させた場合の正答率は14.6%にとどまったが、回答を含む文書を直接与えられた場合の正答率は93.5%に達した。モデルは同一であり、その差のほぼすべては適切な文書を見つけ出せたかどうかに起因している。

Nandanによる検索Agentの完全版セッションはMavenで公開されている。

埋め込みモデルの選定：ランキングだけを見るな、ファインチューニングが見落とされがち

埋め込みモデル（embedding model）は、RAGにおいてドキュメントのチャンクとクエリの双方をベクトルに変換する役割を担い、検索の適合率はこれに大きく依存する。モデル選定の際にはまずMTEBリーダーボードを参照しがちだが、そこで並んでいるのは品質のランキングであり、コスト面はほとんど反映されていない。

Radu Gheorgheは続いて検討に値するいくつかのトレードオフについて解説した。まず「精度」についてである。これはコンピュータが1つの数値を保持するのに何ビット（bit）を使用するかを指す。ビット数が少ないほど使用容量は小さく計算は高速になるが、3.14159を3.14と記録するように、数値の粒度は粗くなる。

• モデルの量子化（モデル自体の数値をどの程度の精度で保持するか。主に計算速度に影響）：CPU上では、INT8（8ビット）モデルはFP32（32ビット）モデルと比較して約3倍高速であり、品質はほぼ維持される。GPU上ではFP16に切り替える。
• ベクトルの精度（出力されるベクトルをどの程度の精度で保存するか。主にストレージに影響）：FP32からバイナリ（二値化）に変更すると、各数値が32ビットから0または1のみを保持する1ビットになり、ストレージは元の1/32に削減される。bfloat16（16ビット）に変更した場合、ストレージは半減し、測定可能な品質低下は見られない。
• Matryoshka（マトリョーシカ）枝刈りモデル：この種の入れ子構造モデルは、最も重要な情報がベクトルの前方の次元に集中するように訓練されている。そのため後方の次元を直接切り捨てることができ、品質を大半維持したまま、ストレージの節約と検索の高速化を両立できる。
• 自身のデータにおける性能：これはリーダーボードからは分からないため、必ず自前のデータで測定する必要がある。専門領域では順位が大幅に入れ替わることがある。一般的な弱点は多言語サポートとコンテキスト長である。

既存のモデルが対象領域に対して依然として不十分である場合、埋め込みモデルのファインチューニングは見落とされがちな有効策である。大規模モデルのファインチューニングよりもはるかに容易であり、得られる性能向上の幅も大きいことが多い。RaduはApache 2.0ライセンスのオープンソース・ノーコードファインチューニングツールVespaEmbedを開発した。Hugging Faceからベースモデルを選択し、テキストペアのデータをアップロードする。各ペアはクエリ（anchor）とそれによって見つけ出されるべきテキスト（positive）で構成される。例えばインターフェースのサンプルでは、anchorが「What is machine learning?」であり、positiveが機械学習を解説した文章となっている。あとは損失関数を選択して訓練をクリックするだけである。Hugging Face上で直接試用することも可能である。

Raduによる埋め込みモデル選定の完全版セッションはMavenで公開されており、埋め込みモデルの選定とファインチューニングに関する彼のスライドも閲覧できる。

OCRの選定：大半のチームはAPIを使うべき、モデルはPDFの落とし穴に合わせて選ぶ

モデルにPDFやスキャン文書を読み取らせるための第一歩は、OCRによってページ上のテキストと構造を認識することである。Joe Barrowは2つの問いから選定を行うデシジョンマトリクスを提示している：純粋なテキストブロックのみが必要か、それともドキュメントの完全な構造（見出し、表、セルの境界線）まで必要か？マネージドAPIを呼び出すか、それとも自前でモデルをデプロイするか？

これら2つの問いを掛け合わせると、4つの選択肢が得られる：

• 大手クラウドベンダーのAPI（AWS Textract、Google Cloud Vision）：テキストブロックのみを出力し、安価（1000ページあたり0.60–1.50ドル）で、ページ上の各単語の位置座標を出力できる。プロダクト内で元の文書上の該当箇所をハイライト表示したい場合に有用である。
• ドキュメント処理スタートアップのAPI（Reducto、Datalab、Extend）：完全な構造を出力し、機能が充実しているが高価（1000ページあたり5–20ドル）である。
• オープンソースのパイプライン（Tesseract、PaddleOCR）：テキストブロックのみを出力し、安価かつ高速だが、対応できる能力の範囲が狭い。
• オープンソースのビジョン言語モデル（LightOnOCR、Chandra、Docling）：完全な構造を出力し、実行にはGPUが必要だが、機能はほぼ網羅されている。

Joeの助言は、自前でデプロイすべきチームは約5%にすぎないということである。プロダクトの開発に注力しているのであれば、通常はAPIを利用する方が賢明である。

APIを利用する場合であっても、どのモデルを選択するかは極めて重要である。PDFはあらゆる予期せぬ方法で抽出処理を破綻させるからである。Joeは以下の落とし穴を指摘している：

• TeXでコンパイルされたPDFにはスペース文字が存在しない：TeX（論文などで広く使われる組版システム）は各グリフを指定された座標に配置して組版を行うため、ファイル内にはスペース文字が存在しない。単純な抽出ツールを使うと、スペースが一切ない連続した文字列として抽出されてしまう。
• 2段組みのページには読み上げ順序が存在しない：行単位で抽出するツールは段落を横断して読み取ってしまい、大規模モデルに渡されるのは順序がめちゃくちゃになったテキストになる。Textractのようなクラウドサービスでもこの誤りが発生する。
• 行ごとの出力は意味的な構造を喪失させる：見出し、表、セルの境界がすべて失われ、後続の検索において文脈が途切れてしまう。
• スキャンの品質が悪い場合、クラウドAPIは文字を捏造する：ノイズの多いスキャン画像に対してTextractが数百個の「the」を返した事例が確認されている。
• 空白ページによってビジョン言語モデル（画像とテキストを同時に処理できるモデル）が定型文を捏造する：真っ白なページに対してヘッダーなどの文字を出力してしまうことがある。
• ビジョン言語モデルが出力するMarkdownには単語レベルの位置座標がない：元のPDF上で引用元のテキストをハイライト表示したいプロダクトの場合、出力されたMarkdownのみでは各単語の位置座標が含まれていないため実現できない場合がある。
• モデルのライセンスに注意する：ChandraおよびSuryaは、年間売上が200万ドル未満であり、かつDatalabと競合しない組織にのみ無償で提供されている。この範囲を超える企業は別途商用ライセンスを取得する必要がある。GLM-OCR自体はMITライセンスだが、ApacheライセンスのPaddleレイアウトモデルを内部で利用しているため、双方のライセンスを遵守しなければならない。

PDFがどれほど厄介になり得るかを確認したい場合は、大半の抽出ツールを破綻させるファイルを収集したWTF PDFを参照するとよい。Joeが提案する選定プロセスは非常に簡潔である：まず上述の2つの問いに答える。次に代表的なページを50〜100ページ抽出する。各候補モデルに同一のページ群を処理させる。そして総合スコアだけを見るのではなく、生の出力を直接確認してそれぞれの失敗の仕方を比較した上で決定を下す。TeXのスペース欠落や2段組みの読み乱れといった問題は、総合スコアの数値だけを見ていても見抜くことができない。

セッションの全編はJoeによるOCR選定の録画を、オープンソースOCRモデルに関する彼の調査記事も一読に値する。

Subtext：Agentのための脚注、書き直し時に重要な決定事項を落とさない

Agentにドキュメントの要約、推敲、リライトを行わせると、文を結合したり、削除したり、言い回しを変更したりする。原文の1文の背後にある前提や制約条件（例えば「ここでの『次のラウンド』とはどのラウンドを指すのか」「この決定にはどのような条件が付随しているのか」など）が文中に明記されていない場合、書き直しによってそれらの情報が失われてしまう危険がある。

Bryan BischofとAdam ConwayはTheory VenturesのAIエンジニアである。このベンチャーキャピタルの投資家たちは詳細な投資メモを作成しており、その1通1通に重要な決定が含まれているため、Agentにリライトさせるとそれらの決定が欠落するリスクを抱えていた。彼らの解決策がSubtextである。これは各文にメタデータを付与する軽量なフォーマットである。文の原文には手を加えず、執筆者による補足説明や未解決の疑問点をメタデータとして保持する。フォーマットには自己記述型のJSON（contextdoc/columnar-v1）が用いられる。これは実質的にAgent向けに書かれた脚注であり、Agentがリライトする際に元の材料から逸脱しないように機能する。

例示（Theory Venturesの実際の内容ではない架空の例）：メモの中に「ACME社への追加投資は一時保留することを推奨する」という一文があるとする。この文に付与される補足説明は次のようなものになる：「ACME社とは、我々がシリーズAで投資した物流ソフトウェア企業を指し、同名の上場企業ではない」「一時保留とは、来四半期の契約更新データが出るまで決定を待つという意味であり、投資の見送りを意味するものではない」。Agentはリライト時にこれらの説明を読み取ることができるため、どの制約を維持すべきかを正しく把握できる。

リポジトリには2つのスキルが含まれている：

• subtext-annotate：元のテキスト（メール、メモ、Markdown）をsubtextドキュメントに変換し、初見の読者の視点から執筆者に対して質問を投げかけ（説明のない略語、不明瞭な指示語、曖昧な日付、背景の不足など）、執筆者の回答を該当する文に紐付ける。
• subtext-read：.subtext.json ファイルを読み込み、理解が難しい箇所に説明を埋め込んで表示し、執筆者が回答できなかった質問を一覧化する。

人間にとってもメリットがある。Adamはチャット画面のプロトタイプを実演した。各メッセージの横に、送信者に紐づくチケットや通話記録が直接表示され、読み手がわざわざ背景情報を探し回る必要がなくなっている。

BryanとAdamによるSubtextの完全版セッションはMavenで公開されており、スライドおよびコードリポジトリも公開されている。

システム：速度、コスト、実行環境

評価と検索が整った後に取り組むべきは、エンジニアリングレイヤーの課題である。応答が遅い問題、自前でモデルをデプロイする際のVRAMとコストの計算方法、そしてAgentに自律的にコードを実行させる際の事故防止策である。

推論レイテンシ：入力の読み込みが遅いのか、出力の書き出しが遅いのかをまず切り分ける

応答が遅い場合、入力の読み込みが遅いのか、それとも出力の書き出しが遅いのかをまず切り分ける必要がある。この2つの状況では解決策が根本から異なる。

Abi Aryanのセッションでは、1回の推論を2つのフェーズに分解している：

• プリフィル（prefill）：モデルが入力のすべてを読み込むフェーズ。試験問題を解く前にまず問題文を読むことに例えられる。入力テキスト全体をGPUに一度に投入して並列計算できるため、1秒あたりに処理できるtoken数は非常に多くなる。
• デコード（decode）：モデルが出力tokenを1つずつ順次生成していくフェーズ。答えを1文字ずつ書いていくようなものである。モデルは1つのtokenを生成するたびに、それを直前までのテキストの後ろに連結し、次のtokenを計算しなければならないため、並列化が不可能である。そのため、1tokenあたりの処理速度で見ると、プリフィルよりも一桁遅くなる。Abiはセッションの中で、デコードの速度は主に計算能力ではなくメモリ帯域によって制限されていると指摘している。1つのtokenを生成するたびに、GPUはモデル全体の重みと過去のコンテキストのKV cacheをVRAMから読み出す必要がある。このステップで実際に実行される計算量は非常に小さいため、ボトルネックはVRAMからデータを転送する速度にあり、GPUの計算能力の大半は遊休状態になってしまう。

彼女のColabノートブックでは、同一のモデルに3つの形状のリクエストを処理させている。実測にはTinyLlama-1.1B-Chat-v1.0（約11億パラメータの小規模モデル）を使用し、1枚のTesla T4グラフィックボード（VRAM約15.6 GB）上で動作させている。より大規模なモデルや高速なグラフィックボードに変更すれば絶対的な所要時間は変わるが、注目すべきは各フェーズが占める割合の傾向である。以下はノートブックのある実行における数値である：

長い入力・短い出力（RAG、分類、情報抽出）：最も扱いやすい形状である。入力は長いものの、プリフィルは並列化できるため極めて迅速に読み終える。実測では入力1205 token、出力25 tokenで合計1087.5ミリ秒であった：プリフィルに386.4ミリ秒（毎秒約3119 token）、デコードに701.1ミリ秒（毎秒約36 token）。

短い入力・長い出力（Agentの実行トレース、コード生成、長文執筆）：最も効率の悪い形状であり、レイテンシのほぼすべてが1つずつの出力生成に費やされる。実測では入力37 token、出力256 tokenで合計7952.4ミリ秒であり、そのうちデコードだけで7918.8ミリ秒（毎秒約32 token）を占めた。

短い入力・短い出力（チャットの1ターン、単発のQA）：実測では入力25 token、出力32 tokenで合計944ミリ秒であり、そのうちデコードが903.5ミリ秒を占めた。さらに25 tokenでは少なすぎて、大量のデータを同時計算することを得意とするGPUを満杯にできず、プリフィルフェーズでGPUの大半の時間がアイドル状態になってしまう。vLLMのような推論エンジンは、連続バッチ処理（continuous batching）を用いて多数のユーザーの小さなリクエストを同一の計算にまとめ上げ、GPUを遊ばせないようにしている。

Abiのアドバイス：主に出力に時間がかかっている場合は、まず回答を短縮すること。その上で投機的デコード（speculative decoding：小型モデルで後続の数tokenをあらかじめ予測し、大型モデルで一括検証して正しければ採用する手法）を検討するか、より小さなモデルへの変更、あるいはより高性能なハードウェアへの換装を検討する。主にプリフィルに時間がかかっている場合は、リクエストをバッチ処理し、コンテキスト長を短縮する。

このノートブックは実践的な検証に適しており、試す価値のある3つの実験がある：

• バッチサイズ：同じリクエスト形状でバッチサイズ4と8を実行し、リクエストごとのスループットがどのように向上するか、VRAMのどこで頭打ちになるかを観察する。
• 推論エンジン：Hugging Faceのpipelineからllama.cppまたはvLLMに切り替える。これはデコード速度に最も大きな影響を与える。
• 量子化：INT8またはINT4モデルに変更し、重みが占めるVRAMが縮小する一方で、スループットが通常向上することを確認する。

Abiによる推論レイテンシの完全版セッションはYouTubeで視聴可能である。

オープンソースモデルの経済学：VRAMを見積もる計算式とデプロイ時の留意点

Zach Muellerはいくつかのオープンソースモデルファミリーを整理し、自身が日常的に使用している所感を共有した：

• Qwen：27BのDenseモデルは、彼が日常的なアシスタント型Agentを構築する際の第一候補である。これはコード生成ではなく、個人アシスタント的なタスク（メールの確認、ウェブサイトの調査、APIの呼び出し）を指す。彼自身のバックグラウンドAgentはこのモデル上で数ヶ月間稼働している。
• GLM 5.2：彼がコードを書く際の主力モデルであり、挙動が安定しており、注意が散漫になりにくく、細かいミスも犯さない。
• DeepSeek V4 Flash：Claude Haikuの直接の代替となり得る。
• Kimi：彼が文章を書く際に最も好んで使用しているが、全精度でのデプロイには8枚のB200を搭載したマシンが必要であり、自前で運用するのは極めて困難である。

モデルを選定する前に、手元のハードウェアに収まるかどうかをまず見積もる必要がある。パラメータ数とはモデル内に保持されている数値の総数であり、27Bとは270億個を意味する。重みが占めるVRAMを見積もる計算式は次の通りである：

重みサイズ（GB）≈ パラメータ数（B、10億）× N × 0.5

この計算式の根拠は次の通りである：16-bit精度では各パラメータが2バイトを消費するため、10億個のパラメータは約2 GBとなる。式の中の N × 0.5 は、各精度において1パラメータあたり何バイトを占めるかに正確に対応している：

• 4-bit精度：N = 1（1パラメータあたり0.5バイト相当）
• 8-bit精度：N = 2（1パラメータあたり1バイト相当）
• 16-bit精度：N = 4（1パラメータあたり2バイト相当）
• 32-bit精度：N = 8（1パラメータあたり4バイト相当）

VRAMは重みが入るだけで足りるわけではない。モデルは生成を行いながら、新しいtokenを生成するたびに過去の文脈を再計算しなくて済むよう、各tokenの中間結果をVRAMに保持しておく必要がある。この部分はKV cacheと呼ばれ、コンテキストが長くなるほど消費量が増加する。さらに計算処理中のアクティベーション値（中間活性化データ）も領域を消費する。例えば27Bモデルを4-bitで使用する場合、重みは約 27 × 1 × 0.5 = 13.5 GB となり、KV cacheとアクティベーション用の領域を確保した上で、16 GBのグラフィックボード1枚に収めることができる。厳密な計算方法については、EleutherAIのtransformer mathに関する記事を参照されたい。

Zachはさらにいくつかの注意事項を挙げている：

• プライベートなコードをOpenRouterのようなサードパーティのルーティングサービスに送信してはならない。ルーティングサービスはリクエストを異なるモデルプロバイダーに転送するため、データプライバシーの取り扱い基準がまちまちなプロバイダーにリクエストが届いてしまう可能性がある。
• セッションの途中でプロバイダーを切り替えてしまうルーティングには注意が必要である。多くのプロバイダーはすでに送信された長いプレフィックス（長大なシステムプロンプトなど）をキャッシュしており、次回以降のリクエストが高速かつ安価になる。途中でプロバイダーが切り替わると、そのキャッシュが無駄になる可能性がある。ルーティングを利用する場合は、推測に頼らず、レイテンシとコストへの影響を評価によって実測すべきである。
• GPUをレンタルする際、彼は複数台のH100クラスタを借りるよりも、最高スペックの単一マシンを1台借りる方を好む。H100は10%〜20%安い程度にすぎず、複数台構成でデプロイするとモデルが複数マシン間でデータを頻繁にやり取りすることになり、マシン間の接続帯域がボトルネックになってしまうためである。

Zachによるオープンソースモデル経済学の完全版セッションはYouTubeで視聴可能である。

Agentへのサンドボックス導入：隔離、高速起動、Agentとツールの分離

Adam Azzamが語ったのは、なぜAgentにサンドボックスを用意する必要があるのかについてである。自身のPC上でコーディングAgentを単独で動かしているだけなら、サンドボックスの必要性をあまり感じないかもしれない。しかしコードの作成速度が上がり、多数のAgentを同時に走らせたり、他者との共同作業を始めたりすると不可欠になる。サンドボックスとは、隔離され、使い終わったら破棄できる一時的な実行環境である。Agentのコード内で問題が発生しても、影響範囲はそのサンドボックス内だけに限定される。

多くの人が最初に思い浮かべるのは既存のCI/CD（コードコミット後にビルドやテストを自動実行するパイプライン）だが、これは適していない。CI/CDは起動が遅く、生存期間が短い。一方Agentは1つのタスクに対して数時間から数日連続して稼働することがあり、自身の実行環境内の依存関係を変更することもある。さらに、Agentが書いたコードは誰もレビューしていないため、1つの不正な変更によってマシンがクラッシュしたり、環境内の認証情報が漏洩したりするリスクがある。

Agentの数が増えると、起動の遅さがボトルネックになる。Rampのアプローチは、30分ごとにマシンイメージ（OSと必要なツールをすべてインストールしたテンプレート）をリビルドしておくことである。Agentの起動時にはあらかじめ準備されたマシンを直接割り当て、git pull を実行して最新コードを取得するだけで、1秒未満で作業を開始できる。

もう1つの設計原則は、Agentとそれが呼び出すツールを分離することである。ツールがクラッシュしてもAgentまで道連れに倒れてはならない。例えば、あるツールが巨大なCSVファイルを読み込もうとしてメモリ不足でクラッシュしたとしても、すでに長時間稼働しているAgentのタスク全体を巻き込むべきではない。Adamが描いた概念図では、Agentはコントロールプレーン（意思決定とスケジューリングを担う側）に、ツールはデータプレーン（実際の実行を担う側）に配置され、その間はネットワークによって隔てられている。

Adamは現在Modalに所属している。Modal上のコードはリモートで実行されるが、ローカルで動いているかのように高速である。Modal上でサンドボックスを作成するhello worldのサンプルコードは以下の通りである。詳細な使い方はModalサンドボックスガイドを参照されたい：

import modal

app = modal.App.lookup("sandbox-hello-world", create_if_missing=True)
sb = modal.Sandbox.create(app=app)
process = sb.exec("echo", "hello")
print(process.stdout.read())
sb.terminate()

AdamによるAgentサンドボックスの完全版セッションはMavenで公開されている。

事後訓練：最後のステップ、まずは評価と環境を点検せよ

評価スコアが伸び悩んでいる時、多くの人が最初に思い浮かべるのはデータの収集とモデルの訓練である。事後訓練とは、既存のモデルをベースに、自前のデータを用いて追加の訓練（教師ありファインチューニングや強化学習など）を行い、モデル自体のパラメータを直接変更することを指す。

Prime IntellectのWill BrownとFlorian Brandは警鐘を鳴らす：評価スコアを上げたい場合、ファインチューニングは最後に用いるべき手段である。なぜなら多くの場合、モデルを変更しなくてもスコアを引き上げることができるからである。彼らはまず以下の3つのステップを順に行うことを推奨している：

1. 実行ログを読み、具体的にどこで失敗しているのかを突き止める。
2. 評価自体と実行環境を修正する。
3. 検索、コンテキスト、ハーネスを改善する。

2番目の項目は意外に思えるかもしれないが、評価環境における小さな問題が大きな影響を及ぼすことがある。一部のベンチマークでは、モデルが無制限に実行し続けるのを防ぐために非常に厳しいタイムアウトが設定されている。このような場合、ハードウェアを強化したりデプロイを高速化したりして、モデルがタイムアウト前に実行できるステップ数を増やすだけで、スコアが向上することがある。彼らが挙げた例では、Terminal-Bench 2においてタスクのタイムアウトを5倍に設定したところ、次のような結果となった：

• GPT-5.2 high：52.8% → 60.67%（7.87ポイント上昇）
• GPT-5.2 xhigh：46.3% → 60.97%（14.67ポイント上昇）

モデルは同一であり、評価環境内の設定を1つ変更したにすぎない。緩和前はhighがxhighを6.5ポイント上回っていたが、緩和後はxhighの方がわずかに高くなった。元のスコアだけを見ていれば、全く逆の結論を導き出してしまうところだった。

彼らはまた、評価環境を構築する際によくある落とし穴を挙げている：

• モデルの訓練時には温度1でサンプリングされていたにもかかわらず、評価時に強制的に温度0に設定されている。温度はモデル出力のランダム性を制御する。0に設定すると常に最も確率の高いtokenが選ばれ、1に設定するとモデルが算出した確率に基づいてサンプリングされる。強制的に0に変更すると、ベンチマーク結果の再現性に影響を与える可能性がある。
• 最大token数や最大ターン数の上限が低すぎ、モデルの推論が完了する前に打ち切られてしまう。
• Agentサンドボックスに割り当てるCPUやメモリが不足している。
• ハーネスが肥大化しすぎている：過剰にカスタマイズされたツール群を用意するのではなく、モデルが直接bashコマンドを実行できる極めてシンプルなハーネスに切り替える。
• モデルが特定のタスクをこなせないと判断する前に、そのタスクに特化したスキル（skills）をコンテキストに含めて試してみる。

以下の2つの条件が同時に満たされた場合にのみ、事後訓練に取り組む価値がある：

1. 正解が自動的に検証可能であること。例えばテストやプログラムによって正誤を直接判定できることである。訓練時においてモデルは膨大な試行を行うため、その都度自動で正誤が判定できなければ、モデルにどの方向へ更新すべきかを伝えるシグナルが得られない。
2. 現在の評価におけるモデルのスコアが0より大きく100未満であること。スコアが0点ということはモデルが一度も成功していないことを意味し、訓練時に強化すべき成功例が存在しない。100点であれば、もはや改善の余地がない。

実際に試してみたい場合は、Prime Intellectのverifiersライブラリを用いてPythonでタスクと報酬を定義できる。彼らのマネージド強化学習サービスを利用すれば、簡潔な設定ファイルを1つ用意するだけで訓練を実行でき、既存の環境を使ってすぐに開始することも可能である。

WillとFlorianによる事後訓練の完全版セッションはMavenで公開されている。