摘要

  • AIPREF 词汇草案第 08 版明确规定：搜索类别优先于原本会落入 AI 训练或 AI 使用的活动。
  • 因而，search=y 可以与 train-ai=n 并存，但模型及其输出必须专用于选择资源、把用户送回资源原始位置的合格搜索活动。
  • 这一例外不涵盖通用模型训练、生成式摘要或其他 AI 产品，也不负责执行偏好或赋予偏好法律效力。
  • 草案首页明确声明，全文或其中任何部分都不代表工作组共识。

搜索许可不是训练许可的反义词

发布者说“可以搜索”，通常是在争取被发现；他说“不要训练”，通常是在限制内容进入更广泛的模型开发。现代搜索服务又可能训练排序、检索或相关性模型。若把三个词当作互不相干的开关，运营者无法判断搜索内部的模型处理究竟听哪一个信号。

9 月 14 日发布的 AIPREF 词汇草案第 08 版 给出了答案。草案把 AI 训练定义为利用一项资源改变生成式 AI 模型已经学习到的参数；AI 使用则指用户没有直接提供该资源时，把它送入生成式模型，而且这个类别不含训练。

搜索采取的是目的标准：主要目的必须是挑选资源，并把用户引向资源的原始位置。结果需要提供直接引用或链接，可以用片段帮助判断相关性，也可以为无障碍目的改变呈现；生成式摘要不属于这个类别。

在这道边界内，内部处理可以包括训练或使用 AI 模型。关键限制是，相关模型和输出只能用于符合搜索条件的用途。第 08 版随后明确写出，搜索类别会覆盖那些原本属于 AI 训练和 AI 使用的活动。因此，search=y 对专用于合格搜索的模型处理构成有限例外，即使一般偏好是 train-ai=n 或 ai-use=n。

第 07 版 已经允许搜索内部使用模型，但类别之间如何排序没有现在这样直接。官方版本对比 还显示，第 08 版新增 ai-use、生成式 AI 定义以及搜索优先条款。这改变的是组合信号的解释，不只是术语名称。

“否”优先只在同一类别内成立

草案另有一条“从严”规则：若同一类别存在多条适用声明，先看是否有 n；没有否定才采用 y；两者都没有就是未知。这条规则解决同一类别内部的冲突。搜索压过训练和使用，则是不同类别之间的单独规则。把两者混为一谈，会得出相反结论。

词汇使用 train-ai、ai-use、search 和 y、n 来序列化偏好。RFC 9651 提供结构化字段的底层表达方式，但它没有定义什么叫搜索，不会监督接收者，也不会自动产生许可或权利。

偏好如何附着到内容，由另一份草案处理。附着草案第 05 版 规定 Content-Usage HTTP 响应头和 robots 指令，其 Datatracker 页面 记录当前状态。传输渠道能让信号抵达，却不能证明爬虫读过它、正确计算过类别优先级，或把搜索模型同其他产品真正隔离。

隔离决定例外会不会变形。只用于挑选、排序并链接回原站的模型，可以落入当前搜索定义。若同一组参数后来服务于问答引擎、写作助手或通用训练库，就不能因为数据最初经过搜索抓取而获得许可。系统生成的摘要同样不因附带原文链接就自动成为合格搜索。

编辑意图提供解释，不提供授权

工作组邮件已经讨论过这个具体问题。Alissa Cooper 问，search=y 是否允许搜索应用训练或使用模型，只要最终呈现满足搜索条件。Martin Thomson 回应，这一理解正确，并指向澄清修改。

这些邮件能解释编辑者为什么加上优先条款，却不是表决或采纳记录。草案自己明确说，它的内容无论整体还是部分都不反映工作组共识。文件状态页、修订历史 与 AIPREF 章程 显示的是仍在推进的标准化工作。

边界也没有全部封闭。议题 249 仍在追问：用户只给出 URL 或引用时，能否算作直接提供资源，从而影响 ai-use 的归类。第 08 版关于模型分发时如何继续传递训练偏好的新段落，也被标记为有待工作组讨论。搜索例外写清楚了，并不等于整个分类体系已经稳定。

草案还承认，表达偏好不能保证对方遵守；接收者自行决定是否以及怎样执行，具体合同也可以覆盖机器可读偏好。文本不要求 IANA 采取行动，也不声称自己是安全机制。它此次最实际的进展，是把搜索许可中包含的内部模型处理公开成一项可讨论、可审计的治理选择。

来源