[Feature] Make PPO compatible with composite actions and log-probs

[vmoens]

Stack from ghstack (oldest at bottom):

• -> [Feature] Make PPO compatible with composite actions and log-probs #2665

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/rl/2665

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 10 New Failures, 8 Unrelated Failures

As of commit 3caa87c with merge base d009835 ():

NEW FAILURES - The following jobs have failed:

• Continuous Benchmark (PR) / CPU Pytest benchmark (gh)
  Process completed with exit code 1.
• Continuous Benchmark (PR) / GPU Pytest benchmark (gh)
  Process completed with exit code 1.
• SOTA Tests on Linux / tests (3.9, 12.1) / linux-job (gh)
  RuntimeError: Command docker exec -t 98c77bff7350d0ff2ecff178a301cfe7d7d0fc3440b1073d28bc9b29886bd01f /exec failed with exit code 1
• Unit-tests on Linux / tests-cpu (3.10) / linux-job (gh)
  test/test_cost.py::TestPPO::test_ppo_value_clipping[False-clip_value4-KLPENPPOLoss-device0]
• Unit-tests on Linux / tests-cpu (3.11) / linux-job (gh)
  test/test_cost.py::TestPPO::test_ppo_value_clipping[False-clip_value4-KLPENPPOLoss-device0]
• Unit-tests on Linux / tests-cpu (3.12) / linux-job (gh)
  test/test_cost.py::TestPPO::test_ppo_value_clipping[False-clip_value4-KLPENPPOLoss-device0]
• Unit-tests on Linux / tests-cpu (3.9) / linux-job (gh)
  test/test_cost.py::TestPPO::test_ppo_value_clipping[False-clip_value4-KLPENPPOLoss-device0]
• Unit-tests on Linux / tests-cpu-oldget (3.12) / linux-job (gh)
  test/test_cost.py::TestPPO::test_ppo_value_clipping[False-clip_value4-KLPENPPOLoss-device0]
• Unit-tests on Linux / tests-optdeps (3.11, 12.1) / linux-job (gh)
  test/test_cost.py::TestPPO::test_ppo_value_clipping[False-clip_value4-KLPENPPOLoss-device0]
• Unit-tests on Linux / tests-stable-gpu (3.10, 11.8) / linux-job (gh)
  test/test_cost.py::TestPPO::test_ppo_value_clipping[False-clip_value4-KLPENPPOLoss-device0]

FLAKY - The following job failed but was likely due to flakiness present on trunk:

• Build Windows Wheels / pytorch/rl / upload / wheel-py3_9-cuda12_4 (gh) (similar failure)
  Unable to find any artifacts for the associated workflow

BROKEN TRUNK - The following jobs failed but was present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• Build Windows Wheels / pytorch/rl / upload / wheel-py3_9-cpu (gh) (trunk failure)
  Unable to find any artifacts for the associated workflow
• Build Windows Wheels / pytorch/rl / upload / wheel-py3_9-cuda11_8 (gh) (trunk failure)
• Build Windows Wheels / pytorch/rl / upload / wheel-py3_9-cuda12_6 (gh) (trunk failure)
  Unable to find any artifacts for the associated workflow
• Habitat Tests on Linux / tests (3.9, 12.1) / linux-job (gh) (trunk failure)
  AttributeError: _ARRAY_API not found
• Unit-tests on Linux / tests-gpu (3.11, 12.1) / linux-job (gh) (trunk failure)
  test/test_loggers.py::TestMLFlowLogger::test_log_video[steps1]
• Unit-tests on Linux / tests-olddeps (3.8, 11.6) / linux-job (gh) (trunk failure)
  test/test_storage_map.py::TestMCTSForest::test_forest_parent[simple-False]
• Unit-tests on Windows / unittests-cpu / windows-job (gh) (trunk failure)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[vmoens]

In this PR, I propose to let PPO have series of actions defined in the in-keys (rather than a single one) to accomodate CompositeDistributions better.

This PR requires pytorch/tensordict#1146 and pytorch/tensordict#1145 to be merged or checked out.

Here is a demo:
https://gist.github.com/vmoens/46175764240dcbaf311af562b9e53294

cc @matteobettini

[matteobettini]

Cool!

Just to understand a bit, how is this related to multiagent?

I see in the example that you are using different agent groups, but the feature seems to be more suited for composite single-agent actions.

In multiagent, the suggested way to do things was to create a different loss for each group. This is to avoid losses taking a list of dones, rewards, and actions and have to match them.

I think this feature for me makes sense for composite actions within a single-agent or a single marl group (avoiding taking a list of rewards and dones).

[matteobettini]

Also in the example you are using a single module to output actions for multiple groups.
I think also here the way we suggest to do things is to process different groups in different modules, so that each module can go to its loss.

[vmoens]

I don't have a strong feeling RE multiagent or not, the use case that was suggested to me here had a composite action space where each leaf was labelled "agent_x"
I guess that long term there's a version of this where you could have one loss for all, since tensordict now supports arithmetic ops you could perfectly do

log_prob = make_some_tensordict(...)
prev_log_prob = make_some_tensordict(...)
advantage = make_a_tensordict_or_a_tensor(...)
loss = (log_prob - prev_log_prob).exp().clamp(...) * advantage

and your loss will be a tensordict itself.
This would probably break now but I do think we could actually get this to work and simplify the code at the same time (that will require deprecating some default behaviours in CompositeDistribution in v0.9 as announed in tensordict)

[matteobettini]

This makes sense for a composite action space yes. But in your PR i see you are also allowing lists of dones and rewards.

This is a bit less trivial as it opens up to a bunch of compatibility usecases if you want to use this in MARL.
The done and reward keys might not be a one to one mapping to actions:

• groups can have composite actions
• reward and done could be partially or totally shared across groups (each in a different way possibly)

Supporting all these usecases might become a big headacke which is why I preferred to stick with one reward and done key per loss class.