大模型
全景与分类

把新闻标题翻译成可验证的句子

新闻标题喜欢使用“首个”“最强”“全能”“端到端”“开源”和“百亿参数”等浓缩词。阅读时可以逐词拆开：所谓“首个”是在哪个时间、哪个任务和哪个数据集上成立？所谓“最强”比较的是准确率、人工偏好、延迟还是成本？所谓“全能”支持哪些输入输出组合，哪些任务没有测过？所谓“端到端”是否真的由一个模型完成，还是把预处理和后处理隐藏在产品里？翻译之后，标题就从结论变成了待验证的假设。

“模型会学习”也需要说明学习的对象。预训练可能让它学习文本中的共现规律，监督微调可能让它学会按照模板回答，偏好训练可能改变拒答和语气，检索系统可能在运行时提供新文档。把这些来源拆开后，你会发现很多争论其实是在谈不同层次：有人谈参数中的表示，有人谈应用中的外部知识，有人谈产品的交互设计。

还要注意时间。模型、接口、许可证、价格和安全策略都可能更新；一年前的文章不一定能说明今天的服务行为。模型分类卡中加入访问日期，不是形式主义，而是让未来的你知道结论属于哪个版本。若发现页面更新，保留旧记录并在新记录中写出变化，不要无声覆盖。

对于初学者，最容易落入的陷阱是把“知道名称”误认为“理解模型”。名称只能帮助定位文档，不能代替输入输出、训练阶段和评估。你可以给自己设一个门槛：每记住一个模型名，就至少写一条它的输入、一条它的输出、一条限制和一条来源。四条信息比十个品牌名更有学习价值。

一次完整的模型描述示范

假设你要向同学介绍一个“图文问答模型”。不要只说“它是一个多模态大模型”，可以按六个轴说：它接受图像和文字问题，输出文字；模型的具体版本和最大输入需要查官方文档；权重是否可下载、代码是否公开、许可证是否允许目标使用，要分别记录；架构可能包含视觉编码器和语言生成部分，但需要技术报告确认；若它是指令微调版本，说明它更偏向遵循请求，而不是重新训练了全部知识；应用上可以先测试课程图表问答，不能把一次正确回答当成医学或财务判断依据。

这段描述同时包含事实、待确认和使用建议。事实是“图文输入、文本输出”这一接口约定；待确认是具体版本、分辨率和许可证；使用建议是“先测试课程图表”。把三者分开，读者就能知道哪些内容可以直接引用、哪些内容需要继续查、哪些内容只是一个低风险实验计划。

再把描述写成一句可复用的摘要：“这是一个图像+文本到文本的指令模型，具体规模和许可待核对；它适合先做带人工复核的图表问答原型，关键风险是小字、数量、空间关系和来源引用。”这句话没有夸大能力，却给出了下一步。任何新模型都可以用同样的句式介绍。

如果同学追问“它是不是比文本模型聪明”，不要接受这个问题的模糊前提。可以改问：在相同提示和相同评估样例上，图文输入是否比先 OCR 再文本生成更准确？视觉编码增加了多少延迟和成本？图片不能出域时是否有本地部署方案？这样，比较就回到了任务、证据和约束。

一张地图怎样帮助你处理新名词

当你第一次看到“视觉语言模型”时，先不要急着记住品牌。沿着本章的坐标走一遍：模态上，它至少涉及图像和文本；I/O 上，它可能是图文到文本，也可能支持文本到图像；开放性上，可能是 API、开放权重或仅论文；架构上，可能由视觉编码器、连接器和语言模型组成；训练上，可能经历图文对比、图文指令微调和偏好训练；用途上，可能服务图表问答、图片描述或视觉代理。一个名词就这样被拆成可查的字段。

再看“基础模型”和“应用模型”的区别。基础模型的描述重点是预训练数据、架构、规模和迁移能力；应用模型的描述重点是输入表单、输出契约、检索来源、权限和业务指标。如果一篇文章把一个带检索和工具的应用系统称作“大模型”，你可以在笔记中同时保留两个层级：底座是什么，系统增加了什么。

地图还能帮助你发现缺口。若你能写出模态和用途，却说不清许可证，下一步查开放性；若你能说出参数量，却不知道激活参数和上下文，下一步查规模；若你能描述 API，却不知道输出是否有来源，下一步查评估和系统。学习不再是从头再读，而是沿着缺失坐标补一格。

对于新闻和课程资料，也可以做“日期标记”。把模型名称、来源页面、访问日期、版本和你当时的结论放在一起。几个月后重读时，你可以比较当时和现在的说法，识别哪些内容是稳定概念，哪些内容只是暂时的产品事实。这种时间意识对快速变化的模型生态尤其重要。

最后，把分类写成可沟通的句子，而不是只写表格。表格适合筛选，句子适合向同学解释；句子又必须能回到表格字段。比如“它是开放权重的图文到文本指令模型，适合带人工复核的图表问答，许可和小字识别仍需确认”。这句话既短，又留下了证据入口和风险边界。

本节的三个收束动作

第一，给任何模型写一行“它是什么”，同时列出事实和未知；第二，给任何系统写一行“它怎样工作”，把模型、检索、工具和人工分开；第三，给任何判断写一行“我凭什么相信”，链接到文档、实验或明确的待核对事项。三行可以很短，但必须能够被别人追问。

如果三行写不出来，说明你还停留在名称层。不要急着增加名词，先用一个模型完成一次完整描述。能把一个对象讲清楚，再扩展到第二个对象，比较才不会变成标签堆积。

学完本节后，最小的可迁移技能是“拆词—列轴—找证据—写边界”。这套动作不仅适用于大模型，也适用于任何快速变化的软件和研究主题。下一节的模态分类会提供第一个具体练习。

把“全景地图”用在真实阅读中

当你第一次打开一个模型仓库、论文摘要或产品说明时，可以按固定顺序做四次停顿。第一次只看输入和输出：它接受的是文字、图片、音频，还是已经整理好的向量？输出是下一个 Token、类别标签、坐标框、向量，还是一段可以执行的动作？如果 I/O 没写清楚，后面的“更强”“更快”都没有可比性。

第二次看能力的来源。模型是在预训练中获得一般规律，还是通过监督微调学会固定格式？回答中的事实来自权重，还是来自检索结果、工具调用和外部数据库？把这几件事分开，才能知道改提示词、换模型、补资料还是加工具，哪一种手段真正对症。

第三次看证据的边界。模型卡、评测报告和营销页面解决的问题不同：模型卡适合确认数据、许可和限制，评测报告适合比较定义明确的指标，营销页面只能作为发现线索。阅读时把“官方声明”“可复现实验”“自己的测试”分别记在三列中，遇到冲突先不急着选边。

第四次看系统责任。一个模型即使能生成答案，也不代表系统可以直接把答案写进数据库、发送给客户或触发付款。凡是会改变外部世界的动作，都应该有格式校验、权限检查、人工确认或回滚机制。全景地图的价值，正是让你在学习新名词之前先看见这些边界。

同一张图片，可能对应四种不同任务

想象一张课程成绩表。若目标是判断它是不是成绩表，这是图像分类；若目标是找出每个学生所在的行列，这是版面分析或表格结构识别；若目标是读出姓名和分数，这是 OCR 与结构化抽取；若目标是回答“谁的分数最高”，还需要把识别结果转换成可计算的数据，再进行排序。它们都可以被产品页面写成“图片理解”，但输入预处理、输出结构和错误成本完全不同。

同理，一段会议录音可以用于转写、说话人分离、情绪分析、摘要和行动项提取。先转写再摘要的系统比较容易调试，但可能丢失语气和重叠说话；端到端音频模型保留更多声学信息，却可能更难解释和定位错误。选择哪条链路，应由任务需要保留的信号决定，而不是由“端到端”听起来更先进决定。

模态之间的转换还会产生不可逆损失。把视频抽成几张关键帧，会丢失连续动作；把图片 OCR 成文字，会丢失空间关系；把语音转成文字，会丢失音色、停顿和环境声；把科学网格压缩成平均值，会丢失局部极值。设计系统时先列“不可丢失的信息”，再选择编码器和模型，是比先选品牌更稳的做法。

输入大小也应按原始对象和中间表示分别记录。一个 2 MB 的图片不一定只占很少上下文，因为模型可能把它切成很多视觉 Token；一段 30 秒音频如果使用高时间分辨率，序列会明显变长；一篇短 PDF 可能包含大量表格、脚注和页面布局。只有把原始长度、压缩方式和表示长度放在同一张表里，才能估算成本。

多模态评估要给出可观察的答案。不要只问“模型看懂了吗”，而是拆成“对象是否存在、数量是否正确、属性是否匹配、关系是否成立、顺序是否保留、引用区域是否正确”。对音频，还要加说话人、时间戳、语言和噪声；对视频，加帧间顺序、动作开始结束和镜头切换；对科学数据，加单位、坐标和不确定度。细任务能让错误变得可复现。

模态说明的最小完整格式

可以用四行记录任何一个模型：第一行写原始输入，例如“中文文本、单张 JPEG 图片、16 kHz 单声道音频或长度不超过某值的视频”；第二行写中间表示，例如“文本 Token、视觉 Patch、声学帧或时空块”；第三行写输出，例如“文本、类别、坐标、向量、音频或动作参数”；第四行写限制，例如“只支持单图、不能保证小字识别、超过时长会抽样、输出需要后处理”。这种格式比“支持文本和图片”多了边界，但仍然足够短。

对多模态输入，顺序也可能是数据的一部分。图像放在问题前还是后，音频和字幕是否对齐，视频帧是否按时间排序，文本和表格是否保留页码，都会影响结果。接口示例如果没有说明顺序，应该在自己的测试中固定并记录。更换 SDK 或服务时，不要假设它们对同一对象有完全相同的序列化方式。

评估输入时要做“等价对照”。例如比较图表问答的两条路线：路线 A 直接把图片交给视觉语言模型，路线 B 先 OCR 再交给文本模型。两条路线应使用同一批原图、同一问题和同一输出评分；否则你无法判断差异来自模态能力、OCR 质量还是提示模板。对音频，也可以比较原始音频、转写文本和带时间戳文本，观察哪些错误在转换时产生。

还有一个容易忽略的字段是“缺失输入”。真实数据会有空图片、损坏音频、缺页 PDF、乱码文本和传感器断点。系统要明确是拒绝、跳过、请求补充，还是使用降级模型。把异常输入纳入模态分类，能提前发现“接口支持”与“业务可用”之间的差距。

模态学习也要注意人机协作。模型可能负责初步转写或描述，人工负责核对关键数字和空间关系；模型可能负责给候选区域，规则或专用算法负责测量；模型可能给出科学假设，实验和专家负责验证。把每个模态的可靠输出范围写清楚，系统才知道什么时候应该停下来等待人。

模态边界的案例推演

案例一是“从一张发票提取金额”。如果图片清晰、版式固定，可以使用 OCR 加规则；如果版式变化大，需要版面分析和表格结构理解；如果发票包含手写、印章和遮挡，可能需要视觉语言模型加人工复核。三种方案都能被称作“发票识别”，但数据、指标和责任不同。先描述任务边界，再决定是否需要更复杂的多模态模型。

案例二是“从讲座视频生成复习提纲”。系统要保留音频、字幕、幻灯片和时间顺序；只取几张关键帧可能漏掉板书，单独转写又可能丢失画面中的公式。一个合理的 I/O 规格是“视频→带时间戳的转写、幻灯片片段、章节摘要”，而不是笼统写“视频理解”。

案例三是“根据实验曲线解释异常”。图片中的曲线、坐标轴、单位和实验条件缺一不可。模型能描述曲线形状，不代表能从图像直接推出因果结论；需要保留原始数据、单位和实验记录，并让模型的解释带上不确定性。模态分类在这里帮助你发现“视觉输入不够，科学上下文也必须输入”。

