音声AI技術

RAGとは?音声AIが社内情報を使って答える仕組み

AI-SNS.IO 編集部 · 公開

RAGとは?音声AIが社内情報を使って答える仕組み(AI-SNS.IO Call ブログ)

RAG(Retrieval-Augmented Generation、検索拡張生成)は、モデルが持っている一般知識だけに頼らず、自社のFAQやマニュアル、Webの公開情報を検索してから答えを作る仕組みです。電話の音声AIでは、「うちの営業時間は?」「キャンセル方法は?」といった、社内に正解がある質問に答える場面で特に重要になります。検索せずにそれらしい答えを生成すると、自信満々の誤案内になりやすいからです。

この記事では、RAGとは何か、音声AIでの使われ方、ソースの準備、答えられないときの扱い、情報の更新、よくある落とし穴を整理します。全体の流れは音声AIの仕組み、プロンプト側の制約は電話AIエージェントのプロンプト設計、声の複製を使う場合はボイスクローンとビジネスも参照してください。読み終わったら、電話で聞かれやすい質問を十件書き、その正解がどの文書の何節にあるかを表にするのが第一歩です。

RAGとは

考え方

まず質問に関連しそうな文書片を探し(検索)、その片を根拠に答えを生成します。教科書を閉じて暗記だけで答えるのではなく、開いて該当ページを見てから話すイメージです。

なぜ電話で必要か

一般モデルは、御社の営業時間や独自メニューを知りません。知ったかぶりをすると、利用者は信じたまま来店や手続きをします。検索で根拠を渡すことは、誤案内の予防装置です。

RAGが得意なこと/不得意なこと

得意なのは、文書に書いてある手順、公開されている料金表の読み上げ補助、所在地、キャンセルポリシーなどです。不得意なのは、文書に無い個別事情の判断、感情的な交渉、最新すぎてまだ載っていない障害の詳細です。不得意領域は人へ渡す設計が必要です。

音声特有の制約

検索結果が長いと、読み上げが長くなり、遅延と割り込みが増えます。電話向けRAGは、短い根拠と短い回答文を前提に設計します。遅延は音声AIのレイテンシ、割り込みはバージイン(割り込み)も関係します。

IVRとの組み合わせ

番号で終わる定型はIVRや固定案内に任せ、曖昧な質問だけRAG付き対話に回すと、検索コストと待ちが減ります。IVRとAI音声エージェントの違いも参考になります。

音声AIでの使われ方

発話、意図、検索、短文生成、読み上げ、必要なら切替の流れ
図1:電話の音声AIにおけるRAGの一往復

典型的な一往復

発話を認識し、意図を把握し、関連文書を検索し、短い回答を生成し、TTSで読む。必要なら復唱や追加質問へ進みます。検索が遅いと、この一往復の体感が壊れます。

先に聞く、あとに検索

曖昧な質問には、検索前に一問だけ確認してから探す方が精度が上がることがあります。ただし確認が増えすぎると遅延になるので、上限を決めます。

回答の型

結論を先に、根拠を短く、次の行動を一つ、が電話向きです。ブログ記事のような前置きは向きません。

多言語

質問言語と文書言語が違うと検索が外れます。言語切替後は、その言語のソースを優先する設計が必要です。多言語の詳細は後続の記事でも扱います。

スタッフ向けと利用者向け

同じ文書でも、スタッフ用の内部メモを利用者に読んではいけないことがあります。公開範囲のラベルをソースに付け、検索対象を分けます。

ソースの準備

何を入れるか

電話で実際に聞かれるFAQ、営業時間、アクセス、キャンセル、支払い方法の公開情報、よくある手順です。社内の雑多なチャットログを無選別に入れると、ノイズが増えます。

音声用に短く書く

Webの長文をそのままだと、検索ヒットしても読み上げが冗長です。電話用の短文回答を別フィールドで持つと品質が安定します。

チャンク(分割)の考え方

長すぎる塊は焦点がぼけ、短すぎる塊は文脈が欠けます。見出し単位や、一問一答単位が扱いやすいです。分割ルールを文書化し、更新時も同じ規則で切ります。

メタデータ

更新日、公開/内部、言語、店舗、サービス名などのメタデータを付けます。検索後に古い内部文書を落とすフィルタに使います。

