智能物流信息技术教材网站

第14章 大模型应用基础

学习目标

  1. 理解大语言模型的本质是基于神经网络的下一词元概率预测,认识其与统计语言模型、循环神经网络的区别。
  2. 掌握Transformer架构中自注意力机制的基本原理,理解其如何解决长距离依赖与并行计算问题。
  3. 了解词元化与子词切分的基本思路,理解字节对编码(BPE)的工作过程及词嵌入向量的作用。
  4. 理解上下文窗口的限制,掌握检索增强生成(RAG)的基本原理与实现框架。
  5. 掌握提示词工程的常见技巧,理解结构化输出的两种实现思路。

引言

以Transformer架构为基础的大语言模型,通过对海量文本的自监督学习,具备了前所未有的语言理解与生成能力。更重要的是,它不再是一个孤立的信息系统,而是可以通过检索增强生成获取企业的私有知识,通过工具调用操作现有的TMS、WMS等业务系统,并以智能体的形式自主完成多步骤的复杂任务。其中,工具调用与MCP协议为模型访问企业现有业务系统提供了统一途径,智能体技能及其渐进式披露机制则回答了如何让模型自主完成多步骤复杂任务。本章介绍词元化、上下文窗口、检索增强生成、提示词工程、工具调用与智能体等关键技术为后续在具体物流业务中评估、选型与集成大语言模型应用打下基础。

14.1 大语言模型基础与架构原理

14.1.1 大语言模型的特征

神经网络可以看成是一个由大量参数构成、可以逼近任意映射关系的函数。大语言模型是这一函数在自然语言处理领域的应用,只是这个函数处理的输入输出不再是图像像素或数值,而是人类语言中的词元序列。具体来说,大语言模型学习并表达的是一种条件概率关系,即给定一段已经出现的文字,模型计算词表中每一个候选词元作为下一个词元出现的概率,记作 P(下一个词元 | 已出现的词元序列)。模型生成文本的过程,本质上是反复地从这个概率分布中选出概率较高的词元,并将其拼接到已有文本之后,如此循环,直到形成一段完整的语句或篇章。

“预测下一个词”的思路并非大语言模型首创。在统计语言模型时代,人们已经采用词频统计的方法,通过统计语料库中若干个词连续出现的次数,估算某个词在给定前几个词之后出现的概率,这类模型通常称为N元文法(N-gram)模型。大语言模型与之的差异在于承担这一概率估计任务的载体:N元文法用频率表格记录概率,大语言模型则用一个包含数十亿甚至上万亿个参数的深度神经网络来逼近这个概率函数,网络参数通过在海量文本上的训练自动调整,不再依赖人工设定的统计窗口。

大语言模型区别于以往自然语言处理模型的关键特征可以归纳为三点。第一,参数规模与训练数据规模呈数量级增长,主流模型的参数量从数十亿到数千亿不等,训练语料通常覆盖数万亿词元的文本。第二,训练方式以自监督学习为主,模型不需要人工标注的任务标签,只需要连续的文本本身:将某段文字的某个位置遮住或截断,让模型学习预测被遮住或截断的内容,这一训练目标可以直接从原始文本中构造,训练数据的获取成本因此大幅降低。第三,随着参数规模与训练数据量跨过某些临界点,模型会表现出小规模模型所不具备的能力,例如仅凭几个示例就能通过上下文学习完成新任务、能够进行多步骤的逻辑推理等,这类现象在相关研究中称为“涌现能力”。

凭借这些特征,大语言模型承担的功能已经从单一的文本生成,扩展到文本理解、摘要、翻译、代码编写、逻辑推理、对话交互等多种任务,并且同一个模型不经过重新训练,仅通过更换输入的提示语句,就可以在不同任务之间切换。

14.1.2 技术演进

大语言模型的出现,是为了解决此前自然语言处理技术长期存在、却始终难以突破的几个瓶颈。

早期基于规则的自然语言处理系统,依赖语言学专家编写语法规则和词典,系统的能力完全取决于规则覆盖的范围,遇到规则之外的表达方式便无法处理,而人类语言的表达方式几乎无穷尽,规则库的维护成本随覆盖范围扩大而急剧上升。随后出现的统计语言模型,将概率统计方法引入语言建模,缓解了规则穷举的问题,但受限于统计窗口的长度,一般只能统计三到五个词的共现关系,难以捕捉句子中相距较远的词语之间的依赖关系。

进入深度学习阶段后,循环神经网络(RNN)及其改进形式长短期记忆网络(LSTM)被引入语言建模,通过将前一时刻的隐藏状态传递到下一时刻,理论上可以捕捉任意长度的依赖关系。在处理文本时,RNN 不是一次性接收整句话,而是像人类读书一样,按时间步逐字(词)输入。在每个时间步 tt,RNN 接收当前词的输入向量 xtx_t,同时接收上一个时间步传递过来的隐藏状态 ht−1h_{t-1},两者混合计算后生成当前时间步的新状态 hth_t。这个隐藏状态就像一个持续更新的“工作记忆单元”,将历史信息不断传递至后续计算中。

但这类网络存在两个实际困难:一是隐藏状态在逐步传递的过程中,较早时刻的信息会随层层计算而衰减或被覆盖,模型在处理较长文本时依然难以记住靠前的内容;二是这类网络的计算方式要求严格按时间步顺序执行,第t个时间步的计算必须等待第t-1个时间步完成之后才能开始,这一顺序依赖关系使训练过程无法在多个计算单元上并行展开,当训练数据规模扩大到数千亿词元级别时,训练所需时间变得难以接受。

大语言模型采用的Transformer架构,正是针对这两个困难提出的:它以可以并行计算的方式,直接建立序列中任意两个位置之间的联系,既不需要逐步传递隐藏状态,也不受限于固定长度的统计窗口。这一架构上的突破,使在超大规模语料上训练超大规模参数的模型在工程上变得可行,也由此打开了将模型能力扩展到多种自然语言任务的空间。这类模型适合处理的问题,通常具备以下共同点:任务本身可以转化为自然语言的输入输出形式,存在大量未标注的原始文本可供训练,且任务对语言的理解与生成需要考虑较长范围的上下文关联,例如文档摘要、多轮对话、复杂问题解答等。

14.1.3 训练与使用

从输入输出的角度观察,大语言模型训练阶段的输入是海量的原始文本语料,这些语料经过词元化处理后转换为词元序列,逐段输入模型用于调整参数,这一阶段不需要任务标签,对语料的要求主要是数量庞大且来源广泛,训练最终输出的结果为各参数权重。此外,大语言模型的训练需要投入能够支撑数十亿乃至数千亿参数并行训练的计算集群,通常由大量图形处理器(GPU)或专用加速芯片组成。

大语言模型使用阶段(推理阶段)的输入则是一段自然语言文字,通常称为提示(prompt),可以是一个问题、一段指令,或者一段需要续写的文字。模型的输出是对下一个词元的概率预测,经过重复采样后拼接成完整的文字回复,大多数应用场景不再重新训练模型,而是直接调用已经训练完成的模型,通过设计合适的提示文字获得所需的输出。

14.1.4 Transformer架构

🎬 教学动画:注意力机制(2:06)

