ai-evals

AI 評価戦略

感覚的な確認を超えて、AI プロダクトの品質と信頼性を体系的かつ実証的に測定します。

Lenny's Podcast と Newsletter のゲスト11名と投稿から得られた知見を活用して、AI 評価戦略をユーザーと一緒に検討します。

活用方法

1. 失敗パターンの特定 - 実際のトレースをエラー分析し、システムが具体的にどこで問題を起こすのかを見つけるサポートをします。
2. 評価方法の選定 - 具体的な技術的用途に応じて、人間、コード、LLM による評価の適切な組み合わせを提案します。
3. ゴールドセットの構築 - アプリケーションの正解データとして機能する高品質な例の参照データセットをまとめるサポートをします。
4. 運用への導入 - 継続的な品質向上のため、これらの評価を CI/CD パイプラインに組み込む方法を案内します。

基本原則

バリューチェーンを自動化する

Brendan Foody：「特に企業にとって、AI が中核となるバリューチェーンをどれだけ自動化できるかを測定するテストや体系的な方法を、どのように構築するかが重要な考え方だと思います。たとえば、顧客に提供する建築図面を制作する建築事務所なら、それを効果的に測定するにはどうすればよいでしょうか。それぞれの企業には独自のバリューチェーンがあり、複数のプロダクトを持つ企業なら、そのチェーンがいくつかあるかもしれません。」

自社に固有の中核的な成果物を特定し、AI がそうした業務をどれだけ正確に再現できるかを測る体系的なテストを開発します。

主観的な卓越性を重視する

Edwin Chen：「私たちが求めているのは、ノーベル賞を受賞するような詩です。この詩は独創的でしょうか。繊細なイメージに満ちているでしょうか。意外性があり、心に響くでしょうか。月光の本質について何かを教えてくれるでしょうか。」

真のデータ品質とは、表面的な二元的チェックではなく、心に響くことや独創性といった、人間が深く主観的に評価する卓越性によって定義されます。

感覚的な確認をなくす

Hamel Husain & Shreya Shankar：「評価によって、アプリケーションの状況を測定し、改善するために使える指標を作れます。また、確信を持ってアプリケーションを改善する方法が得られます。つまり、改善に向けて繰り返し取り組むためのフィードバックシグナルが得られるのです。」

アプリケーションの品質を継続的に追跡する体系的な指標を作成することで、従来のソフトウェアと同じ確信を持って、チームがプロンプトやモデルを繰り返し改善できるようにします。

構造化された評価ロジック

「Beyond vibe checks: A PM’s complete guide to evals」より：「評価者となる LLM に何を測定させたいのかを明確に伝えることは、単なる工程の一つではありません。それが、平凡な AI と、一貫してユーザーを喜ばせる AI を分けるものです。こうした文章作成のスキルを身につけるには、練習と注意が必要です。」

評価者の役割、データ、成功基準、具体的なラベルを定義する構造化プロンプトを使い、効果的な自動評価を作成します。

テンプレートとフレームワーク

• LLM-as-a-Judge プレイブック（AI プロダクトを改善する評価システムの構築） - 主観的な AI 品質について、信頼できる合格／不合格の二値指標を提供する LLM ジャッジを構築、検証、測定するための体系的な 3 ステップのプロセスです。
• 3 つの評価アプローチ（人間、コードベース、LLM ベース）（雰囲気でのチェックを超えて：PM のための評価完全ガイド） - ユースケースに基づいて適切な評価アプローチを選ぶための判断フレームワークで、それぞれのメリットとデメリットを示します。
• 評価の公式（4 部構成）（雰囲気でのチェックを超えて：PM のための評価完全ガイド） - 効果的な LLM ベースの評価プロンプトを作成するための 4 部構成の公式で、あらゆる PM がジャッジ LLM 用プロンプトを作成する際に利用できます。
• AI エラー分析のためのオープンコーディングと軸足コーディング（AI プロダクトを改善する評価システムの構築） - AI プロダクトの評価に適用した質的調査手法で、ユーザーのインタラクションデータから障害モードを発見し、分類するために使用します。
• RAG 評価フレームワーク（リトリーバー＋ジェネレーター）（AI プロダクトを改善する評価システムの構築） - RAG システムのリトリーバーとジェネレーターの各コンポーネントを分け、それぞれに固有の指標を用いて評価する 2 部構成のアプローチです。
• AI 評価改善フライホイール（AI プロダクトを改善する評価システムの構築） - CI のセーフティネットと本番環境での発見エンジンを組み合わせ、AI プロダクトを継続的に改善するクローズドループのプロセスです。
• リファレンスデータセットの構造（AI プロダクトに異なる開発ライフサイクルが必要な理由） - コールドスタートを解消し、AI システム評価のベースラインを提供するために、初期リファレンスデータセット（20～100 件の例）を構築するテンプレートです。
• エージェント型ワークフローの遷移失敗マトリクス（AI プロダクトを改善する評価システムの構築） - エージェントの複数ステップのワークフローで、どのステップに問題があるのかを正確に特定する診断ツールです。データに基づくデバッグを可能にします。

詳細を含む全リストについては、references/artifacts.md を参照してください。

ユーザーへの質問

• 「本番環境で、現在ユーザーが経験している主な障害モードを 3～5 個挙げると何ですか？」
• 「この機能に求められる品質を定義する、唯一のドメインエキスパートまたは絶対的な決定権を持つ人はいますか？」
• 「現在の評価プロセスのうち、手動と自動の割合はそれぞれどのくらいですか？」
• 「システムの非決定性は、主に検索フェーズと生成フェーズのどちらで発生していますか？」
• 「人間がラベル付けした例を少なくとも 20～50 件含むゴールデンデータセットを、すでに作成しましたか？」
• 「モデルを切り替えたり、システムプロンプトを変更したりしたときの性能差を、現在どのように測定していますか？」

注意すべきよくある間違い

• 雰囲気でのチェックに頼る - 手動かつ逸話的なテストでは品質に一貫性がなくなり、隠れたリグレッションが生じて、時間の経過とともにユーザーの信頼を損ないます。
• プロンプトエンジニアリングにこだわりすぎる - 評価システムの基盤をおろそかにしてプロンプトだけに注力すると、チームが体系的にスケールしたり、段階的に改善したりできなくなります。
• プロダクトのレポートに汎用的な指標を使う - 既製のスコアはフィルタリングには役立ちますが、ビジネスロジックに固有の価値や障害を捉えきれないことがよくあります。
• コンポーネントの分離を無視する - RAG システムでリトリーバーとジェネレーターを個別に評価しないと、スタックのどの部分に問題があるのか判断できません。
• 非決定性を軽視する - LLM の確率的な性質を考慮しないと、本番環境では再現しない可能性のある結果に誤った確信を持つことになります。

詳細

11 人のゲストから得た、出典付きの知見 33 件すべてについては、references/guest-insights.md を参照してください。

関連スキル

• AI プロダクト戦略
• AI ネイティブ UX