10 万文档 RAG 落地实战：从 Demo 到生产，我踩过的所有坑

引言：RAG 为什么在企业级场景“必选但难用”

在过去一年里，RAG（Retrieval-Augmented Generation）几乎成了企业落地大模型的标准配置。

原因很简单：

• 企业数据高度私有，无法直接丢给大模型训练
• 业务知识更新频繁，微调成本高、周期长
• 需要“可控、可解释、可追溯”的回答来源

但当你真的把 RAG 从 Demo 推到生产，会发现三个问题几乎一定会出现：

• 文档一多，检索明显变慢
• 明明文档里有答案，模型却“搜不到”
• 本地 + 向量库 + 模型 + 服务，部署复杂度飙升

这篇文章不会再重复“RAG 是什么”这种内容，而是围绕一个真实企业级目标展开：

在 10 万级文档规模下，如何构建一个可用、稳定、可扩展的 RAG 系统。

技术原理：先把“为什么慢、为什么不准”讲清楚

RAG 的本质不是“问答”，而是信息检索系统

很多人理解 RAG 是：

向量检索 + 大模型生成

但在工程视角下，它更像一个搜索系统：

• 输入是自然语言查询
• 中间是召回 + 排序
• 输出是可供生成模型使用的“证据集”

如果你做过搜索或推荐系统，会发现很多问题是相通的。

为什么文档一多，检索就慢？

根本原因通常不是模型，而是三点：

• 向量数量膨胀，索引结构不合理
• embedding 维度过高，算力浪费
• 查询阶段做了太多不必要的全量扫描

在 10 万文档规模下，实际进入向量库的 chunk 往往是 50 万～300 万级别。

如果你：

• 使用 Flat 索引
• embedding 维度 1024+
• 没有分片或分区

那检索慢几乎是必然的。

为什么召回率低，明明“文档里有答案”？

这是企业 RAG 最常见、也是最隐蔽的问题。

核心原因通常有四类：

• 文档切分策略错误，语义被破坏
• embedding 模型不适合业务语料
• 查询语句和文档语义“不在一个空间”
• 只做向量召回，没有关键词兜底

很多团队第一版 RAG 的失败，并不是模型不行，而是检索层根本没把信息找对。

为什么部署复杂，维护成本高？

因为 RAG 是一个系统工程：

• embedding 服务
• 向量数据库
• 原始文档存储
• rerank / LLM 服务
• 权限、日志、监控

如果每一层都是“随便拼的”，后期几乎无法维护。

实践步骤：一套可支撑 10 万+ 文档的 RAG 工程方案

下面进入真正的实战部分，我会按照真实项目的构建顺序展开。

第一步：文档预处理，比你想象中重要 10 倍

文档清洗的三个工程原则

• 不要相信“原始文档一定有用”
• 不要一次性全量入库
• 文档是会“进化”的

建议在入库前至少做：

• 去除目录、页眉页脚、免责声明
• 合并被错误拆分的段落
• 统一编码、符号、语言

Chunk 切分：不是越小越好

常见误区是：

chunk 越小，检索越准

在企业语料中，这往往是错的。

推荐经验区间：

• chunk 字数：300～800
• 保留 10%～20% overlap
• 按语义边界切，而不是按字数硬切

示例（伪代码）：

chunks = semantic_split(
    text,
    max_tokens=600,
    overlap=100
)

第二步：Embedding 模型选型与调优

不要盲选“排行榜第一”的 embedding

企业级场景更看重：

• 中文 / 行业语料适配度
• 向量维度 vs 性能
• 是否支持本地部署

实测经验：

• 768 维往往是性价比最优点
• 高维模型在召回提升上收益递减
• 行业语料 > 通用榜单指标

如果你需要快速定制 embedding 模型，而不想从零写训练代码，可以考虑LLaMA-Factory Online用在线方式对 embedding 模型做领域适配，成本和风险都更可控。

第三步：向量库不是“装进去就完了”

索引结构决定了 80% 的性能

在 10 万+ 文档规模下，强烈建议：

• 使用 HNSW / IVF-PQ
• 按业务或文档类型分库
• 定期重建索引

示例（FAISS）：

index = faiss.index_factory(
    dim,
    "IVF4096,PQ64"
)

向量召回一定要“兜底”

纯向量召回在企业场景一定不够。

推荐组合策略：

• 向量召回 TopK
• BM25 / 关键词召回
• 结果合并去重

这样可以显著减少“明明有却搜不到”的情况。

第四步：Rerank 是企业 RAG 的分水岭

如果说 embedding 决定“找不找得到”，
那 rerank 决定“用不用得上”。

建议：

• 向量召回 Top 50～100
• rerank 到 Top 5～10
• 再交给 LLM 生成

rerank 模型不需要很大，但一定要语义理解强。

第五步：生成阶段要“约束模型，而不是相信模型”

企业级 RAG 中，生成阶段要注意三点：

• 严格基于检索内容回答
• 明确拒答策略
• 输出可追溯引用

示例 Prompt 思路：

你只能基于提供的资料回答问题。
如果资料中没有答案，请明确说明“资料不足”。

效果评估：RAG 好不好，不能只看“感觉”

必须量化的四个指标

• Recall@K（检索层）
• MRR / NDCG（排序层）
• Answer Accuracy（人工或半自动评估）
• 延迟（P95 / P99）

一个实用的评估技巧

从真实业务中抽取：

• 高频问题
• 长尾问题
• 模糊问题

做成固定评测集，每次改动都跑一遍。

总结与未来展望：RAG 会走向哪里？

当你真的把 RAG 做到企业级，会发现一个结论：

RAG 的上限，取决于你对“检索系统”的理解，而不是模型参数量。

未来 1～2 年，我认为企业级 RAG 会呈现三个趋势：

• 检索与生成进一步解耦
• 行业 embedding / rerank 成为标配
• RAG 与微调、Agent 深度融合

如果你愿意，下一篇我可以继续深入：
“RAG + 微调到底怎么选？哪些场景 RAG 一定不够？”