2017年,Google团队在论文《Attention Is All You Need》中提出了 Transformer 架构,颠覆了以往基于循环(RNN/LSTM)和卷积(CNN)的序列建模范式。Transformer与循环神经网络最核心的区别,在于处理序列内部依赖关系的方式,循环神经网络依靠隐藏状态沿时间步顺序传递来建立词与词之间的联系,而Transformer使用自注意力机制(self-attention),让序列中每一个位置都可以直接计算与其余所有位置之间的关联程度,不需要经过中间时间步的传递。

自注意力机制的计算过程可以概括为:模型为输入序列中的每一个词元生成三个向量,分别称为查询向量(Query,Q)、键向量(Key,K)和值向量(Value,V),三者都是词元向量经过不同参数矩阵变换得到的。用比喻来理解这三个向量,假设你需要研究“冷链温控标准”。研究课题就是 Query(查询);图书馆每本书书脊上的分类标签与摘要就是 Key(键);而书本内部的具体知识内容就是 Value(值)。

对于某一个词元,将它的查询向量与序列中所有词元的键向量做点积运算,点积结果衡量该词元与其余各词元之间的关联程度;将这些点积结果除以键向量维度的平方根进行缩放,再经过softmax函数归一化为一组权重;最后用这组权重对所有词元的值向量做加权求和,得到该词元新的表示。写成公式即为:

Attention⁡(Q,K,V)=softmax⁡(QKTdk)V(14-1) \operatorname{Attention}(Q, K, V) = \operatorname{softmax}\left(\frac{QK^{T}}{\sqrt{d_k}}\right)V \tag{14-1}

其中,dkd_k 是键向量的维度。除以 dk\sqrt{d_k} 是为了避免点积数值过大,导致 softmax⁡\operatorname{softmax} 的梯度过小。这一计算对序列中所有位置同时展开,不存在前后依赖,因此可以在计算设备上并行执行。

单一的查询-键-值计算只能捕捉一种关联模式,为了让模型同时关注不同类型的语言关系,例如既捕捉语法上的主谓搭配,又捕捉语义上的指代关系,Transformer将输入向量拆分为多组,分别进行上述注意力计算,再将各组结果拼接后线性变换,这一设计称为多头注意力(multi-head attention)。由于自注意力计算本身不包含词元先后顺序的信息(打乱输入顺序,点积结果不变),Transformer在输入词元向量中额外叠加位置编码(positional encoding),以正余弦函数或可学习参数的形式将位置信息注入向量表示,弥补这一缺陷。

将自注意力层、位置编码与常规的前馈神经网络层组合起来,并配合残差连接与层归一化,构成Transformer的一个基本模块;将若干个这样的模块逐层堆叠,即构成完整的Transformer网络。以目前主流大语言模型普遍采用的仅解码器(decoder-only)结构为例,其整体计算流程可表示为:

transformer_decoder cluster_transformer_block 重复 N 层 input 输入文本 tokenize 词元化 input->tokenize embedding 词嵌入+ 位置编码 tokenize->embedding attention 多头自注意力 (施加因果掩码) embedding->attention norm1 残差连接 与归一化 attention->norm1 ffn 前馈网络 norm1->ffn norm2 残差连接 与归一化 ffn->norm2 output 线性输出层 norm2->output softmax softmax output->softmax probability 下一词元 概率分布 softmax->probability

图14-1 Transformer仅解码器结构的整体计算流程

其中“因果掩码”指在计算注意力权重时,屏蔽掉每个位置对其之后位置的关注,只允许每个词元参考它之前已经出现的词元,这一限制保证模型生成文字时,是按照从前到后的顺序、依据已经生成的内容逐词元预测,符合人类阅读和写作的时间顺序。

14.1.5 预训练与后训练

模型参数的具体数值,来自两个阶段的训练。第一阶段称为预训练,模型在覆盖网页、书籍、代码等多种来源的海量文本上,反复执行“根据前文预测下一个词元”这一任务,通过随机梯度下降等方法逐步调整参数,使模型输出的概率分布尽可能接近语料中真实出现的词元。这一阶段耗时最长、消耗计算资源最多,训练完成后的模型已具备较强的语言理解和生成能力,但其输出风格更接近续写文本,不一定符合人类期望的问答或对话形式。

第二阶段的后训练通常包括指令微调和基于人类反馈的强化学习(RLHF)等步骤:先用少量人工编写的问答或对话样本对预训练模型进行有监督微调,使其学会按照指令的形式组织回答;再收集人类对模型多个候选回答的偏好排序,训练一个反映人类偏好的评价模型,并以此评价模型的打分作为反馈信号,通过强化学习进一步调整语言模型的参数,使其输出更符合人类偏好,同时减少有害或无意义的回答。经过这两个阶段之后的模型,才是目前实际部署、供用户直接使用的大语言模型。

模型能力随参数规模、数据规模和计算量增长而提升的规律,在相关研究中称为“缩放定律”(scaling law)。这一规律也解释涌现能力:当规模跨过某个量级后,模型在未经过专门训练的任务上,仅凭提示中的少量示例或说明就能完成任务,这一现象是缩放定律在质变层面的体现。

14.2 文本词元化与向量表示

14.2.1 词元化的作用

条码编码要解决的问题,是把现实世界中千差万别的商品,转换成计算机可以识别的标准化数字代码,编码规则一旦确定,同一件商品无论何时何地被扫描,都会得到同一个代码。词元化(tokenization)要解决的问题与此类似:模型内部的运算只能作用于数值,而人类输入模型的是连续的文字流,其中夹杂汉字、英文单词、标点、数字、代码符号等各种字符。词元化的作用,就是按照一套预先确定的编码规则,把这段连续文字切分成一串有限、可枚举的基本单位(词元,token),并为词表中每一个词元分配一个唯一的整数编号,使后续的一切运算得以在整数序列而非原始字符串上展开。

与条码编码不同的是,条码所对应的商品种类相对有限,一套编码体系可以穷举式地覆盖;而人类语言中可以出现的词语组合数量趋于无穷,新词、缩写、拼写变体、专业术语层出不穷,词元化方案必须在“词表规模可控”与“任意文本都能被表示”这两个相互制约的目标之间找到平衡。

14.2.2 词元化思路

词元化方案并非只有一种可选思路,按词切分和按字切分是两种最直观、但都存在明显缺陷的方案。

按词切分以英文为例,即以空格和标点作为词语边界,将句子切分为一个个独立单词,词表由语料中出现过的所有单词构成。这种方案的问题在于词表规模会随语料扩大而持续膨胀:同一个词根的不同形态(例如动词的时态变化、名词的单复数)都会被当作不同的词元,专业词汇、人名地名形更是难以穷举。一旦推理阶段遇到词表之外的词,模型只能用一个统一的“未知词”标记代替,导致该词携带的全部信息丢失。对于中文这类书写时词与词之间没有空格分隔的语言,按词切分还需要先进行一次独立的分词处理,分词本身的准确率又会引入新的误差来源。

