Douwe Kiela 的 10 个关键教训犹如智慧的灯塔。其一，持续学习，紧跟领域前沿；其二，注重细节，从细微处提升质量；其三，勇于创新，突破传统思维；其四，团队协作，发挥集体智慧；其五，精准定位，明确目标方向；其六，高效沟通，避免误解与冲突；其七，快速迭代，不断优化方案；其八，风险把控，预防潜在问题；其九，客户至上，满足需求为要；其十，坚韧不拔，面对困难不轻易放弃。这些教训如同一把把钥匙，开启成功的大门，为我们在各种领域的探索与实践提供了宝贵指引。

今天继续这个话题，事实上这个系列不太好写，写深入了容易将现在正在做的项目技术路径泄露，写浅了又有点隔靴搔痒，但其实现在很多公司都有类似的问题：

1. AI聊得不像人，最常见案例就是生硬，就算上RAG或知识库也不好使；

2. AI准确率不高，最常见就是AI能覆盖80%的场景，但业务的及格线是95%；

这些问题都与我们探讨的问题相关，其中准确率不高这个是专家系统需要解决的任务；而聊得不像人这就比较麻烦了，策略层面涉及了Cot，技术层面暂时多与RAG相关。

只不过就RAG这个技术，要用好的公司也不多，为避免泄露当前项目技术机密，今天我就借Douwe Kiela（RAG 技术的最初开创者之一）提出的10个宝贵经验，来聊聊如何做好RAG这件事。

上下文悖论

The Context Paradox，莫拉维克悖论指出：对计算机而言，执行人类觉得困难的任务（如下棋）比执行人类觉得容易的任务（如行走、感知）更容易。

其实这一观点与RL 之父 Rich Sutton某一观点十分类似：依靠纯粹算力的通用方法，最终总能以压倒性优势胜出。

他特别提出：AlphaGo/GPT-3的成功并非源于复杂规则，而是大规模算力支撑的简单算法（神经网络+海量数据）。

类似的情况在大模型领域正在发生：

大型语言模型（LLMs）在生成代码、解决数学问题等许多方面表现惊人，甚至超越大多数人类。然而，它们在处理和理解上下文方面却依然面临挑战。

而人类，尤其是领域的专家，能够毫不费力地凭借多年积累的专业知识和直觉，将信息或问题置于正确的上下文环境中。

上述问题的原因，我们之前也探讨过：AI尤其擅长处理正确架构下的有限集。

比如，AlphaGo的成功建立在围棋规则完全透明、状态空间有限的基础上。

但大模型在构建（训练）的根本上就显得天生残疾，因为语料是残缺的，或者说信息是残缺的。

知识/数据是对真实世界的描述，但有很多隐性知识根本没有得到记录，比如医生在实际诊断过程中，不仅依赖临床指南，还有大量的内化知识，包括：

1. 患者微表情解读（疼痛忍耐度）；

2. 社会经济因素权衡（治疗方案可行性）；

3. 伦理判断（生命质量 vs 延长寿命）；

这是当前AI难以跨越的困局：隐性知识难以结构化，导致训练数据在本质上是残缺的。

综上，其实际体现出来的结果就是上下文悖论，我们觉得复杂的事物AI处理得很好，如数十万数据的查漏补缺；但我们觉得简单的事物模型却处理得很差，如聊天像个人。

这也是很多企业实际正在遭遇的问题，如何让模型更好地学习理解公司内部的知识，并将他们表达出来，以下是10个关键教训。

PS，我看了下Douwe Kiela的10个教训，和我去年总结的有几条是类似的：

工程大于模型

Systems > Models，这其实是我去年的核心经验了：

对于AI项目来说，工程能力是真正的难点，因为AI项目周期较长，很多AI项目执行到最后，会发现对工程能力、项目管理能力的要求极高。

再以行业应用为例：一套行业应用的背后是成百上千个SOP，如何组织这些SOP将是AI应用真正的难点。

大家对这里的工程难度其实是没有概念的，就过往经验来看：一个SOP对应5000~10000字的提示词，一个复杂的AI项目至少会包含50个SOP：

这意味着你需要写25万50万字的提示词！而这还算简单的……

这数十万的提示词中又会有很多本地数据、外延数据的处理，还得建立循环升级的飞轮系统。

所以，在AI项目中，工程难度远大于模型难度，一定要好好确定模型的边界，在我过往AI项目中，模型的使用占比不会超过30%，使用越多越不稳定。

