RAGは“データを入れれば答える”ほど単純ではない

公開日：2026年6月1日

RAG（Retrieval-Augmented Generation）という言葉を聞くと、社内資料やマニュアルを入れておけばAIが賢く答えてくれる仕組み、というイメージを持たれがちです。 ただ、SiMa RAGサーバーのデモを準備する中で強く感じたのは、RAGは“データを入れたらすぐ使える”ほど単純ではないということでした。 実際には、AIモデルそのものよりも、どのようなデータを、どのような形に整えて、どのように検索させるかが、回答品質を大きく左右します。

目次

• 1. RAGがうまくいかないとき、原因はモデルではなく“データの持たせ方”にある
• 2. PDFやMarkdownを入れれば終わり、ではなかった
• 3. 一番悩ましかったのは、どこで文書を区切るかだった
• 4. “検索件数を増やせば良い”わけでもない
• 5. 日本語文書では、さらに気をつける点が多い
• 6. RAGの調整は、モデルの調整より地道で、でも効果が大きい
• まとめ

1. RAGがうまくいかないとき、原因はモデルではなく“データの持たせ方”にある

RAGでは、ユーザーの質問に対して関連する文書を検索し、その内容をもとにLLMが回答を生成します。 しかし検索で引っかかった文書が適切でなければ、その後のLLMがいくら優秀でも答えは簡単にずれてしまいます。 質問と関係が薄い文章を拾う、欲しい説明の途中だけが切り出される、前提条件が抜ける、似た単語に引っ張られて違うトピックを参照してしまう──こうしたことはRAGでは珍しくありません。 つまりRAGは「AIが答える仕組み」というより、「必要な文脈をどれだけ正しく渡せるかの仕組み」と言った方が実態に近いと感じました。

2. PDFやMarkdownを入れれば終わり、ではなかった

デモ準備の段階では、とりあえず文書を入れればそれなりに答えるのではないか、と考えがちです。 ですが実際には、PDFやMarkdownをそのまま投入するだけでは期待した品質にはなかなか届きませんでした。 人間はPDFを見れば見出し・本文・注釈・表・箇条書きを自然に読み分けられますが、RAGの検索対象として取り込む段階ではその構造が崩れてしまうことがあります。 その結果、見出しと本文の対応が曖昧になる、本来セットで読むべき文章が分断される、表や箇条書きが不自然なテキスト列になる、といった問題が起き、検索精度や回答品質に影響しました。 文書の中に正しい情報が存在していても、それが検索でうまく引けなければLLMはその情報を使えません。つまり「資料に載っている」ことと「答えられる」ことは別でした。

【被災地デモ環境で検証した生成AIの画面例】

3. 一番悩ましかったのは、どこで文書を区切るかだった

RAGの品質を左右する要素のひとつに、チャンク設計があります。これは文書をどの単位で分割して検索対象にするか、という考え方です。 文書を細かく切りすぎると、検索には引っかかりやすく見える反面、回答に必要な前後関係まで失われます。条件文だけが残って結論がない、手順の一部だけが出てきて全体像が分からない、なぜそうなるかの説明が抜ける、といった形になりやすく、結果として回答が薄くなります。 逆に大きくまとめすぎると、必要な情報があってもノイズが多くなり、関係ありそうで実は遠い文章が拾われる、質問の焦点に対して回答がぼやける、必要な箇所が埋もれる、といった問題が出てきます。 このバランス調整は想像以上に難しく、RAGの出来を左右する核心部分でした。

4. “検索件数を増やせば良い”わけでもない

RAGでは、質問に対して関連文書を何件取り出すかという設定も重要です。 一見すると、検索件数を増やせば取りこぼしが減って精度が上がりそうに思えますが、実際には単純に件数を増やすだけでは逆効果になることもありました。 関連度の高い文書に加えて、やや近いだけの文書まで大量に渡してしまうと、LLMがどの情報を中心に答えるべきか分かりにくくなります。 その結果、回答が冗長になる、余計な話題が混ざる、本来の答えがぼやける、といった現象が起きやすくなります。 RAGは「たくさん渡せば賢くなる」仕組みではなく、「必要な情報を、必要なだけ渡す」ことが大事な仕組みでした。

5. 日本語文書では、さらに気をつける点が多い

今回のデモでは日本語で自然に答えることも重視していたため、データ整形の難しさはさらに増しました。 日本語文書は、見出しと本文の境目が曖昧なことがある、主語が省略されやすい、箇条書きや表に意味が圧縮されている、文脈依存が強い、といった特徴があり、単純にテキスト化しただけでは意味のまとまりが崩れやすい場面があります。 そのため、どの単位で意味が完結しているか、見出しをどこまで残すか、箇条書きと本文をどうつなぐか、回答に必要な背景情報をどこまで一緒に持たせるかを意識して整える必要がありました。 ここを雑にすると、検索結果はそれっぽいのに、最終回答がどこか不自然、あるいは少しずれている、という状態になりやすいです。

6. RAGの調整は、モデルの調整より地道で、でも効果が大きい

AIデモというと、どのモデルを使うか、どのくらい高速か、どれだけ賢そうに見えるかに目が向きがちです。 もちろんそれらも大事ですが、今回の経験では実際に回答品質を押し上げたのは、モデル差以上にRAGデータの整え方でした。 文書構造を崩しすぎない、チャンクの切り方を見直す、検索件数を調整する、ノイズになりやすい部分を整理する、質問と検索結果の噛み合い方を確認する。 こうした一つひとつは地味ですが、積み重ねることで「答えが出る」から「納得できる答えが返る」へと変わっていきました。 RAGは派手な技術に見えて、実際にはかなりデータ整備型の技術なのだと思います。

まとめ

SiMa RAGサーバーのデモ構築を通じて分かったのは、RAGは決して「データを放り込めば自動で賢くなる」仕組みではないということでした。 本当に重要なのは、LLMに答えさせることそのものではなく、LLMが答えやすい文脈を検索で適切に渡せるようにすることです。 そのためには、文書構造の理解、チャンク設計、検索件数の調整、日本語文書の整形、回答品質の確認と改善といった、地道な設計と検証が欠かせません。 RAGの本質は、知識をどう整理して渡すかという設計力にあり、そこを丁寧に詰めていくことが、デモを「動くだけ」から「使えそう」へ引き上げる一番大きな差になるのだと感じました。

【展示会でのRAGデモ展示の様子】