生成AIの評価データの作り方｜正解・例外・回答しない条件をそろえる

生成AIの回答を評価するときは、気になった質問をその場で入力するだけでなく、同じ条件で比較できる評価ケースを用意しましょう。自然に読める回答でも、必要な条件が抜けたり、根拠のない内容が加わったりする場合があります。

この記事では、社内FAQや文書作成支援などの業務AIを評価する担当者向けに、入力、期待する動作、根拠、判定の観点をそろえる方法を紹介します。実施済みの評価結果や、特定モデルの優劣を示すものではありません。

「良い回答」を、業務上の条件へ分解する

Microsoft Foundryの資料では、生成AIの評価に品質、安全性、信頼性などの観点を設け、公開前に評価データセットや例外ケースを使う考え方が説明されています。Microsoftの生成AI評価の説明

評価項目を選ぶ際は、業務で何に使う回答なのかを先に決めます。案内文の下書きと、社内規程を根拠にしたFAQでは、確認したい条件が異なります。共通の総合点だけで済ませず、その用途で見逃せない誤りを言葉にします。

たとえばFAQなら、根拠資料と矛盾しないこと、対象者や適用条件を落とさないこと、資料にない内容を断定しないことが評価候補になります。文体の読みやすさとは別の欄で判定しましょう。

次は評価ケースの記録案です。製品の必須形式ではなく、担当者同士が同じ条件を確認するための項目です。

期待する回答を一文だけで固定すると、意味が正しい別表現を不合格にしたり、文章が似ているだけで合格にしたりするおそれがあります。必要な意味と、許容できる表現の幅を分けておきます。

架空の社内手続きFAQを想定します。以下は評価設計の例で、実在する会社の規程や実測結果ではありません。

通常ケースだけを増やすより、判断の違うケースを含める方が、利用範囲の確認に使えます。短い質問、言い換え、複数の条件が混ざった質問なども、実際の用途に合わせて選びます。

入力資料に秘密情報を含める必要はありません。利用許可のある資料や、条件を保った架空データを使い、実情報を使う場合は組織の取り扱いルールに従ってください。

評価では、根拠違い、条件漏れ、質問の取り違え、不要な断定など、修正方針が異なる失敗を分けます。回答を控えるべきケースで断定したなら、文体の評価が高くても別の問題として扱います。

判定担当の間で意見が分かれる場合は、正解文を増やす前に、業務上の期待がそろっているかを確かめます。資料自体が曖昧なら、そのケースをAIの性能差だけで説明しないでください。

自動評価を使う場合も、何を判定でき、何が判定外なのかを確認します。重要な失敗例は人が根拠を見て確かめ、評価値だけで利用可否を決めないようにします。

モデル、指示文、参照資料を変えたら、何を変えた比較なのかを記録します。評価ケースまで同時に変えると、回答が変わった理由を追いにくくなります。

新しく見つかった失敗例は、既存の比較用ケースとは区別して追加し、評価データの版を更新します。一度の回答だけで安定性を断定せず、必要に応じて同じ条件でのばらつきも確認してください。

まずは一つの業務について、通常、不足情報、対象外のケースを用意し、担当者が同じ理由で判定できるかを確認しましょう。生成結果を共有前に確認する流れは、AI議事録の確認方法も参考になります。