最后提一点，AI项目的工程难度80%都在数据工程……

垂直而不是通用AI

Specialize > AGI，企业拥有宝贵的机构知识和专家经验。通用目的的 AI 助手很难匹敌公司内部专家的水平。如果企业真的想解决那些非常困难、具有高度领域特异性的问题，就必须进行专业化。

这句话我为大家粗暴地翻译翻译，大概可以理解为：垂直领域AI才是王道，比如Manus是玩具，Cursor才解决问题。

这个其实算是业内通识，包括前些日子红杉AI大会也是这个意见：在企业级市场中，真正先跑出来的入口未必是通用大模型，而是 Harvey（法律）、Open Evidence（医疗）这类垂直领域的智能体 OS，因为它们能听懂行业语言，理解真实需求。

只不过他这里的意见提出来后有些划水，我来为大家进一步翻译翻译什么是专业化：

这个SOP/Workflow就是专业化，其背后就是我们所谓行业KnowHow。

数据是壁垒

Data is Your Moat，这一条大概是去年我们也聊过：现阶段公司与公司之间，产品与产品之间是没有根本的技术壁垒的，因为壁垒都是大模型的……

这里举个实际的例子：之前IBM Watson花大力气构建的医疗知识图谱，现阶段再去做，成本可能不到过去的1/10！

技术不再是壁垒，而数据可能变成一个公司最大/最后的壁垒。

许多企业认为必须先花费大量时间清洗和整理数据才能应用 AI，但这通常不切实际。真正需要做的是让 AI 能够处理大规模的、嘈杂的真实企业数据。成功做到这一点，就能获得差异化的价值和竞争优势，因为这些独特的数据正是你的“护城河”。

这里有点复杂，需要为大家翻译翻译：这里的数据不仅是结构化的数据，还包括公司日常产生的各种业务非结构化数据。

公司需要将这些数据用起来，构建一个业务飞轮系统，以便不断地拉开和竞争对手的体验差距。

AI项目的非对称性

Pilots are Easy， Production is Hard，使用现有框架构建一个简单的 RAG 试点项目相对容易。你可能能快速搭建一个系统，放入一些文档，服务少数用户，并获得积极反馈。然而，将它推向生产环境则面临巨大挑战。

这里用我们去年的经验来说就是：要特别小心AI项目的非对称性，你可以花一周就做出70分的demo，让老板大家赞赏，但半年后很可能你的AI项目依旧只有70分！

因为生产环境需要处理数十万、数百万甚至数千万份文档，服务成千上万的用户，你可能需要覆盖数万种不同的使用场景，此外，还有严格的 企业级安全和合规 要求。

将试点扩展到这样的规模，现有的许多开源工具都难以胜任。因此，从第一天起就要面向生产进行设计，而非仅仅为了试点成功。

事实上这一条建议貌似意义不大，因为他强调的就是第一个建议，AI项目的难点在于工程，这里描述的所有内容都是工程设计上如何处理数据工程的问题。

快速迭代

Speed is More Important Than Perfection，在 RAG Agent 的生产部署中，速度是至关重要的。这意味着要尽早将产品交付给真实用户，获取他们的反馈。

产品初期不必完美，只要基本可用（barely functional）即可。

通过快速迭代，你才能逐步完善产品，使其达到“足够好”的水平。如果等待过长时间追求完美，反而会使从试点到生产的跨越变得更加困难。迭代是许多成功企业级 AI 部署的关键。

AI时代的竞争，不再是产品功能的竞争，而是试错速度与资源的竞争，初期决定胜负的是企业的反应速度及基础实力。

其实这里说起来简单，做起来就很难了所以，因为企业也不得不担心一个问题：我今天付出大量成本获得的技术优势，会不会半年后模型一更新，或者大公司发布一个产品，优势就荡然无存了！

因为速度总是意味着成本啊，比如FastGPT、GPTBots等Agent平台迭代得也挺快，只不过跟Coze比起来又不算什么了。

这里的点是：速度快是一回事，但找准差异化，足够垂直也许才是最重要的。

当然，这里的点是针对于RAG技术来说，他大概的意思依旧是快速收集真实的数据，好实现飞轮系统，这一条事实上意义也不大。

别搞工程师

Engineers on Value，不要让工程师在无聊的事情上花费大量的时间，工程师的精力不能消耗在分块策略、提示工程等底层优化上。

