第 1 章先观察：LLM 是什么，又不是什么

1.1 从一个问题开始：怎样才算答对？

在聊天窗口里输入问题，等软件给出回答，这是许多人接触大语言模型的方式。本书把提供这项完整服务的软件叫作助手。发给它的文字叫输入，它返回的文字叫输出，也就是回答。助手内部有一个负责计算、生成文字的模型；显示对话、查找文件等工作，则由模型周围的应用程序处理。两者怎样配合，我们会从具体例子讲起，不需要你事先学过编程。

假设你正用一个助手准备出差。你让它补全一句关于法国的话，问它住宿费能报销多少，再让它查一下订单。这几件事都在同一个聊天窗口里完成，但判断回答对不对，依据各不相同：地理问题要核对事实，报销问题要查单位现行的制度，订单问题则要查那一笔订单的记录。助手的回答再有说服力，也代替不了这些依据。

所以，我们首先要问的，不只是“助手能不能回答问题”，而是：任务、输入和回答都摆在面前时，怎样判断系统完成了要求？先把这件事弄清楚，再去研究模型内部怎么算。第 1 章先学会判断回答，第 2 章再看回答怎样产生。到了第 3、4 章，我们会亲手完成其中两件事：把文字变成数字，再用计数预测接下来的文字。

任务（task）规定要做成什么，以及做的过程中有哪些限制；评测标准（evaluation criterion）规定怎样才算合格。要求“说出法国首都”，就要判断答案是否符合事实。要求“给句子补一个合理的结尾”，就可能有多种合格答案。要求“查询订单”，还要看助手是怎么得出答案的：它得查对订单，也不能为了报告状态就去修改订单。

本章准备了五组事先编写的教学记录，分别讨论事实补全、开放补全、线索变化、制度更新和订单查询，每组两条。这些回答不是从真实模型上测出来的。制度、人物和订单都是虚构的，法国首都则是普通的地理事实。每组案例着重说明一个问题，完整的条件和回答都列在正文中，无须注册账号或运行模型。这里的一条“记录”，就是一次问答的条件、输入和回答。把两条放在一起，才能看清某个条件或回答改变后，有什么区别。如果查阅配套数据，可以在 part-i-v1 版本中找到这些记录。

本书会一直区分教学例子和实际测量。例子能说明在给定条件下会得出什么结论；要估计一个真实系统有多可靠，还得先规定怎样抽取样本、怎样评测，再收集它的实际表现。

1.2 先定标准，再比较回答

1.2.1 事实补全：句子通顺，答案也可能错

例 1.1——同一句话的两种续写。两条记录的输入都是 法国的首都是___，均没有可用工具。回答如下：

记录	回答	事实标准	结果
第一条	`巴黎。`	说出首都：巴黎	通过
第二条	`里昂。`	说出首都：巴黎	未通过

填入这两个城市名，句子都很通顺。只看语法，就发现不了第二条回答的错误。我们还得另找可靠依据，核对“这个城市是法国首都”是否属实。

可见，一段续写完全可能读起来合理，却不符合事实。模型把没有充分依据的内容当作事实说出来，通常会被笼统地称为“幻觉”（hallucination）。但只说“出现了幻觉”，既没指出具体错在哪里，也没说明该怎么改。“回答把里昂说成了法国首都”就清楚得多：它指出了一个可以核查的错误。

语言模型学习文本中的规律，也会学到许多有用的事实关联。可是，文本里同样有错误、虚构故事、过时信息和常见误解。模型预测出一种熟悉的续写，并不等于它能分清这些内容。TruthfulQA 研究了模型是否会说出类似人类常见误解的错误答案，提醒我们：回答是否真实，需要单独评测。本章的巴黎与里昂对照是自己编写的教学例子，并非取自该评测集。Lin 等，2022

回答“巴黎”，只说明这一次答对了。它不能证明同一个系统还会查找公司的现行制度、利用距离问题较远的线索，或按授权执行操作。要判断这些能力，得分别设计任务，说明各自的条件。

1.2.2 开放补全：答案不一样，未必有一个错了

法国首都有确定的答案，所以“里昂”必须判错。但并非每个问题都只有一个正确答案。现在把输入换成 补全：猫坐在___上。。题目没有要求复述一件真实发生的事，也没指定必须填哪个名词。“垫子”和“沙发”都说得通。如果评测程序只认“垫子”，就会把本来合格的回答判错。

既然两个结尾都可以，助手怎么选呢？一种办法是每次都选同一个；另一种办法是两个都允许选，但选中的机会不同。可以想象袋子里有十张同样大小的纸条，六张写着“垫子”，四张写着“沙发”。不看内容，随机抽出一张，每张被抽到的机会相同。每次抽完都放回去、重新混匀，下一次的机会分配才不会变。抽到“垫子”的机会就是十分之六，写成小数是 0.6，写成百分数是 60%；“沙发”则是 0.4，也就是 40%。这就是这里所说的概率。它规定的是怎么选，并不保证接下来抽十次恰好有六次抽中“垫子”，也不表示句子有多大可能符合事实。

例 1.2——概率不变，输出也可以不同。我们规定“垫子”的概率为 0.6，“沙发”为 0.4。把所有选项和各自的概率列在一起，就得到一个概率分布。程序可以用数轴代替纸条：把从 0 到 1 的一段分成两部分，前面长 0.6 的部分归“垫子”，后面长 0.4 的部分归“沙发”。再从 0 到 1 之间均匀地取一个数，包含 0，不包含 1。“均匀”是指长度相同的区间，被选中的机会也相同。取到的数小于 0.6，就选“垫子”；大于等于 0.6，就选“沙发”。这样，两种结尾被选中的机会与抽纸条时相同。

表 1.1——同一分布下的两次抽样。

记录	候选项与概率	抽样值	选中的回答	任务结果
第一条	垫子：0.6；沙发：0.4	0.2	`垫子。`	通过
第二条	垫子：0.6；沙发：0.4	0.8	`沙发。`	通过

按概率分布选择结果，叫作采样（sampling）。在这个例子里，概率分布没变，只是抽样值变了，回答就不同了。因此，不能仅凭两次回答不一样，就断定模型变了。

还要看任务到底要求什么。如果指令是“原样重复‘垫子’这个词”，“沙发”就不合格了。如果进一步要求逐字符完全一致，那么多加一个句号也算错。输出有变化是好是坏，要看任务允许什么。

真实实验中，指令、文档、模型版本或输出选择方式发生变化，都可能改变回答。要认定差异来自采样，就得控制或记录其余条件。本例能直接确定原因，是因为概率分布和两次抽样值都是我们事先给定的。

1.3 换掉线索，看回答会不会跟着变

前两组案例解决了“这个回答算不算合格”。接下来还要追问：回答真的依据了题目里的信息吗？假设一个助手遇到钥匙颜色的问题就答“红色”，它即使完全不读故事，也能答对红钥匙的题目。要区分它是在读题，还是碰巧答中，就得换一道答案不同的题。

例 1.3——只改线索中的颜色。第一条记录的输入是：

米拉把一把红色钥匙放进抽屉。灯关着。一列火车经过。有人关上了窗。钥匙是什么颜色？

第二条记录只把“红色”改成“蓝色”，其余文字不变：

米拉把一把蓝色钥匙放进抽屉。灯关着。一列火车经过。有人关上了窗。钥匙是什么颜色？

两条记录的回答都是 红色。。第一条答对了，第二条却与题目矛盾。关于灯、火车和窗户的句子都没改，正确答案之所以变了，只是因为钥匙换了颜色。

这段故事和问题都属于上下文（context），也就是模型这次运行时拿到的信息。这里，答案应由上下文中的一个细节决定。改动颜色，就得到了一组对照案例（contrastive case）：两份输入几乎相同，但我们明确知道，哪处改动使正确答案变了。如果系统一味重复先前的回答，就不可能两次都答对。

现在可以确定，第二条回答没有正确利用“蓝色”这条线索。但原因还没有查清：可能是应用准备输入时漏掉了线索，也可能是模型收到了线索却仍然答错。同一个表面错误，可能出在不同环节。先查清是哪一步出了问题，才知道该改哪里。

接下来至少要查两件事。首先，应用真的把“蓝色”发给模型了吗？聊天窗口里显示的内容，未必就是实际发给模型的内容。其次，如果确实发了，线索放在哪里会不会影响回答？可以保留蓝色线索和其余句子，只把线索移到问题前面。前一个问题要查实际输入；后一个问题要通过控制变量、比较不同位置来判断。

长上下文研究发现，相关信息的位置可能影响模型表现，这也说明值得做位置对照。不过，本章这个虚构的短故事并没有测量任何真实模型处理长上下文的能力。Liu 等，2023

这也体现了设计实验的一条原则：好的反例不只是再找出一次错误，还要帮助我们区分原先分不清的原因。只看红钥匙的故事，无法知道系统是在读线索，还是不管问什么都答“红色”；换成蓝钥匙，才能把这两种情况分开。

1.4 到模型之外查找依据

1.4.1 问的是现行规定，就得有现行文件

钥匙的颜色已经写在输入里。问制度时，情况就不一样了：所需信息可能存在别处，而且已经更新过。

这有点像开卷答题：书上刚修订了一条规定，答题的人得拿到并读到新内容，才有机会用它作答。文件保存在电脑上，也不等于它已经随问题一起发给了模型。

假设一家单位先后有两个制度版本。travel-v1 规定北京住宿每晚限额 600 元；travel-v2 取代 v1，将限额改为 750 元。这里的 v1、v2 只是“第 1 版”“第 2 版”的简称，方便追踪究竟用了哪份文件。用户要查的是现在适用的限额，答出一个曾经在制度中出现过的数字并不够。

例 1.4——有这份文件，不等于模型拿到了它。下面两条记录都以 v2 为现行制度，区别在于输入中是否包含它。

表 1.2——有无现行制度摘录时的回答。

记录	完整输入	本次提供的资料	回答
第一条	`北京差旅住宿每晚限额是多少？`	无；外部已有 v2	`每晚 600 元。`
第二条	`travel-v2：北京住宿每晚限额 750 元，取代 travel-v1（600 元）。北京差旅住宿每晚限额是多少？`	travel-v2	`根据 travel-v2，每晚 750 元。`

第一条回答给出了旧限额，没有完成查询现行制度的任务。第二条回答符合所给的现行摘录，还注明了版本。这组教学记录中，回答变好的同时，有一个条件明确变了：新规定放进了模型的输入。

这里要分清三件事：外部有现行文件，应用把现行文件发给了模型，模型根据文件答对了问题。前两件事，无论哪一件成立，都不能保证第三件事。系统可能拿对了文件却读错了，也可能碰巧答出 750，却说不出可靠依据。

如果这次没有拿到现行规定，助手应当说明“根据现有信息，我无法核实现行限额”，而不是没有依据地报出一个数字。这样虽然还没完成查询任务，至少如实交代了缺什么信息。评测时，有没有完成任务和缺少依据时有没有妥善处理要分别记录，不能把拒绝猜测与查证后答对算成同一种结果。

检索增强系统会用模型之外的软件查找资料，再交给模型生成回答。RAG 论文提出了将模型已经学到的信息与检索文档结合起来的架构。本例直接给出一小段摘录，是为了说明这两类信息的区别；怎样检索、怎样处理文档，留到后面的章节讨论。Lewis 等，2020

1.4.2 说“做了”，还得能查到执行结果

查制度要找到文件，查订单则要找到管理订单的程序。这里又多出一个区别：读取订单，只是了解状态；修改订单，却可能影响这笔交易接下来怎样处理。在聊天窗口里写一句话，本身既没有查询，也没有修改。

订单信息保存在另一个程序维护的记录中。本例使用 order-v1：订单 A-104 的状态为 processing，即正在处理。

例 1.5——查询状态与修改状态。第一条记录的输入是 查询订单 A-104 的状态。。助手没有连接查询工具，也没拿到查询结果，却回答 A-104 已发货。。第二条记录在同一请求后附上 应用提供 order-v1：order_id=A-104，status=processing。，得到的回答是 根据 order-v1，A-104 正在处理。。

两条记录都没有修改订单，但第一条仍然不合格：没改订单，不能说明它对订单状态的说法就有依据。第二条则满足了本例的两个要求：如实报告所提供的状态，同时不改动订单。

如果把请求改为“取消 A-104”，就需要修改订单了。本例规定，取消前必须获得审批。要确认任务完成，必须核实请求是否获得授权、规定的审批是否完成、取消操作是否执行，以及有没有成功的结果。单凭一句“A-104 已取消”，这些事情一件也证明不了。

