DS-STAR contre les agents de codage généraux : explication du système d’analyse de données de Google.

Les agents de codage polyvalents se révèlent très efficaces pour les tâches d’ingénierie courantes, mais ils ont tendance à stagner lorsqu’ils sont confrontés à des problématiques sérieuses en science des données. Une analyse typique se limite à quelques moyennes. Ils sont utiles, mais il n’y a ni comparaisons de distributions, ni valeurs p ou intervalles de confiance, et peu d’attention est portée à la qualité des données. C’est un peu comme demander à un généraliste d’effectuer le travail d’un spécialiste.

Une étude de Google, DS-STAR, vise précisément à combler cette lacune. Elle affirme que les améliorations proviennent du cadre et de la conception du système entourant le modèle, et non d’un modèle plus complexe. Les chiffres clés illustrent bien ce point : Gemini 2.5 Pro, utilisé seul, obtient 12,70 % sur les tâches difficiles de DABStep. Avec DS-STAR, le même modèle atteint 45,24 %, soit une hausse d’environ 32 points de pourcentage. Le modèle n’a pas changé ; c’est le système qui l’entoure qui a évolué.

La même logique explique pourquoi certains outils de codage surpassent d’autres sans forcément disposer du meilleur modèle de base : la manière dont le système est conçu est tout aussi importante que les poids utilisés. DS-STAR applique cette approche à la science des données, et ce qui suit décompose ce système morceau par morceau.

La publication à l’origine de DS-STAR

Cette publication, simplement intitulée DS-STAR (un agent de science des données pour des tâches diverses), a été rédigée par Jaehyun Nam (KAIST) en collaboration avec Jinsung Yoon, Jiefeng Chen, Raj Sinha et Tomas Pfister de Google Cloud. Elle est apparue pour la première fois sur arXiv en septembre 2025 et a atteint sa quatrième version en février 2026. Google a également publié un résumé plus court sur son blog de recherche.

D’après la description des auteurs, DS-STAR est un agent de science des données conçu pour traiter et intégrer des données provenant de formats divers et hétérogènes, et pour aller au-delà de simples réponses aux questions en produisant des rapports de recherche complets pour des requêtes ouvertes.

Voici le plan des sections suivantes :

• Le problème abordé dans cet article, et les raisons pour lesquelles les approches en une seule passe échouent dans le travail réel en science des données.
• La structure en couches du système : DS-STAR gère les questions clairement formulées, tandis que DS-STAR+ s’occupe de recherches ouvertes.
• Un examen approfondi des sept modules de DS-STAR, de leurs formules ainsi que de l’algorithme itératif complet.
• DS-STAR+ et la manière dont la décomposition, un module d’écriture et un cycle de refinement permettent de créer des rapports structurés.
• Les prompts publiés par Google dans son appendice, et ce que révèlent les choix de conception.
• Tests d’ablation, afin de déterminer quel composant est responsable de la majeure partie de l’amélioration de 32 points.
• La manière dont le nombre d’itérations augmente avec la difficulté de la tâche.
• Un exemple de rapport DS-STAR+ généré sur un ensemble de données de paiements.
• Limites, y compris l’absence d’une version officielle.

Quel est l’objectif de DS-STAR pour l’analyse de données

L’ambition affichée est grande : un système capable de répondre à n’importe quelle question en science des données, quel que soit le format et la nature des requêtes.

Les données sont ce qui rend la tâche difficile. Le travail réel implique rarement un simple fichier CSV bien organisé et une question formulée avec précision. Il s’agit plutôt de plusieurs ensembles de données structurés nécessitant une réflexion en plusieurs étapes, de connaissances sectorielles intégrées dans des règles, ainsi que de questions auxquelles aucune génération de code unique ne peut répondre. Le benchmark DABStep, développé par Adyen et Hugging Face, reflète bien cette réalité. Il comprend 450 tâches, dont 72 sont faciles (un seul ensemble de données, peu de contexte requis) et 378 sont difficiles (plusieurs ensembles de données, connaissances sectorielles nécessaires, pas de solution immédiate). KramaBench va encore plus loin, avec 104 défis répartis sur 1 700 fichiers et 24 sources de données dans 6 domaines, où l’agent doit déterminer par lui-même quels fichiers sont importants.

