【ITニュース解説】We thought exact match was enough for LLM evals. It wasn't.

大規模言語モデル（LLM）を活用したシステム開発において、その性能を評価する方法は非常に重要になる。特に、システムが一度本番環境で稼働を始めると、評価は単なる一度きりの検証作業ではなく、日々の開発に欠かせないものとなる。新しい機能の追加、バグの修正、あるいはLLMへの指示（プロンプト）のわずかな変更であっても、「意図した問題が解決されたか」だけでなく、「他の機能に悪影響が出ていないか」を常に確認する必要がある。LLMの動作は複雑で、一つの変更が予想外の場所に影響を及ぼす（回帰）ことが少なくないため、これを繰り返しテストできる評価の仕組みは、システムの品質を維持する上で不可欠だ。

あるサービスでは、研究論文を読み込み、編集者が必要とする情報（倫理承認の有無、臨床試験登録の有無、図表参照の一貫性、自己引用率など）をLLMが回答するシステムを開発していた。当初、これらの質問はほとんどが「はい／いいえ」で答えられるようなシンプルなものだと考えられ、LLMの回答と人間が事前に準備した「正解」が完全に一致するかどうかを評価する「完全一致（Exact Match）」という方法が採用された。正解と出力が全く同じであれば1点、異なれば0点というシンプルな仕組みだった。この方法は、「はい／いいえ」のような厳密な回答が求められるチェックには効果的で、プロンプトを変更した後でも、すぐに結果を確認し、何が改善され、何が悪化したかを把握できた。

しかし、この評価方法は、LLMに「引用文を抽出する」や「構造化されたメタデータ（著者名、所属など）を抽出する」といった、より複雑なタスクを求め始めるとすぐに限界を迎えた。LLMは多くの場合、意味的には正しい回答を生成していたにもかかわらず、評価システムはそれを「間違い」と判断してしまったのだ。例えば、正解のテキストに含まれる引用符が、PDFからの抽出過程やLLMの生成過程で「‘」から「'」のようにわずかに形が変わったり、ハイフンが異なる種類のダッシュになったり、あるいはPDF変換時にギリシャ文字や特殊文字が微妙に変化したりすることがあった。さらに、LLMが正解の文脈に加えて、その前後の余分な文を一緒に返してしまうこともあった。これらの違いは、人間から見れば「実質的に正しい」回答であるにもかかわらず、完全一致の評価基準では「間違い」とされてしまった。

このような状況が続くと、評価レポートが実際の性能を正しく反映していないという不信感が生まれ、本当にシステムに問題が発生した際にも、それが単なる「形式上の誤り」なのか「本質的なバグ」なのかの区別がつかなくなり、問題の見落としにつながる可能性が生じた。

この問題に対処するため、開発チームは「すべての情報を同じ厳密さで評価する必要はない」という結論に達した。そして、データの種類（フィールドタイプ）に応じて異なる評価ルールを適用する方針へと変更した。

具体的には、以下のように評価基準を分類した。

• ブール値（はい／いいえ）や列挙型（選択肢から選ぶもの）：これらは厳密さが重要であるため、引き続き完全一致を採用し、閾値（合格ライン）を1.0とした。
• メタデータフィールド（名前、所属など）：これらの情報は、わずかな表記ゆれがあっても意味が変わらないことが多い。そのため、少し緩やかな閾値（約0.95）を設定し、部分的な一致も許容するようにした。
• 参照テキスト（論文からの引用文など）：重要なのは、LLMが正しい文章の箇所を見つけられたかどうかであり、文字の一字一句が完全に一致することではない。このため、より緩やかな閾値（約0.85）を設定した。

特にテキストフィールドの評価においては、以下の工夫が凝らされた。まず、比較するテキストの両方に対し、小文字化、余分な空白の除去、無害な句読点や括弧の削除といった「正規化」処理を行った。これにより、表面的な違いを吸収し、テキストの本質的な内容で比較できるようにした。次に、文字列の類似度を計算する「ファジーマッチング」という技術を導入した。これは、単なる完全一致ではなく、文字列の並び順の類似度、単語の集合の類似度、部分的な一致度など、複数の観点からどれだけ似ているかを数値化する技術だ。さらに、「包含ルール」も追加された。これは、正解テキストがLLMの出力に完全に含まれている場合や、その逆の場合に、強力な一致とみなすというルールだ。長いテキストのうち、どの程度の割合がカバーされているかに応じてスコアを調整する。

この新しい評価システムでは、完全一致、ファジーマッチ、そしてF1スコア（適合率と再現率という二つの指標を組み合わせたもので、精度のバランスを示す）が並べて表示されるようになった。これにより、もし完全一致スコアが低くてもファジーマッチスコアが高ければ、それは「形式的なノイズ（表示のズレ）」が原因であり、もし両方のスコアが低ければ、「実際にモデルが間違っている」と判断できるようになった。

評価システムを構築するにあたり、LLM自身を評価者として使う方法や、既存の複雑な評価フレームワークの利用も検討された。しかし、LLMを評価者にすると、評価結果自体が非決定論的（実行するたびに結果が変わる可能性がある）になり、システムの問題なのか評価者の問題なのかが分かりにくくなる。また、既存のフレームワークも、このサービス固有の複雑な構造化データやフィールドごとの評価ルールに対応するには、結局多くのカスタムロジックを開発する必要があった。埋め込み類似度（テキストの意味的な近さを評価する技術）も検討されたが、「意味的に近い」回答が、特定の文脈では「誤った回答」となる可能性があり、厳密さが求められるこのサービスには不向きだった。

結局、最もシンプルで決定論的な方法が採用された。それは、人間が作成した「正解ファイル（グランドトゥルース）」に基づき、シンプルで透明性の高い文字列比較やセット比較によってスコアを算出するというものだ。この方法は、高度な技術を使っているわけではないが、安価で、結果が分かりやすく、何よりも「なぜスコアが下がったのか」を正確に特定できるという大きな利点があった。具体的には、正解ファイルとLLMの出力ファイルを比較することで、問題の根本原因をすぐに突き止めることができる。

グランドトゥルースは、品質保証チームによって作成された。これは、通常の運用でよく見られる「典型的な論文」と、システムの弱点を突くような「意図的に困難なエッジケース（例：変則的な構造、分かりにくい場所に書かれた情報、欠落したセクションなど）」の両方から構成されている。典型的なデータだけでは評価が甘くなりがちで、エッジケースだけでは厳しすぎるといった偏りを避けるため、両方をバランス良く含めることが重要だった。このデータセットは、各チェックにつき約8つの論文と小規模だが、プロンプトやパイプラインの変更による明らかな回帰（性能低下）を検出するには十分だと考えられている。

システムエンジニアを目指す初心者へのアドバイスとして、まず「完全一致」で評価を始めることは良い出発点となる。それにより、どの情報が本当に厳密な正確性を必要とし、どれがそうでないかを学ぶことができる。次に、評価指標をプロジェクト全体で一律に決めるのではなく、ブール値、テキスト引用、メタデータといった「フィールドタイプごと」に適切なものを選択することが重要だ。また、評価スコアが下がった場合、すぐにプロンプトを修正するのではなく、まず正解と出力の差分を詳細に確認するべきだ。時には、問題がLLMではなく、評価の仕組み自体にある場合もある。さらに、実際の運用で問題となりがちな「意図的に厄介なケース」をテストデータセットに含めておくことも有効だ。そして、LLMのプロンプトと評価結果は必ずセットでバージョン管理を行い、後でどの変更がどの結果に影響したのかが明確にわかるようにしておくことが、長期的な開発では非常に重要となる。