RAG 之父分享的十个 RAG 经验教训。

推理模型训练的现状。

Sebastian Raschka 最近写了一篇 blog，阐述了最近推理模型训练的现状。其实就像文中说的，最近由于发布的模型 GP4-4.5， Llama 4 都是传统的模型，不是推理模型，所以大家反应比较平淡。但是我的感受是，大家之所以感受平淡，是因为目前模型的能力已经超出了大多数人的使用场景，对于简单任务，够用了，再提升好像也用不上。对于复杂任务，不知道怎么用。

像极了在原有产品上添加 AI 的能力，添加 Agent 的能力，感觉很容易，操作起来很复杂，甚至结果也没有那么美好。最后还是当做谷歌搜索的平替版先用用吧。

但是一路读下来还是有着一些收获，读这类文章的好处就是，不断的以新的知识阐述的方式来磨合你原有的旧知识。比如图一，就是一个例子。这是 CoT 的一张图示表示，CoT 的目的就是显示的生成中间的推理结果。下面是一些 takeaways:

1. RLHF 其实包含两步，第一步是让人来对模型回复排名，用来训练一个奖励模型，图二。第二步就是使用 PPO 算法 + 奖励模型继续微调。图三。PPO的一个关键目的是，它尽可能的保证调整的参数，跟原有模型相比，不会偏离太多，毕竟还是微调而不是重新训练。

而更详细的 PPO 图四，其实涉及到了3个模型，一个是原始的模型，用来产生结果，一个是 RLHF 训练出来的奖励模型，用来打分，另外还有一个是 Critic 模型（value 模型），目的是预测奖励模型会对这个结果打分多少。这两个打分相减会得到一个差异，用来指导怎么更新原始模型的参数，避免过度奖励或过度惩罚。

而 Critic 模型一般回去评估部分的答案，同时也会一直更新。而奖励模型一般训练好了就不会改变了。

2. 从 PPO 到 GRPO。GRPO 是 DeepSeek R1 引进的，就是计算打分的差异不再通过是 Critic 模型和奖励模型分别打分的差异了，而是算一组的平均分，高于的就是差异。同时也把 Critic 模型去除了。图五。

3. 从 RLHF 到 RLVF。这点其实有点意思，在 RLHF 中，是有一个奖励模型的，用于模拟人来进行评分。但这 RLVF 去掉了奖励模型。图六。目的是为了让结果更加准确，用来最终的正确结果来验证而不是人类奖励模型，因为有误差。但是这个应该只能用于有正确结果的领域，比如编码，数学等。对于开放性的问题探索等，RLVF 并不实际。但文中没有提及。

最后如果这一切都结合起来看，其实还是回到了 DeepSeek R1是怎么训练的过程了。图七。

每个人其实都该练习去做一些自己不喜欢的事，而且还要尽量把它做好。不是说为了委屈自己，而是因为这是成长中很重要的一课。社会上很多事并不会照着我们的喜好来安排，如果我们只做自己愿意做的，就很难真正进步。很多时候，那些让人头疼、让人想逃避的事，反而最能锻炼一个人的耐心和毅力。能在不喜欢的事里坚持下去、把事情做好，这本身就是一种本事。出了社会以后，你会发现，责任往往不是你选的，而是你得扛的。所以如果你能把不喜欢的事也做得有模有样，那面对更多挑战时，你自然就更有底气了。

再次重读 - 构建有效的 agent。

anthropic 几个月前发布了一篇 blog，写的是如何构建有效的 agent，<build affective agents>。之前读过，更多是概念上的理解，也就是说知道有这个东西。

最近有机会在公司落地了一个 agent，同时看了几个 build affective agents 的作者的访谈，又重读了一下这篇 blog，理解上又不一样了。

先在看下 workflow 和 agent 的定义。如果做一件事可以拆分成多个固定的，明确的步骤，那么用代码串起来就是一个 workflow，因为它可预测，可观测，有确定性。

如果做一件事，有多个路径，甚至有很多开放的路径可以做这件事，那么就可以使用 agent，它做事情的路径是随机的，同时可以根据执行后的路径反馈进行调整接下来的路径，它基本无法预测，无法观测，确定性低。

所以开放性的事情就用 agent，确定性的事情就用 workflow。

另外一个概念是，什么是增强型的 LLM？一般的 LLM 其实就是 text-in，text-out，纯粹靠自己的知识理解。而增强型的 LLM，则可以开始搜索数据、使用工具和拥有记忆了，图一。

所以不论是 workflow 还是 agent，里面的 LLM 都是增强型的。

而对于我来说，一个 surprise 是，workflow 的模式很多，图 2-图 5，从顺序型到并发型，从路由挑选 LLM到可以让 LLM 编排 LLM，很多模式。 而 agent 的模式很少，基本就是一种，让 LLM 自己拆分任务，自己执行，自己检查结果后自己调整子任务，直到结束。

而 blog 的作者也说了，不要什么场景都直接上 agent，大多数情况下 workflow 都是最好的选择，而且一开始越简单越好。这个在我们落地一个图表助手上也验证了，我们按照了最简单方式来实现了一个 workflow，效果够用。

