"做一个 RAG Demo 只需要 50 行代码，但做一个能上生产、可被业务部门信任的 RAG 系统，可能需要 5000 行代码加上 50 次踩坑。" 这是我们团队在过去一年里反复验证过的事实。本文系统分享古戈尔在多个客户项目中沉淀下来的 RAG 工程化实践。
1. 切片：从「按长度切」到「按语义切」
最早期的 RAG 教程几乎都使用「每 500 字符切一段」的暴力策略，结果就是上下文断裂、关键信息被切碎。我们采用「段落 → 章节 → 文档」三级父子结构 + 语义切片器，确保检索时既能命中精确片段，又能在生成时获得完整上下文。
2. 检索：向量检索 + 关键词检索 + 重排
纯向量检索擅长「语义模糊查询」，但对专有名词、型号、产品代码等命中率反而不高。我们将 BM25 关键词检索与 dense vector 检索并行，最后用 Cross-Encoder Reranker 做精排，平均能提升 25–35% 的命中率。
3. 提示词：把「指令」与「上下文」明确分离
生产级 RAG 的 prompt 模板必须做到：(1) 系统指令清晰约束模型不要编造；(2) 检索片段以编号 + 来源标注；(3) 输出格式标准化以便程序后处理。古戈尔有一套针对中文行业语料调优过的 prompt 模板库，已经覆盖法律、金融、医疗、客服四大方向。
4. 引用：让答案可被追溯
"答案是哪里来的"是企业用户决定是否信任 AI 的关键。我们在生成阶段强制要求模型输出 [doc#3] 这样的引用标记，前端再渲染成可点击的卡片，跳转到原文位置。这一个看似简单的设计，让大模型幻觉造成的信任损失下降了 80% 以上。
5. 可观测：每一次问答都是一次实验
生产 RAG 系统必须埋点：召回文档列表、检索耗时、Token 消耗、人工反馈点赞/点踩。我们基于 OpenTelemetry + 自研可视化面板，让产品和算法同学每天都能看到系统真实表现，并把不满意的对话沉淀成下一轮微调或 prompt 优化的素材。
6. 上线之后才是真正的开始
RAG 不是一次性项目，而是一个需要持续运营的「知识系统」。文档要不断更新、prompt 要不断迭代、模型要不断升级。古戈尔为每一个 RAG 客户都提供持续运营服务，确保系统效果不会随着时间衰退，而是越用越聪明。
如果你也正在思考如何把 RAG 真正落地，欢迎联系古戈尔团队——我们愿意把这些一手经验分享给每一个认真做 AI 应用的伙伴。