① ドキュメントを「そのまま」埋め込んでいる
もっとも頻発するのが、PDFやWordをそのままチャンク分割して埋め込んでしまうケース。図・表・見出し階層が壊れた状態でVector DBに突っ込まれているので、検索もブレ、回答品質も上がりません。
対策：前処理に時間をかける。具体的には——
- レイアウト保持で構造化（見出し・段落・表をMarkdown／HTMLに正規化）
- 表は別チャンクとして抽出し、表名・列名をメタデータに付与
- 長文ドキュメントは見出し単位で分割し、「親見出し」を子チャンクに継承
② チャンクサイズを"なんとなく"決めている
チャンクサイズ500トークン、オーバーラップ50——のような既定値で進めるとほぼ確実に痛い目を見ます。業務文書はジャンルによって「意味のまとまり」が違うため、一律設定が機能しません。
対策：「業務単位」で評価して決める。
- マニュアル系：短め（200〜400トークン）で見出し単位
- 議事録系：会話のターン単位
- 契約書系：条文単位（条→項→号）
- 長文レポート：要約と詳細の二段構え（Parent-Childリトリーバル）
Tips — 評価データセットを最初に作る
「想定質問 × 期待される根拠ドキュメント」のセットを最低30件、できれば100件作ってから設計に入る。これがないと、チャンクサイズの議論が"感想戦"になります。
③ Vector検索だけで戦おうとしている
意味検索（Vector）は強力ですが、固有名詞・型番・コード・略称には弱い。「型番A-2030の修理手順」のような問い合わせでは、BM25（全文検索）の方がはるかに当たります。
対策：Hybrid Search を最初から組み込む。BM25とVectorの両方で候補を取得し、Rerankerでマージするのが現状のベストプラクティス。
// 概念的なフロー
const bm25Hits = await searchBM25(query, k=20);
const vecHits = await searchVector(query, k=20);
const merged = uniqueById([...bm25Hits, ...vecHits]);
const reranked = await rerank(query, merged, topK=5);
return reranked;④ Rerankerを使っていない
初期実装で「Top-5をそのまま渡す」をやると、文脈に合っていない断片がLLMに渡り、回答品質が崩れます。Rerankerは費用対効果が極めて高い投資のひとつ。
対策：Cohere Rerank・BGE Reranker・自前ファインチューニングモデルなど、用途に合わせて選定。100ms程度のレイテンシ増で、Top-5の品質が2段階上がります。
⑤ 引用元（出典）が表示されない／嘘の出典が出る
業務RAGの最重要要件は「出典の正確な表示」。これがないとユーザーは検証できず、結局使われなくなります。生成された回答に対して、「どのチャンクを引用したか」を確実にトラッキングする必要があります。
対策：
- チャンクごとに一意ID＋ドキュメント名・ページ番号をメタデータ保持
- プロンプトで「引用したチャンクIDを必ず返せ」と指示
- 引用IDが存在しないものは生成後にバリデーション、無効なら再生成
- UI上で出典ドキュメントへの直接リンクを提示
出典が表示されていないRAGは、業務では使われません。「答えは生成できているのに、信用できないから結局オリジナル資料を読み直す」——これがPoCで終わるパターンの典型です。
⑥ 評価が「目視レビュー」止まり
PoC段階で「いい感じに動いてますね」で進めると、本番で必ず崩れます。評価ハーネス（テストセット＋自動評価）を最初から組み込まない限り、改善のループが回りません。
対策：下記4軸で評価する仕組みを最初に作る。
- Retrieval評価：Recall@K（期待ドキュメントが上位K件に入っているか）
- Faithfulness：回答が引用ドキュメントに根拠を持っているか（LLM-as-a-Judge）
- Answer Relevance：回答が質問の意図と一致しているか
- Citation Accuracy：引用IDが実際に該当箇所を指しているか
⑦ 権限と監査ログを後付けしようとする
「部署外秘の文書が他部署のメンバーに見えてしまった」——これが起きるとプロジェクトは即停止します。権限と監査ログは設計段階から組み込むべき機能です。
対策：
- ドキュメントごとに ACL（アクセス制御リスト）をメタデータに保持
- 検索時にユーザーの所属・役職でフィルタ
- クエリと回答、引用ドキュメントの全履歴を監査ログに保存
- 定期的に「誰がどの機密情報にアクセスしたか」を情シスへ自動レポート
まとめ — 業務RAGの"勘所"
業務RAGは「LLMをつなぐ」より、「データを整え、検索を整え、評価を整える」部分の比重が圧倒的に大きい。逆に言えば、ここを諦めなければ、社内ナレッジが"動く資産"に変わるところまで持っていけます。
MU AI事業部では、RAG構築・運用代行・内製化トレーニングまでを一貫で提供しています。「自社データでどこまで動くか」をPoCで見たい方は、初回ヒアリングからお気軽にご相談ください。