这可能是在原有 saas 产品上添加 agent 的最有效方式，同时不用大概底层逻辑和结构。

另一个作者则是表达了很多人可能低估了 workflow 和 agent 自动化带来的效果，如果一件事情只需要花 1 分钟，那么即使全部自动化了还是只省了一分钟，有什么帮助吗？

作者给出来的答案是，真正的作用是，这样的事情可以很快的做成百上千次。规模化。

MCP 跟 RAG 更近？

如果我们把 MCP 能做的事情抽象一下，无非就是数据的获取，以及触发一个动作，使得第三方系统可以发生变化（可以是一个 api call，也可以是写入一份数据）。

而对于数据的获取来说，我觉得更贴近 RAG，目的都是为了获取到足够多、足够准确的数据来当做 prompt 去让模型回答。

而对于操作第三方系统而言，实际上就是 MCP 的使用工具，比如发送一个邮件，发布一篇 blog。

所以在很多介绍 MCP 的文章是，看到的也是这两点，连接数据源和使用工具。

MCP 以及它可能带来的一些问题。

原文是 <Everything wrong with MCP>, 不是批判，而是整理可能遇到的一些问题。毕竟，即使 MCP 还是处于很早期的阶段（去年年底提出）但是已经不影响它成为 Agent 跟第三方工具和数据源打交道的一个标准了。

MCP 如果作为一个整体来看的话，像图1，那就是 MCP 允许 assistant 助手去调用一些外部的工具和数据源，来辅助它完成自己的工作。目前大部分的 assistant 其实都是 text-based 的大模型，而 MCP 则是提供了很多非文本性的操作，比如浏览网页，文件查找。

而 MCP 使用起来也不全是好处。其实 MCP 还一直在完善中，比如一开始它就缺少了身份认证，Claude assistant 怎么跟 MCP server 通讯的？MCP server 知道请求方式谁吗？它基本没有身份认证，也没有权限控制，甚至 Claude assistant 使用者只是员工权限，但是他可以问到他的老板的薪资。

同时 MCP 有点危险。其实这点更像是 agent 自带的 YOLO 特性，它可以自动的调用 MCP（工具），然后可以删除任何文件而不询问用户。同时，如果为了完整一件事，甚至会出现上面说的数据泄露。

另外，目前不管是 Claude desktop 还是 Cursor 这些assistant，它们使用 MCP 的方式都是下载对应的 MCP 代码到本地，直接运行，有可能会导致安装 MCP server 的时候把漏洞、病毒库也给安装了，会变的更加的不安全。

所以这一切对于我来说，怎么保证所用的 MCP 是可信的，就变成了另外一个问题，为了解决这些问题，MCP 会变得越来越复杂，比如后续 MCP 就加上了身份验证，那么集成 MCP 就变的更加复杂了。

RAG+Agent+MCP，最佳组合。

RAG，Agent 和 MCP 已经是当下开发 AI 系统的最佳实践了。

RAG 是让知识更可靠，Agent 是自动化决策，MCP 是让所有工具都能以一种方式使用。

如果只单纯剩下 RAG+MCP，那么 MCP 还是提供给 RAG 数据源的一种方式。

AI 在走通用模型道路，而产品未必。

曾经的 AI PPT 产品 Tome 宣布放弃 PPT 赛道了，转型销售助手，被后来者居上的 Gamma 击败了。

Tome 我曾经在一年多前用过，差不多它刚出来的时候我就使用了，当时还没有几个像样的 AI PPT 产品，而 Tome 可以根据我给的文本，生成好看的 PPT，而这个本来是很多人的弱项。

而当时我还成功使用了这个工具快速做了一个分享，当时的感受就是效率高。

可惜还是没有找到对应的 PMF，导致了转型。看到图片中他们在官方博客说的那段话，很有感触。

大家都在看 AI 是往 AGI 方向发展，能力越来越强，能力也越来越全。于是妄想现存产品+AI 后也是如此，想要自己的产品服务所有客户，适用所有场景。

特别是对于创业公司来讲，几乎就是一个致命的问题。更多时候不妨回过头看看，人家就二十几个人，但是产品成功了，究竟做对了什么？

即使是大模型，也是小模型在起作用。

看了赛博禅心的一篇 MoE 的架构科普文章，学习到几点新知识，这里记录一下。

首先，大模型的架构基本就是 dense 架构和 moe 架构，不管是什么模式，首先所有的模型参数都需要加载到显存中。

对于 dense 架构来说，任何一个用户任务，都需要激活全部参数参与完成任务。而 moe 架构则是选择出来对应专家（对应小部分参数），只激活这部分参数进行任务完成。

moe 架构来说，推理性能更高，但是部署上是跟 dense 架构一样的，所有参数入显存。这就解释了为什么我们看到的一些开源小模型，比如32B，性能上可以媲美大模型671B 的性能，比如代码，数学，推理等。

一方面是这些大模型比如 DeepSeek 671B，当它推理时，本身就只有一个或者几个专家被激活，平均每个专家大概就1-2B 参数被激活（比想象中的小）。最近刚发布的 Llama 4，也是类似，取决于多少个专家，每个专家激活的参数可以是3b，可以是17b 大小。