rag fine-tuning ai-agents llm architecture

RAG、微调还是智能体：选择合适的构建层级及顺序

RAG与微调与AI智能体：各自的功能、成本、延迟及故障模式、经验法则，以及一个展示构建顺序的人力资源助手。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 12 分钟2836 词

来源: RAG vs Fine-Tuning vs AI Agents: When to Use What in Real-World AI Systems

在几乎每一个大语言模型项目中，迟早都会出现两个问题。其一是应该检索文档还是对模型进行微调；其二是产品需要智能体还是只需更智能的提示词。令人惊讶的是，这两个问题的回答往往都很糟糕，而且不只是初学者会这样。有些经验丰富的工程师花费数周时间调优模型，只为让它记住那些通过检索功能半天就能获取的事实。还有些团队把原本只是问答端点的系统套上了智能体框架，仅仅因为那个季度的每次站会都在讨论智能体相关内容。

较为现实的情况是，检索、微调与智能体并非同一任务的竞争对手。它们各自解决不同的问题，而面向真实用户运行的系统通常会结合其中两种或全部三种技术，让每一种都发挥其优势。下文将介绍它们的工作原理、成本、团队可能出现的误用方式、各组件之间的协同关系，以及一个展示构建顺序的小项目。

每种技术的实际功能

检索增强生成

检索技术不会改变模型本身，仅调整模型在回答问题前所读取的内容。

当有问题出现时，系统会将其转化为嵌入向量，即对其含义的数值表示，然后在 Pinecone、Qdrant、FAISS 或 Azure AI Search 等向量数据库中查找含义最相近的已存储内容片段。这些片段会被作为上下文放入提示词中，模型便依据这些内容而非预训练时吸收的信息来回答。

其价值在于能够避免错误。当模型被迫从内部记忆中寻找答案时，尤其对于最新、晦涩或特定于某公司的主题，它最容易编造细节。在每次调用时都为模型提供参考文本，能使其基于当前信息进行推理而非猜测。

该流程具有固定的结构：获取文档、将其分割成多个块、对这些块进行嵌入、存储向量、执行相似度搜索（通常与关键词搜索结合使用），可选地对候选结果重新排序、组合提示词并生成结果。

微调

微调在性质上有所不同，而不仅仅是程度上的差异。预训练模型会继续在您自己挑选的示例集上进行训练，这些示例通常是能够体现所需精确行为的输入与期望输出对。模型的权重会发生变化，或者在使用LoRA和QLoRA时，会在冻结的基础模型之上调整少量适配器权重。

它在教授具体操作方式方面效果很好：比如语调、固定的输出格式、解决某一类问题的特定方法，或是处理那些已有数千个标注样本的领域中的边缘情况。其目的是重塑默认行为，从而无需在每个提示中重复相同的指令，而非添加新事实。

但对于那些不断变化的内容，它的效果就很差。每周都会更新的产品目录无法合理地存储在模型权重中，因为训练结束后知识就会固定，每次更新都需要重新进行训练。

智能体

智能体将模型置于一个循环中：观察、推理、行动、观察结果、再次推理，如此持续直至达成目标或触发停止规则。模型不再只输出单一答案，而是通过调用 API、函数、数据库及其他服务等工具来决定下一步该做什么，并将这些工具的输出作为后续决策的依据。

正是这个循环让一个仅能回答问题的系统转变为能够完成任务的系统。LangGraph、CrewAI以及手工编写的 ReAct 循环都实现了这一机制：模型先形成思路，选择工具，工具执行任务，结果返回到上下文中，然后循环重复，直到智能体判定任务已完成或达到步数限制。始终应当设置步数限制。

区分这三者的简洁方法：

检索功能负责提供正确的信息。
微调能够实现正确的行为表现。
智能体则能提供适当的自主程度。

对比分析

两者的差异体现在多个方面：

知识更新。检索是实时的，只需刷新向量存储即可。经过微调的知识在下次训练之前保持不变。而对于智能体而言，其知识更新情况取决于它们检索或调用的内容。
成本。检索的成本处于中等水平：包括嵌入向量、存储空间以及额外的输入标记费用。微调的成本则较高，因为需要处理数据筛选、计算资源、GPU使用时间以及评估工作。智能体的成本则介于中等与较高之间，因为每项任务都需要多次调用模型，同时还涉及工具使用费用。

复杂性。检索需要分块处理、嵌入技术以及搜索参数的调整；微调则需要数据准备、训练基础设施、评估流程以及防止过拟合的措施；智能体则需具备规划能力、工具集成功能、错误处理机制以及循环控制能力。

部署时间。检索需要数天时间，微调需要数周时间，而智能体的部署时间则根据工作流程不同，从数天到数周不等。

最适用场景。检索方面适用于问答系统、文档搜索以及信息关联；微调方面适用于语气调整、格式优化以及领域推理；智能体则适用于多步骤任务、自动化处理以及工具调用场景。