固有名詞の揃え

メニュー名やプラン名の表記ゆれは検索漏れの原因です。表記を統一し、読みリストとも揃えます。認識側の話は電話の音声認識も参照してください。

入れてはいけないもの

未公開価格、個人情報、内部の人事評価、推測のメモです。誤って入ったら生成に混ざります。取り扱い方針は社内ルールに従い、この内容は一般的な情報であり、法的助言ではありません。

答えられないときの扱い

古い文書、長文読み上げ、空ヒット、内部混入、矛盾、更新遅れの比較
図2:電話向けRAGで起きやすい失敗

知らないと言う

根拠が無い、検索が空、信頼が低いときは、無理に答えない指示をプロンプトに書きます。知ったかぶりが最悪です。

人へ渡す

判断、例外、苦情、支払い争い、医療・法律の結論は人へ。条件は具体的に。電話AIエージェントのプロンプト設計の引き継ぎ条件と揃えます。

別チャネルへ

長い手順やフォーム入力は、電話で全部読まず、案内ページやメールへ逃がします。URLを長く読まない言い方にします。

確認質問

候補が複数あるときは、二者択一で絞ってから答えます。五つ並べて読まないこと。

部分回答

分かる範囲だけ答え、残りは人や別チャネル、と明示します。中途半端を隠さないことが信頼につながります。

情報の更新

更新のトリガー

メニュー変更、料金改定(公開後)、営業時間変更、キャンペーン終了、障害の開始と終了です。トリガー一覧を運用表にします。

誰が直すか

文書オーナーと、検索インデックス反映の担当を分けて書くと滞留しません。反映遅れが誤案内の主因になることがあります。

キャッシュ

頻出回答のキャッシュは速度に効きますが、鮮度管理が必須です。無効化のきっかけを決めます。

回帰セット

重要質問十件を、更新のたびに電話台本で確認します。検索が別文書にすり替わっていないかを見ます。

デモと本番のデータ

日本の電話番号の提供は準備中です。現在はデモで着信をシミュレーションして体験できます。電話回線でのAI応答を含む各機能の提供状況は機能一覧でご確認ください。デモ用の仮データと本番の公開データを混ぜないでください。

よくある落とし穴

ソース品質を無視してモデルを責める

文書が古い、矛盾している、長すぎる、ラベルが無い、状態でモデルだけ変えても直りません。まずソースを直します。

ヒット件数を増やすほど安心する

関係ない断片が増えると、生成が迷います。件数より関連性、公開範囲、更新日のフィルタが重要です。

書き言葉のまま読む

ブログ調の長文を読むと、電話では途中で止められます。音声用短文を用意します。

根拠を言わない/言いすぎる

根拠が無い断定は危険です。逆に、内部ファイル名を読み上げるのも不適切です。利用者向けの言い方を決めます。

評価を人手でしない

自動の類似度だけだと、電話での聞きやすさが分かりません。週次で実再生します。

セキュリティを後回し

内部文書が検索に混ざる事故は、起きてからでは遅いです。公開範囲ラベルを初期から付けます。法的助言ではありません。

評価の観点

正解率だけでなく、根拠の妥当性、短さ、禁則、人へ切替の妥当性、更新反映の遅れ、を見ます。未検証のパーセントを対外的に掲げないこと。社内の改善には、失敗質問のリストが一番効きます。

ナレッジとプロンプトの分担

プロンプトは振る舞い、RAGは事実、と分けると手入れが楽です。事実をプロンプトに直書きしすぎると、更新のたびにプロンプトを開くことになります。逆に、振る舞いを文書にだけ書くと、検索が外れたときに振る舞いも消えます。両方に必要な最小限だけ重複させます。

業種別のソース例

飲食

営業時間、席種、キャンセル、アレルギーの聞き方、駐車場。日替わりは鮮度管理が要点。

医療

受付時間、初めての受診の持ち物、処方の説明はしない、緊急性の分流。

不動産

公開中の物件条件、内見の申し込み方法、非公開の交渉条件は人へ。

SaaS

公開ドキュメントの手順、権限変更は管理画面へ、障害は現状の短い告知を優先。

運用チェックリスト

AI-SNS.IO Callでの位置づけ

