写给谁
如果你的团队正在把 RAG 从 demo 推向生产(无论是金融机构知识库、央企政策语义、政务监管解读), 这份内容是给你的。
本文整理在生产环境反复出现的 6 种 RAG 工程反模式 — 它们都不是模型选错或语料不够, 而是被多数 PoC 团队忽视的工程细节。
一、不是问题的"模型选择"
embedding 模型选择 (BGE / M3E / Sentence-BERT / 自研) 几乎不是 PoC 失败的根因。换言之, 主流 embedding 模型在 PoC 阶段都能拿到一个可接受的召回率, 这不是瓶颈。
真正咬人的是下面 6 件事。
二、6 个真正的工程反模式
反模式 1:Chunking 粒度按"字数"切, 不按"语义边界"切
最常见的错。
很多团队用 chunk_size=512 + overlap=50 这种定长切分把文档切碎。在 PoC 时(单一文档 / 简单问答)看不出问题, 上生产后:
- 一个法律条款被切成 3 段, 检索时只命中 1 段, 答案缺失关键限定
- 表格被横切, 表头和表体分离, 模型读到表体不知道列是什么
- 代码块被中间切, 函数定义和实现分到不同 chunk
真问题: chunk 粒度 ≠ 字数, 应该是"语义可独立成立的最小单元" 对策: 按文档类型设计 chunking 策略 — 法律按"条款", 表格按"完整表 + 表头", 代码按"函数级别", 长文按"自然段 + 上下文窗口"; 实战中 chunk_size 经常需要从 256 到 2048 浮动
反模式 2:只索引 raw text, 不索引"重写后的 query-friendly summary"
PoC 时, 索引原始文档段落, 检索效果良好。
生产中遇到客户问法千奇百怪:
- 原文: "本条款适用于持有不少于 30 天的客户"
- 用户问: "我刚开户一周, 能享受这个吗?"
- raw text 检索可能匹配不上, 因为字面 token 不重合
真问题: raw text 是事实表达, 用户问题是意图表达, 两者语义空间不直接对齐 对策: 对每个 chunk 额外生成"可能的问题列表" (LLM 离线生成 5-10 个相关问题), 把这些问题与原 chunk 一起索引. 检索时同时匹配 raw text 和 question variants
反模式 3:不做 reranker, 直接把 top-K 塞给生成模型
PoC 时 top-5 召回率 80%, 看着不错. 生产中:
- top-5 里有 1 个高度相关 + 4 个略相关, LLM 被噪声分散注意力
- LLM 在长 context 上的"中间被遗忘"现象明显, 关键文档如果不在 top-2 就经常被忽略
真问题: embedding 召回 ≠ relevance 排序; 一阶段检索的目标是不漏, 不是排好 对策: 加二阶段 reranker (BGE-Reranker / Cohere Rerank / 自研 cross-encoder), 把 top-50 重排为 top-5; 公开基线对比中, 加 reranker 后端到端 EM 通常有显著提升
反模式 4:把"幻觉"问题当成"模型能力"问题
PoC 时偶尔幻觉, 看起来是模型不够强, 计划"换更大的模型"修复。
但在生产中, 幻觉的来源结构通常是这样 (按粗略主次排序):
- 主因: 检索召回不到关键文档 (上面反模式 1+2+3)
- 次因: prompt 没明确"不知道就说不知道"
- 再次: 语料本身就有冲突 (例: 同一政策的新旧版本都在库里)
- 末位: 才是模型推理能力问题
真问题: 幻觉是系统级问题, 不是模型问题; 多数幻觉可以在检索层和 prompt 层解决 对策: 系统化 "no-answer" prompt + 语料版本管理 + 检索召回率监控. 换更大模型是最后手段, 不是第一手段
反模式 5:索引建一次就不再迭代
PoC 阶段索引建一次, 演示完归档. 生产中:
- 客户文档库每月新增 / 修订, 但索引没自动重建, 老文档 stale
- 客户的历史问答记录是黄金语料, 但没被反喂回索引
真问题: RAG 是持续运营系统, 不是一次性 ETL 对策: 建立索引增量更新机制 (新文档自动 chunked + indexed) + 历史问答闭环 (高频问题 → 反推语料缺口 → 主动补充)
反模式 6:不监控"检索召回率", 只监控"用户满意度"
PoC 时人工评估 30 个问答, 都满意. 生产中:
- 一个月后用户投诉"答非所问", 但没有指标可看到这一趋势
- 不知道是 LLM 输出问题 / 检索问题 / 语料过期 — 排障靠猜
真问题: RAG 系统的 SLO 必须分层 (检索层 + 排序层 + 生成层 + 端到端), 不能只看终端满意度 对策: 维护 ~200 个"金问题"的回归测试集, 每周自动跑一遍; 各层指标分别看 (Recall@K, MRR, Faithfulness, Answer Relevance)
三、6 个反模式的优先级 (排查顺序建议)
四、LYG.AI 在 RAG 工程上的实践
我们在 LYG Lumen Agent + Foundry 平台上的 RAG 默认架构包含以下"反反模式"基线:
- Chunking 策略: 按文档类型 (法律 / 表格 / 代码 / 长文) 各自的 chunker, 不是一刀切定长
- Query 重写: 入库时 LLM 离线生成 query variants, 检索时 query expansion
- 二阶段 reranker: 默认开启, 客户可选 cross-encoder 或 LLM-as-reranker
- No-answer prompt: 默认开启, 检索 confidence 低于阈值直接返回"无法回答"
- 金问题回归集: 上线时同步建一份 200+ 问题的金集, 自动周回归
- 语料版本管理: 同一文档新版本进库自动 deprecate 旧版本, 不允许新旧并存
完整架构白皮书 (含示意图 + 性能数据) 见 LYG Ark 架构白皮书 § 五 RAG 模块。
五、给 CIO / CTO 的 RAG 项目检查清单
如果你的团队下个月要启动 RAG PoC, 把这 6 件事写进验收标准:
- Chunking 是按文档类型设计的, 不是固定字数
- 每个 chunk 有对应的 query variants 索引
- 二阶段 reranker 已就位
- Prompt 含 no-answer 模板, 默认开启
- 语料有版本管理, 新旧不并存
- 金问题回归集 ≥ 100 题, 周自动跑
PoC 验收时这 6 项都通过, 上生产的成功率会显著高于跳过它们的项目。
延伸阅读
- 旗舰白皮书:企业 AI 落地的 6 个工程决策点 (决策 3 RAG vs 微调 vs 长上下文)
- LYG Ark 架构:LYG Ark 架构白皮书
需要与 LYG.AI 工程团队做 RAG 项目技术评审? 联系 sales@lyg.ai, 24 小时内首次响应。