过去8个月，某技术团队深度参与了RAG（Retrieval-Augmented Generation，检索增强生成）项目的落地实践。其服务对象包括Usul AI（共计900万页）以及一家未具名的法律AI企业（共计400万页）。本文回顾了该团队在真实生产环境中构建RAG系统所踩过的坑、优化过程及关键经验，并对每项优化措施按ROI（投资回报率）进行排名。
初始阶段：Langchain + Llamaindex
项目初始阶段以常见教程为指导，采用了 Langchain 结合 Llamaindex 的组合。第一周内便构建出原型系统，并在小规模数据（100个文档）上测试结果令人满意。随后在接下来的几天里将整个流程扩展到生产级数据集上，整个过程在一周内完成，表面上进展迅速。
然而，问题随之而来：实际结果效果不佳，且只有终端用户能明确指出问题所在。接下来数月内，团队对系统各模块逐步重写和优化，直至达到理想性能。
真正“有效”的关键优化（按效果排序）
✅ 1. 查询生成（Query Generation）
用户的最后一句话往往不足以表达其全部信息需求。团队引入LLM对完整对话线程进行分析，生成多个语义查询与关键词查询并行处理，随后将结果交由重排序器处理。这种方式显著扩大了搜索覆盖面，避免了过度依赖初步检索评分的弊端。
✅ 2. 结果重排序（Reranking）
仅需几行代码，却带来了最大性能提升。团队发现，仅靠初始排序的表现差距巨大，通过传入较多候选块（chunks）并由 reranker 精选，可极大提升最终结果质量。最佳设置为：输入50个chunks，输出15个。
✅ 3. 切块策略（Chunking Strategy）
这是最耗费精力但至关重要的环节。团队为两个项目构建了定制化切块流程。关键点在于：
- 避免chunks在单词或句子中途被截断；
- 保证每个chunk为逻辑独立单元，具备自洽的信息承载能力。
✅ 4. 向LLM传递元数据（Metadata to LLM）
初期仅传递chunk内容，后经实验发现，在输入中加入元数据（如标题、作者等）能显著提升答案质量与上下文完整性。
✅ 5. 查询路由（Query Routing）
很多用户提问并不适合用RAG解决，例如“这篇文章是谁写的”“总结一下全文”等。团队开发了轻量级路由器用于识别此类问题，并调用API + LLM方式处理，避免不必要的全文检索与推理。
技术栈与工具选择
- 向量数据库：从 Azure → Pinecone → Turbopuffer（性价比高，原生支持关键词搜索）
- 文档解析：自研模块
- 切块工具：默认使用 Unstructured.io；企业级项目使用自定义方案（团队也推荐 Chonkie）
- 嵌入模型：
text-embedding-large-3（未测试其他模型） - 重排序器：起初无 → 后续采用 Cohere 3.5 → 最终使用 Zerank（冷门但效果良好）
- 语言模型：从 GPT-4.1 → GPT-5 → 又回到 GPT-4.1（因Azure额度支持）
总结
在生产环境构建 RAG 系统，远不只是“搭一个 Langchain + LLM”那样简单。快速跑通原型容易，但真正做到效果可靠、性能可控，需要：
- 深入理解数据
- 高质量切块策略
- 结构化规划查询与处理流程
- 明确边界，合理使用 AI
- 灵活架构应对多样问题类型
唯有不断打磨细节，才可能让RAG系统真正从实验室走向实用级落地。