做跨模态对照时，尽量保留同一问题和同一评分。若把图片转成文字后效果变好，可能是 OCR 恰好适合这个任务；若效果变差，可能是空间关系丢失。把中间表示保存下来，才能解释系统在哪一步改变了信息。

不同模态也会有不同的空值语义。空文本可能表示没有内容，空图片可能表示文件缺失，静音音频可能表示环境安静，缺失传感器值可能表示设备故障。不能把所有空值都填成同一个字符串再交给模型，否则系统会把“没有信息”和“信息为零”混淆。

最后，给模态规格卡加一列“可审计性”：输出能否回到原图区域、音频时间、视频帧或科学记录？能回溯的系统更容易发现错误，也更适合高风险任务。若模型只能给一段无法定位来源的自然语言，至少应在系统层保留原始输入和中间结果。

本节的模态判断口诀

先看输入，不看宣传；再看输出，不看想象；再看中间表示，不只看文件；最后看边界，不只看成功。输入决定模型有没有机会观察到关键信息，输出决定系统怎样评分，中间表示决定信息在哪里被压缩，边界决定结果能否进入真实流程。

如果任务只要求文本标签，就不要因为产品支持图片而增加复杂性；如果任务必须保留空间、时间或声音线索，就不要在第一步把它们无损地假设成文字。模态越多，潜在能力越丰富，接口、评估和故障组合也越多。最小可行的模态链路，通常比一次接入所有模态更容易学习和维护。

下一节学习开放程度时，继续沿用同一规格卡：对每种模态分别记录是否可调用、是否有权重、是否有预处理代码、是否有评估和许可证。一个文本模型开放，不代表它配套的视觉编码器也开放；一个多模态 API 可用，不代表图片和音频拥有相同的数据政策。

从模态到数据管线：不要跳过中间层

“模型支持图片”只是入口描述，真正决定效果的是图片进入模型前经历了什么。原图可能被缩放、裁剪、压缩或切成 Patch；文字可能被 OCR 成带坐标的片段；音频可能被重采样、分帧并转换成频谱；视频还要决定抽取多少帧、是否保留时间顺序。任何一步都会改变信息密度，甚至改变任务本身。

因此，描述一个模态系统时至少要记录四层：原始数据、预处理表示、模型接口、最终输出。比如发票审核的原始数据是照片，预处理表示是图像和 OCR 文本，接口可能是“图片加问题”，最终输出则应是带字段名、数值、置信度和页码的结构化结果。只写“视觉问答”会掩盖大量工程工作。

跨模态对齐也有不同粒度。全局对齐只要求一句话和整张图大致对应；局部对齐要求词语能定位到区域；时序对齐要求事件发生的时间点一致；因果对齐则要说明某个视觉变化是否真的导致了文字结论。评测指标和错误分析都应跟着对齐粒度变化，不能用一个总分代表全部能力。

学习时可以用同一份资料做四次实验：只给文本，观察语言理解；只给图像，观察视觉识别；给图像和问题，观察跨模态推理；再加入检索文本或工具，观察外部证据是否被正确引用。这样的对照实验比背诵“多模态”三个字更能建立直觉。

模态规格卡的最后三列

为了让模态说明可以真正落地，再补上三列：限制、证据和降级。限制写清文件大小、分辨率、采样率、时长、Token 或帧数上限；证据写清哪些能力有官方示例、哪些来自自己的测试；降级写清缺少图片、音频损坏、OCR 失败或模型不可用时系统怎样处理。这样一张卡既能指导选型，也能直接转成测试清单。

例如“课程截图问答”可以规定图片最长边、是否需要保留公式和表格、答案必须引用截图位置；若图片模糊，系统先请求重新上传而不是让模型猜。若一段录音只有背景噪声，系统应标记为低质量音频；若视频缺少关键帧，系统应说明时间段无法判断。把异常输入写进规格，往往比再添加一个成功示例更能提升可靠性。

模态系统还要记录数据变换是否可逆。压缩后的图片能否回到原图，OCR 文本能否定位坐标，音频转写能否跳回时间戳，视频摘要能否找到对应帧？可逆或可定位的中间结果，能够支持人工复核和错误分析；完全丢失来源的中间表示，会让模型输出变成无法追问的黑箱。

把模态选择写成可测试的最小规格

一个可执行的模态规格至少包含：输入格式、预处理、表示、输出字段、限制、证据位置和失败处理。比如“图像问答”还要注明图片是否需要 OCR、表格是否保留行列、答案是否必须返回框选区域；“音频摘要”要注明语言、采样率、最长时长和时间戳要求。规格写得越具体，越容易判断该用单模态模型、串联模型还是多模态模型。

测试时从最小输入开始，再逐步加入会改变判断的因素：低分辨率、遮挡、噪声、多个对象、文字和图像冲突、跨页关系以及缺失模态。每增加一种因素，都记录模型是识别失败、定位失败、推理失败还是格式失败。这样得到的错误地图，能直接指导数据增强、预处理、检索或人工复核。

多模态系统的答案还应保留“看见了什么”的证据。例如视觉问答返回相关区域，音频问答返回时间段，视频摘要返回帧区间，科学图表解释返回曲线和单位。没有证据位置时，即使答案语言流畅，也难以判断模型是否真的利用了正确模态。

开放性审计的三个边界

第一是技术边界：你能否获得运行所需的权重、分词器、配置、代码和依赖？只下载一个大文件，可能仍无法复现官方输入格式。第二是权利边界：许可证是否允许你的目标用途、修改、分发和商用？许可可能对主体、规模、地区、产品形态或署名有额外要求。第三是责任边界：模型出现偏差、隐私泄露或安全问题时，谁负责更新、监控和响应？开放材料越多，使用者通常要承担更多本地责任。

审计时建议保存四份快照：下载页或 API 文档的 URL，许可证和使用政策的原文，模型卡的版本说明，以及你自己的核对日期。页面会更新，仓库会重写 README，服务会切换默认模型；没有快照就无法解释为什么上个月可以使用、这个月却出现限制。

对于团队协作，给每个字段指定负责人。工程人员确认权重和依赖，安全人员确认执行脚本和网络权限，法务人员审核许可证，数据人员确认输入和训练数据的隐私边界，评估人员复现实验。学生项目可以由一个人承担多种角色，但仍要在记录中分开写，避免“我觉得应该可以”替代核查。

不要把“可免费调用”与“开放”混为一谈。免费额度可能只是商业服务的试用条件，服务方仍保留权重、数据和运行控制；相反，开放权重模型可能需要你购买硬件、维护环境和支付电力。比较时把一次调用价格、长期基础设施和人的时间放在同一张成本表里。

最后，开放性也影响学习路径。仅 API 的模型适合先练习提示、结构化输出和应用编排；开放权重模型适合观察分词、量化、推理和微调；代码与数据更开放的项目适合研究训练流程。没有必要为了“真正学会”马上下载最大的权重，先选择与你当前问题匹配的开放层级。

把开放性写成一份“材料清单”

拿到一个模型仓库后，可以先按顺序列目录：模型卡或 README、许可证和 NOTICE、配置文件、分词器或预处理、权重文件、推理代码、训练代码、评估脚本、数据说明和安全政策。对每一项写“存在、缺失、需要申请、只给链接或未知”。这样你很快能看出一个项目是偏研究复现、偏本地使用、偏 API 服务，还是只是一个展示页面。

如果某材料缺失，不要立刻给项目负面评价。数据因版权和隐私不能公开很常见，权重因安全或商业原因不公开也很常见；重要的是把缺失记录下来，并判断它对你的目标是否构成阻塞。做个人学习实验时，缺少训练数据可能只影响复现；做商业分发时，许可证和再分发权可能是硬门槛。

版本管理也要具体。记录仓库分支或标签、文件哈希（如果需要）、模型卡最后更新时间、许可证版本和你下载的文件列表。API 还要记录请求使用的模型 ID、响应中的版本字段和服务区域。以后出现行为差异时，这些信息能帮助你判断是权重改变、服务升级、提示模板改变还是数据变化。

对于输入数据，开放模型并不自动授予“可以上传”的权利。公开模型服务可能保存日志，本地推理可能把输入写入调试文件，检索系统可能把文档复制到向量库。你要分别审查传输、存储、日志、备份和删除。把数据治理写进开放性审计，才能避免“模型在本地，所以完全安全”的错误结论。

开放性还影响团队的退出能力。API 服务若涨价、改版或停服，你是否有替代接口和迁移计划？本地权重若停止维护，你是否能修复依赖和漏洞？代码和评估是否足够让新成员接手？在比较候选时加一列“退出成本”，它往往比短期价格更能解释长期选择。

个人学习、团队原型和生产上线的不同门槛

个人学习可以使用公开、脱敏和自写数据，目标是理解调用、权重和许可证字段；团队原型要增加数据审批、成本上限、日志脱敏和候选替换；生产上线还要有安全评审、版本锁定、监控、回滚、事件响应和责任人。同一个模型在三种场景中的“可用”定义不同，不能用个人实验的成功直接推断组织可以上线。

如果你从 API 开始，建议把调用封装在自己的函数中，并保存模型 ID、请求时间、输入摘要、输出、错误码和计费信息。不要把密钥写进代码或公开仓库；使用环境变量和最小权限。若切换到本地权重，再替换实现而不改变业务层接口。这样可以同时学习 API 便利性和本地控制力。

如果你从开放权重开始，先阅读仓库的启动脚本和配置，确认下载、缓存、遥测和远程代码行为。把模型放在独立环境，固定依赖版本，避免直接用管理员权限执行未知脚本。测试时用公开样例和合成数据，先观察输出，再考虑接入真实资料。开放性是学习机会，也是一项需要谨慎操作的工程能力。

许可证审查要留下“适用事实”和“需要解释”两列。事实包括许可证名称、版本、允许和禁止条款、署名和再分发要求；需要解释的部分包括商业产品、衍生权重、规模门槛和地域限制。不能确定时停在“待审核”，不要用网络评论替代原文。学习资料可以教你提问，但不能替代专业法律意见。

当多个模型都满足硬门槛时，再比较退出成本：迁移到另一模型需要改多少提示、分词、输入格式、评估脚本和后处理？是否存在开放格式、替代权重和可回放测试？越早保留这些抽象，后面越不容易被某个 SDK 的专有字段锁住。

开放性审计：从“我能用”走到“我能负责”

学习者常把开放性审计做成下载测试：文件能下载、示例能运行，就认为模型开放。更完整的审计要分三次完成。第一次是可获得性审计，记录你能看到和拿到的材料；第二次是权利审计，核对这些材料允许怎样使用、修改和分发；第三次是运行审计，确认在自己的环境中能否固定版本、保护数据、监控输出并在出问题时退出。

可获得性审计可以从仓库根目录开始。先列出 README、模型卡、LICENSE、NOTICE、配置、分词器、权重、推理脚本、评估脚本和示例数据，再给每个文件标记“有、无、链接、需申请、未知”。不要用一个“开源”标签替代清单，因为缺少分词器或输入模板时，权重可能无法按作者的方式运行；缺少评估脚本时，报告中的分数也难以复核。

权利审计需要把对象分开：源代码是一种作品，权重是一种发布物，训练数据是另一组来源，生成输出还可能受输入资料和使用场景的约束。许可证可能对其中一个对象开放、对另一个对象限制；模型服务条款还可能规定日志、再训练、批量调用或商用方式。学习笔记中至少保存对象、许可证、版本、来源和适用范围，避免把一份许可证误套到整条链路。

运行审计关注的是可控性。固定依赖版本和模型哈希，记录分词器与推理参数，给服务设置网络和文件权限，准备一组脱敏测试数据，观察日志是否会写入原文。若模型从远程地址自动下载额外文件，先阅读下载逻辑并改成明确的离线缓存；若仓库要求执行脚本，先在隔离环境中检查它访问了哪些目录和网络资源。