Callでは、ナレッジや試し通話、IVR、ボイスメール、要約などを組み合わせて、社内情報に基づく案内の流れを設計・観察できます。電話回線でのAI応答を含む各機能の提供状況は機能一覧でご確認ください。手順は使い方のガイドも参照してください。日本の電話番号の提供は準備中です。現在はデモで着信をシミュレーションして体験できます。全体はAI-SNS.IO Callのトップ、開始は月額0円からです。

関連する記事

検索クエリの作り方(電話向け)

利用者の発話をそのまま検索クエリにすると、フィラーや言いよどみで外れます。意図の短い正規化文(例:キャンセル方法)に変換してから探す指示が有効です。正規化はプロンプトか専用の小さな処理で行い、元発話はログに残します。個人情報は方針に従ってマスクします。法的助言ではありません。

正規化が強すぎると、別意図にすり替わります。例:『料金』と正規化した結果、別プランの料金を返す、などです。正規化辞書は小さく保ち、すり替わり台本で回帰します。

根拠の提示の仕方

『受付時間の案内では、平日は九時から十八時です』のように、利用者に分かる根拠名を短く添えます。内部の文書IDやファイルパスは読み上げません。根拠が複数矛盾する場合は、新しい更新日を優先するか、人へ渡すかをルール化します。矛盾をモデルに仲裁させない方が安全な領域があります。

インシデント対応

誤案内が起きたら、該当ソースを直し、キャッシュを無効化し、回帰十問を回し、必要なら利用者へ訂正連絡の方針を決めます。モデルのバージョンだけ戻しても、ソースが古いままなら再発します。インシデント票に、ソース側の原因か、検索側か、生成側かを分けて書きます。

次の一歩のワークシート

電話十問、正答ソース、音声短文の有無、公開ラベル、更新担当、空ヒット時の発話、切替条件、回帰日、を埋めてください。空欄のまま検索エンジンだけ強くしても、誤案内は残りがちです。

インデックス再構築のタイミング

全文再構築は重いので、差分更新を基本にし、破壊的な分割規則変更のときだけ全再構築します。再構築中に古いインデックスが残る時間帯の扱い(読み取り専用、人へ多めに切替)を決めます。再構築後は回帰十問必須です。

実務での進め方

インデックス再構築のタイミングについて、担当、頻度、失敗時のフォールバックを一枚にまとめます。まとめが無い状態でツールだけ導入しても、運用が追いつきません。フォールバックは人への切替か、短い謝罪と折り返しを基本にします。

店舗・ブランドが複数ある場合

メタデータで店舗を絞り、利用者の店舗が分からないときは一問だけ確認してから検索します。全店舗横断のヒットをそのまま読むと、別店舗の時間を案内する事故が起きます。

実務での進め方

店舗・ブランドが複数ある場合について、担当、頻度、失敗時のフォールバックを一枚にまとめます。まとめが無い状態でツールだけ導入しても、運用が追いつきません。フォールバックは人への切替か、短い謝罪と折り返しを基本にします。

季節コンテンツ

夏季講習や繁忙期メニューは、開始前にインデックスへ追加し、終了後に無効化します。無効化忘れは、終了後の誤案内の典型です。カレンダー連動のチェックリストを持ちます。

実務での進め方

季節コンテンツについて、担当、頻度、失敗時のフォールバックを一枚にまとめます。まとめが無い状態でツールだけ導入しても、運用が追いつきません。フォールバックは人への切替か、短い謝罪と折り返しを基本にします。

測定項目の社内定義

空ヒット率、人へ切替率、スタッフ修正が必要だった要約の割合、回帰十問の失敗数、を週次で見ます。対外的なパーセント自慢には使いません。

実務での進め方

測定項目の社内定義について、担当、頻度、失敗時のフォールバックを一枚にまとめます。まとめが無い状態でツールだけ導入しても、運用が追いつきません。フォールバックは人への切替か、短い謝罪と折り返しを基本にします。

ベンダー選定で聞くこと

電話向け短文の扱い、メタデータフィルタ、更新反映の遅延、ログの取りやすさ、公開/内部の分離、障害時の挙動を確認します。デモの好条件だけを契約根拠にしないでください。

実務での進め方

