Portfolioはじめに
「社内でAIを使いたい」と考えたとき、最初に思いつくのはChatGPTをそのまま使うことではないでしょうか。確かに手軽ですが、業務で使う場合には大きな問題があります。
この記事では、なぜ私が**RAG（Retrieval-Augmented Generation：検索拡張生成）**というアプローチを選んだのか、その理由と仕組みを解説します。
ChatGPTをそのまま使う問題点
ハルシネーション（幻覚）のリスク
ChatGPTは非常に賢いAIですが、「知らないこと」を聞かれると、それらしい嘘をつくことがあります。これを**ハルシネーション（幻覚）**と呼びます。
| シーン | ChatGPTの問題 |
|---|---|
| 社内規定について質問 | 一般的なルールを答えてしまう（御社の規定とは異なる） |
| 過去の対応事例を聞く | 架空の事例を作り上げてしまう |
| 商品の価格を聞く | 適当な価格を答えてしまう |
業務で使う場合、「AIが言ったから」という理由で誤った対応をしてしまうリスクがあります。
根拠が示せない
もう一つの問題は、回答の根拠を示せないことです。
「なぜそう言えるのか？」と聞かれても、ChatGPTは「私の知識によると」としか答えられません。業務では「どのマニュアルに書いてあるのか」「過去にどんな対応をしたのか」という根拠が必要です。
RAG（検索拡張生成）とは
基本的な考え方
RAGは、AIが回答する前にまず関連情報を検索する仕組みです。
ユーザーが「〇〇について教えて」と質問
データベースから関連するドキュメントを検索
検索結果をAIに渡し、それを元に回答を作成
「〇〇のマニュアルによると...」と参照元付きで回答
ポイントは、AIが「自分の知識」ではなく「検索で見つけた情報」を元に回答することです。
ChatGPTとの違い
| 観点 | ChatGPT単体 | RAG |
|---|---|---|
| 回答の根拠 | AIの学習データ（不明確） | 検索で見つけたドキュメント（明確） |
| 最新情報 | 学習時点の情報のみ | データベースを更新すれば反映 |
| 社内情報 | 知らない | データベースに入れれば回答可能 |
| ハルシネーション | 起きやすい | 検索結果がなければ「わからない」と言える |
なぜ「検索」と「生成」を分けるのか
「AIに全部任せればいいのでは？」と思われるかもしれません。しかし、検索と生成を分けることには明確なメリットがあります。
検索フェーズでは、質問に関連する情報を確実に見つけます。これはAIの「創造性」ではなく、データベースの検索機能で行います。
生成フェーズでは、見つけた情報を元に分かりやすく回答を作成します。ここでAIの文章生成能力が活きます。
この分業により、「根拠のある、読みやすい回答」が可能になります。
ベクトル検索の仕組み
従来の検索との違い
従来の検索（キーワード検索）は、入力した単語が含まれる文書を探します。しかし、これには限界があります。
| 検索方式 | 「返金したい」で検索した場合 |
|---|---|
| キーワード検索 | 「返金」という単語を含む文書のみヒット |
| ベクトル検索 | 「キャンセル」「払い戻し」「返品」なども意味が近いとしてヒット |
ベクトルとは
ベクトル検索では、文章を**数値の配列（ベクトル）**に変換します。意味が近い文章は、数値としても近い値になります。
たとえば、以下の3つの文章があるとします。
- 「商品を返品したい」
- 「返金の手続きについて」
- 「天気が良いですね」
これらをベクトルに変換すると、1と2は数値として近く、3は遠くなります。質問が「払い戻しの方法は？」なら、1と2がヒットし、3はヒットしません。
Embeddingとは
文章をベクトルに変換する処理を**Embedding（埋め込み）**と呼びます。このプロジェクトでは、OpenAIのEmbedding APIを使用しています。
「返金の方法は？」
マニュアル、FAQ、対応履歴
[0.12, -0.34, 0.56, ...]
[0.11, -0.33, 0.55, ...]
類似度が高いものを取得
pgvectorの採用理由
PostgreSQLの拡張機能
ベクトル検索を行うには、ベクトルデータを保存・検索できるデータベースが必要です。このプロジェクトでは、pgvectorというPostgreSQLの拡張機能を採用しました。
| 選択肢 | 特徴 | 採用理由 |
|---|---|---|
| Pinecone | ベクトル検索専用のクラウドサービス | 別途契約が必要、コストがかかる |
| Qdrant | オープンソースのベクトルDB | 運用の手間がかかる |
| pgvector | PostgreSQLの拡張機能 | Neon DBで簡単に使える、Vercelとの相性が良い |
Neon PostgreSQLとの組み合わせ
Vercelが提供するNeon PostgreSQLは、pgvectorを標準でサポートしています。
- 追加設定なしでベクトル検索が使える
- Vercelプロジェクトとの統合が簡単
- サーバーレスで自動スケーリング
- 無料枠でも十分な性能
RAGの設計ポイント
チャンク分割
長いドキュメントは、適切なサイズに**分割（チャンク化）**する必要があります。
| チャンクサイズ | メリット | デメリット |
|---|---|---|
| 小さい（数百文字） | 検索精度が高い | 文脈が失われる可能性 |
| 大きい（数千文字） | 文脈が保たれる | 検索精度が下がる、トークン消費が増える |
このプロジェクトでは、**適度なサイズ（数百〜千文字程度）**でチャンク化し、必要に応じて複数のチャンクを取得することで、精度と文脈のバランスを取っています。
検索結果の件数
質問に対して何件の関連ドキュメントを取得するかも重要です。
- 少なすぎる：必要な情報が含まれない可能性
- 多すぎる：関係ない情報が混ざる、トークン消費が増える
このプロジェクトでは、上位5〜10件を取得し、AIが適切に取捨選択するようにしています。
プロンプト設計
RAGで重要なのは、AIへの指示（プロンプト）の設計です。
あなたは社内サポートアシスタントです。
以下の検索結果を参考に、質問に回答してください。
【重要なルール】
- 検索結果に含まれる情報のみを使って回答してください
- 検索結果にない情報は「わかりません」と回答してください
- 回答の根拠となった参照元を明示してください
【検索結果】
{検索で見つけたドキュメント}
【質問】
{ユーザーの質問}
このように指示することで、AIが「知らないことを知ったふり」をするリスクを減らせます。
まとめ
RAGを採用した理由は、以下の3点に集約されます。
- 根拠を示せる：「〇〇のマニュアルによると」と参照元を明示できる
- ハルシネーションを抑制：検索結果がなければ「わからない」と言える
- 最新情報に対応：データベースを更新すれば回答に反映される
AIは便利なツールですが、業務で使うには「信頼性」が必要です。RAGは、AIの能力を活かしながら、根拠のある回答を実現するアプローチです。