UC-AI-005AILv5
LLM Grounding（事実検証・継続評価）
LLM 出力の事実検証と継続評価を仕組み化し、品質劣化を早期に検知する。
LLM Grounding
KPI 例
- 誤情報検知率
- 評価カバレッジ
- 再発率
LLM Grounding は、LLM の回答精度を「モデルの気分」ではなく、参照したデータとの対応で評価する考え方です。Bright Data の一次情報では LLM Grounding が AI 向けユースケースとして案内されており、この学習サイトでは 検索やクロールで取得した根拠を残し、その根拠で回答を評価する 形で理解するのが自然です。
誰の課題か
- 回答品質を人手レビューだけに頼っている AI チーム
- 引用は付けたが、その引用が回答を本当に支えているか検証したい開発者
- モデル更新やプロンプト変更後の劣化を定点観測したい運用担当
Grounding で重要なのは、スコアそのものより比較可能性です。同じ質問セット、同じ取得条件、同じ評価軸で回せるようにしないと、改善か悪化かを判断できません。
推奨製品セット
| 製品 | 役割 | 使いどころ |
|---|---|---|
| LLM Grounding | 評価の設計単位 | 回答と根拠の対応を確認する |
| SERP API | 最新ソースの探索 | 質問ごとの候補 URL 収集 |
| Crawl API | 根拠本文の固定化 | 評価時に読む本文を保存する |
| MCP | AI クライアント連携 | 検索や取得をエージェントから呼ぶ |
- Grounding は単独では完結せず、根拠を安定して取得する基盤と一緒に設計します。
- 評価対象の回答本文、出典 URL、取得日時を 1 セットで保存することが前提です。
最小実装イメージ
以下は、回答テキストと根拠テキストの単純な一致率を記録する最小例です。専用 API の詳細スキーマは製品更新の影響を受けるため、このページではアプリ側の評価フレームに留めます。
import json
import re
def tokenize(text: str) -> set[str]:
return {
token.lower()
for token in re.findall(r"[A-Za-z0-9一-龠ぁ-んァ-ヶー]+", text)
if len(token) > 1
}
def grounding_score(answer: str, evidence: str) -> float:
answer_tokens = tokenize(answer)
evidence_tokens = tokenize(evidence)
if not answer_tokens:
return 0.0
overlap = answer_tokens & evidence_tokens
return round(len(overlap) / len(answer_tokens), 3)
sample = {
"question": "Bright Data MCP は何に使うか",
"answer": "Bright Data MCP は AI クライアントから検索や抽出を呼び出す接続面として使う。",
"evidence": "MCP は Claude、Cursor、社内エージェントなどの AI クライアントから Bright Data を呼ぶための接続面です。",
}
sample["grounding_score"] = grounding_score(sample["answer"], sample["evidence"])
print(json.dumps(sample, ensure_ascii=False, indent=2))この例は単純ですが、回答と根拠を分離保存し、比較結果を数値化する最初の一歩として使えます。実運用では、SERP API や Crawl API で取得した根拠本文を評価セットとして固定し、モデルやプロンプトを変えても同じ条件で比較します。
運用ポイント
- 評価に使う根拠データは、回答生成時の live 取得結果とは別に保存します。後から再現できない評価は運用に乗りません。
- Grounding スコアだけで合否を決めず、引用漏れ、引用切れ、必須語の欠落も別指標で見ます。
- モデル更新時は、質問セット、根拠セット、採点コードを同時に固定して比較します。
- 間違った引用が付いた回答は、高スコアでも危険です。URL 単位ではなく本文断片との対応まで確認できる設計が望ましいです。
- 定期評価は本番トラフィックに混ぜず、固定サンプルで別ジョブとして回します。