【Hackathon 9th Sprint No.60】【RFC】为 FastDeploy 新增支持 DeepSeek 模型的 Reasoning Parser & Tool Parser #1185
Conversation
…ning Parser & Tool Parser
|
|
|
请问是哪里有问题吗，一直没消息欸 |
LiqinruiG
left a comment
LiqinruiG
left a comment
There was a problem hiding this comment.
感谢您对 FD 的关注和参与， 文稿写的十分详细，对Reasoning Parser 和Tool parser 的理解也十分到位。 为了保障后续解析逻辑有章可查，并使得Review过程更加顺畅，可以提前再细化一下解析方案。 同时，也和您同步一下，接下来思考机制在架构上会做的一个变更（参考上面评论），可以按照该方式进行开发，避免增加后续适配工作。
| <tool_call> | ||
| {"name": "get_weather", "arguments": {"location": "上海"}} | ||
| </tool_call> | ||
| ``` |
There was a problem hiding this comment.
下面文档有提到 <｜tool▁calls▁begin｜> ， 可以类似上面的思考输出， 再做进一步调研， 确认不同模型的工具输出协议是不是有差异，以做不同的解析方案。
https://github.com/vllm-project/vllm/blob/main/vllm/entrypoints/openai/tool_parsers/deepseekv31_tool_parser.py
| 这是最终的回复内容 | ||
| ``` | ||
|
|
||
| **特点**： |
There was a problem hiding this comment.
可以再进一步调研 DeepSeek 在不同模型版本上的的思考输出方式， 总结成一段结论。
例如，如果模型支持思考开关， 开思考时模型可能不会再输出<think>了； 而在不支持思考开关的模型，可能会输出<think>..</think>
| | 情况 | 处理策略 | | ||
| |-----|---------| | ||
| | 完全没有推理标记 | 将整个输出作为 content | | ||
| | 只有 `</think>` 没有 `<think>` | 将结束标记前的内容作为 reasoning | |
There was a problem hiding this comment.
根据这两句的判断， 在流式情况， 如果收到的前几个 token (没有 的情况)， 是没有办法判断这些 token是content 还是 reasoning_conten 的哦
| </tool_call> | ||
| ``` | ||
|
|
||
| # 三、设计思路与实现方案 |
There was a problem hiding this comment.
基于现在FD 架构，下面的实现方案是没有问题的。但此处即将会有个思考机制架构调整，需要和您同步一下：
背景: 不同模型对思考开关的参数定义不统一、默认参数不统一，用户输入的或chattemplate拼接后的 prompt 灵活。架构上需要感知模型的输出是处于思考阶段还是回复阶段等。同时 reasoning_parser 和 tool_call_parser 从严格解析逻辑上来看，也需要感知模型输出所处的阶段。 因此，在实现过程中增加了如下设计：
- reasoning_parser 需要提供一个方法： 根据进入模型的 prompt_token_ids，判断接下来模型输出在哪个阶段（不同模型，识别方式可能会不一样）
- 解析方法中，会增加一个 模型输出所处阶段的参数（不是实时的，可以辅助对首token进行判断）。
- 无论思考开关是打开还是关闭，输出后处理过程都会统一调用 parser， 由parser 根据实际情况进行判断要返回的内容。
可以参考PR(预计28号前可以合入): [Feature]Optimization of Thinking Pattern Framework FastDeploy#4302
| | 只有 `</think>` 没有 `<think>` | 将结束标记前的内容作为 reasoning | | ||
| | `</think>` 后立即是 `<tool_call>` | content 为空，由 Tool Parser 处理 | | ||
| | 多个 `</think>` 标记 | 只识别第一个 | | ||
|
|
There was a problem hiding this comment.
对于具体执行方案，给一个以下建议：
根据不同模型输出协议的差异制定不同的执行方案（Review 的时候，也会与方案进行对齐）。
首先，列举模型，正常返回是的协议情况， 例如（不一定是 Deepseek 模型的示例）
有调用工具意图的时候：reasoning_content</think>\n\n<tool_call>xxx</tool_call><tool_call>xxx</tool_call></s>
无调用工具意图的时候：reasoning_content</think>content</s>
其次，制定在不同输出场景的处理方案， 例如：
- 未出现
</think>场景， 如：ABCD；
- 如果模型处于思考开始阶段，这些应该是异常结果，会被解析到思考内容中；
- 如果模型处于思考结束阶段，这些应该是回复内容
- 未出现<tool_call>， 如
ABCD </think> EFG
- （不再详细列举）
- 出现
<tool_call>, 但与</think>之间有 非\n字符，如ABCD </think>\nEFG\n<tool_cal>XXX</tool_call>
- 视为异常情况
- 考虑流式过程遇到 EFG时， 会当做 content 内容， 因此，当前情况后续可以都作为 content 内容， 不去做工具解析（tool_call_parser 要做该情况判断，跳过解析）。
- 出现
<tool_call>, 且与</think>之间仅有\n字符， 如ABCD </think>\n\n<tool_cal>XXX</tool_call>
- 视为正常情况， 流式过程遇到
<\think>后面的\n，可以考虑忽略。 - content 内容与 tool_call 内容，保持互斥。
- 多工具解析时，
</tool_call>与下一轮的<tool_call>之间有非\n 字符时， 可以忽略，如ABCD </think>\n\n<tool_cal>XXX</tool_call>\nXYZ\n<tool_call>XXX</tool_call> - 工具解析逻辑<tool_call>与</tool_call>之间任一个内容不合法时....
还可以进一步考虑非思考模式下，思考和工具的解析方案。
5 participants
…ning Parser & Tool Parser