チャットボット設計のベストプラクティスの知識マップ(知識グラフ)
この記事は、チャットボットをモデル選定より先に設計すべき要素として、用途の一点化、知識ソースの正本管理、権限の最小化、人への引き継ぎ条件、評価方法を整理します。RAGはチャンク分割した文書を検索してモデルに渡すことでグラウンディングを実現し、根拠のない断定であるhallucinationを防ぎます。ガードレールと権限の最小化はprompt injectionの影響を軽減し、handoff rulesは高リスクな質問を人へ確実に渡す条件を定めます。評価セット(evals)を先に作り、model snapshotを固定してから変更を測ることで、改善を勘に頼らせない運用を目指します。single-agent構成から始め、明確な理由がない限りmulti-agent化は避けるべきというのが本記事の推奨です。
チャットボット設計
モデル選定より前に、役割・知識ソース・権限・引き継ぎ条件・評価方法を含めて行うチャットボット開発の実務。
対話エージェント設計
RAG(Retrieval-Augmented Generation)
質問に関係しそうな文書やページをまず検索し、その本文をモデルに渡して答えさせる方式。モデルが覚えていることだけに頼らせないための仕組み。
グラウンディング(grounding)
回答を、モデルの内部知識ではなく指定した資料に基づかせること。
チャンク分割(chunking)
長い文書を、検索で拾いやすい大きさの意味の塊(1つの制度説明、1つの手順、1つのFAQなど)に切り分けること。
hallucination
事実でないことを、もっともらしい文章で答えてしまうこと。
ハルシネーション
用途を1つに絞る設計
誰の、どの仕事を、どこまで減らすのかというチャットボットの用途を、着手前に1つへ絞り込むこと。
スコープ定義
正本と更新責任者の管理
どの文書やページを正本にするか、誰が更新責任者か、どの頻度で更新し、いつ古い情報を捨てるかを決めて運用すること。
ナレッジガバナンス
single-agent構成
1つのボット(agent)で完結させる構成。
シングルエージェント
multi-agent構成
役割の違うボット(agent)を複数組み合わせる構成。
マルチエージェント
handoff rules(引き継ぎ規則)
どの条件で、ボットから人(または別の担当ボット)へ引き継ぐかをあらかじめ決めておく規則。
escalation rate
全体のうち、人へ引き継いだ割合を示す指標。
エスカレーション率
evals(evaluations)
決めておいた入力の一式を流して、回答の良し悪しを毎回同じ基準で測る仕組み。
評価セット
ガードレール(guardrails)
チャットボットが答えてよい範囲、実行してよい操作をあらかじめ制限しておく仕組み。
prompt injection
利用者の入力や、読み込ませた外部の文書・Webページに指示文を仕込んで、ボット本来の指示を上書きする攻撃。
プロンプトインジェクション
権限の最小化(least privilege)
読める資料や実行できる操作を必要最小限に絞り込む設計原則。
Structured Outputs
回答を自由な文章ではなく、決められた形のJSONで返させる機能。後段のシステムへ値を渡すときに使う。
構造化された出力
PII(Personally Identifiable Information)
氏名、メールアドレス、電話番号、顧客IDなど、個人を特定できる情報。
個人を特定できる情報
model snapshotの固定
本番運用で使うモデルのバージョン(snapshot)を固定し、評価してから切り替える運用。
RAGは検索で見つけた資料の本文をモデルに渡して答えさせることで、回答を指定資料に基づかせるグラウンディングを実現する手段の1つである
PDFやページをそのまま入れるのではなく、意味の塊で切り分けるチャンク分割を前提にすることが、RAGの回答を安定させるための本記事の推奨である
回答をモデルの内部知識ではなく指定した資料に基づかせるグラウンディングは、もっともらしい誤答であるhallucinationを減らすが、無くすわけではない
誰の、どの仕事を、どこまで減らすのかという用途を1つに絞ってから、何を正本にするかを決める順序が推奨される
モデル選定より先に、誰の・どの仕事を・どこまで減らすのかという用途を1つに絞ることが本記事の推奨である
どの文書を正本にするか、誰が更新責任者かを先に決めておくことが本記事の推奨である。ここが無いとボットは古い情報と新しい情報を同時に拾う
明確な分離理由がない限り、まずsingle-agentで検証する流れが推奨される。実装が単純で運用負荷が下がり、予測しやすい実行モデルになる
明確な分離理由がないまま最初からmulti-agent構成にすることは、latency・状態管理・監視・権限管理を重くするためよくある失敗として挙げられている
どの条件で、どこへ、何を添えて人へ渡すかまで最初から決めておくことが本記事の推奨である
チャットボットの運用が適切かは、人へ引き継いだ割合を示すescalation rateなどの指標で確認できる
promptを触るたびに良くなったか悪くなったか判断できるよう、まず評価セット(evals)を作ることが本記事の推奨である
hallucination率は、決めておいた入力を毎回同じ基準で測るevalsで継続的に確認できる
答えてよい範囲・実行してよい操作をあらかじめ制限するガードレールを設計に含めることが本記事の推奨である
外部コンテンツをsystem instructionと同列に扱わず、ツール実行権限を最小化するガードレールは、prompt injectionが与える影響を軽減する
読める資料や実行できる操作を最小化しておくことで、prompt injectionが成功した場合の被害範囲を軽減できる
注文状況や問い合わせ分類のように後段の処理へつなぐ場面では、自由文だけでなくStructured OutputsによるJSON返却を使うことが本記事の推奨である
PIIや顧客固有データを扱うなら、認証はアプリ側で行い取得できる情報を絞るなど、権限を最小化した設計が本記事の推奨である。ユーザーが入力した個人情報が自動でscrub/maskされるわけではない
本番系では、昨日と今日で答え方が変わってしまう事故を避けるため、model snapshotを固定することが本記事の推奨である
固定したmodel snapshotを安全に変更するには、promptのbehaviorをevalsで測ってから切り替えるという運用が前提になる(固定したまま変更しないだけならevalsは必須ではない)