对个人学习而言，API、开放权重和本地小模型都可以成为入口。API 适合快速观察任务边界；开放权重适合学习分词、量化和推理流程；小模型适合在没有高端硬件时练习数据清洗和评估。不要把“最开放”误当成“最适合开始”。选择一个能在你的设备、时间和许可范围内稳定运行的模型，才有机会形成可重复的学习记录。

对团队原型而言，应把开放性写进替换成本。若服务方更新模型而你的评估集、提示模板和输出校验都没有保存，迁移时就无法判断是模型变化还是业务代码变化；若本地权重只能由一个人运行，离职或环境损坏就会导致项目不可维护。把接口、测试样例和版本清单独立保存，才能在 API 与本地模型之间比较。

对生产上线而言，开放性还要和安全责任绑定。模型权重是否可审计，不代表输出自动可信；许可证是否允许商用，不代表输入数据可以上传；代码是否公开，不代表依赖没有漏洞。上线前要让技术、法务、安全和业务共同确认：谁批准版本，谁处理漏洞，谁查看日志，谁决定暂停服务，谁对高风险输出负责。

最后练习“面向未来写声明”。不要只写“本模型开放，可用于研究”，而要写“截至某日期，API 和权重可用，推理代码可见，训练数据未公开，评估仅覆盖列出的任务，许可证允许哪些用途；本项目未验证哪些场景”。限定性语言不会削弱介绍，反而让读者知道哪些内容可以依赖、哪些内容需要继续核对。

开放性声明应该写出时间、对象和未知项

模型资料会更新，仓库链接也可能指向不同提交，因此开放性说明不能脱离时间。建议把“截至某日期、某版本、某来源”写在每一项材料旁边，并保存网页或文件的校验信息。这样半年后重新查看时，能区分项目真的改变了，还是你当初读到的是另一版文档。

声明还要把“对象”写清楚。模型权重、分词器、视觉编码器、推理框架、示例数据和生成输出可能分别受不同许可约束。一个多模态系统即使语言模型权重开放，配套的图片编码器或数据集也可能有单独条款。把对象混成一行，容易在部署和再分发时漏掉限制。

对于未知项，使用“未披露”“未找到”“尚未验证”三个词比统一写“没有”更准确。“未披露”表示发布方没有公开，“未找到”表示你在已查范围内没有看到，“尚未验证”表示材料存在但还没有完成测试。精确描述未知，能避免团队把暂时的空白误当成否定结论。

学习者可以用最小审计顺序：先读模型卡的用途与限制，再读许可证和使用政策，接着确认权重、代码和数据说明，最后在隔离环境中跑一个无敏感信息的测试。若任何一步出现冲突，就暂停传播结论，保留原文和问题位置。这个顺序比先在社交媒体上转发“开源／闭源”更可靠。

开放性不是越高越好，而是与任务责任匹配。个人练习重视能否运行和能否观察；团队原型重视版本、替换和数据边界；生产系统还要重视安全更新、审计、合规和退出。把使用场景写在声明里，读者才知道同一模型在不同场景下为什么会有不同结论。

开放程度与学习路线如何对应

如果目标是理解 API 调用，可以先选择文档完整、输入输出稳定的托管服务，练习请求、错误处理、速率限制和成本记录；如果目标是理解模型内部，可以选择可下载的小权重，在本地观察分词、层结构、量化和推理参数；如果目标是学习训练，则还要寻找数据说明、训练脚本和评估脚本，不能只凭一个权重文件推断训练过程。

同一个模型在不同学习目标下的“够用”标准不同。做提示词实验时，许可证清晰和接口稳定比权重是否下载更重要；做部署实验时，权重、分词器和推理框架要能一起固定；做论文复现时，数据来源、训练目标、代码版本和评估协议缺一不可。先写学习目标，再决定需要哪一层开放材料。

建立记录时，还要标记材料的可信等级：官方发布文件、项目维护者说明、第三方测评、个人博客和论坛讨论不能等量齐观。第三方内容适合发现问题或找到线索，关键许可和安全结论应回到原文核对。把来源等级写进表格，能减少“很多文章都这么说”造成的误判。

开放性审计的最终结果不是一句“推荐”或“不推荐”，而是一份有条件的结论。例如“适合公开课程资料的离线摘要实验，暂不用于含个人信息的生产场景；原因是权重许可已确认，但训练数据说明、长上下文评估和安全更新流程仍未知”。有条件的结论更容易随着新证据更新。

从参数账本走向真实基准

第一次估算时，把模型视为一张静态权重表；第二次测量时，要把真实运行条件写进实验：输入 Token 数、输出 Token 数、批大小、并发、精度、量化、硬件、线程数、缓存是否复用和是否流式。每次只改变一个变量，例如固定模型和输入，比较不同量化；或固定精度，比较短上下文和长上下文。否则结果变化无法归因。

延迟最好拆成首 Token 延迟、后续 Token 间隔和完整响应时间。首 Token 受提示长度、权重加载和预填充影响，后续速度受解码和缓存影响，完整时间还包含输出长度。并发下要记录平均值和尾延迟；一个平均 1 秒的系统，可能在高峰时有少数请求等待几十秒。对用户体验来说，尾延迟和超时处理同样重要。

吞吐也要带单位。每秒 Token、每秒请求、每批图片和每小时成本回答不同问题。图像和音频的“Token”不一定与文字 Token 等价，服务框架可能把视觉编码和文本解码分开统计。记录原始输入大小和中间表示数量，才能进行跨模态比较。

架构对资源的影响还包括内存访问。模型参数即使能放进显存，频繁从 CPU 或磁盘搬运也会降低速度；MoE 路由可能让专家权重访问不均；长上下文会增加缓存而不是只增加一次计算。遇到“显存够但很慢”，不要只继续压缩权重，先查带宽、缓存、批处理和算子支持。

规模估算还可以帮助你决定学习顺序。先用小模型或玩具模型验证数据、提示和评估流程，再换成更大模型；先在短上下文测通，再增加长度；先把单请求跑稳，再测并发。这样失败时知道是逻辑错误还是资源问题，也不会把昂贵的 GPU 时间浪费在一个拼写错误上。

一个“7B 模型能不能跑”的完整推理过程

先问权重精度。若是半精度，理论权重约为参数量乘 2 字节；若是 4 位量化，权重下界会明显下降，但量化元数据和运行时计算仍然存在。再问输入长度和输出长度，因为预填充和 KV cache 会随序列增长。然后问批量和并发：单用户能跑不代表四个用户同时请求也能跑。最后问框架和硬件是否支持目标量化算子，否则理论显存够，实际速度也可能无法接受。

如果只是学习 Token 生成，短输入、单批、较低精度可以帮助你快速验证流程；如果要做文档问答，要用最坏文档长度、检索片段数量和生成长度测试；如果要做多模态输入，要把视觉或音频表示带来的额外序列长度算进去；如果要服务多人，还要测尾延迟、排队和缓存复用。不同任务的“能跑”定义不同。

参数量还会影响训练和微调方式。全参数训练需要保存权重、梯度和优化器状态，资源远高于推理；参数高效微调只增加适配器，但仍要加载底座；蒸馏和量化可以降低部署成本，却可能改变输出质量。选择训练路线时，先看可用硬件和目标任务，再决定要不要使用大模型。

架构对比也要避免只看名称。两个解码器式模型可能有不同的位置表示、注意力窗口、归一化顺序和词表；两个 MoE 模型可能有不同专家数、路由策略和通信方式；同样的“上下文长度”可能对应不同的有效利用率。阅读技术报告时，把结构图和配置字段对应起来，写出每个数字的含义。

最小的实测报告可以只有一页：环境、模型版本、精度、输入输出长度、批量、首 Token 延迟、Token/s、峰值显存、错误和限制。它不需要取代完整基准，却能告诉你当前硬件和任务是否值得继续投入。把报告与显存估算并排保存，估算和事实之间的差距本身就是学习结果。

把参数数字翻译成一份可运行的账本

看到“7B”“70B”或“671B”时，先不要把它们直接翻译成“更聪明”。参数数量只说明可学习数字的规模，实际运行还要同时考虑权重精度、激活值、临时缓冲、KV cache、并发和框架开销。一个粗略的权重下界是：参数量乘以每个参数占用的字节数。7B 参数用 16 位浮点保存，只有权重就约需要 14GB；用 8 位保存约 7GB，用 4 位保存约 3.5GB。这个估算不等于完整显存需求，却能帮助你先排除明显不可能的配置。

训练和推理的账本不同。训练还需要梯度、优化器状态、激活保存和通信缓冲，显存往往远高于权重本身；推理可以不保存梯度，却会随着输入长度和并发量增加 KV cache。微调也有全参数、参数高效和量化等路径，每种路径需要的显存、磁盘和时间不同。记录“这次实验是推理、全量训练还是 LoRA”比只记录模型大小更有用。

稠密模型每个 Token 通常都会经过大部分参数；混合专家模型（MoE）可以拥有很大的总参数，但每次只激活其中若干专家。比较两者时应同时写总参数和激活参数，并注明专家数量、每 Token 选择几个专家、路由负载是否均衡。总参数更像容量上限，激活参数更接近单步计算量，但通信和路由也会带来额外成本。

上下文长度是另一个容易误读的数字。支持 128K Token 不代表一次输入 128K 后仍然保持同样准确，也不代表成本和延迟可以忽略。长上下文会增加预填充时间和缓存占用，信息埋在中间时还可能出现“检索到但没有正确使用”的现象。学习时要分别测试短上下文、边界长度、重复信息、关键信息位于开头／中间／结尾的情况。

KV cache 的直觉是“已经处理过的历史，不必每次重新计算”。在自回归生成中，它能显著减少重复计算，却会占用显存，并且通常随层数、头数、每头维度和序列长度增长。并发请求越多，缓存越多；开启分页缓存、压缩缓存或限制最大输出长度，都会影响吞吐与延迟。模型规格页若只给上下文长度而不说明缓存策略，运行账本仍不完整。

架构名称也要拆成数据流。编码器更擅长把整段输入变成双向表示，解码器适合按顺序生成，编码器—解码器适合输入到输出的转换；视觉 Transformer 把图像切成 Patch，多模态模型还要加入视觉编码器、投影层或跨模态注意力。不要把“用了 Transformer”当成足够的架构说明，至少画出信息从输入到输出经过的模块。

规模和能力通常相关，但不是简单的单调关系。数据质量、训练目标、去重、课程安排、优化稳定性、后训练和评估覆盖都会改变结果。一个参数更小、训练更干净、指令更贴合的模型，可能在特定任务上胜过更大的通用模型；一个排行榜分数更高的模型，也可能因为格式、延迟或许可不合适而无法用于你的系统。

比较模型时建议做控制变量实验。固定问题集、解码参数、系统提示、检索文档和后处理规则，一次只更换模型或一个部署变量。记录首 Token 延迟、完整响应延迟、每秒 Token、峰值显存、错误率、输出长度和成本。不要把换模型、换提示、换量化、换硬件同时发生的结果写成“模型升级带来的提升”。

def weight_memory_gb(parameters_billion, bits):
    """只估算权重下界，不包含缓存和运行时开销。"""
    bytes_per_parameter = bits / 8
    return parameters_billion * 1_000_000_000 * bytes_per_parameter / 1_000_000_000

for bits in (16, 8, 4):
    size = weight_memory_gb(7, bits)
    print(f"7B @ {bits}-bit: {size:.1f} GB")

量化也不是“免费压缩”。低比特权重可能改变困惑度、事实准确率、代码格式或长上下文表现；不同层、不同权重和不同校准数据对量化敏感度不同。应在自己的任务集上比较原精度与量化版本，记录速度、显存、质量和异常输出，而不是只看文件大小减少了多少。

