{"schema_version":"1.0","service":"Publicasta","type":"article","id":1126,"slug":"nvidia_auto_ontology_semantic_layer_agent_data_testing","title":"Auto Ontology de NVIDIA transforme les métadonnées d’entreprise en couche de contexte pour les agents — ce qui est prêt à être testé","excerpt":"Le projet Auto Ontology de NVIDIA, sous licence Apache-2.0, rend explicites définitions métier, lignage, relations et provenance pour fiabiliser les requêtes d’agents. Reste à vérifier l’adéquation de son déploiement et de ses identifiants avec une vraie plateforme data.","language":"fr","default_language":"en","canonical_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=fr","image":{"url":"https://publicasta.com/storage/projects/10/pages/1126/2026/11/6e65ded1-0370-47ab-a268-e5d402ff8ee0.webp","alt":"Visualisation éditoriale de métadonnées d’entreprise traversant un graphe sémantique vers un agent de données IA."},"publisher":{"id":10,"slug":"open_source_radar","name":"Open Source Radar","url":"https://publicasta.com/open_source_radar"},"author":{"name":"Anton R"},"published_at":"2026-11-04T13:52:27+00:00","updated_at":"2026-11-04T13:52:27+00:00","content_markdown":"## Ce que NVIDIA a publié et le rôle prévu de la couche d’ontologie\n\n ![Visualisation éditoriale de métadonnées d’entreprise traversant un graphe sémantique vers un agent de données IA.](https://publicasta.com/storage/projects/10/pages/1126/2026/11/6e65ded1-0370-47ab-a268-e5d402ff8ee0.webp)\n\n NVIDIA Auto Ontology se présente comme un framework Python sous licence Apache-2.0, conçu pour transformer les métadonnées d’entreprise en couche de contexte structurée pour les agents data. Son objectif n’est pas de remplacer un modèle de langage, une base de données ou un catalogue de données classique. Il s’intercale plutôt entre ces systèmes : il rassemble les informations sur les tables, les colonnes, les définitions métier, les relations, le lignage et la provenance, puis les organise afin qu’un agent puisse les utiliser pour interpréter une question et formuler une requête analytique.\n\n Cette distinction est importante, car un agent peut produire un SQL syntaxiquement valide tout en comprenant mal le sens métier de la demande. Une base de données peut contenir plusieurs versions des données de chiffre d’affaires, de clients, d’expéditions ou d’activité, chacune avec ses propres bornes temporelles et son responsable. Un modèle qui ne voit que les noms de tables et les descriptions de colonnes peut sélectionner un champ plausible sans savoir quelle définition a été certifiée, comment un indicateur est calculé ni quel système amont fait autorité. Auto Ontology vise à rendre ces liens explicites, plutôt que de les abandonner aux associations déduites par le modèle.\n\n Le dépôt décrit un framework capable de générer des ontologies d’entreprise à partir des métadonnées, ou de s’y connecter, et de réconcilier les définitions entre plusieurs systèmes. Concrètement, l’ontologie est une représentation lisible par une machine des concepts data de l’organisation et de leurs relations. Elle peut associer un terme métier à des structures de données physiques, relier des entités apparentées, préserver le lignage et conserver la provenance nécessaire pour comprendre l’origine d’une définition ou d’une relation. Le résultat ressemble davantage à une carte sémantique gouvernée qu’à un ensemble de documents récupérés pour alimenter un prompt.\n\n Auto Ontology expose aussi ce contexte par plusieurs interfaces. Le projet comprend une application web, une API, une interface en ligne de commande et une intégration MCP destinée aux environnements d’agents. Ces interfaces offrent différents points d’entrée vers un même flux de travail général : ingérer les métadonnées, construire ou examiner l’ontologie, puis rendre ses informations sémantiques accessibles aux applications qui doivent répondre à des questions sur les données. MCP est particulièrement pertinent pour les équipes qui testent déjà des agents capables d’utiliser des outils, car il permet à un environnement d’agent externe d’appeler des fonctionnalités reposant sur l’ontologie, au lieu d’intégrer tout le catalogue et tout le processus de raisonnement dans un prompt.\n\n L’architecture prise en charge sépare donc deux préoccupations. La première est l’environnement data de l’entreprise : bases de données, schémas, systèmes de métadonnées et définitions auxquels le projet se connecte ou qu’il ingère. La seconde est la couche d’ontologie et de raisonnement, qui interprète ces entrées et présente le contexte pertinent à un agent. Cette séparation est utile sur le plan opérationnel. Une couche d’ontologie peut décrire une source sans devenir elle-même la source, et elle peut aider un agent à parcourir plusieurs systèmes sans obliger chaque règle métier à être redécouverte à partir de la structure brute des bases de données.\n\n C’est aussi pourquoi Auto Ontology ne doit pas être évalué comme un simple produit de recherche vectorielle. La récupération sémantique peut faire partie de l’implémentation, mais la valeur annoncée du projet repose sur des relations structurées et des métadonnées, pas seulement sur la recherche de textes ressemblant à la question de l’utilisateur. Un index vectoriel peut retrouver une définition ; à lui seul, il n’établit pas si deux indicateurs sont équivalents, quel jeu de données est en amont ni comment un concept correspond à un chemin de jointure. Le modèle d’ontologie doit préserver ces liens afin que l’agent reçoive un contexte structuré et traçable.\n\n La même frontière distingue le projet d’un endpoint de modèle. Auto Ontology ne rend pas un agent fiable simplement en ajoutant une étape de génération supplémentaire. Sa contribution proposée est le contexte fourni au modèle : les définitions qu’il doit respecter, les entités qu’il peut relier, le lignage qu’il peut examiner et la provenance qu’il peut utiliser pour évaluer son niveau de confiance. La qualité de la réponse finale dépend toujours du modèle sous-jacent, des métadonnées disponibles pour l’ingestion, de la configuration du déploiement et de la qualité des propres définitions de l’organisation.\n\n Cela rend le projet intéressant comme composant d’ingénierie des données que l’on peut tester, plutôt que comme une promesse de correction sémantique automatique. Une équipe peut vérifier si un contexte fondé sur une ontologie modifie le comportement de l’agent sur un ensemble contrôlé de questions métier. Elle peut examiner si la requête générée utilise le concept certifié, suit une relation appropriée et conserve le périmètre attendu. Elle peut aussi évaluer si la réponse reste explicable : non seulement quelles lignes ont été renvoyées, mais pourquoi un jeu de données, une définition ou un parcours de lignage précis a été retenu.\n\n La première question pratique est donc plus ciblée que celle de savoir si Auto Ontology résout l’analytique d’entreprise. Il s’agit de déterminer si le framework peut rendre un agent existant plus sensible au vocabulaire et à la structure des données de l’organisation. Le projet de NVIDIA fournit les composants nécessaires à cette expérience — ingestion des métadonnées, construction de l’ontologie, accès sémantique via une API ou MCP, et interfaces d’exploitation du système — mais la preuve doit venir d’une évaluation limitée, menée sur des schémas et des réponses connus. La couche ontologique est le pont proposé entre les métadonnées brutes de l’entreprise et le raisonnement de l’agent ; reste à voir si ce pont améliore les réponses lorsque c’est le sens métier, et pas seulement la syntaxe SQL, qui détermine la bonne réponse.\n\n ## Le test utile : le sens métier peut-il améliorer les réponses de l’agent ?\n\n Le problème pratique auquel Auto Ontology est censé répondre n’est pas de savoir si un agent peut produire du SQL qui s’exécute. Il faut déterminer si la requête représente bien la question métier. Une colonne appelée `revenue` peut ne pas fournir assez d’informations pour indiquer à l’agent quelle définition utiliser ; une table de clients peut décrire des comptes, des entités de facturation ou des utilisateurs finaux. Le résultat peut alors être syntaxiquement valide, numériquement plausible, mais sémantiquement faux. NVIDIA présente Auto Ontology comme un moyen de fournir aux agents un contexte explicite avant l’interrogation, notamment des termes métier associés à des colonnes, du SQL validé pour les mesures et des relations entre les tables. ([README du dépôt](https://github.com/NVIDIA/auto-ontology))\n\n Ce contexte doit être testé comme une chaîne complète, plutôt qu’accepté comme une promesse générale. Un concept métier doit renvoyer à une définition qu’une équipe peut examiner et, si nécessaire, certifier. Cette définition doit identifier les tables, colonnes ou logiques de métrique concernées ; les relations doivent expliquer quels rapprochements sont légitimes ; le lignage doit montrer comment une réponse dépend des actifs en amont ; et la provenance doit rendre visible l’origine des métadonnées. La valeur ne réside pas dans le fait que l’agent semble plus sûr de lui. Elle tient à ce qu’un évaluateur puisse comprendre pourquoi un terme a été sélectionné et comment ce choix a conduit à la requête générée.\n\n « Certifié » doit également signifier davantage que « créé par un processus d’ingestion ». Un test utile doit distinguer les définitions validées par un responsable métier des suggestions encore provisoires. Si une ontologie définit « client actif » selon une logique métier approuvée, les questions qui utilisent cette expression devraient renvoyer à la métrique ou au chemin de requête correspondant. Si le système ne peut pas indiquer quelle définition a été utilisée, quelles relations ont justifié la jointure ou quels actifs sources ont contribué à la réponse, la couche sémantique n’a pas rendu le résultat suffisamment traçable.\n\n Une évaluation limitée est plus révélatrice qu’une démonstration générale. Commencez par un petit schéma comprenant quelques tables de faits et de dimensions, un champ de date et au moins une mesure volontairement ambiguë. Préparez des questions dont les réponses sont connues, notamment des cas qui exigent une jointure précise, une période de reporting définie ou une distinction entre des métriques proches. Exécutez chaque question d’abord avec une approche text-to-SQL classique, accompagnée du schéma et d’une documentation ordinaire, puis avec une approche fondée sur l’ontologie. Gardez le modèle, les données et les permissions aussi cohérents que possible afin que la comparaison mesure la couche de contexte, et non des changements sans rapport.\n\n Ne consignez pas uniquement la réussite de l’exécution. Pour chaque essai, capturez le SQL généré, les concepts et relations récupérés, les filtres appliqués et le résultat final. Vérifiez si la requête a utilisé la définition attendue, conservé le bon niveau de granularité, joint les bonnes entités et répondu à la question qu’aurait réellement posée un expert métier. Le dépôt de NVIDIA décrit un contrôle d’answerability et renvoie le SQL ainsi que les étapes suivies par l’agent avec une réponse ; ces éléments doivent faire partie de l’évaluation, et non être jetés après l’affichage du résultat par l’interface. ([README d’Auto Ontology](https://github.com/NVIDIA/auto-ontology))\n\n Les tests négatifs sont essentiels. Posez une question sur un terme ambigu, omettez une limite temporelle nécessaire ou demandez une relation que le schéma ne prend pas en charge. Le comportement attendu peut être une demande de clarification ou l’indication explicite que la question ne permet pas d’obtenir une réponse. Un chiffre impeccable n’est pas un succès si l’agent sélectionne silencieusement une table pratique. La documentation MCP expose également `check_answerable` aux côtés de la réponse aux questions, et son outil `ask_question` renvoie séparément la réponse, le SQL et les lignes, ce qui facilite l’inspection de ce comportement dans un banc d’essai pour agents. ([Documentation MCP](https://github.com/NVIDIA/auto-ontology/blob/main/docs/mcp.md))\n\n Enfin, classez les échecs au lieu de réduire le résultat à un seul chiffre de précision : définition métier incorrecte, jointure invalide, granularité erronée, filtre manquant, affirmation non prise en charge ou SQL simplement inefficace. Réinjectez les corrections validées dans le glossaire et les relations, puis relancez le même jeu de questions dont les réponses sont connues. Cette boucle de rétroaction n’est utile que si chaque modification des métadonnées peut être révisée et attribuée. Si l’ancrage dans l’ontologie améliore la précision sémantique, le comportement de clarification et la traçabilité sur des questions dont les définitions sont explicites, il mérite de faire l’objet de tests supplémentaires. Cela ne suffit pas, à lui seul, à établir que des requêtes d’entreprise arbitraires sont fiables.\n\n ## Ce qu’il faut réellement pour l’exécuter\n\n Auto Ontology de NVIDIA ressemble davantage à une petite plateforme de données qu’à un paquet pouvant être ajouté à un agent existant en une seule commande. Le dépôt décrit un déploiement composé de plusieurs services : un frontend pour l’interface web, un backend qui expose l’application et la surface d’API, des services d’ingestion qui se connectent aux sources de données d’entreprise et construisent l’ontologie, ainsi que Postgres avec pgvector pour l’état de l’application et la récupération fondée sur des vecteurs. Les méthodes de déploiement documentées sont Docker Compose pour une configuration locale ou sur un hôte unique, et Kubernetes pour un déploiement plus opérationnel. Cette répartition est importante, car le test ne consiste pas seulement à vérifier si l’ontologie produit une meilleure réponse ; il faut aussi déterminer si une équipe peut maintenir les services, les bases de données, les points de terminaison des modèles et les identifiants alignés au sein d’un même système.\n\n La couche des modèles constitue une autre dépendance explicite. Auto Ontology est conçu pour fonctionner avec des points de terminaison NVIDIA NIM ou des points de terminaison compatibles, et sa configuration couvre davantage que le modèle de langage utilisé pour interpréter une question. Les choix d’embedding et de reranking influencent également la sélection des métadonnées et du contexte candidat avant la production d’une réponse. En pratique, deux installations utilisant le même schéma source peuvent se comporter différemment si leurs configurations de modèle, d’embedding ou de reranking diffèrent. Une évaluation utile consigne donc ces paramètres avec les questions et les résultats. Sinon, une modification de la récupération ou de la configuration du modèle peut être prise à tort pour une amélioration de l’ontologie elle-même.\n\n Le volet base de données est tout aussi concret. Le projet est destiné à se connecter à des bases de données d’entreprise prises en charge et à utiliser leurs métadonnées comme données d’entrée, tandis que Postgres et pgvector assurent les besoins de persistance et de récupération propres à l’application. Une frontière se crée ainsi entre les bases de données décrites et le stockage utilisé par Auto Ontology. Un essai doit cartographier cette frontière avant toute saisie d’identifiants : déterminer quels systèmes sources seront lus, quelles métadonnées ou informations de lignage seront collectées, où l’ontologie produite sera stockée et quel service est autorisé à atteindre chaque point de terminaison. L’architecture reste maîtrisable, mais il ne s’agit pas d’une installation légère sous forme de binaire unique que l’on pourrait déposer dans l’environnement d’exécution d’un agent sans prendre de décisions d’infrastructure.\n\n Deux grandes approches permettent de présenter le contexte produit à un agent. Le projet expose une voie API pour les applications qui souhaitent appeler directement ses services, et sa documentation MCP décrit un serveur MCP utilisable par un banc d’essai compatible avec MCP. MCP est utile lorsque l’agent sait déjà découvrir et appeler des outils, tandis que l’API constitue le point d’intégration le plus direct pour une application contrôlée ou un script d’évaluation. Dans les deux cas, l’agent ne consulte pas une seconde base de données magique. Il invoque les capacités sémantiques et de récupération d’Auto Ontology afin d’intégrer les définitions métier, les relations et les métadonnées associées au flux de la requête ou de la question.\n\n Cette distinction doit guider le premier test. Commencez avec une petite base de données non sensible, ou avec un schéma représentatif, déployez la configuration Compose, puis vérifiez séparément le frontend, le backend, le chemin d’ingestion, le stockage Postgres/pgvector et le point de terminaison du modèle avant de connecter un agent. Faites ensuite passer les mêmes questions fixes par l’API ou la route MCP, en conservant inchangée la configuration du modèle, des embeddings, du reranking et des sources. Ne vérifiez pas seulement la réponse finale en prose : contrôlez aussi que le SQL généré est valide, qu’il utilise les tables et définitions prévues et que le système fournit suffisamment de provenance pour expliquer le résultat. Le fait qu’un déploiement réponde correctement à une question de démonstration ne prouve pas encore que l’intégration complète est fiable.\n\n Le coût opérationnel fait donc partie de la question produit. Les équipes ont besoin d’une orchestration de conteneurs, d’un service Postgres persistant, d’un accès aux modèles, de routes réseau vers les bases sources et d’un plan pour les mises à niveau et les pannes entre composants distincts. Kubernetes peut rendre ce fonctionnement reproductible à l’échelle de l’organisation, mais il renforce aussi l’importance de la responsabilité et de l’observabilité ; Docker Compose peut accélérer une évaluation circonscrite tout en laissant les enjeux de production ouverts. Le seuil raisonnable pour dépasser le stade du test n’est pas que l’interface fonctionne, mais que l’équipe puisse reproduire l’installation, limiter les accès, déterminer quel composant a produit une réponse et retirer ou remplacer le service d’ontologie sans laisser l’agent ou les systèmes sources dans un état ambigu.\n\n ## Licence, identifiants et raisons de rester prudent\n\n Apache-2.0 rend Auto Ontology relativement simple à évaluer du point de vue des licences : les équipes peuvent inspecter, exécuter, modifier et redistribuer le projet conformément aux conditions de la licence. NVIDIA publie également des artefacts de conteneurs et identifie séparément les composants tiers. C’est utile pour une évaluation technique, mais il ne faut pas y voir un engagement complet de support en production. Le dépôt précise que l’équipe Auto Ontology assure la maintenance du code et n’accepte pas les pull requests externes ; les demandes d’intégration et les rapports de bugs sont traités sous forme d’issues. En pratique, un adoptant doit partir du principe que les corrections importantes, les décisions de publication et les changements sensibles pour la sécurité restent tributaires de l’équipe mainteneuse.\n\n Ce modèle de responsabilité compte, car le projet est assez vaste pour présenter plusieurs frontières opérationnelles : frontend web et couche d’authentification, backend FastAPI et services d’ingestion, PostgreSQL avec pgvector, points de terminaison des modèles, connecteurs de bases de données et passerelle MCP. Une issue publique signale également une documentation qui décrit encore le dépôt comme interne à NVIDIA alors qu’il est public. Cette incohérence ne constitue pas en soi une vulnérabilité, mais elle indique que la documentation doit être confrontée au code, aux manifestes de déploiement et aux images publiées avant qu’une équipe ne considère le quickstart comme une procédure d’exploitation faisant autorité. Le même examen doit confirmer quels tags d’images, quelles valeurs Helm, quelles routes API et quels points de terminaison de modèles sont approuvés pour l’environnement visé.\n\n L’avertissement le plus important concerne le stockage des identifiants. Les connexions ajoutées depuis l’interface sont stockées différemment selon que HashiCorp Vault est configuré ou non. Sans Vault, l’objet de connexion complet, mot de passe compris, est sérialisé sans chiffrement dans une ligne du catalogue PostgreSQL. Vault modifie cette organisation en stockant les identifiants séparément et en les excluant de la ligne du catalogue, mais Vault est optionnel et une configuration partielle entraîne un retour au stockage en clair, accompagné d’un avertissement. Ce réglage constitue donc un contrôle architectural, et non une simple commodité. Avant de connecter un entrepôt de données de production, les équipes de sécurité doivent vérifier la configuration effective de Vault, examiner les sauvegardes et les réplicas de la base, restreindre l’accès au catalogue et confirmer que les enregistrements de connexion ne peuvent pas être lus par des rôles qui n’en ont pas besoin.\n\n La frontière entre les services internes mérite le même niveau d’attention. La documentation du projet précise que les ports utilisés par le backend FastAPI et le service d’ingestion doivent rester sur un réseau privé. Le frontend transmet l’identité de l’utilisateur au backend, tandis que les opérations d’ingestion — ingest, delete, reset et compile — ne disposent pas de leur propre authentification. Le chemin prévu passe donc par l’application web authentifiée ou la passerelle API publique, et non par une exposition directe de ces services FastAPI. Publier les ports internes derrière un équilibreur de charge, les ouvrir à un réseau de cluster étendu ou supposer qu’un client MCP fournit l’autorisation manquante fragiliserait la séparation sur laquelle repose le modèle de déploiement.\n\n Le choix des modèles et des services hébergés ajoute une autre question de gouvernance des données. La configuration par défaut utilise des points de terminaison de modèles hébergés par NVIDIA, tandis que des points de terminaison NIM auto-hébergés ou compatibles peuvent être configurés selon les rôles. Lorsque cette fonction est activée, les questions prédictives peuvent également être acheminées vers KumoRFM ; la documentation indique que les tables connectées peuvent être téléversées vers ce service hébergé, dans les limites de sa configuration et sous réserve de ses conditions. Une évaluation doit donc consigner où circulent les métadonnées de schéma, les valeurs échantillonnées, les prompts, le SQL généré et les résultats des requêtes. « Open source » décrit le code d’Auto Ontology, mais n’intègre pas automatiquement le fournisseur de modèles configuré, le connecteur, la base de données ou le service de prédiction hébergé dans la même frontière de confiance.\n\n Une adoption raisonnable commence par un pilote limité utilisant des données synthétiques ou non sensibles, des politiques réseau qui maintiennent les services internes privés, Vault activé avant l’ajout d’identifiants gérés depuis l’interface, et des points de terminaison de modèles choisis délibérément. Testez l’authentification et le comportement des rôles via les mêmes chemins API et MCP que ceux utilisés par les agents. Conservez une exportation d’ontologie fonctionnelle, la configuration d’accès à la base de données et la version du déploiement afin de pouvoir désactiver la compilation ou revenir en arrière sans perdre l’état de référence. Avant toute utilisation en production, exigez ensuite un examen de sécurité indépendant, couvrant notamment les secrets, les journaux, les sauvegardes, le trafic sortant, la provenance des dépendances et les permissions de chaque source connectée.\n\n La conclusion pratique est plus nuancée que « Auto Ontology est prêt » ou « Auto Ontology est dangereux ». Il est prêt à être testé comme couche de métadonnées et de contexte pour les agents, à condition de considérer le déploiement et le traitement des données comme des éléments du produit, et non comme de simples détails de configuration. Sa licence Apache-2.0 facilite l’inspection, tandis que le stockage en clair des connexions sans Vault, les points de terminaison internes non authentifiés, les frontières liées aux modèles hébergés et les changements contrôlés par les mainteneurs soulèvent des questions auxquelles une démonstration ne peut pas répondre. La preuve pertinente est un déploiement réduit et réversible, dont les contrôles de sécurité, le comportement des requêtes et la procédure de retour en arrière sont tous démontrés avant que l’ontologie ne soit placée devant des données d’entreprise sensibles.","available_translations":[{"language":"ar","title":"تحوّل NVIDIA Auto Ontology البيانات الوصفية للمؤسسات إلى طبقة سياق للوكلاء — ما الذي أصبح جاهزًا للاختبار؟","html_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=ar","markdown_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=ar","json_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=ar"},{"language":"de","title":"NVIDIA Auto Ontology verwandelt Unternehmensmetadaten in eine Kontextschicht für Agenten – was sich testen lässt","html_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=de","markdown_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=de","json_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=de"},{"language":"en","title":"NVIDIA Auto Ontology turns enterprise metadata into an agent context layer — what is ready to test","html_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=en","markdown_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=en","json_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=en"},{"language":"es","title":"Auto Ontology de NVIDIA convierte los metadatos empresariales en una capa de contexto para agentes: qué está listo para probar","html_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=es","markdown_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=es","json_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=es"},{"language":"fr","title":"Auto Ontology de NVIDIA transforme les métadonnées d’entreprise en couche de contexte pour les agents — ce qui est prêt à être testé","html_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=fr","markdown_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=fr","json_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=fr"},{"language":"pl","title":"NVIDIA Auto Ontology zamienia metadane przedsiębiorstwa w warstwę kontekstu dla agentów — co jest gotowe do testów","html_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=pl","markdown_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=pl","json_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=pl"},{"language":"ru","title":"NVIDIA Auto Ontology превращает корпоративные метаданные в контекстный слой для агентов — что уже можно тестировать","html_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=ru","markdown_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=ru","json_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=ru"},{"language":"zh","title":"NVIDIA Auto Ontology 将企业元数据转化为智能体上下文层——目前有哪些内容可以测试","html_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=zh","markdown_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=zh","json_url":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=zh"}],"_links":{"self":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=fr","api":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=fr","html":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=fr","canonical":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=fr","markdown":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=fr","json":"https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=fr","channel":"https://publicasta.com/api/public/v1/channels/open_source_radar","channel_articles":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}