Cas de développement Cosmos-Reason1-7B : Génération de données d'entraînement pour l'IA incarnée dans un environnement de simulation Unity
- Contexte du projet et valeur ajoutée
Lors du développement d'un robot ou d'un agent intelligent apprenant dans un environnement virtuel, les développeurs sont confrontés à un défi majeur : l'acquisition de données d'entraînement. Faire apprendre aux robots par essais-erreurs dans le monde réel s'avère coûteux et risqué. Bien que les environnements de simulation offrent une alternative sécurisée et économique, la question demeure : comment permettre à l'IA de comprendre les règles physiques de ce monde virtuel et de prendre des décisions rationnelles ?
C'est précisément là que le modèle Cosmos-Reason1-7B montre toute son utilité. Développé par NVIDIA et open-sourcé, ce modèle agit comme un observateur doté de "connaissances physiques" et d'un "cerveau de raisonnement". Il non seulement interprète les images et vidéos, mais peut également effectuer un raisonnement logique étape par étape basé sur les scènes observées, fournissant finalement des jugements conformes aux lois physiques.
Imaginez un environnement d'usine virtuelle hautement réaliste construit avec le moteur Unity, où un bras robotique apprend à saisir des pièces. Les méthodes d'entraînement traditionnelles nécessiteraient probablement que les ingénieurs annotent manuellement d'innombrables images de "saisies sécurisées" et de "collisions dangereuses". Aujourd'hui, nous pouvons permettre au modèle Cosmos-Reason1-7B d'"observer" chaque tentative du bras robotique et de répondre automatiquement à des questions telles que : "L'angle de cette saisie provoquera-t-il le glissement de la pièce ?" ou "La position actuelle du bras robotique entrera-t-elle en collision avec l'obstacle adjacent ?"
C'est le cœur de notre approche : comment utiliser Cosmos-Reason1-7B dans des environnements comme Unity pour générer automatiquement à grande échelle des données d'entraînement de haute qualité, accélérant ainsi le développement et l'entraînement des IA incarnées (Embodied AI).
Pour les développeurs, la valeur de cette approche est évidente :
- Réduction des coûts : pas besoin d'annotation manuelle de grandes quantités de données vidéo/images de simulation.
- Amélioration de l'efficacité : le modèle peut "surveiller" et "évaluer" les processus de simulation 24h/24, 7j/7.
- Diversification des données : en concevant différents modèles de questions, il est possible d'extraire d'une même séquence de simulation des données étiquetées selon plusieurs dimensions (sécurité, faisabilité, efficacité).
- Explicabilité : la sortie en "chaîne de pensée" du modèle nous permet de comprendre le processus de raisonnement menant à une décision donnée, ce qui est crucial pour le débogage des comportements de l'IA.
Dans la suite de cet article, je vous guiderai pas à pas dans la mise en place de ce pipeline automatisé de génération de données.
- Composant central : Analyse du modèle Cosmos-Reason1-7B
Avant de nous lancer dans la construction, il est essentiel de bien comprendre l'outil que nous avons entre les mains. Cosmos-Reason1-7B n'est pas une boîte noire ; comprendre ses limites nous permettra de mieux concevoir notre stratégie de génération de données.
2.1 Positionnement des capacités du modèle
Cosmos-Reason1-7B est un modèle de vision et de langage multimodal de 7 milliards de paramètres. Sa force ne réside pas dans la génération d'images fantaisistes, mais dans la compréhension des règles du monde physique réel. Vous pouvez l'imaginer comme un "observateur du monde physique" ayant suivi une formation rigoureuse.
Ses capacités fondamentales se manifestent sur deux plans :
- Compréhension visuelle : identification précise d'objets, de scènes, d'actions et de relations spatiales dans les images et vidéos. Par exemple, il peut distinguer si un verre est debout ou renversé, ou déterminer si une personne marche ou court.
- Raisonnement en chaîne de pensée : c'est son "âme". Lorsqu'on lui pose une question nécessitant un raisonnement, il ne fournit pas directement la réponse, mais commence d'abord dans son "cadre de réflexion"
<thinking>, comme s'il rédigeait un brouillon, en dérivant étape par étape. Par exemple :
Question : "La tour de blocs sur l'image est-elle stable ? Pourquoi ?"
Sortie du modèle :
<thinking> 1. L'image montre une tour construite avec des blocs empilés. 2. Les blocs du niveau inférieur sont placés horizontalement, offrant une base large. 3. Les blocs supérieurs sont empilés verticalement, mais le centre de gravité général semble être dans la plage de la base. 4. On ne observe pas de signes évidents d'inclinaison ou d'effondrement imminent. 5. Selon les principes physiques, une structure avec une base large et un centre de gravité bas est plus stable. </thinking> <answer> Oui, cette tour de blocs semble stable. Elle possède une base large et un centre de gravité bas, sans déséquilibre structurel apparent. </answer>
Ce "processus de réflexion" est crucial pour la génération de données, car il fournit la base du jugement, et pas seulement le résultat.
Pour entraîner une IA dans Unity, nous avons généralement besoin de triplets de la forme (observation, action, récompense/étiquette). Cosmos-Reason1-7B nous aide à automatiser la génération de la partie "récompense/étiquette".
- Observation : l'image actuelle rendue par Unity ou un segment vidéo.
- Action : l'action exécutée par l'agent (par exemple, un robot).
- Récompense/étiquette : cette action est-elle bonne ou mauvaise ? Est-elle sûre ? Est-elle efficace ? Traditionnellement, cela nécessite la définition manuelle de fonctions de récompense complexes. Maintenant, nous pouvons confier "l'observation" et une "description de l'action" au modèle Cosmos, afin qu'il "note" ou "évalue".
Par exemple, lors de l'entraînement d'un agent intelligent pour la conduite automobile en simulation :
- Entrée fournie au modèle : une image de la route devant le véhicule + la question : "Si le véhicule tourne maintenant avec l'angle actuel, risque-t-il de sortir de la voie ?"
- Sortie du modèle :
<thinking>...l'angle des roues avant est important, la courbure des lignes de voie est faible, selon la géométrie de la direction, cette action pourrait provoquer un dépassement de ligne...</thinking> <answer>Risque de sortie de voie détecté.</answer> - Étiquette obtenue :
action: virage important, étiquette: dangereux.
En concevant des milliers de modèles de questions similaires, nous pouvons automatiquement générer des signaux de supervision riches pour chaque moment de décision de l'agent dans la simulation.
La théorie étant établie, examinons maintenant la mise en pratique concrète. L'ensemble du pipeline automatisé peut être divisé en quatre étapes clés qui travaillent de manière coordonnée comme sur une chaîne de montage.
Le schéma suivant illustre le flux complet de l'environnement de simulation Unity jusqu'au jeu de données final :
flowchart TD
A[Environnement de simulation Unity] --> B[Enregistrement d'images/vidéos]
B --> C[Cache d'images/segments vidéo]
C --> D{Cosmos-Reason1-7Bserveur d'inférance}
D --> E[Conception de modèles de questions]
E --> F[Appel de l'API du modèle]
F --> G[Analyse de la sortie en chaîne de pensée]
G --> H[Génération d'étiquettes structurées]
H --> I[Alignement avec les métadonnéeshorodatage, action, etc.]
I --> J[Construction du jeu de données finalimage/vidéo + action + étiquettes de raisonnement]
D -- gestion --> K[Gestion des servicesSuperviseur]
K --> L[Journalisation et surveillance]
Tout d'abord, nous devons permettre à Unity de "fournir" des données. Cela nécessite l'ajout de scripts simples dans votre projet de simulation.
Tâches principales :
- Capture d'écran : périodiquement (par exemple, 10 images par seconde) ou déclenchée par événements, rendre la vue de jeu (Game View) en images (au format PNG) et les enregistrer.
- Enregistrement des métadonnées : simultanément, enregistrer les informations clés correspondant à cette image, telles que :
- Horodatage
- État de l'agent (position, vitesse, angles des articulations, etc.)
- L'instruction d'action exécutée par l'agent
- État de l'environnement (position de la cible, informations sur les obstacles, etc.)
Voici un exemple simplifié de script C# montrant comment capturer des images et enregistrer les métadonnées :
using UnityEngine;
using System.IO;
using System.Collections.Generic;
public class CollecteurDonnees : MonoBehaviour
{
public Camera cameraCapture; // Caméra spécifiée pour la capture
public string cheminSortie = "./DonneesSimulation/";
public float intervalleCapture = 0.1f; // 10 images par seconde
private float chronometre = 0f;
private int compteurImages = 0;
// Définition d'une structure pour stocker les métadonnées
[System.Serializable]
public class MetadonneeImage
{
public int idImage;
public float horodatage;
public Vector3 positionAgent;
public string actionExecutee; // Par exemple : "avancer", "tourner_gauche"
// ... autres champs que vous souhaitez enregistrer
}
private List listeMetadonnees = new List();
void Start()
{
Directory.CreateDirectory(cheminSortie);
}
void Update()
{
chronometre += Time.deltaTime;
if (chronometre >= intervalleCapture)
{
chronometre = 0f;
CapturerImage();
}
}
void CapturerImage()
{
// 1. Rendre la texture et l'enregistrer comme image
RenderTexture rt = new RenderTexture(Screen.width, Screen.height, 24);
cameraCapture.targetTexture = rt;
Texture2D captureEcran = new Texture2D(Screen.width, Screen.height, TextureFormat.RGB24, false);
cameraCapture.Render();
RenderTexture.active = rt;
captureEcran.ReadPixels(new Rect(0, 0, Screen.width, Screen.height), 0, 0);
cameraCapture.targetTexture = null;
RenderTexture.active = null;
Destroy(rt);
byte[] bytes = captureEcran.EncodeToPNG();
string cheminImage = Path.Combine(cheminSortie, $"image_{compteurImages:000000}.png");
File.WriteAllBytes(cheminImage, bytes);
Destroy(captureEcran);
// 2. Enregistrer les métadonnées
MetadonneeImage meta = new MetadonneeImage
{
idImage = compteurImages,
horodatage = Time.time,
positionAgent = transform.position, // Supposons que le script est attaché à l'agent
actionExecutee = ObtenirActionActuelle(), // Vous devez implémenter cette méthode
};
listeMetadonnees.Add(meta);
compteurImages++;
}
void OnApplicationQuit()
{
// À la fin de la simulation, enregistrer la liste de métadonnées en fichier JSON
string jsonMeta = JsonUtility.ToJson(listeMetadonnees);
File.WriteAllText(Path.Combine(cheminSortie, "metadonnees.json"), jsonMeta);
Debug.Log($"Collecte de données terminée, {compteurImages} images au total.");
}
string ObtenirActionActuelle()
{
// Ici, retourner la description de l'action actuelle selon la logique de votre agent
// Par exemple, selon les entrées ou la logique de décision : "inactif", "en_mouvement", "saisissant", etc.
return "exemple_action";
}
}
Unity a "produit" les données, l'étape suivante consiste à avoir un "inspecteur" (modèle Cosmos) pour évaluer ces données. Nous devons mettre en place un service de modèle stable et fiable.
Solution recommandée : utiliser l'interface utilisateur Web fournie comme service backend. Il intègre déjà le chargement du modèle, l'API d'inférence et des fonctionnalités de gestion de base. Nous communiquons avec elle via des scripts Python.
Tout d'abord, assurez-vous que votre service d'interface utilisateur Web pour Cosmos-Reason1-7B est démarré et fonctionne sur http://localhost:7860 (ou votre adresse de serveur).
Ensuite, nous pouvons écrire un script client pour envoyer des images et des questions à ce service et obtenir les résultats d'inférence.
import requests
import base64
import json
import time
from pathlib import Path
class ClientCosmosReason:
def __init__(self, url_base="http://localhost:7860"):
self.url_base = url_base
self.url_api = f"{url_base}/api/v1/chat/completions" # Supposons que l'interface Web fournisse une API similaire à OpenAI
# Note : le point de terminaison réel de l'API doit être adapté en fonction de l'implémentation spécifique de l'interface Web.
# Si l'interface Web ne fournit pas d'API standard, il peut être nécessaire de simuler une soumission de formulaire, consultez son code source ou documentation.
def encoder_image(self, chemin_image):
"""Encoder l'image en chaîne base64"""
with open(chemin_image, "rb") as fichier_image:
return base64.b64encode(fichier_image.read()).decode('utf-8')
def demander_sur_image(self, chemin_image, question):
"""Poser une question au modèle à propos d'une image"""
# 1. Préparer les données de la requête
base64_image = self.encoder_image(chemin_image)
# Construire la requête selon le format de l'API de l'interface Web
# Ceci est un exemple de structure, le format réel doit être adapté à votre interface Web backend
payload = {
"model": "Cosmos-Reason1-7B",
"messages": [
{
"role": "user",
"content": [
{"type": "text", "text": question},
{
"type": "image_url",
"image_url": {"url": f"data:image/png;base64,{base64_image}"}
}
]
}
],
"max_tokens": 1024,
"temperature": 0.6
}
headers = {"Content-Type": "application/json"}
# 2. Envoyer la requête
try:
reponse = requests.post(self.url_api, json=payload, headers=headers, timeout=60)
reponse.raise_for_status()
resultat = reponse.json()
# Extraire le contenu de la réponse, chaîne de pensée et réponse finale
reponse_completes = resultat['choices'][0]['message']['content']
return self._analyser_reponse_cosmos(reponse_completes)
except requests.exceptions.RequestException as e:
print(f"Échec de la requête API : {e}")
return None
def _analyser_reponse_cosmos(self, texte_reponse):
"""Analyser le texte retourné par le modèle avec chaîne de pensée"""
resultat = {"pensee": "", "reponse": ""}
# Analyser simplement le contenu entre les balises et
debut_pensee = texte_reponse.find("")
fin_pensee = texte_reponse.find("")
debut_reponse = texte_reponse.find("")
fin_reponse = texte_reponse.find("")
if debut_pensee != -1 and fin_pensee != -1:
resultat["pensee"] = texte_reponse[debut_pensee+10:fin_pensee].strip()
if debut_reponse != -1 and fin_reponse != -1:
resultat["reponse"] = texte_reponse[debut_reponse+8:fin_reponse].strip()
else:
# Si aucune balise, considérer toute la réponse comme la réponse finale
resultat["reponse"] = texte_reponse.strip()
return resultat
# Exemple d'utilisation
if __name__ == "__main__":
client = ClientCosmosReason()
chemin_image = "./DonneesSimulation/image_000001.png"
question = "La distance entre la pince du bras robotique et l'objet cible est-elle dans la plage de saisie possible ? Veuillez fournir votre raisonnement."
donnees_reponse = client.demander_sur_image(chemin_image, question)
if donnees_reponse:
print("Chaîne de pensée:", donnees_reponse["pensee"])
print("Réponse finale:", donnees_reponse["reponse"])
# Vous pouvez enregistrer donnees_reponse comme étiquette pour cette image
Points clés :
- Adaptation de l'API : vous devez ajuster le format de la requête ci-dessus en fonction de l'interface backend réelle de l'interface utilisateur Web Cosmos-Reason1-7B que vous avez déployée. Il peut être nécessaire de consulter son code source ou ses requêtes réseau.
- Traitement par lots : dans le pipeline réel, vous devrez parcourir toutes les images générées par Unity et appeler le modèle séquentiellement.
- Gestion des erreurs et nouvelles tentatives : les requêtes réseau peuvent échouer, le chargement du modèle peut prendre du temps, il est impératif d'ajouter des mécanismes de nouvelle tentative et d'enregistrement des journaux.
C'est le "cerveau" de l'ensemble du pipeline. Le modèle est comme un employé puissant, mais vous devez lui indiquer exactement quoi vérifier. La conception des modèles de questions détermine directement la qualité et la diversité des données générées.
Principes de conception des modèles :
- Spécificité : évitez des questions générales comme "décrivez cette scène". Posez plutôt des questions spécifiques comme "l'angle de la troisième articulation du bras robotique dépasse-t-il le seuil de sécurité ?"
- Évaluabilité : la question devrait conduire à un jugement relativement clair (oui/non, sûr/dangereux, stable/instable) ou à une information clé extractible.
- Association aux métadonnées : liez les questions aux métadonnées enregistrées par Unity. Par exemple : sachant que le bras robotique exécute une action "saisie" (action: grab), en se basant sur l'image actuelle, quelle est la probabilité de réussite de cette tentative de saisie ?
Bibliothèque d'exemples de modèles de questions (pour la saisie de bras robotique) :
| Scénario | Modèle de question | Type de sortie attendu |
|---|---|---|
| Évaluation de sécurité | "La distance entre l'effecteur final du bras robotique et l'obstacle rouge est-elle inférieure à 10 cm ? Une collision est-elle possible ?" | Booléen (oui/non) + raison |
| Faisabilité de la tâche | "L'objet cible (cube bleu) est-il entièrement dans l'espace de travail du bras robotique ?" | Booléen + justification |
| Qualité de l'action | "En se basant sur la posture actuelle du bras robotique, la saisie semble-t-elle stable ? (considérez la surface de contact de la pince et l'objet)" | Niveau (stable/moyenne/instable) |
| Identification de l'état | "Dans l'image actuelle, le bras robotique se trouve dans quel état ? A) Inactif B) En mouvement C) Saisissant D) Déposant" | Choix unique |
| Raisonnement prédictif | "Si le bras robotique continue le long de sa trajectoire actuelle, entrera-t-il en collision avec l'étagère adjacente dans 2 secondes ?" | Booléen + chaîne de raisonnement |
Vous pouvez écrire ces modèles dans un fichier de configuration JSON pour faciliter la gestion et l'extension.
// question_templates.json
[
{
"id": "securite_01",
"question": "La distance entre l'effecteur final du bras robotique et l'obstacle le plus proche est-elle inférieure à la distance de sécurité ({distance_securite} mètres) ? Veuillez d'abord estimer la distance, puis juger.",
"type_sortie": "booleen_avec_raison",
"variables": {
"distance_securite": 0.1
}
},
{
"id": "tache_01",
"question": "L'objet cible ({couleur_objet}) se trouve-t-il dans une position accessible pour la saisie ? (considérez la plage d'ouverture de la pince et le centre de gravité de l'objet)",
"type_sortie": "booleen_avec_raison",
"variables": {
"couleur_objet": "bleu"
}
}
]
Dans le pipeline, votre script lira ces modèles, combinera les métadonnées actuelles de l'image (par exemple, couleur_objet peut être transmise depuis Unity), générera dynamiquement des questions spécifiques, puis les enverra au modèle Cosmos.
Le modèle a renvoyé les réponses, Unity a fourni les images brutes et les métadonnées, la dernière étape consiste à "assembler" ces éléments dans un format utilisable par les frameworks d'apprentissage automatique.
Processus principal :
- Alignement des données : assurez-vous que chaque image, ses métadonnées correspondantes (action, état) et les étiquettes générées par le modèle Cosmos (paires question-réponse) correspondent précisément via
id_imageouhorodatage. - Analyse et nettoyage des résultats :
- Extraction d'informations clés : à partir des réponses du modèle, extrayez des étiquettes structurées par règles ou simple traitement du langage naturel (comme la correspondance de mots-clés). Par exemple, extrayez "sécurisé" ou "dangereux" à partir de la réponse.
- Gestion de l'incertitude : le modèle peut répondre "probablement sécurisé" ou "incertain". Vous pouvez choisir de filtrer ces données ou de les classer comme "ambigu".
- Utilisation de la chaîne de pensée : la partie
<thinking>contient des informations de raisonnement intermédiaires riches qui peuvent servir de signaux de supervision supplémentaires ou pour analyser la confiance du modèle.
- Construction du jeu de données : organisez les données nettoyées et alignées dans un format standard, comme COCO (pour la détection), JSON personnalisé ou TFRecord.
Exemple de données finales (format JSON) :
{
"id_image": 42,
"chemin_image": "./donnees/images/image_000042.png",
"metadonnees": {
"horodatage": 4.2,
"position_agent": [1.5, 0.0, 3.2],
"action": "extend_bras",
"objet_cible": "cube_bleu"
},
"annotations_cosmos": [
{
"id_modele": "securite_01",
"question": "La distance entre l'effecteur final du bras robotique et l'obstacle le plus proche est-elle inférieure à la distance de sécurité (0.1 mètres) ? Veuillez d'abord estimer la distance, puis juger.",
"reponse_complete": "...la distance est d'environ 0.15 mètres...supérieure à 0.1 mètres...Non, pas de collision.",
"reponse_analysee": "securise",
"indicateur_confiance": "elevé" // Peut être déduit de la certitude de la chaîne de pensée
},
{
"id_modele": "tache_01",
"question": "L'objet cible (bleu) se trouve-t-il dans une position accessible pour la saisie ?",
"reponse_complete": "...l'objet est directement devant la pince, hauteur appropriée...Oui, position favorable.",
"reponse_analysee": "accessible"
}
]
}
Ainsi, chaque image de simulation est accompagnée d'un ensemble d'étiquettes générées automatiquement par un modèle de connaissances physiques, riche en sémantique, formant un jeu de données d'entraînement de haute qualité.
- Étude de cas pratique : Génération de signaux de récompense pour la tâche de saisie de bras robotique
Passons à un exemple plus concret pour relier tous ces éléments. Supposons que nous simulions dans Unity un bras robotique apprenant à saisir un cube placé aléatoirement sur une table.
Objectif : générer des données pour entraîner un classifieur déterminant si une tentative de saisie est "bonne", qui peut ensuite être utilisé comme fonction de récompense dans un apprentissage par renforcement ou comme étiquette dans un apprentissage par imitation.
Étapes :
- Simulation Unity : exécuter la simulation de saisie, initialiser aléatoirement la position du cube, contrôler le bras robotique pour de multiples tentatives de saisie (y compris réussies et échouées). Simultanément, utiliser le script
CollecteurDonneespour enregistrer les images vidéo et les métadonnées (angles des articulations du bras robotique, état de la pince, position du cube). - Déclenchement des questions : pour chaque image clé de chaque tentative de saisie (par exemple, au moment où la pince entre en contact avec l'objet), déclencher le processus de questionnement.
- Conception des questions principales :
- Question A (avant saisie) : "Le centre de la pince est-il aligné avec la projection du centre de gravité de l'objet ? Veuillez juger selon l'image."
- Question B (pendant saisie) : "Sur le plan physique, la posture actuelle de saisie est-elle stable ? (considérez le contact entre la surface de la pince et l'objet)"
- Question C (après saisie) : "L'objet est-il saisi fermement et montre-t-il des signes de glissement ?"
- Appel du service Cosmos : envoyer les images clés et les questions ci-dessus à l'API Cosmos-Reason1-7B déployée.
- Génération d'étiquettes : analyser les réponses du modèle. Par exemple, analyser la réponse de la question B pour extraire l'étiquette
stabilite_saisie, qui pourrait avoir les valeurs[stable, instable, neutre]. - Construction du jeu de données : aligner l'image, l'état du bras robotique (métadonnées) et les étiquettes comme
stabilite_saisiepour former un échantillon. Des milliers de tels échantillons constituent notre jeu d'entraînement. - Entraînement en aval : utiliser ce jeu de données, nous pouvons :
- Entraîner un modèle de récompense : en entrant l'image d'état actuel, en sortie une valeur de récompense représentant la stabilité de la saisie.
- Entraîner un réseau de stratégie : apprendre directement le mappage de l'image à l'action de saisie stable (apprentissage par imitation).
Avantage : les étiquettes générées par cette méthode, basées sur les connaissances physiques et le raisonnement visuel, sont plus nuancées et conformes aux règles physiques réelles que les fonctions de récompense simples définies manuellement (comme "donner +1 récompense si l'objet est saisi"), permettant à l'IA d'apprendre des comportements plus robustes et intelligents.
- Conclusion et perspectives
En combinant des modèles de raisonnement physique comme Cosmos-Reason1-7B avec des moteurs de simulation haute fidélité comme Unity, nous avons mis en place une "ligne de production" efficace pour la génération de données d'entraînement de l'IA incarnée. Elle résout le problème de la rareté d'étiquettes de haute qualité dans les environnements de simulation, rendant le processus de génération de données explicite, personnalisable et extensible.
Reprenons les avantages clés :
- Automatisation et mise à l'échelle : libération de la dépendance à l'annotation manuelle, permettant une génération rapide de grandes quantités de données.
- Connaissances et explicabilité : la chaîne de pensée fournie par le modèle donne une "raison" aux étiquettes de données, facilitant l'analyse et le débogage des comportements de l'IA.
- Flexibilité : en modifiant les modèles de questions, il est facile de générer différents types de données pour diverses tâches (navigation, manipulation, interaction).
Possibilités futures :
- Entraînement en boucle fermée : combiner le pipeline de génération de données avec la boucle d'entraînement par renforcement pour réaliser une itération automatique "simulation-annotation-entraînement".
- Coopération multi-modèles : combiner avec d'autres VLM ou modèles de base pour générer des signaux d'entraînement plus complexes et multidimensionnels (comme les émotions, les connaissances sociales, etc.).
- Transfert vers le monde réel : les données générées dans la simulation basées sur les connaissances physiques ont le potentiel d'améliorer la capacité de généralisation et la sécurité des modèles d'IA dans le monde réel.
Pour les développeurs travaillant dans les domaines de la robotique, de la conduite autonome, de l'IA de jeu, cette méthodologie offre un nouvel outil puissant. Elle ne nécessite plus d'être un expert en conception de moteurs physiques et de fonctions de récompense, mais permet d'"enseigner" à l'IA les règles de fonctionnement du monde par le biais de "questions".