今日我们继续探讨这一议题，实际上，这个系列的撰写颇为棘手，若内容过于详尽，恐有泄露当前项目技术路线之虞；而若内容过于简略，又似乎未能触及问题的核心。然而，实际上，众多企业均面临着类似困扰。
人工智能的对话方式与人类存在较大差异，其中最典型的例子是其生硬的表现，即便接入RAG或知识库，效果仍然不尽如人意。
AI的准确度并不理想，通常情况下它只能处理大约80%的情境，然而，对于业务来说，合格的标准却是高达95%。
这些问题均与我们所讨论的主题紧密相连，其中，提高准确率是专家系统亟待攻克的关键任务；至于交流起来不像人类，这则显得尤为棘手，策略上需要考虑Cot，而在技术层面，目前主要与RAG有所关联。
关于RAG这项技术，能够运用得当的企业并不多见，为了防止当前项目的技术秘密外泄，今日我便借助Douwe Kiela（RAG技术的先驱之一）所提出的十个极具价值的经验，来和大家探讨如何有效地实施RAG。
上下文悖论
莫拉维克悖论，亦称情境悖论，揭示了一个有趣的现象：对于计算机来说，完成人类认为较为复杂的任务（例如下棋）往往比执行那些被视作简单的任务（如行走、感知）来得更为简单。
实际上，这一看法与RL领域的奠基人Rich Sutton的某种理念颇为相似，即仅凭强大的计算能力，通用方法终究能够以绝对的优势脱颖而出。
他特别强调指出，AlphaGo/GPT-3之所以取得显著成就，并非因为其复杂的规则设定，而是得益于强大的算力基础，这背后是简单高效的算法（即神经网络与海量数据的结合）。
类似的情况在大模型领域正在发生：
大型语言模型（LLMs）在编写代码、破解数学难题等多个领域展现出令人瞩目的能力，有时甚至超越了众多人类。不过，在处理及领会语境方面，它们仍旧遭遇了不少困难。
人类，尤其是那些领域的专家，往往能轻松地运用他们多年累积的专业知识及敏锐的直觉，将信息或问题放置在恰当的背景之中。
关于上述问题的成因，我们之前已经进行过讨论：人工智能在处理结构正确且范围有限的集合方面具有特别的优势。
AlphaGo的胜利源自围棋规则的公开性以及其有限的状态空间这一特点。
然而，大型模型在训练过程中本质上存在缺陷，这主要是因为所使用的语料库不完整，亦或是信息本身存在缺失。
知识与数据构成了对现实世界的描绘，然而，众多深藏不露的智慧并未被记录下来。以医生为例，在诊断病例时，他们不仅参照临床手册，还运用了大量的个人化知识，诸如：
1. 患者微表情解读（疼痛忍耐度）；
2. 社会经济因素权衡（治疗方案可行性）；
3. 伦理判断（生命质量 vs 延长寿命）；
这构成了当前人工智能领域难以逾越的难题：由于隐性知识难以被系统化整理，这直接导致了用于训练的数据在本质上存在不完整性。
综上所述，实际上所呈现的效应便是所谓的语境矛盾现象。我们常认为AI在处理复杂任务时表现优异，比如在处理数十万数据的查漏补缺方面；然而，对于看似简单的任务，如模拟人类进行聊天，AI的表现却显得不尽人意。
这同样成为了众多企业面临的真实困境，即如何使模型更有效地吸收并理解公司内部的知识，进而将其准确表达，以下列举了十个至关重要的经验教训。
此外，我浏览了Douwe Kiela提出的十个教训，发现其中一些与我去年归纳的要点存在共通之处。
工程大于模型
系统优先于模型，这实际上已成为我去年最为重要的心得体会。
在AI项目的实施过程中，工程技能构成了真正的挑战，这主要是因为这类项目的持续时间较长；往往到了项目后期，人们才会意识到对工程技能和项目管理技能的需求尤为迫切。
以行业应用为参照，每一套应用背后都隐藏着成百上千个标准操作流程（SOP），而如何对这些SOP进行有效组织，将成为人工智能应用所面临的核心挑战。
众人对于此项目的挑战程度实际上并不了解，根据以往的经历：每个操作流程（SOP）需要5000到10000字的详细说明，而一个复杂的AI项目至少涉及50个这样的操作流程。
这意味着你需要写25万50万字的提示词！而这还算简单的……
在这数十万条提示词中，将涉及大量本地数据及外延数据的处理，同时，还需构建一个能够实现循环升级的飞轮系统。
因此，在AI项目实施过程中，所面临的工程挑战通常要远超模型本身的复杂性，故而务必精确界定模型的应用范围。在我参与的众多AI项目中，模型的应用比例通常不超过三成，且随着使用量的增加，其稳定性也会相应下降。
最后提一点，AI项目的工程难度80%都在数据工程……
垂直而不是通用AI
专注于AGI领域，企业能够掌握宝贵的组织智慧与专业人才的经验。通用型AI助手在应对公司内部专家时往往难以比拟。若企业意图攻克那些极其复杂、高度专业化的难题，专业化发展是不可或缺的途径。
这段话我简单为大家进行一番直译，大致意思是：在专业领域，人工智能才是关键所在，比如Manus只是个玩具，而Cursor才是真正能够解决问题的工具。
这实际上已成为业界共识，正如近期红杉AI大会上所提出的观点：在企业级市场领域，率先崭露头角的或许并非通用的巨型模型，而是像Harvey（法律）、Open Evidence（医疗）这样的专注于特定领域的智能操作系统，因为它们擅长辨识行业术语，并能深刻把握实际需求。
他的观点提出后，似乎显得有些不够深入，因此我打算为大家详细阐释一下何为专业化：
此SOP/Workflow体现了专业化特点，其核心正是我们所称的行业专业知识。
数据是壁垒
数据构成你的护城河，这一点我们去年也曾讨论过：目前，在各个公司之间，以及不同产品之间，并不存在真正的技术障碍，因为这些障碍实际上都是基于大型模型的……
这里以IBM Watson先前投入大量资源建设的医疗领域知识图谱为例，目前若重新进行构建，其所需成本或许仅为之前十分之一的水平！
技术不再是壁垒，而数据可能变成一个公司最大/最后的壁垒。
众多企业普遍认为，在应用人工智能之前，必须投入大量时间去清洗和整理数据，然而这种做法往往并不现实。实际上，关键在于使人工智能具备处理海量、杂乱无章的真实企业数据的能力。一旦实现这一目标，企业便能获得独特的价值和竞争优势，因为这样的数据正是构成其“护城河”的关键所在。
这里的情况较为复杂，需要为大家进行解释：这里所涉及的数据不仅包括结构化的信息，而且还涵盖了公司日常运营中产生的各类非结构化业务数据。
公司必须充分利用这些数据，以此为基础打造一个业务循环系统，进而持续扩大与对手在用户体验方面的优势。
AI项目的非对称性
飞行员操作简单，而生产过程则充满难度。依托现有框架，构建一个简易的RAG试点项目并非难事。你或许能迅速搭建起一个系统，将若干文档纳入其中，服务于少量用户，并收获正面的评价。然而，当尝试将此系统推广至实际生产环境时，却会遇到诸多挑战。
以我们过往的实践为例，我们必须格外留意AI项目的非对称性。你可能在短短一周内就能打造出一个得分70分的演示版本，从而赢得老板和同事们的赞誉，然而，令人遗憾的是，即便如此，半年之后，你的AI项目可能依旧停留在70分的水平。
由于生产环境需处理数十万至数千万份文件，服务于成千上万的用户，你可能需应对数万种不同的应用场景，同时还要满足企业级的安全与合规标准。
将试点规模扩大至此程度，众多现有的开源工具已无法满足需求。故而，设计工作需从第一天开始就着眼于实际生产，而不仅仅追求试点的短期成功。
实际上，这条建议看似作用有限，原因在于它着重强调的是首条建议；AI项目的挑战主要在于工程领域，而文中所述的各个方面均涉及工程设计中如何处理数据工程的相关问题。
快速迭代
追求速度胜过完美，在RAG Agent的生产部署阶段，速度显得尤为关键。这要求我们尽快将产品推向实际用户，以便收集他们的宝贵意见。
在产品开发初期，无需追求极致的完美，只要确保其具备基本的使用功能即可。
通过不断优化，产品才能逐步提升至“足够优秀”的境界。若过分拖延，执着于完美，则可能让从试验阶段过渡到量产阶段的过程变得更加艰巨。迭代是众多企业成功部署AI技术的核心要素。
在AI时代，竞争的核心已从产品功能的较量转变为对试错效率及资源掌控的争夺，而在这一阶段的胜负往往取决于企业对市场变化的响应速度和其固有的综合实力。
实际上，这听起来似乎很容易，但实施起来却极为复杂。因此，企业也必须面对一个担忧：我目前投入大量资源所获得的技术领先地位，是否会在半年后因为模型更新，或者大公司推出一款新产品，而瞬间消失殆尽！
速度往往与成本挂钩，以FastGPT、GPTBots等平台为例，它们的更新迭代速度相当迅速，但与Coze相比，就显得微不足道了。
这里的重点在于：速度的快慢是一方面，然而，精准地找到差异化的定位，实现足够的垂直化，或许才是最为关键的因素。
自然，就RAG技术而言，其核心目的依然是迅速获取准确信息，以便构建飞轮系统，但这一目标在现实中的重要性并不显著。
别搞工程师
在Engineers on Value的语境下，应避免让工程师将大量时间投入到枯燥乏味的事务中，他们的精力不应被分散在细分策略、提示工程等基础优化层面。
实际上，这竟是我唯一未能理解的建议；分块策略、提示工程等基础的优化任务，工程师们不涉足，旁人也难以胜任……
根据以往的经验，若想使一个AI项目实现良好的盈利，往往需要对细节进行精确的控制。
此外，在我观察到的十几家公司中，提示词呈现出较高的密集度，并非任何人都能随意撰写。
根据我个人的经历，工程师的职责在于持续进行微调，进行各式各样的微调，对众多小细节进行修改……
使AI易于消费
让人工智能变得易于使用，众多企业已成功将生成式AI引入生产领域，然而令人意外的是，真正使用这一技术的用户数量可能极为有限，甚至可能一个也没有。
这一点与RAG技术并无太大关联，因为AI知识库必然会在生产环境中得到应用，否则企业投入如此巨额资金有何意义……
赢得用户，创造“哇”时刻
获取使用体验，保持用户粘性，这一条与RAG技术并无直接关联，并未解决提升AI智能水平的问题，似乎是在挂羊头卖狗肉。
关注不准确性，而非仅关注准确性
不再仅仅是关于精确度，这一点至关重要，然而它与RAG似乎并无直接关联：可观察性相较于精确度显得更为关键。在确保了基本的精确度之后，我们的焦点应转向归因的追踪、审计的跟踪以及错误的剖析，随后，还需构建起一个反馈循环监控系统，以此确保合规性并不断推动改进。
在AI领域，实现百分之百的精确度可谓是遥不可及。即便能够达到九成或九成五的准确度，企业当前所关注的焦点已转变为如何应对那剩余的5%至10%的不准确数据。面对错误，企业该如何采取应对措施呢？
除了对基本准确性的要求之外，处理不准确性的方式至关重要，这要求具备可观测性。必须对系统的表现进行细致评估，并确保存在恰当的审计记录，特别是在那些受到监管的行业中。
审计过程能够记录下模型得出某一结论所依据的具体文件信息，在RAG系统中，这一功能被称为归因。归因机制在应对不准确的结果以及查找问题根源方面扮演着至关重要的角色。
除此之外，我们还可以通过后续的处理步骤来验证系统输出的声明，以此保障归因信息的准确性。
这一规定至关重要，甚至超出了RAG框架的范畴。然而，作者的表达相当晦涩难懂，许多同学可能难以理解。为此，我将通过举例进行阐释，并计划在后续的文章中做详细说明。
追求百分百的翻译精确度是不切实际的，关键在于识别错误所在、探究错误原因以及找到改正的方法。同时，还需确保技术体系形成一个封闭且可复制的循环。
深度解析 “可观测、可提高”
这里是一个财务+AI的真实AI发票审核的场景：
张三出差上海 2 天，提交报销：
1. 高铁票：¥553
2. 酒店：¥ 800 / 晚 × 2 晚
3. 网约车：¥150
4. 发票：全部上传（酒店发票为增值税普通发票）
若由AI直接执行，很可能一次性就能顺利通过，然而在人工进行复核时，问题便显现出来。
这四个错误需被送回AI工程进行修正，今后在类似情境下，系统务必确保结果的准确性。
此处问题易于识别，项目易于升级，风险易于规避，若能提升精确度，便至关重要，进而可构建一套简便的操作指南。
这里的实现过程相当复杂，大家只需明白这个道理即可，不必深究细节，感受一下即可。
Be Ambitious
保持雄心壮志。
咱们又开始分享励志故事了，这回与RAG技术并无直接关联。事实上，我们之前已经提及，人工智能项目的挑战主要在于处理复杂且持续时间较长的工程管理工作。
AI项目表现波动不定，时而出色时而逊色，我们无法因此影响情绪，需迅速搭建起高效运转的循环系统……
结语
自年初DeepSeek的发布至今，已经超过半年时间，众多企业仍旧在市场深处默默探索：表面看似风和日丽，实则水下正酝酿着惊天的策略。
然而，尽管众人高呼2025年是AI的元年，但在实际的开发实践中，许多团队甚至未能攻克RAG这一难关，目前市场上充斥着众多徒有其表的Agent……
依据个人实际体会，切莫被众多新颖的AI术语所迷惑，更不要被“RAG 已死”这类耸人听闻的标题所误导，目前最为切实可行的做法仍旧是：
将整个业务操作规范（SOP）融入工作流程中，即便提示词略显生硬也无妨。
2. 把审计链闭环跑通，先攒可观测数据再谈花式推理；
清理自家未分类的资产——一旦数据循环转动起来，与他人的差距便会自然而然地显现出来。
待到下一版RAGFlow将Agent完全融入其中，你便会发现：如今这段看似摇摆不定的时光，实则是在为下一轮的爆发奠定坚实的基础。
到那时，或许论文内容仍旧平淡无奇，然而你的生产环境却已悄然将准确率、可观测性以及迭代过程这三者紧密结合，使之运转流畅。
