本番運用のRAG：実際の顧客が質問を始めた瞬間に壊れるもの

動作するRAG（Retrieval-Augmented Generation）のデモは半日で作れます。いくつかの文書をベクトル化し、ベクトルストアに入れ、コサイン類似度で上位5チャンクを取得し、プロンプトに貼り付ける。質問に答えます。画面録画で見れば魔法のようです。

それを実際の顧客の前に置いた瞬間、隔たりが口を開けます。

誰かが、対応している3番目の言語で質問します。誰かが、自社サイト上に矛盾する2つのバージョンで存在するポリシーについて尋ねます。誰かが、コンテンツが本当にカバーしていないことを尋ね、システムはそれでも答えます——流暢に、自信ありげに、間違って。再クロールが走っている最中に20人が同時に質問します。入力ではなくスキャンで作られたPDFが検索ノイズとなり、その周辺の回答を静かに汚染していきます。

これらはデモには一切現れません。デモではきれいな文書、単一言語、単一ユーザー、そして作った本人が答えを知っている質問しか使わないからです。RAGでコストがかかる部分はすべて、この2つの状況の間の距離に住んでいます。

本記事はその距離についての話です。RAGが何かはすでにご存じである前提で進めます。まだであれば、まずRAGチャットボットとは何か、どう動くのかを読んでから戻ってきてください。ここから先はその上の層——検索システムが実ユーザーとの接触に耐えられるかどうかを決めるエンジニアリングです。

コンテキストウィンドウが大きくなるたびに、誰かがRAGの終わりを宣言します。しかしそうはなりませんでした。理由は一時的なものではなく構造的です。

実用的なコンテキストは、公称のコンテキストより小さい。 20万トークンを受け取れるモデルが、その20万すべてに対して同じ質で推論できるわけではありません。この効果はよく知られています。2023年のLiuらの論文「Lost in the Middle」は、長い入力の中央に埋もれた情報で精度が落ちることを示し、以後の長文脈モデルはどの世代も同種の但し書きを付けて出荷されています。品質はハードリミットより先に劣化します。しかも中堅企業の実際のナレッジは200ページではなく、数万ページ規模です。

ファインチューニングは振る舞いを変えるが、知識は変えない。 これはこの分野で最も高くつく誤解です。ファインチューニングは、形式・トーン・推論パターンを教えるには優れています。しかし事実を教える手段としては弱く、信頼できず、事実が変われば急速に劣化します。そして価格、ポリシー、在庫の事実は毎週変わります。

コストが逆方向にスケールする。 全コーパスを毎リクエストに詰め込むということは、質問のたびに全コーパス分を支払うということです。検索なら、関連する数千トークン分だけを支払います。現実のメッセージ量では、この差がそのまま利益率です。

監査可能性は機能ではなく要件。 金融・医療・法務では、出典をたどれない回答は使えません。検索はその痕跡を無料で生みます。どの一節がどの文書から来たかを、システムがすでに知っているからです。

つまり本当の論点はもはや「検索すべきか」ではありません。「なぜこれほど多くの検索システムが下手なのか」です。

回答が悪くなる最大の原因は、モデルでもエンベディングでもベクトルDBでもありません。コーパスです。

ある顧客のナレッジベースでは、文書のおよそ半分がもう半分のほぼ重複でした——同じポリシーが、わずかな書式差でマーケティングサイト、ヘルプセンター、アーカイブされたPDFに再掲載されていたのです。検索は忠実に5チャンクを返しましたが、それは同じ段落の5つのコピーでした。モデルは5つの視点ではなく1枚の狭い証拠を見ることになり、top-kの予算は冗長性に費やされました。これを直すのは、地味で手作業のデータパイプライン仕事でした。それでもその月に行ったどの検索チューニングよりも回答品質を改善しました。

常習犯はこれです。

• スキャンPDFとOCR破損。 人間の目にはきれいに読めるテキストでも、構造的にはズタズタなことがあります。段組の順序が入れ替わり、表が単語のスープに潰される。壊れたテキストのエンベディングは予測不能な形で検索されます。
• 定型文と同意バナー。 素朴にクロールすると、どのページも同じCookie通知、同じナビ、同じフッターを抱えます。すると全チャンクが長い同一の接頭辞を共有し、無関係なページ同士の意味的類似度が上がります。だから当社のクローラーは、何かをインデックスする前に同意バナーと共通枠を除去します。
• ログイン壁と中身の薄いページ。 ログインページにもテキストはあるので、素朴なパイプラインはそれを取り込みます。何も足さず、すべてを薄めます。
• 誰も気づいていない矛盾。 2つのページが異なる返品期限を書いている。検索は両方見つける。モデルはどちらかを選ぶ。どちらを選んでも、誰かが誤った案内を受け取ります。

