你有没有这么一回这样的经历, 就是让人工智能一次给你三十个标题, 等导出来看的时候, 会发现它们仿佛是同一句话的三十种不同表述方式。

多数人这时会去责怪模型, 或者转头更改提示词, 将「要有创意」「不要重复」再度加重多说几遍。然而倘若你在提示词里写了「用 JSON 格式返回」, 那么问题或许既不在模型, 也不在你的创意表述, 而在于你为了便于解析而额外多写的那半句话。

一句格式要求，把 52 种答案压成了 36 种

该判断源自一篇论文, 这篇论文于7月20日提交, 其arXiv编号为2607.18476, 作者是Tapan, 标题直译过来的话, 是《结构化输出在44个语言模型上压垮了回答多样性》。

它有着十分干净清洁的做法, 研究者选取了一份已然存在预备好的测试集, 存在31个那种答案给予的空间广度极为宽阔极大范围的类别提示, 像那种处于宽泛随便随便随意随便说个词之类的完全没有绝对标准正确答案、无论说出什么内容都可视为正确的问题题类, 于44个模型之上开展一次运行操作, 接着又将同样一模一样的题目完全按照原本模样再次开展运行一遍, 而唯一仅有的区别之处在于于请求之中额外添加上用JSON格式予以返回这样的字样。

出现的情况是: 针对同一道「随便说个词」题目, 于正常对话之中, 41%的模型能够进行回答；当将其改成JSON形式输出时, 此比例提升至64%。除此之外, 整个模型池所给出的各不相同的答案, 由52种下降至36种。

在论文当中, 存在着另外一个能够更清晰地表明问题的指标, 平均惊异度从1.80小数位降低到了1.58小数位, 惊异度是信息论范畴里评判「一个答案究竟有多超乎人们预料」的量值, 数值越低的话, 那么就意味着模型越是在几个具备安全性的选项当中徘徊。

你没加约束，只是「说了一声」，压缩就已经发生了

写过这类代码的人员, 一般会对两种做法予以区分, 具体如下: 其一, 是于提示词当中, 态度谦逊客气地写上一句「请用 JSON 返回」；其二, 是调用 API 的参数, 促使系统在解码层面实施强制约束输出。前者被视作软要求, 而后者才被认定为真正严格的要求。

有关于论文的测试呈现出这样一点, 即增添了强制约束的情况之下, 相较于单纯在提示词里边去请求JSON的情形, 多出来了0.03 bits的压力。

大约近乎全部的压缩, 在你张开嘴巴索要 JSON 的那个时刻便早已完成了。约束层所做的事情少得可怜甚是微小至极几乎可以忽略不现了。你觉得你只不过单纯仅仅是顺便提出了一条建议而已, 可模型早就已然已经切换到另外的一整套应答形式和思维逻辑上去并且在稳稳运作不息了。

做法在国内的情形下, 会致使这件事情变得更为普遍。官方所给出到的JSON文档之中, 首要的要求便是需要在系统提示或者用户提示里面含有json这个词汇, 并且要给出期望达成的JSON格式示例。这并非属于可选择的项目, 而是若不按照此编写方式, 便极有可能无法获取到相应结果的强制性用法。那些依据官方文档规规矩矩去执行的人员, 在每一次进行调用操作的时候, 都在触发此种效应。

你或许会思索一下, 这有没有可能是国外模型所存在的问题呢。论文针对44个模型逐一绘制于一张图上, qwen、kimi、glm、ernie一个都未缺漏掉落。真的要是讨论收缩幅度这个方面, -v3.2这根线属于全图中最长的几根里面的, 从2.6 bits周边一路下降至1.3附近, 相较于0.22 bits的全局平均大出了好几倍额度；qwen3 - 235b同样处于收缩最为厉害的那一档范畴内。你每日都在使用的那几个, 恰恰是反应最为强烈显著的那几个。

论文当中存在一个具体程度达到了称得上好笑地步的例子, Fable 5 在自由对话里进行回答时那种（属于一种蓝色的情况）所占比例为 0%, 然而切换到 JSON 之后, 该比例变为了 100%, 44 个模型当中有 6 个出现了这种在统计方面具备显著特征的个体漂移现象, 另一组组内重采样所得到的数据是, JSON 使稳定聊天默认答案改变的比例达到了 53%, 超过了一半。

出问题的不是结构化本身，是 JSON 这一种格式

原帖作者给出了这样的建议, 那就是即便想要多样性的话, 也千万别去要求结构化的输出格式。而就在这个结论方面, 我仅仅只同意一多半。

因为论文把几种格式拆开测了，结果并不一致。

json压缩呈现为0., 具备的p值为0.0002；xml压缩是0., 其p值是0.002。这两者属于确定无疑的情况。然而yaml并不存在显著效应, csv同样不存在显著效应。更具趣味的地方在于, 仅仅要求模型将答案用方括号进行包裹, 多样性却反倒增长了0.。

我的判定是, 将创意类任务的输出格式由 JSON 换成 YAML, 除此之外别的一概无需更改, 多样性便回归了。那些坚持使用 JSON 的人, 是在为一种自己从未测试过的解析便利进行付出。

这句话我晓得会有人去反对, 并且反对的理由是能站得住脚的。那些编写agent以及后端管线的工程师会讲: JSON存在成熟的校验、类型约束, 差不多每种语言都具备解析库；YAML对缩进敏感, 其解析存在一堆歧义, 写个no都极有可能被当作布尔值false。在一条需要进行长期维护的生产管线当中去更换格式, 成本要远远大于多出来的那一点点多样性。

他们算的这个账没有错, 我只是想着说, 许多人根本就没有去算这个账, 仅仅是顺便用一下默认值, 在这儿默认值是存在代价的, 可这个代价先前没有人告知你。

再说得明白一些: 这个结论当下仅有这一篇论文支撑着。要是有人拿同一批提示运行一组 YAML 进行对照, 发觉 YAML 同样被压缩了, 我上面所说的那句判断就应当作废。

下次写提示词，先分清这个活要不要多样性

这个任务，我要的是发散还是收敛？

发散发散, 起标题, 想选题, 取名字, 编测试用例, 写广告文案，只要是「给我 N 个不一样的」这样的, 就把 JSON 摘掉, 换成 YAML, 或者干脆让它输出纯文本, 你多写十几行解析代码。

需收敛, 选取字段, 进行分类, 加以判断意图, 将非结构数据转化为表格。但凡本应有唯一正确答案的, 安心采用 JSON。压缩在此并非副作用, 而是助力。

要改的实际上是一种习惯性的认知, 我们默认输出格式仅仅关注东西如何被装, 和装的究竟是什么未曾关联, 这篇论文所阐述的是, 它会对装进去的内容予以改写。

你是否曾让人工智能一口气生成了一批事物, 随后却发觉它们看起来全都相差无几?