動いたことと、役に立つことを分ける

第12節で、検索の失敗と生成の失敗を分けました。この節では、そのような原因の調査と、変更前後の品質の比較を継続して行う方法を学びます。

LangChainで処理をつなぎ、文章が返るようになっても、アプリケーションの品質が確認できたわけではありません。社内規程の案内なら、正しい資料を使い、条件を落とさず、根拠の無いことを補わずに答えられる必要があります。評価は、このような期待を具体的な基準にして、繰り返し確かめるために行います。

一つの質問にうまく答えられただけでは、別の表現や例外条件にも対応できるか分かりません。また、以前は正しく答えられた質問でも、モデルやプロンプト、検索方法の変更で結果が変わることがあります。動作確認と継続的な品質の比較を分けて考えます。

トレースは、内部で何が起きたかの記録

トレースは、一つの依頼に対して行われた処理の記録です。モデルへ渡した入力、受け取った応答、検索の結果、ツールの要求や実行、各段階の時間などを追います。最終回答だけを見るより、どの段階で問題が生じたかを調べやすくなります。

たとえば古い規程に基づいた回答が返った場合、検索が古い版を選んだのか、正しい資料と古い資料が両方渡ったのか、モデルが資料を読み違えたのかを分けて調べます。生成の途中で何を入力したかが分からないと、推測でプロンプトを変更し続けることになりがちです。

トレースはモデルの内面をすべて説明するものではありません。観察できる入力、出力、選択、時間などの記録です。また、記録には質問や資料の本文が含まれる可能性があるため、保存する範囲や閲覧できる人も設計します。

トレースで原因を調べることと、評価基準に照らして良い結果かを判定することは別です。「検索ツールが一回呼ばれた」という記録だけでは、その検索が必要だったか、回答を支えたかまでは決まりません。記録は判断の材料になり、何を良いとするかは仕事に合わせて定めます。

LangSmithで、観察と比較を行う

LangSmithは、モデルを利用する処理の観察や評価に使える関連プラットフォームです。LangChainの実行を追跡し、呼び出しの構造や失敗箇所を確認したり、質問集合に対する結果を比較したりできます。LangChain以外のアプリケーションにも利用できます。

LangChainを使うためにLangSmithが必須というわけではありません。小さな構成では自分で記録を保存して比較することもできます。ただし、エージェントのように処理経路が変わる構成では、複数の呼び出しをひとまとまりとして追える仕組みが役立ちます。

評価データと基準を、仕事に合わせて用意する

評価用の質問集合には、一般的な質問だけでなく、条件不足、該当資料なし、古い版との混同、利用できない情報への問い合わせなどを含めます。単に正解の文章を一つ用意するより、何を含めるべきで、何を言ってはいけないかを明らかにすると、表現の違いを許しながら意味を確認できます。

このように、質問や必要に応じた参考情報・期待する結果をまとめたものを、評価用データセットと呼びます。たとえば第9節の資料で「申請先」を尋ねた場合は、精算システムという根拠に沿って答えることが基準です。「期限」を尋ねた場合は、資料から確認できないと伝えることが基準になります。すべての質問へ具体的な答えを出すことが、良い結果とは限りません。

RAGなら、必要な資料を取得できたか、回答が資料に支えられているか、質問へ答えているかを見ます。ツール利用なら、正しいツールと引数を選んだか、結果を取り違えていないかを見ます。構造化出力なら、形式と項目の内容を分けて確認します。時間、呼び出し回数、使用量も、品質と並べて比較します。

評価には、決まったルールによる検査、人の確認、別のモデルによる判定などがあります。モデルによる判定も誤る可能性があるため、基準となる人の判断と照らして使います。点数が付いたことだけを、正しさの証明として扱わないことが大切です。

たとえば必須の項目があるかはルールで調べやすく、適用条件を正しく説明しているかは資料と照らした確認が必要です。一つの合計点だけにすると、根拠のない回答が速く返ることを高く評価してしまう場合があります。正確さ、根拠、時間、利用量を分けて見ると、何が改善し、何を犠牲にしたかが分かります。

変更前後を、同じ条件で比較する

開発中に用意したデータで比較する評価をoffline評価、実際の利用中のやり取りを対象とする評価をonline評価と呼びます。ここでのofflineは、APIへ接続しないという意味とは限りません。運用前などに、用意したデータ集合で比較するという意味です。

モデル、プロンプト、検索設定を同時に変えると、結果が改善しても理由が分かりにくくなります。変更を区別し、同じ質問、同じ資料の版、同じ基準で比べることで、何が改善したかを判断しやすくなります。実際に失敗した質問を評価データへ加えると、同じ問題が戻っていないかも確認できます。

次の節では、ここまで学んだ部品を、継続して利用できるアプリケーションへまとめる際の考え方を整理します。