Les deux benchmarks ont été conçus pour contrer l’approche consistant à « écrire un bloc de code et soumettre la réponse », ce que DS-STAR remplace précisément.

Même une configuration plus restreinte, comme une seule base de données interne et une question bien définie, bénéficie de ces choix architecturaux. Un système capable de gérer le chaos hétérogène produira des données propres. Le contraire n’est pas vrai.

Comment DS-STAR est structuré

Il s’agit en réalité de deux systèmes, l’un construit sur l’autre. DS-STAR est le moteur interne de DS-STAR+. La couche externe, DS-STAR+, divise une requête ouverte en sous-questions ciblées et les transmet chacune à DS-STAR. Un agent d’écriture synthétise ensuite les réponses en un rapport, et un évaluateur peut déclencher de nouvelles séries d’analyses.

DS-STAR en détail

Le diagramme présenté dans l’article est correct, mais il omet quelques composants qui aident à suivre l’ordre de l’algorithme ; il est donc utile de lire le module par module, dans l’ordre où les données le traversent.

Les sept modules

DS-STAR se compose de sept agents nommés.

Module 1, l’Analyseur. Avant toute planification, DS-STAR analyse chaque fichier de données qu’il reçoit. Pour chaque fichier, il génère un script Python, l’exécute et stocke le résultat affiché sous forme de description structurée, à l’image d’un petit indexeur ou d’une couche RAG légère. Un détail notable est que cette description provient de code Python déterministe, et non d’un LLM qui déciderait librement comment examiner un fichier. L’appendice du rapport inclut un script d’exemple qui analyse un fichier JSON ainsi que le résultat qu’il produit. Google publie également le prompt correspondant à chaque module. Voici celui de l’Analyseur :

You are an expert data analysist.
Generate a Python code that loads and describes the content of {filename}.

# Requirement
- The file can both unstructured or structured data.
- If there are too many structured data, print out just few examples.
- Print out essential informations. For example, print out all the column names.
- The Python code should print out the content of {filename}.
- The code should be a single-file Python program that is self-contained and can be
executed as-is.
- Your response should only contain a single code block.
- Important: You should not include dummy contents since we will debug if error occurs.
- Do not use try: and except: to prevent error. I will debug it later.

Module 2, le Planificateur. Compte tenu des descriptions des données et de la question de l’utilisateur, le Planificateur ne propose que la première étape d’un plan d’exécution, et non l’ensemble d’un coup. Il fonctionne en deux modes : planner_init pour la première étape lorsqu’il n’y a pas de plan préalable, et planner_next pour les étapes suivantes, qui prend en compte le plan actuel ainsi que les résultats d’exécution antérieurs. Voici la commande qui démarre l’élaboration d’un plan :

You are an expert data analysist.
In order to answer factoid questions based on the given data, you have to first plan
effectively.

# Question
{question}