延迟。检索会增加一次处理步骤，通常耗时50至300毫秒；与基础模型相比，微调在推理阶段不会增加额外延迟；智能体往往需要经过多个处理步骤，每项任务可能需要数秒时间。

维护。检索意味着保持知识库的时效性。微调则是指随着需求变化而定期重新训练模型。智能体则涉及更新工作流程、工具及提示词。

常见故障。糟糕的检索会导致出现无关的上下文和错误的答案。过拟合会使经过调优的模型在面对陌生输入时变得脆弱。智能体可能会陷入循环，调用错误的工具，或导致成本无限制上升。

三种情况，各对应一种解决方案

在产品文档之上添加支持聊天机器人更便于信息检索。那些拥有400页文档、变更记录和政策文件的软件公司可以对这些文本进行微调，但调整后的模型在下一个版本发布时就会过时。将每段文本嵌入向量存储则可以避免这一问题。当客户询问API是否支持批量请求时，系统会提取最相关的三个部分，模型基于这些部分给出答案并标注对应的页面。下次迭代更新文档后，只需重新嵌入数据即可更新答案，无需再次进行模型训练。

面向文档风格的写作助手适合进行微调。某媒体公司要求摘要必须遵循特定风格：固定的句子节奏、不得使用第一人称，且开头需列出固定数量的要点。通过提示词引导可以接近该风格，但长时间使用后仍会出现偏差。通过对约2,000对经人工编辑的摘要进行训练，该模型能够稳定输出符合品牌要求的文本，无需在每次请求中都粘贴风格指南。

候选人筛选适合由代理来完成。某招聘初创公司希望设定规则：若候选人符合条件，则对其进行筛选并安排通话，后续流程自动推进。代理会阅读简历，通过内部评分API对照职位要求进行核查，查看招聘经理的日程表，撰写并发送日程安排邮件，最后在申请者跟踪系统中记录结果。所有操作仅需一条指令即可完成，无需人工逐一处理每个步骤。

在实践中，这种分工模式反复出现：以数据检索为主的设计负责基础处理，代理负责整体协调，而仅在提示词无法稳定控制行为时才会进行微调。

它们如何协同工作

这三者并非相互独立的层次。功能最强大的系统会将它们串联起来，请求从负责规划的智能体开始，经过提供事实信息的检索环节，最终传递给经过调优的模型以生成输出内容。

User Query
    ↓
   Agent (decides what needs to happen — plan the steps)
    ↓
   RAG (retrieves relevant knowledge, if the step needs facts)
    ↓
   LLM (fine-tuned, if tone/format/behavior consistency matters)
    ↓
   Action (respond to user, call a tool, trigger a downstream workflow)
    ↓
   Agent (evaluates result → loop again or stop)

在支持服务场景中，其运作流程如下：有消息送达后，客服人员会判断其意图，得出需要产品信息的结论。检索系统会调出相关的文档片段。经过微调的模型会以品牌风格撰写回复。随后客服人员会判断回复的可靠性是否足够高，可以自动发送，还是需要人工介入，最后将整个交流过程记录在CRM系统中。

若缺少其中任何一部分，都会出现漏洞。没有客服人员的检索系统无法决定何时进行查询、何时采取行动。没有检索功能的客服人员对其训练数据之外的内容一无所知。没有检索功能的微调模型虽然能生成格式良好、看似可靠的回复，但这些回复可能已经过时。

各环节的成本

以下数字仅作为参考，实际费用会因规模和服务提供商的不同而有所差异。

在检索方面，前期成本在于语料库的嵌入，可以一次性完成，也可以随着文档量增加而逐步进行。运行成本则包括按不同定价层级提供的向量数据库托管服务，以及每次请求时为检索到的上下文所需的额外令牌费用。这是实现相应价值的最经济方式，也是大多数团队应首先采用的方案。

在微调方面，最大的前期投入往往是数据：收集并标注高质量的训练样本成本很高。其次是训练和评估阶段的计算开销。之后，一旦需要改变模型行为，则需要重新训练；除非使用基于共享模型的LoRA技术，否则还需为自定义模型支付托管费用。这种方案需要最大的初始投资，且对错误容忍度最低，因为劣质的训练数据会直接将不良行为体现在模型权重中。

对于智能体而言，设置工作包括流程设计、工具集成以及故障路径测试。运行成本则是隐藏在背后的问题，因为每个智能体步骤都意味着一次模型调用。一个包含五步的任务其成本可能是单次检索查询的五到十倍，而如果没有迭代次数限制的循环则可能导致成本失控。成本反映的是任务的复杂性，而不仅仅是使用量。

实际来看，检索通常是减少幻觉最经济的办法。只有当一致的行为是产品的核心需求而非附加功能时，微调才能带来成本回报。只有当任务需要多次决策和操作时，智能体的高成本才有合理性，而若一次合理的调用就能解决问题，则无需如此高的成本。

选择时的经验法则

