RAG（检索增强生成）与Agent的深度融合正成为企业实现AI落地的关键路径。RAG技术创始人Douwe Kiela分享了关于RAG Agent在企业应用中的10个深刻教训，本文基于其视频内容与一线实践经验，为你解读其中5个核心教训，并附上实操经验与常见问题解答。

1. 更好的LLM不是（唯一）答案

系统优化比单一模型更重要：RAG系统的整体效果胜过顶尖LLM。LLM只是整个AI系统（特别是RAG系统，包括提取、检索、生成、联合优化）的一小部分（约20%）。一个优秀的RAG系统配合普通的LLM，效果可能优于一个顶尖LLM配合糟糕的RAG系统。关键是关注系统而非孤立的模型。

实践分享

我曾经参与优化过一个基于RAG的知识库问答系统。当时的情况是，团队做了测试，使用GPT-4的效果会好于GPT-3.5的效果，但是回答内容的准确率仍然低于50%。后来做了一些调整，准确率提升到80%以上：

• 提取企业数据到向量数据库之前，将数据格式化，例如都变成Markdown格式。同时清洗掉一些无效数据，例如HTML的标签等，页眉页脚、目录、引用等部分。
• 检索时候使用多路召回，不仅仅使用向量检索，还结合了关键词检索，联合重排后使用。这样可以提高召回率。
• 生成最终回复内容的时候，利用提示词工程来限定大模型使用的知识范围，例如只从召回的内容中生成回答，否则直接回答无法回复等方式，避免幻觉。
• 使用提示词工程例如：格式化指令、Few-Shot等来引导模型生成更好的内容。

在使用上述方法后，我们替换了GPT-3.5 Turbo，以及后续发布的成本更低的GPT-4o mini。虽然模型不是最新的最高级的版本，但是综合效果却是最好的。也就是Douwe Kiela所说的，RAG系统的整体效果比单一模型的效果更重要。

小提示：不要总是盯着最贵的模型。先花精力把数据清洗、索引结构、检索策略和提示词优化好，往往能用低成本模型获得远超预期的效果。

常见问题：为什么我换了更强的模型（如从GPT-3.5换成GPT-4）还是效果不好？

答：模型只是RAG系统的20%。问题可能出在数据质量差（如含有噪声标签）、检索召回率低（只有向量检索，缺少关键词补充）、或者提示词没有约束模型只能使用检索内容。建议先系统排查检索和生成两个环节，再考虑模型升级。

2. 专业知识是你的燃料

专业知识是AI价值的核心：企业内部积累的专业知识和机构知识（通常存在于文档和数据中）是驱动AI产生价值的核心燃料。必须设法解锁这些专业知识。

实践分享

每个企业都有丰富的所在领域的领域知识。有一个项目是一个学校做一个AI私人教师，给每个学生提供个性化的学习方案。这个学校准备的RAG的数据，是他们自己的材料和特有的教学方法，这也是他们和其他同行的主要区别，也是他们的行业壁垒。AI机器人基于这些数据的构建才会有能力解决这个领域的问题。而通用大模型是很难获得这么特殊的领域知识的。

小提示：不要只把公开网页或通用知识塞进RAG知识库，真正有价值的是企业内部的SOP、历史案例、产品手册、客户对话记录等专有数据。把这些“燃料”准备好，AI才能“燃烧”出业务价值。

常见问题：企业数据很零散，如何快速提取专业知识？

答：不必追求一次清洗完所有数据。可以先聚焦一个业务场景，选出最核心的10-20份文档（如产品规格书、常见问题手册），人工整理成结构化格式（如Markdown表格、JSON），先跑通一个MVP。后续再逐步添加更多文档，通过自动化流程（如使用LLM自动提取元数据）来扩展。

3. 企业规模是你的护城河

企业规模和数据是竞争优势：利用独特数据构建竞争壁垒。企业的核心竞争力在于其独特的数据。真正的挑战在于大规模地利用这些数据，让AI能够处理大规模、甚至“嘈杂”的真实数据。成功做到这一点，就能构建竞争壁垒。

实践分享

我经历过的项目中，最开始确实有大量和复杂的数据清洗过程，为了给AI提供高质量的数据，提高RAG的召回率和质量。不过随着从试点到推广阶段，你会发现企业大量的数据都是带有“噪音”的。如果都要进行数据清洗，工作量和效率上都是不可能完成的任务。所以与其利用大量的时间做数据清洗，倒不如想办法让AI能够接受这些带有”噪音“的已存在的数据是更契合实际的。

