返品の受付条件を尋ねた時、検索が古い手順書を見つけたなら、回答がその資料に忠実でも現行条件と違います。必要な現行資料が見つかったかを最初に確認します。回答の点数だけでは、資料の管理と検索の問題を見分けられません。

現行の手順書が見つかっても、例外を省いて回答する場合があります。どの条件が必須か、何を言い切ってはいけないかを期待回答へ書きます。意味が同じなら表現の違いを許容するなど、採点の目的を明確にします。

利用者が参照先を開けるかも確認します。見かけ上の引用が付いていても、対象の版や章へ戻れなければ照合が難しくなります。評価は、文章の自然さ、資料との一致、参照できることを別々に見る構成にします。

この章の根拠：出典1出典2

AIが作った答えをそのまま正解に使うと、同じ誤りを評価で見逃します。返品業務の責任者が現行手順を読み、質問に必要な箇所を選びます。正解は長い模範文だけでなく、含むべき条件と含めてはいけない断定でも表せます。

例えば「通常商品の返品受付で何を記録するか」なら、注文番号と返品理由が必要だと資料にあるかを確認します。一方、大型商品の例外が資料にないなら「責任者へ確認」が期待結果です。今回の記入例は架空の手順で、公的な返品条件ではありません。

質問文は利用者の言い方も取り入れます。同じ意味の短い質問、条件が省かれた質問、複数の相談が混ざる質問を用意します。業務担当者が期待結果を確認できない場合は、資料や社内の条件を先に整理します。

この章の根拠：出典1

よくある質問に答えられても、前提が足りない質問で推測する可能性があります。「これを返品できますか」なら、商品と時期などが不明です。追加で確認すべき情報を示せるかを試します。質問の前提が不足したことと、資料に記載がないことは分けます。

資料にない質問は、回答しない判断の確認に使います。RAGが常に返答を作ると、実際には書かれていない条件を会社の手順として説明してしまいます。根拠を見つけられない時に、未確認の表示と相談先が出るかを採点します。

古い資料や似た手順が検索へ混ざる可能性も試します。対象の閲覧条件がある場合は、許可された利用者と対象外の利用者の条件を確認します。実際の権限試験は管理担当と設計担当が行い、機密の実値を試験資料に不用意に広げません。

この章の根拠：出典1出典3

「精度が悪い」という感想だけでは、設定担当は直す箇所を選べません。必要な章が取得されなかったなら検索側、章は取得できたが条件が抜けたなら回答側の問題として記録します。資料自体に条件がない場合は、文書整備の課題として分けます。

同じ質問で結果が変わる場合は、実行した条件と結果を残します。1回の成功をもって安定したとは判断しません。どの程度繰り返し確認するかは、使う業務の影響と試験の規模に合わせて決めます。

失敗例を改善の材料に使った後は、別の質問でも試します。調整に使った質問だけが通る設定になっていないかを見るためです。最後の確認用の材料と、調整用の材料を分け、評価で何を確かめたかを説明できるようにします。

この章の根拠：出典1

返品手順の記録項目が変わったなら、その項目を問う質問を再試験します。新しい条件が回答へ反映されたか、古い版を参照していないかを確認します。資料を置き換えた日と、検索へ反映した時点を記録しておきます。

更新箇所だけの試験では、分割や検索の設定が変わった影響を見逃す場合があります。以前通った通常質問や未回答質問も一部再確認します。新しい質問に答えられた代わりに、根拠なしの質問を断定するようになっていないかも見ます。

経営者は合計点の上昇だけで対象を広げません。重要な条件の誤り、資料の範囲、確認へ戻せることを別に判断します。評価の結果は、今回確かめた資料と質問の範囲を添えて、次の運用条件へ引き継ぎます。

この章の根拠：出典1出典3

最初から全社の質問を集めるより、1つの業務で正しい参照先を作れるかを確かめます。通常の質問と、前提不足や根拠なしの質問を用意すれば、回答を作る仕組みの限界も見えてきます。

採点者は、資料を作った人や設定した人だけに限定せず、実際の利用者にも参照先の確認を依頼します。業務条件の正しさと、読み手が根拠へ戻れるかを分けて見ます。試験の負担が大きい場合は、重要な条件から優先します。

結果を共有する時は、試験件数、材料の種類、未評価の範囲を明示します。合格率の1つの数字より、どの質問で使え、どの質問を人へ戻すかが現場の役に立ちます。評価表は利用範囲を決めるための根拠にします。

この章の根拠：出典1出典3