从 Demo 到生产：RAG 系统落地的 5 个关键工程实践

---
title: 从 Demo 到生产：RAG 系统落地的 5 个关键工程实践
date: 2026-10-25
category: 人工智能
tags: [RAG, 大模型, AI应用开发, 检索增强, 工程实践]
---

# 从 Demo 到生产：RAG 系统落地的 5 个关键工程实践

很多团队的 RAG 之旅是这样开始的：用开源框架跑通一个 Demo，向量库加一个大模型 API，拿几个内部文档问下来效果还行，于是立项落地。等真实用户一上线，问题就藏不住了——检索召回不准、答案张口就编、响应动辄十几秒、token 账单肉眼可见地膨胀。

问题多半不在模型，而在工程。Demo 和生产之间的鸿沟，恰恰是大量不起眼的工程细节填平的。这篇文章整理 5 个实际项目里反复验证过的实践，按投入产出比排序，供正在落地 RAG 的团队参考。

## 一、文档切分决定了 RAG 的上限

一个反直觉的事实：RAG 效果差，八成不是模型不行，是语料没处理好。检索再强、模型再好，喂进去的是切碎的表格和拦腰截断的段落，产出必然拉胯。

几个值得投入的点：

**按结构切，别按长度切。** 无脑按 512 token 切一刀，会把表格切成两半、把结论和论据切开。优先利用文档自身结构：Markdown 的标题层级、HTML 的 DOM、Word 的样式，以语义单元为基础切分，chunk 之间保留 10%~20% 的重叠防止边界信息丢失。

**小 chunk 检索，大 chunk 生成。** 这是被验证有效的经典策略（small-to-big）：用 200 token 左右的小块去做向量检索，命中后把它所属的父段落（比如整个小节）送给模型。小块保证召回精度，大块保证上下文完整，两头都占。

**元数据别省。** 每个 chunk 带上来源文档、章节路径、更新时间、部门/产品线等字段。它们在检索阶段可以用来做权限过滤和时效过滤，在生成阶段可以用来做引用溯源——后面会讲到这两点有多重要。

一句话总结：切分策略没有银弹，但"按结构切 + 父子 chunk + 元数据"这个组合，值得作为默认起点。

## 二、只靠向量检索是不够的

纯向量检索有个天然短板：对专有名词、型号、缩写、精确编号的召回很不稳定。用户问"故障码 E2032 怎么处理"，嵌入模型很可能把它和不相关的故障处理章节算出高相似度——字面完全匹配的文档反而排不进前五。

解法是混合检索：

```text
查询 → BM25 关键词检索 (top 50)
     → 向量语义检索 (top 50)
     → RRF 融合排序
     → 重排模型精排 (top 5)
     → 送入大模型
```

BM25 负责抓住字面精确匹配的硬信号，向量检索负责语义泛化的软信号，两者用 RRF（Reciprocal Rank Fusion）融合，互补性非常明显。工程上各主流向量数据库和搜索引擎基本都支持这两种检索方式，成本增加有限。

如果只能加一个环节，我建议加**重排（rerank）**。用一个 cross-encoder 重排模型对融合后的 top 50 做精排，只保留 top 5 送进大模型。它带来的精度提升通常大于你花一周调 prompt 的收益，而且推理成本可控——重排模型比生成模型便宜一个数量级。

## 三、没有评测集，一切优化都是玄学

"调了 prompt，感觉答案变好了"——这句话在生产环境里没有任何价值。感觉会骗人，尤其是在你期待它变好的时候。

落地前先做这件事：**构建一个 50~200 条的评测集**，覆盖三类内容——高频真实用户问题、边界 case（文档里没有答案的问题）、刻意构造的歧义问题。每条标注标准答案和应命中的文档块。

然后定义两个层级的指标：

- **检索层**：recall@k（正确文档块是否进了 top k）、MRR（正确答案排多前）；
- **生成层**：忠实度（答案是否有语料支撑）、相关性（是否回答了问题）、拒答正确率（该说"不知道"时是否说了）。

生成层指标用 LLM-as-judge 自动打分即可，RAGAS 这类开源框架可以直接用，也可以自己写评分 prompt。

有了这套东西，切分策略改了、模型换了、prompt 调了，跑一遍评测集就知道是进步还是退步。它还有一个隐性收益：当业务方质疑效果时，你拿得出数字，而不是形容词。

## 四、幻觉治理：让模型学会说"不知道"

RAG 的幻觉有一半是 prompt 惯出来的。如果系统提示词只说"根据资料回答问题"，模型面对资料里没有的内容，会倾向于硬编一段。三条行之有效的约束：

**第一，明确授权拒答。** 提示词写清楚："仅根据以下资料回答；资料中没有的信息，直接回答'根据现有资料无法确定'，不要推测。"给模型台阶，它才敢说不知道。

**第二，引用溯源。** 要求答案中的关键结论标注来源编号（如 [1][2]），并把编号对应到具体文档和章节展示给用户。这不仅是给用户核实用的——一旦要求引用，模型编造内容的倾向会明显下降，因为它得给出处。同时这也是倒逼检索质量的手段：引用错了，一眼就能看出来。

**第三，设置相似度阈值兜底。** 重排得分低于阈值时，不走生成，直接返回"未找到相关内容"。宁可少答对，不要答错得理直气壮。在客服、内部知识库这类场景，一个编造的答案造成的信任损失，远大于十次坦诚的拒答。

## 五、延迟和成本，工程上同样致命

功能和准确率达标后，RAG 系统的下一个生死关是首 token 延迟和 token 成本。三个立竿见影的手段：

**流式输出是底线。** 用户对 3 秒首 token + 逐步输出的容忍度，远高于 15 秒后一次性输出完整答案。检索和重排环节可以和首 token 并行压缩。

**上语义缓存。** 相同或语义相近的问题直接返回缓存答案。企业知识库场景里，问题分布高度集中（20% 的问题覆盖 80% 的流量），缓存命中率做到 30% 以上并不难，省下的是真金白银。

**分级路由。** 简单事实型问题路由给小模型（响应快、便宜），只有需要长推理或多文档综合的问题才走大模型。用一个轻量分类器或者小模型自己判断即可。整体成本砍半是常见结果。

另外，文档入库环节做增量更新而不是全量重建——按文件哈希判断变更，只重新切分和 embedding 有变化的文档。语料上万份之后，全量重建的向量库账单会让你重新审视这个问题。

## 写在最后

RAG 不是"接个 API"的活，而是数据工程、检索算法、评估运营三个环节咬合的系统工程。这 5 个实践的优先级是有讲究的：**切分和评测集是地基，混合检索和幻觉治理是骨架，延迟成本优化是装修**。顺序做反了，很容易在错误的楼层上精装修。

在华为云上落地这条链路，ModelArts Studio 提供的知识库与智能体编排能力可以覆盖其中大部分环节——知识库托管语料解析与混合检索，编排画布串联重排与生成，配合函数工作流和缓存服务组装成完整应用，从 Demo 到生产的路径可以走得更短。

如果你正在做 RAG 落地，欢迎在评论区交流你踩过的坑。