評価が大事

評価が大事

目次 1. Speeda Agent チームでやっていたこと 2. 学び① 評価が大事 3. 学び② 正解データが大事

Speeda Agent チームでやっていたこと

学び① 評価が大事 GitHub Copilotは、間違いなく LLMを使った最初の産業規模のアプリケーションで す。先手を打つことの呪いは、（今では）誰もが知っていることを笑えるほどに無視 してしまい、後から考えると、自分が下した選択の一部が愚かに見えてしまうことで す。 しかし、私たちが絶対的に正しかったことの 1つは、どのように始めたか でした。 GitHub Copilotのコードベースの最も古い部分は、プロキシやプロンプト、 UI、アプ リケーションを IDE拡張機能として設定するボイラープレートではありません。 私た ちが最初に書いたコードは「評価」 であり、そのおかげで、他のコードとともに非常 に早く、成功裏に進むことができました。 なぜなら、私たちが行ったすべての変更について、その変更が正しい方向への一 歩、間違い、あるいは、あまり影響を与えなかった、よい試みだったのかを直接確 認できたからです。

Agent 開発初期の状況 ● テスト書いてない ● 確認コストが大きい ● リグレッションに気付けない ● 安心感がない（個人的に）

LLM を使ったアプリケーションのテスト ● LLM の出力は確率 ● 評価項目の例 ○ 構造の正しさ、ソースとの整合性、意味的な一致 （E2Eテスト, ユニットテスト的なものを作っていきたい）

評価手法 ● オフライン評価（デプロイ前） ○ 人間による評価 ○ 自動評価 ■ ROUGE, BERTScore, LLM-as-a-Judgeなど ● オンライン評価（デプロイ後） ○ ABテスト、Good/Bad など

評価を始めてどうだったか ● ROUGE, BERTScore, LLM-as-a-Judge ● まず始めるのが大事 ● 確認コスト減った ● 安心感があった（個人的に） ● とはいえ、課題はたくさんある

学び② 正解データが大事 ● 正解データがないと評価できない（当たり前） ● ゴールデンデータセットを用意せよ ○ プロンプトとそれに対応する正解回答

道のり ● 正解データを作る ↓ ● 正解データに出力を近づける ↓ ● 出力を安定させる

正解データを作ることを後手に回さない ● 正解データは動く前提で、意識的に作りにいく ● 作って貰える状況なら、早めに依頼する ● 無理なら、Biz側も巻き込んで早めに一緒に作る？