即便模型输出的是结构化的工具调用请求，道理也一样。工具（tool）是模型之外的软件提供的操作，例如读取订单。模型可以给出调用参数，但由应用代码决定是否执行，再把结果传回来。ReAct 区分了模型提出的动作与环境返回的观察结果。本例中的审批要求是应用另行规定的，不是用了这套方法就自动有保障。Yao 等，2023

“没有依据”和“事实错误”有关联，却不完全一样。假如订单碰巧已经发货，第一条回答就符合事实，但仍不能证明系统查过订单。如果任务要求核实状态，缺少查询证据依然是问题。评测既要看最后说了什么，也要检查有没有按要求完成查询。

1.5 分清模型与整个系统

再回头看猫的例子。前面由我们直接规定“垫子”和“沙发”的概率，语言模型则会根据前面的文字，通过计算给出这些概率。如果要生成一段更长的回答，就选出一个片段，接到已有文字后面，再算下一步。如此反复，文字就一段段接了出来。

用更一般的说法，语言模型（language model）为语言单位组成的序列分配概率。本书讨论的文本生成器，通常根据前面的输入预测下一个单位。这些单位叫作 Token，可以是词、词的一部分、标点，也可以是编码方案规定的其他片段。

大语言模型（large language model，LLM）通过较大规模的训练，获得较广泛的语言能力。模型计算时要用到许多事先保存的数，这些数叫参数（parameters）。训练就是利用例子调整参数，让模型更好地完成训练要求。等我们向它提问时，它再用调整后的参数计算回答。第 2 章会仔细区分：改动这些数，与换一个问题，有什么不同。规模多大才算“大”，没有统一的数值门槛。第一部分主要讨论因果文本生成：根据已有序列，接着选出一个又一个 Token。不同架构和训练目标的区别，后面会进一步介绍。

给续写内容分配概率，可以用来生成文字，但这样的计算本身并不提供现行制度库、订单服务或授权机制。完整的系统（system）除了模型，还包括负责挑选输入、查找依据、保存记录、执行获准操作和展示结果的软件。因此，两个系统即使用同一个模型，能做什么、做得多可靠，也可能很不一样。

一次请求怎样处理

应用保存的记录1. 选取的消息和审批状态
处理步骤2. 应用组织上下文
模型保存的数值3. 模型使用固定权重
处理步骤4. 应用检查输出

数据按 1 → 2 → 3 → 4 传递；是否执行操作，由应用控制 ⇢。

从外部查到的依据

模型之外travel-v2：每晚 750 元
模型之外order-v1：A-104 正在处理

外部资料在第 2 步加入上下文。有这份文件，不等于已经读取了它。

图 1.1——模型是整个系统中的一个计算环节。本书原创图示 · CC BY-SA 4.0。

图 1.1 把制度更新和订单查询中各个环节的职责列了出来。应用先选取外部文档，文档才会进入模型的上下文；查询订单后，应用才拿到相应的记录。模型根据应用提供的材料生成文字，或提出操作请求。至于操作能不能执行、有没有真正改动数据，仍由应用把关。

分清这些环节，就更容易查出问题。假如应用发给模型的是 travel-v1，那么模型再善于阅读 travel-v2，也帮不了这一次回答，因为它根本没拿到 v2。如果现行文件已经发过去，回答却把金额说错了，就要往后查模型怎样使用这份文件。如果取消订单时跳过了审批，最后的回复再流畅，也补不上这一步。排查时，要先确定哪个必要环节出了问题。

前面的五组案例也说明，不能因为助手能聊天，就认定它具备某些能力：答对一次补全，不等于总能说真话；根据文档作答，不等于参数永久学会了文档；说已经执行，不等于真的执行了。证据不足时，这些推断就不能成立，无须先给系统是否“真正理解”下一个笼统结论。把问题落实到具体计算和依据，比用“理解”二字包办解释更有帮助。

1.6 把评测过程记清楚，让别人也能核查

1.6.1 条件、标准和结果都要保存

前面已经学会沿着各个环节查错，但别人怎样才能核对我们的判断？仍以制度问题为例，只写“助手回答了 600”，别人没法知道它有没有拿到新规定。写成“已提供限额为 750 的 travel-v2，助手却回答 600”，差错才清楚。如果再补上“员工可能按错误限额安排报销”，就交代了这个错误为什么值得处理。

把这样的记录整理起来，就形成了评测中的几类材料。一个评测样例（evaluation case）要写清输入、相关运行条件，以及怎样才算合格。运行或检查这个样例后，才能得到结果。如果没有达到标准，失败记录（failure record）要写明实际结果与要求差在哪里。风险记录（risk record）则说明可能造成什么后果，以及怎样预防或减轻这些后果。某次运行没有造成损失，不代表风险就不存在。

表 1.3——五组案例的判定依据与风险。

案例	判定依据	本例的问题	可能后果与处理办法
事实补全	回答法国首都是巴黎	第二条回答说成了里昂	读者可能信以为真；另找可靠依据核对
开放补全	两种合理结尾都合格	两条回答都没错；只认一个标准答案会误判“沙发”	合理回答可能被判错；说清楚允许哪些变化
线索变化	红钥匙答红色，蓝钥匙答蓝色	题目改成蓝钥匙后，仍回答“红色”	可能没用上线索；先查实际输入，再比较线索位置
制度更新	按现行制度回答 750 元；无法核实时如实说明	第一条回答仍使用旧限额 600 元	可能误导报销；核对制度版本，并检查是否发给了模型
订单查询	报告“正在处理”；没查到时如实说明；不修改订单	第一条回答没有查询就声称已发货	错误状态可能误导后续操作；先核实，修改前须获批准

这份比较表可以作为基线（baseline），也就是之后比较变化时使用的一份固定参照。不要把它与 base model 混淆：后者说的是模型所处的训练阶段。两个英文名称相近，指的却是不同的东西。

要让失败报告有用，还得保存完整输入和原样回答。只写“制度答错了”，别人就分不清是用了旧文件，还是读错了新文件。做真实模型实验时，还应保存模型和分词器版本、指令、实际带入的历史记录、资料版本、工具返回结果、输出选择设置，以及原始输出。如果程序用一串可以重现的随机数来选择回答，还要记下这串数的起始设置，称为随机种子。它有助于重现选择过程，却没有保存问题和系统的其他条件。第 4 章会给出一个完整例子。

1.6.2 总分会漏掉哪些差别？

例 1.6——给这组教学记录计分。按前面的标准，事实补全有一条通过，开放补全有两条，线索变化、制度更新和订单查询各有一条，总共十条，六条通过。如果评测程序在开放补全案例中只认“垫子”，就会算成五条通过。回答一条也没变，变的是判定标准。

即使“十条通过六条”算得完全正确，也只能说明这十条教学记录的情况，不能当作测得的模型准确率。这些记录是为了说明特定问题而编写的，不是从真实业务中抽取的样本。把它们合成一个百分比，还会掩盖不同问题的轻重：措辞换了但意思合理，与没查订单就声称已发货，显然不是一回事。

比较系统时，要让人看得明白测了哪些案例、按什么标准计分。如果刚修复了制度检索，首先应该检查制度案例现在能否依据现行文件作答，而不是只看总分涨没涨。整体平均分可以作为补充，却不能代替对具体问题的分析。后面的评测章节会讨论样本如何体现真实任务分布、为什么要重复运行，以及结果有多大不确定性。这里先养成一个习惯：每个分数，都能回头查到对应的案例和判定依据。

1.7 本章小结

面对同一个聊天窗口，我们现在会问几类不同的问题：回答符合任务要求吗？用上给定线索了吗？模型拿到现行资料了吗？报告的状态与订单记录一致吗？获准执行的操作真的完成了吗？

这些问题帮助我们分清：说得流畅与说得正确、合理变化与错误、有上下文与用好上下文、生成文字与执行操作。模型利用训练中学到的规律进行计算，模型之外的软件则负责提供信息、控制操作后果。接下来，第 2 章会沿着一个 Token 的生成过程，看看计算中究竟发生了什么变化，又怎样才算模型本身变了。

1.8 习题

制定标准。任务要求“给出两个适合在法国度假的目的地”。评测程序只接受“巴黎和里昂”，回答却是“尼斯和波尔多”。这个评测程序有什么问题？你会怎样规定合格标准？增加什么要求后，只接受原来的答案才合理？
设计对照。系统答对了红钥匙的故事。请再设计两组比较，分别检查线索中的颜色和线索的位置是否影响回答，并说明每组比较要保持哪些条件不变。
依据与事实。假设订单查询案例中那句未经核实的“已发货”，碰巧符合实际情况。现在回答在哪一点上变好了？任务的哪项要求仍然没有证据证明已经完成？
追踪来源。外部已有 travel-v2，应用实际发给模型的却是 travel-v1，回答为 600。沿着查找资料、提供资料、生成回答的顺序，最先能确认哪一步出了错？手工改掉最后的数字，能否证明系统选对了文件？
汇总评分。计算表 1.3 中每组案例和全部案例的通过数。再解释：为什么把例 1.1 中“巴黎”这条回答复制十份加进来，就能提高总体通过比例，却不能证明系统多了一项能力？
执行依据。日志里有一个取消订单的提议，最后还写着“已取消”，但没有审批记录和工具返回结果。还有哪些事情需要核实？为什么把“已取消”再说一遍也没有用？
失败报告。某系统已经收到 travel-v2，却回答 600。请写清输入条件、应有的行为、实际差错和风险。它与制度更新案例中的第一条记录有什么不同？
观察的限度。输入中加入文档后，模型改了回答。围绕系统保存了什么，提出两个仅凭这一现象还无法回答的问题，并说明原因。

1.9 参考解答

题目允许多种正确组合，不能只认其中一组。合格标准应是：给出两个位于法国、符合已有度假要求的目的地，措辞和排列顺序可以不同。只有指令明确要求逐字符返回“巴黎和里昂”，才应该严格核对这个字符串；那时任务已经变成了原样复述。
检查颜色时，只把红色改成蓝色，其余文字和设置不变，正确答案应随之变成蓝色。检查位置时，保留蓝色线索和其余句子，只把线索移到问题前，正确答案仍为蓝色。前一组看回答是否跟着内容变，后一组看位置是否影响表现。两者都不能单独说明模型内部为什么会这样。
回答现在符合事实，但仍然没有证据证明系统查过正确的订单记录。如果要求核实状态，碰巧答对不能算作按要求完成了查询。
最先能确认的问题是：应用没有把新文件放进实际输入。改掉显示的数字，可以纠正这一次的回答，却没有修好选取文件的环节，也无法保证下次会用对文件。
各组通过数依次为 1/2、2/2、1/2、1/2、1/2，总计 6/10。加入十份通过记录后，变为 16/20。已有的成功案例在总数中占比更高了，但既没有增加新任务，也没有增加独立测量，更不能说明系统改进了。
还要核实是否有权限、是否完成规定的审批、是否真的执行了取消，以及是否有成功结果或状态记录。提出操作不等于执行操作。再生成一句话，只是多了一条文字记录，补不上这些步骤。
输入条件：问题中附有现行 travel-v2 摘录。应有行为：回答 750，并注明来源。实际差错：拿到新规定后仍回答 600。风险：用户可能按旧限额办事。与原案例第一条不同，这里已经知道新文件发给了模型，接下来应查它怎样使用文件，而不是继续追查有没有提供文件。
例如：应用是否会保存这份文档，并在下次运行时再次提供？是否有另外一个过程改动了模型参数？仅凭回答变化，无法知道这两件事，因为只改变输入就可能让回答改变。

1.10 参考文献

Lin、Hilton 与 Evans，TruthfulQA: Measuring How Models Mimic Human Falsehoods（2022）。这项研究考察模型是否会重复人类常见的错误观念。结合事实补全案例阅读，可以更清楚地看到：语言流畅与内容真实，需要分别判断。
Liu 等，Lost in the Middle: How Language Models Use Long Contexts（2023）。研究比较了相关信息放在上下文不同位置时，模型表现怎样变化。可以对照本章提出的位置实验来读。
Lewis 等，Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（2020）。论文把模型学到的信息与外部检索到的文档结合起来。它有助于理解本章的制度案例：新规定要先交给模型，才能作为回答的依据。
Yao 等，ReAct: Synergizing Reasoning and Acting in Language Models（2023）。该方法交替生成推理文字和动作提议，并接收环境返回的结果。阅读时可以关注“提出查询”与“拿到查询结果”的区别；本章的审批要求则是应用另行规定的。

第 1 章 先观察：LLM 是什么，又不是什么