按字切分则走向另一个极端,以单个汉字或单个字母作为词元。这种方案的词表规模很小且固定,不存在未知词的问题,但代价是同一句话被切分成的词元数量大幅增加,序列变长直接加重了自注意力计算的负担;同时单个字符携带的语义信息通常十分有限,例如“环”字单独出现时语义模糊,只有与“保”组合成“环保”才具备明确含义,模型需要额外的层数和参数去学习这种字符组合关系,学习难度相应上升。

大语言模型普遍采用的解决办法,是介于两者之间的子词切分(subword tokenization):让常见的完整词汇作为一个词元保留,而不常见、结构复杂的词,则拆分成若干个更小但仍然频繁出现的片段的组合。这样词表规模可以控制在几万到十几万的量级,序列长度也不至于因为逐字切分而过度膨胀,同时因为切分的最小单位可以细化到单个字符甚至单个字节,任何输入文本理论上都能被已有词表表示,不再需要“未知词”标记。

14.2.3 词元化流程

词元化环节的输入是一段原始文本字符串,输出分两步。第一步是切分与编号:按照词元化规则将文本切分为词元序列,并根据词表将每个词元映射为一个整数编号,这一步的结果是一串整数(词元ID序列)。第二步是向量化:将每个整数编号,通过一个可训练的映射表转换为一个固定维度的稠密向量,这串向量才是真正输入到Transformer自注意力层的数据,即“词嵌入”步骤。

需要注意的是,词元化规则与向量映射表在训练流程中所处的位置并不相同。词元化的切分规则和词表,是在模型正式训练之前,基于大规模语料统计一次性确定下来的一套固定规则,之后无论是训练阶段还是推理阶段,都直接调用这同一套规则,本身不随模型训练过程更新。而词元编号对应的向量数值,则是模型参数的一部分,在模型训练过程中与其余网络层参数一起,通过梯度下降不断调整。

14.2.4 字节对编码

🎬 教学动画:BPE 字节对编码(2:05)

目前主流大语言模型普遍采用字节对编码(Byte Pair Encoding,BPE)或其变体来构建子词词表,算法思路可以概括为一个不断合并高频相邻符号对的迭代过程,如图14-2所示:

初始化词表 = 训练语料中出现的全部单字符(或单字节)
重复执行,直到词表达到预设规模:
    统计当前切分方式下,语料中所有相邻词元对出现的次数
    找出出现次数最多的相邻词元对 (A, B)
    将全部 (A, B) 合并为一个新词元 AB,加入词表
    用新词元 AB 替换语料中所有 (A, B) 组合
输出:最终词表,以及记录合并顺序的规则表
bpe_process raw 原始文本 "冷藏集装箱运输" split 基础字符切分 ['冷', '藏', '集', '装', '箱', '运', '输'] raw->split merge BPE 迭代合并高频字符对 ('冷'+'藏' -> '冷藏') ('集'+'装'+'箱' -> '集装箱') ('运'+'输' -> '运输') split->merge tokens 最终切分Token序列 ['冷藏', '集装箱', '运输'] merge->tokens ids 词表数值ID [8420, 19302, 3811] tokens->ids

图14-2 基于字节对编码(BPE)的子词切分与数值化流程

训练完成后,词表中会同时包含高频完整词、常见前缀后缀词根,以及作为兜底的单字符或单字节。对任意新输入的文本进行编码时,按照训练阶段记录的合并顺序,从最基本的字符或字节开始,依次尝试执行同样的合并操作,最终得到该文本对应的词元序列——由于兜底的单字符或字节始终在词表之中,任何输入,包括训练语料中从未出现过的词形、外语词汇甚至表情符号,都能够被表示,不会出现未登录词。

在BPE之外,还有WordPiece、SentencePiece等实现思路相近的变体:WordPiece以候选合并对能否提升语言模型似然作为合并标准,而非单纯统计出现频率;SentencePiece则将输入视为原始字节流,不预先假设词与词之间存在空格分隔,因而同一套流程可以直接处理中文、日文等不依赖空格分词的语言,也便于构建覆盖多语言的统一词表。

14.2.5 从词元到向量

词元编号本身只是一个整数索引,编号之间的大小关系不承载任何语义信息。若直接以独热编码(one-hot vector)表示每个词元,即向量维度等于词表大小、仅对应位置为1、其余位置为0,则任意两个不同词元的独热向量之间的距离都完全相同,无法体现“轿车”与“卡车”在语义上比“轿车”与“香蕉”更接近这一事实,而且当词表达到数万规模时,独热向量的维度也过于庞大。

大语言模型采用的解决办法,是引入一个可训练的词嵌入矩阵(embedding matrix),矩阵的行数等于词表大小,每一行是一个维度远小于词表规模(通常为几百到数千)的稠密向量,对应词表中的一个词元。给定一个词元编号,直接取出矩阵中对应的那一行,即完成从整数编号到稠密向量的转换。这个矩阵中的数值最初随机初始化,在模型训练过程中,与自注意力层、前馈网络层等其余参数一起,依据下一词元预测目标同步更新。训练过程中,经常出现在相近上下文里的词,其对应的向量会被逐渐调整到方向相近的位置,可以用余弦相似度衡量两个词向量方向的接近程度,如式(14-2)所示:

cos⁡(a,b)=a⋅b∥a∥×∥b∥(14-2) \cos(a, b) = \frac{\mathbf{a} \cdot \mathbf{b}}{\lVert \mathbf{a} \rVert \times \lVert \mathbf{b} \rVert} \tag{14-2}

其中,a\mathbf{a}和b\mathbf{b}表示两个词元的嵌入向量,a⋅b\mathbf{a} \cdot \mathbf{b}表示二者的点积,∥a∥\lVert \mathbf{a} \rVert和∥b∥\lVert \mathbf{b} \rVert分别表示两个向量的长度(模)。该值的范围通常为[−1,1][-1, 1]:越接近11,表示两个向量的方向越相近、语义通常越接近;接近00表示关联较弱;接近−1-1则表示方向相反。

在Transformer出现之前,Word2Vec、GloVe等模型已经采用类似思路,专门训练独立于具体任务的通用词向量,但这类词向量一旦训练完成便固定不变,同一个词无论出现在哪句话中,对应的向量都相同,无法处理一词多义的情况,例如“苹果”在“苹果富含维生素”与“苹果发布新款手机”两句话中的含义并不相同,静态词向量却只能给出同一个折中的表示。大语言模型中的词嵌入层,仅仅是整个网络的输入端,词元经过嵌入层得到初始向量后,还要继续经过自注意力层,与上下文中其余词元的向量相互作用,得到融合了具体语境信息的表示,这才使同一个词在不同句子中获得不同的最终表示,从根本上解决静态词向量无法区分多义词的问题。

14.3 上下文窗口与检索增强生成

14.3.1 上下文窗口的限制

自注意力运算要求序列中的每一个词元都与其余全部词元计算一次关联度。若一段文本包含n个词元,这一步运算量与n的平方成正比,所需存储关联度结果的空间同样与n的平方成正比。当n从几百增长到几万甚至几十万时,这一平方级的开销会迅速超出计算设备的算力与显存承受范围。因此,实际部署的大语言模型都会设定一个能够处理的词元数量上限,这个上限称为上下文窗口(context window)。一次对话或一次任务中,无论是用户输入的历史文字,还是模型自己已经生成的文字,全部合并计算在这一个上限之内,一旦总词元数超过窗口容量,模型就无法再“看到”更早之前的内容。

