LayerX エンジニアブログ

LayerX の エンジニアブログです。

評価駆動開発（Eval-driven development）：LLMアプリケーション開発における課題とアプローチ

この記事は、LayerX Tech Advent Calendar 2024 の 12日目の記事です。

tech.layerx.co.jp

こんにちは、LayerXのAI・LLM事業部プロダクトマネージャーの野畑(@isseinohata)です。

AI・LLM事業部では生成AIプラットフォーム「Ai Workforce」を開発しています。

getaiworkforce.com

LLMを用いたアプリケーション開発には独自の特徴や課題が存在しており、Ai Workforceの開発チームも、日々様々なチャレンジに向き合っています。今回は、その中でも特にLLMの「出力の不確定さ」に起因する開発プロセスの課題を解決するための方法として、評価駆動開発というアプローチをご紹介します。

評価駆動開発を紹介する前に、LLMをアプリケーションに組み込む上での特徴や課題について、簡単にまとめてみます。

LLMを用いたアプリケーション開発の特徴

1. 精度向上のためのプロセス設計とドメイン知識の拡充

業務アプリケーション等で比較的複雑性の高い処理をAIで自動化するケースにしても、チャット型の汎用的な業務アシスタント、RAGシステム、AIエージェント等の開発を進めるケースにしても、LLMアプリケーションの構築においてはLLMの処理プロセスの設計とドメイン知識の拡充がシステムの性能を大きく左右します。

特に複雑な業務を安定的に解決することが求められるケースでは、タスクの分割によってLLMが解きやすい粒度の問題に落とし込み、ドメイン知識やコンテキストを不足なく与えることによって実用化レベルの精度を出すことが可能になります。

Beyond PoC〜LLMを本番業務で適用するためにLayerXで取り組んでいること〜 - Speaker Deck

一方でAIエージェントやRAGシステムのように比較的汎用性やインタラクティブ性が求められる用途であれば、個別のタスクを分解するのではなく、より抽象的な、人間の基礎的な認知・推論能力に近い機構を定義し、その組み合わせとしてプロセスの構築・最適化をすることが重要となります。

いずれのケースでもユースケースに合わせたプロセスの設計と、ドメイン情報の取り込ませ方（事前にチューニングするか、インタラクティブな体験の中で吸収させるか）が、LLMを実用レベルでシステムに組み込む上では中心的な要素となると思います。

2. コスト、時間、精度のバランスとUXの工夫によるトレードオフ自体の解消

処理プロセスの複雑化は計算コストや処理時間の増加を招くため、システムの性能向上との間でトレードオフの関係にあります。特にLLMアプリケーションでは処理フローや各ステップの抜本的な改修によってユーザーへの提供価値が大幅に向上する場合があるため、局所的な最適化に縛られるのではなく、アウトカム自体の拡大可能性も含めて探索していくことが重要となります。

また、処理時間に対するユーザーの感じ方は、途中出力の見せ方やインタラクションの設計によっても大きく変わります。例えば、プロセスの進捗状況を明確に示したり、途中で得られる部分的な結果を逐次提示することで、最終的なアウトプットが得られるまでのユーザーの体感速度を改善することが可能です。

そのため、単純にコスト、時間、精度のトレードオフの中で最適化を図るだけでなく、ユーザー体験の工夫やアーキテクチャの抜本的な改善を通じて、全体のバランスをとりつつ提供価値の拡大を進めていくことになります。

LLMを用いたプロダクト開発の課題

LLMを用いたプロダクト開発特有の課題として、LLMの出力が確率的で不確定さを伴う点はよく指摘されますが、前述の観点に沿って様々なタスク分割や抽象的な処理機構を組み合わせた複雑なアーキテクチャを構築すると、確率的な要素が絡み合うことで全体の不確定さがさらに増加します。

その結果、プロセスの組み替えや新しいタスク・機構の導入、各タスクにおけるプロンプトの改善など、あらゆるタイプの変更がシステム全体のパフォーマンスにどのような影響を及ぼすかを把握しきれなくなる問題が発生します。

Ai Workforceの開発においても、日々発見される課題に対してさまざまな改善施策を打つものの、それらの施策が他にどのような影響を及ぼすのかを把握しきれず、アウトカムの拡大やトレードオフの最適化を目的にプロダクト自体の改善サイクルを回す観点でも、プロダクションリリース時の品質保証の観点でも大きな足枷となっていました。

評価駆動開発（Eval-driven development ）の導入

