Suggestions on code organisation

[lucasjinreal]

Hi, can you use verl as an importable dependency rather than copy all its code?
This is a similar behavior to many CV researchers who like to copy all mmxxx code to their project. It has some drawbacks:

1. It's hard to know which part was changed compared with the original verl package;
2. It's hard to maintain for users who want to try it;
3. It's hard to integrate with other models.
4. It's hard to catch up with the latest features from the official verl package (as far as I know, verl is actively maintained).

In my opinion, verl is relatively stable enough in its API. I think it can be used as a dependency and focus on the algorithms implemented by VisionThink.

[Yangsenqiao]

Hi @lucasjinreal 👋,
Thanks a lot for your thoughtful suggestion!

During our early experiments, verl didn't yet support multi-turn dialogue and Multimodal, which led us to copy and adapt the code for our use case. I'll revisit the latest version of verl soon to explore how we can better align with the official implementation and ideally treat it as a proper dependency.

The core idea behind VisionThink is straightforward: we first input downsampled images to save tokens. If the model deems the information insufficient, it will reprocess the full-resolution image in a second round.

Appreciate your attention and support for VisionThink!

[lucasjinreal]

@Yangsenqiao Thanks for your consideration!

I'd like to reference the RL part since rare projects consider adding general vqa training to grpo. I'd like to wait for your new version support as I think it could be much cleaner and can be easily adopted.