我的征尘是星辰大海。。。
The dirt and dust from my pilgrimage forms oceans of stars...
-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆
作者:黄教授
手机视频列表
大模型的深思熟虑
视频
音频
原始脚本
大模型的深思熟虑，83%输出预留，是工程铁律还是因题制宜？在讨论大模型编程或推理时，我们常陷入一个非黑即白的误区。 Context window 上下文窗口越长越好，能塞的内容越多越稳。 直到我在 VS Code 里看到 GPT 五点四那个惊人的83%输出预留。 以及你关于大独裁者电影里那个希特勒的神比喻，我才真正意识到大模型的深思熟虑不能一概而论，而是一场动态的输入与输出博弈。 一、两个极端的思维光谱大模型的思考过程，其实分布在一个连续的光谱上。 我们看看两个极端。 一、极致输入导向。 福尔摩斯与定理判定有些任务输入是绝对的核心。 比如你把福尔摩斯探案集的所有卷宗、现场证据、证词全部喂给大模型，让它做案情复盘。 或者给大模型抛出一个极其复杂的定理，一堆晦涩的前提条件和案例数据，让它去判断是否符合。 在这种情况下，背后的逻辑推理是一一对应的精准匹配。 模型只需要快速校验逻辑闭环，几乎不需要漫长的思考过程。 它就像一个读完了万卷书的学者，直接给出结论，对或者不对。 此时如果强行预留大量输出空间，反而是对计算资源的浪费。 二、极致输出导向。 哥德巴赫猜想与直觉判断有些任务，输出才是决胜的关键。 就像你说的哥德巴赫猜想，我只需要告诉你定义。 大于二的偶数都可以写成两个素数之和。 上下文可能就一两百字，但大模型要完成这个证明，可能需要输出几天几夜的思考过程。 逻辑推演、试错、归纳，每一步都必须通过 token 输出完成。 哪怕是一个简单的一一对应翻译，大模型也需要输出 token 来完成逻辑推理、语法校验。 没有充足的输出空间，他就无法完成，哪怕是最简单的逻辑闭环。 二、大独裁者的隐喻。 输出空间就是思考画布。 你提到的大独裁者片段简直是大模型思考机制的完美隐喻。 希特勒哐哐哐讲几分钟，代表海量的输入信息堆砌。 秘书只打两三个字，代表模型瞬间的脱口而出，浅度思考。 希特勒只说两三个字，代表极简的需求。 秘书疯狂打字打一两分钟。 代表模型背后漫长的、高密度的思考过程。 深度推理。 这个场景狠狠戳破了一个认知误区，我们想要的最终结果，几行代码，一句话结论。 背后是模型巨大的计算与思考成本，大量 token 三、上下文工程的核心真谛，预留是为了随时可能的爆发。 那么回到工程实践，为什么 VS Code 依然坚持83%的输出预留？因为编程和推理是高风险、零容错的场景。 虽然我们可以区分输入导向和输出导向的任务。 但在实际的工程开发中，我们无法预知模型在思考过程中会何时迸发灵感，何时发现漏洞，何时需要自我修正。 保底原则，哪怕是最简单的函数修改。 模型也需要输出 token 来完成逻辑校验、边界排查，避免截断。 一旦输出空间被输入内容挤占，一旦思考到关键环节被截断。 就是灾难性的断片，只能重来。 动态博弈，上下文调度系统的最高智慧，不是把输入塞满，而是在输入和输出之间动态博弈。 当检测到任务需要深度推理，如数学证明、架构设计时，它会进一步精简输入，为输出让路。 当检测到任务是海量数据归纳时，他会合理分配资源。 解语大模型的上下文工程，本质上不是一场容量竞赛，而是一场新型资源调度的艺术星星。 我们要做的。 不是非黑即白的强调输入多或输出多，而是在绝大多数通用场景下，始终为大模型的深思熟虑保留一块广阔的画布。 就像 VS Code 那样，即便只改几行代码，也预留83%的空间。 因为我们不知道模型为了这几行代码背后推演了多少步逻辑。 预留充足的输出 token 就是给大模型的思考留足了犯错、修正、逼近真理的余地，这才是工程化的底气。
修正脚本
大模型的深思熟虑，83%输出预留，是工程铁律还是因题制宜？在讨论大模型编程或推理时，我们常陷入一个非黑即白的误区。 Context window 上下文窗口越长越好，能塞的内容越多越稳。 直到我在 VS Code 里看到 GPT 五点四那个惊人的83%输出预留。 以及你关于大独裁者电影里那个希特勒的神比喻，我才真正意识到大模型的深思熟虑不能一概而论，而是一场动态的输入与输出博弈。 一、两个极端的思维光谱 大模型的思考过程，其实分布在一个连续的光谱上。 我们看看两个极端。 一、极致输入导向。 福尔摩斯与定理判定有些任务输入是绝对的核心。 比如你把福尔摩斯探案集的所有卷宗、现场证据、证词全部喂给大模型，让它做案情复盘。 或者给大模型抛出一个极其复杂的定理，一堆晦涩的前提条件和案例数据，让它去判断是否符合。 在这种情况下，背后的逻辑推理是一一对应的精准匹配。 模型只需要快速校验逻辑闭环，几乎不需要漫长的思考过程。 它就像一个读完了万卷书的学者，直接给出结论，对或者不对。 此时如果强行预留大量输出空间，反而是对计算资源的浪费。 二、极致输出导向。 哥德巴赫猜想与直觉判断有些任务，输出才是决胜的关键。 就像你说的哥德巴赫猜想，我只需要告诉你定义。 大于二的偶数都可以写成两个素数之和。 上下文可能就一两百字，但大模型要完成这个证明，可能需要输出几天几夜的思考过程。 逻辑推演、试错、归纳，每一步都必须通过 token 输出完成。 哪怕是一个简单的一一对应翻译，大模型也需要输出 token 来完成逻辑推理、语法校验。 没有充足的输出空间，它就无法完成，哪怕是最简单的逻辑闭环。 二、大独裁者的隐喻。 输出空间就是思考画布。 你提到的大独裁者片段简直是大模型思考机制的完美隐喻。 希特勒哐哐哐讲几分钟，代表海量的输入信息堆砌。 秘书只打两三个字，代表模型瞬间的脱口而出，浅度思考。 希特勒只说两三个字，代表极简的需求。 秘书疯狂打字打一两分钟。 代表模型背后漫长的、高密度的思考过程。 深度推理。 这个场景狠狠戳破了一个认知误区，我们想要的最终结果，几行代码，一句话结论。 背后是模型巨大的计算与思考成本，大量 token。 三、上下文工程的核心真谛，预留是为了随时可能的爆发。 那么回到工程实践，为什么 VS Code 依然坚持83%的输出预留？因为编程和推理是高风险、零容错的场景。 虽然我们可以区分输入导向和输出导向的任务。 但在实际的工程开发中，我们无法预知模型在思考过程中会何时迸发灵感，何时发现漏洞，何时需要自我修正。 保底原则，哪怕是最简单的函数修改。 模型也需要输出 token 来完成逻辑校验、边界排查，避免截断。 一旦输出空间被输入内容挤占，一旦思考到关键环节被截断。 就是灾难性的断片，只能重来。 动态博弈，上下文调度系统的最高智慧，不是把输入塞满，而是在输入和输出之间动态博弈。 当检测到任务需要深度推理，如数学证明、架构设计时，它会进一步精简输入，为输出让路。 当检测到任务是海量数据归纳时，它会合理分配资源。 解读大模型的上下文工程，本质上不是一场容量竞赛，而是一场新型资源调度的艺术。 我们要做的，不是非黑即白的强调输入多或输出多，而是在绝大多数通用场景下，始终为大模型的深思熟虑保留一块广阔的画布。 就像 VS Code 那样，即便只改几行代码，也预留83%的空间。 因为我们不知道模型为了这几行代码背后推演了多少步逻辑。 预留充足的输出 token 就是给大模型的思考留足了犯错、修正、逼近真理的余地，这才是工程化的底气。
back to top