生成AI (大規模言語モデル: Large Language Model: LLM) に自社の業務や制度、ルールなどを語らせたり、お客様対応を任せるには、いくつか方式があると思います。
- LLM にユーザーメッセージとプロンプトで必要な情報を与えて回答を生成させる方式 (プロンプトエンジニアリングによる解決)
- LLM をトレーニングデータと検証データを用いてあらかじめ学習し、回答を生成させる方式 (機械学習: ファインチューニング: FT による解決)
- LLMにユーザーメッセージと、それに関連するデータを与えて回答を生成させる方式 (コンテキストエンジニアリングによる解決)
RAG は「ラグ」と呼ばれていますが、Retrieval-Augmented Generation (検索拡張生成) の略です。上記の 3. の方式を実現するものになります。
さて、本資料のタイトル「RAGパイプライン」とはなにか？ といいますと、RAGジャーニーと言いますか、RAGがユーザーに回答するまでの工程をご説明する必要があります。
- ユーザーの入力を受け付ける (「休暇の取得方法を教えて」)
- システムが 1. の入力を、データベースで検索可能な値に変換する (「休暇の取得方法を教えて」という自然言語を数値 (数千次元のベクトル値) に変換する)
- システムが 2. の検索クエリ (数千次元のベクトル値) を用いてデータベースに問い合わせを行う
- データベースから top-k (検索クエリとの類似性が高い順に n 件) の検索結果を取得する
-
- で得たユーザー入力と 4. で得た検索結果、その他必要に応じたプロンプトなどを LLM (Large Language Model：大規模言語モデル) に入力する
- LLM から返却された出力を、ユーザーに RAG の回答として画面に表示する (休暇の取得には勤怠管理システム (接続情報などが続く...) にログインし、メニューの「休暇の申請」を選択して必要事項を入力してください)
RAG はこのような処理を行うシステムです (実際にはもっと複雑な工程、例えば 2. で行なっているベクトル検索以外の検索手法を併用したり、6. で得られたユーザーへの回答を再評価して、回答として不十分と判断した場合の振る舞いを定義するなど行なっています)。
RAG はこのように、ユーザーへの回答に必要なデータを、あらかじめ DB に「検索可能な状態」で格納しておく必要があります。
このデータは、関連性の高い情報をまとめた「かたまり (チャンク)」として用意され、関連性が低い情報とは分割して管理することで、ユーザーの問い合わせに対して関連性が高い情報を使って回答することが可能になります。
これらの流れ (パイプライン) を、Ingestion (データ投入) と、Query (DB検索と回答生成) としてまとめたものが以下になります。
技術者向けの記載にはなりますが、ご参考になれば幸いです。 (RAG には教科書はありません。弊社ではこう考えています、という内容です)
Ingestion パイプライン(投入系)
| # | ステージ | 責務 |
|---|---|---|
| I1 | Load | ファイル/テキストの取り込み、ソースメタデータ付与 |
| I2 | Preprocess | 正規化(文字コード、空白、不要要素の除去) |
| I3 | Chunk | セクション見出し付き段落分割(500文字方式がベース) |
| I4 | Embed | エンベディングモデルによるベクトル化(複数モデルを切替・比較可能) |
| I5 | Index | ベクトルストア(PostgreSQL + pgvector)への登録 |
Query パイプライン(検索・生成系)
| # | ステージ | 責務 |
|---|---|---|
| Q1 | Query Transform | ユーザー入力から検索クエリを作る(素通し / LLMによる書き換えを選択可能) |
| Q2 | Retrieve | 多段検索(メタデータ+ベクトル / ベクトルのみ / 全文検索、recall-first) |
| Q3 | Context Build | 検索結果のリランク・整形・件数制御・ゼロ件判定 |
| Q4 | Generate | プロンプト組み立て + 閉域LLMによる生成(「生成で制御」の実体) |
| Q5 | Log | 全段トレーシング(クエリ・スコア・採否・応答・所要時間)→ 評価の基盤 |
I1. Load、I2. Preprocess
RAG に投入するデータを用意する工程です。
データが頻繁に変化し、その鮮度が重要な場合には、元データを直接参照する仕組みを設ける、など、お客様要件に従った機能を検討します。
I3. Chunk
RAG に投入するデータを分割する工程です。
検索する単位として、意味のある単位で分割することと、システムで取り扱い可能な文字数 (トークン) の範囲で分割しなければなりません。
お客様要件に従った自動処理や、区切り文字 (------ とか) を指定してもらって、そこで区切る、といった対応を検討します。
I4. Embed
データとして投入される自然言語を、ベクトル (数値) に変換する工程です。
この変換はプログラムを通じて実施され、これらのプログラムは Embedding model と呼ばれています。
| モデル | 発音 | 特徴 |
|---|---|---|
| bge-m3 | ビージーイー・エムスリー | 多言語対応の定番。MITライセンス |
| multilingual-e5-large | マルチリンガル・イーファイブ | bge-m3の最有力対抗馬。MITライセンス |
| Ruri | ルリ | 日本語の「瑠璃」由来 |
| PLaMo-Embedding | プラモ | Preferred Networks公式が「プラモ」と読んでいる |
| sarashina-embedding | サラシナ | 「更級日記」の更級が由来 |
| nomic-embed-text | ノミック | 英語中心だが多言語版あり |
| OpenAI text-embedding-3 | OpenAI（米国） | 高性能だがAPI経由のみなので閉域要件では使えない点に注意 |
| モデル | 開発元 | 補足 |
|---|---|---|
| bge-m3 | BAAI(中国) | dense/sparse/multi-vector を1モデルで出せる |
| multilingual-e5-large | Microsoft | 多言語対応で日本語性能も高い |
| Ruri | 名古屋大学（日本） | 日本製の日本語特化エンベディングモデル。日本語ベンチマーク（JMTEB）で上位。「国産」を求める顧客に最適 |
| PLaMo-Embedding | Preferred Networks（日本） | こちらも国産。PFNブランドはSIer系顧客に知名度あり |
| sarashina-embedding | SB Intuitions（ソフトバンク系、日本） | 日本語特化の国産モデル |
| nomic-embed-text | Nomic AI（米国） | 完全オープン |
I5. Index
ベクトル (数値) に変換されたデータを、データベースに格納する工程です。
今のところですが、PostgreSQL / pgvector への格納を想定しています。
Q1. Query Transform
ユーザー入力から検索クエリ (検索文字列) をつくる工程です。
この時に、ユーザーメッセージを加工なしで素通しするだけでなく、以下の用語で説明するような加工を行うことで、意図する情報を取得できるように調整していきます。
クエリ処理に関連する用語の整理
| 用語 | 発音 | 内容 |
|---|---|---|
| query rewriting | クエリ・リライティング | LLMでクエリを検索向きに書き換える。口語→明確な質問文、会話履歴を踏まえた代名詞の解決など |
| query expansion | クエリ・エクスパンション | 同義語や関連語を足して検索の網を広げる。「有給」→「有給休暇 年休 休暇申請」 |
| query decomposition | クエリ・ディコンポジション | 複合質問を分割。「AとBの違いと申請方法は？」→「Aとは」「Bとは」「申請方法」の3検索に |
| HyDE | ハイド | Hypothetical Document Embeddings。後述 |
| query routing | クエリ・ルーティング | クエリの種類に応じて検索先や処理方式を振り分ける |
HyDEだけ少し詳しく、発想が面白い手法です：質問文と回答文書は文体が違うので、ベクトル空間上で意外と遠いことがある。そこでLLMにまず仮の回答を生成させ、その仮回答をエンベディングして検索する。「質問で探す」のではなく「答えっぽい文章で答えを探す」わけです。仮回答の内容が間違っていても、文体と語彙が正解文書に近ければ検索としては機能する、という割り切り。
Q2. Retrieve
ユーザーメッセージとの類似性が高い情報を DB から取得する工程です。
ベクトル検索を行うため、ユーザーメッセージ (チャットにおけるユーザーの入力) をベクトル値に変換します。これには、データ投入時に採用した Embedding model を用いて変換する必要があります。
また、ベクトル検索で期待される検索が実現できない場合には、以下の用語にある手法や、データセットに対するメタデータの付与と検索条件を追加するなどの対応や、全文検索などの異なる検索方式の併用を検討することが考えられます。
検索方式に関連する用語の整理
| 用語 | 発音 | 意味 |
|---|---|---|
| dense retrieval | デンス・リトリーバル | ベクトル検索のこと |
| sparse retrieval | スパース・リトリーバル | キーワードベースの検索（BM25等） |
| BM25 | ビーエム・にじゅうご | 古典的なキーワードスコアリング。今も現役 |
| hybrid search | ハイブリッド・サーチ | dense + sparse の併用 |
| reranker / cross-encoder | リランカー / クロス・エンコーダー | 検索結果を精密に並べ替える後段モデル |
| cosine similarity | コサイン類似度 | ベクトル間の近さの計算方法。距離スコアの正体 |
| HNSW | エイチ・エヌ・エス・ダブリュー | pgvector 等のベクトルDBが内部で使う |
Q3. Context Build
検索結果のリランク、整形、件数制御、ゼロ件判定などを行う工程です。
Q4. Generate
Generate に関連する用語の整理
| 用語 | 発音 | 意味 |
|---|---|---|
| context augmentation | コンテキスト・オーグメンテーション | 取得チャンクをプロンプトに組み込むこと。RAGの「A（Augmented）」の正体 |
| grounding | グラウンディング | 回答を検索結果に「接地」させること。「グラウンディングされた回答」=根拠に基づく回答 |
| hallucination | ハルシネーション | LLMが事実にない内容を生成すること。RAG導入の最大動機の一つ |
| citation / attribution | サイテーション / アトリビューション | 回答に出典（どのチャンク由来か）を付けること |
| lost in the middle | ロスト・イン・ザ・ミドル | 長いコンテキストの中間部分をLLMが見落としやすい現象。チャンクの並べ順が効く理由 |
この工程では、どの LLM 実行環境を選択するかも重要となる。
reasoning model (推論モデル)
- DeepSeek
- gpt-oss
non-reasoning model (非推論モデル)
- Gemma
- Llama
- Qwen
Q5. Log
I1 から I5 の工程と、Q1 から Q4 の工程は、パイプラインとしてそれぞれ 1 つのまとまったログとして記録され、参照可能な状態である必要がある。
このために必要なログの生成を行う工程である。
この資料で取り扱っていないこと
RAG の回答に対する評価については、本資料では取り扱っていません。
評価としてまず最初に行われるのは、いくつか質問してみて、意図した回答が得られか確認するんだと思います。
意図した回答が得られなかった場合は、パイプラインを通じて問題箇所を特定することになりますが、その際に Q5. で記録しているログを確認する、というのが出発点になると思います。
実際の運用では、RAG の回答に対してユーザーが評価できる仕組みが必要になります。
どの程度のユーザーが満足しているか、という値を定量的に取得する仕組みが必要で、その値と目標値を近づけることが当面の課題になります。また、ユーザーの評価が低いケースを確認し、データやプロンプト、パイプラインそのものを追加、変更する「改善フロー」が必要になります。