AI 学习笔记系列的第六篇，介绍其他模型、上下文学习、数据来源、标注和众包等与 LLM 相关的补充内容。

其他模型

不使用 Transformer 的模型是存在的，例如 Mamba、Jamba。

这里重点看的是 状态空间模型（State Space Model, SSM） 这条线。 序列模型（比如 RNN）看起来像“老东西”，但它们的变体研究仍然很活跃：除了 Mamba，也还有 RWKV、xLSTM 等方向。

它们目前在准确率上整体还没有超过 Transformer，但常被强调的优势是：

  • 可处理长上下文
  • 速度很快

也就是说，这条路线并不是完全替代 Transformer，更像是在某些约束（长序列、吞吐、延迟）下提供不同的权衡。

上下文学习（ICL，In-Context Learning）

ICL 指的是：不更新模型参数，而是在提示词中直接加入用于示范任务的信息（任务说明与示例），希望模型据此完成任务。

N-shot

N-shot 就是给多少示例：

  • 0-shot：直接提问，不给示例
  • 1-shot：给 1 个示例再提问
  • N-shot：给 N 个示例再提问

示例数量不是简单的越多越好。 常见的结论是少量示例时性能快速上升，中间可能下滑，然后随着示例继续增加又稳步上升。

提示词

提示词质量差异可以非常大。 一个常见经验是低困惑度提示词通常更好（Perplexity）（更像自然语言、更顺）。 但也存在明显的变异性（Variability，表现为结果波动）来源：格式不同、顺序不同。这意味着即使任务、示例内容都不变，仅仅改变排列方式与模板，都可能带来显著波动。

标签

关于什么标签有帮助，一个常见结论是小规模时标签内容更关键（你写的标签本身会强烈影响模型），而大规模时模型会自己推断更多（标签的具体措辞相对没那么决定性）。

思维链（CoT）

CoT（Chain of Thought）是一种提示词工程（Prompt Engineering）技术，指用连贯的逐步推理过程引导模型完成多步复杂任务。

但要注意糟糕的解释通常会导致错误答案。 也就是说，CoT 并不是加了就一定好，而是加了之后，解释本身成为新的风险点。

此外，也有一些较新的研究与讨论认为：在一些情况下，思维链可能呈现出类似“欺骗”或“不忠实解释”的现象——例如过程与答案不一致（过程错、结果对，或反之亦然）、根据答案事后拼装推理（看起来像因果倒置）、以及在用户暗示存在时更倾向于迎合暗示而非独立求证。

需要强调的是，这类现象并不必然说明语言模型真正懂得了思考，更像是模型在语言层面学习到了一套可生成的解释模板，这些解释在不少情况下能提升可读性与可用性，但也可能在某些场景下成为误导来源，因此仍需结合任务与评估方式谨慎使用。

ICL 工程实践

LLM 在 ICL 场景里看起来会从以下内容受益：

  • 示例展示了标签空间（有哪些可能输出/类别）
  • 示例暴露了输入分布（问题大概长什么样）
  • 示例固定了期望输出格式

换句话说，示例不只是“提供答案”，它还在提供隐式规范：任务边界、输出模板、甚至错误分布。

因此，做 ICL 时通常建议：

  • 尽可能使用更多演示示例
  • 避免示例顺序里出现明显模式

按标签排序会伤害性能，把同类标签连续堆在一起（模型容易学到顺序模式而不是任务本身）。

同时也有一些对标签做改动但影响很轻微的操作，例如：

  • 翻转标签
  • 随机化标签
  • 直接移除标签

这意味着模型在 ICL 中可能并不依赖你以为它依赖的那部分显式符号，而更依赖分布、格式、对齐出来的隐式规律。

数据来源

训练大模型的数据主要来自互联网。

一个例子是 FineWeb。它的基本流程可以概括为两步：

  1. 下载数据
  2. 过滤数据

其中 FineWeb 提到的一个关键点是：通过训练来选择过滤器，大致思路是：

  1. 改变过滤器
  2. 训练模型
  3. 测量性能

数据过滤

数据过滤不是拍脑袋规则，它可以被当成可搜索、可评估的系统组件。