# Given data: {filenames}
{filenames #1}
{summaries #1}
...
{filenames #N}
{summaries #N}

# Your task
- Suggest your very first step to answer the question above.
- Your first step does not need to be sufficient to answer the question.
- Just propose a very simple initial step, which can act as a good starting point to
answer the question.
- Your response should only contain an initial step.

Pour les étapes suivantes, la demande change. Elle inclut désormais les étapes précédentes ainsi que leurs résultats, ce qui permet au système de se souvenir de ce qui a été tenté et fournit un contexte plus approfondi :

You are an expert data analysist.
In order to answer factoid questions based on the given data, you have to first plan
effectively.

Your task is to suggest next plan to do to answer the question.

# Question
{question}

# Given data: {filenames}
{filenames #1}
{summaries #1}
...
{filenames #N}
{summaries #N}

# Current plans
1. {Step 1}
...
k. {Step k}

# Obtained results from the current plans:
{result}

# Your task
- Suggest your next step to answer the question above.
- Your next step does not need to be sufficient to answer the question, but if it
requires only final simple last step you may suggest it.
- Just propose a very simple next step, which can act as a good intermediate point to
answer the question.
- Of course your response can be a plan which could directly answer the question.
- Your response should only contain an next step without any explanation.

Module 3, le Codeur. Il prend l’étape du plan actuel et en génère du Python exécutable. Comme le Planificateur, il dispose de deux modes : coder_init pour le premier bloc et coder_next pour les blocs suivants, en tenant compte des résultats précédents. Le résultat est un script autonome unique. L’instruction initiale :

# Given data:
{filenames}
{filenames #1}
{summaries #1}
...
{filenames #N}
{summaries #N}

# Plan
{plan}

# Your task
- Implement the plan with the given data.
- Your response should be a single markdown Python code (wrapped in ```).
- There should be no additional headings or text in your response.

Et l’instruction pour coder chaque action suivante :

You are an expert data analysist.
Your task is to implement the next plan with the given data.

# Given data:
{filenames}
{filenames #1}
{summaries #1}
...
{filenames #N}
{summaries #N}

# Base code
```python
{base_code}
```

# Previous plans
1. {Step 1}
...
k. {Step k}

# Current plan to implement
{Step k+1}

# Your task
- Implement the current plan with the given data.
- The implementation should be done based on the base code.
- The base code is an implementation of the previous plans.
- Your response should be a single markdown Python code (wrapped in ```).
- There should be no additional headings or text in your response.

Module 4, le débogueur. La sortie du Codeur est testée sur les fichiers de données réels. Si l’exécution échoue, que ce soit en raison d’une erreur de syntaxe, d’une colonne manquante ou d’un incohérence de type, le débogueur prend le relais. Il reçoit le code défectueux ainsi que le message d’erreur et génère un script corrigé. La Figure 1 du document ne lui accorde pas beaucoup d’importance, pourtant il fait partie de l’algorithme, situé entre le Codeur et le Vérificateur, et gère les échecs d’exécution avant même qu’ils n’atteignent l’évaluation du plan. Il utilise deux prompts. Le premier condense le rapport d’erreur, car les traces d’erreur peuvent être très longues :

# --> PROMPT TO SUMMARISE THE ERROR
# Error report
{bug}

# Your task
- Remove all unnecessary parts of the above error report.
- We are now running {filename}.py. Do not remove where the error occurred.

Le deuxième effectue la réparation réelle :

# --> PROMPT TO FIX THE ERROR
# Code with an error:
```python
{code}
```

# Error:
{bug}

# Your task
- Please revise the code to fix the error.
- Provide the improved, self-contained Python script again.
- There should be no additional headings or text in your response.
- Do not include dummy contents since we will debug if error occurs.
- All files/documents are in `data/` directory.

Module 5, le Vérificateur. Une fois que le code s’exécute avec succès, le Vérificateur détermine si le plan mis en place jusqu’à présent est suffisant pour répondre à la question initiale. Son verdict est binaire : suffisant ou insuffisant. Ce jugement s’appuie sur le plan cumulatif, la requête de l’utilisateur, le code de solution qui met en œuvre ce plan ainsi que son résultat d’exécution, en utilisant cette indication :

You are an expert data analysist.
Your task is to check whether the current plan and its code implementation is enough to
answer the question.

# Plan
1. {Step 1}
...
k. {Step k}

# Code
```python
{code}
```

# Execution result of code
{result}

# Question
{question}

# Your task
- Verify whether the current plan and its code implementation is enough to answer the
question.
- Your response should be one of 'Yes' or 'No'.
- If it is enough to answer the question, please answer 'Yes'.
- Otherwise, please answer 'No'.

Module 6, le Routeur. Il intervient uniquement lorsque le Vérificateur indique un manque. Le Routeur examine le plan, la question et les résultats de l’exécution, puis choisit parmi deux options : soit une nouvelle étape est ajoutée à la fin (« Ajouter une étape »), soit une étape existante doit être corrigée (« Remplacer l’étape K », où K est l’indice de l’étape). La première option convient aux cas où la question n’a tout simplement pas encore été abordée. La seconde est importante car le système avance étape par étape : il peut corriger une seule étape défectueuse sans avoir à réécrire tout le plan.

You are an expert data analysist.
Since current plan is insufficient to answer the question, your task is to decide how to
refine the plan to answer the question.

# Question
{question}

# Given data:
{filenames}
{filenames #1}
{summaries #1}
...
{filenames #N}
{summaries #N}

# Current plans
1. {Step 1}
...
k. {Step k}

# Obtained results from the current plans:
{result}

# Your task
- If you think one of the steps of current plans is wrong, answer among the following
options: Step 1, Step 2, ..., Step K.
- If you think we should perform new NEXT step, answer as 'Add Step'.
- Your response should only be Step 1 - Step K or Add Step.

Module 7, le Finaliseur. Lorsque le Vérificateur renvoie des résultats suffisants, le Finaliseur extrait le résultat pertinent de l’historique d’exécution accumulé et le formate en réponse à la question initiale.

You are an expert data analysist.
You will answer factoid question by loading and referencing the files/documents listed
below. You also have a reference code.

Your task is to make solution code to print out the answer of the question following the
given guideline.

# Given data: {filenames}
{filenames #1}
{summaries #1}
...
{filenames #N}
{summaries #N}

# Reference code
```python{code}
```
# Execution result of reference code
{result}

# Question
{question}

# Guidelines
{guidelines}

# Your task
- Modify the solution code to print out answer to follow the give guidelines.
- If the answer can be obtained from the execution result of the reference code, just
generate a Python code that prints out the desired answer.
- The code should be a single-file Python program that is self-contained and can be
executed as-is.
- Your response should only contain a single code block.
- Do not include dummy contents since we will debug if error occurs.
- Do not use try: and except: to prevent error. I will debug it later.
- All files/documents are in `data/` directory.

Un point à retenir : le pipeline est séquentiel, et non parallèle. La sortie de chaque agent alimente le suivant, de sorte que toute modification apportée à l’un d’eux change ce que voit son successeur.

Les formules

Une caractéristique intéressante de cet article est qu’il exprime l’algorithme sous forme de formules. Le message n’est pas « voici comment nos prompts s’assemblent parce que nous l’avons calculé », mais plutôt « ce système se compose d’étapes logiques qui peuvent être décrites avec précision ». De telles formules pourraient aider l’équipe de Google à adapter chaque prompt, modèle Python et script afin d’optimiser les performances. L’article ne le dit pas explicitement, mais il est raisonnable de supposer que c’est ainsi qu’ils ont guidé la conception finale.

Il existe des formules pour la configuration du problème, l’Analyseur, le Planificateur, le Codeur, le Vérificateur et le Routage. Le Débogueur n’en possède aucune, car il se contente de détecter les problèmes d’exécution et de les corriger, produisant toujours du Python fonctionnel. Le Finaliseur manque également de formule, car il s’agit simplement d’une invitation à rédiger la réponse finale à une question détaillée, qu’il s’agisse d’un tableau, d’un nombre ou d’un rapport récapitulatif.

L’algorithme

L’Algorithme 1 présenté dans l’article fournit du pseudo-code pour l’ensemble du processus. Après avoir abordé les modules et les formules, son contenu est facile à comprendre. En termes simples :

Phase 1 : analyse des données. Pour chaque fichier du jeu de données, on exécute l’Analyseur et on enregistre sa description. Tout le reste repose sur cette base.

Phase 2 : planification itérative.

1. Le Planificateur élabore la première étape de plan à partir de la question et des descriptions des données.
2. Le Codeur écrit le code pour cette étape.
3. L’Exécutant le lance. En cas d’échec, le Débogueur corrige le code et il est exécuté à nouveau.
4. Le Vérificateur évalue le plan cumulatif par rapport au résultat obtenu. S’il est suffisant, on passe à l’étape 6.
5. S’il n’est pas suffisant, le Routeur décide s’il faut ajouter une étape ou remplacer l’étape K. On retourne au Planificateur avec le contexte mis à jour, en répétant le processus jusqu’à atteindre la limite d’itérations.
6. Le Finaliseur extrait la réponse à partir des résultats accumulés.

La structure ressemble à un cycle de contrôle par rétroaction, comme celui utilisé dans les régulateurs PID. Le Vérificateur agit comme le capteur, le Routeur comme le régulateur, et le Planificateur ainsi que le Codeur comme les actionneurs. Le cycle se termine lorsque le capteur indique que la tâche est terminée.

DS-STAR+ en détail

DS-STAR+ prend une requête ouverte et la transforme en un rapport structuré. Son diagramme officiel est suffisamment détaillé pour être utilisé tel quel. Le flux se compose de trois parties.

1. La décomposition a la priorité. Une requête vague ne peut pas être envoyée directement à DS-STAR. DS-STAR+ introduit un agent générateur. En analysant à la fois la requête et les descriptions des données, il élabore un ensemble de sous-questions plus ciblées. Chacune comporte une question claire ainsi qu’un lien vers les données pertinentes, permettant ainsi à DS-STAR de y répondre. DS-STAR traite chacune d’elles de manière indépendante et renvoie des réponses.
2. Un agent écrivain fusionne ensuite les paires sous-question-réponse en un rapport structuré. Ses instructions lui dictent de citer chaque affirmation en se référant à la sous-question qui en est à l’origine, dans le but de limiter les hallucinations en assurant que chaque affirmation soit traçable à une requête de données effectuée.

La boucle de perfectionnement ressemble à celle de DS-STAR. Le générateur relit le brouillon actuel ainsi que les descriptions des données et crée de nouvelles sous-questions visant ce qui manque ou est insuffisamment développé.

La notation étend la chaîne DS-STAR grâce à cette couche de décomposition. L’article présente les formules exactes, mais l’algorithme montre plus clairement comment fonctionne la boucle et quels flux y circulent.

Les prompts à l’origine de DS-STAR+

Les prompts utilisés pour cette boucle externe sont également publiés. Tout d’abord, le générateur de sous-questions, lors de sa première passe :

You are an expert data analysist.
Your task is to write a comprehensive data science report to the given question by using
the files/documents listed below.
In order to do this, you have to first suggest multiple data analysis questions that
should be answered to write the report.

# Given data: {filenames}
{filenames #1}
{summaries #1}
...
{filenames #N}
{summaries #N}

# Question
{question}

# Your task
- Suggest multiple factoid data analysis questions that are required to write the report
really well.
- All the questions should be well-answered using the given data.
- All questions should be answered independently.
- Generate as much as you can.
- Return in valid JSON format:
Questions = {'question': str}
Return: list[Questions]

Puis le même agent lors du affinage :

You are an expert data analysist.
Your task is to complement the given data science report of the given question.
In order to do this, you have to suggest supplementary multiple data analysis questions
that can strengthen to the report.

# Given data: {filenames}
{filenames #1}
{summaries #1}
...
{filenames #N}
{summaries #N}

# Given data science report:
{report}

# Question
{question}

# Your task
- Suggest multiple factoid data analysis questions that are required to complement the
report.
- All questions should contain new information that is not included in the report.
- All the questions should be well-answered using the given data.
- All questions should be answered independently.
- Return in valid JSON format:
Questions = {'question': str}
Return: list[Questions]

Ensuite, l’auteur, qui produit le premier rapport :

You are an expert data analysist.
Your task is to write a **comprehensive data science report** to the given question by
using the data and some relevant informations listed below.

# Relevant informations:
{Sub-Question #1}
{Answer #1}
...
{Sub-Question #M_0}
{Answer #M_0}

# Question that you have to write a comprehensive data science report:
{question}

# Your task:
- The report should be grounded to the given relevant informations.
- For the citation, use the Sub-Question number as a citation number which is in 1 - {len(subquestions)}.
- The data science report should be relevant to given question, should be comprehensive,
and should be insightful.
- The data science report should have nice structure, good readability, and should be
professional.
- Write a very comprehensive data science report to the given above question.

Et l’Auteur, une fois de plus, affine un rapport existant :

You are an expert data analysist.
Your task is to complement the given data science report of the given question by using
the some relevant informations listed below.

Relevant informations:
{Sub-Question #1}
{Answer #1}
...
{Sub-Question #M_k}
{Answer #M_k}

# Given data science report:
{report}

# Question that you have to write a comprehensive data science report:
{question}

# Your task:
- Do not modify the given report a lot. Just try to add new information.
- The report should be grounded to the given relevant informations.
- Cite with alphabet. For the citation, use the Sub-Question number as a citation
alphabet (e.g., cite with [a] for the Sub-Question 1).
- The data science report should be relevant to given question, should be comprehensive,
and should be insightful.
- The data science report should have nice structure, good readability, and should be
professional.
- Complement the give data science report to the given above question.

Pour toute personne souhaitant exécuter le système, un projet communautaire, JulesLscx/DS-Star, propose une réimplémentation fidèle (145 étoiles et 37 forks au moment de la vérification). Il contient dsstar.py avec la classe complète DS_STAR_Agent, prompt.yaml avec tous les prompts sous forme de texte, ainsi que provider.py prenant en charge Gemini, OpenAI et Ollama. Il ne s’agit pas d’une version officielle de Google, et il n’en existe pas, mais il suit fidèlement le papier de recherche.

Ce que montrent les ablations

Le tableau 4 du papier de recherche demande quel composant contribue le plus aux résultats de DS-STAR. La méthode utilisée est l’ablation par suppression : on retire un composant et on mesure la baisse des performances.

Sans l’Analyseur, la précision de DABStep pour les tâches difficiles passe de 45,24 % à 26,98 %, ce qui représente la plus grande baisse pour une seule opération de suppression. En l’absence de descriptions des données, le Planificateur établit des étapes sans tenir compte de leur contenu réel. Les performances restent supérieures au seuil de référence non agentique de 12,70 %, ce qui montre que les autres composants contribuent également, mais l’Analyseur a le poids le plus important.

Sans le Routeur (en forçant uniquement l’option « Ajouter une étape »), la précision diminue tant pour les tâches faciles que pour les tâches difficiles. La possibilité de remplacer une étape défectueuse, au lieu de se contenter d’ajouter des éléments à un plan erroné, empêche les erreurs de s’accumuler. Sans cette capacité, le plan et ses erreurs continuent simplement de s’accumuler.

Remplacer le vérificateur étape par étape par une approche qui consiste à planifier tout d’abord avant d’exécuter, où le seul critère est le succès de l’exécution du code, donne de moins bons résultats que la méthode DS-STAR. Vérifier au niveau de chaque étape permet de détecter les problèmes de planification avant qu’ils ne se propagent à l’étape suivante.

Les data scientists reconnaîtront cette méthode comme une sorte d’étude de l’importance des caractéristiques appliquée à un agent : supprimer les composants un par un et observer dans quelle mesure les résultats se détériorent. Selon cette mesure, l’Analyseur occupe la première place, le Routeur la deuxième, tandis que le vérificateur étape par étape surpasse la référence basée sur un plan complet.

Le blog de recherche de Google ajoute une nouvelle observation. DS-STAR avec GPT-5 performe mieux sur les tâches faciles, tandis que DS-STAR avec Gemini 2.5 Pro excelle sur les tâches difficiles. Même framework, mais forces différentes selon le modèle. Cela ne remet pas en question l’efficacité des modèles puissants ; cela montre plutôt que le framework met en évidence les forces de chaque modèle plutôt que de les moyanner.

Plus d’itérations pour des problèmes plus difficiles

Les tâches difficiles nécessitent en moyenne 5,6 itérations pour aboutir à un plan suffisant, tandis que les tâches faciles en nécessitent 3,0. Plus de la moitié des tâches faciles sont résolues en une seule itération. Le système n’effectue pas trop d’itérations sur les problèmes simples : il consacre autant de tours de perfectionnement que le niveau de difficulté de la demande le requiert. Une question simple nécessite une seule itération, tandis qu’une question complexe couvrant plusieurs ensembles de données et de nombreux étapes de raisonnement en nécessite cinq ou six.

Cela a de l’importance en pratique, car le coût des tokens et la latence augmentent avec le nombre d’itérations. Un système qui s’arrête tôt sur les tâches simples et persévère sur celles qui sont difficiles se comporte comme il se doit.

Rapport d’exemple de Google sur l’ingénierie des caractéristiques

L’appendice G du document comprend trois exemples de résultats DS-STAR+. Le rapport 3 est le plus intéressant, car il aborde l’ingénierie des caractéristiques pour les problèmes d’apprentissage automatique. La demande concerne un rapport détaillé de préparation des données visant à améliorer le calcul des frais de traitement des paiements. Il s’agit d’examiner les liens entre les caractéristiques des commerçants, les attributs des transactions et les structures de frais à travers plusieurs ensembles de données, ainsi que de considérer les problèmes de qualité des données, l’ingénierie des caractéristiques pour le calcul des frais et la question de savoir si les règles de frais s’appliquent réellement.

Le rapport couvre quatre aspects :

1. Décisions d’ingénierie des fonctionnalités pour le calcul des frais, c’est-à-dire quels champs combiner et quelles règles s’appliquent dans quelles conditions.
2. Problèmes de qualité des données identifiés dans l’ensemble des ensembles de données, tels que des valeurs manquantes, des encodages incohérents et des cas limites en ce qui concerne l’application des règles.
3. Vérification pour savoir si les règles de frais décrites dans le manuel peuvent réellement être appliquées aux données actuelles telles qu’elles sont.
4. Citation, dans chaque section, de la sous-question correspondante ainsi que de l’exécution du code associée.

Pour un data scientist expérimenté, un rapport de ce type permettrait d’accélérer considérablement l’analyse de domaines spécifiques des données.

Limites, y compris une version sur Claude Code

Quatre limites méritent d’être mentionnées.

1. Aucune version officielle open source disponible. Google n’a pas publié d’implémentation. L’implémentation réalisée par la communauté est fidèle au modèle et bien documentée, mais ses auteurs ne la maintiennent pas.
2. L’intégration avec Claude Code reste un problème non résolu. Une question évidente concerne la possibilité de faire fonctionner des modèles DS-STAR au sein d’un workflow Claude Code. Claude Code peut accéder à des sources de données externes via des serveurs Model Context Protocol, ce qui permet en principe de créer un outil de type DS-STAR sous forme d’ensemble de compétences ou d’agents. Aucune version publiée et testée en production n’existe pour l’instant.

L’Analyseur est puissant mais basique. Actuellement, il génère un script Python et le lance, ce qui revient essentiellement à une fonction describe() programmée. Des outils tels que ydata-profiling (anciennement pandas-profiling) fournissent des résumés de qualité des données bien plus complets, avec des graphiques de distribution, des matrices de corrélation, des cartes thermiques des valeurs manquantes et des avertissements concernant les encodages catégoriels. La question de savoir si un contexte plus riche fourni par l’Analyseur permettrait d’améliorer davantage les performances reste une véritable question de recherche laissée en suspens dans cet article.

Le nom est légèrement trompeur. À en juger par ce que produit l’agent, il ressemble davantage à un agent de science des données destiné à la production. Il est difficile d’imaginer qu’il puisse générer des solutions d’apprentissage automatique et les itérer en fonction d’une métrique cible. Des projets open source tels que l’outil autoresearch de Karpathy se concentrent sur ce type de problèmes.

Pourquoi le harnais est plus important que le modèle

DS-STAR fonctionne grâce à son harnais. Les données sont d’abord analysées. La planification se déroule ensuite étape par étape, chaque étape étant vérifiée par rapport à ce qui a réellement été exécuté ; en cas d’échec, c’est précisément cette étape qui est corrigée plutôt que le système de continuer sans tenir compte du problème. Sept agents spécialisés accomplissent chacun une tâche, chacun étant contrôlé par une instruction courte et spécifique.

L’ablation effectuée sur l’Analyseur est celle dont les conséquences restent marquantes. La plus grande perte de performance provient de la suppression de l’étape qui décrit les fichiers de données, et non de celle du Vérificateur ou du Routeur. Avant de commencer la planification, DS-STAR lit les données et en crée un modèle, et toutes les étapes suivantes s’appuient sur ce modèle. Si cette étape est omise, la planification qui suit se fait à l’aveugle.

Tout ceux qui cherchent des workflows de science des données basés sur des LLM plus fiables peuvent retenir ceci : il ne s’agit pas d’ajouter des capacités à un seul agent. Divisez le travail en étapes plus petites qui peuvent être vérifiées, et assurez-vous que la première d’entre elles consiste à comprendre les données.