Nemo Gym Pivot Datasets

Référence de l'article

Cette skill opérationnalise PivotRL : créer des datasets pivot locaux à une étape à partir de trajectoires réussies, préférer les états à récompenses mixtes informatifs, et entraîner avec des récompenses locales basées sur un vérificateur plutôt que sur l'imitation exacte de trajectoires.

Vérification d'invocation

Utilisez cette skill quand la tâche est de transformer des trajectoires d'agent existantes ou des artefacts de rollout en dataset pivot Nemo Gym, ou de valider si une paire JSONL/config pivot peut être utilisée pour du RL local à une étape ou de l'évaluation.

Avant d'écrire un convertisseur, inspectez des lignes source représentatives et le serveur de ressources cible. N'assumez pas que les noms de champs source font contrat. Convertissez en reconstruisant les éléments sémantiques nécessaires au format de ligne Responses-style de Gym.

Flux de travail principal

1. Inspectez la forme des données source et comptabilisez les points de décision assistant candidats.
2. Identifiez les champs sémantiques nécessaires pour chaque pivot :

• contexte d'entrée de l'appel modèle avant l'action pivot
• outils disponibles à ce point de décision
• action assistant attendue
• cible récompense/vérificateur si elle est distincte de l'action démontrée
• provenance optionnelle telle que task id, source trajectory id, rollout id, uuid, depth, et métadonnées originales

3. Convertissez chaque point de décision accepté en une ligne JSONL pivot.
4. Générez ou mettez à jour la config Gym correspondante pour que le JSONL au format pivot soit utilisable directement.
5. Validez avec le validateur fourni et, quand disponible, les modèles de serveur de ressources Gym cible.
6. Écrivez des métriques qui facilitent l'inspection des lignes ignorées, types d'actions, noms d'outils, depth, et couverture de provenance.

Forme de ligne

Consultez references/row-contract.md lors de l'implémentation ou de l'examen d'un convertisseur. Pour single_step_tool_use_with_argument_comparison, les champs de ligne essentiels sont :

• responses_create_params: entrée style Responses API et spécifications d'outils pour l'appel modèle.
• expected_action: un function_call ou un message.
• agent_ref: routage au niveau de la ligne qui correspond à la config générée.

Ne copiez pas les champs optionnels null dans responses_create_params ; omettez-les sauf si le contrat cible les demande explicitement.

expected_action est singulier. Si un tour assistant source a plus d'un appel d'outil, filtrez ce tour hors du dataset pivot et conservez-le seulement dans un audit de lignes ignorées s'il a besoin d'examen.

Motifs de conversion

Consultez references/conversion-patterns.md quand les données source ne sont pas déjà au format pivot. La règle est de normaliser par le sens, pas par le conteneur source.

Des scripts de référence utiles se trouvent sous scripts/reference/. Ils sont copiés de vraies conversions et peuvent contenir des chemins spécifiques à des datasets, des hypothèses, ou un comportement de branche plus ancien, donc traitez-les comme des exemples à emprunter plutôt que des commandes canoniques à exécuter inchangées :

• generic_pivot_dataset_reference.py: lignes sources génériques vers lignes pivot.
• chat_messages_to_pivot_dataset_reference.py: messages de chat-completion vers lignes pivot.
• conversational_messages_to_pivot_dataset_reference.py: trajectoires de messages conversationnels vers lignes pivot avec gestion du raisonnement/provenance.
• tool_messages_to_pivot_dataset_reference.py: lignes style message/tool-use vers lignes pivot.

Sélection de pivot

Utilisez des trajectoires source propres et positives pour les pivots démontrés. Quand plusieurs trajectoires source existent pour une tâche, préférez les tâches dont le groupe de trajectoires source a des récompenses mixtes au lieu de tous succès ou tous échecs ; cela évite de dépenser des données sur des tâches qui étaient triviales ou impossibles pour le modèle source. Traitez ce filtre source-task comme préféré, pas obligatoire, car le modèle source et la politique en aval peuvent avoir des capacités différentes.

Quand possible, profilez les pivots candidats avec des rollouts on-policy locaux de la politique en aval ou initiale. Utilisez au moins 8 rollouts locaux échantillonnés par candidat comme défaut. Gardez les candidats avec récompenses locales mixtes, écartez les groupes reward tous-1 et tous-0, et si les données sont abondantes, supprimez les pivots les plus faciles/taux-de-réussite-élevé en premier pour que l'entraînement se concentre sur les états difficiles mais apprenables.

Config et entraînement

Consultez references/config-training-and-agent-ref.md lors de la création du YAML Gym ou de l'explication de comment entraîner/évaluer à partir du dataset.

Points clés :

• Le JSONL pivot est le dataset d'entraînement/éval ; pointez l'entrée train dataset de la config directement vers lui.
• agent_ref.name dans chaque ligne doit correspondre au bloc agent utilisé par la config sauf si le launcher surcharge le routage intentionnellement.
• word_count_similarity_threshold est le bouton principal d'appariement d'arguments string pour le vérificateur tool-use à une étape.
• Utilisez tool_choice: "auto" pour ces lignes ; tool_choice: "required" peut router certains moteurs d'inférence vers des chemins de décodage structuré.
• Validez configs et datasets ensemble ; un fichier JSONL valide peut toujours être inutilisable si les noms agent/resource-server ne s'alignent pas.

Validation

Exécutez le validateur fourni avant de déclarer un dataset pivot terminé :

python scripts/validate_pivot_dataset.py --path /path/to/pivot.jsonl --agent-ref expected_agent_name

Quand le repo Gym est disponible, validez aussi contre les modèles Pydantic du resource-server :

python scripts/validate_pivot_dataset.py \
  --path /path/to/pivot.jsonl \
  --agent-ref expected_agent_name \
  --gym-repo /path/to/Gym-github

Utilisez --require-field et --require-any-field uniquement quand un workflow spécifique à un dataset a besoin de vérifications de provenance supplémentaires. La provenance est utile pour le débogage et le filtrage, mais n'est pas requise par le modèle de requête du resource-server.

Le validateur accepte les deux types d'expected-action supportés par défaut (function_call et message) et affiche un résumé final divisé entre pivots tool-call et message.