这一限制与循环神经网络的记忆衰减问题看似相近,实则不同。循环神经网络理论上没有固定的长度上限,但由于隐藏状态在逐步传递过程中信息会被反复覆盖,实际表现为越靠前的内容被记住的程度越模糊,是一种渐进式的遗忘;而Transformer凭借自注意力机制,只要词元处于窗口范围之内,无论距离远近都能被同等精确地关联到,表现为窗口之内记忆清晰、窗口之外则被直接截断,是一种硬性的边界。

14.3.2 上下文窗口的扩展方案

由于窗口容量直接决定模型一次能够处理的文本规模,围绕如何在可接受的计算成本下扩大窗口,已经形成若干条并行的技术路线。一类做法从工程实现入手,通过更高效的显存管理方式,例如分块计算注意力、避免存储完整的关联度矩阵,在同样的硬件条件下容纳更长的序列。还有一类做法通过限制每个词元只与邻近范围内的词元直接计算关联度(滑动窗口或稀疏注意力),以牺牲部分远距离精确关联为代价,将计算量从平方级降低到接近线性级。

需要说明的是,窗口容量扩大并不等同于窗口内信息都能被同等有效地利用。当输入文本很长时,模型对处于文本中间位置的内容,关注和利用的准确程度通常低于处于开头或结尾位置的内容,这一现象在相关研究中被称为“中间迷失”。这意味着单纯扩大窗口容量,并不能完全替代下面要讨论的、更有针对性地筛选相关信息的机制。

14.3.3 检索增强生成的产生背景

大语言模型的知识来自预训练阶段学习到的参数,这部分知识存在两个明显的局限。第一,参数中固化的知识截止于训练语料收集的时间点,此后发生的事件、更新的政策、新出现的商品信息,模型无从得知。第二,当被问及训练语料中出现频率较低或未曾出现过的具体细节时,模型仍然会依照其学到的语言概率分布生成一段读起来通顺、但内容并不准确的文字,这类现象通常称为“幻觉”。对于企业内部的运单记录、库存台账、合同条款等私有且频繁更新的数据,模型在预训练阶段更是完全没有接触过。

针对这一局限,一种办法是持续用最新数据对模型做微调,将新知识重新写入参数,但这一过程的成本与预训练的成本处于同一量级,且模型参数一旦调整完成,下一次数据更新又需要重新微调,难以适应频繁变化的业务数据。检索增强生成(Retrieval-Augmented Generation,RAG)提供了另一种思路:不改动模型参数本身,而是在每次回答问题之前,先从外部知识库中查找与当前问题相关的原始资料,将这些资料作为额外的文字,与用户问题一并放入上下文窗口,模型据此生成的回答,就有了可以核对的具体依据,而不仅仅依赖训练阶段记忆下来的模糊印象。知识库的更新也因此简化为增删文档这一操作,不再涉及模型本身的重新训练。

14.3.4 检索增强生成的实现框架

检索增强生成的运行过程可以分为离线建库和在线问答两个阶段,如图14-3所示:

离线阶段(建立知识库):
原始文档集合 → 按一定规则切分为若干文本块(chunking)
             → 每个文本块经由文本嵌入模型编码为一个向量
             → 文本块原文与对应向量一并存入向量数据库

在线阶段(响应用户问题):
用户问题 → 经同一文本嵌入模型编码为查询向量
        → 在向量数据库中检索与查询向量最相似的若干文本块(最近邻搜索)
        → (可选)用更精细的相关性模型对候选文本块重新排序,保留最相关的部分
        → 将筛选后的文本块与原始问题拼接为提示词,输入大语言模型
        → 模型在检索到的资料基础上生成回答
rag_architecture cluster_offline cluster_online raw_docs 多源业务文档 (SOP/规范) chunker 文档语义切分 (分块与元数据标记) raw_docs->chunker embed_model 向量化编码 (Embedding) chunker->embed_model vector_db 向量数据库 (构建高维索引库) embed_model->vector_db retriever 混合检索与重排 (语义匹配) vector_db->retriever 近邻检索 query 业务提问 query_embed 提问向量化 query->query_embed query_embed->retriever prompt_builder 上下文组装 (Prompt + 命中知识切片) retriever->prompt_builder llm 大语言模型 (逻辑推理) prompt_builder->llm answer 输出 (含依据) llm->answer

图14-3 检索增强生成(RAG)系统离线建库与在线回答流程

其中文本块与查询之间相似度的计算方式,与词向量相似度时使用的思路相同,同样以余弦相似度衡量两个向量方向的接近程度。区别在于词向量针对的是单个词元,而这里的向量针对的是一整段文本块,编码这段向量的嵌入模型也是专门针对语段级别语义训练得到的,但两者背后用向量空间中的距离表示语义相似程度这一原理是一致的。

向量数据库承担的检索任务,与关系型数据库的匹配标准不同,关系数据库中的索引通常按照键值是否精确相等来加速查找,而向量数据库依据的是向量之间的距离远近,检索出的是语义上“相近”而非取值上“相等”的记录,这也是向量数据库需要专门的近似最近邻检索算法,而不能直接复用传统数据库索引结构的原因。

14.3.5 文本切块方案

文本切块环节直接影响检索质量。切分得到的文本块过大,会将大量与问题无关的内容一并纳入检索结果,浪费上下文窗口的有效容量,也可能引入干扰模型判断的噪声;切分得到的文本块过小,则容易割裂原本连贯的语义,导致断章取义。常见做法是按照固定长度切分并在相邻文本块之间保留一定重叠,或者按照文档本身的段落、章节等结构边界切分,具体选择需要结合文档类型与检索场景调整。

将检索增强生成、微调与直接扩大上下文窗口这三种为模型补充知识的方案加以对比,各自适用的场景有所不同。微调将知识固化进模型参数,推理时不再需要额外的检索步骤,回答速度快,但更新成本高、更新周期长,且反复微调存在覆盖或干扰模型已有能力的风险。直接扩大上下文窗口、把全部资料一次性放入提示词,实现方式最为简单,但受计算开销制约,难以覆盖规模较大的知识库。检索增强生成通过先筛选、后放入的方式,把需要模型处理的文本量控制在窗口容量之内,且知识库的更新只需增删向量数据库中的记录,不涉及模型训练,因而在知识规模大、更新频繁的场景中更具优势,最终回答的质量在很大程度上取决于检索能否准确找到相关资料。

14.4 提示词工程与结构化输出

14.4.1 提示词工程的概念

大语言模型的生成过程概括为反复计算条件概率P(下一个词元|已出现的词元序列),并从这个概率分布中选出词元。这个公式中,模型的参数决定了这个条件概率函数本身,而“已出现的词元序列”,也就是提示词,决定了每一次计算时代入的具体条件。同一个函数、同一套参数,代入不同的条件,自然会算出不同的概率分布,进而生成不同的文字。提示词工程要做的事情,正是在不触碰、不调整模型参数的前提下,通过设计输入给模型的文字,让计算出来的概率分布尽可能集中在符合任务要求的输出上。