对于初学者，最有价值的规模练习是建立一张小账本：模型参数、激活参数、精度、上下文、并发、显存、吞吐、延迟、评测集和许可各占一行。每次换模型或换硬件只改对应字段，最后写一句“适合／不适合我的任务的原因”。这样你会逐渐从背诵参数数字，转向解释数字怎样影响真实体验。

当账本中的字段越完整，你越容易发现“更大”到底改变了什么：它可能提高复杂推理，也可能只是增加成本；它可能扩大上下文，也可能让缓存把并发压垮；它可能适合离线部署，也可能许可证和硬件让方案不可行。把这些差异写出来，才算真正理解规模。

规模估算的三个常见反例

反例一是“参数越大，延迟一定越高”。在不同硬件、量化和批处理策略下，小模型可能因为实现不佳、内存搬运或频繁启动而更慢；大模型也可能通过更高吞吐摊薄单请求成本。比较时要在同一设备、同一输入长度、同一并发和同一框架上测首 Token 与完整响应，而不是只比较参数数字。

反例二是“上下文越长，知识越多”。上下文窗口只是接口能容纳的 Token 范围，不是模型能可靠使用的保证。长输入可能包含重复、冲突和无关内容，模型还可能忽略位于中间的关键证据。把长文拆成可检索片段、保留来源和版本，常常比把所有文字一次塞入窗口更稳定。

反例三是“量化只会损失一点点质量”。量化误差在不同层和不同任务上并不均匀，代码缩进、数字、专有名词、少数语言和工具参数都可能更敏感。量化前后至少比较格式通过率、数字准确率、引用正确率、拒答边界和长输入表现；如果只是看一个平均分，可能错过真正影响业务的退化。

算力预算还要按阶段拆分。下载和存储是一次性成本，预填充和生成是每次请求成本，KV cache 是随并发增长的资源，微调和评估则是周期性成本。把这些成本分开，才能判断应该换更小模型、降低精度、缩短上下文、增加缓存，还是把任务改成 Embedding 加检索。预算不仅是财务问题，也是架构选择。

如果你没有 GPU，也可以完成规模学习。先用公开的小模型或 API 记录输入输出，再用纯 Python 计算权重下界、估算 Token 数和比较不同精度；随后观察同一任务在短上下文与长上下文、不同批量和不同输出长度下的延迟变化。理解变量之间的关系，比盲目购买硬件更重要。

最后把规模字段写成可审计的句子，而不是孤立数字。例如：“该检查点总参数约 7B，使用 4-bit 权重时文件约 3.5GB；本地实测 4K 输入、单并发首 Token 为 X ms，峰值显存为 Y GB；未测多并发和长上下文。”这种写法明确哪些是规格、哪些是实测、哪些仍未知。

用同一张表比较不同规模，而不是比较宣传数字

比较两个模型时，先把单位统一。参数量通常以十亿为单位，显存可能用 GB 或 GiB，吞吐可能按每秒 Token，延迟可能区分首 Token 和完整响应；如果单位混在一起，结论很容易偏差。表格中同时保留“规格值”和“实测值”，并注明硬件、批大小、输入长度和输出长度。

小模型的优势不只在文件小。它可能更容易放到边缘设备，冷启动更快，成本更稳定，也更适合把任务拆成多个专用组件；大模型可能在复杂推理、长文整合或多语言覆盖上更有余量。选择时把任务分成“必须准确”“可以近似”“必须离线”“可以联网”四类，再看哪种规模组合满足硬约束。

模型结构还会改变规模的含义。增加层数、隐藏维度、注意力头或词表都会影响容量和计算；共享参数、分组查询注意力、滑动窗口和稀疏路由会改变内存与带宽。两个都写着 7B 的模型，可能因为上下文、词表、架构和实现不同，得到完全不同的部署体验。

规模比较要保留任务分布。若输入以短中文问答为主，就不能用长英文文档基准代替；若输出必须是代码或 JSON，就不能只看开放式聊天偏好；若系统需要图片和表格，就不能拿纯文本分数作唯一依据。模型越大，越需要问“在哪些数据和指标上变大了价值”。

一次可重复的基准至少包含三组样例：代表性样例、边界样例和压力样例。代表性样例回答平均质量，边界样例揭示空值、超长、冲突和少数格式，压力样例观察并发、资源和超时。分别报告三组结果，才能知道模型是平均不错、边界危险，还是资源根本不可接受。

如果结果冲突，不要急着用一个总分压平。可以保留一个简单决策矩阵：硬约束先筛掉不合格模型，再对质量、成本、延迟、许可和维护做加权比较。权重由任务负责人和实际使用者共同确认；如果隐私是不可妥协项，就不应让更高的质量分数抵消它。

训练目标决定“模型看见什么、学会什么”

训练数据的排列方式会决定模型观察到的关系。因果语言模型把前缀和后续联系起来，掩码目标让模型利用左右上下文，序列到序列目标要求它把一种序列转换成另一种序列，对比目标把匹配对象拉近，扩散目标则让模型学习从噪声状态恢复结构。同一个“文本”可以因为目标不同，形成完全不同的表示和输出习惯。

标签质量决定监督微调的上限。若示例把“无法确认”都写成肯定答案，模型会学到过度自信；若格式有时用 JSON、有时用自然语言，模型很难稳定遵守；若拒答条件没有示例，安全边界只能靠猜。训练集的每一条样本都在暗示一个规则，越是重复出现的规则，越容易被模型当成普遍行为。

数据配比也会造成能力取舍。增加代码数据可能提高程序模式，但可能改变自然语言风格；增加某种语言或领域语料可能改善术语，却让其他语言的容量相对变少；增加合成数据可以扩展覆盖，却可能把生成错误循环放大。看到训练数据比例时，不要只问“总量多不多”，还要问“任务需要的信号是否被覆盖、噪声是否会被重复学习”。

训练阶段之间还可能出现遗忘和冲突。领域继续预训练可能让模型更懂专业词，却损伤通用表达；微调可能让格式更稳定，却降低开放式灵活性；强安全对齐可能让危险请求拒答，却误伤正常研究问题。评估要在同一套通用、领域和边界样例上前后对照，才能知道新增能力的代价。

模型输出的“理由”也不一定等于内部真实过程。思维链、解释文字和引用格式可能是训练出来的行为，不应直接当成证明。需要计算时交给确定性工具，需要事实时给出来源，需要安全判断时保留规则和人工审核。训练目标能塑造行为，却不能替代外部证据。

训练阶段的易错对照

把继续预训练当成事实更新：继续训练领域文本可能让术语更熟悉，但不会自动保证最新事实，也不会自动知道哪些文档可信。要更新知识，可以使用新数据训练，也可以在运行时检索带版本的文档；两者的成本、时效和证据不同。

把监督微调当成能力创造：微调可以改变输出格式、语气和任务行为，却不一定能补上缺失的广泛知识。若样本中包含大量事实，模型可能记住其中一部分，但仍需要验证、引用和版本控制。

把对齐当成正确性证明：回答更礼貌、拒绝更安全，不等于事实更准确。对齐目标往往包含帮助性、无害性和遵循指令等偏好，需要和事实、格式、检索来源分开评估。

把工具结果当成模型能力：模型调用计算器得到准确结果，不代表模型自己会做任意精确计算；模型读取检索文档生成答案，也不代表参数中保存了这份最新资料。系统描述要写清工具和模型的责任边界。

把训练损失当成业务指标：损失下降说明模型更好地拟合了训练目标，但业务可能更关心引用覆盖、字段准确率、召回、延迟和拒答。每一项指标都要与任务合同对应。

可以用“前后对照”检查训练效果：同一批通用样例、领域样例和边界样例，在预训练基座、微调版本、对齐版本和接入检索后分别运行。比较格式、事实、来源、拒答和延迟的变化，记录新增能力和退化能力。这样你看到的不是一个模糊的“升级”，而是一张能力变化表。

训练方案的证据链：从数据到行为逐项验收

分析一次训练或微调，第一步是写数据合同。合同至少说明样本来源、许可、时间范围、语言、字段、去重规则、脱敏方式、质量抽检和删除流程。数据越接近真实业务，越要知道哪些内容可以用于训练、哪些只能用于评估、哪些必须永不离开原系统。没有数据合同，后面的分数很难解释，也很难在用户要求删除时找到对应记录。

第二步是写目标合同。目标不是一句“让模型更强”，而要明确模型在优化什么：下一个 Token 的概率、被遮挡片段的恢复、输入输出的转换、正负样本的距离、噪声恢复、任务标签、偏好排序或工具调用成功率。目标函数决定模型在训练中被奖励的行为；如果业务要求引用来源，却只优化流畅文本，模型自然不会稳定地产生可核查引用。

第三步是写样本合同。每条监督样本都应该有明确的输入边界、目标格式和拒答条件。对于结构化输出，统一字段名、类型、枚举值和空值语义；对于问答，标注“资料不足”的正确行为；对于工具调用，区分可执行参数、缺失参数和需要人工确认的参数。样本之间若互相矛盾，应先处理矛盾，而不是期待模型自己学会裁决。

第四步是做切分和泄漏检查。随机切分可能把同一文档的相邻段落同时放进训练和测试，导致分数虚高；时间敏感任务要按时间切分，用户或项目数据要按主体切分，近重复样本要在切分前去重。测试集应尽量代表上线时会遇到的输入，同时保留一套永不参与训练的“盲测集”。

第五步是做能力与退化的双向评估。新版本可能提高领域术语，却损伤通用表达；可能减少危险输出，却增加误拒答；可能让 JSON 更稳定，却在长文本中遗漏信息。用同一套通用、领域、边界、长上下文和格式测试做前后对照，把“提升”和“退化”同时写进报告。只公布上涨的指标，会让读者误解训练效果。

把训练变更写成可复现的实验

训练阶段之间的边界，最好用一个固定实验集来观察，而不是靠记忆推断。准备同一批通用样例、领域样例、格式样例、长上下文样例和安全边界样例，在基座、指令微调、对齐版本以及接入检索的系统上依次运行。输入、解码参数、文档版本和评分规则保持不变，只有待比较的阶段发生变化。

每次实验都记录四类结果。第一类是任务质量，例如字段准确率、摘要要点覆盖、代码测试通过率或图文匹配召回；第二类是行为质量，例如指令遵循、拒答边界、对冲突提示的处理；第三类是系统质量，例如延迟、吞吐、缓存占用和失败率；第四类是证据质量，例如答案是否引用正确来源、能否定位原文、是否把不确定内容标出来。

训练样本应有“正例”和“反例”。正例告诉模型希望看到什么，反例告诉它哪些相似输入不能这样回答。对于课程问答，正例可以是带章节引用的答案，反例可以是资料中没有结论时输出“无法确认”；对于工具调用，正例是完整参数，反例是缺少金额或权限时暂停。只收集成功样本，模型很难学会何时停下。

数据质量检查也要分层进行。格式检查确认字段可解析，语义检查确认答案与来源一致，安全检查确认没有泄露和越权，分布检查确认不同语言、长度、主题和用户类型没有被某一类样本完全代表。自动规则可以筛掉明显错误，但重要样本仍需要人工抽检，并保留抽检规则和比例。

训练中的“遗忘”需要显式测试。领域继续预训练可能让术语更熟，却削弱普通表达；微调可能让输出格式更稳，却忘记少见但重要的通用任务；安全对齐可能减少危险回答，却误拒答合理研究问题。将退化样例列为回归测试，每次发布都跑一遍，必要时采用混合数据、冻结层、适配器或检索来平衡。

训练完成后，先做离线报告，再做小流量试运行。离线报告解释指标和失败案例，小流量试运行观察真实输入分布、用户修改、拒答、延迟和资源成本。不要把离线高分直接等同于线上成功；线上还会出现输入缺失、格式混乱、重复请求、恶意提示和版本迁移等问题。

