LLM增强系统设计：LoRA、RAG 与 Agent

发表于 分类于 Waline： 本文字数： 13k 阅读时长 ≈ 47 分钟

1. 从模型能力到系统能力

在过去几年中，大模型在自然语言理解、代码生成、知识问答等领域展现出惊人的能力。随着参数规模持续扩大，模型在零样本与少样本场景中的表现不断提升，许多任务甚至无需额外训练即可获得可用结果。然而，在真实的企业场景与复杂系统环境中，一个基础大模型往往并不足以支撑稳定、可靠、可控的智能应用。

问题并不在于模型“不聪明”，而在于模型的能力边界与实际需求之间存在结构性差距。大模型擅长语言模式建模，却不天然具备长期记忆、稳定执行、多工具协同、成本可控等系统级能力。因此，真正的挑战不是构建一个更大的模型，而是设计一套完整的模型增强系统。

本章旨在明确大模型的能力边界，提出“模型增强系统”的整体框架，并为后续关于 LoRA、RAG、Agent 以及多模型协作的讨论建立统一的逻辑基础。

1.1 大模型的三种核心能力与三类局限

从能力结构上看，大模型主要依赖三种基础机制：

  1. 统计语言建模能力。模型通过海量语料学习语言模式与知识关联，可以在给定上下文下生成合理的后续内容。
  2. 上下文推理能力。借助注意力机制，模型能够在一定上下文窗口内进行推理、总结与改写。
  3. 泛化能力。通过大规模预训练，模型具备一定的跨领域迁移能力，在未见任务上仍可给出近似合理的输出。

然而，这三种能力在工程实践中会暴露出三类典型局限。

  • 第一类局限是知识时效性与私有性问题。预训练数据存在时间滞后，且不包含企业内部资料。模型在面对最新信息或专有数据时，往往只能依赖概率性猜测。

  • 第二类局限是幻觉问题。当上下文不足或推理路径不清晰时，模型可能生成语义流畅但事实错误的内容。

  • 第三类局限是行动能力缺失。模型可以“回答如何操作数据库”，却无法真正执行数据库查询；可以“描述一个流程”，却不能管理复杂任务的执行状态。

这些局限说明，大模型本质上是一个强大的概率生成器，而不是一个完整的智能系统。 

flowchart LR

subgraph A["单模型能力"]
direction TB