このようなLLM特有の不確定さに起因する開発プロセスの課題に対する解決策として注目されているのが、評価駆動開発（Eval-driven development）です。

評価駆動開発とは生成AIやLLMを活用したシステム開発において、システムの出力の評価（evaluation）を中心に設計、開発、改善の開発プロセスを回す手法です。

従来のソフトウェア開発におけるテスト駆動開発（TDD）の概念と基本的には同じですが、テスト駆動開発が予測可能なシステムに適しているのに対し、評価駆動開発はLLMならではの確率的な振る舞いや自然言語による入出力の品質を継続的に評価し、それを改善サイクルに組み込むことで、前述したようなLLMを用いたプロダクト開発特有の課題を解決するためのアプローチです。

具体的には、システムのアウトカムと連動する評価指標（回答の正確性、自然さ、正解データとの忠実性、応答速度、処理コストなどのベーシックなものからユースケース特化のカスタマイズされた評価観点など）とデータセットを定義し、これらを基にシステムの個別要素と全体それぞれの出力品質を評価する仕組みを構築します。実際の開発プロセスではさまざまな実装、改善施策に対して評価を実施し、期待される評価結果が得られるまで改善サイクルを回していきます。

これにより各施策が狙った課題解決につながっているのか、これまでできていたことができなくなっていないか、コストや処理時間に許容できない影響を及ぼしていないか、などを網羅的、効率的に把握できるようになるため、地に足のついた改善プロセスを回すことが可能になります。

OpenAI DevDayでもLLMのように非決定論的な技術を備えたアプリケーションをプロトタイプから本番環境へ移行する際の重要なフレームワークとして評価駆動開発が紹介されています。

The key here is to adopt evaluation-driven development. Good evaluations are the ones which are well correlated to the outcomes that you're trying to derive or the user metrics that you care about. They have really high end-to-end coverage in the case of RAG and they're scalable to compute. This is ...

youtu.be

評価駆動開発における評価方法とプロセス

評価駆動開発における評価は一般的に以下の3つの方法の組み合わせで実施されます。

  • 人間による評価：
    • 複数のタスクを横断した最終アウトプットの評価やニュアンスを含めた評価など、自動化しにくい箇所の評価で活用できる一方、スケール性が低いことが課題となります。
  • AIによる評価：
    • いわゆるLLM as a judgeと呼ばれる、生成された出力をLLM自体に評価させる手法です。この方法はスケール性が高いのが特徴ですが、LLMによる自動評価自体の評価やチューニングが必要になり、評価精度の担保が重要になります。
  • コードベースの評価：
    • 具体的なルールや基準に基づいてAIの出力を評価するアプローチです。ある程度ルールベースに品質を評価できるケースでは活用できますが、それ以外のケース（ほとんどのケース）では活用できない点がデメリットです。

当社でも初期は少数の評価データセットを構築し、人手による評価を行っていましたが、アーキテクチャの複雑性や評価データ数の増加に伴い、比較的すぐに人力の評価が難しくなったため、RAGASやLangfuseを導入してAIによる評価の自動化、モニタリングに取り組んでいます。

評価プロセスについては、以下のような進め方をしています。

  1. 評価の仕組みの開発
    1. ユースケースごとに代表的な少数（十数個程度）のデータセットを作成する
    2. RAGASなどを活用し、代表的な評価指標を導入
  2. リリース時
    1. 導入すべきか悩んでいる新たな変更や改善を実際に評価してみる
    2. 評価結果を見つつ、機能の実装判断と評価自体の改善を行う
  3. リリースされた後
    1. ユーザーのフィードバックや利用ログデータを集めつつ、リリースした機能自体を評価
    2. 評価基盤自体を育てるために、利用データから評価データセットの拡充や評価基準を改善

特に初期はテストケースの網羅性がほとんどないと感じられたり、後述するような正解データ作成の難しさによって一つのデータセットを定義するのに数時間程度かかることもざらにあったため、この取り組み自体に意味があるのだろうかと不安になりました。 しかし現実的に最初から大量のデータセットを準備するのは難しいですし、正確な評価よりも、まず評価プロセス自体を回し始めること自体が重要でもあり、基本的には少数でも良いので初めてみることが大事なのだと思います。

評価駆動開発（Eval-driven development ）の適用事例

当社ではまだ取り組み初期の段階でご紹介できる事例が少ないため、いくつか公開されている事例を中心にご紹介します。

Vercel v0

vercel.com