当一个训练项目被交接给别人时，最重要的不是一句“效果提升了 8%”，而是别人能否重现比较。交付包应包含运行命令、环境版本、数据切分摘要、固定测试集、原始和新版本输出、指标脚本、已知失败和回滚方式。若某项结果不能重现，就在报告中标记不确定，不要用精确数字掩盖实验波动。

训练目标、数据合同和评估证据连在一起，才能解释模型为什么出现某种行为。预训练形成广泛表示，微调形成任务格式，对齐改变偏好和安全边界，检索与工具把外部信息和动作接入系统；没有哪一个阶段单独负责全部正确性。

训练、微调、检索：遇到问题先定位阶段

回答事实错误时，先问输入里有没有正确资料。如果资料没有出现，问题可能是知识缺失，应考虑检索、更新数据或改变任务流程；如果资料已经出现但回答仍错，才进一步检查上下文组织、提示、微调和生成参数。这样可以避免为了“补知识”盲目训练，或者为了“改格式”不断扩大训练集。

输出格式不稳定时，先检查模板和解析器。系统提示是否和训练模板一致，字段是否有明确类型，停止条件是否正确，解码是否允许额外文本，后处理是否会破坏 Unicode 或转义？只有这些环节都稳定后，才判断是否需要监督微调。很多所谓的“模型不听话”，其实是接口合同不完整。

回答过于自信时，分别测试三种输入：有明确来源、来源不足、来源互相冲突。若三种输入都给出同样肯定的语气，说明数据样本或对齐目标没有教会模型表达不确定性；若接入检索后仍引用不存在的段落，问题可能在召回映射或引用校验，而不是预训练知识。把失败按阶段归类，修复才有方向。

工具调用失败时，记录模型生成的参数、验证器的错误、工具返回值和最终回复。参数缺失属于任务格式问题，参数越权属于权限问题，接口超时属于系统问题，工具返回错误属于外部服务问题。它们可能同时出现，但不能都叫作“幻觉”。一份完整日志能帮助你决定应该改样本、改规则还是改重试。

训练数据和线上反馈也不能直接混在一起。用户反馈可能包含个人信息、偏见、错误答案和重复请求，进入训练前要脱敏、授权、去重、标注和抽检。把线上输出原样回灌，可能放大模型自己产生的错误；更稳妥的做法是把反馈先变成带来源和判定的评估样例。

当新版本表现更好时，仍要检查它是否改变了不希望改变的行为。固定一组回归问题，比较事实、格式、引用、拒答、延迟和成本；对变化最大的样例做人工复核；把可接受变化、需要修复变化和必须回滚变化分别标记。训练的成功不是所有分数都上涨，而是目标行为改善且代价在可接受范围。

学习者可以把每次实验写成四句总结：我改变了哪一个训练或系统阶段；我预期它影响哪个行为；哪个指标和案例证明了变化；还有什么未知或退化。四句总结会迫使你把“感觉更好”转成可核查的因果假设，也为之后学习 Transformer、LLM 和 RAG 留下清晰入口。

小规模训练实验的观察顺序

初学者不需要马上训练大模型，可以用很小的文本或图像数据观察目标如何改变行为。先让模型在训练集上过拟合一小批样本，确认数据、标签、损失和反向传播确实连通；再换成未见过的样本，观察泛化；最后加入噪声、缺失字段和冲突输入，观察模型是否知道何时不确定。

每轮实验只改变一个变量：数据量、去重方式、目标函数、学习率、微调层、提示模板或解码参数。保存原始输入、训练配置、损失曲线、验证结果和失败输出。若一次同时改变五个变量，即使分数上涨，也很难知道是哪一步起作用。

小实验最重要的输出不是最终分数，而是一个可解释的对照。例如“加入拒答反例后，资料不足问题的肯定回答减少，但正常问题的误拒答增加”；“换成带时间戳的检索后，引用定位改善，但长文延迟上升”。这样的句子可以继续转成测试，成为后续章节的工程资产。

当你能用几百条样本完成这套观察，再考虑更大的数据、模型或硬件。先理解目标、证据和退化，再扩大规模，能避免把资源消耗误认为学习效果。

训练结论的谨慎表达

描述训练结果时，尽量使用“在某个版本、某套数据、某个协议下，某项指标发生变化”的句式。例如“在固定中文制度问答集上，指令微调提高了结构化输出通过率”，不要直接写成“微调让模型全面变强”。前一种写法能被复查，后一种写法把局部结果夸大成普遍能力。

如果没有训练脚本、数据或完整评估，就把结论标为“根据发布方说明”或“根据有限测试推测”。对于最新知识、事实准确和安全边界，尤其要保留限制。模型的训练阶段能解释行为来源，却不能代替运行时证据。

学习笔记还可以给每次实验加一个“未改变的变量”清单：底座版本、分词器、输入长度、解码参数、测试集和评分规则。未改变的变量写得越清楚，实验结论越容易迁移到下一次比较。

训练阶段的最后核对

在模型卡上看到“预训练”“指令微调”或“对齐”时，先把它们写成阶段记录，再问每个阶段是否有对应的样本、目标和评估。若没有来源或实验，保留“发布方声明”标签；若只有少量样例，保留“有限验证”标签。阶段名称帮助你提出正确问题，但不会自动证明效果。

一个可靠的训练说明还要交代未覆盖的输入、已知退化和回滚版本。这样读者才能知道新能力的范围，也知道出现问题时应回到哪个阶段检查。能力来源越清楚，后续的系统设计越不容易把责任推给一个抽象的“模型”。

从“模型选型”到“系统责任表”

真正的项目通常不是一个模型解决全部问题，而是一组组件共同完成任务。可以建立责任表：数据接入负责格式和权限，预处理负责清洗和切分，Embedding 负责表示，检索器负责召回，生成模型负责组织答案，工具负责确定性计算，规则负责硬约束，人工负责高风险决策，监控负责发现漂移。每一行都写输入、输出、指标和失败时的接管人。

责任表能防止两种极端。第一种是把所有问题都交给模型，连权限和算术也依赖生成；第二种是为了追求确定性，把所有内容都写成僵硬规则，无法处理自然语言变化。合理系统会把概率模型放在擅长理解和生成的环节，把确定性代码放在需要精确、可审计和可回滚的环节。

行业模型的“行业”也有不同深度。浅层可能只是系统提示和术语表，中层是检索和模板，深层才是领域继续预训练或监督微调。三者都可以改善体验，但成本、数据要求和风险不同。记录模型在哪一层适配，才能避免把“接入一套行业知识库”宣传成“重新训练了行业大模型”。

任务层级还影响数据治理。L0 训练数据可能很广泛，通常由发布方负责；L1 领域数据需要组织授权、版本和脱敏；L2 用户输入和业务记录可能包含个人信息，必须限制保存和访问；系统日志还可能复制模型输入输出。模型选择和数据治理应该一起做，而不是上线后再补隐私说明。

评估也要按层级拆开。L0 可以看通用语言或视觉基准，L1 看领域术语、事实和专家判断，L2 看字段级准确率、人工修改量和业务成功率，系统看端到端延迟、权限、检索覆盖和回滚。某层分数上升，不代表整个系统成功；一条错误的检索结果可能让一个很强的生成模型给出错误答案。

当系统需要动作时，建议采用“建议—验证—执行”三步。模型先生成结构化建议，验证器检查参数、范围和权限，确定性工具执行并返回结果。高风险动作增加人工确认，所有步骤写入审计日志。这样即使模型判断错，也有机会在执行前拦截；不要让自然语言直接变成不可逆操作。

三个需求的分层示范

需求一：给公开文章做摘要。输入是文本，输出是短文本，资料不需要实时更新，风险较低。可以先用通用生成模型建立基线，再用固定提示和长度规则评估；不一定需要行业微调，也不一定需要 Agent。重点是摘要是否覆盖要点、是否凭空增加事实、延迟和成本是否可接受。

需求二：回答带版本的课程制度。输入是问题，输出必须包含原文引用和版本。通用模型只负责理解和组织，检索系统负责找文档，任务层规定引用字段和“找不到就说不确定”，系统层负责权限、版本和日志。若制度变化频繁，优先更新知识库而不是反复微调模型。

需求三：根据库存自动下单。输入是自然语言或表格，输出是结构化订单建议，真正执行由业务 API 完成。模型可以解析意图和补齐候选参数，但规则必须检查库存、金额、权限和重复提交；高风险操作需要人工确认。这里系统层的安全和可回滚，比底座模型多几个百分点的开放式能力更重要。

这三个例子使用的模型可能相同，但系统层级和责任完全不同。一个模型在需求一中可以直接生成文本，在需求二中必须接入检索和引用，在需求三中只能提供经过验证的建议。不要因为“模型能回答”就跳过任务合同和权限设计。

层级也决定迭代路线。先做 L2 的规则和数据质量，再确定 L0 的能力是否不足；如果检索召回错误，换更大的生成模型往往没有帮助；如果输出格式不稳定，先改善样本、模板和验证器；如果延迟过高，再比较更小模型、缓存、批处理和本地部署。按故障层级迭代，成本更可控。

对于行业和科学任务，专家参与不是最后的装饰。专家可以帮助定义标签、边界、重要错误和可接受证据；他们还要参与抽样复核和上线后的漂移监控。模型系统的“专业”来自数据、流程和责任共同构成的闭环，而不是一个行业 Logo。

分层之后还要补上 SLO、权限和接管路径

把需求写成 L0、L1、L2 只是第一步，真正上线还需要一份服务目标（SLO）。例如课程问答可以要求“95% 的请求在 4 秒内返回，答案必须有章节引用，检索不到依据时明确说不确定”；库存建议可以要求“所有金额和库存由确定性接口校验，模型不得直接下单，异常请求在 30 秒内进入人工队列”。SLO 把抽象的智能变成可监控的承诺。

权限应沿着数据、模型和动作三条线分别设计。数据权限决定模型能读哪些文档，模型权限决定谁能调用哪一个版本，动作权限决定输出能否触发查询、写入或付款。一个用户有权阅读课程资料，不代表他有权访问教师备注；一个模型能生成订单 JSON，不代表它有权调用下单 API。把三种权限混在一个登录状态里，越权时很难定位。

接管路径要在正常流程中就存在，而不是故障后临时想办法。系统可以设置三种出口：低风险且格式完整时自动完成；信息不足、置信度低或检索冲突时请求补充；涉及敏感数据、高金额或不可逆动作时转人工。每个出口都应有明确条件、提示语、超时处理和日志字段，避免模型用一句“我不确定”把责任推回用户。

层级评估也要分开报。模型级报告回答“在固定输入上输出质量如何”，检索级报告回答“正确资料是否被召回”，工具级报告回答“参数和动作是否正确”，系统级报告回答“用户任务是否完成、成本和延迟是否可接受”。如果只报告生成模型的 BLEU、ROUGE 或人工偏好分数，就无法解释端到端失败。

上线前要定义降级方案。云端模型不可用时，是否切换到本地小模型、规则模板或只返回原文检索结果？Embedding 服务故障时，是否保留最近一次索引？工具超时或返回冲突时，是否停止动作而展示待处理状态？降级不一定保留全部智能，但应保留安全、可解释和可恢复的最小功能。

系统还会遇到版本漂移。行业规则、课程资料、库存和价格会变化，模型服务也可能更新。为每次回答记录模型版本、提示模板版本、检索索引版本、文档时间和工具结果，才能在用户反馈错误时重放请求。版本不是为了增加表格，而是为了回答“当时系统究竟看到了什么”。

