商品マスタ×RAGで「根拠ある提案」を作る

はじめに

接客AIで一番怖いのは、AIがそれらしい嘘をつくことです。「この商品は完全防水です」と自信たっぷりに言われて、実は違った、では信用を失います。

この記事では、モーターサイクル用品を扱うECサイトの接客AIで、AIの提案に根拠を持たせるために使ったRAG（検索拡張生成）の仕組みを解説します。商品マスタとナレッジベースという2種類の情報源を組み合わせ、「資料に書いてあること」だけを根拠に提案する設計です。

なぜ根拠が必要なのか

AI任せの提案の危うさ

LLMに商品名だけ渡して「おすすめして」と頼むと、それっぽい説明を生成してくれます。ただ、その説明が実際の商品仕様に合っている保証はどこにもありません。

だからこそ、提案の一つひとつに「どの資料に基づくか」という裏付けが必要でした。

2種類の情報源を使い分ける

根拠を支える情報源は、性質の違う2つを用意しました。構造化された商品マスタと、文章として蓄えたナレッジベースです。

「予算3万円以内で在庫のある黒いジャケット」は商品マスタの得意分野。「長時間走行で疲れにくいのはどれか」はナレッジベースの出番です。両方あって初めて、絞り込みと説明の両方に根拠が持てます。

ナレッジベースを作る

PDFやWeb情報をテキスト化する

ナレッジベースの元ネタは、商品の取扱説明書PDFやメーカーのWeb上の商品情報です。これらをまずテキスト抽出し、検索できる形に整えます。

このパイプラインを通すことで、バラバラだった商品資料が「意味で検索できる知識」に変わります。

pgvectorにベクトルを保存する

変換したベクトルは、Neon Postgresの拡張機能であるpgvectorに保存しています。ベクトル専用の別サービスを立てず、既存のPostgres上で完結できるのが利点です。

商品マスタと同じデータベースに置けるので、「この商品説明のチャンクは、どの商品のものか」という紐づけが素直に表現できます。運用がシンプルになり、Vercel環境との相性も良好でした。

チャンクの粒度を調整する

チャンクは小さすぎると文脈が切れ、大きすぎると検索精度が落ちます。取扱説明書は見出しや項目でまとまっていることが多いので、その区切りを意識しつつ、数百文字程度を目安に分割しました。

粒度が適切だと、「ベンチレーション機構について」といったピンポイントな質問にも、該当箇所だけを的確に引ける。ここは商品資料の性質を見ながら調整する部分です。

提案に根拠を組み込む

検索してから生成する

提案を作るとき、AIはいきなり文章を書きません。まずお客様の要件でナレッジベースを検索し、見つかったチャンクだけを材料に説明を組み立てます。これがRAGの基本発想です。

「取扱説明書によると」という一言が添えられるかどうかで、提案の信頼度はまるで変わります。

商品マスタで事実を固める

価格・在庫・バリアントといった動かせない事実は、ナレッジベースではなく商品マスタから直接引きます。ここはRAGに委ねず、Shopifyから同期した正確なデータで押さえるのが安全です。

さらに、身体寸法から適切なサイズを割り出すサイズ提案ロジックも商品マスタ側と連携させています。試着できないECで「あなたにはこのサイズ」と言い切れるのは、正確なマスタがあってこそです。

見つからないときは正直に言わせる

RAGのもう一つの効用は、検索でヒットしなければ「分かりません」と言えることです。プロンプトで「検索結果にない情報は答えないように」と縛ることで、無理に作話させません。

まとめ

根拠のある提案を作るために取り組んだのは、次の3点です。

1. 2つの情報源 — 商品マスタで事実を固め、ナレッジベースで意味的に検索する
2. RAGのパイプライン — テキスト抽出・チャンク化・Embedding・pgvector保存で知識化する
3. 作話させない — 検索結果を根拠にし、なければ正直に「分からない」と言わせる

こうして作った根拠のある提案を、お客様にどう見せて納得してもらうか。比較表やチャートによる可視化は「比較表・チャートで提案を可視化するUX」で、要件を聞き取る対話設計は「ヒアリング対話の設計と状態管理」で解説しています。