当从网络收集 LLM 训练数据时，经常会直接跳过整域名（例如 URL 含某个域名的全部网站）。 典型原因包括：

  • 避免给模型喂入低质量数据
  • 或避免鼓励有风险输出

相比按域名过滤的常见替代方法是使用自动检测器判断网页是否高质量且合适（即更细粒度的质量/安全判定）。

数据扩展和风险

开发者追求更多和更好的数据，规模虽然能影响性能，但它不是唯一的。

数据扩展的例子很多，例如：

  • BERT：互联网抓取书籍
  • RoBERTa：增加更多数据

但更多数据不等于更好的训练。 数据集的影响可能非常大，因此应当：

  • 在多个任务上同时评估，避免过拟合单任务
  • 采用典型基准，如 GLUE（General Language Understanding Evaluation）

除了质量问题，还会有一些结构性风险：

  • 捷径（Shortcuts）：模型不真正完成任务也能答对
  • 有效性（Validity）
  • 统计功效（Statistical Power）
  • 社会偏见（Social Bias）
  • 任务本身是否值得创建（价值与伦理）

对应的一些做法包括：

  • 收集真实使用场景文本
  • 构造难例：例如错误答案却与输入/真答案有大量词重合
  • 对真答案做最小编辑并使其变错（控制变量制造对比样本）

数据集标准

一个好的数据集标准包括：

  • 有效性（Validity）：任务上表现好的模型在真实世界也表现好
  • 可靠性（Reliability）：标签准确
  • 统计功效（Statistical Power）：样本充足且包含足够难例，可做有意义比较
  • 可测试（Testable）
  • 公共许可（Publicly licensed）
  • 避免社会偏见

其中统计功效尤其值得单独强调，因为它是数据集区分不同模型性能的能力。 统计功效差的数据集可能会随机排序模型（谁好谁坏只是巧合），统计功效强的数据集会稳定排序模型，并更准确反映真实能力。

标注（Annotation）

我们到底在标注什么？

  • 真实世界数据：可能很少出现我们关心的现象，或天然带偏见
  • 构造数据：可能引入意外模式或偏见

数据预处理往往也是两步：

  1. 下载
  2. 过滤

标注工具和标注指南

标注工具的常见优势是：提升一致性、支持能力（例如约束输入、强制字段、自动抽样检查）。

标注指南则是标注能否稳定的关键，但它也有风险，不同标注员处理同类案例的方式可能不同。 因此说明应当做到简单、清晰、简洁、一致、可泛化，并且示例应同时包含常见案例和稀有案例。 同时需要随着时间迭代完善。

以一个情感分析的标注说明为例：对每条文本，把情感从正到负打在 7 分量表上。 这个说明简洁且能明确给出量表。 但还有如下可改进的点：

  • 加示例
  • 明确中间分值含义
  • 说明歧义样例处理（如暂不标）
  • 明确 1 分代表正还是负（避免方向歧义）

相关概念和注意事项

试标（Pilot annotation）的流程如下：

  1. 指抽样数据由多个标注员标注
  2. 比较、讨论并更新说明（试标的目标之一就是修改标注指南）

训练标注员（Train Annotators）的流程如下：

  1. 读说明
  2. 标注数据
  3. 与正确答案比较
  4. 讨论（过程中也可能更新说明，但在训练阶段通常不是以改说明为主要目标）

全量标注（Full annotation）是指对训练数据集中的所有样本进行完整标注。

每条样本配几个人，是成本与质量的权衡。

  • 训练集：常每样本 1 个标签
  • 测试集：常多个标签 + 裁决（因为希望测试集更准确）

常见质量控制还包括：

  • 注意力检查（Attention checks）：插入不合语境内容检查是否认真
  • 一致性检查（Consistency checks）：让部分样本由多人重复标，若不一致过高则报错

裁决（Adjudication） 是解决分歧的集中机制：筛出有分歧的样本，讨论并确定标签。

一致性度量（Measuring agreement）是指用统计指标来量化标注员之间的一致性水平。