这一机制与“涌现能力”直接相关,当提示词中包含若干示例时,模型会把示例本身当作条件的一部分,在一次前向计算中直接从示例里归纳出任务的模式,并套用到新的输入上。这种“上下文学习”只发生在当次推理过程中,示例信息占用的是上下文窗口的容量,对话或任务一旦结束,这部分信息也随之消失,不会像微调那样留存在模型参数中。

14.4.2 为什么措辞会影响输出质量

在传统的机器学习范式下,一个模型通常只服务于一项预先设定好的任务,任务的输入输出格式在模型设计与训练阶段就已经固定,使用者无法通过文字描述去改变任务本身。大语言模型将任务的定义方式转移到了自然语言层面,模型本身是通用的,具体执行什么任务、按照什么格式输出,都由使用者在提示词中临时指定。这带来了巨大的灵活性,但也随之产生新的问题,即:自然语言天然存在歧义,同一项任务,表述含糊与表述精确,模型对任务意图的把握程度会有明显差异;示例的选取、顺序,任务约束条件是否讲清楚,都会影响模型推断出的概率分布集中在哪一片区域。提示词工程正是为解决这一问题而形成的一套系统性方法,其目标是把使用者头脑中清晰,但未必落于文字的任务要求,转化为模型能够准确捕捉到的条件文本。

14.4.3 提示词常见技巧

一段完整的提示词,通常由若干部分组合而成,包括任务指令、背景信息、约束条件、示例、以及使用者当次的具体输入,围绕如何组织这些内容,已经形成几类常见且效果得到验证的技巧。

不提供任何示例、仅依靠一段任务描述让模型直接作答,称为零样本提示(zero-shot prompting),适用于模型在对齐训练阶段已经充分接触过的常见任务类型。当任务的输出格式或推理方式较为特殊,仅凭文字描述难以说清楚时,可以在提示词中给出若干组输入输出示例,让模型通过归纳这些示例中的规律来处理新的输入,称为少样本提示(few-shot prompting),示例的作用相当于用具体的例子替代抽象的规则描述。

对于需要多个步骤才能得出正确结论的任务,例如数值计算、逻辑推理或多条件判断,直接要求模型给出最终答案,往往因为中间推理过程被压缩在模型内部而出错;若在提示词中明确要求模型先给出推理过程、再给出结论,或者在少样本示例中直接演示这种“先推理、后作答”的写法,模型的正确率通常会有明显提升,这一技巧称为思维链提示(chain-of-thought prompting)。其作用机制可以理解为:模型每生成一个词元,可利用的计算资源是固定的,直接跳到最终答案,相当于要求模型在一步之内完成全部推理;而要求模型先输出中间步骤,则是把复杂推理拆解成一连串更简单的、每一步都只需要少量计算的词元预测,这些中间结果又会作为后续生成的一部分被重新纳入条件,帮助模型逐步逼近正确答案。

【直接提问模式】:
 用户:“某冷库存储5吨海鲜,前3天免仓租,第4天起按120元/吨/天计费,第10天起按180元/吨/天计费。存满12天总租金是多少?”
 模型直接输出:“总租金是7200 元。”
 直接推算可能遗漏分段阶梯,导致计算错误

【思维链引导模式】:
 提示词加入:“请按天数分段详细列出计算过程,最后给出总计金额。”
 模型输出:
 “1. 第1~3天:免租期,费用=0元;
  2. 第4~9天(共6天):单价120元/吨/天,费用=5吨×6天×120元/天=3600元;
  3. 第10~12天(共3天):单价180元/吨/天,费用=5吨×3天×180元/天=2700元;
  4. 汇总合计:0+3600+2700=6300元。
  最终总租金为:6300元。”

此外,为模型设定一个角色或一组长期适用的行为准则(例如“你是一名专注物流客服问题的助手,回答须遵循XX规范”),通常会作为独立于具体问题的“系统提示词”单独给出,与逐轮变化的用户提问区分开来。这类系统提示词在对齐训练阶段通常被赋予较高的遵循优先级,因而比嵌入在普通对话中的临时说明更能稳定地影响模型在整个对话过程的行为倾向。

14.4.4 结构化输出

模型默认生成的是连续的自然语言文字,但许多下游场景需要将模型输出直接接入其他软件系统,例如把输出结果写入数据库字段,或者作为参数传递给某个程序接口,这类场景要求输出严格符合预先约定的格式,通常表现为带有固定字段名与数据类型的JSON结构。数据库设计中依据数据模型定义表结构、约束字段类型的思路相似,都是预先规定数据应当具备的结构,使后续处理程序可以按照固定方式解析,而不必对每一条数据单独编写解析逻辑。

实现结构化输出目前主要有两种思路。第一种是提示约束,即在提示词中明确说明所需的字段名称、数据类型与格式要求,甚至给出一个符合要求的示例,依靠模型在对齐训练阶段已经具备的格式遵循能力来完成输出。这种方式实现简单,但不能完全保证结果一定合法,模型仍可能在结构化内容之外附加多余的说明文字,或者输出的JSON存在字段缺失、类型错误等问题,需要下游程序自行做容错处理。

第二种是约束解码。模型在每一步生成时,先由输出层计算出词表中每一个候选词元的分数,再经过softmax函数转换为概率分布,最后从中选取词元。约束解码正是在这一步介入:事先将所需的输出格式定义为一套形式化的语法规则(例如JSON Schema,规定字段名称、取值类型、是否必填等),生成每一个词元之前,先根据已经生成的部分内容与这套语法规则,计算出哪些候选词元仍然能够使最终结果保持合法,将其余候选词元的概率强制置零,再执行softmax归一化与采样。由于不符合格式的词元从一开始就不会被选中,这种方式可以从机制上保证输出结果一定符合预先设定的结构,不再依赖模型自身对格式要求的理解与遵循程度,但代价是需要特殊方法接触到模型逐词元输出的概率分布并按语法规则实时干预,而不能仅通过普通的文字提示来实现,对调用方式和相应工具支持有更高的要求。

图14-4展示了一个物流场景下利用大语言模型进行结构化信息抽取的示例。

ner_pipeline raw_text 非结构化派车文本 "王师傅 13900112233 明天上午从青岛港前湾码头 拉25吨冻鳕鱼去济南冷库 全程打冷要求-18度" llm LLM 结构化 提取引擎 raw_text->llm schema JSON Schema 约束模式 定义字段名、数值类型 及必填项校验规则 schema->llm json_out 标准 JSON 数据输出 {  "driver_name": "王师傅",  "driver_phone": "13900112233",  "origin": "青岛港前湾码头",  "destination": "济南冷库",  "cargo": {    "name": "冻鳕鱼",    "weight_tons": 25.0  },  "temp_required_c": -18.0 } llm->json_out

图14-4 基于大语言模型的非结构化物流信息抽取与标准化流程

14.5 工具调用、MCP协议与命令行

14.5.1 工具调用的动因

