AIのAIによるAIのための出力評価と改善

AIのAIによるAIのための出力評価と改善 AIの出力の質をあげる！チームの集合知を注入する方法

自己紹介 @_chocoyama（たまねぎ）株式会社LayerX バクラク申請・経費精算チーム Flutterでモバイルアプリ作ってますよく使っているAI Coding Tools Claude Code,
Cursor 最近の悩み老眼、鼻炎、知覚過敏と顔面周りのおぢ化が急速に進んでいる © LayerX Inc. 2

「AIの出力の質をあげる！」そもそも「質が上がった」ということをどう判断していますか？

AIの出力の質が上がったかどうか © LayerX Inc. 「ルールを追加したら、なんかいい感じに動いてそう」「とりあえずルール見てくれてはいるから、なんかいい感じにやってくれてそう」 4

AIの出力の質が上がったかどうか →「なんかいい感じになってる」を脱しきれないもう少し主観的ではない形で評価したい！ ※ 今日話す内容　x 完璧にうまくいっている　o 試行錯誤しながら前に進んでいる ©
LayerX Inc. 「ルールを追加したら、なんかいい感じに動いてそう」「とりあえずルール見てくれてはいるから、なんかいい感じにやってくれてそう」 5

弊チームのAI Codingの状況 © LayerX Inc. 1月ごろからCursor活用開始ちょうどmdcファイルが使えるようになったぐらいのタイミング元々活用していたTechDocumentsをそのままルールとしてimport なんとなくプロジェクトの文脈を理解してくれそう！という状態になる一定レベルを超えない感覚があり、DesignDocやADRを一通りimportしてみるが、まぁまぁ...という感じ
Specっぽいのを入れてみたりしてみるが、良い感じにはならず... 6

改善したい！ Tryしてみた

なんとなくの対策1：プロンプトの改善 © LayerX Inc. ルールの改善ではないため、根本的な基盤に対しては何も変化がない個々の実装者のプロンプト力にも依存しており、再現性がない 8

なんとなくの対策2：ルールの追加や改善 © LayerX Inc. 足りてなさそうなルールの追加ちゃんとワークしているのかよくわからない「追加したルール見てくれてるから多分良さそう」から脱しきれないルール設定のベストプラクティスへの準拠やAIによるルール改善を試す対応内容によっては、明らかにアウトプット品質が低下低下しなかったとしても、何が変わったのかイマイチわからない
9

なんとなくの対策3：AI Coding Agentの変更 © LayerX Inc. 「Claude Code使ってるとルールそんなに整備しなくてもいい感じだよ」ルールの呪縛から逃れられるのであれば、それが一番楽 Cursor,
Cline, Roo Code → Claude Codeに切り替え確かに良くなった感じがするが、うまくいかないこともまだまだ多い Flutter/Dartは弱い？プロジェクトが複雑すぎる？ 10

そもそもルールがワークしてるか　　　把握できていない

何か対応を入れようとしてみても... その対応を入れたことで、どういった変化が出るかがいまいち見えない変わらないならまだしも、出力を悪化させるのは避けたい気持ちも生まれる積極的にルールいじる動きになれない © LayerX Inc. 12

計測してみよう

どう計測するか LLMのアウトプットってシステマチックに評価できるもの...？ © LayerX Inc. x「モデルの性能」自体を評価するような計測 o 実ユースケースに近い、アウトプットされたコードを評価するような計測実行のたびに大きく結果が変わる結果はテキストデータになるため、評価はある程度定性的に判断するしかない
14

世のプロダクトはどうやって評価している？ © LayerX Inc. LangSmith がそれに近いアプローチをしている ※ LangSmith: LLMアプリケーションを構築するためのプラットフォーム以下の組み合わせを構成し、LLMのアウトプットを評価
Datasets：評価対象となるもの（何を検証するか） Evaluators：出力を評価する関数（どう採点するか） Human：人が採点 Heuristic：ルールベースで採点 LLM-as-judge：LLMが採点 Pairwise：バージョンを比較して判定 15

エージェントに対する評価の方法 © LayerX Inc. Final Response：最終的なレスポンスだけを評価するブラックボックス的にテキストレスポンスを評価することになるので、LLM-as-judge Evaluatorが効果的「時間がかかる」「内部の動作を評価していない」
「評価指標の定義が難しい」という欠点がある Single Step：エージェントのステップを単独で評価する高速で実行でき、アプリケーションの失敗箇所を特定しやすい「エージェントの全体像が把握できない」「後半ステップのデータセット作成が困難」という欠点がある Trajectory：期待された経路をたどったかどうかを評価するエージェントが取った全てのステップを評価するアプローチ複数の正しいパスがある場合に評価しづらい 16

今回試した組み合わせ → これを動かすための仕組みを用意した © LayerX Inc. 評価方法：Final Response Datasets：実装コード Evaluators：LLMが主体となり、人が最終チェック
17

構成 © LayerX Inc. Datasets Creator：Datasetsを生成する Evaluator：生成されたDatasetsを評価する 18

構成 © LayerX Inc. 簡単にするために、Datasets CreatorとEvaluatorをプロンプト化このプロンプトを渡して、Agentに作業を委譲 19

構成 © LayerX Inc. 毎回プロンプト作るのも面倒→プロンプト生成作業もAgentに委譲「プロンプト生成プロンプト」を用意「担保したいこと」からDatasets CreatorとEvaluatorを自動生成 20

動作イメージ Claude CodeのCustom Slash Commandでプロンプト生成用プロンプトを実行 /create-benchmark で起動 © LayerX
Inc. 21

Datasets Creator 検証対象となるDatasets （実装コード）を生成するためのタスクを定義したファイル AIにはこれをプロンプトとして渡して、Datasetsを生成してもらう ©
LayerX Inc. 22

評価の実行 Datasets Creatorと Evaluatorの内容に問題がないことを確認 /benchmark で起動 LLMのアウトプットは一定にはならない複数回並列実行して総合的に判
断（Claude CodeのTaskツールで実現） © LayerX Inc. 24

できるようになったこと © LayerX Inc. 「なんかよさそう」「なんかイマイチ」という状態を客観的に評価できるようになった変更前後の差分を見ることで、対応内容に価値があるかを判断しやすくなった（今後）モデルを変えるだけで、どういった変化が現れるか検証しやすくなった 26

実際に改善できたこと

課題 © LayerX Inc. 実行時間が長いコスト面を考えるとCIに載せられない try & errorも時間がないとできない（git worktreeなど活用して裏で回しておくことはできるが...）
これを実行する習慣は中々つかない今回実験的にやってみているが、普段積極的にやるかと言うとやらない気がする... ここまで仕組み化はせず、プロジェクトで何個か挙動を確認するためのスニペットを持っておくぐらいでも十分かもあくまでベンチマーク実際の実装時に100%期待結果が出るとは限らないある程度、個々のプロンプトにも左右される（が、近い将来"プロンプト力"のようなものは重要じゃなくなってくるかもしれない） 32

今後、より意味のあるものにするには継続的に色々試していくぞ！ © LayerX Inc. ベンチマークの作成と起動をオートにする「うまくいかなかったこと」を溜めておく → これをトリガーに自律的に改善を回せたら良いかもしれない AIからの自動提案などと組み合わせる
それらの改善提案を適用すると、「Before/Afterでこうなるよ」を合わせて示す → 取り込むモチベーションになる 33

AIのAIによるAIのための出力評価と改善

AIのAIによるAIのための出力評価と改善

たまねぎ

More Decks by たまねぎ

Other Decks in Technology

Featured

Transcript