[RFC] 083 - 思考过程展示

[arvinxx]

背景

OpenAI O1、DeepSeek R1、Gemini Thinking 模型都开始内置 CoT，本 RFC 将研究如何将思考过程做用户体验友好的展示

• [Request] 支持 DeepSeek-R1 模型，及其思考过程的展示 #5528
• [Bug] 使用DeepSeek-R1 模型助手返回的信息顶部被轻微截断 #5530
• Gemini 也有 Thinking 的模型

设计思路

在之前的实现中，我们通过 model runtime 定义了一套自行封装的请求规范，因此针对 reason_content 的流式解析的处理会比较简单，通过 chunk 解析，将有 reasoning_content 的 chunk 解析成 {type:'reasoning', data: reasoning_content } 的格式即可。

export const transformOpenAIStream = (
  chunk: OpenAI.ChatCompletionChunk,
  stack?: StreamStack,
): StreamProtocolChunk => {
    // ... 其他实现

    const item = chunk.choices[0];

    // ... 其他实现

    // 无内容情况
    if (item.delta && item.delta.content === null) {
      // deepseek reasoner 会将 thinking 放在 reasoning_content 字段中
      if ('reasoning_content' in item.delta && typeof item.delta.reasoning_content === 'string') {
        return { data: item.delta.reasoning_content, id: chunk.id, type: 'reasoning' };
      }

      return { data: item.delta, id: chunk.id, type: 'data' };
    }

示例的测试用例：

lobe-chat/src/libs/agent-runtime/utils/streams/openai.test.ts

Lines 725 to 754 in bf2d848

	expect(chunks).toEqual(
	[
	'id: 1',
	'event: reasoning',
	`data: ""\n`,
	'id: 1',
	'event: reasoning',
	`data: "您好"\n`,
	'id: 1',
	'event: reasoning',
	`data: "！"\n`,
	'id: 1',
	'event: text',
	`data: "你好"\n`,
	'id: 1',
	'event: text',
	`data: "很高兴"\n`,
	'id: 1',
	'event: text',
	`data: "为您"\n`,
	'id: 1',
	'event: text',
	`data: "提供"\n`,
	'id: 1',
	'event: text',
	`data: "帮助。"\n`,
	'id: 1',
	'event: stop',
	`data: "stop"\n`,
	].map((i) => `${i}\n`),

然后对应在 fetchSSE 层对应加一个 smoothing 处理逻辑，往外抛: https://github.com/lobehub/lobe-chat/pull/5558/files#diff-9b2bf237e44d83c03957c853eb46aa4b0124858d612b6b3a21bc52a67c4f6934

最后在 chat store 层接住这个 type 的 chunk ，并且存到 reasoning json 字段中。

效果：

目前支持 Reasoning 的模型有：

• DeepSeek R1 （本次支持）
• Google Gemini Flash Thinking （ google sdk 还缺少配置能力：Need a config params of thinking google-gemini/deprecated-generative-ai-js#328 ）
• Ollama + DeepSeek R1，存在的问题是包裹在 <think> 标签中，虽然可以解决但是不如 DeepSeek 优雅
• GLM-Zero-Preview：输出内容不够结构化

[SAnBlog]

还有 GLM-Zero-Preview

[arvinxx]

有文档吗？我去看下

[SAnBlog]

有文档吗？我去看下

https://www.bigmodel.cn/dev/api/normal-model/glm-zero-preview

现在是公测限时免费,整体不如上面的三个

[arvinxx]

看了下 GLM-Zero-Preview 的输出应该不好兼容

[Sun-drenched]

以DeepSeek R1为例，推理模型会带来更多参数的启用和禁用，比如temperature、top_p、presence_penalty、frequency_penalty、logprobs、top_logprobs参数无效（似乎其他推理模型对temperature的敏感性和一般模型也有差异），同时新增控思维链的长度的参数（reasoning_effort）。o1也有类似需求（参考 #5063 #5407）
Qwen部分模型（等）支持以enable_search参数配置API侧联网搜索能力（参考 #5297 ）

鉴于以思考过程、联网搜索为代表的模型特殊能力（特性）发展，建议在实现思考过程展示时同时实现对模型（特殊）参数用户友好型配置（以及顺路把配置绑定到模型，增强灵活性）的支持。
比如将enable_search、reasoning_effort等关键参数配置项添加到输入框工具栏，模型不接受temperature配置项时，将原有的temperature配置项置于不可调整状态（同时给予用户友好提示）

更进一步的，由于不同提供商的模型以及同一提供商的不同类型模型（推理/非推理）模型对temperature等参数的敏感性不同（比如OpenAI的模型temperature虽然支持到0-2，但一般超过1就容易胡言乱语；deepseek官方temperature指引通用对话1.3，创意性任务1.5），建议将temperature绑定到模型。
类似的需求是，对于某些高价模型，用户可能有限制历史消息的个别需求（或者说临时需求，比如低价模型解决不了问题，在对话过程中切换模型），而不是遵循助手下前一模型默认设置。

当然这会导致助手默认设置和绑定到模型的参数冲突，所以建议参考 #2726 提供以temperature为基础参数的输出风格模式设置，将助手设置和不同风格下适合不同模型的temperature等参数统一起来。在助手设置侧，只需要设置该助手适合的输出风格，在模型的风格设置中绑定个性化temperature等配置。

[Sun-drenched]

至于思考过程，建议提供不显示/显示思维链的设置，以及在思维链token数超过一定限额后自动收起（并提供展示全部选项），避免思维链内容（一般来说对用户直接价值比较低）占用太多聊天界面空间。
从UI和用户友好的角度，由于思维链的存在，推理模型响应速度（指输出首个回答token用时）偏慢，也可以做一个动画（比如lobechat logo那个小人头脑子里喷出来那一团绚丽地翻涌）展示正在思考（比较适合不希望显示思维链的用户，如果想要看，可以在回答输出完毕后在回答开头提供展示思维链选项）

[arvinxx]

推理模型会带来更多参数的启用和禁用，比如temperature、top_p、presence_penalty、frequency_penalty、logprobs、top_logprobs参数无效（似乎其他推理模型对temperature的敏感性和一般模型也有差异），同时新增控思维链的长度的参数（reasoning_effort）

这个其实和是否是推理模型无关，更根本的问题应该是模型级别支持的参数有哪些，这个应该是模型自定义这部分要做的事情，单独会弄 RFC 来做。

类似的需求是，对于某些高价模型，用户可能有限制历史消息的个别需求（或者说临时需求，比如低价模型解决不了问题，在对话过程中切换模型），而不是遵循助手下前一模型默认设置。
当然这会导致助手默认设置和绑定到模型的参数冲突，所以建议参考 #2726 提供以temperature为基础参数的输出风格模式设置，将助手设置和不同风格下适合不同模型的temperature等参数统一起来。在助手设置侧，只需要设置该助手适合的输出风格，在模型的风格设置中绑定个性化temperature等配置。

去年的时候我们内部基本上已经讨论出一个比较好的解决方案了，今年会做出来，可以期待下，到时候应该能进一步达到最高的灵活度。

至于思考过程，建议提供不显示/显示思维链的设置，以及在思维链token数超过一定限额后自动收起（并提供展示全部选项），避免思维链内容（一般来说对用户直接价值比较低）占用太多聊天界面空间。
从UI和用户友好的角度，由于思维链的存在，推理模型响应速度（指输出首个回答token用时）偏慢，也可以做一个动画（比如lobechat logo那个小人头脑子里喷出来那一团绚丽地翻涌）展示正在思考（比较适合不希望显示思维链的用户，如果想要看，可以在回答输出完毕后在回答开头提供展示思维链选项）

以 DeepSeek 的 api 来说的话，CoT 的 token 还是需要展示的，不然就像现在这样会觉得等的很慢。

[Sun-drenched]

至于思考过程，建议提供不显示/显示思维链的设置，以及在思维链token数超过一定限额后自动收起（并提供展示全部选项），避免思维链内容（一般来说对用户直接价值比较低）占用太多聊天界面空间。
从UI和用户友好的角度，由于思维链的存在，推理模型响应速度（指输出首个回答token用时）偏慢，也可以做一个动画（比如lobechat logo那个小人头脑子里喷出来那一团绚丽地翻涌）展示正在思考（比较适合不希望显示思维链的用户，如果想要看，可以在回答输出完毕后在回答开头提供展示思维链选项）

以 DeepSeek 的 api 来说的话，CoT 的 token 还是需要展示的，不然就像现在这样会觉得等的很慢。

这一点还是应该如前文所说放到模型层面，因为deepseek会提供reasoning_effort参数来约束CoT（文档说了即将提供，估计年后），并不会总是很慢。如果很慢，也不一定要吐字出来，通过过程动画展示这一过程似乎会更友好一些。

[Sun-drenched]

推理模型会带来更多参数的启用和禁用，比如temperature、top_p、presence_penalty、frequency_penalty、logprobs、top_logprobs参数无效（似乎其他推理模型对temperature的敏感性和一般模型也有差异），同时新增控思维链的长度的参数（reasoning_effort）

这个其实和是否是推理模型无关，更根本的问题应该是模型级别支持的参数有哪些，这个应该是模型自定义这部分要做的事情，单独会弄 RFC 来做。

类似的需求是，对于某些高价模型，用户可能有限制历史消息的个别需求（或者说临时需求，比如低价模型解决不了问题，在对话过程中切换模型），而不是遵循助手下前一模型默认设置。
当然这会导致助手默认设置和绑定到模型的参数冲突，所以建议参考 #2726 提供以temperature为基础参数的输出风格模式设置，将助手设置和不同风格下适合不同模型的temperature等参数统一起来。在助手设置侧，只需要设置该助手适合的输出风格，在模型的风格设置中绑定个性化temperature等配置。

去年的时候我们内部基本上已经讨论出一个比较好的解决方案了，今年会做出来，可以期待下，到时候应该能进一步达到最高的灵活度。

在灵活度之余也建议提供锁死服务端一些配置的能力，比如LobeHub（付费计划）用户跑去AI provider那改模型能力，用不了就来报告bug的（ #5563）以及 #5537 的需求。

[arvinxx]

这一点还是应该如前文所说放到模型层面，因为deepseek会提供reasoning_effort参数来约束CoT（文档说了即将提供，估计年后），并不会总是很慢。如果很慢，也不一定要吐字出来，通过过程动画展示这一过程似乎会更友好一些。

看个效果，我觉得展示出来是有必要的，默认推理用时会达到10s + ，所以还是要流式出来让用户体感好一些的

were.mp4

在灵活度之余也建议提供锁死服务端一些配置的能力，比如LobeHub（付费计划）用户跑去AI provider那改模型能力，用不了就来报告bug的

嗯是的，这个会增强，未来也会进一步强化管理端的能力