小提示：对于大规模真实数据，可以先用简单的分块（如按段落或固定Token长度切分）建立索引，然后通过检索后处理（如重排序时引入相关性过滤）来容忍噪声。相比花大量时间清洗所有数据，这种“快糙猛”的方法更利于快速上线验证。

常见问题：数据噪声很大（比如包含表格、页眉页脚），直接使用会影响效果，怎么办？

答：可以在索引阶段进行轻量级清洗，例如使用正则表达式或LLM提取正文主要段落。对于表格数据，可以先用LLM将表格转为纯文本描述再索引。同时，在检索阶段提高召回数量，让重排序模型帮忙过滤掉噪声片段。这样不需要对每份文档做精细标注。

4. 试点与生产之间的鸿沟总是比预想的要大

建立小规模试点相对容易（少量文档、用户、单一场景、低风险），但将其扩展到生产环境则面临巨大挑战（海量文档、大量用户、多场景、高安全风险、SLA要求等）。

实践分享

还是企业内部知识库的AI项目，少量文档20～50个50K～100K大小文档的内容作为知识库的基础数据，召回率以及效率都很好。不过实际企业中的数据量和单文件大小都存在很大差异。铺开后先不考虑RAG的召回率和准确率。就说索引和召回的速度都成了问题。所以在试点阶段，需要考虑到后续的规模化的系统设计和应对方案，而不是只关注眼前的体量。但考虑多少需要基于实际项目来平衡。

小提示：在试点阶段就要做压力测试，模拟生产环境的数据量级（如10倍、100倍文档）测试索引构建时间和检索延迟。提前启用分库分表、缓存、异步索引等架构手段，避免上线后推倒重来。

常见问题：如何评估从试点到生产需要扩充多少资源？

答：建议评估三个指标：数据量增长速度、并发用户数、响应时间SLA。例如试点时100份文档、10个并发用户、响应时间2秒；生产预估10000份文档、1000个并发用户、响应时间要求1秒。那么需要选择支持水平扩展的向量数据库（如Milvus、Wea viate）并设计合理的分片策略。另外，索引更新频率也很关键，建议使用增量索引而非全量重建。

5. 速度比完美更重要

速度比完美更重要：不要追求一开始就完美。应尽早将（哪怕不完美的）系统交给真实用户使用，获取反馈并快速迭代。通过迭代“爬山”达到目标，而不是试图一次性设计出完美方案。

实践分享

这一点和第4点有冲突的感觉。如何把握快速且完美之间的平衡呢？还是分享一个实际项目中的情况：

• 找到企业最需要AI解决的问题，最好是单一问题，降低复杂度。快速实现，让客户看到效果。获得企业的认可。这个时候数据量不需要很大，主要是关注是是否能够让企业理解AI的价值。
• 按照生产环境的要求来设计系统，仍然是试点的单一问题，放大规模后，看看是否能够满足企业的要求。例如我们在和一个小学合作研发AI私人教师的项目中，一开始是覆盖客户希望的全部学科中的三个，数学、语文、自然科学。但是提供资料是有限的的5M，同时参与验收体验的学生和老师总共20人。小规模验证需求可行性。这个过程用了1个月的时间。得到肯定效果后，通过扩充教材数据量，从5M到200M，参与的老师和学生扩充到300人。这个过程用了2个月的时间。期间有多次UAT来搜集反馈。这些都通过后，才开始进一步演进，例如模型的优化、数据优化、系统吞吐量的优化等。所以保持快速交付与用户的参与是AI项目落地的关键。

小提示：可以采用“双轨制”：一条轨快速搭建最小可用系统让用户试用（用公开模型+简单检索），另一条轨同时进行生产级架构设计（如高可用、安全、监控）。这样既满足速度，又预留了扩展空间，避免后期重构。

常见问题：快速发布不完美的系统，用户会不会因为体验差而失去信任？

答：建议在MVP阶段明确告知用户“这是测试版本，正在快速改进”，并提供简单的反馈通道（如“点赞/点踩”按钮）。同时，只开放给少量核心用户（如内部团队或友好客户），承诺在几周内根据反馈更新。用户看到自己的建议被采纳后，往往会更愿意参与共创。

总结：以上5个教训覆盖了RAG Agent落地中的关键认知——系统思维>模型迷信、专业知识是燃料、规模数据是壁垒、警惕试点到生产的鸿沟、速度优先于完美。Douwe Kiela的10个教训后续还有更多精彩内容（如评估、安全、人机协作等），欢迎持续关注。记住：AI落地的核心不是技术炫技，而是用正确的方法解决真实业务问题。