最近、私はブログ記事を推敲するのを手伝ってほしいとAIに頼んだ。
それは素早く書いた。構成は整っており、アイデアも明確だった。もっとプロフェッショナルな響きにしたいと伝えると、技術的な議論を加えた。学術的な裏付けを求めると、最近の論文を見つけてきた。
記事はより重厚になったが、私はためらい始めた。本当にこのように書く必要があったのだろうか？
内容に明らかな誤りはなかった。しかし私が書きたかったのは、自分の声で書かれた文章であり、読者に私が問題をどう考え抜いたかを伝えるものだった。何度かの改訂を経て、それは徐々に、私自身が消化するのに時間を要する研究レビューへと変わっていった。
途中で私の期待も変わっていった。当初は、この特定の記事にとって「プロフェッショナル」や「深みがある」とはどういうことかを十分に詰め切れていなかった。
その経験から、優れたエージェントとは何かについて考え直すことになった。
要件を一つずつ確認すれば、私たちのコラボレーションはかなりのことを成し遂げていた。記事は書かれ、調査も行われ、参考文献も揃っていた。個々の依頼には、それぞれ対応する成果物があった。
しかしそれらをまとめてみると、やはり問わざるを得なかった。これは私が公開したい記事なのだろうか？
エージェントが何をしたかを確認するのは容易だ。その行動がユーザーを目標に近づけたかどうかを説明するには、より多くの手間がかかる。
この場合、「学術的な裏付けを加える」は明示的な依頼だった。その目的は、論拠をより説得力のあるものにすることだった。研究を加えることで記事が本来の声を失うなら、その資料をどう使うかを考え直す必要があった。
ユーザーの新たな依頼は、必ずしも単に上乗せすればよいものではない。方向の修正であることもあれば、すでに完了した作業を削除する理由になることさえある。
タスクに継続的に関わるエージェントにとって、こうした変化を理解することは、コラボレーション全体の質に影響する。フィードバックが入るたびにタスクの理解を修正すべきであり、成果にひたすら付け足し続けるべきではない。
これは「完了」という概念もより複雑にする。記事には結末があり、タスクは完了と記されていても、ユーザーはまだ使えるものを手にしていないかもしれない。
だから評価を設計する前に、別のことを明確にしたい。私たちは結果からどのような判断を下そうとしているのか、ということだ。
事実の正確さを確認するとは、引用や裏付けとなる証拠を検証することだ。改訂能力を評価するとは、エージェントがフィードバックを理解し、依然として機能する内容を保持できるかを観察することだ。タスクを最初から最後まで遂行できるかを判断するとは、ユーザーにどれだけの作業を残すかを見ることでもある。
これらの問いは関連しているが、「全体の品質が良い」というだけでは、それらすべてに答えることはほとんどできない。
何を評価しているのかが明確になって初めて、どのような証拠を集めるべきか、そしてスコアがどれだけのことを教えてくれるのかが分かる。
評価はまた、その時点の状況に対して公正である必要がある。
この執筆過程では、いくつかの目標は議論を通じて初めて明確になった。初期の応答は、後から生じた好みではなく、すでに表明されていたニーズに照らして判断されるべきだ。
要件がすでに明確だったのに結果が依然として不適切だったなら、問題をより正確に特定する必要がある。エージェントが誤解したのか？以前の制約を忘れたのか？それとも新たな依頼を満たすことで、すでに機能していたものを台無しにしたのか？
これらはすべて「文章が下手」と表現されるかもしれないが、求められる改善は大きく異なる。タスク情報を増やすこと、コンテキストを調整すること、実行へのアプローチを変えることが、それぞれ役立つかもしれない。しかしまず、どこで物事がうまくいかなかったのかを知る必要がある。
その他の要件は個人の好みによって変わるべきではない。引用が実在するか、事実が正確か、結論が裏付けられているかは、独立して確認されなければならない。ユーザーが結果を気に入っているだけでは、これらの要件が満たされたことを立証するには不十分だ。
この区別は重要だと思う。これにより評価は、特定のニーズを考慮しつつ、必要な判断基準を保つことができる。
目標が明確で、エージェントが今回それを正しく達成したとしても、なお観察すべきことはある。
同じタスクを二度目もうまくこなせるか？ユーザーが依頼の言い方を変えたら、意図を読み違えるか？情報が欠けているとき、流暢な文章で穴を埋めるのではなく、不確実性を認めることができるか？
エージェントの信頼性に関するある研究では、一貫性、堅牢性、予測可能性、安全性をそれぞれ別々に検討した。それがテストしたモデルとベンチマーク全体で、能力の向上は信頼性の限定的な改善しかもたらさなかった。これは、エージェントが何を成し遂げられるかを学んだ後でも、どのような条件下でそれに頼れるのかを理解する必要がある、ということを思い起こさせる。関連研究
では、優れたエージェントを定義するのは誰か？
私は、ユーザーの実際の目的が出発点であるべきだと考える。プロダクトチームは、どのニーズに応えるつもりか、どれだけの責任を負うのかを明確にする必要がある。エンジニアリングは、実装とシステム能力の限界を理解する必要がある。評価は、そうした期待を具体的な状況に落とし込み、結果がそれを裏付けるかどうかを試す。
最終的なトレードオフに対して誰かが責任を負う必要があり、それを議論するための証拠も必要だ。
何かを「よりプロフェッショナルに」するという依頼を考えてみよう。ある人は用語や参考文献を思い浮かべる。別の人はより厳密な推論を思い浮かべる。さらに別の人は、著者が問題の核心を突き止めることを期待する。その依頼を実際の記事に当てはめてみると、私たちが皆同じことを話しているわけではないことが見えやすくなる。
私はこうした事例を通じて合意を築いていきたい。どの事実が正確でなければならないか？どの部分が結果の使えるかどうかに影響するか？どこに異なる選択の余地があるか？これらはすべて議論できる。基準が具体的であるほど、後で意見の相違を説明できる可能性が高まる。
その基準は改訂にも開かれているべきだ。新しい状況が、考慮していなかった問題を明らかにすることもあれば、ユーザーが異なるものを求め始めることもある。重要なのは、なぜ調整を行ったのかを記録し、チームがプロダクトの改善と、それがどう判断されるかの変化とを区別できるようにすることだ。
評価の価値は、その後の私たちの選択にも表れなければならない。
評価によって、何を優先すべきかがより明確になり、ある改善に投資する価値がある理由を説明でき、証拠が不十分なときにどのような追加テストが必要かを認識できるなら、そのスコアには実用的な価値がある。
振り返ると、AIは確かに記事をより完全なものにする手助けをしてくれた。何を残し何を削れるかを私たちが突き止められたのは、その後の何度もの議論のおかげだった。
これこそ、評価がチームの助けとなることを私が望むことでもある。結果がすでに良く見えるときでも、それをユーザーの手に渡せる状態かどうか、そしてなぜその判断に自信を持てるのかを判断する手段を、なお持てるようにすることだ。