大语言模型的参数化知识截止于训练数据收集的时间点,检索增强生成通过引入外部文档缓解了这一局限,但检索到的始终是预先存好的静态文本,无法回答“当前某运单的实时位置”、“某仓库此刻的库存数量”这类需要即时查询才能获知的问题,更无法代替使用者去执行“创建一条新运单”、“发送一封通知邮件”这类会改变外部系统状态的操作。此外,模型生成文字的方式是依据训练中学到的概率分布逐词元预测,这种方式对于精确的数值计算、严格的逻辑判断并不擅长,容易出错。

工具调用(tool calling,也称function calling)要解决的正是这一类问题。让模型在生成过程中,不再局限于输出自然语言文字,而是可以生成一个结构化的请求,说明需要调用哪一个外部函数、传入什么参数,由外部程序实际执行这个函数,可能是一次数据库查询、一次数值计算、一次接口调用,也可能是一次会改变系统状态的操作,并把执行得到的真实结果重新交还给模型,模型再基于这个真实结果继续生成后续内容。这一机制把模型的角色从单纯的文字生成者,扩展为能够调度外部程序、依据真实数据作答的协调者,而具体的计算、查询、操作仍旧交由专门的外部程序完成,并非由模型自身的神经网络运算替代。

14.5.2 工具调用的实现机制

工具调用能力并非在模型结构上另行添加了一个特殊模块,其生成过程仍然是逐词元条件概率预测,区别在于模型在对齐训练阶段额外学习了一类样本,在恰当的时机,按照约定的结构化格式(结构化输出)生成工具调用请求,而不是直接给出自然语言回答。在向模型发起请求时,除对话内容外,还会附带一份可用工具的清单,每个工具包含名称、功能说明与参数格式约定,这份清单同样作为文字纳入提示词,占用上下文窗口。

一次包含工具调用的完整交互,可以概括为如下循环:

输入 = 系统提示(含工具清单与参数格式说明)+ 对话历史 + 用户问题
重复:
    模型基于当前输入生成下一段内容
    若生成内容是自然语言回答 → 作为最终结果输出,循环结束
    若生成内容是结构化的工具调用请求(工具名 + 参数)→
        外部程序解析该请求,实际执行对应的函数、查询或操作
        将执行结果转换为文本
        将该文本追加到输入末尾,转到循环开头,模型据此继续生成

这一循环可以反复执行多轮,模型每一轮都基于此前所有工具的返回结果决定下一步是继续调用其他工具,还是已经掌握了足够信息、可以给出最终回答,这种“依据已有信息判断下一步行动”的循环结构,正是智能体系统的基本运行方式。

14.5.3 MCP协议

在电子数据交换(EDI)出现之前,贸易伙伴之间的系统对接依赖各自约定的私有格式,贸易伙伴数量一旦增多,需要两两定制维护的对接关系随之成倍增长;EDI通过约定统一的报文标准,把这种两两对接的问题,化简为每一方只需按同一套标准对接一次。工具调用领域面临结构相似的问题:不同的大模型应用(客户端)需要接入形形色色的工具与数据源(网页搜索、企业数据库、文件系统、第三方业务系统等),如果每一对客户端与工具都各自约定一套私有的调用格式,接入的维护成本会快速增长。

模型上下文协议(Model Context Protocol,MCP)针对这一问题提出了统一的接入标准:任何工具或数据源,只要按照MCP规范封装成一个“MCP服务器”,对外以统一的方式声明自己提供哪些工具、每个工具的参数格式是什么;任何大模型应用,只要实现“MCP客户端”、能够按照同一套协议发起工具发现与调用请求,就可以直接连接任意一个MCP服务器,不需要为每一对客户端与服务器单独编写适配代码。

MCP的典型架构如图14-5所示。

mcp_architecture cluster_host MCP Client / Host 环境 cluster_servers 标准化 MCP Servers 工具集群 agent_core 智能体(AI Agent) llm 大语言模型(LLM) agent_core->llm mcp_client MCP Client 协议层 agent_core->mcp_client mcp_wms WMS MCP Server (提供库位查询、拣货指令) mcp_client->mcp_wms Stdio/SSE mcp_gis GIS 路径规划 MCP Server (提供路况测距、路线优化) mcp_client->mcp_gis mcp_tms TMS 运力调度 MCP Server (提供车辆派发、运单更新) mcp_client->mcp_tms

图14-5 模型上下文协议(MCP)

一次基于MCP的调用,大致包含客户端向服务器查询当前提供哪些工具,以及客户端将模型生成的结构化调用请求转发给对应服务器、取回结构化返回结果,其余的执行细节由服务器一侧实现,对客户端保持透明,客户端不需要关心不同工具各自的内部实现差异。

14.5.4 命令行执行体系

工具调用,多数是针对特定用途单独定义的函数,例如查询天气、查询库存。与此不同,还存在一类通用性更强的工具形态,让模型直接生成一段命令行指令或一段程序代码,交由外部环境执行,再把执行的输出(包括程序打印的结果与报错信息)返回给模型。命令行和编程语言本身就是操作计算机的通用接口,几乎所有可以在计算机上完成的任务,包括读写文件、处理数据、调用其他程序、部署与配置软件等等,都能够通过这一接口完成,因此相比逐一定义单项功能的工具,暴露命令行或代码执行能力,让模型获得的是一种不针对特定任务、覆盖面更广的操作能力。

这种通用性同时意味着更高的不确定性,单项功能工具的参数范围与可能产生的后果通常预先可以枚举清楚,而命令行指令或代码理论上可以执行任意操作,一旦模型生成的指令存在偏差,波及的范围也更难预先界定。因此,实际系统通常将命令执行环境限制在一个隔离的沙箱之中,赋予其有限的权限,以降低误操作带来的风险。MCP协议与CLI模式的对比如表14-1所示。

表14-1 MCP协议与CLI命令行模式的对比

评估维度 MCP 协议模式 CLI 命令行模式
Token 消耗 较高(需在上下文中完整注入各工具的 JSON Schema 定义) 极低(仅需提供通用的终端执行接口,命令生成依托先验知识)
执行机制 结构化单步函数调用,多步骤需反复通过模型决策中转 支持利用管道符(|)和脚本语言在底层一次性流水线处理
参数确定性 极高(具备严格的类型定义与校验,不易出错) 中等(需防范字符串转义、路径错误及环境依赖差异)
安全性与权限边界 极高(严格限制在 MCP 暴露的白名单接口内,便于权限隔离) 需严格的沙箱隔离机制(容器化运行,防止越权破坏系统文件)
典型适用场景 企业核心业务系统对接(如 WMS、TMS、ERP 生产业务交互) 自动化运维巡检、海量数据清洗、批量报表汇总、开发调试

14.6 智能体与技能

14.6.1 智能体的本质

在工具调用循环中,模型每一轮生成之后是否结束、是否继续调用下一个工具,理论上都由这个循环本身决定,在较为简单的应用场景里,需要完成的步骤数量与顺序往往可以预先大致确定,调用方只需按固定流程依次触发即可。智能体(agent)要处理的是另一类场景:任务目标明确,但完成目标所需的具体步骤数量、步骤顺序,在任务开始之前无法完全确定,需要根据每一步实际观察到的结果动态调整下一步该做什么。例如处理一批异常运单,需要先查询异常原因,原因不同,后续该联系承运方还是联系收货人、是否需要重新调度车辆,都取决于查询结果,无法提前写成一条固定的处理流程。智能体的本质,可以概括为以大语言模型作为持续运行的决策核心,反复执行“感知当前状态、判断下一步行动、执行该行动、观察行动结果”这一循环,直到任务目标达成或满足预先设定的终止条件为止。智能体架构把“下一步该做什么”这一决策,从调用方转移给模型自身,让模型依据任务目标与已经观察到的中间结果自主判断,从而适应那些步骤路径无法在事前穷举清楚的任务。