M["大模型
概率生成系统"]

C1["统计语言建模能力
语言模式学习
知识关联
文本生成"]

C2["上下文推理能力
注意力机制
上下文理解
推理与总结"]

C3["泛化能力
跨领域迁移
未见任务处理
近似合理输出"]

M --> C1
M --> C2
M --> C3
end

subgraph B["工程局限"]
direction TB

L1["知识时效与私有性问题
数据时间滞后
缺少企业数据
概率性猜测"]

L2["幻觉问题
上下文不足
推理路径不清
事实错误"]

L3["行动能力缺失
无法执行数据库操作
无法调用工具
无法管理任务状态"]

end

subgraph C["系统级能力"]
direction TB

S1["知识更新机制
实时数据接入
文档检索
知识补充"]

S2["工具执行能力
数据库查询
代码执行
外部接口调用"]

S3["任务控制能力
任务拆解
流程管理
执行状态跟踪"]

S4["模型调度能力
多模型协同
能力分工
任务路由"]

end

A --> B
B --> C
图1-1 单模型能力与系统能力差异图
### 1.2 为什么仅靠 Prompt 无法解决系统问题 在实际应用初期，常见做法是通过不断优化 Prompt 来弥补模型不足。例如加入更详细的指令、示例、角色设定或输出格式约束。然而，Prompt 优化存在明显上限。 - 首先，Prompt 只能影响当前上下文，而无法改变模型的参数结构。当问题涉及专业领域知识或长期稳定风格时，仅靠提示词往往难以保证一致性。

  • 其次，Prompt 无法为模型提供结构化长期记忆。当信息规模超过上下文窗口时，必须依赖外部机制进行检索与选择。

  • 再次，Prompt 无法赋予模型执行外部操作的能力。工具调用需要明确的接口、参数校验与结果反馈机制，这属于系统层设计，而非文本层优化。

因此，Prompt 更像是一种交互优化技术，而不是系统增强方案。要构建稳定的智能应用，必须从更高层级进行架构设计。

1.3 大模型增强的五层架构

在系统视角下，大模型增强可以抽象为五个层级，每一层解决一种核心能力缺口。

  • 第一层为模型层，关注参数能力的专注化。通过 LoRA 等参数高效微调技术，使模型在特定领域表现更稳定、更精准。

  • 第二层为记忆层，关注知识的外部化与可更新性。通过 RAG 机制，将外部知识库接入生成过程，使模型获得动态记忆能力。

  • 第三层为行动层，关注工具执行能力。通过 Function Calling 等机制，使模型能够调用数据库、搜索引擎或业务接口。

  • 第四层为控制层，关注任务编排与状态管理。通过 Agent 机制，实现任务分解、循环执行与结果反馈。

  • 第五层为调度层，关注模型能力分配与协同。在多模型环境下，通过路由策略实现不同模型之间的协作与优化。

这五层并非相互替代，而是逐层叠加。模型层解决“懂不懂”，记忆层解决“知不知道”，行动层解决“能不能做”，控制层解决“如何持续做”，调度层解决“谁来做”。

flowchart LR
subgraph STACK[大模型增强五层架构]
direction TB

L1["模型层
Model Layer
参数能力专注化
LoRA / PEFT / 微调"]
L2["记忆层
Memory Layer
知识外部化与可更新
RAG / 向量检索 / 知识库"]
L3["行动层
Action Layer
工具执行能力
Function Calling / API / 数据库"]
L4["控制层
Control Layer
任务编排与状态管理
Agent / Planning / Feedback Loop"]
L5["调度层
Orchestration Layer
模型能力分配与协同
Router / 多模型协作 / 策略路由"]

L1 --> L2 --> L3 --> L4 --> L5
end

P1["解决问题：
懂不懂"]
P2["解决问题：
知不知道"]
P3["解决问题：
能不能做"]
P4["解决问题：
如何持续做"]
P5["解决问题：
谁来做"]

L1 --- P1
L2 --- P2
L3 --- P3
L4 --- P4
L5 --- P5
图1-2 大模型增强五层架构

1.4 从模型使用到系统设计

在简单问答场景中，直接调用大模型即可满足需求。但在企业级应用中，常见需求包括：

  • 需要接入内部知识库
  • 需要保证输出可追溯
  • 需要执行数据库查询
  • 需要控制成本与延迟
  • 需要管理多步骤任务

这些需求已经超越了单模型调用范畴，进入系统设计层面。以企业知识库问答为例，如果仅使用基础模型，可能出现以下情况：

  • 模型回答流畅但未引用真实文档
  • 不同提问方式导致答案不一致
  • 无法判断答案来源
  • 无法保证长期稳定性

当引入记忆层后，可以实现基于向量检索的知识增强；当引入行动层后，可以调用真实数据库进行查询；当引入控制层后，可以实现复杂任务的多步执行；当引入调度层后，可以根据问题类型选择不同模型进行处理。

由此可见，大模型的真正价值不在于参数规模本身，而在于如何被纳入一套结构清晰、可维护、可扩展的增强系统。

本章建立了一个核心观点：大模型只是系统的一部分。真正决定应用质量的，是增强架构的设计能力。后续章节将依次展开模型层、记忆层、行动层与调度层的具体实现机制，从理论原理到工程实践，逐层构建完整的大模型增强体系。

2. 让模型更专注：LoRA 与参数高效微调

本章先回到最底层——模型参数本身。在许多实际场景中，大模型已经具备较强的通用能力，但在专业领域、特定语气风格或业务规范下，仍可能出现回答不稳定、术语使用不准确或逻辑偏差等问题。此时，仅依赖 Prompt 优化往往难以获得长期稳定的效果。

参数高效微调技术，尤其是 LoRA 与 QLoRA，正是为了解决这一问题。其核心思想并非“重新训练一个模型”，而是在尽量不改变原始模型结构的前提下，注入少量可训练参数，使模型在特定领域更专注、更稳定。

本章将从全量微调的现实困境出发，逐步解释 LoRA 的原理、工程实践方式以及适用边界。

2.1 全量微调的现实困境

传统的微调方式通常采用全参数更新策略，即对模型所有权重进行训练。这种方法在早期小模型时代是可行的，但在当前数十亿乃至数百亿参数规模下，问题逐渐显现。

首先是计算资源消耗巨大。全量微调需要高显存 GPU 集群支持，成本极高。其次是存储成本增加。每个下游任务都会生成一套完整模型副本，难以进行版本管理。再次是过拟合风险。领域数据规模通常远小于预训练数据，全量微调可能破原有泛化能力。最后是部署复杂度上升。模型版本繁多，维护与回滚难度加大。

在企业场景中，往往需要为多个业务模块分别进行适配。如果每个模块都进行全量微调，资源消耗将呈指数级增长。因此，一种更加轻量、可插拔的适配方式成为必然选择。

2.2 LoRA 的低秩分解原理

LoRA 的核心思想来自线性代数中的低秩分解。其基本假设是：在下游任务中，模型权重的更新方向往往位于一个低维子空间中，而非需要对整个高维权重矩阵进行完整调整。

在 Transformer 中，权重矩阵通常规模巨大。例如注意力层中的投影矩阵维度可能为 d × d。当进行微调时，传统方法直接更新该矩阵；而 LoRA 则将权重更新表示为两个低秩矩阵的乘积。具体而言：原始权重保持冻结，仅引入两个小矩阵 A 与 B，使得权重更新近似表示为：
$$ΔW = A × B$$
其中 $A$ 的维度为 $d × r$，$B$ 的维度为 $r × d$，$r$ 为低秩参数。只需训练 $A$ 与 $B$，即可完成适配。

这种方法显著减少了可训练参数数量。当 r 远小于 d 时，训练成本与显存需求大幅下降。

flowchart LR
X["输入向量
x"]

W["原始权重矩阵 W
d × d
Frozen 不参与训练"]

A["低秩矩阵 A
d × r
可训练"]

B["低秩矩阵 B
r × d
可训练"]

DW["权重增量
ΔW = A × B"]

SUM["权重合成
W + ΔW"]

OUT["输出
(W + ΔW) × x"]

X --> W
X --> A

A --> B
B --> DW

W --> SUM
DW --> SUM

SUM --> OUT
图2-1 LoRA 权重注入结构图

该图展示 LoRA 在 Transformer 权重上的注入方式。原始权重矩阵 W 保持冻结，不参与训练；同时在旁路引入两个低秩矩阵 A 与 B。输入向量 x 一方面经过原始权重计算 W × x，另一方面通过低秩路径 A → B 生成权重增量 ΔW = A × B。最终 W + ΔW 共同参与后续计算，从而在不修改原始模型参数的情况下实现高效微调。

2.3 Rank 选择与表达能力边界

低秩参数 r 的选择直接影响模型的表达能力与训练效率。当 r 过小，模型更新能力有限，可能无法充分适应领域数据。当 r 过大，训练成本上升，同时可能引入过拟合风险。

在实践中，常见的 r 取值在 4 至 64 之间。不同任务对表达能力的需求不同，例如法律文本与医疗文本可能需要更高秩参数以保留复杂语义结构。

需要强调的是，LoRA 并不是在所有层都必须插入。通常优先在注意力层的投影矩阵中注入适配器，因为这些位置对语义表示影响最大。

合理的层选择与秩参数设计，是参数高效微调的关键工程问题。

2.4 QLoRA 与低比特量化机制

在 LoRA 基础上，QLoRA 进一步通过低比特量化降低显存占用。其核心思想包括两点：

  1. 将基础模型权重量化为 4bit 表示，从而大幅减少存储与计算开销。
  2. 仅对 LoRA 注入参数进行高精度训练。

这种混合精度策略使得在单张消费级 GPU 上微调数十亿参数模型成为可能。QLoRA 的关键技术包括：

  • 使用 NF4 数据类型表示权重
  • 采用双重量化策略减少精度损失

通过这些优化，微调成本进一步下降，同时保持与全精度训练接近的性能表现。

2.5 LoRA 的工程实践策略

在实际部署中，LoRA 具有以下优势：

  • 模型权重可共享，仅保存小规模适配器参数
  • 可针对不同业务加载不同 LoRA 模块
  • 支持快速切换与版本回滚

例如，在企业场景中，可以为客服场景加载“客服 LoRA”，为法律场景加载“法律 LoRA”，基础模型保持不变，仅切换适配模块即可。在推理阶段，可以选择将 LoRA 权重合并至主模型，或采用动态加载方式。

此外，需要注意数据质量控制。领域数据规模虽不必过大，但必须结构清晰、标注一致，否则模型会学到不稳定模式。

2.6 LoRA 的适用边界与失效模式

尽管 LoRA 在许多场景中效果显著，但并非万能解决方案。

  • 第一，当问题属于知识更新而非能力专注时，应优先考虑 RAG，而不是微调。

  • 第二，当任务频繁变化时，维护多个 LoRA 模块可能增加复杂度。

  • 第三，当数据极少或质量较低时，微调效果有限。

  • 第四，LoRA 无法解决模型固有推理能力不足的问题，只能在现有能力基础上进行偏移。

因此，参数增强层的目标是“让模型更稳定、更符合特定规范”，而非“让模型无所不能”。

本章围绕模型层展开，阐明了参数高效微调的原理与工程实践方式。下一章将进入记忆层，讨论如何通过 RAG 机制为模型引入外部知识，从而解决时效性与私有知识问题。

3. 让模型拥有“记忆”：RAG 的结构原理与工程实践

如果参数高效微调解决的是“模型是否专注于某个领域”的问题，那么记忆增强机制解决的则是“模型是否掌握最新、完整且可追溯的知识”。

预训练模型的知识来源于训练语料，具有时间滞后性与不可更新性。即使通过 LoRA 微调增强了领域表达能力，模型仍无法实时获取新增文档或企业内部资料。在这种情况下，仅依赖模型参数本身已无法满足系统需求。

检索增强生成机制，即 RAG（Retrieval-Augmented Generation），成为连接模型与外部知识库的关键桥梁。本章将系统分析 RAG 的基本结构、工程实现细节、性能优化策略以及常见失效模式。

3.1 RAG 的基本结构与流程

RAG 的核心思想是将“检索”与“生成”结合，使模型在回答问题前，先从外部知识库中获取相关信息，再基于检索结果进行生成。其基本流程可以概括为四个阶段：

  • 第一阶段，查询理解。用户问题被编码为向量表示。

  • 第二阶段，向量检索。系统在向量数据库中寻找与问题最相似的若干文本片段。

  • 第三阶段，构建提示。将检索结果与原始问题拼接成结构化提示词。

  • 第四阶段，生成回答。大模型基于扩展后的上下文生成最终输出。

这种结构的关键在于，模型不再完全依赖内部参数知识，而是通过动态检索获得外部记忆支持。

flowchart LR

U["用户问题
User Query"]

E["Embedding 模型
问题向量化"]

VDB["向量数据库
Vector Database
存储文档向量"]

R["相似度检索
Top-K 文本片段"]

P["Prompt 构建
问题 + 检索上下文"]

LLM["大模型生成
LLM Generation"]

A["最终回答
Answer"]

U --> E
E --> R
VDB --> R
R --> P
U --> P
P --> LLM
LLM --> A
图3-1 RAG 标准流程图

3.2 检索机制对比：倒排索引与向量检索

在信息检索领域，传统方法主要基于倒排索引结构，通过关键词匹配实现文档召回。这种方法在精确匹配场景中效果良好，例如法律条款查询。

然而，大模型应用更多涉及语义匹配。例如“如何优化系统延迟”与“降低响应时间的方法”在语义上相近，但关键词并不完全一致。此时，向量检索机制更具优势。

向量检索通过将文本映射为高维向量，在向量空间中计算相似度。常见相似度度量方式包括：

  • 余弦相似度
  • 点积
  • 欧氏距离

在实际工程中，往往采用混合检索策略，即同时使用关键词召回与语义召回，再进行融合排序，以提高召回质量。

不同场景对检索方式的选择存在差异。例如合规审计类任务偏向精确匹配，而技术问答类任务更依赖语义匹配。

3.3 Embedding 与文本切片策略

Embedding 模型的质量直接影响召回效果。如果嵌入模型无法准确表达语义关系，则检索阶段便难以找到真正相关内容。文本切片策略同样重要。切片过大可能引入无关信息，造成上下文干扰；切片过小则可能丢失完整语义。常见策略包括：

  • 固定长度切分
  • 基于段落或标题结构切分
  • 滑动窗口切分

在企业知识库场景中，推荐结合文档结构进行语义切分，使每个片段保持相对独立且语义完整。此外，应避免简单堆叠过多检索结果。上下文窗口有限，过多无关信息会挤占有效空间，降低生成质量。

3.4 向量数据库与索引结构

向量数据库的核心目标是在海量向量中实现高效近似最近邻搜索。常见索引结构包括：

  • HNSW 图结构
  • IVF 分桶结构
  • PQ 量化压缩

HNSW 基于分层小世界图结构，在查询时可以快速定位近似邻居，兼顾速度与精度。IVF 通过聚类将向量分桶，缩小搜索范围。PQ 通过向量量化压缩降低存储成本。

不同数据库实现对延迟与召回率的权衡不同。工程实践中需要根据数据规模、查询频率与精度要求进行选择。

3.5 召回优化与二阶段排序

初始召回阶段通常返回 TopK 个候选片段，但这并不保证排序完全准确。为提升质量，可以引入二阶段排序机制：

  • 第一阶段：向量相似度召回
  • 第二阶段：使用交叉编码器或小模型对候选片段重新打分

这种两阶段结构在提升精度的同时，会增加一定延迟成本，因此需要在质量与效率之间进行权衡。此外，可以通过 Query 改写、查询扩展或多路召回策略提升召回覆盖率。

3.6 延迟与成本拆解

RAG 系统的延迟通常由以下几部分组成：

  • Embedding 时间
  • 向量检索时间
  • 大模型生成时间

在多数场景中，大模型推理时间占主要比例，但当数据规模扩大时，检索时间也可能成为瓶颈。通过缓存机制，可以减少重复查询的计算开销。例如对常见问题缓存生成结果，或对常用文本缓存向量表示。

3.7 RAG 的典型失效模式

尽管 RAG 提供了外部记忆能力，但其效果并非绝对可靠。典型失效模式包括：

  • 检索结果本身错误或过时
  • 检索正确但模型未有效利用
  • 多跳问题无法通过单次检索解决
  • 检索结果之间存在冲突

此外，检索错误会直接传导至生成阶段，放大错误影响。

需要强调的是，RAG 并非替代长上下文机制的唯一方案。随着上下文窗口扩大，可以直接放入更多原始文本。但在大规模知识库场景中，RAG 仍具成本与效率优势。

本章系统分析了记忆增强层的结构与工程细节。下一章将进一步探讨 RAG 的局限性与进化方向，从而为后续行动层与控制层设计奠定基础。

4. RAG 的局限与进化路径

上一章系统分析了 RAG 的结构原理与工程实现方式。然而，在实际应用中，仅仅理解流程与技术组件并不足以构建稳定系统。任何架构都有其适用边界与失效模式。如果忽视这些问题，RAG 可能从增强机制转变为误导来源。

本章将围绕三个核心问题展开：RAG 在什么情况下会失效？错误如何在系统中传导？未来的改进方向在哪里？通过对这些问题的分析，可以为后续的 Agent 与多模型协作设计提供更稳固的基础。

4.1 RAG 的典型失效模式

在工程实践中，RAG 失效通常表现为三类情况。

  • 第一类是检索错误。向量召回结果与问题语义相关度不足，或者召回的文档本身存在错误信息。在这种情况下，模型生成的内容可能逻辑自洽，却基于错误事实。

  • 第二类是检索正确但未被有效利用。即检索到的文本是相关的，但模型在生成过程中未充分引用，甚至忽略了关键信息。这通常与 Prompt 构造方式或上下文竞争有关。

  • 第三类是复杂推理失效。某些问题需要多段推理，即从多个文档中提取信息并进行组合。如果 RAG 仅执行一次检索，往往难以覆盖完整推理路径。

例如，在企业场景中，某一问题可能需要同时查询制度文件与历史记录。如果只检索到其中一类文档，生成结果将缺失关键依据。

4.2 检索错误如何传导至生成错误

RAG 结构中存在一个关键特点：生成阶段高度依赖检索阶段输出。

如果检索结果中包含错误内容，大模型在生成过程中通常会默认其为“可信上下文”，并围绕其进行合理扩展。由于模型具备较强的语言流畅性，最终输出往往看似专业，却建立在错误信息之上。

这种现象说明，RAG 并不能完全消除幻觉，而是将幻觉来源从“模型内部知识不足”转移为“外部检索不准确”。

因此，在设计系统时，应增加检索结果的可追溯机制，例如：

  • 标注引用来源
  • 限制生成仅基于检索文本
  • 引入二阶段验证

通过结构约束，可以降低错误放大的风险。

4.3 长上下文是否可以替代 RAG

随着模型上下文窗口不断扩大，部分观点认为可以直接将大规模文档整体输入模型，而无需单独构建检索系统。从理论上看，长上下文确实能够容纳更多信息，但其局限同样明显。

  • 第一，成本问题。大规模上下文意味着更高的推理费用与延迟。

  • 第二，注意力稀释问题。模型在极长上下文中可能难以聚焦关键信息。

  • 第三，更新效率问题。若知识库频繁变化，每次都重新拼接完整文档，效率极低。

因此，在中大型知识库场景中，RAG 仍然具有明显优势。长上下文更适用于小规模、结构稳定的文本集合。

4.4 RAG 的进化方向

面对上述局限，RAG 技术正在不断演进。

  • 一种方向是引入图结构检索，即 Graph RAG。通过构建实体关系图，将文档之间的关联结构显式表示，从而支持多跳推理。

  • 另一种方向是 Agent 驱动检索。模型不再仅执行一次固定检索，而是在生成过程中根据中间结果动态发起多轮查询。这种方式常被称为 Agentic RAG。

  • 还有一种方向是将检索与微调结合。例如通过 Retrieval-Augmented Fine-tuning，使模型在训练阶段学习如何更好地利用检索结果。

这些演进方向的共同目标，是提升检索质量与推理深度，同时控制系统复杂度。

4.5 何时不应使用 RAG

尽管 RAG 在知识增强方面具有明显优势，但并非所有场景都适合。当知识规模较小且更新频率低时，直接通过微调或长上下文方式可能更简单。当问题主要涉及逻辑推理而非外部知识时，构建检索系统反而增加复杂度。当对实时性要求极高且数据规模有限时，额外的检索延迟可能成为瓶颈。

因此，在系统设计阶段，应评估知识规模、更新频率、成本预算与性能需求，再决定是否引入 RAG。

本章从批判性角度分析了 RAG 的边界与进化路径。接下来将进入行动层与控制层，讨论如何使模型不仅“知道”，还能够“执行”与“管理任务”，从而构建真正可落地的智能系统。

5. 让模型真正“能做事”：Function Calling 与工具增强

如果说 LoRA 让模型更专注，RAG 让模型拥有记忆，那么工具增强机制则赋予模型“行动能力”。

在没有工具接口的情况下，大模型本质上仍是一个文本生成器。它可以解释如何查询数据库，却无法真正执行查询；可以描述如何发送邮件，却无法触发实际发送行为。在企业级系统中，这种“只会说，不会做”的能力显然不足以支撑自动化流程。

Function Calling 机制的引入，使模型能够通过结构化协议调用外部系统接口，从而实现真正的任务执行。本章将从协议原理、工程实现与风险控制三个层面展开讨论。

5.1 从文本生成到结构化调用

传统大模型交互基于自然语言输入与输出，其核心形式是“文本对文本”。而在实际业务系统中，操作通常以函数形式存在，例如：

  • 查询数据库
  • 调用搜索接口
  • 执行文件读写
  • 发送通知

Function Calling 的关键思想在于：将模型输出限制为符合预定义 JSON Schema 的结构化格式，从而让系统能够解析并执行对应函数。基本流程包括：

  • 第一，系统向模型声明可用工具及其参数结构。

  • 第二，模型在生成阶段判断是否需要调用工具。

  • 第三，若需要调用，则输出结构化函数调用请求。

  • 第四，系统执行函数并将结果反馈给模型。

  • 第五，模型基于执行结果生成最终文本。

这一机制使模型从“解释行为”转向“触发行为”。

5.2 Function Calling 的协议机制

在工程层面，Function Calling 的核心在于接口设计与参数约束。每个工具需要定义：

  • 函数名称
  • 参数字段
  • 参数类型
  • 必填约束

例如，一个数据库查询函数可能定义为：

1
2
3
4
name: query_database
parameters:
table_name: string
condition: string

模型在输出调用请求时，必须严格符合该结构，否则系统无法解析。这种结构化约束有两个重要意义：

  • 第一，降低误调用风险。
  • 第二，提高可控性与可审计性。

相比完全自由的文本生成，结构化输出可以显著增强系统稳定性。

5.3 工具类型与能力扩展

在企业系统中，常见工具类型包括：

  • 数据库查询工具
  • 全文搜索工具
  • 文件系统操作工具
  • 第三方 API 调用工具
  • 任务调度工具

工具数量与种类会直接影响系统复杂度。因此，在设计阶段应避免无节制增加工具接口。一个常见策略是建立工具注册中心，由控制层统一管理工具元数据，并限制模型可访问范围。

此外，还可以通过能力分级策略限制高风险操作。例如，将写入类操作与查询类操作分离，并设置权限校验机制。

5.4 Agent 的执行循环模型

当模型能够调用工具后，任务执行通常不再是单步行为，而是多步循环过程。典型 Agent 执行流程可以抽象为四个阶段：

  • 计划阶段。模型根据目标拆解任务。
  • 行动阶段。调用工具执行具体操作。
  • 观察阶段。接收执行结果。
  • 反思阶段。根据结果决定是否继续。

这一循环常被称为 Plan-Act-Observe-Reflect 结构。例如，在企业知识库场景中，某个复杂问题可能需要：

  • 首先检索相关制度文件
  • 然后查询数据库记录
  • 最后整合结果生成报告

如果某一步骤失败，Agent 可以根据反馈重新规划路径。

flowchart LR
    P["计划阶段
Plan
任务拆解
确定下一步策略"]

    A["行动阶段
Act
调用工具执行
API / 搜索 / 数据库"]

    O["观察阶段
Observe
接收执行结果
更新环境状态"]

    R["反思阶段
Reflect
评估结果
判断是否继续"]

    T["工具系统
搜索引擎 / 数据库
外部 API"]

    G["任务目标
用户问题
最终报告"]

    %% 主循环
    P --> A
    A --> O
    O --> R
    R -->|继续任务
重新规划| P

    %% 工具调用
    A -->|调用工具| T
    T -->|返回结果| O

    %% 结束条件
    R -->|任务完成
生成结果| G
图5-1 Agent 执行循环结构图

5.5 单 Agent 与多 Agent 协作

在简单场景中，一个 Agent 即可完成任务。然而，当任务复杂度提升时，单一控制单元可能面临负载过高的问题。多 Agent 协作模式将任务拆解为不同角色，例如：

  • 规划 Agent
  • 检索 Agent
  • 执行 Agent
  • 审查 Agent

这种分工方式可以提升模块清晰度，并降低单点失效风险。

例如，在代码生成场景中，可以设置一个生成 Agent 负责初稿输出，另一个审查 Agent 负责错误检测与优化建议，从而形成闭环改进。

5.6 工具增强的风险与治理

赋予模型行动能力，也意味着风险增加。主要风险包括：

  • 错误调用
  • 无限循环
  • 成本失控
  • 权限越界

因此，需要在系统层增加以下机制：

  • 调用次数限制
  • 超时控制
  • 权限白名单
  • 日志审计

此外，应防止提示词注入攻击。例如，当外部文本包含恶意指令时，系统应明确区分“用户输入”与“工具指令”，避免模型误执行。

工具增强的目标不是无限扩展能力，而是在可控范围内提升系统自动化水平。

本章完成了从文本生成到行动执行的过渡。下一章将进一步抽象控制层与调度层问题，探讨多模型协作与能力分配机制，从而构建更加复杂且稳定的增强系统。

第六章 多模型协作：从单一智能体到模型调度系统

随着模型规模不断扩大与能力日益分化，一个新的趋势逐渐显现：并非所有任务都适合由同一个模型完成。不同模型在推理深度、规划能力、代码生成、成本效率等方面存在显著差异。在复杂系统中，单一模型往往难以在性能、成本与稳定性之间取得最佳平衡。

因此，在控制层之上，需要引入调度层，将多模型能力进行合理分配与协作。本章将从能力差异分析出发，探讨模型角色划分、协作模式设计以及成本控制策略，构建多模型增强系统的整体框架。

6.1 为什么一个模型不够

在实际工程场景中，可以观察到如下现象：

  • 某些模型在长文本规划方面表现稳定，但在复杂代码推理上存在细节错误。
  • 某些模型推理能力强，但调用成本较高。
  • 某些模型响应速度快，适合高并发场景，但逻辑深度有限。

当系统目标涉及任务拆解、跨文档推理、工具调用与结果审查时，单模型往往难以同时满足所有需求。例如，在企业知识库自动报告生成场景中，系统可能需要：

  • 首先对需求进行规划与结构设计
  • 其次进行多轮检索与数据整合
  • 随后生成初稿
  • 最后进行格式校验与逻辑审查

若由单一模型完成全部流程，不仅成本高昂，而且稳定性难以保证。

多模型协作的核心动机在于：将不同能力优势进行组合，形成更高效的整体系统。

6.2 能力分解与模型角色定义

在设计多模型系统时，首先需要进行能力分解。常见角色包括：

  • 规划模型。负责目标拆解与流程设计。
  • 推理模型。负责复杂逻辑推理或代码生成。
  • 执行模型。负责高频简单任务或批量处理。
  • 审查模型。负责结果验证与纠错。

例如，在代码生成场景中，可以采用如下分工：

  • 规划模型生成任务步骤
  • 推理模型生成核心代码
  • 审查模型进行静态检查
  • 执行模型处理格式化与简单重构

这种角色划分并非固定，而是根据任务类型动态调整。

6.3 规划与执行分离架构

一种常见协作模式是规划与执行分离。在该模式下：

  • 第一模型负责制定执行计划，包括步骤顺序、工具选择与参数设计。
  • 第二模型根据计划完成具体推理或生成任务。

这种结构的优势在于：

  • 可以将高层逻辑与底层细节解耦。
  • 可以使用成本较低的模型承担重复性任务。
  • 可以在执行阶段进行独立审查与回滚。

例如，在复杂问答场景中，规划模型可以先判断问题类型，决定是否需要检索、是否需要工具调用，再将具体子任务分配给推理模型。

规划模型类似系统调度器，而执行模型类似工作节点。

6.4 审查闭环与自我优化机制

在多模型系统中，引入审查闭环可以显著提高输出质量。典型流程包括：

  • 生成阶段输出初稿
  • 审查阶段识别潜在问题
  • 修复阶段进行修改

这一闭环结构可以减少错误传播风险，并增强系统鲁棒性。例如，在报告生成场景中，审查模型可以检查：

  • 是否引用真实来源
  • 是否存在逻辑矛盾
  • 是否符合格式规范

若发现问题，可将反馈结果重新传递至生成阶段，形成迭代优化。这种结构类似传统软件工程中的代码评审机制，将质量控制嵌入流程本身。

6.5 模型路由与成本控制策略

多模型协作并不意味着每次都调用所有模型。合理的路由机制可以根据问题复杂度动态选择模型。常见策略包括：

  • 基于问题分类进行模型选择
  • 基于历史数据进行性能预测
  • 基于成本预算进行优先级控制

例如，对于简单事实查询，可以直接使用轻量模型；对于复杂多步推理问题，则升级至高性能模型。此外，可以结合缓存机制与分级调用策略，避免重复计算。模型调度系统的核心目标在于平衡三项指标：

  • 质量
  • 延迟
  • 成本

过度追求质量可能导致成本失控；过度追求效率可能降低准确率。因此，需要在设计阶段明确优先级。

6.6 从多模型协作到完整增强系统

至此，增强体系已包含：

  • 模型层的参数专注能力
  • 记忆层的知识检索能力
  • 行动层的工具调用能力
  • 控制层的任务编排能力
  • 调度层的模型协作能力

这些层级共同构成一个完整的增强系统。在企业知识库场景中，整体流程可能如下：

  • 接收问题
  • 规划模型判断是否需要检索
  • 记忆层完成召回
  • 推理模型生成答案
  • 审查模型进行验证
  • 必要时调用工具
  • 最终输出结果

这种分层结构将单一大模型转化为模块化智能系统，使其具备更强的稳定性与扩展性。

本章完成了调度层与多模型协作机制的讨论。下一章将综合前述所有层级，构建一个完整的企业级智能系统架构，并从性能指标与工程治理角度进行总结与评估。

7. 企业级智能系统的整体架构与工程治理

前文分别讨论了模型层、记忆层、行动层、控制层以及调度层。至此，各个能力模块已经相对清晰。然而，真正的挑战在于如何将这些模块整合为一个可运行、可监控、可优化的企业级系统。

本章将围绕整体架构设计、关键评价指标、性能与成本优化策略以及生产环境治理问题展开，构建一个具备工程可落地性的完整智能系统框架。

7.1 企业知识库 Agent 的总体架构

以“企业知识库问答与自动报告生成系统”为例，其整体架构可以分为以下模块：

  • 数据接入模块。负责文档抓取、数据清洗与结构化处理。
  • 向量化模块。负责文本切片与 Embedding 生成。
  • 向量数据库。存储文本向量与元数据。
  • 检索层。执行语义召回与排序。
  • 控制层。负责任务规划与流程管理。
  • 推理模型层。执行复杂生成与逻辑推理。
  • 工具执行层。对接数据库、搜索系统与业务接口。
  • 审查与评估模块。对生成结果进行质量控制。

各模块之间通过清晰接口进行解耦，形成分层结构。

7.2 五层增强体系的整合逻辑

在系统运行过程中，各层之间并非线性调用，而是存在动态协作关系。

  • 模型层提供基础语言能力与领域专注能力。
  • 记忆层根据查询结果补充知识上下文。
  • 行动层在需要时触发外部操作。
  • 控制层根据执行反馈进行流程调整。
  • 调度层决定调用哪个模型完成任务。

例如，在一个复杂问题处理中，流程可能为：

  • 控制层判断问题类型
  • 调度层选择规划模型
  • 规划模型决定调用检索
  • 记忆层返回相关文档
  • 推理模型生成初稿
  • 审查模型验证输出

若发现缺失，则再次检索或调用工具，这种多层协作机制，使系统具备自适应能力。

7.3 关键评价指标体系

构建企业级系统，必须建立量化指标。常见评价维度包括：

  • 检索指标。召回率、精确率、平均逆排名
  • 生成质量指标。事实准确性、逻辑一致性、引用完整性
  • 系统性能指标。端到端延迟、平均响应时间、并发处理能力
  • 成本指标。单次调用 Token 成本、模型调用频率、向量存储开销

在评估体系中，应避免单一指标驱动。例如，过度优化召回率可能导致上下文冗余，反而影响生成质量。

7.4 延迟拆解与性能优化

在实际运行中，延迟通常来自以下环节：

  • Embedding 计算
  • 向量检索
  • 模型推理
  • 工具执行

通过对延迟进行拆解，可以识别瓶颈位置。优化策略包括：

  • 对 Embedding 结果进行缓存
  • 控制 TopK 数量
  • 使用轻量模型完成简单任务
  • 并行执行独立工具调用

此外，可以采用分级策略：对于简单问题直接使用轻量模型；对于复杂问题升级调用高性能模型。通过这种方式，在保证质量的同时控制成本。

7.5 成本治理与模型版本管理

企业系统必须考虑长期维护问题。模型版本更新可能带来输出风格变化，需要进行灰度测试与回滚机制设计。不同 LoRA 模块应建立版本编号与加载策略，避免冲突。

对于向量数据库，应定期清理冗余数据，并维护索引结构健康状态。

同时，需要建立日志审计系统，记录：

  • 检索内容
  • 模型调用路径
  • 工具执行记录
  • 生成输出

这些数据不仅用于问题排查，也可用于持续优化。

7.6 生产环境中的风险控制

当系统具备工具执行能力后，风险进一步提升。需要设置调用频率限制与预算控制机制，防止异常循环。

对于高风险操作，应增加人工确认或双重验证机制。

此外，应对提示词注入攻击进行防护，例如限制模型对外部文本中隐藏指令的执行权限。

稳定的企业级系统不仅依赖模型能力，更依赖完善的治理机制。

7.7 从增强系统到可持续智能平台

当各层能力稳定运行后，系统不再是单一问答工具，而成为可持续迭代的平台。未来可以加入：

  • 自动数据更新流水线
  • 模型性能监控与自动回归测试
  • 动态模型路由策略优化
  • 自适应 LoRA 选择机制

通过持续迭代与数据反馈，系统将不断优化，而不是停留在一次性部署阶段。

本章完成了对企业级增强系统的整体架构与工程治理分析。至此，从参数专注、知识增强、工具执行到模型调度的完整体系已经建立。接下来将进入最后一章，对技术边界与未来方向进行总结与展望，进一步完善整体认知框架。

8. 技术边界与未来方向：从增强系统到可进化智能体

在完成模型层、记忆层、行动层、控制层与调度层的系统构建之后，有必要回到一个更根本的问题：这种增强体系是否适用于所有场景？其边界在哪里？未来又将如何演进？

任何技术体系如果缺乏对自身局限的认知，往往会在复杂场景中暴露结构性问题。本章将在总结前述架构的基础上，从边界条件、替代路径与未来趋势三个维度展开分析，使整个体系具备更完整的战略视角。

8.1 何时不应使用大模型增强系统

增强系统并非默认最优解。在以下情形中，可能需要重新评估架构复杂度。

  • 问题规模较小且规则清晰。例如固定格式的数据转换或简单字段校验，使用规则引擎往往更加高效稳定。

  • 知识规模有限且更新频率低。在这种情况下，直接微调或使用长上下文即可满足需求，无需额外构建向量数据库。

  • 实时性要求极高。若系统必须在毫秒级响应，而模型推理与检索时间不可压缩，则应考虑采用更轻量化方案。

  • 强一致性要求场景。例如金融交易系统，对输出正确性与确定性要求极高，此时大模型仅适合作为辅助分析工具，而非核心执行单元。

因此，在系统设计初期，应明确目标边界，避免过度工程化。

8.2 小模型与规则系统的价值

在大模型热潮下，小模型与传统规则系统的价值仍不可忽视。小模型具有如下优势：

  • 成本低
  • 响应快
  • 易部署
  • 行为可预测

规则系统则在确定性场景中具有绝对稳定性。在实践中，可以采用混合架构。例如：

  • 规则系统处理高确定性流程
  • 小模型处理轻量文本任务
  • 大模型负责复杂推理与开放问题

这种分层策略有助于控制成本并提高整体稳定性。增强系统并不是替代所有技术，而是与既有系统协同工作。

8.3 自适应专家模型与动态微调

随着参数高效微调技术成熟，可以构建多个领域专家模块，并在运行时根据问题类型动态加载。例如，在企业内部系统中，可构建：

  • 法律专家模块
  • 财务专家模块
  • 技术支持模块

当调度层识别问题领域后，自动加载对应 LoRA 模块。这种自适应专家机制使系统具备“领域切换能力”，同时保持基础模型稳定。未来方向可能包括：

  • 基于问题向量自动匹配最佳 LoRA
  • 动态更新专家模块
  • 持续在线学习机制

这些机制将使模型能力更加模块化与可扩展。

8.4 自动模型路由与智能调度

多模型协作的下一阶段，是建立更加智能的模型路由系统。当前模型调度多基于人工规则或简单分类逻辑。未来可以引入以下机制：

  • 基于历史性能数据进行预测
  • 基于问题复杂度自动评分
  • 结合成本预算动态选择模型

例如，系统可以在低复杂度问题上默认使用轻量模型，当置信度不足时自动升级至高性能模型。这种分级调用策略不仅优化成本，也提升响应效率。

在更高级阶段，调度层本身可以成为一个学习系统，通过持续反馈不断优化路由策略。

8.5 从增强系统到可进化智能体

当模型层、记忆层、行动层、控制层与调度层形成闭环后，系统具备持续优化的基础。可进化智能体的特征包括：

  • 能够根据反馈自动调整策略
  • 能够监控自身性能指标
  • 能够更新知识库
  • 能够选择最优模型组合

这种系统不再是静态部署的工具，而是具备动态适应能力的平台。在未来架构中，可以预见以下趋势：

  • 记忆与推理更加深度融合
  • 图结构与多跳检索成为常态
  • 模型之间的协作更加自动化
  • 系统级监控与自我修复机制更加成熟

增强系统的目标并非构建一个“最强模型”，而是构建一个“可持续演进的智能系统”。

8.6 总结：从模型到系统的转变

回顾全文，可以看到一条演进路径：

  • 从参数增强解决专注问题
  • 到记忆增强解决知识问题
  • 再到工具增强解决执行问题
  • 通过控制层实现任务编排
  • 最终通过调度层实现模型协作

这一体系将大模型从单一生成器转化为结构化系统。

真正的能力提升，不仅来自模型规模增长，更来自架构设计能力的提升。模型只是智能系统的核心组件，而不是全部。当增强体系与工程治理机制相结合，大模型才能在企业级场景中发挥长期稳定的价值。