実務上の原則：品質ゲートはインデックス作成の前に、コードベースのただ1か所に置き、コンテンツを追加しうるすべての経路がそこを通ること。取り込みルールが3か所に散らばると必ず乖離し、オンボーディング経由と再クロール経由の品質差は、誰にも再現できない謎になります。実践編はきれいなナレッジベースの作り方をご覧ください。

単一の密ベクトル検索は、検索の第一稿にすぎません。本番の検索は4〜5段のパイプラインであり、各段が他の段では届かない故障モードを潰します。

クエリ拡張。 実際のユーザーのクエリは短く、綴りが揺れ、社内略語だらけです。埋め込む前に同義語と展開した略語でクエリを拡張すると、再現率が測定可能なほど改善します。とくに、実際のチャット流量の大半を占める2〜3語の質問で効きます。

ハイブリッド検索：密＋疎。 密なエンベディングは意味を捉えますが、完全一致のトークンを取り逃します。品番、エラーコード、型番、人名などです。キーワード検索（当社ではPostgresのtsvector上のBM25）はそこを的確に当て、言い換えを取り逃します。両方を走らせ、Reciprocal Rank Fusion（RRF）で融合するのは最適化ではなく、本番の既定構成です。

本来以上に重要な細部が1つあります。キーワード検索は言語依存だということです。Postgresは、そのテキストが英語だと伝えたときにだけ「prices」を「price」に語幹化します。トルコ語、ドイツ語、スペイン語、フランス語、イタリア語、ポルトガル語はそれぞれ固有の設定を必要とし、組み込みのステマーがない言語——日本語、韓国語、中国語——には、偶然ではなく意図的なフォールバックが必要です。すべてのクエリを英語として語幹化する多言語RAGは、他のすべての言語で静かに再現率を失います。複数市場を相手にしているなら、この節と合わせて多言語チャットボットのガイドもお読みください。

リランキング。 融合の結果、もっともらしい候補が20〜30件残ります。cross-encoder型のリランカーは各候補を実際のクエリに対して採点し、本当に正しい一節を15位から上位3位へ日常的に引き上げます。「ほぼ正しいページばかり引用する」なら、まず疑うべきは欠けているリランク段です。

キャッシュは慎重に。 同一の質問でパイプライン全体を再実行する必要はありません。ただしキャッシュするのは検索結果（クエリ＋top-kをキーに）であり、生成された回答ではありません。さもないと、元の文書を更新した後に古い回答を配信してしまいます。

真剣なRAGシステムは、生成の前に検索結果を採点し、そのスコアで「このコンテキストをどこまで信じてよいか」をモデルに指示します。そのまま答える、留保をつけて答える、あるいは答えずに人へ引き継ぐ。これは存在する中で最も重要なハルシネーション対策です。

同時に、最も間違っている可能性が高い設定でもあります。既定値はたいてい測定されたものではなく、思いつきで決められているからです。

学ぶ価値のある失敗を1つ——私たち自身のものです。当社の「高確信度」しきい値はコサイン類似度0.82に設定されていました。いかにも厳格に聞こえる数字です。ところが実トラフィックで検証すると、実際の応答のうちこれを超えたものは2%未満でした。密な意味的一致は、取得した一節が誰の目にも完全に正しい場合でさえ、おおむね0.80を超えることは稀なのです。つまりモデルはほぼ毎回「このコンテキストは部分的にすぎない」と告げられ、身構えていました。正しい回答が不要な曖昧さに包まれていたわけです。検索は問題なかった。壊れていたのは物差しでした。

直し方は「全部ゆるめる」ではありませんでした。曖昧な帯域にある実会話のサンプルを引き出して読みました。0.64〜0.68の回答は具体的で正しく、プラン上限やポリシー規定を正確に引用していました。一方で本物の欠落——当社が対応していない連携についての質問——も同じ帯域に落ち、正しく留保していました。そこで、高しきい値を実際の一致が到達できる水準まで下げ、曖昧な中間帯は「部分的」のまま残し、最下段の「捏造禁止」ガードはそのまま維持しました。

持ち帰れる教訓：しきい値は直感ではなく自分の分布に対してキャリブレーションすること。調整対象の帯域にある実会話を実際に読むこと（集計スコアは、良い回答と高得点の外れを区別してくれません）。そしてすべてのしきい値を環境変数にすること。そうすればキャリブレーション失敗はデプロイではなく1分のロールバックで済みます。

チャンク分割は書式上の判断に見えます。実際には検索上の判断であり、「ドキュメントに確実に書いてあることをボットが見つけられない」という苦情の驚くほど多くがここから生まれます。