ベンダー選定で聞くことについて、担当、頻度、失敗時のフォールバックを一枚にまとめます。まとめが無い状態でツールだけ導入しても、運用が追いつきません。フォールバックは人への切替か、短い謝罪と折り返しを基本にします。

教育とオーナーシップ

文書オーナーが『検索に載っている』ことを自分の成果物だと認識する文化が必要です。載せて終わり、にすると鮮度が死にます。月次でオーナー会を短く開きます。

実務での進め方

教育とオーナーシップについて、担当、頻度、失敗時のフォールバックを一枚にまとめます。まとめが無い状態でツールだけ導入しても、運用が追いつきません。フォールバックは人への切替か、短い謝罪と折り返しを基本にします。

音声短文の読み上げ点検1

ソース点検1では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件1を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検2

ソース点検2では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件2を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検3

ソース点検3では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件3を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検4

ソース点検4では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件4を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検5

ソース点検5では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件5を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検6

ソース点検6では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件6を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検7

ソース点検7では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件7を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検8

ソース点検8では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件8を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検9

ソース点検9では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件9を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検10

ソース点検10では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件10を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検11

ソース点検11では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件11を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検12

ソース点検12では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件12を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検13

ソース点検13では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件13を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検14

ソース点検14では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件14を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検15

ソース点検15では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件15を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検16

ソース点検16では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件16を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検17

ソース点検17では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件17を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検18

ソース点検18では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件18を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検19

ソース点検19では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件19を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検20

ソース点検20では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件20を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検21

ソース点検21では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件21を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検22

ソース点検22では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件22を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検23

ソース点検23では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件23を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検24

ソース点検24では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件24を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検25

ソース点検25では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件25を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検26

ソース点検26では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件26を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検27

ソース点検27では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件27を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検28

ソース点検28では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件28を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検29

ソース点検29では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件29を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

音声短文の読み上げ点検30

ソース点検30では、回帰十問のうち一問を選び、ヒットした断片が音声短文として読み上げ可能かを二人で確認します。不可能なら短文を追加し、元の長文は検索対象外または要約専用に落とします。点検は店舗条件30を変えて行い、他回と同一文面にならないよう、その問の実際の利用者表現を一件添えます。

電話向けRAGの点検観点1

更新日が九十日を超えた案内は、検索優先度を下げ、必要なら人へ早めに切替えます。古い案内がトップヒットになる状態は、誤案内の温床です。

この観点1の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号1、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点2

店舗メタデータが空の文書は、全店舗検索から除外するか、確認質問後にだけ使うようにします。別店舗の時間を読む事故を防ぎます。

この観点2の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号2、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点3

内部ラベルの文書がヒットしたら、生成前に破棄し、公開ソースだけでもう一度探します。それでも無ければ知らないと伝えます。

この観点3の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号3、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点4

チャンクが四百文字を大きく超える場合は、見出し単位へ再分割し、電話用短文フィールドを必須にします。

この観点4の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号4、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点5

営業時間が文書間で矛盾したら、更新日の新しい方を採用するか、人へ渡すかをルールで固定し、モデルに仲裁させません。

この観点5の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号5、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点6

キャンペーン終了日を過ぎた文書は、終了処理のチェックリストで無効化し、キャッシュも同時に消します。

この観点6の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号6、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点7

クエリ正規化が意図をすり替えていないかは、言い換え二種の台本で確認します。すり替わりがあれば辞書を小さくします。

この観点7の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号7、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点8

空ヒット時は、短い謝罪と切替、または別チャネル案内に固定し、生成モデルに埋めさせません。

この観点8の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号8、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点9

人へ切替が遅い場合は、検索中の無音上限を見直し、先に切替条件を判定する順序へ変えます。

この観点9の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号9、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点10

キャッシュ無効化の漏れは、更新担当の完了条件に『無効化確認』を入れ、二人確認にします。

この観点10の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号10、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点11

同じ質問に対し文書が三件以上ヒットするときは、店舗・言語・更新日で絞り、読み上げ候補を一つにします。

この観点11の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号11、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点12

料金表を扱うときは、公開済みの表だけを対象にし、未掲載は人へ回す禁則を検索後にもう一度適用します。

この観点12の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号12、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点13

障害告知は一般FAQより優先するフィルタを入れ、障害終了後は告知を無効化して通常FAQへ戻します。