对行业和科学任务，人工工作流是系统的一部分。专家不只是最后签字，还可以参与样本定义、边界标注、错误分级、阈值设定和上线后抽检。把专家修改内容回流为新的评估样例，比单纯追求更大模型更容易形成持续改进闭环。

这样一来，所谓“行业大模型”就能被拆成可学习、可测试和可负责的组件。你既不会低估通用底座的价值，也不会把行业数据、检索和人工流程的贡献全部算到模型参数头上。下一节的模型选择，就会把这些约束变成一张可比较的证据表。

从一个真实需求开始画四层架构

假设需求是“让学生查询课程资料”。L0 可以提供语言理解和生成，L1 可以通过课程术语和资料建立领域语境，L2 规定问题、答案、引用和不确定字段，系统层负责文档导入、切分、Embedding、检索、权限、日志和人工反馈。这样画出来后，任何一次错误都能对应到某个组件，而不是笼统地说“模型不够聪明”。

如果学生问“第三章的练习二答案是什么”，系统首先要判断是否有权访问答案，再按章节和版本检索，生成时必须引用来源；如果学生问“这条规则现在还有效吗”，系统要优先查最新版本，不能只凭模型记忆；如果学生要求自动提交作业，系统要把提交动作与生成答案分开，并要求明确确认。一个通用模型可以参与三种请求，但承担的责任不同。

再看“从实验日志生成报告”。原始日志可能是文本、表格和图片，L0 负责语言和图表理解，L1 负责实验术语和单位，L2 规定报告字段、计算公式和不确定度，系统层保存原始文件、运行代码、版本和审核记录。模型可以提出异常假设，却不能把未经验证的因果结论直接写成最终报告。

“客户工单自动分派”则可能不需要大模型。若标签固定、样本充足、延迟要求严格，一个分类模型或规则系统可能更合适；大模型可以处理少量新类别和解释，但最终队列、优先级和通知由确定性服务执行。按任务拆开后，你会发现“大模型”不是所有层级的默认答案。

分层还可以指导预算。模型调用费、向量索引存储、文档解析、工具 API、日志存储和人工审核都是不同成本。先测每层的请求量和失败率，再决定是否缓存、批处理、蒸馏、量化或更换部署方式。只比较生成模型的单价，往往会漏掉检索和人工环节的主要支出。

分层也可以指导隐私。原始文档可能只能在内网处理，脱敏后的片段可以进入检索库，匿名统计可以用于评估，但原始用户问题和模型输出未必可以长期保存。为每层写数据保留时间、访问角色和删除方式，才能回答用户“我的内容去哪了”。

最小可行系统应该有“停止按钮”。当检索无结果、工具返回冲突、模型输出不符合结构、权限判断不确定或成本超过预算时，系统可以暂停自动化，展示可解释的状态并转人工。比起让模型在每个异常上继续生成一段听起来完整的话，明确停止通常更安全。

当你向别人介绍一个大模型产品时，可以用五句话：它处理什么输入；输出什么结果；底座与行业适配在哪里；外部资料和工具怎样进入；失败、权限和人工接管怎样安排。若五句话说不完整，说明产品仍停留在品牌或宣传层面，还没有形成可学习的系统定义。

本章后面的比较矩阵会继续使用这套方法。先按硬约束排除不可用方案，再比较模型质量；先确定系统责任，再讨论参数规模；先确认来源和许可，再决定是否把数据接入。按层级思考，能让学习路线和工程决策保持一致。

层级判断的反例练习

如果一个平台提供“法律问答”，先不要直接把它叫作法律大模型。它可能只是通用模型加法律文档检索，也可能包含领域微调、引用模板、权限和人工审核。你要分别问：法律知识在哪里，文档版本如何更新，答案怎样引用，越权问题怎样处理，最终责任由谁承担。

如果一个设备提供“端侧多模态 AI”，也要拆开看。图片可能在设备上预处理，复杂推理可能发送到云端；文本模型和视觉编码器可能由不同供应商提供；离线时可能只保留分类或 OCR。广告中的一个标签，不能替代数据流和降级路径。

如果一个科研工具声称“自动发现规律”，应区分候选生成、统计检验、实验执行和科学结论。模型可以生成假设或排序实验，但数据质量、测量误差、控制变量和专家复核仍然属于系统和科学流程。把候选当结论，是层级混淆带来的高风险错误。

做层级练习时，可以刻意把同一个底座放进三个场景：公开文章摘要、带版本的制度问答和库存下单建议。比较它们需要的检索、工具、权限、人工审核和回滚，写出哪些职责不能由模型独自承担。这样你会看到“同一模型，不同系统”的真正含义。

层级也影响学习顺序。先学 L0 的表示和生成，再学 L1 的领域数据与检索，随后学 L2 的任务契约和评估，最后学系统的权限、监控和部署。若一开始只看应用演示，容易把系统编排误认为模型本身；若只研究底座参数，又容易忽略真实任务的边界。

当一个产品把所有能力都写在“模型”一栏时，你可以要求它补一张组件和责任表。能清楚回答的产品，通常更容易评估和维护；只能重复“行业领先”“全能 Agent”的产品，需要更多证据。分类不是为了贴标签，而是为了知道下一步该查哪里。

层级拆分后的最小交付物

通用底座层的交付物是模型身份、接口和能力边界；行业适配层的交付物是领域数据说明、版本和专家规则；任务层的交付物是输入输出契约、样例和评分脚本；系统层的交付物是检索索引、工具协议、权限、日志、监控和回滚。每一层都有自己的文档，别人才能在不猜测的情况下接手。

交付物也应对应故障。模型版本变化，检查模型回归；行业文档更新，重建索引并检查引用；任务字段变化，更新样例和解析器；工具接口变化，跑权限和参数测试；系统延迟升高，查看缓存、并发和外部服务。把变化和检查点绑定，比上线后凭感觉排查更快。

一个成熟的系统会把“模型可替换”作为设计目标。业务代码只依赖统一接口，模型适配器负责不同 SDK 或权重格式，评估脚本使用同一套测试集，报告记录版本和证据。这样你可以比较不同模型，也可以在某个供应商不可用时安全降级，而不必重写全部业务。

当你还在学习时，不必一次实现完整平台。先用文件和纯 Python 做四层的最小模拟：一份模型卡、一个领域资料列表、一个任务 JSON 和一个验证报告。等基础概念稳定，再把其中一层替换成真正的模型、Embedding、检索或工具。小闭环能让每一步的责任都看得见。

层级判断的完成句式

看到任何模型或产品，都可以用一句完整的话复述：“它在 ___ 层，处理 ___ 模态，输入是 ___，输出是 ___；能力主要来自 ___，外部系统还提供 ___；它适合 ___，不适合 ___；上线前必须验证 ___，失败时由 ___ 接管。”这句式会自动暴露遗漏，也能直接变成模型分类卡的字段。

如果一句话里只有品牌、参数和“智能”，说明你还没有完成分层。补上数据、责任、证据和停止条件，才算从产品宣传进入系统理解。

一条可复用的分层检查

每次新增组件，都问它属于模型、知识、工具、规则还是人工流程，并写出输入、输出和责任。若一个组件无法回答这三件事，就先不要把它放进生产链路。

分层结果如何进入项目文档

把四层架构写进项目 README：模型层说明检查点和接口，知识层说明资料来源和更新，任务层说明输入输出与评分，系统层说明权限、日志、降级和回滚。这样新成员可以沿着同一顺序理解系统，也能知道某个变更会影响哪一层。

如果一个问题无法归属于任何一层，先记录为未知并补充任务合同，不要用“模型问题”笼统带过。清楚的归属是后续排错、评估和交付的前提。

把测试结果记录成可复查的实验单

一条测试记录不应只有“通过”或“失败”。建议同时保存样例 ID、输入摘要、期望输出、实际输出、评分维度、证据位置、运行耗时和失败标签。涉及隐私的原文可以用脱敏后的引用或哈希代替，但要保证复核者能找到同一份测试材料。这样，后来的人看到一个分数时，能沿着“样例 → 输出 → 评分 → 结论”反向检查，而不是只能相信作者的截图。

两个候选模型出现接近分数时，优先比较最影响任务的失败类型，而不是继续追逐小数点后的差异。例如一个模型平均分略高，却经常漏掉引用；另一个模型分数略低，但能稳定返回可验证的字段。对课程资料问答、财务整理等任务，后者可能更适合上线。把“为什么这个失败更严重”写进实验单，权重才真正和业务风险连接起来。

一次评估必须写清“谁、对什么、怎么测”

模型评估常见的三个缺口是对象不清、任务不清和协议不清。对象不清指没有说明具体检查点、分词器、量化或服务版本；任务不清指只写“综合能力”，没有说明输入、输出和失败代价；协议不清指没有固定提示、解码、评分和人工判定。任何一个缺口都可能让两个结果看起来可比，实际上比较的是不同东西。

评估表可以增加“证据等级”：A 级是官方原始结果或可复现脚本，B 级是你在固定数据上的重复测试，C 级是少量探索样例，D 级是二手转述或个人印象。D 级信息可以帮助发现候选，却不应支持高风险上线。随着项目推进，把关键判断从 C/D 级提升到 A/B 级。

人工评分也要写规则。开放式答案可以按事实正确、来源完整、格式合格、表达清楚和安全边界分别打分；两个评审者要看到同一份指南和样例。若使用另一个模型作为评判者，记录评判提示、版本和可能的偏差，不要把自动评分当成客观裁判。

负面结果同样重要。记录模型拒答、超时、截断、格式错误、引用缺失、重复和越权建议的比例；不要只统计成功样例。对生产系统，加入“可发现性”：错误能否被规则、引用检查或人工审核及时发现？无法发现的错误比明显报错更危险。

评估还要有停止规则。你不需要无限扩大测试集，先定义“达到什么结果可以进入下一步”“什么失败必须回到数据或提示修复”“什么风险直接淘汰候选”。停止规则可以防止在一个看似微小的分数差异上反复调参，而忘记任务和成本。

选择完成后保留一个基线。新版本、量化、提示改动和检索策略都与基线比较，至少保存原始输入、输出、指标和环境。没有基线，就无法知道“优化”是真的改善，还是换了数据和评分方式。

选择模型时的反直觉问题

“更大是不是一定更好？”不一定。若任务是固定字段抽取，小模型配合规则和验证器可能更稳定；若任务需要复杂跨文档推理，大模型可能更有余量，但也要支付延迟和成本。真正的比较要在同一任务合同、相同错误代价和可接受资源内进行。

“上下文越长是不是越省事？”不一定。把整本资料塞进上下文可能增加成本、延迟和信息埋藏，模型还可能忽略关键段落。合理切分、检索和摘要能减少无关内容，让证据更容易定位。长上下文要用位置、长度和干扰样例测试，而不是只看官方上限。

“自动评判分数高就可以上线？”不一定。自动评判可能偏爱流畅语言，忽略事实、引用、格式或安全；数据集还可能与训练语料重叠。高风险任务需要人工抽检、对抗样例、来源检查和回滚演练。自动评分是加速器，不是责任替代品。

“开源模型一定更可控？”不一定。权重可下载会增加本地控制，但你要负责依赖、漏洞、访问权限、更新和输出监控；API 服务虽然内部不可见，却可能提供成熟的安全和运维能力。可控性要按数据、版本、审计、退出和维护具体衡量。

“同一模型的不同提示只是写法差异？”不一定。系统提示、角色、工具定义、结构化约束和示例会改变输入分布；版本升级也可能改变默认模板。把提示文件纳入版本控制，并把它当作模型调用的一部分评估，才能复现结果。

选择过程可以分为探索、收敛和上线三个阶段。探索阶段允许快速试用和少量样例，目标是发现候选和主要失败；收敛阶段固定版本、数据、提示、指标和权重，目标是比较并淘汰；上线阶段加入安全审核、监控、回滚和责任人，目标是可持续运行。不同阶段的证据标准不同，不要用探索阶段的演示直接跨到生产。

