カスタマーサポートのための RAG：AI の返信を本当に正確にする方法

検索がなければ、LLM は"パスワードをリセットするには？"という質問に対して、 もっともらしいが恐らく間違った答えを返します——ボタンが違う、フローが違う、URL が違う。RAG（検索拡張生成）は、モデルが話す前に、あなたのドキュメントから正しい チャンクをプロンプトに注入することでこれを解決します。

パイプラインの概要

3 つのステージ：取り込み、検索、生成。

1. 取り込み

• ナレッジ UI から PDF、Markdown、Office ファイルをアップロード
• Worker がテキストを抽出し、約 800 token で 100 token のオーバーラップを付けてチャンク化
• 各チャンクは text-embedding-3-small（1536 次元）で埋め込み
• pgvector 拡張を備えた Postgres に保存

2. 検索

訪問者がメッセージを送ると、クエリを埋め込み、そのテナントのチャンクに対してコサイン 距離検索を実行します。Top-K（デフォルト 5）が取り込まれ、類似度のしきい値で無関係な 一致を除外します。

SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM knowledge_chunks
WHERE tenant_id = $2
ORDER BY embedding <=> $1
LIMIT 5;

3. 生成

検索されたチャンクは、明示的な指示とともにシステムプロンプトの先頭に追加されます： 出典を引用する、コンテキストが質問をカバーしていなければ回答を拒否する、確信度が低け れば人間に引き継ぐ。

トークン請求を削減する

大規模なナレッジベースで実際にコストを節約する 3 つのコツ：

• 埋め込みキャッシュ——同じクエリテキスト → 同じ埋め込み。SHA1 ハッシュをキーとし、Redis で 24 時間の TTL。繰り返しの質問では再埋め込みコストを ゼロにします。
• プロンプトキャッシング——Anthropic の cache_control と OpenAI の自動キャッシングにより、静的なシステムプロンプトは 5 分間のウィンドウごとに 1 回だけカウントされます。
• しきい値ベースのスキップ——類似度のしきい値を通過するチャンクが なければ、何も注入しません。モデルに"わかりません"と言わせます。

RAG だけでは足りないとき

RAG は"どうやって X するの？"という質問にうまく対応します。パーソナライズ されたデータ（"私の注文はどこ？"）では失敗します——それには関数呼び出しが必要で、これは別の記事で取り上げます。この組み合わせこそが、わずかなコストで Intercom レベルの AI を実現するものです。