この観点13の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号13、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点14

新規メニュー名は、認識辞書・読みリスト・検索シノニムの三か所へ同日登録します。どれか欠けると見つかりません。

この観点14の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号14、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点15

長い手順は電話で読まず、短文で誘導し、詳細は案内ページへ逃がします。URLの字母読みを避けます。

この観点15の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号15、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点16

スタッフ専用の手順書は、利用者向けインデックスから物理的に分離します。ラベルだけに頼ると事故ります。

この観点16の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号16、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点17

回帰十問の失敗は、ソース/検索/生成のどれかに必ず分類し、担当を分けます。『なんとなく』で閉じません。

この観点17の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号17、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点18

多店舗の共通FAQと店舗差分を分けて持ち、差分だけを店舗メタデータ付きで載せます。

この観点18の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号18、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点19

季節文書の開始前プレビューは、本番インデックスと分離した検証枠で行い、開始時刻にだけ切替えます。

この観点19の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号19、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

電話向けRAGの点検観点20

要約ログに検索根拠IDを残し、誤案内調査でどの断片が使われたかを追えるようにします。個人情報はマスクします。

この観点20の点検では、対象となる質問を一件選び、実際の利用者の言い回しを一つつけた台本で通し、ヒット断片・採用短文・読み上げ・切替の有無を記録します。不合格ならソースかフィルタを直し、同じ言い回しともう一つの言い換えで再実行します。変更票には観点番号20、担当、期限、結果を書き、翌週の冒頭で閉じます。対外的な精度の誇示は目的にせず、失敗リストを減らすことが成果です。関連するプロンプト禁則や遅延予算も、必要なら同じ変更票からリンクします。

よくある質問

RAGとは何の略ですか?

Retrieval-Augmented Generation(検索拡張生成)の略で、関連情報を検索してから答えを生成する仕組みです。

電話でRAGは必須ですか?

社内固有の事実に答えるなら、実質的に必要です。検索無しの生成は誤案内リスクが高いです。

FAQをそのまま入れれば十分ですか?

不十分なことが多いです。音声用短文、更新日、公開ラベル、分割規則が揃って初めて安定します。

答えがないときはどうしますか?

知らないと伝え、人へ渡すか別チャネルへ案内します。推測で埋めません。

料金は答えてよいですか?

公開されている情報に限ります。未掲載は人へ。記事でも未検証の金額は書きません。

更新はどれくらいの頻度ですか?

変更のたびに反映が基本です。週次の棚卸しに加え、キャンペーンや障害は即時反映の手順を持ちます。

検索が遅いときは?

頻出回答のキャッシュ、クエリの正規化、対話前のIVR分流、音声短文化を検討します。

内部資料が混ざる事故を防ぐには?

公開/内部ラベルとフィルタ、投入前レビュー、定期の抜き取り確認です。法的助言ではありません。

プロンプトとどちらを直すべきですか?

事実はソース、振る舞いはプロンプト、が原則です。どちらも直しが必要な場合は変更票を分けます。

評価はどう始めますか?

電話十問の回帰から始め、失敗をソース/検索/生成に分類します。未検証の改善率公表はしません。

AI-SNS.IO CallでRAG的な案内は試せますか?

ナレッジと試し通話を組み合わせ、短い根拠つき案内や切替の流れを確認できます。電話回線でのAI応答を含む各機能の提供状況は機能一覧でご確認ください。日本の電話番号の提供は準備中です。現在はデモで着信をシミュレーションして体験できます。公開情報だけをソースにした十問から試すと安全です。

最初の一日で何をしますか?

十問の正答表を作り、音声短文が無いものを書き、空ヒット時の発話と人へ切替を一文ずつ決めます。

まとめ

RAGは、音声AIが社内の正解に基づいて話すための検索と生成の組み合わせです。電話では、短い根拠、短い回答、答えられないときの切替、更新とキャッシュの鮮度が品質を決めます。モデル名を追う前に、十問の正答ソースと音声短文を整えてください。プロンプト、遅延、割り込みの設計とセットで見直すと、案内全体が安定します。今日、十問の表を作るところから始めてみてください。

Callのプレイグラウンドで、音声AIの応答を試してみる

デモコンソールでは、着信をシミュレーションで体験できます。

関連記事