Expose generation index to tool callables in GRPOTrainer

[lukehinds]

What does this PR do?

When using GRPOTrainerwith tools, the trainer generates multiple completions per prompt (num_generations), then executes tool calls for each completion via _tool_call_loop. However, tool callables have no way to know which completion triggered them.

The fix exposes the completion index to tool callables by inspecting each tool's signature at initialization and caching whether it accepts a _completion_idx parameter. During tool execution in _tool_call_loop, if a tool declares this parameter, the trainer passes the current completion index; otherwise it calls the tool normally. This allows tools to know which of the multiple generated completions triggered them, enabling per-completion attribution for reward functions without breaking existing tools that don't need this information.

Fixes #4866

Before submitting

• Did you read the contributor guideline,
  Pull Request section?
• Was this discussed/approved via a GitHub issue? Please add a link
  to it if that's the case.
• Did you make sure to update the documentation with your changes?
• Did you write any new necessary tests?

Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

[lukehinds]

hi @qgallouedec do you have enough info to review this now? happy to jump on discord and chat through or fill in any more details on the original issue. I believe its a low risk change as the code is only leveraged when the parameter is passed, so existing users will not be impacted.

[lukehinds]

How to get a review folks, I know you have a lot of work - so I am happy to help in anyway if more context is needed.

[qgallouedec]

Hi, and sorry for the late reply.

I understand your use case, and I agree that adding the index as you suggested would technically solve the issue. However, since reward functions are not meant to depend on the index, I don’t want to allow that. It would essentially encourage a workaround that goes against the intended design.

That said, I’ve been working on an alternative solution that I believe should work perfectly for your case: environment support. You can take a look here: #5093.

The idea is that tools are called within the context of a class (method instead of function), which makes it possible to maintain any state for reward computation in a clean and intended way.