最近上手体验了很多智能体，觉得AI还是有使用门槛，对使用者的某些知识素养、表达能力都有要求。AI目前可以替代一定的技能和操作，但是不能补充使用者的知识和经验。所以，该学习还是要学习，该练习也还是得练习。要不然AI做错了你也不知道，做不出来你还不知道怎么骂他。而且大部分人都是从商业角度看大模型，觉得遍地都是商机，如果从用户角度看，很多机会就不成立了。
举个?，用LLM做线上问诊，看似提升患者交互体验，还能把模型卖给几百家互联网医院使用，是个好机会；实际发现患者要花费大量时间打字与bot多轮对话，相比现在的“点选”操作，体验不升反降。
大公司都在搞LLM，算法/算力大差不差，后续竞争在数据，一方面是原有数据积累，更重要的是在比拼谁可以更快构建数据正循环，通过使用获取反馈+数据，进一步优化模型效果
不管是垂直还是通用大模型，一定要争做第一名，毕竟用户只会选择最好用的，没人会委屈自己单一AI如果不让人满意，组合使用做成“AI工作流/流水线”似乎是一个思路。但是考虑到AI生成的结果不一定稳定，“AI工作流”比起人原本熟练的工作流，究竟更方便还是更废事儿，不好说。现有的这些所谓的 agent workflow，本质上是把一个大任务拆分成很多个子任务，每个子任务都有明确的 input 和 output，自己定义一些变量和接口，把这些子任务串起来。这种方式很像是早期的自动驾驶，把感知和规控分开解，或者是上一代的语音助手，把语音转文字、LLM、语音合成这些工作流串起来。现在的agent workflow，速度慢先不说，最大的问题还是在接口的地方把信息降维了。这些 input / output 的接口和变量，本质上都是把信息降维到人能理解的维度，这是以高维信息的损失为代价的。每多一层 workflow，损失的信息就多了一次。面对简单问题时， agent workflow 或许是可行的，但它注定无法解决复杂问题。当然如果从现在的市场环境中理解的话，agent workflow只是现阶段模型能力不足情况下的过渡方案，因为好歹要有个生产可用的产品形态告诉用户、老板、投资人们这次LLM不是吹泡泡，包括现有所谓构建Agent的智能体平台也是同样：需要手动创建流程+设置知识库+调用三方插件+定制响应结构。并且这种方式是最容易拿到稳定结果的方式，在很多场景下，比起偶尔获得90分惊喜，更需要的是稳定的获得70分+的结果。像是梁宁过往强调的那样，用户需要的是一种确定感。从用户视角出发，你是用什么方式来解决问题，是不是充分的AINative产品，是不是理想的Agent，根本不重要。重要的是，能不能稳定的持续的，较好的解决问题。我始终觉得每一个 Agent 应该是独立的智能体，拥有自己的 memory, planning, tool use 等能力，能够端到端地解决问题，而不是需要人类按照自己的理解一口口地把饭喂到嘴里。之前在想，大模型的能力基本都差不多的情况下，那上层应用是否会面临门槛低、天花板小的问题？这个问题正好昨天看了一篇文章，文章中介绍核心资产还是在数据层！首先是个人数据。今天的AI应用与十年前相比有很大的不同，十年前的应用是同质化的标准产品，应用内个性化的成分很少，除了可能发个性化广告，产品仍是标准化的。然而，今天的AI必须尽可能收集用户的数据，因为AI回答的所有问题，都是根据用户当前输入的内容，再加上过往与用户交互的历史记忆，给出一个它认为最好的答案。数据积累非常重要，如果数据积累达到了一定壁垒，即使大模型能力相似，因个人数据了解程度不同，带来的体验也完全不同。其次是基于上下文的数据。自动驾驶汽车会时刻将摄像头和所有激光雷达、毫米波雷达数据收集到一起，在极短时间内做出转弯、加速或刹车等决策。它无时无刻不在收集这些上下文数据，而今天的大语言模型针对这类数据的收集仍基本处于手动状态。一个好的应用应该以最方便、最不需思考的方式收集上下文数据，更好地服务用户，这样的应用才是好应用。第三是协作数据。假设一个AI产品在用户个人数据积累方面尚未形成壁垒，此时市场上出现了一个更优秀的竞品，用户很容易切换过去。但如果该AI产品需要用户与同事共同使用，切换就变得困难许多，因为需要共同切换，这大大提高了切换成本。我们认为未来的AI应用必须考虑协作数据的整理。数据整理加上大模型本身能力的提升，有机会通过问答方式让AI具有商业价值并变现。如果涉及自动化，不可避免地会涉及新AI与物理世界的交互，这就是今天具身智能领域非常火热的原因。有钱：就搞基建，使用微调，因为微调是需要算力的，周期较长RAG实际上我们并没有去改变我们的这个大模型，而是在当前这个模型基础之上增加了一些外部知识。然后在使用这个模块去回答我们用户的问题；但是相反我们的微调的话，它是基于一个给定的大模型，再结合知识来去改造这个大模型，所以这个大模型的话它是一个新的大模型，也是被我们微调过的，然后我们再基于这个大模型来去回答我们用户的这个问题，所以说这是这两个概念的话， RAG 和微调它是两个完全不同的一个什么不同的一个套路。所以简单来说 RAG 里面的大模型是没有被训练的，但是微调里面的话我们是需要训练这个大模型的微调是指在预训练模型的基础上，使用特定任务的数据集对模型进行进一步训练的过程。预训练模型通常在大规模数据集上学习了丰富的语言表示，微调则是在此基础上针对特定任务进行优化。1. 特定任务优化：*当你有一个特定的任务，比如情感分析、命名实体识别、文本分类等，并且你有足够量的数据来训练模型时，微调可以使得模型在该任务上表现得更好。2. 性能提升：如果预训练模型在你的任务上表现不够好，通过微调可以进一步提升模型的性能。3. 资源充足：微调需要一定的计算资源和时间，因此在资源允许的情况下，微调可以带来更好的效果。本质：就是LLM+外部数据。通过引入外部数据，来进一步增强大模型的能力。实现方案：用户输入了一个问题，先去向量数据库中查询，查询得到结果后，用给大模型写提示词的方式讲用户的问题和结果一起输入给大模型，然后大模型输出后，再统一反馈给用户。这其中就涉及到一个知识库的使用流程。目前我在使用各家智能体的时候，基本知识库的流程是这样子的。通过使用，发现对于知识库的上传和分段，其实成本还是很高的，需要有一定的基础能力，对于小白直接上手有一定操作成本。
使用场景：一般适用于数据更新频率较快，可以用rag技术解决1. 知识密集型任务：当任务需要生成包含大量事实信息的文本时，比如回答问题、撰写摘要等，RAG可以利用外部知识库来提高生成内容的准确性和丰富性。2. 数据不足：如果你没有足够的数据来微调一个大型的语言模型，RAG可以利用检索机制来弥补数据的不足。3. 实时更新：RAG可以实时检索最新的信息，这对于需要反映最新数据或事件的任务非常有用。第一个场景就是我们的动态数据：这里的动态数据的话就指的是我们经常会变化的数据，就比方说像某某企业里面的一些业务数据，那为了满足这个场景实际上更适合，显然肯定是RAG，那如果说在这个场景当中我们用微调的话，你每次把这个数据一改变，我们每次都要去微调这个模型的话，那显然这个成本其实肯定不划算第二个场景的话就是模型能力的定制：就比方说我们在开发的时候，我们希望模型具备一定的特殊能力，就比如说他以特殊的口吻去跟用户进行交流，那这种能力的话，可能这个基座模型他没有具备，那显然这个时候我们更适合的甚至是微调，就比如我们的模型需要去阅读一些经营的研报，需要或者需要去抽取一些内容等等啊。第三种场景的话就是幻觉：实际上 RAG 和微调的话对于幻觉它都是有帮助的，它可以降低我们模型的这个幻觉，但是从一个效果的角度来看的话，那这个 RAG 对于模型的价它要大于这个微调。第四种场景的话是可解释性：就有个时候我们希望这个模型具备一定的可解释性，从这个角度来讲的话， RAG 它是要高于这个微调的，因为微调很多时候它其实就是一个黑盒子，不太清楚他到底内部他是怎么工作的，而且出现了问题的话，我们很难去追溯得到为什么在某个单词的生产，所以这个时候的话，我们这个 RAG 肯定是我们什么首选。第五个场景的是成本的角度：很显然 RAG 也是我们的首选，因为 RaG 里面的话我们不太需要去训练我们的模型，我们只需要通过一个工程的方式把这个 RAG 的整个搭建流程的一些细节，把它搭建起来就 OK 了。但是微调的话我们需要去收集数据，然后进行微调，如果微调的效果不是很好的话，我们还要接着去做一些迭代，所以说它的这个成本的话是相对来说是比较高的。第六个场景的是依赖通用能力：大模型通用能力，就包括一些对话的能力，那在这个时候显然 RAG 是我们的首选。因为我们去进行模型微调的时候，本质上我们对大模型进行了改变，这种改变的话是不可避免的会导致我们原有的大模型能力有一些降低。第七个场景就是延迟：有的时候我们对延迟的要求比较高，那这个时候微调是我们的首选，因为 RAG 本身是因为包含了很多的一些流程，这个流程里面包像这个检索等各种流程，所以这些的话是比较耗时间的。所以说如果我们要求快速响应，肯定这个微调是我们的首选。 总的来说，RAG和微调各有其优势和适用场景。选择哪种方法取决于具体的任务需求和性能要求。未来的发展可能会探索两种方法的结合，以充分利用它们的优势，并改进大型语言模型的性能。
粤ICP备17114055号
支持私有云部署