14.6.2 智能体的实现框架

智能体的运行过程,可以视为调用循环的扩展版本,增加了显式的目标判断与终止条件:

输入 = 任务目标 + 可用工具清单 + 初始上下文
状态 = 初始上下文
重复,直到达成目标或达到预设的最大步数:
    模型依据任务目标与当前状态进行推理,判断当前进展与仍然缺少的信息
    模型决定下一步行动:
        若判断任务尚未完成 → 选择一个工具并生成调用参数
            执行该工具,将返回结果并入状态,进入下一轮
        若判断任务已经完成 → 生成最终结果,循环结束

其中“判断任务是否完成”这一步是智能体区别于简单工具调用循环的关键环节,简单的工具调用通常由调用方决定循环何时结束,而智能体需要模型自身具备识别目标是否已经达成的能力,这一能力同样来自对齐训练阶段包含的相应样本,而非模型结构上专门设计的判断模块。为避免模型反复判断“尚未完成”导致循环无法正常结束,实际系统通常会设置最大步数等限制,一旦达到上限就强制终止循环并返回当前已取得的进展。

14.6.3 长程运行中的记忆管理

智能体循环每执行一轮,都会把该轮的推理内容与工具返回结果并入状态,状态会随着运行步数增加而持续增长。但模型一次能够处理的词元总量存在上限,当智能体需要执行的步骤较多、运行时间较长时,累积的状态很容易超出这一上限。为此,实际的智能体系统通常引入某种记忆管理机制,完整保留最近若干轮的详细内容,供模型做当前决策时参考;对于更早的步骤,则压缩为一段简要摘要,只保留对后续决策仍然有用的结论性信息,舍弃过程性细节,以此把状态规模控制在上下文窗口容许的范围之内。

14.6.4 智能体技能

智能体在实际处理某一类具体任务时,往往需要遵循一套相对固定的操作规范或最佳实践,例如处理某类异常运单时应当依次核实哪些信息、生成某类报告时应当采用什么格式。若把这些针对具体任务类型的详细操作说明,全部写入每一次调用都会用到的系统提示,会占用大量原本可以留给对话内容本身的上下文窗口空间,而其中的大部分说明,在处理其他类型任务时其实用不上。

智能体技能的思路是,把针对某一类任务的操作说明、参考示例整理成一个独立的、可以按名称和简要描述被索引到的模块(技能),平时只在系统提示中保留各个技能的名称与一两句功能简介,模型据此判断当前任务是否与某个技能相关;一旦判断相关,再把该技能完整的详细内容读取并并入当前状态,供后续步骤参考。这一“先依据简要描述判断是否需要、需要时才读取完整内容”的思路,与检索增强生成中先检索、再补充上下文窗口的方式类似,区别在于检索增强生成补充的是用于回答问题的事实性资料,而技能机制补充的是用于指导任务如何执行的过程性说明,二者都是应对上下文窗口容量有限这一约束的、按需调用外部内容的解决办法,只是所调用内容的性质不同。

为了让通用大语言模型掌握垂直场景的专业操作能力,业界通常采用标准化的Markdown规范文档为Agent封装具体的业务技能(Skill)。

一个标准的技能文档通常包含元数据配置层(YAML Frontmatter)与操作指令正文层两部分:

---
name: coldchain-temperature-alert-handler
description: 处理冷链运输途中车载传感器上报的温度异常超标告警,执行业务核验并触发应急流程
version: 1.0.0
tools_required:
  - query_vehicle_status
  - update_chiller_setpoint
  - dispatch_emergency_warehouse
---

# 业务背景
当冷链车上报的实时回风温度超过货物允许温区阈值且持续时间 > 15 分钟时触发本技能。

# 执行步骤 (SOP)
1) 调用 `query_vehicle_status` 工具,核实当前车辆所在地理位置、货物种类(如疫苗/冷冻肉)及门磁状态。
2) 分支逻辑判断:
   - 若门磁处于开启状态(属于装卸作业造成的短暂温升),记录监控日志,暂不触发紧急报警;
   - 若门磁关闭但温度持续上升(制冷机组故障),立即执行下一步。
3) 调用 `update_chiller_setpoint` 尝试向车载终端下发强制强冷指令。
4) 若 5 分钟后二次检测温度仍未改善,调用 `dispatch_emergency_warehouse` 查询沿途最近的合作应急冷库,生成越库转运预案并通知车队主管。

# 输出规范
必须输出包含 `alert_level`, `root_cause`, `action_taken`, `next_plan` 字段的结构化 JSON 报告。

14.6.5 渐进式披露机制

企业级物流平台可能注册有数百项专业技能。如果一次性将所有技能的详细操作步骤都载入上下文,会瞬间占满上下文窗口并导致严重的注意力弥散。 在实际工程中,渐进式披露(Progressive Disclosure) 采用两阶段的按需加载策略来优化 Token 消耗:

第一阶段轻量级匹配:系统将所有已注册技能的元数据清单(仅包含 name、description 与 required_tools 字段)一次性加载至模型上下文,通常仅消耗几百个Token。模型依据用户描述的业务事件进行快速意图识别与技能路由,精准锁定目标技能名称。

第二阶段按需详解:确认目标技能后,系统从文件系统或知识库动态加载该特定技能的完整操作SOP 文档(包含逐步执行步骤、分支判断逻辑、工具参数规范与输出格式定义),此时才将详细的操作指令注入上下文窗口。模型基于这份完整的上下文规范执行具体的工具链调用与业务逻辑推理。

这种设计通过延迟加载,在支持企业级数百甚至数千项专业技能的同时,将日常推理的基准Token 消耗降低至原来的20%以下,同时大幅提升了指令遵循的准确率与系统的可维护性。

除单一智能体独立完成整个任务之外,另一类实现方案是把复杂任务拆分给多个各自专注于不同子任务的智能体分别处理,再由一个统筹角色汇总各自的结果、协调彼此之间的先后顺序与信息传递,这种多智能体协作方式适合任务本身可以清晰拆分为若干相对独立子任务的场景,但相应地也引入了子任务之间如何分工、结果如何汇总一致等额外的协调成本,是否采用需要结合具体任务的可拆分程度权衡。

14.7 大模型在智能物流中的应用

14.7.1 物流异常工单处理智能体

物流企业的客服与调度岗位,日常需要处理大量运单查询与异常投诉,例如货物延误、破损、少件等情况。人工处理这类工单,通常需要在运输管理系统(TMS)、仓储管理系统(WMS)、客服工单系统等多个系统之间切换查询运单状态,还需要熟悉理赔标准、时效承诺等一系列政策条款,并结合具体情况判断应当如何答复客户、是否需要联系承运方或仓库核实、是否需要升级处理。这类工作兼具信息查询、政策比对与多步骤判断的特点,是智能体可以发挥作用的典型场景。

