ジェネラティブエージェンツの大嶋です。
先日LangChainから、LLMアプリケーションのテストに関する決定版ガイド「The Definitive Guide to Testing LLM Applications」が公開されました。
LangChain公式によるXでのアナウンスはこちらです。
The Definitive Guide to Testing LLM Applications by LangChain
— LangChain (@LangChainAI) 2024年8月13日
Reviewing LLM app responses can be a time-consuming and daunting process, from defining criteria for style and accuracy, to spotting new regressions.
After partnering with hundreds of companies to enhance their GenAI… pic.twitter.com/rhc0f2ZI2n
ガイドのPDFは以下のページからダウンロードできます。
この記事では、こちらのガイドの概要を紹介します。
LLMアプリケーションにおけるテストが重要な理由
当ガイドでは、LLMアプリケーションにおけるテストが重要な理由を3つ挙げています。
First, LLMs are non-deterministic, generating a distribution of possible outcomes from a single input. This can lead to inconsistent or hallucinated outputs. Additionally, LLMs ingest arbitrary text, forcing developers to grapple with a broad domain of possible user inputs. And, finally, LLMs output natural language, often requiring new metrics to assess style or accuracy.
- LLMは非決定論的であり、出力には一貫性がなかったりハルシネーションが発生したりする
- LLMは入力として任意のテキストを受け取るため、ユーザーの入力を幅広く想定する必要がある
- LLMの出力は自然言語のため、文体や正確性を評価する新たな指標が必要になることが多い
LLMアプリケーションのテストの3つのステージ
LLMアプリケーションのライフサイクルの中で、テストは以下の3つのステージに適用できると整理されています。
- Design
- Pre-Production
- Post-Production
この3つについて、順に解説されています。
Design
まずはアプリケーションの設計上の工夫として、エラーが発生した際にLLMにフィードバックして出力を修正させること (self-correction) が挙げられています。
LLMアプリケーションの処理がうまくいかなかった際にLLMにフィードバックする処理は、RAGの工夫として使われることもあります。 Self-RAG や Corrective RAG (CRAG) を参考にした例は、LangChain公式ブログでも紹介されています。
また、ガイドに記載がある例ではありませんが、マインクラフトを自動プレイするAIエージェントの「Voyager」では、生成されたコードがエラーにならないかチェックする機構が取り入れられています。
Pre-Production
続いて、Pre-Production、つまり本番環境にデプロイする前のテストについてまとめられています。 事前に決められたテストスイートにもとづくバッチでの評価は「オフライン評価」とも呼ばれます。
Pre-Productionのテストの目的は、以下の3つだと整理されています。
- アプリケーションのパフォーマンスを測定する
- 継続的な改善を可能にする
- リグレッションを検知する
データセットの構築には、以下の3つの方法があると整理されています。
- 手動で例を収集する
- アプリケーションのログを活用する
- 合成データを使用する
LLMアプリケーションのパフォーマンスを数値化する方法は、以下の3つがあると整理されています。
このように、ガイドの中ではLLMアプリケーションのテストにどんな要素があるのか、分かりやすく整理されています。
Advanced
Pre-productionのテストの発展的な工夫として、以下の4つが挙げられています。
- LLMによる評価を、人間が修正したものをFew-shotとして使うことで、LLMによる評価を自己改善 (self-improving) できる
- LLMアプリケーションの出力を単独で評価するのが難しい場合、2 つの出力のどちらが望ましいか評価するほうが簡単な可能性がある (ペアワイズ評価)
- エージェントのテストは「最終的な回答のテスト」「個々のステップのテスト」「エージェントの軌跡のテスト」の3つに分けられる
- LLMアプリケーションのCIの工夫として「キャッシュの使用」「CI用のデータセットの分離」「人間による補助」が推奨される
Post-Production
最後に、Post-Production、つまり本番環境にデプロイした後のテストについてまとめられています。 データセットとして期待する出力を持たず、ユーザーの入力に対してリアルタイムで実施する評価は「オンライン評価」とも呼ばれます。
Post-Productionのテストとしては、以下の2つが挙げられています。
- ユーザーによるフィードバック
- LLM-as-Judge評価器によるフィードバック
LLMアプリケーションを本番環境にデプロイして、トレーシングとオンライン評価器をセットアップすることで、エラーをもとにアプリケーションを改善したり、テストデータを追加したりできると書かれています。
おわりに
以上、LangChainの「The Definitive Guide to Testing LLM Applications」の概要を紹介しました。 こちらの記事で紹介したのはあくまで概要であり、ガイドの中ではよりしっかりとした説明や、LangSmithで具体的に構築するための手順へのリンクなども掲載されています。 再掲になりますが、ガイドのPDFは以下のページからダウンロードできます。
このガイドで紹介されている内容の多くは、LangSmithの機能として提供されています。 LLMアプリケーションの評価を学ぶうえで、LangSmithの公式ドキュメントを読んで実際に構築してみるのは、個人的にもとてもおすすめです。