备注：一致不等于好，也不等于有用，要结合任务需求来判断。

一致性（Agreement / Consistency）

常用的一致性指标有如下几个：

  • Cohen’s Kappa：值高表示一致性好
  • Fleiss’ Kappa：用于 2 人以上标注（把 Cohen 推广）
  • Krippendorff’s alpha：更通用，支持排序 / 比率/区间等数据类型

Cohen’s Kappa 高表示标注非常一致，低表示更接近随机。 这里的随机不是均匀随机，而是按标签分布抽样：例如 A 占 80%、B 占 20%，随机抽样会更常得到 A，因此随机一致性（Chance Agreement）较高。

备注：Chance Agreement 指的是当两个或多个评分者在评估同一个对象时，仅仅通过瞎猜、随机因素或者运气而非由于真正的共识而达成的一致性。

Cohen’s Kappa 相比直接算标签匹配比例的优势是它考虑了 Chance Agreement 的影响。 如果数据集标签极度不平衡，会提高随机一致项，从而影响 Kappa。 但如果把所有计数都翻倍，Kappa 数值不变。

一致性低的时候，需要调查并迭代，确定问题出在哪里：

  • 说明不清？
  • 任务主观？
  • 样本歧义？
  • 标注员粗心？

一致性低会让模型更难学习，因为训练信号不一致，同类样本一会儿标 A 一会儿标 B，模型会看到 loss 先下降后停在较高水平，难以继续改善。

发布标注数据

发布标注数据通常涉及：

  • 托管：GitHub、HuggingFace Datasets、自建网站
  • 许可证：是否有发布许可？是否做了必要匿名化？是否有权分享？按什么 license 共享？

备注：标注属于人类受试研究。大学通常需要伦理审批；公司也需遵循相关规范。

合规共享数据的要点如下：

  1. 联系被爬取网站获取许可
  2. 在发布时明确合适许可证
  3. 过滤/匿名化用户身份信息（在有身份风险时是必要环节）

标注的工程实践

先跑自动系统，再人工纠错可能增加错误，因为标注员过度信任自动系统，可能忽略系统错误。 例如句子 it was not not good 里双重否定容易被匆忙阅读忽略。

此外成本也可能上升：标注员既要做原本工作，还要检查系统输出。 如果自动系统准确率低，质量未必提升，成本却更高。

标注时另一个选项是编辑模型输出。 但这个模型通常来自既有工作、在其他数据上训练，因此在当前数据上可能不准，或存在特定错误模式，会把偏差带进来。

确定每条样本该配多少标注员可以在试标阶段决定。 若任务很难、常需多视角才能达成一致，就给每条样本配多个标注员。 多数数据集训练集每条样本仅 1 人标，测试集每条常 2 人或以上。 有一个例外，非常主观的任务（如判定社交媒体是否冒犯），有时每条会收集 10+ 标签，并发布完整标签分布而非单一真值，这类任务可能不存在唯一正确答案。

测试集通常每条收 2+ 标签是因为我们希望测试集很准确，多标签有助于发现错误和困难样本。

训练集通常每条只收 1 个标签是因为这样可以在同样成本下做更大的训练集。

假设我们要在文本分类项目中使用语言模型，可以根据标注数据的规模来选择不同的使用方式：

  • 没有标注数据（Text + Label）：用 Prompt 做 0-shot 预测。
  • 有几千条标注：做 ICL，并按与当前查询相似度选子集示例。
  • 有几百万条标注：在任务上微调 LM。另一种是不用这些标签数据，直接用 LM 生成 embedding，再喂给专用监督模型。

众包（Crowdsourcing）

众包是指把任务分解成小块，分发给大量人来完成的过程。 众包是获取训练数据的常见方式，尤其是当需要人工标注时。

众包可以有不同组织方式：

  • 微劳动（Microwork）：付费、小任务
  • 有益游戏（Games with a Purpose）：不付费，把任务做得有趣；或竞赛奖金
  • 公民科学/协作（Citizen Science / Collaboration）：不付费，可能有趣，也可能是成就感
  • 隐式劳动（Implicit Work）：不付费、不有趣，但有其他收益