从候选列表到最终选择：一套可复用的评估协议

模型选择最好先写协议，再开始跑样例。协议的第一行是任务定义：谁使用系统、输入从哪里来、输出交给谁、错误会造成什么后果；第二行是数据边界：哪些内容允许上传、保存和用于评估，哪些内容必须脱敏或留在本地；第三行是资源约束：响应时间、并发、预算、硬件和可接受的维护工作量。没有这三行，比较很容易被演示效果带偏。

测试集不要只收集“典型问题”。可以按输入来源、长度、语言、格式、主题和风险各取样，再单独加入边界样例。以课程资料问答为例，测试集应同时包含直接事实、跨章节关联、表格内容、图片公式、资料缺失、版本冲突和恶意提示。每个样例写出期望答案、必须引用的证据、允许的近似和不能接受的错误，评分才不会随评审者心情变化。

候选模型应使用同一接口适配层。适配层负责消息格式、图片或文件序列化、超时、重试和错误码，把模型差异转换成统一的输入输出记录；业务评估只读取统一记录，不在每个候选分支里写一套特殊逻辑。这样可以避免某个模型因为专属提示或隐藏后处理而“作弊”，也方便以后加入本地模型或测试替身。

评估时同时保存原始输出和解析后的结果。原始输出用于复盘模型是否添加了多余文字、拒答或引用，解析结果用于统计字段准确率、格式通过率和工具参数。若只保存最终分数，发现异常时无法知道是模型输出错、解析器丢字段，还是评分脚本读取错列。原始记录还要遵守隐私策略，必要时使用脱敏 ID。

质量评分可以拆成多个维度，而不是一个“好／坏”。事实正确性检查答案与来源是否一致，完整性检查是否覆盖任务要求，格式检查字段和类型，引用检查来源是否存在且定位准确，安全检查是否越权或泄露，表达检查可读性和冗余。不同任务的权重不同，但维度名称最好固定，便于跨版本比较。

成本与延迟也要按分位数报告。平均延迟会掩盖偶发超时，至少记录 P50、P95 和超时比例；平均成本会掩盖长文档，最好记录每次输入 Token、输出 Token、检索 Token 和工具调用次数。线上用户感受到的是尾部延迟和失败后的等待，不是实验室里的平均值。

隐私和许可应当是硬门槛。候选模型如果要求数据出域而任务不允许，直接淘汰；如果许可证或数据处理政策没有确认，标记为未知并暂停上线，而不是用质量分数抵消。对于本地模型，也要检查权重来源、依赖、日志和更新责任。选择矩阵的硬门槛列应先于软评分列。

稳定性需要重复运行。对确定性任务可以固定解码参数，对开放式生成可以设置多个种子或重复请求，观察输出变化；对 API 模型还要记录日期、服务端版本和限流情况。一次偶然的好答案不能证明稳定，连续失败也要保留，尤其是格式、引用和工具参数的失败。

人工评审要有抽样策略。可以先自动筛出高分、低分、冲突和异常样例，再让专家重点审查；同时随机抽取一部分普通样例，避免只看极端案例。评审者应知道任务规则，却不必知道候选模型名称，以减少先入为主。分歧样例要保存讨论结果，必要时更新评分指南。

最终选择应写成带条件的决策记录：选择哪个版本、用于哪些输入、不用于哪些场景、依赖哪些外部组件、目前证据等级是什么、上线前还要完成哪些测试、什么时候复评或回滚。把“暂时选择”写清楚，比宣称“最佳模型”更诚实，也更能适应模型和数据的快速变化。

把这份协议保存成模板，之后比较文本、视觉、Embedding 或多模态模型都可以复用，只需替换模态、指标和风险字段。它会让你在第 10 章学习 RAG、第 11 章学习视觉大模型和第 14 章学习部署评估时，仍然沿用同一套严谨习惯。

选择报告的写法：让别人能复核你的决定

一份选择报告先写结论范围：“在课程资料问答原型中，候选 B 通过了中文、文档不出域和结构化输出三个硬门槛；在固定测试集上引用覆盖和延迟达到目标，暂不代表医疗或生产交易场景。”先限定范围，再给模型名称，读者就不会把局部实验误读成普遍排名。

接着写候选的身份和接口：家族、检查点、版本、模态、上下文、访问方式、量化和分词器。若是 API，记录服务端返回的模型标识和日期；若是本地权重，记录文件哈希、推理框架和硬件。身份字段缺失时，所有后续分数都应标为不可复核。

然后写硬门槛结果。每个门槛都给出通过、失败或未知，以及证据位置。许可证未知不是“低分”，而是暂不允许进入生产；隐私不满足不是可以由质量补偿的缺点；不支持所需模态就不应继续比较细节。硬门槛单独成表，能避免加权平均掩盖不可接受风险。

软指标表要给出定义和样本量。答案质量是怎样评分的，引用命中如何判定，延迟测了多少次，成本包含哪些 Token 和工具调用，人工修改量从哪一批数据统计？数字后面附测试编号或报告链接，别人才能判断差异是否超过噪声。

报告还要列出被淘汰和未选择的候选，并写理由。一个模型可能质量最高但许可证未知，另一个成本最低但格式不稳定，第三个质量略低却能离线运行并且证据充分。记录放弃原因可以避免下次重复同样的试错，也能让团队理解选择不是个人偏好。

最后写复评触发器：模型版本变化、资料库更新、输入分布变化、成本超过阈值、出现新的安全事件或人工修改量上升。触发器出现时重新跑固定测试，而不是凭感觉继续使用。选择报告因此成为一个会更新的文档，而不是一次性的排行榜截图。

对于学习项目，报告可以很短，但字段不能省。哪怕只有两个候选，也要有任务合同、硬门槛、五个软指标、证据链接、失败样例和下一步。小而完整的报告比大而含糊的模型名单更能训练判断能力。

当报告按这个顺序组织，模型选择就从“推荐某个名字”变成了可解释的工程决策。后面的综合实验会把身份、硬门槛、评分和回读全部写入 Python 数据结构，形成一个可以持续维护的最小资料库。

把“推荐”改成可回滚的选择

选择模型不是一次性投票，而是一个带回滚的实验。先指定一个当前基线，所有候选都与基线在同一协议下比较；若新候选只在少数样例上提升，却让成本、延迟或格式退化，就保留基线。基线不是最强模型，而是你已经知道如何运行、评估和退出的方案。

决策表中可以加两列“置信度”和“剩余工作”。高分但样本少的候选，置信度应低；许可证已确认但长文本未测的候选，剩余工作应写清；本地运行稳定但质量略低的候选，可以作为降级路线。这样团队不会把分数误解为完成度。

测试集要防止答案泄漏。若问题来自模型训练过的公开基准，分数可能高于真实新任务；若测试样例过于接近提示模板，格式通过率也会被高估。可以加入自己编写的改写题、时间外样例、实体替换题和反事实题，并保留一小批不公开的盲测数据。

不要忽略用户体验指标。模型质量上升但响应变慢、输出变长、引用位置难找或人工修改量增加，用户可能仍然觉得系统变差。把完成任务所需的总时间、重新提问次数、人工编辑量和失败后恢复时间纳入比较，才能把模型指标连接到真实使用。

对于开放式生成，分数差异可能小于评审噪声。报告中给出样本量、评分者数量、重复运行次数和置信区间或波动范围；如果无法做统计，就明确写“探索性结果”。不要把 0.1 分的差异包装成稳定优势，尤其是在测试集很小的时候。

模型选择还要考虑退出成本。API 迁移可能需要重写提示和限流逻辑，本地模型迁移可能需要重新量化和部署，领域微调可能绑定某个底座版本，检索系统可能绑定某种向量格式。提前保留统一接口、原始数据和评估协议，能降低未来换模型的代价。

当选择理由写完后，让一个没有参与实验的人复核。请他只根据报告回答：为什么选它、它哪里失败、哪项证据仍未知、出现什么情况会回滚。若对方回答不了，说明报告缺少上下文；补齐报告比继续添加一个候选更有价值。

选择结论的三个限制词

用“在……上”限定任务，用“截至……版本”限定时间，用“尚未验证……”限定边界。例如“在固定的课程问答集上，截至 demo-1 版本，候选 B 的引用覆盖较高；尚未验证多轮对话、超长文档和真实用户输入”。限制词让结论不被误读，也为下一次复评留下明确问题。

如果报告无法写出这三个限制词，通常不是模型太复杂，而是任务、版本或测试还没有定义。先补齐证据，再给出推荐。

选择时一定要保留未选择的理由

记录“为什么没有选另一个候选”同样重要。它可能因为许可证未核对、长上下文未测、中文格式不稳、延迟超过硬门槛或维护成本过高。未来条件变化时，这些理由能告诉你是否值得重新测试，而不是从零开始猜。

一份可复核的选择结论，应该同时包含选择、放弃、未知和复评触发器。只留下一个名字和一个总分，别人无法判断你的决策是否仍然适用。

选择完成后的复核问题

请再问一次：如果输入模态变化、资料版本变化、并发量变化或许可证变化，原来的选择还成立吗？如果答案是“不知道”，就在报告里写成复评触发器；如果答案是“不会成立”，提前准备降级或替换方案。能提前说明何时失效，选择才真正可维护。

这一步也能防止把一次测试结果当成永久结论。模型生态、数据分布和任务要求都会变化，选择表应允许更新而不覆盖旧证据。

评估报告还要说明“没有测什么”

除了列出通过的指标，还要列出没有覆盖的语言、输入长度、模态、并发、版本和风险场景。没有测到的内容不能被默认当作稳定能力；在报告中明确空白，能提醒使用者不要越界。

如果两名评审者对答案分歧较大，保留原始样例和讨论结果，并更新评分指南。分歧往往揭示任务合同不够清楚，或者指标无法表达真实目标。修订规则后要重新跑基线，不能只修改最终分数。

最终选择应同时保存候选、淘汰理由、未知项和复评日期。这样当价格、版本、数据政策或任务输入变化时，可以快速决定是否重测，而不是重新从搜索结果开始。

为资料库留下“可追溯的变化记录”

模型资料库不是填完一次就结束的静态表格。每次修改记录时，最好写明变更日期、修改人、变更字段和依据：例如版本升级、许可证条款变化、官方评估更新，或你自己的测试集增加了新样例。若只是修正拼写，也要避免覆盖原始证据。最简单的做法是在 JSON 中保留 updated_at 和 evidence，同时把旧报告按日期保存；项目变大后再引入版本控制。

还要区分“事实变化”和“判断变化”。模型发布方改了许可证，是事实变化；你因为任务预算改变而调整权重，是判断变化。前者要重新核对来源，后者要在报告中说明新的任务假设。把两种变化混在一个总分里，日后很难解释为什么同一模型的排名突然改变。

当资料库供多人使用时，可以给字段增加维护责任人和复核日期。超过复核日期的许可证、价格、上下文上限和服务版本标为“需要更新”，而不是继续显示成确定事实。这样，目录不仅能帮助你学习分类，也能训练你建立面向真实工程的资料维护习惯。

项目交付前的三次检查

第一次是结构检查：用 JSON 解析器读取文件，确认字段类型和唯一 ID；第二次是行为检查：用一条合格、一条缺字段、一条未知许可和一条同分记录运行脚本，观察接受、拒绝、待测和排序是否符合规则；第三次是冷启动检查：在新的终端和空输出目录中，从 README 开始执行，确认没有依赖内存状态、当前工作目录或手工修改。

报告里不要只放漂亮的排名表。把被过滤的记录、缺失字段、证据链接、评分权重和生成时间一起写出；如果某个候选分数很高但许可证待核对，就在报告顶部标注“不可直接上线”。一份诚实的“待核对清单”比一份看似完整但无法解释的排行榜更有价值。

