LINEのRAG回答を更新後にどう確かめるか｜FAQと回答のテスト表の作り方

FAQを更新したら、新しい質問へ答えられるかだけでなく、以前は正しく答えられた質問が崩れていないかも確認します。RAGで資料を検索できても、その資料の条件を落として回答すれば、お客さんには誤った案内が届きます。

検証では、探した資料、作った回答、人に渡すべき相談の扱いを分けます。平均の点数だけを見るより、「どの質問で、何が外れたか」を残すほうが、直す場所を判断しやすくなります。

回答の文章を先に採点せず、正しい根拠を決める

テスト表は、質問と模範の言い回しを並べるだけでは不十分です。回答に必要な事実、条件、答えてはいけない範囲を先に整理します。書き方が違っても必要な条件が伝わっていれば合格にでき、流暢でも条件を落とした回答は不合格にできます。

Google Cloudの生成AI評価の公式案内でも、用途に合う評価データ、評価基準、回答生成、結果の確認を分けた流れが示されています。本記事では特定サービスの導入手順ではなく、LINEの相談窓口で担当が判断するためのテスト表を提案します。

テスト表の項目	記録する内容
質問	検証用の架空の質問。個別顧客の会話をそのまま転記しない
根拠	回答の正本となる資料と、その版・適用時点
必須条件	回答から落としてはいけない範囲・例外
期待する対応	回答する、追加確認する、人へ渡す、など
実際の結果	取得した資料、回答、引き継ぎ状態
判定と理由	合否と、直す対象が分かる短い理由

更新後の回答を確かめる。正しい根拠を決める：FAQの版と条件を固定。同じ質問で試す：答えない質問も含める。誤りを分ける：検索・回答・引き継ぎ。重大な誤りを直す：平均点だけで公開しない。

図：更新後の回答を確かめる。細かな条件と例外は、本文で確認してください。

「営業時間は？」のような単純な質問だけでは、個別相談での問題を見つけにくくなります。資料の条件を分ける質問、根拠が存在しない質問、人の判断が必要な質問も用意します。

たとえば、期間が決まったキャンペーンを扱うなら、期間内、期間外、対象外の商品、期限が曖昧な質問を試します。架空の注文について返金可否を尋ねる場合は、情報が足りないまま可否を断定しないことが期待する動作になります。

言い換えも入れます。同じ質問の丁寧語と短い口語、複数の条件が入った文を試し、単語が完全一致しなくても適切な資料へ進むかを確認します。文章を大量に自動生成して本数を増やす前に、業務で外してはいけない条件を選んでください。

誤回答を見つけたら、すぐに指示文を長くするのではなく、どの段階で外れたかを見ます。

根拠となる資料が検索結果にない場合は、資料が取り込まれているか、最新版が使われているか、必要な条件が一緒に検索されるかを確認します。廃止した資料が残っていないかも見ます。

根拠は正しいのに回答が違う場合は、条件の省略、資料にない補足、金額や期限の取り違えを確認します。「対象店舗のみ」の条件が検索された資料にあるのに回答から抜けているなら、検索の成功だけを合格にしないでください。

答えられない相談を抱え込む場合は、追加確認や人への切り替え条件を見ます。単に「担当へ渡します」と回答するだけでなく、実際に担当の確認待ちへ残るかも検証します。この三つは、直す場所が異なります。

資料、検索設定、回答の指示、モデルを同時に変えると、何が結果を変えたか分かりにくくなります。可能な範囲で変更を分け、同じテスト表で更新前後を比較します。実行時の資料の版と設定を記録して、後で同じ条件を確認できるようにします。

同じ質問でも結果が変わる場合は、一度の成功だけで合格とせず、揺れがあることを記録します。どの程度の再確認が必要かは、回答が業務へ与える影響で決めます。料金・契約条件・注文変更などの断定が関わる箇所は、一般案内とは別に人の確認を設けます。

多くの質問で正しく答えても、個別の未確認条件を確約する回答が残っていれば、平均点だけで公開判断はできません。重大な誤りとして止める条件と、文章表現の改善として後で扱う条件を先に決めます。

担当への引き継ぎが必要なテストで、元の質問や未解決の内容を渡せなかった場合も、AIの文章だけは正しくても窓口全体の検証は未完了です。お客さんに同じ説明をやり直してもらわず、必要な担当へ話が届くところまで試します。

RAGの仕組みは、LINEとRAGを組み合わせる設計で扱っています。まずは更新したFAQ一つから、答える場合・追加確認する場合・人へ渡す場合をテスト表へ入れてください。正しく答えた数と、人が続きを引き受けられた数を分けると、次に直す箇所が見えます。