ベンチマークがない場合のAIエージェントのテスト方法 — ネイサニエル・ウェイル（エア・カナダ）

하이라이트

• エア・カナダでは運行、コーポレート、商業、ロイヤルティの各部門でAIソリューションを提供しているが、専門的なタスクに対するパブリックなベンチマークは一切存在しない。

• データサイエンティストはドメインエキスパートではなく、エキスパートも多忙でアクセスが制限されるため、エージェントの評価やベンチマークの構築が困難になる。

• RAGの検証において、基本原則を反転させて1つのページからLLMに質問を自動生成させ、コードベースで評価を行うことで、評価頻度を週1回から1日数十回へと劇的に増加させた。

• サプライヤー契約の分析においては、署名済みの優れた契約書を意図的に壊したり、専門家のテンプレートを再利用して多数のテストケースを生成したりする5つのテクニックを活用している。

• LLMをジャッジとして使用するとノイズが多すぎて構築が極めて困難になるため、可能な限りコードによる評価や完全一致を採用している。

• 専門家からのフィードバックは直接エージェントの修正に使うのではなく、より良いテストやプロンプトを生成するための材料として1ループずつ活用している。

타임라인

1. 00:00 - 06:27

   ベンチマーク不在の課題と過去のRAGプロジェクトの経験

   エア・カナダでのAI開発において、公開ベンチマークの欠如とドメインエキスパートへのアクセスの制限が重なり、評価プロセスの構築が極めて困難になっている。通信エンジニア向けのQ&Aシステムを構築した過去のプロジェクトでも同様の課題に直面し、専門家を交えた長期的で面倒な週1回のミーティングでは十分な開発スピードを維持できなかった。このボトルネックを打破するため、評価の仕組みそのものを根本から変える必要があった。

   • エア・カナダの多様な事業部門向けにAIソリューションを開発する際、特化したタスクに対するパブリックなベンチマークが存在しない。
   • 開発チームはドメインエキスパートではなく、エキスパートへのアクセスも限られているため、手動による評価は週1回しか行えずスピードが出ない。
   • RAGの構築においては正しいドキュメントを見つけることが本質的な課題であり、複雑なパイプラインを追加するとかえって他の箇所が壊れる問題が発生する。
2. 06:27 - 07:50

   問題を逆転させた評価の自動化と開発スピードの向上

   既存のアプローチを反転させ、正解のページから逆向きに質問と検証データを自動生成する手法を取り入れた。これにより主観的な意見の相違や時間のロスを排除し、コードによる客観的な自動評価が可能になった。結果として検証サイクルが高速化し、モデルのチューニングと精度向上の軌道に乗せることができた。この経験から、エージェントの性能を向上させるためには迅速な評価環境が不可欠であるという知見が得られた。

   • 1つのドキュメントからLLMに質問を自動生成させ、エージェントの検索結果と比較するコード評価の仕組みを導入した。
   • 主観的な専門家の意見に頼らない自動評価によって、評価の頻度が週1回から1日数十回へと飛躍的に向上した。
   • 複雑なテクニックを排除し、適切な埋め込みモデルやチャンキングに集中したことで精度が着実に向上した。
3. 07:50 - 16:40

   サプライヤー契約分析における5つの評価テクニック

   エア・カナダのサプライヤー契約分析プロジェクトでは、膨大な契約書の条項チェックを自動化するエージェントの開発に取り組んでいる。外部のベンチマークが存在しないため、過去の変更履歴の比較、ルールからの契約生成、優れた署名済み契約からの条項の意図的な削除、無関係な箇所の順序入替、そしてテンプレートを活用した多様なパターンの生成という5つのテクニックを駆使してテストケースを構築した。これにより、LLMジャッジに頼らずコードのみで高速かつ正確な評価を実現している。

   • サプライヤー契約の分析業務では、弁護士のコストと時間の制約があるため、専用のベンチマークを独自に作成する必要がある。
   • 過去の決定の比較、ルールに基づく契約書の逆生成、署名済み契約書の意図的な破壊など、5つの具体的なテクニックを活用している。
   • 専門家が使用するテンプレートの空白部分に選択肢を網羅的に生成し、コードチェックによって違反を検知する仕組みを構築している。
4. 16:40 - 19:46

   LLMジャッジの限界とテスト駆動による継続的な改善

   評価プロセスにおいてLLMをジャッジとして導入することは一見便利に思えるが、ノイズの多さから構築自体がエージェント開発と同等以上に困難になる。そのため、コード評価や完全一致といった確実な手法を軸に据えることが重要である。また、得られた専門家のフィードバックはエージェントの直接的な修正ではなく、テストの精度を高めるためのループに組み込むことで、開発プロセス全体を継続的に改善することができる。

   • LLMをジャッジとして使用するとノイズが多すぎるため、可能な限りコードによる評価や完全一致を優先すべきである。
   • 専門家からのフィードバックは直接エージェントを修正するのではなく、より良いテストケースやプロンプトの生成に活用する。
   • テストの自動生成はリリースを保証する十分条件ではなく、開発者を加速させるための強力な出発点である。