500トークンごとの固定長分割は、表を真っ二つにし、見出しをそれが導く段落から切り離し、番号付き手順を2つのチャンクに割って、どちらも単独では使えなくします。構造を意識した分割——まず見出しと段落境界を尊重し、次に目標サイズへ向けて結合し、長い区間は文の境界で切る——は実装に1日かかりますが、すぐに元が取れます。当社のパイプラインは1チャンクあたり約800トークン、重なり200トークンを目安にしています。文章主体のビジネスコンテンツには妥当な出発点です。

より微妙な問題は、チャンクが切り離された時点で、それを意味あるものにしていた文脈を失うことです。「標準配送は3〜5営業日です」は、誰の配送か、どの地域か、どの製品ラインかがチャンクに書かれていなければ、検索対象として無価値です。単独で取得されれば、モデルはまったく別の質問に当てはめかねません。

解決策は、埋め込む前に各チャンクを自身の出自で補強することです——文書タイトル、セクション見出し、出典。そうすれば埋め込まれたテキストは、人間の読者ならページ全体から得ていた文脈を持ち歩けます。Anthropicはこの考え方を「contextual retrieval」として広め、検索失敗の大幅な減少を報告しています。価値を得るのにLLMのパスは必須ではありません。文書自身のメタデータから組み立てた決定論的な接頭辞で、限界費用ゼロのまま利益の大半を回収できます。当社が本番で動かしているのもこれです。

経験からの警告：チャンク分割や文脈付与の方針を変えたら、それは移行作業を抱え込んだということです。既存のチャンクはすべて旧方式で埋め込まれています。文書単位の狙いを定めた再インデックスを計画してください——本番コーパスの盲目的な一括再埋め込みは決してしないこと。

チームが議論するのは検索品質です。しかし実際にシステムを倒すのは信頼性です。

取り込みは、長時間・多段階・一部外部依存のプロセスです。取得し、抽出し、分割し、埋め込み（レート制限に当たりうる有料API呼び出し）、書き込み、完了を記録する。ネットワーク境界をまたいで数分走るものは必ず中断されますし、その中断は珍しくありません。

最も学びの多かった障害は、静かに起きました。あるユーザーがサイトのクロールを開始し、その後ページを離れました。リクエストを処理していたサーバーレス関数は飛行中に停止されました——チャンクとエンベディングが書き込まれた後、しかし文書が「処理済み」と記録される前に。例外なし。監視にもエラーなし。あるのは、完全にインデックス済みなのに永久に「インデックス中」と表示される文書と、バッジを変えようと19時間で同じサイトを4回クロールし直し、そして去っていったユーザーだけでした。

この種のバグは、盗む価値のある3つの不変条件を教えてくれました。

• ユーザーに見える真実を最初に確定するよう書き込み順序を設計する。 コンテンツが永続化された直後に処理済みフラグを立て、統計・キャッシュ無効化・その他の帳簿付けは後回しにし、それぞれ時間上限付きのベストエフォートにする。実際の作業と、それを記録するフラグの間に任意の工程を挟まないこと。
• すべてのジョブハンドラを冪等にし、そのうえで積極的に再キューする。 ワーカーが途中で死んだら、次のスイープがジョブ全体を安全に再実行できなければなりません。「削除してから挿入」型のハンドラは再試行を無料にします。
• 自己修復スイープを足す。 未完了状態で固まった文書を探して再キューする定期ジョブは、恒久的でユーザーに見える障害を数分の遅延に変えます。RAGパイプラインで最も投資対効果の高い信頼性施策であり、そしてほぼ誰も、痛い目を見るまでは作りません。

同時負荷に備えて、退屈なインフラも足してください。投げっぱなしのPromiseではなく本物のキュー、埋め込み呼び出しが接続を掴み続けることを見込んだコネクションプール上限、そして1社の900ページのクロールが他社のライブチャットを飢えさせないためのテナント分離です。

RAGの品質は目視では測れません。どのチームも測れると思っていて、どのチームも間違っています。悪いRAGの故障モードは、流暢で、もっともらしく、整った書式の——たまたま誤っている回答だからです。良い回答とまったく同じように読めます。

実用最小限の評価環境は、恐れられているほど大きくありません。

ゴールデンセット。 正解が分かっている実際の質問を30〜100件、作り物ではなく実際のサポート履歴から抽出します。検索・チャンク分割・プロンプト・モデルバージョンを変更するたびに再実行してください。これは回帰テストであり、大きな音を立てて失敗すべきものです。

検索の採点と回答の採点を分ける。 品質が落ちたとき、正しい一節が取得されなかったのか、取得されたのに無視されたのかを知る必要があります。対処法はまったく異なり、単一のエンドツーエンドスコアでは区別できません。

確信度の分布を時系列で監視する。 検索スコアのヒストグラムのずれは早期警報です。たいていは誰かが低品質コンテンツをまとめて追加したか、トラフィックがコーパスの守備範囲外の話題へ移ったかです。

