Skip to content

Clarification request: Qwen enable_thinking setting used for reported ALFWorld results #90

Closed

Description

@yanan1116

Hi authors,

I have a question about the Qwen backend configuration used for the reported results, especially the ALFWorld numbers for Qwen3.6-35B-A3B or Qwen3.5–4B.

In the current released code, skillopt/model/qwen_backend.py appears to only send:

payload["chat_template_kwargs"] = {"enable_thinking": True}

when config.enable_thinking is true. When enable_thinking=false, the request does not explicitly send chat_template_kwargs={"enable_thinking": False}. In that case, the actual thinking behavior may depend on the vLLM server / model chat-template default.

Could you clarify:

  1. For the ALFWorld results reported in the paper for Qwen3.6-35B-A3B, was Qwen thinking mode enabled or disabled?

  2. If it was disabled, did your serving endpoint explicitly force enable_thinking=false, or was it controlled only by the SkillOpt client-side config?

  3. Would you recommend always sending chat_template_kwargs={"enable_thinking": false} when enable_thinking=false to avoid ambiguity across vLLM deployments?

I am asking because local runs can differ substantially depending on whether Qwen reasoning/thinking is enabled by default on the serving side. Explicitly clarifying this would help make the reported Qwen results easier to reproduce.

Thanks!

Activity

  1. yanan1116 commented on Jul 2, 2026

    @yanan1116
    Author

    raytrun could you take a look at this concern. thanks.

  2. Huangzisu commented on Jul 6, 2026

    @Huangzisu
    Contributor

    Hi Yanan (@yanan1116), sorry for the delay. Here is some clarification:

    1. After checking, our experiments on open-source models are all conducted with enable_thinking=false, that is, Qwen thinking mode is disabled in our reported experimental results.
    2. The serving endpoint is launched with default settings, and we send enable_thinking=false from client side.
    3. SkillOpt doesn't fundamentally prefer reasoning or not. I think it is a choice depending on the situation, a trade-off between performance and optimization budget (slower and more costly when more tokens are generated and evaluated). I think this should be a user-controllable parameter in the framework, and we will adjust our code and give clearer explanation on this afterwards.

    Thanks for your question! Also, we plan to conduct relevant experiments with Qwen thinking mode enabled to provide more reference for users — stay tuned!

  3. Huangzisu commented on Jul 21, 2026

    @Huangzisu
    Contributor

    Hi Yanan (@yanan1116) , here are the corresponding results with Qwen thinking mode enabled:

    Benchmark 4B No Skill 4B SkillOpt 35B No Skill 35B SkillOpt
    AlfWorld 0.4179 0.7537 0.5970 0.8209
    DocVQA 0.8930 0.9011 0.9251 0.9332
    OfficeQA 0.2384 0.3488 0.4477 0.4651
    SearchQA 0.7100 0.7486 0.7621 0.8157
    SpreadsheetBench 0.2071 0.2429 0.4143 0.4214

    Overall, the reasoning-enabled version generally performs better than the corresponding reasoning-disabled version. SkillOpt still works when we turn reasoning mode on. We do not tune training hyperparameters in these experiments. For better performance, we have multiple key training configs for user to explore. We may find a more suitable set of training hyperparameters for Qwen with reasoning mode enabled like we do when training neural networks.

    Regarding your specific question about ALFWorld, enabling thinking mode does not consistently outperform the non-thinking setting. One possible reason is that the ALFWorld task prompt explicitly requires the model to generate a think tag in its output, which may partially conflict with or interfere with the model’s native reasoning behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions