Portia : un harnais d'agent open source pour une ingénierie de données vérifiable

Publié le 7 octobre 2026, Portia est un harnais d'agent open source conçu pour assister aux tâches réelles d'ingénierie des données. Créé par Jad1908 et hébergé sur GitHub, cet outil se connecte aux principaux entrepôts de données et aux systèmes de fichiers locaux pour profiler les tables, répondre aux questions et générer des pipelines SQL. Contrairement à de nombreux assistants IA qui traitent directement les données brutes, Portia garantit que le modèle de langage sous-jacent n'accède jamais au jeu de données réel, s'appuyant plutôt sur du code déterministe pour toutes les affirmations numériques.

Ce qui s'est passé

Le projet introduit un copilote pour le travail sur les données qui s'intègre à Snowflake, BigQuery, PostgreSQL ou à des dossiers locaux contenant des fichiers CSV et Parquet. Une fois connecté, Portia profile chaque table rencontrée, mesurant les taux de valeurs nulles, les comptes distincts, la couverture des clés et le fan-out avant l'exécution de toute opération de jointure. Il permet aux utilisateurs de poser des questions en langage naturel sur la structure et le contenu de leurs données, comme vérifier si un identifiant spécifique est unique ou demander une ventilation des revenus par mois. Le système construit ensuite les tables demandées étape par étape, enregistrant chaque décision dans une spécification YAML.

Un choix architectural critique dans Portia est la séparation du raisonnement et de l'accès aux données. Le modèle de langage utilisé pour l'interaction n'a aucun accès au système de fichiers ni aucune capacité shell. Chaque nombre ou statistique présenté à l'utilisateur est calculé par du code déterministe plutôt que généré par la prédiction probabiliste du prochain token du modèle. Cette conception garantit que l'outil peut gérer des tables trop volumineuses pour tenir en mémoire tout en rendant chaque affirmation vérifiable. La sortie finale est compilée en fichiers SQL au format dbt pouvant fonctionner indépendamment de Portia, assurant ainsi que le pipeline généré n'est pas verrouillé sur l'outil lui-même.

Le système inclut également un graphe de connaissances alimenté par Neo4j, qui stocke la lignée des colonnes et les chevauchements mesurés entre les jeux de données. Ce graphe aide le copilote à déterminer quelles tables sont pertinentes pour la requête d'un utilisateur. Les utilisateurs peuvent parcourir ce graphe localement pour comprendre comment les colonnes sont liées dans l'ensemble du pipeline. De plus, Portia prend en charge les graphiques visuels dans l'interface de conversation. Si le modèle sous-jacent accepte les entrées d'image, le copilote peut inspecter visuellement un graphique rendu dans le navigateur de l'utilisateur pour vérifier son exactitude avant de signaler les conclusions, bien que l'image elle-même ne soit jamais sauvegardée ni utilisée pour des décisions numériques.

Comment cela fonctionne

Portia fonctionne en indexant les sources de données et en construisant un catalogue de métadonnées. Lorsqu'un utilisateur pose une question, le copilote consulte le graphe de connaissances pour identifier les tables et colonnes pertinentes. Il formule ensuite des requêtes exécutées contre la source de données en utilisant les propres identifiants de l'utilisateur. Pour les connexions de base de données, les requêtes s'exécutent sous le rôle de l'utilisateur, ce qui signifie que rien n'est téléchargé vers le serveur d'application et que les nouvelles tables sont créées directement dans l'entrepôt. Pour les fichiers locaux, les données restent sur le disque et ne sont pas copiées. Le modèle ne voit que le schéma, les statistiques résumées et les résultats de ces requêtes déterministes.

L'outil fonctionne avec le Claude Agent SDK et peut piloter Claude Code sans modification. Il nécessite Python 3.11 ou supérieur, uv et Docker. L'installation consiste à cloner le dépôt, synchroniser les dépendances et démarrer un conteneur Neo4j. Les utilisateurs doivent fournir leur propre clé API Anthropic ou configurer un fournisseur de modèles local comme Ollama ou llama.cpp. Comme les instructions pour l'agent font environ 15 000 tokens, les modèles locaux doivent prendre en charge une fenêtre de contexte d'au moins 32K tokens. Le système vérifie cette exigence avant d'envoyer les prompts et refuse de continuer si le contexte est insuffisant.

Détails clés

• Confidentialité des données : Le modèle de langage ne lit jamais les données brutes, n'a aucun accès au système de fichiers et ne possède aucune capacité shell.
• Sources prises en charge : Se connecte à Snowflake, BigQuery, PostgreSQL et aux dossiers locaux contenant des fichiers CSV ou Parquet.
• Vérification : Chaque affirmation numérique est calculée par du code déterministe, permettant aux utilisateurs de vérifier les résultats indépendamment.
• Format de sortie : Génère des fichiers SQL au format dbt stockés dans un répertoire models/, pouvant fonctionner sans Portia.
• Graphe de connaissances : Utilise Neo4j pour stocker la lignée des colonnes et mesurer les chevauchements entre les colonnes dans l'ensemble du pipeline.
• Prise en charge des modèles locaux : Compatible avec Ollama et llama.cpp, nécessitant une fenêtre de contexte minimale de 32K pour l'inférence locale.

Pourquoi c'est important

Pour les ingénieurs logiciels et les équipes de données, la principale valeur de Portia réside dans sa vérifiabilité. Les outils de codage assistés par IA traditionnels hallucinent souvent la syntaxe ou la logique, nécessitant une révision manuelle importante. En ingénierie des données, un SQL incorrect peut entraîner une corruption silencieuse des données ou des analyses trompeuses. En forçant le modèle à s'appuyer sur du code déterministe pour toutes les mesures et en l'empêchant de voir les données brutes, Portia réduit le risque de statistiques hallucinées. La fonctionnalité « gate on zeros » protège davantage contre les erreurs courantes en refusant d'écrire les résultats si une requête renvoie des ensembles vides, des grains non uniques ou des colonnes entièrement nulles.

La capacité de compiler les spécifications en SQL standard atténue également le verrouillage fournisseur (vendor lock-in). Les équipes peuvent utiliser Portia pour accélérer le développement initial des pipelines de données mais déployer les fichiers SQL résultants dans leurs environnements de production existants. Cela signifie que l'outil sert d'accélérateur de développement plutôt que de dépendance d'exécution. L'intégration avec les pipelines CI via la commande build --check garantit que si un fichier SQL diverge de sa spécification originale, la construction échoue, maintenant la cohérence entre l'intention et l'implémentation.

Ce que vous pouvez faire

• Installez Portia en utilisant uv et Docker, en veillant à disposer de Python 3.11+.
• Connectez l'outil à une base de données de test ou à un dossier de fichiers CSV d'exemple pour explorer ses capacités de profilage.
• Utilisez le module devtools.demodata pour générer un projet de démonstration à cinq tables avec des problèmes connus pour les tests.
• Configurez un modèle local comme Qwen 3 8B via Ollama si vous préférez ne pas utiliser d'API cloud.
• Examinez les spécifications YAML générées et les fichiers SQL compilés pour comprendre comment l'agent structure ses décisions.
• Parcourez le graphe de connaissances Neo4j à localhost:7474 pour visualiser la lignée des colonnes et les chevauchements.