原创 孔某人 2025-03-06 18:56 北京
结构化是一种协议。
发现一直以来没有专篇讨论过这个话题，也正好叠加自己在这方面认知转变不久，所以来完整写一下。
0、前言
0.1、何为粗粒度结构化
首先得讨论什么是LLM输出中的结构化。现在有两类典型的结构化设计：
输出中的json、代码、xml、latex数学公式等等，其实tool use也属于此类，表现为一整块作为一个独立元素，经常有自己的语法要求等。
类似R1的think、answer两段式格式，或者是包含多个步骤划分的方式（目前没有广泛认知的案例）
前者是一个专门的话题，并非本文关注范围。而本文更多考虑后一种方式，这种结构化称为粗粒度结构化。
0.2、我的认知转变
在2023年就关注我的读者应该知道，我最初就是推崇尽量粗粒度结构化的。现在复盘一下，原因有2点：第一、之前靠这个思路成功过，历史惯性。第二、这个方式确实也符合不少人的直觉，分层设计在不少方面很常见，例如Hierarchical RL。
但这是我在过去半年中的一个明显的思路转变，我目前认为要减少非必要的粗粒度结构化。因为它短期并不可行，并不是说这条路做不出来，而是说它的成本太高，并且工作不能低成本scale到各种场景上。相对来说，尽量让各种内容都保持在非结构化的状态上更能scale，并且能够无损直接利用LLM模型基础设施的进展。苦涩的教训就是告诉我们这一点：尽量去依赖明显在未来会（最）快速改进的基础设施。不同路线上的差距可能是指数级的，最终导致只有能够借力最快速提升的基础设施的路线才能最终成功。
回顾过去2年，推崇粗粒度结构化路线的方式几乎毫无建树，ToT、GoT、XoT等早早就被提出，但最后都无法落地，被扫进历史的垃圾堆。XoT路线的唯一被验证可行的方案就是CoT，但CoT恰恰是其中不需要粗粒度结构化的方式，跟其他XoT并非一路。CoT的Thought和其他XoT的Thought并不是一个东西。
DeepSeek R1的技术报告一出，目前还是大道至简，不靠粗粒度结构化就可以继续快速提升。
1、必要的结构化
本文对于必要的结构化的标准是：
所有的结构化设计，都应该是为了与LLM之外的外部组件交互而存在的。结构化是一种协议。
这里的外部组件仍然需要解释：是指所有不依赖LLM直接生成token而可以生成文本、触发动作，或者是对于LLM输出结果进行后续处理的组件。包括不限于：
通过json schema限制来生成json
通过生成tool use json args来触发外部tool，并把结果写回文本。
生成think、answer的切分边界，可以让后续过程可以将这两部分文本区别对待。
生成Step或者Thought的边界，可以在推理过程中按粗粒度进行PRM校验，或者是进行MTCS。
所有的结构化设计应该都要被用到，没被用到的结构化都是非必要的。
以及其实目前还不常用，但未来可能会有的结构化也包括：
内嵌的公式直接调用计算器给出计算结果
对外置的memory进行读写
触发外部工具修改已经生成的context，例如剔除冗余内容、概括失败尝试。
2、关于Step/Thought划分
在粗粒度结构化中，有几个共识的思路，其中之一就是划分Step/Thought。
其实2023年的ToT、GoT、XoT等就是这个思路，尝试构建一个独立的Thought边界，然后基于Thought再加上图算法试图来改进。但问题是，学术界的方案基本上回避了在一般场景下如何设定Thought边界的问题，选择的demo问题都是自带非常结构化的状态的。
当然现在来看，这个Thought的边界划分是可以做的。人工在post-training数据中合成一些带有Thought边界的数据，然后再通过一些方式强化LLM模型输出Thought边界token的概率，总能得到一个结果。这个结果中Thought大概是有大有小，也很难做进一步处理，但从切分的角度上来说，总还是能做的。
然后有两个主要的问题，一个是如何评价一个Step/Thought状态，这实际上就是PRM（Process-supervised Reward Models）的职责。而我们现在知道，在通用场景中PRM很难预先做好。即使在有明确中间环节的场景中，如果限制的太死，不能犯错的话，模型也很难强化出自我审视和改错能力。以及如果限制必须经过的中间关键节点覆盖不全的话，可能会导致模型无法学出所有可行的路径，限制了模型的视野和能力。而在模型训练中，同步训练PRM的方式，也会遇到很多问题，例如reward hacking。所以DeepSeek R1才选择了现在的方案。
另一个问题是，如何判定两个Step/Thought状态是相同的。这个问题在大家熟悉的棋类游戏中是很简单的，所有棋类游戏的状态都是完全结构化的，而且不同的盘面基本上后续走势都不相同。但在LLM这边，虽然token序列空间也很大，但语义不同的序列数量其实没有那么多。特别是不少序列在语义上只有细节差异，并非完全相同，但大体意思又很接近。这些都给状态相同的判定带来了很大挑战。在这个方面，目前都没有什么很好的方式。即使是简单的新标签体系提取场景，这都是一个头疼的问题。
如果放弃判断两个不同路径上的状态是否相同，那么也就很难从别的路径中复用结果和计算量。而在LLM的大量输出采样过程中，语义重复的比例很大，这会导致很大的计算量浪费。另外这种方式也变得在成本和效果上并没有显著好于单纯的Self-Consistency或者Best-of-N。这就是为什么ToT、GoT、XoT等最后被人放弃的原因。
严格来讲这也并非完全无用，从一个状态生成下一个候选状态时，是可以采样多个结果，并从中筛选出语义差异较大的几个，再分别进行推理的，或者是在一个context中，让模型输出多个不同的方案，各自形成一个独立分支。这种方式相对于没有任何处理的多路采样，有希望提升在相同计算量下的采样到的语义多样性。但这种多样性增强也有成本，综合来看是否更好需要更精细的测算。
从OpenAI o系列模型的分步思考过程来看，它内部应该是有埋有Step边界的划分，可能也是想往这方面尝试。但我们对o1 pro mode和o3的了解太少，无法判断他们是否使用了这些方案。
3、关于语义单元切分
除了Step/Thought之外，剩下一个结构化方式是围绕着语义的，这条线大家的认知就更模糊一些，可大可小。小到具体的术语名词，类似于一个更大token；大到接近于人脑一次产生的一个想法。语义的这个思路也是更符合人的认知习惯的。
但这种方式在面对文本中各种内容时，遇到的各种情况会更多，例如：
一个长数学公式是否算一个语义单元？
一个1k的代码是否算一个语义单元？
在一个列表中，不同的项目之间的并列关系该如何表达，都放在一起算一个语义单元的话是否太大？
等等
这都让语义单元这个思路在开始落地时就面对一堆细节问题。这种方式带来的系统复杂度、规范化的工作量都很大，但没有多少实际能够直接产生价值的地方。
4、总结
经过上述讨论之后，我们可以看到，结构化都是有成本的，有的大有的小，有些看似可以定义清楚但很难定义的很清楚。所以有个直接推论就是，所有的结构化设计都应该是为了实现某个具体的目的而引入的。如果你不需要把think过程从答案中剥离，那么都不应该引入think小节的划分。这并不影响RL过程，RL过程可以适应任何回答格式template。QwQ-32B-Preview就没有设计think小节。
如果不能把多个路径上的结果组合在一起，或者能够回滚一部分回答，那么设计结构来划分整个回答文本并无必要。
反过来说，所有需要与外部打交道的系统，最好都应该进行一些结构化设计，而不是让外部工具再调用一个LLM来进行提取。仅当这两个LLM的成本差异巨大而在提取信息时的效果接近时除外。
当输出文本跨过结构化的部分与外部交互时，信息损失是难免的。所以应该是尽量减少输出在结构化和非结构化之间的切换次数，能用一个模型（或混合模型）生成一个更长的非结构化回答，就不要把它拆分成workflow上的多个顺序的节点。除非你有对于中间结果的校验方式或其他工具，而这其实就是PRM。当你有一个好的PRM的时候，应该设计配合这个PRM输入输出的结构化方案。
这样我们就有了另一个审视workflow的视角：如果两个节点之间没有PRM或其他外部工具的接入，那么随着模型成本的下降、context能力的增加，最终应该合并成一个节点。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请加微信，联系方式请点击 -> 联系方式。
本文于2025.3.6 首发于微信公众号和知乎，知乎链接：
https://zhuanlan.zhihu.com/p/28446641676