事实上这是我唯一没读懂的建议，分块策略、提示工程等底层优化工作工程师不去做，其他人也做不了啊……

就过往的经验，一个AI项目要变现得好，很可能就是对这些细节的把控足够精准。

而且，就我所见的10多家公司，提示词属于密度较高的存在，也不是谁想写就能写的。

就个人经验，工程师的工作就是不断地做微调、各种微调、小细节的修改……

使AI易于消费

Make AI Easy to Consume，很多公司成功地将生成式 AI 推向了生产环境，但令人惊讶的是，实际使用它的用户可能非常少，甚至为零。

这一点也与RAG技术没多少关系，因为AI知识库肯定会出现在生产场景的，不然公司花这么多钱做什么……

赢得用户，创造“哇”时刻

Get Usage， Be Sticky / Wow Users，这一条与上一条与RAG技术没撒关系，不解决让AI变得更聪明的问题，有点挂羊头卖狗肉。

关注不准确性，而非仅关注准确性

It's Not About Accuracy Anymore，这一条是很重要的，但似乎与RAG没关系：可观测性比准确率更重要。在保证基础准确率后，重点要转向归因追溯、审计追踪和错误分析，然后，建立反馈闭环监控系统，确保合规并持续改进。

在AI项目中，达到100%的准确性几乎是不可能的。即使能达到90%或95%的准确率，企业现在更关心的是如何处理那缺失的5%或10%——即是不准确的部分。当出现错误时该如何应对？

除了基本的准确性要求外，关键在于如何处理不准确性，这就需要可观测性。需要仔细评估系统表现，并确保有 适当的审计追踪，尤其是在受监管行业。

审计追踪可以记录模型生成某个答案是基于哪些具体文档，这在 RAG 系统中称为 归因 (attribution)。归因对于处理不准确性、追溯问题原因非常重要。

此外，可以通过后处理来检查系统生成的声明，确保归因的可靠性。

这一条是非常重要的，甚至是跳出了RAG框架的，只不过他这里的描述过于晦涩，很多同学都未必听得懂，我在这里举个例子，后续会单独开一篇文章做说明。

核心翻译：追求完美准确率不现实，关键是要知道错在哪、为什么错、怎么改！并且能证明技术框架是闭环可重复的！

深度解析 “可观测、可提高”

这里是一个财务+AI的真实AI发票审核的场景：

张三出差上海 2 天，提交报销：

1. 高铁票：¥553

2. 酒店：¥ 800 / 晚 × 2 晚

3. 网约车：¥150

4. 发票：全部上传（酒店发票为增值税普通发票）

如果直接让AI来做，极可能一次性通过，但人工复核的时候就出问题了：

这里出现的4个错误就要被迭代回AI工程，下次再遇到这个场景就必须是对的了。

这里的错误可发现、工程可更新、错误可预防，准确率会提高，就很关键了，可以简单形成一套方法论：

PS：这里的实际实现很复杂，大家知道这个意思就行，找找感觉。

Be Ambitious

保持雄心壮志。

继续开始卖鸡汤了，这里又跟RAG技术没撒关系了。其实我们之前也说过，AI项目的难点在于复杂而长期的工程管理。

AI项目的表现非常神经，一会好一会差，我们的情绪不能被它调动，要快速构建飞轮系统……

结语

从年初的DeepSeek发布到如今，都过去半年多了，各个公司依旧在水底深潜：水面风平浪静，在水下憋着大招。

只不过，大家嘴上喊着2025AI元年，实际在开发过程中连RAG都无法突破，当前很多Agent都是花架子……

就个人经验来说，不要被各种新鲜AI名词忽悠，也别被“RAG 已死”这种标题党带跑偏，眼下最实在的动作依旧是：

1. 把业务 SOP 全丢进 Workflow，哪怕提示词写得土一点；

2. 把审计链闭环跑通，先攒可观测数据再谈花式推理；

3. 把自家非结构化资产盘干净——数据飞轮一转，差距自然就拉开了。

等下一版 RAGFlow 把 Agent 真正并进来，你会发现：今天这段看似左右横跳的日子，其实是给下一波爆发打地基。

届时论文也许还是“乏善可陈”，但你的生产环境已经悄悄把准确率→可观测→迭代的三连击跑顺了。

本文来自微信公众号：叶小钗，作者：叶小钗