自然言語からUIデザイン（コード）の自動生成が可能なv0を開発しているチームの発表したブログでは、Vercelが取り組んでいる評価駆動開発（Eval-driven development ）について説明されています。自動スクリプトによる評価テストの実行とGitHubプルリクエストとの連携を行い、出力に影響を及ぼすすべてのプルリクエストについて評価がトリガーされ、結果が開発者にフィードバックされているそうです。評価が開発プロセスに真に組み込まれている面白い事例だと思います。

Anaconda Assistant

www.anaconda.com

Anaconda社はAnaconda Assistant（データサイエンスやAIプロジェクトにおけるコードの作成、分析、デバッグを支援するツール）の開発において、評価駆動開発を採用した開発プロセスについてのブログを公表しています。ユーザーにとってのクリティカルな性能にフォーカスした評価基準の設定や、評価の先の自動チューニング（Agentic Feedback Iteration）の取り組みなども紹介されており、参考になる部分が多いです。

Dosu

blog.dosu.dev

DosuはGitHubリポジトリ上でソフトウェア開発者を支援するAIツールで、特に非コーディングタスク（質問対応や課題の分類など）を軽減することで、開発者が本来の作業に集中できる環境を提供しています。Dosuの開発チームも当初はログを手動で分析して課題の特定や改善を行っていたものの、コードの更新と異なりLLMのプロンプトや処理プロセスの調整が及ぼす不確定な影響を把握し切ることが難しくなり、評価駆動開発を採用しています。

評価設計における難しさ

評価駆動開発に取り組む上で特に難易度が高いと感じるのは正解データの作成です。 LLMシステムでは往々にして正解自体を定義することが難しいケースが多いと思います。 いくつか理由はあるとおもいますが、特に自分が感じる理由を挙げてみます。

  • LLMに任せるタスクの特性によるもの
    • 実業務にLLMを適用する場合、いきなり実用化レベルの最終アウトプットを作ることは難しいため、中間生成物をLLMに作らせることで全体の効率化を目指すケースが多いです。
    • このケースでは人によって作業プロセス自体が違うこともあったり、これまでの業務で中間生成物が明確にアウトプットとして認識されていないケースが多く、正解の定義自体から始める必要があり、難しさの要因になっています。
  • ユーザー側のコンテキストの違いによるもの
    • 仮に別のユーザーから同じ文面で質問や指示が投げられた場合でも、それぞれのユーザーの既知の情報や、ユーザーごとに置かれたコンテキストが違う場合は、同じアウトプットでも異なる評価になることがあり得ます。
    • 正確に評価するのであればクエリと正解データのセットだけではなく、ユーザーの置かれたコンテキストや既知の情報などごとに、正解を分けて作る必要が出てきますが、このレベルの細かい評価データセットを網羅的に作っていくのは現実的ではありません。
  • インタラクティブな体験設計によるもの
    • 特にAIエージェントやチャット型のRAGシステムなどインタラクティブ性を持たせるケースにおいては、一回一回のやり取り自体よりもインタラクション全体を通じてユーザーの課題が解決されたかどうかが重要となります。
    • インタラクティブなやり取りまで含めて様々なパターンの評価データセットを作成するのは非現実的ですが、ユーザー目線では個別の出力というよりは全体の体験としてのアウトカムの評価になるため、このギャップをどのように埋めるかが非常に難しいと感じています。

このような難しさをどう乗り越えていくのかはまだ見えていませんが、例えば後ろの二点については評価用のAIエージェントを構築し、ユーザーが達成したい仮想的なゴール設定とコンテキストを与えて、様々なシナリオを自動評価するとかできると夢が広がるなーと思っています。

最後に：

今回ご紹介した評価駆動開発（Eval-driven development）の実践においては、評価単位の最適化、評価手法のスケール性、データセットの構築方法など、超えるべき問題はたくさんあります。評価基盤を早期に構築し、適切な評価を中心とした開発プロセスを回せるかどうかは、LLMアプリケーション開発において長期的にみて非常にレバレッジの効く部分だと思っており、今後のAIプロダクト開発におけるスタンダードになっていくのではと考えています。

当社でも日々模索しながら進めているため、AI時代のプロダクト開発に興味のある方、すでに取り組まれている方、是非以下のリンクからお話しできると嬉しいです！

jobs.layerx.co.jp

また、LayerXでは、AIプロダクト開発に興味のあるデザイナー、エンジニア、PdMを募集しています。 ご興味のある方は、ぜひチェックしてください！

open.talentio.com