benchmarkでは優秀でも、会話ではモデルが迷子になる

Microsoft ResearchのJennifer Nevilleは、一般的なAI benchmarkが作業を完璧に記述された1回の指示へ単純化していると指摘する。実際の会話では要件が少しずつ追加され、彼女たちの研究ではモデル性能が大きく低下した。

Microsoftは変化していく会話の中でモデルを試す

NevilleはMicrosoft ResearchのAI Interaction and Learningチームを率いる。Podcastで語った目標は、現実的な作業環境におけるAIの性能限界とユーザー体験を調べ、見つかった穴からアルゴリズムやモデルを改善することだ。彼女は130本を超える論文を発表し、引用数は1万件を超える。この議論はchatbotを触った印象ではなく、構造化データとinteractionに関する長年の研究に基づいている。

チームはmultiturn interaction、共同作業、長期タスクを重視する。ある研究では公開single-turn benchmarkの完全な指示を複数ターンに分け、模擬ユーザーが条件や補足を少しずつ加えた。Nevilleによれば、現在のモデルは完全な指示を1回で受け取った場合より、この条件で性能が大きく下がった。

これは人の普通の行動に近い。利用者は最初から完全な仕様を知っているとは限らず、作業しながら見つけていく。完成したpromptを使うbenchmarkは、整えられた問題を解く能力を測る。製品は仕様が生まれる過程そのものにも耐えなければならない。

evalsは研究室の都合ではなく仕事を再現すべきだ

製品チームへの示唆は具体的だ。静的benchmarkの好成績だけでは、複数の手順を通して意図を保ち、修正を受け入れ、文書を共同編集するagentの力は分からない。Evaluationには、不完全な指示、変化する目標、長いcontextを含む実際のworkflowが必要になる。

Nevilleは企業研究所の利点も説明する。Microsoftは製品チームと協力し、大規模な消費者ログから成功と失敗のパターンを分析できる。そこから実際の問題を狙ったテストを作れる。学習データに答えが含まれているかもしれない問題集を増やすより有用だ。

影響はUXにも及ぶ。長い会話でモデルが迷う間は、確認済みの要件を要約し、計画の変更を示し、完全な仕様で再開できるUIが要る。Nevilleも現在使える方法として、会話が何ターンも続いて混乱したら、そこで得た知識をまとめて新しく始めるよう勧めている。

模擬ユーザーは本物の同僚ではない

Single-turn benchmarkを複数ターンへ分ければ重要な変数を切り出せるが、それでもsimulationだ。実際の人は考えを変え、情報を省き、社内用語を使い、仕事への結果で出力を評価する。テストはcontext喪失を示せても、優れた共同作業まで証明できない。

ユーザーログの分析にも、privacy、代表性、成功の定義という問題がある。Product telemetryは頻発する失敗を示せるが、利用者がなぜ中断し、手作業で直し、二度と戻らなかったのかは、定性的な調査なしでは説明できない。

製品evalsは成果までの全行程を測る必要がある

進歩を示すのは、複数回の確認、文書作業、失敗からの回復、最後に人が得た利益まで含むbenchmarkだ。公開された手順、比較可能なモデル、単一の総合点ではなくタスク別の結果も欠かせない。

AIを導入するチームには、vendor benchmarkと並んで実際の作業履歴から作る独自evalが必要であり、予想外の失敗を定期的に検討すべきだ。本番環境でモデルが出会うのは、整った試験問題ではない。会話しながら必要なものを見つけている人間である。

Lilithの判定

benchmarkは完成した台本をモデルに渡す。本番では4ターン目に考えを変える同僚が現れ、その瞬間にモデルの実力が見える。