最后把项目当作学习资产而不是一次性作业：保留原始 JSON、脚本、测试输入、报告和失败记录；每次更新模型版本时复制一份目录，修改 schema_version 或日期，不覆盖旧证据。这样你在第 7～10 章学习评估、Embedding 和 RAG 时，可以继续复用同一套数据结构。

知识边界检查：会描述，不等于会训练

完成本章后，你应该能阅读模型资料、整理分类字段、设计选择矩阵并指出证据缺口，但还不要求你从零训练一个大模型。训练需要更深入的 Python、数据处理、数学、机器学习、神经网络、GPU、分布式和评估知识，这正是后续章节的任务。把“能解释模型类别”和“能实现模型训练”分开，是对学习进度的诚实记录。

同样，你现在可以理解“RAG 是模型外接检索”“多模态需要对齐和融合”“开放权重不等于完全开源”，但还不必立刻搭建向量数据库、部署视觉模型或分析数十亿参数。先把概念、输入输出和证据链练熟，后面的工具学习会更快。过早追逐完整产品，往往会让基础漏洞被复杂框架遮住。

如果别人问你“哪个模型最好”，你可以先要求补充任务、模态、数据边界、延迟、预算、许可和风险。若对方暂时无法提供，就给出“需要更多条件”的回答，并说明可以先做一个低风险基线。专业判断并不总是立即给出一个名字，有时是把问题问得足够具体。

把复盘变成一次可重复的口述测试

第一轮只用一分钟说清“模型是什么”：层级、模态、输入输出和开放性。第二轮用一分钟说清“它为什么能做”：预训练目标、微调、对齐、检索和工具。第三轮用一分钟说清“我凭什么选”：任务合同、硬门槛、评估证据、成本、延迟、隐私和失败接管。三轮都不允许用“很强”“很大”“很智能”结束，必须补上事实或未知。

口述测试的价值在于暴露隐形混淆。你可能知道“视觉模型”这个词，却说不出输出是标签、坐标、描述还是图像；可能知道“开放权重”，却没有核对代码和许可证；可能知道“长上下文”，却没有测量有效利用率；可能知道“Agent”，却没有写工具权限和回滚。卡顿的位置就是下一次学习的入口。

把口述提纲与分类卡对照，检查每个结论能否回到一个字段或一个来源。没有来源的结论标为推测；没有测试的能力标为待测；没有定义的指标标为待补。每次修改分类卡时，再录一次短复盘，观察自己是否能更快说明重点。这个过程比不断收藏新模型名字更能提升判断力。

如果要和同学协作，可以互换模型卡进行“反向提问”：对方只读你的摘要，追问一个模态边界、一个许可材料、一个评估协议和一个失败处理。你不能打开原始页面，只能根据记录回答；回答不了的地方就补证据。这样能检验资料是否真的可读，而不是只有作者自己看得懂。

复盘还要写一条“停止条件”。当资料不足、风险无法评估或硬门槛不满足时，停止继续比较并标记阻塞；当证据满足、测试达标且回滚方案可用时，才进入下一阶段。知道何时停止，是工程判断的一部分，也能避免在不可靠的信息上不断投入。

最终复盘卡

我现在能解释：大模型没有单一分类标准；模态、开放程度、规模架构、训练目标和用途是不同观察轴；模型能力与应用系统能力不能混为一谈。

我亲手留下：models.json、验证脚本、比较报告、至少一次失败记录，以及一份带来源和日期的参考清单。

我下一步要做：进入第 1 章，先让 Python 解释器、目录、文件和最小脚本稳定运行，再把本章的分类卡交给代码处理。

结业前的完整复盘：把“知道”变成“能证明”

复盘第一步是重新命名对象。不要只写产品名，而要写发布方、模型家族、具体检查点、版本、模态接口和访问方式；如果页面只说“某系列模型”，就把检查点标成未知。名称越精确，后面的参数、许可、评估和输出记录才有可能对应到同一个对象。

第二步是画输入输出图。把原始输入、预处理、中间表示、模型输出、后处理和外部动作画成节点，给每条边标上格式、长度、版本和失败处理。图中若出现“模型直接负责权限”“自然语言直接触发付款”或“没有来源的事实进入报告”，就先把它标成需要修复的风险，而不是继续讨论模型大小。

第三步是做分类轴的交叉检查。模态回答“处理什么信息”，开放程度回答“哪些材料可获得”，规模回答“计算和容量怎样”，训练目标回答“能力怎样形成”，用途层级回答“服务什么任务和责任”。一个字段不能代替另一个字段：知道模型支持图片，不等于知道它有视觉权重；知道它有 128K 上下文，不等于知道它能可靠使用长文；知道它是行业模型，不等于知道行业数据怎样进入。

第四步是复核证据等级。官方模型卡和许可证适合确认用途、限制和权利；技术报告和论文适合确认架构、数据和训练目标；自己的测试适合确认目标任务上的质量、延迟和格式；论坛和二手文章适合发现线索。把不同等级的证据混写，会让猜测看起来像事实。

第五步是检查未知项是否可行动。每个未知字段旁边写“下一步查什么、谁来查、通过标准是什么”。例如许可证待核对，就指定阅读哪份条款；长上下文待测，就指定长度、位置和评分；图像能力待测，就准备低分辨率、遮挡和文字样例；数据处理政策未知，就暂停输入真实资料。未知不是空白，而是一项待完成的工作。

第六步是检查错误地图。把失败按对象、模态、数据、训练、提示、检索、工具、权限和系统状态归类，并记录一个可复现样例。若所有错误都写成“模型幻觉”，你就失去了修复方向；若错误能定位到链路节点，下一步可以是补数据、改接口、加验证器、换模型或转人工。

第七步是做一次反向教学。尝试向没有读过本章的人解释一个模型，让对方只允许你使用分类卡和比较报告提问。对方应该能从你的记录知道模型处理什么、能否使用、适合哪里、怎样评估和什么时候停止。若必须重新打开十几个页面才能回答，说明资料还没有压缩成可迁移的知识。

第八步是做一次冷启动。复制项目到一个空目录，在没有缓存和历史终端状态的情况下读取 JSON、运行验证、生成报告、检查引用和执行测试。冷启动失败通常暴露路径写死、隐式依赖、未记录环境、缺失字段或排序不稳定，这些问题会在后续数据与模型实验中反复出现。

第九步是写“暂不学习”的边界。本章介绍了视觉、音频、多模态、科学模型、Embedding、RAG、Agent 和部署，但没有要求你现在实现每一种。暂不实现不等于不重要，而是先把它们放在地图上，等 Python、数学、机器学习和 Transformer 基础足够后再深入。明确边界能防止学习范围无限膨胀。

第十步是写迁移问题。进入下一章时，不要只问“Python 语法有哪些”，而要问“如何用 Python 读取分类卡、检查字段、处理未知、稳定排序、保存报告和记录错误”。把新知识绑定到已有项目，能让基础学习产生真实反馈，也能让第 0 章的结论在代码中接受检验。

完成闭环后，你不需要背下所有模型名称，也不需要立刻做出一个复杂产品。你需要的是一种稳定的判断动作：先定义对象和任务，再按模态、开放程度、规模、训练和用途拆解，随后寻找证据、做最小测试、记录未知、设计接管，最后把结论保存成别人可以复查的资料。第 0 章的价值，就在这套动作可以迁移到任何新模型和新论文。

如果某个结论无法被证据支持，就保留它的暂定状态；如果某个任务无法通过硬门槛，就停止比较并说明原因；如果某个系统已经满足目标，就保留基线和回滚。专业的学习资料不是把页面写得永远正确，而是让读者知道结论来自哪里、边界在哪里、下一步怎样验证。

复盘输出的最低质量标准

复盘不是把正文再读一遍，而是要产生新的可检查文件。至少留下对象身份卡、模态 I/O 表、开放性审计、规模账本、训练阶段说明、任务合同、模型比较矩阵和错误地图。每份文件都写版本、日期、来源和未知项，避免下一次学习只能依赖记忆。

覆盖检查要包含正向和反向问题。正向问题是“它能做什么”，反向问题是“什么情况下不能做、失败如何发现、发现后谁接管”。只有正向没有反向，资料会像宣传页；只有反向没有正向，资料又无法指导选择。两者一起写，才能形成可执行的边界。

知识点之间还要能互相引用。模态表应能链接到任务合同，规模账本应能链接到部署指标，训练阶段应能链接到能力证据，开放性审计应能链接到版本记录。交叉引用不是形式工作，它能让你在修改一个字段时发现受影响的测试和结论。

复盘时把“事实、推测、计划”分成三种标记。事实来自官方文档、论文或已保存的实测；推测是根据架构或有限样例得到的暂时判断；计划是下一步要做的测试、核对或迁移。三种标记混在一段话中，读者很难知道哪些内容可以直接依赖。

还要记录一条最小失败路径。比如资料不存在时返回“不确定”，图片模糊时请求重传，许可证未知时停止上线，工具参数越权时阻断动作，模型服务超时时切换降级方案。失败路径越具体，后续 Python、RAG 和部署学习越容易把它实现成代码。

如果和同学或团队共同维护资料，约定字段含义和修改规则。新增模型必须有来源和日期，修改分数必须保留测试集和原因，删除记录必须说明是否仍有旧报告引用，许可证变化必须触发复评。规则不需要复杂，但要让不同的人写出的卡片可以放在一起比较。

当本章的资料开始变长时，优先删掉重复标签和没有证据的形容词，不要删掉限制、案例、表格和失败说明。长资料的价值不在于每个名词都出现，而在于关键概念有定义、有例子、有反例、有操作和有验收。后续每章都沿用这个标准。

最后给自己一个清晰的完成判断：能用自己的话讲清九个主题，能打开一个新模型资料并填写分类卡，能运行项目验证并解释一个失败，能说出下一章要用 Python 解决的具体问题。满足这些条件，就可以进入第 1 章；不满足时，只补对应卡点，不必无限重复整章。

复盘通过的最低判断

你不必记住所有术语，但要能把一个新模型放进坐标系：先说对象和版本，再说模态 I/O、开放材料、规模架构、训练阶段、用途层级和证据边界。遇到未知时能写出下一步核对动作，遇到高风险时能说出停止或人工接管条件。

如果这些动作都能完成，第 0 章就达到了“可迁移”的标准。接下来学习 Python 时，直接用本章的分类卡做读取、验证、排序和保存练习，让概念在代码中继续生长。

把复盘结果带走

复盘的最终产物不是“已学完”的标签，而是一组能在下一章继续使用的文件和问题：分类卡、比较表、失败样例、来源记录、JSON 验证脚本，以及“如何用 Python 读取和更新它们”的入口。带走这些资产，第 1 章的语法会立刻有真实任务。

若仍有不确定项，把它们列成待验证清单并保留优先级；若某个结论已被测试支持，把测试编号写回分类卡。这样学习资料会随着证据成长，而不是随着时间被新的宣传名词覆盖。

把本章结论交给未来的自己

在复盘文件顶部写三行：已确认的事实、仍然未知的边界、下一次要做的验证。事实附来源或测试编号，未知附风险和负责人，验证附通过标准。每次进入新章节时先读这三行，学习就会围绕真实问题推进，而不会重新陷入无目的的名词收集。

同时保留一条最小可运行命令，例如读取分类卡、运行验证、生成报告和检查输出。命令能在空目录执行，说明知识已经从网页迁移到实践；命令不能执行，就把缺失的 Python、路径或文件知识列为第 1 章的具体任务。

当模型生态变化时，回到这份文件更新版本、来源、许可证和测试结果。旧结论不必删除，标记失效日期和原因即可。保留变化轨迹，才能区分知识本身变化与资料记录变化。

复盘完成

此后每次学习，都从一个可验证的问题开始。