以某物流企业客服场景为例,可以将把企业的理赔标准、时效承诺、常见问题处理规范等文档切块并编码,建立一个供检索的政策知识库;将TMS的运单状态查询、WMS的库存查询、工单系统的创建与更新等内部接口,封装为可供模型调用的工具;约定智能体的处理原则与工单记录的输出格式;利用循环结构,让智能体在接到客户问题后,自主判断需要检索哪些政策条款、需要查询哪些系统数据,直至能够给出处理结果或客户回复。

14.7.2 应用效果分析

这类智能体在实际运行中,效果主要体现在以下几个方面。处理规则的执行更加一致,不同工单只要情形相近,得到的处理结果不会因为客服人员经验、状态的差异而产生明显出入,这一点在结构化输出约定统一的前提下可以得到保证。响应可以做到全天候即时受理,客户提交查询后不必等待人工排班处理初步问题,人力可以更多集中在需要专业判断的复杂或高风险工单上。此外,由于智能体的每一步检索与调用都可以被记录下来,处理过程具备较好的可追溯性,便于事后复核某个工单的处理依据。

同时也需要认识到这类应用的局限。模型对政策条款的理解与工具调用参数的生成仍然可能出现偏差,对于涉及金额较大、条款存在模糊地带、或可能引发客户关系纠纷的工单,仍需要设置人工复核环节,不宜让智能体在没有约束的情况下自主完成全部决策。实践中通常会循环中,加入一条基于工单金额、涉及条款清晰程度等因素的判断分支,一旦触发即转交人工处理,而不是单纯以模型自身的完成度判断作为唯一依据。

14.7.3 实现步骤

搭建上述智能体,大致可以按以下步骤展开。第一步整理企业现有的理赔标准、时效承诺、常见问题处理规范等文档,切块并编码,建立政策知识库。第二步将TMS运单查询、WMS库存查询、工单创建与更新等能力,分别封装为独立的工具,并按MCP规范声明各工具的名称、功能说明与参数格式。第三步编写系统提示,写明智能体的处理原则、可用工具清单,以及结构化工单记录的输出格式约定,同时写明触发人工复核的判断条件。第四步实现智能体主循环,将上述知识库检索、工具调用与系统提示整合为可运行的程序。第五步在小范围工单上试运行,收集实际处理结果,据此修正提示词表述、补充知识库中覆盖不足的政策条目、调整触发人工复核的判断条件,再逐步扩大处理范围。第四步的主循环可以用如下伪代码表示:

初始化:
    加载政策知识库(向量数据库)
    注册工具:query_order_status(查询运单状态)、
             query_warehouse_stock(查询库存)、
             create_followup_task(创建后续处理任务)等
    设定系统提示:处理原则、工具清单、工单输出格式、人工复核触发条件

接收客户问题 question
状态 = 系统提示 + "客户问题:" + question
重复,直到生成最终结果或达到最大步数:
    模型基于当前状态判断:是否需要参考政策条款
        若需要 → 在知识库中检索相关条款,将检索结果并入状态
    模型基于当前状态判断下一步行动:
        若需要查询某系统数据 → 调用对应工具,将返回结果并入状态,进入下一轮
        若判断涉及金额较大或条款模糊 → 生成待复核说明,转交人工处理,循环结束
        若信息已经充分 → 按约定格式生成工单记录与客户回复,循环结束

除工单处理之外,本章介绍的技术也可以组合用于其他场景:例如结合计算机视觉技术识别运单、发票等单据上的文字信息,再由大语言模型按识别结果整理为符合企业数据库字段要求的结构化记录,替代人工逐项录入;又如把数据仓库中经过多维分析得到的经营指标,交由大语言模型生成面向管理者的自然语言解读报告,把表格与图形形式的分析结果转换为便于非技术人员理解的文字说明。这些场景的共同点,都是把本章介绍的语言理解、检索、工具调用与结构化输出能力,与企业已有的信息系统和数据资产结合起来,而非把大语言模型当作独立于现有物流信息系统之外的新系统。

本章小结

本章围绕大语言模型的基本原理与应用方法展开。首先介绍了大语言模型“预测下一个词元”的基本原理,解释了大语言模型的Transformer架构,重点说明了自注意力机制如何克服循环神经网络在长文本处理中的困难,以及词元化、词向量等基础环节的设计考虑。接下来讨论了如何为大语言模型补充知识与能力:一是通过检索增强生成(RAG),弥补模型参数中未包含的知识;二是通过提示工程手段,引导模型给出更符合任务需求的推理过程与输出格式;三是通过工具调用与MCP协议,使模型能够访问外部系统的数据与能力。在此基础上,进一步介绍了智能体的概念,说明了智能体与简单工具调用循环的区别,以及技能渐进式披露等机制的必要性。最后,以物流行业的客户理赔与工单处理为例,展示了如何将知识库检索、工具调用、系统提示与结构化输出等技术整合为可运行的智能体系统。

课后习题

  1. 简述大语言模型“预测下一个词元”的基本原理,并说明其与N元文法模型的本质区别。
  2. 循环神经网络在处理长文本时存在哪两个困难?Transformer架构是如何克服这两个困难的?
  3. 简述自注意力机制中查询向量、键向量、值向量的作用,并写出注意力的计算公式。
  4. 简述字节对编码(BPE)构建词表的基本过程,并说明为什么采用BPE的模型不会出现未登录词。
  5. 简述检索增强生成(RAG)离线建库与在线问答两个阶段的主要步骤,并说明向量数据库与关系型数据库在检索方式上的差异。
  6. 什么是思维链提示?结合一个物流费用计算的例子,说明其作用机制。
  7. 简述一次包含工具调用的完整交互循环。MCP协议解决的是什么问题?
  8. 智能体与简单的工具调用循环有何区别?长程运行中为什么需要记忆管理机制?

参考文献

[1] VASWANI A, SHAZEER N, PARMAR N, et al. Attention is all you need[C]// Advances in Neural Information Processing Systems (NeurIPS), 2017, 30: 5998-6008.

[2] LEWIS P, PEREZ E, PIKTUS A, et al. Retrieval-augmented generation for knowledge-intensive NLP tasks[C]// Advances in Neural Information Processing Systems (NeurIPS), 2020, 33: 9459-9474.

[3] YAO S, ZHAO J, YU D, et al. ReAct: Synergizing reasoning and acting in language models[C]// International Conference on Learning Representations (ICLR), 2023.

[4] SU J, AHMED M, LU Y, et al. RoFormer: Enhanced transformer with rotary position embedding[J]. Neurocomputing, 2024, 568: 127063.

[5] Anthropic. Model Context Protocol Specification[EB/OL]. (2024-11-25)[2026-03-01]. https://modelcontextprotocol.io.

[6] OPENAI. Structured Outputs in the API[EB/OL]. (2024-08-06)[2026-03-01]. https://platform.openai.com/docs/guides/structured-outputs.

[7] 申金升, 汝宜红. 智能物流系统导论[M]. 北京: 机械工业出版社, 2022.