当数据频繁变化时，选择检索方式。每周或每天都会更新的文档、政策、产品目录、价格信息及库存数据非常适合采用此方式，而不太适合微调。
当行为比知识更重要时，选择微调方式。如果模型虽然了解相关领域，但在得到良好提示后仍持续使用错误的语气、格式或推理模式，那么问题就出在行为层面。
当任务需要在现实世界中执行多个步骤或操作时，选择智能体方式。单纯回答问题并不需要智能体，但需要确定应执行的任务并跨系统完成时，则需要智能体。
当既需要基于事实的回答又需要一致的语气时，结合使用检索与微调方式，这在面向客户的产品中十分常见。
当任务需要事实信息同时还需要决策能力，且由智能体决定查找什么内容以及何时采取行动时，结合使用检索与智能体方式。

仅当使用智能体更为时尚时才考虑使用它。如果一个设计良好的提示语加上一次检索就能解决问题，那么智能体只会增加延迟、成本和出错概率，却没有任何好处。

同样的逻辑可以用两个简短的流程图来表示。第一个流程图用于判断答案是否依赖于那些经常变化的信息。

Does the answer depend on information that changes often?
   YES → RAG
   NO  ↓

第二个问题涉及行为一致性，以及任务是包含多个步骤还是实际操作。

Does the model need to consistently behave/sound a certain way,
and prompting alone isn't holding that consistency?
   YES → Fine-tuning
   NO  ↓Does the task require multiple steps, tool calls, or real actions
(not just answering a question)?
   YES → Agent (likely combined with RAG, and fine-tuning if voice matters)
   NO  → A single well-prompted LLM call is probably enough

一个展示该系统运作方式的小项目

以内部人力资源助理为例。

首先从信息检索开始。将员工手册、休假政策及福利相关文件存储到向量数据库中。员工随后可以询问自己可享受多少病假天数，就能得到有依据、有引用的答复。这种方式能解决大约70%的用例需求，且只需几天时间。
只有在出现不足时才进行微调。假设人力资源部门希望每条答复都带有特定的共情语气，并遵循“这里是政策内容，这是其对您的具体含义”这样的严格格式，但实际生成的答复却总是偏离这一标准。此时，用几百组经过筛选的、符合该风格的问答对对小型模型进行微调，就能弥补这一不足。

为多步骤任务添加智能体。申请下周五休假并非简单的查询操作，而是需要依次执行检查休假余额、查看团队日历以确认时间冲突、提交申请以及向员工确认回复等操作，每一步都属于一次工具调用。智能体在处理过程中会利用检索层来解答政策相关问题，并借助经过微调的模型来确定最终回复的语气。

这样的顺序是有意为之的。首先使用检索层是因为其成本最低且能处理最多信息。只有在出现实际的行为差异时才会进行模型微调。最后才启用智能体，且仅限于那些确实需要多步骤处理的任务。

常见错误

在需要检索时进行微调。当实际问题无法获取最新信息时，团队试图将相关知识嵌入模型权重中。这样一来，处理速度会变慢，成本也会大幅上升，而且一旦部署就会立刻过时。
缺乏明确工作流程的智能体。模糊的目标加上无限制的工具会让智能体行为混乱、反复无常且难以预测。有限的工具、明确的停止条件以及合理的推理步骤限制能够使其保持有序，而仅仅要求其自行解决问题并不能替代明确的流程。
忽视延迟与成本问题。每一次检索操作和智能体的每一步行动都会带来额外的数据传输和计算成本。演示时可能表现优异，但实际应用中却可能需要12秒的时间以及6次模型调用才能得到一个答案。

将选项视为阶梯式结构。这三种方法中没有哪种比其他更高级。最佳的系统就是最简单且能完成任务的那种，通常仅仅是检索功能，或者是在检索基础上稍作调整的模型，远未到需要使用智能体堆栈的地步。

跳过评估环节。这三种方法都会悄悄出现性能下降：检索结果质量差、参数调整过度，或者智能体采取错误行动却无人察觉。在任何一种方法开始扩展之前，都应先建立评估集。

发展方向

行业显然正朝着智能体工作流方向发展，也就是那些能够自主规划、执行操作并跟进后续工作的系统。接下来的发展阶段则是混合模式：利用检索来获取答案，通过参数调整来稳定行为，再加上持久化记忆功能，这样智能体就能回忆之前的对话内容，而无需每次会话都从零开始。

我们可以明显看到，技术正从聊天机器人转向如今被一些人称为“AI员工”的系统——这类系统能够在不同工具间持续工作并随时间推进任务，而无需等待用户提问。要实现这一目标，并非取决于选择最炫酷的技术，而是要了解每个组件的优势，并有针对性地将它们组合起来，从最能解决当前问题的简单层面开始。

问题从来不是在检索、微调还是智能体之间做选择，真正的关键在于某个特定系统需要哪种组合，以及应以何种顺序构建它。