「わかりません」を最も価値あるテレメトリとして扱う。 低確信度の回答も人への引き継ぎも、すべてラベル付きのコンテンツギャップです。数か月かけてアシスタントが目に見えて良くなるチームは、ほぼ例外なく、そのリストを毎週読んで足りないページを書いているチームです。チャットボット分析のガイドで追うべき指標を解説しています。

そして自己解決率は正直に測ってください。会話は、顧客が入力をやめたから解決したのではありません。1時間後にメールを送ってこなかったから解決したのです。この2つの出来事を結びつけられないプラットフォームを使っているなら、あなたは自分を喜ばせるだけの数字を最適化しています。

アーキテクチャがまったく同じ2つのRAGが、同じ業界で片方は成功し片方は失敗します。違いはたいていパイプラインの中にはありません。

ドメイン言語は本物の作業です。 医療の略語、金融商品名、法律の引用形式、品番の付け方は、それぞれ固有の形で汎用検索を壊します。金融の顧客が「3年もの」と尋ねるとき、それは特定の商品を指していますが、汎用エンベディングは時間について考えます。これは同義語辞書、メタデータフィルタ、そして人間だけでなく機械にも読ませるつもりで書かれたコンテンツで直します。大きなモデルでは直りません。

スコープの規律は能力に勝ります。 アシスタントへの信頼を最速で破壊する方法は、実際には知らない領域の質問に答えさせることです。明示的な境界——このエージェントは自社の製品・ポリシー・ドキュメントについて答え、それ以外は引き継ぐ——は、どんな検索改善よりも恥ずかしい回答を減らします。これは、実際のアシスタントが一般論の泥沼へ漂流するのを見たあとに私たちが投入した修正でもあります。

定着は公開の前提条件です。 サポートチームに知らされていないアシスタントは、そのサポートチームによって足を引っ張られます。コンテンツギャップを持ち主として引き受け、引き継ぎを読み、アシスタントが何を約束してよいかを決める人が必要です。

企業の信頼にはチェックリストがあります。 誰が尋ねているかを検索が尊重するためのロールベースアクセス、どの出典がどの回答を生んだかを示す監査証跡、明確なデータ所在地、保持期間の制御、そして顧客の会話を公開モデルの学習には使わないという曖昧さのない言明。これらはセキュリティレビューの後に足す機能ではありません。レビューを通るか落ちるかの理由そのものです。チャットボットのセキュリティとプライバシーのガイドで、ベンダーに何を確認すべきかを説明しています。

社内で作るなら、正直なスコープは「ベクトルDBとプロンプト」ではありません。コンテンツ品質ゲート、多段の検索パイプライン、キャリブレーション済みの確信度しきい値、冪等ハンドラと自己修復スイープを備えたジョブキュー、評価ハーネス、分析ループ——そしてそれら全部の継続的な運用です。検索品質そのものが製品であるなら、やる価値があります。検索が「顧客の質問に答える」ための手段にすぎないなら、小さなチームの1年の使い方としては筋が悪いでしょう。

購入するなら、この記事のチェックリストがそのままデューデリジェンスの質問集になります。ベンダーにこう聞いてください。ハイブリッド検索ですか、密のみですか。リランク段はありますか。「わかりません」のしきい値はどう決まり、私が変更できますか。取り込みが途中で中断したら文書はどうなりますか。ある回答をどの出典が生んだか確認できますか。私の言語ではキーワード検索はどう扱われますか。先週アシスタントが答えられなかった質問は何ですか。これらに答えられないベンダーが作ったのはデモです。

この層こそ、Chatloomが引き受けるために存在する領域です。本記事で説明したパイプライン——文脈補強を伴う構造認識チャンク分割、クエリ拡張、言語を意識した語幹化を備えた密＋疎のハイブリッド検索、RRF融合、cross-encoderリランキング、本物の「わかりません」を持つキャリブレーション済み確信度、自己修復スイープ付きの冪等な取り込みジョブ、そして未回答の質問を正確に見せるダッシュボード——が、プラットフォーム上のすべてのエージェントの背後で、10言語で、あなたの側にML チームがなくても動いています。

今日、あなた自身のコンテンツで試してください。 無料アカウントを作成し、サイトのURLを貼り付けて、この記事を読むのにかかったのとほぼ同じ時間で全ループ——クロール、品質ゲート、チャンク分割、埋め込み、ハイブリッド検索——が走るのをご覧ください。顧客が実際に尋ねる5つの質問をぶつけてみてください。回答が自社コンテンツに根拠を持ち、知らないことは知らないと認めるなら、それがあなたの評価結果です。無料プランにカードは不要です。

先に詳細を知りたい方は、当社のRAGエンジンの仕組みをご覧いただくか、実践編の自社データでアシスタントを学習させる方法をお読みください。