Dataherald est un moteur de conversion de langage naturel vers SQL AI au niveau de l'entreprise qui permet aux utilisateurs non techniques d'interroger directement la base de données via une conversation sans écrire d'instructions SQL.

Dataherald

Paramètres de base et statistiques de Dataherald

Dataherald se positionne officiellement comme un moteur de conversion langage naturel vers SQL au niveau de l'entreprise. Sa valeur fondamentale est de permettre aux utilisateurs non techniques d'interroger directement les bases de données relationnelles via des conversations quotidiennes, sans que l'équipe chargée des données n'ait besoin d'écrire des instructions SQL. La différence fondamentale entre celui-ci et les outils de BI traditionnels est qu'il ne s'appuie pas sur des tableaux de bord prédéfinis ou des modèles de rapport fixes, mais analyse les intentions des utilisateurs en temps réel, génère dynamiquement des instructions de requête et prend en charge plusieurs cycles de dialogue pour affiner progressivement les exigences.

Projets	Informations publiques
Positionnement officiel	Moteur de langage naturel vers SQL de niveau entreprise
Capacités de base	NL2SQL, contexte de dialogue multi-tours, génération SQL complexe (fonction JOIN/sous-requête/agrégation/fenêtre)
Bases de données prises en charge	PostgreSQL, MySQL, BigQuery, Snowflake, Databricks, MS SQL Server, ClickHouse, MariaDB, Redshift
Stockage vectoriel	Pomme de pin, Astra, Chroma
Méthode de déploiement	Auto-hébergement (Docker Compose), hébergement cloud (Enterprise Edition)
Méthode de saisie	Langue naturelle (principalement anglais)
Format de sortie	Instruction SQL + résultat de la requête + exportation CSV
Licence Open Source	Apache-2.0
Étoiles GitHub	~3 600
Fourches GitHub	~264
Contributeurs au code	19
Dernière version	v1.0.3 (30/04/2024, versions GitHub)
Total des sorties	9 versions
Langues de base	Python (58,5%), TypeScript (39,3%)
Composants du système	Moteur, API d'entreprise, console d'administration, Slackbot

Architecture de déploiement : Dataherald adopte une architecture de microservices, comprenant quatre composants indépendants : Engine (moteur principal NL2SQL), Enterprise (gestion des utilisateurs/organisations/authentification), Admin Console (interface de gestion) et Slackbot (intégration Slack). Chaque composant est orchestré uniformément via Docker Compose, prenant en charge le déploiement fractionné à la demande.

Étendue de la couverture des bases de données : De la v0.0.1 à la v1.0.3, Dataherald a progressivement intégré 9 types de bases de données relationnelles et 3 types de stockage vectoriel, couvrant les entrepôts de données grand public OLTP (MySQL, PostgreSQL, SQL Server), OLAP (ClickHouse, Redshift) et cloud (BigQuery, Snowflake, Databricks). C'est son différenciateur clé de la solution NL2SQL qui ne prend en charge qu'un seul type de base de données.

Rythme d'itération : la première version publique v0.0.1 (2023-08), v1.0.0 (2024-01), v1.0.3 (2024-04), après quoi la fréquence de validation de GitHub a considérablement diminué et est actuellement en période de maintenance. Lors de la sélection, vous devez évaluer l’activité de la communauté et les risques de support à long terme.

Utilisateurs de Dataherald et reconnaissance du marché

La reconnaissance de Dataherald sur le marché se reflète principalement dans les commentaires de la communauté open source et la vérification PoC de l'entreprise. Le responsable n'a pas divulgué de données spécifiques sur les revenus, le nombre de clients payants ou les détails de l'engagement SLA.

Popularité de la communauté GitHub : plus de 3 600 étoiles et 264 forks, ce qui se situe à un niveau moyen supérieur dans la piste open source NL2SQL. Comparaison de projets similaires : SQLChat a environ 4 000 étoiles, Vanna a environ 12 000 étoiles et DB-GPT a environ 14 000 étoiles. Dataherald se caractérise par la fourniture d'un ensemble complet de quatre composants (Engine + Enterprise + Admin Console + Slackbot), qui est plus proche d'un formulaire de livraison au niveau de l'entreprise que la plupart des projets qui ne fournissent qu'un moteur d'inférence de base.

Scénario de vérification d'entreprise : les cas d'utilisation typiques mis en évidence dans la documentation officielle et dans le fichier README de GitHub incluent des fonctionnalités de questions-réponses intégrées au sein du SaaS, des robots de comptage en langage naturel basés sur Slack et des portails de comptage en libre-service pour les équipes commerciales. Ces cas d'utilisation s'adressent aux moyennes et grandes entreprises qui ont investi dans des entrepôts de données mais manquent de personnel analytique, plutôt qu'aux petites et micro-équipes.

Coopération écologique : le projet intègre LangSmith pour l'observabilité, prend en charge trois bases de données vectorielles Pinecone/Astra/Chroma comme stockage de contexte de schéma et peut être connecté aux services LLM grand public (série OpenAI GPT Anthropic Claude, modèles auto-hébergés). Cela montre qu’il est conçu pour rester indépendant du modèle et non lié à un seul fournisseur d’IA.

Conditions préalables à l'adoption : la version à valeur réelle de Dataherald nécessite que l'entreprise dispose déjà ① d'actifs de données relationnelles structurées, ② de documents de schéma clairs ou d'échantillons de requêtes privilégiés (Golden SQL) et ③ les équipes informatiques sont disposées à maintenir une infrastructure auto-hébergée supplémentaire. Sans aucun d’entre eux, l’effet d’atterrissage sera considérablement réduit.

Avantages financiers de Dataherald

La structure des coûts de Dataherald doit être examinée séparément des trois niveaux « côté C/utilisateurs individuels », « intégration API/développeur » et « déploiement entreprise/privatisé ».

Client C/utilisateurs individuels :

• Coût explicite : l'édition communautaire open source est entièrement gratuite et la licence Apache-2.0 permet une utilisation, une modification et une redistribution arbitraires. Les développeurs individuels ne doivent supporter que les coûts d'exploitation de leurs propres serveurs (exécutant 4 conteneurs en mode Docker Compose, et la configuration minimale estimée est de 4 cœurs et 8 Go de mémoire).
• Coût caché : vous devez configurer vous-même la clé API LLM (telle que OpenAI, Anthropic), et les frais d'appel LLM sont facturés par jeton. Une requête typique comprenant l'analyse de schéma + la génération SQL consomme environ 2 000 à 8 000 jetons, ce qui augmente avec la complexité de la requête. Dans les scénarios avec des appels fréquents, la surcharge de l'API LLM peut rapidement dépasser les coûts d'infrastructure.

Intégration API/développeur :

• Couche API REST : les versions open source des composants Engine et Enterprise fournissent une API RESTful complète (y compris les invites, les générations SQL, les générations nl, le réglage fin et d'autres points de terminaison), que les développeurs peuvent intégrer gratuitement dans leurs propres applications.
• Coût de réglage : Dataherald prend en charge le réglage fin (Finetuning) basé sur Golden SQL, mais le processus de réglage fin consomme des crédits de formation OpenAI et nécessite la préparation d'échantillons appariés Question-SQL de haute qualité. Le nombre recommandé d’échantillons est de 50 à 200, et le coût d’un seul réglage fin est de l’ordre de plusieurs dizaines de dollars.
• Coûts d'intégration implicites : vous devez configurer manuellement la description du schéma pour chaque connexion à la base de données (ou exécuter une analyse automatique), maintenir la bibliothèque d'exemples Golden SQL et gérer la logique cachée selon laquelle le SQL généré par LLM ne répond pas aux attentes. Ces efforts d’ingénierie sont souvent supérieurs au coût des appels API eux-mêmes.

Déploiement en entreprise/privé :

• Tarif de l'édition Entreprise : Le prix officiel de l'édition Entreprise n'a pas été divulgué. Selon la pratique de l'industrie, on suppose qu'un système d'abonnement est adopté. Les dimensions de facturation incluent généralement : le nombre de connexions à la base de données, le quota d’appels API et le niveau SLA du siège utilisateur. La valeur ajoutée de l'édition Enterprise inclut l'intégration SSO, la journalisation d'audit et la prise en charge SLA dédiée.
• Coût d'infrastructure : le déploiement privé nécessite que l'entreprise gère Docker pour exécuter la base de données MongoDB limitée, la base de données vectorielle et la configuration réseau. Avec une charge modérée de 1 000 requêtes par jour, le coût mensuel de l’infrastructure est estimé entre 100 et 500 USD (hôte cloud + stockage vectoriel + bande passante).
• Coût humain d'exploitation et de maintenance : au moins un personnel de développement ou d'exploitation et de maintenance familier avec les appels Docker et LLM est requis pour être responsable de la maintenance du système, de la gestion des Golden SQL et de la surveillance de la qualité des requêtes. Ce coût caché représente généralement 3 à 5 fois le coût de l’infrastructure.

Comparaison des coûts : solution open source NL2SQL

Solutions	Licence Open Source	Complexité du déploiement	Couverture de la base de données	Prise en charge du réglage fin	Fonctionnalités d'entreprise	Activité communautaire
Héraldique des données	Apache-2.0	Moyen (4 composants Docker)	9 types de base de données + 3 types de stockage vectoriel	✅ API de réglage fin intégrée	✅ Console d'administration + Slackbot + Entreprise	Moyen (3,6 000 étoiles)
Vanna	MIT	Faible (bibliothèque Python)	Prend principalement en charge SQLite/PG	✅ Formé via les documents DDL	❌ Aucun	Élevé (12 000 étoiles)
SQLChat	MIT	Faible (Bibliothèque de nœuds)	Prend principalement en charge MySQL/PG	❌ Aucun	❌ Aucun	Moyen (4 000 étoiles)
DB-GPT	Apache-2.0	Élevé (composants multiples)	Plusieurs bases de données	✅Assistance	✅ Fonctionnalités d'entreprise complètes	Élevé (14 000 étoiles)

Points saillants de la différence de coût :

• Dataherald fournit le package de niveau entreprise le plus complet de la solution open source NL2SQL (intégration de la console d'administration Slack, multi-location, prêt pour les journaux d'audit), adapté aux équipes qui ont besoin de « prêts à l'emploi » plutôt que de créer à partir de zéro.
• Si vous disposez déjà de crédits API LLM et avez une faible tolérance à la complexité du déploiement, Vanna (installation d'une seule bibliothèque Python) ou SQLChat (package Node.js) ont des coûts de démarrage initiaux inférieurs.
• DB-GPT est leader en termes d'exhaustivité fonctionnelle et d'échelle communautaire, mais sa complexité de déploiement est également plus élevée et il est principalement optimisé pour les scénarios chinois, ce qui est différent du positionnement anglophone de Dataherald.

Principales fonctions de Dataherald

• Natural Language to SQL (NL2SQL) : saisissez « Classement des ventes par région au cours du dernier trimestre », le moteur reconnaît automatiquement l'intention d'agrégation et génère des instructions SQL avec GROUP BY et ORDER BY. Le mécanisme de base consiste à mapper les questions des utilisateurs au schéma de base de données via LLM, puis à combiner le contexte de conversation pour synthétiser du SQL exécutable. La différence avec les outils BI traditionnels réside dans le fait qu’il n’existe pas de structure de rapport prédéfinie et que les utilisateurs peuvent décrire librement toutes les dimensions de la requête.

• Plusieurs cycles de préservation du contexte de dialogue : continuez à poser des questions en fonction du premier résultat de la requête (comme « Voir uniquement la Chine orientale » ou « Modifier l'affichage par mois »). Le moteur conserve les conditions de filtre et la logique d'agrégation du SQL de pré-commande, et ne modifie que de manière incrémentielle la clause WHERE ou le champ GROUP BY. La véritable valeur de cette solution pour les utilisateurs professionnels réside dans le fait qu'il n'est pas nécessaire de décrire toutes les exigences d'un coup et que la portée de la requête peut être progressivement réduite, comme une conversation avec un humain. Les tours interactifs d'une même tâche d'analyse sont généralement étendus de 1 tour à 3 à 5 tours, mais chaque tour reste sémantiquement cohérent.

• Connaissance automatique du schéma de base de données : le moteur analyse automatiquement la structure des tables de base de données, les noms de champs, les types de champs, les relations de clés primaires et étrangères, et fait automatiquement correspondre les alias de champ et les clés associées lors de la génération de SQL. Les résultats de l'analyse de schéma sont stockés dans les bases de données MongoDB et vectorielles. Lors de la génération de SQL, LLM récupère uniquement les tables et les champs liés aux questions des utilisateurs en tant que contexte, évitant ainsi que l'intégralité du schéma ne soit insérée dans l'invite et ne provoque une expansion des jetons.

• Explication en langage naturel des résultats de requête (génération NL) : pour les instructions SQL générées et les résultats d'exécution, le moteur génère automatiquement des explications en langage naturel pour expliquer "quel filtrage a été effectué pour ce SQL, par quelles dimensions ont été agrégées et quelle est la base du tri". L'intérêt clé de cette fonctionnalité pour les utilisateurs non techniques est que même s'ils ne comprennent pas SQL, ils peuvent comprendre si la logique de requête est correcte, établissant ainsi la confiance dans les résultats générés par l'IA.

• Gestion des Golden SQL et réglage fin du modèle : prend en charge le stockage des paires "question-SQL" vérifiées dans la collection Golden SQL et le réglage automatique (Finetuning) des modèles de la série GPT en fonction de ces échantillons. La précision du modèle affiné sur des requêtes métiers similaires est considérablement améliorée. Il s'agit d'un mécanisme « plus précis plus vous l'utilisez » : dans la phase initiale, il s'appuie sur la connaissance du LLM général, et à mesure que l'entreprise accumule des échantillons de requêtes propriétaires, la précision converge progressivement vers 90 %+.

• Visualisation des étapes intermédiaires (Streaming) : Le point de terminaison Streaming introduit dans la v1.0.2 montre les étapes de raisonnement intermédiaires de la génération SQL - de la récupération du schéma à la synthèse SQL en passant par l'exécution des résultats - permettant aux utilisateurs et aux développeurs de voir la chaîne de réflexion de l'IA, facilitant le débogage et l'établissement de la confiance.

• Robot de requête intégré Slack : grâce au composant Slackbot, les utilisateurs peuvent directement utiliser le langage naturel pour poser des questions à la base de données dans le canal Slack, et le robot renvoie les résultats de la requête ou les fichiers CSV. Ceci est particulièrement utile pour les équipes opérationnelles, marketing et commerciales sans formation technique : il n'est pas nécessaire d'ouvrir des outils BI pour finaliser l'acquisition de données dans les flux de travail quotidiens.

• Exportation CSV et stockage de fichiers : les résultats de la requête peuvent être directement exportés au format CSV et stockés dans S3 (en configurant les informations d'identification AWS), ce qui convient à une analyse secondaire ultérieure dans Excel ou Google Sheets. Utilisez automatiquement le stockage de fichiers lorsque le nombre dépasse 50 lignes pour éviter que la charge utile de la réponse de l'API ne soit trop volumineuse.

Evolution du modèle et de la version de Dataherald

L’historique des versions de Dataherald reflète clairement le chemin évolutif depuis la vérification des prototypes jusqu’à l’amélioration des fonctionnalités de l’entreprise jusqu’à l’expansion écologique. Ce qui suit est compilé sur la base des informations publiques des versions GitHub.

Version principale

Version	Date de sortie	Changements fondamentaux	Jalons
v0.0.1	2023-08	Version initiale, fonction de requête de base NL2SQL	Approbation du projet, vérification MVP
v0.0.2	2023-09-14	Reconstruction du point de terminaison RESTful, standardisation du nom de collection MongoDB, introduction de l'association db_connection_id	Finalisation de la structure des API, passer du prototypage rapide à la standardisation
v0.0.3	2023-09-26	LLM Credentials prend en charge l'optimisation des connexions SSH et l'analyse de schéma asynchrone	Les capacités de connexion d'entreprise sont améliorées et les performances d'analyse sont optimisées
v0.0.4	2023-10-07	Le point de terminaison renomme ObjectId clé étrangère NL génération divisée	La sémantique de l'API est claire, préparez-vous à la version 1.0
v0.0.5	2023-10-26	champ llm_api_key stockage S3 CSV simplifié, système de code d'erreur	Configuration simplifiée et observabilité améliorée
v0.0.6	2023-11-14	Drapeau de génération CSV Certificat S3 configurable	Capacités d'exportation de données améliorées
v1.0.0	2024-01-17	API de réglage fin, collection Golden SQL divisée en trois phases Prompt/SQL-Generation/NL-Generation	Étape de maturité architecturale
v1.0.1	2024-03-05	ClickHouse prend en charge le support officiel de MariaDB, l'actualisation du point de terminaison et l'affinement du code d'erreur	Extension de la couverture de la base de données
v1.0.2	2024-04-04	MS SQL Server, prise en charge sans serveur Astra/Pinecone Étape intermédiaire de streaming Intégration LangSmith	Connexion écologique et amélioration de l'observabilité
v1.0.3	2024-04-30	Prise en charge de Redshift, prise en charge de plusieurs schémas (PG/BigQuery/Snowflake/Databricks)	La dernière version, parfaite pour les scénarios multi-schémas d'entreprise

Interprétation du contexte évolutif

Phase 1 : Vérification du prototype (v0.0.1-v0.0.2) : Les deux premières versions complétaient principalement le processus de bout en bout « du langage naturel au SQL ». La refactorisation de l'API RESTful dans la version 0.0.2 jette les bases de toutes les fonctionnalités d'entreprise ultérieures.

Phase 2 : Création des capacités de connexion d'entreprise (v0.0.3-v0.0.6) : connexions SSH progressivement complètes, plusieurs bases de données prenant en charge l'exportation CSV vers le stockage S3, systèmes de codes d'erreur et autres fonctionnalités d'IA nécessaires à l'entreprise mais non essentielles. Cette étape montre que l'équipe Dataherald se rend compte que l'obstacle à la mise en œuvre de NL2SQL dans les entreprises n'est pas seulement la précision de l'IA, mais aussi la connectivité des données et l'observabilité de l'exploitation et de la maintenance.

Phase trois : Maturité de l'architecture 1.0 (v1.0.0) : la v1.0.0 est un changement architectural majeur qui divise le processus original unique « question → réponse » en un pipeline en trois étapes : invite (compréhension du problème) → génération SQL (synthèse SQL) → génération NL (interprétation des résultats) et introduit l'API de réglage fin. La répartition en trois étapes permet à chaque section d'être optimisée, mise en cache et auditée indépendamment, ce qui constitue une décision de conception clé pour le déploiement au niveau de l'entreprise.

Phase 4 : Expansion et maintenance écologiques (v1.0.1-v1.0.3) : Concentrez-vous sur l'expansion de la couverture des bases de données (ClickHouse, MariaDB, SQL Server, Redshift) et des options de stockage vectoriel (Astra, Pinecone sans serveur), tout en améliorant l'observabilité via les points de terminaison de streaming. Après la version 1.0.3, le projet est entré dans une période de maintenance peu active et aucune nouvelle version de fonctionnalité n'a été publiée.

Vérification des candidats et contribution de la communauté

En plus des versions principales, Dataherald suscite la participation de 19 contributeurs via des demandes d'extraction et des problèmes, couvrant les corrections de bogues, les améliorations de la documentation et les améliorations mineures des fonctionnalités. Mais dans l’ensemble, le développement principal du projet est mené en interne par l’équipe, et les contributeurs de la communauté se concentrent principalement sur la documentation et les fonctions marginales.

Évaluation de la stratégie de version : la dénomination des versions de Dataherald suit la spécification sémantique de version (SemVer), mais cela n'a pris que 8 mois entre la v0.0.1 et la v1.0.3, puis a stagné. Lors de la sélection, vous devez évaluer : si les fonctions actuelles répondent aux besoins et si vous êtes prêt à accepter le risque d'un fork communautaire ou d'un auto-entretien.

Les avantages techniques de Dataherald

L'avantage technique de Dataherald ne réside pas dans la percée d'un algorithme unique, mais dans la conception de l'architecture d'ingénierie : comment encapsuler les capacités NL2SQL de LLM dans un système au niveau de l'entreprise qui peut être implémenté, observable et itérable.

Architecture de pipeline en trois étapes

Dataherald divise le traitement d'une requête en langage naturel en trois étapes indépendantes :

Entrée utilisateur → [Invite] → [Génération SQL] → [Génération NL] → Sortie utilisateur
                 ↓ ↓
           Récupération de vecteurs de schéma Correspondance Golden SQL

• Étape d'invite : recevez les entrées en langage naturel de l'utilisateur, combinez l'historique des conversations (le cas échéant) et les informations de schéma pertinentes extraites de la base de données vectorielles, et assemblez-les dans une invite conviviale LLM. L'optimisation clé est la suivante : au lieu d'injecter l'intégralité du schéma de base de données en une seule fois, seuls les tables et les champs les plus pertinents pour le problème de l'utilisateur sont sélectionnés via la récupération de similarité vectorielle, ce qui réduit considérablement la consommation de jetons et réduit la distraction du LLM.
• Phase de génération SQL : envoyez l'invite assemblée à LLM pour générer du SQL. Si le modèle de réglage fin Golden SQL est configuré, utilisez d'abord le modèle de réglage fin pour améliorer la précision ; sinon, revenez au modèle général. Le point de terminaison Streaming introduit dans la version 1.0.2 permet de visualiser en temps réel les étapes de raisonnement intermédiaires de la génération SQL - chaîne de pensée de LLM, processus de correspondance de champs, sélection des conditions JOIN - ce qui est essentiel pour le débogage et l'établissement de la confiance.
• Phase de génération NL : utilisez le langage naturel pour expliquer à l'utilisateur "ce que cette requête a fait" pour le SQL généré et les résultats d'exécution. Il s'agit d'une conception sous-estimée mais extrêmement précieuse : les utilisateurs non techniques ne peuvent généralement pas lire SQL, mais grâce à l'interprétation du langage naturel, ils peuvent rapidement juger si la logique de la requête est correcte et décider d'accepter ou non les résultats.

Collaboration entre la connaissance des schémas et la récupération de vecteurs

Le mécanisme de gestion des schémas de Dataherald constitue la principale ligne de démarcation entre celui-ci et le simple wrapper Prompt :

1. Analyse automatique : analysez la base de données via la tâche en arrière-plan asynchrone du point de terminaison POST /api/v1/table-descriptions/sync-schemas pour obtenir les noms de tables, les noms de champs, les types de champs, les commentaires et les relations de clés primaires et étrangères.
2. Stockage vectorisé de schéma : Vectorisez les informations de description de la table et du champ (nom + commentaire) à l'aide du modèle d'intégration et stockez-les dans la base de données vectorielles Pinecone/Astra/Chroma.
3. Récupération à l'exécution : lorsque l'utilisateur pose une question, effectuez d'abord l'intégration sur la question, récupérez les tables et les champs associés au Top-K dans la bibliothèque vectorielle et injectez uniquement ces contextes dans l'invite LLM.
4. Mise en cache incrémentielle : les résultats de l'analyse sont mis en cache dans MongoDB, prenant en charge les mises à jour incrémentielles plutôt que la reconstruction complète. Le point de terminaison POST /api/v1/table-descriptions/refresh (introduit dans la v1.0.1) est conçu pour actualiser efficacement la liste des tables sans réanalyser toutes les données.

L'importance technique de ce mécanisme réside dans le fait que les bases de données d'entreprise contiennent souvent des centaines de tables et des milliers de champs. Si tous sont injectés dans le contexte LLM, la consommation de jetons sera inacceptable et LLM sera sérieusement distrait. La récupération de vecteurs + l'injection dynamique contrôlent le contexte de schéma de chaque requête dans 3 à 8 tables, en tenant compte à la fois de la précision et du coût.

Golden SQL fermés par itération

Le mécanisme de réglage fin de Dataherald constitue un processus d'optimisation continu :

Requête métier → Génération SQL → Révision manuelle → Stocker dans Golden SQL → Affiner le modèle → Améliorer la précision
                                                      ↑
                                              Déclenchez périodiquement le réglage fin

• Golden SQLs Collection : stocke les paires validées « Question en langage naturel ↔ SQL standard ». Chaque paire contient question, sql, db_connection_id et métadonnées.
• Processus de réglage fin : appelez POST /api/v1/finetuning pour créer une tâche de réglage fin, et le moteur formate automatiquement les Golden SQL dans le format d'ensemble de données requis pour le réglage fin d'OpenAI et le soumet. Une fois le réglage fin terminé, vous pouvez interroger l'état via GET /api/v1/finetuning/{id}. Si le statut est SUCCEEDED, il peut être utilisé pour la génération SQL.
• Résultats réels : selon la documentation officielle, le modèle affiné améliore considérablement la précision de la génération SQL dans les domaines métier propriétaires. Bien que la valeur précise ne soit pas divulguée, elle est logiquement raisonnable : le modèle général peut comprendre que les « ventes » sont SOMME (montant), mais ne comprend pas les « ventes nettes = SOMME (montant) - SOMME (remise) - SOMME (retour) » spécifiques à l'entreprise ; après un réglage fin, le modèle peut apprendre ces règles métier.

Indépendance et remplaçabilité du modèle

Dataherald maintient l'abstraction du LLM sous-jacent au niveau architectural : le moteur accède à différents modèles via des interfaces de configuration et n'est pas lié à un seul fournisseur OpenAI. La prise en charge officielle inclut GPT-4/GPT-3.5, la série Claude et les modèles auto-hébergés (via un déploiement local compatible avec le format API OpenAI). Cette conception a une valeur pratique dans les achats d'entreprise : vous pouvez utiliser GPT-4 pour atteindre la limite supérieure de précision de la vérification PoC et passer à un modèle auto-hébergé après la mise en ligne pour réduire les coûts d'inférence et contrôler la souveraineté des données.

Multilocation et isolation des autorisations

Le composant Entreprise fournit une gestion des utilisateurs à l'échelle de l'organisation, des autorisations de rôle et une isolation des connexions à la base de données. Chaque connexion à la base de données peut être configurée avec une clé API LLM indépendante, prenant en charge le mode lecture seule (empêchant la génération d'instructions UPDATE/DELETE/DDL) et la désensibilisation des données. Ces mécanismes sont strictement nécessaires dans des scénarios multi-départements ou multi-clients : différents départements ne peuvent interroger que les tables et les données dans le cadre de l'autorisation.

Comment utiliser Dataherald

Dataherald propose plusieurs entrées et méthodes d'intégration, couvrant différents scénarios d'utilisation, de l'intégration de l'API du développeur à l'interaction Slack de l'équipe commerciale.

Comparaison des entrées de déploiement

Entrée	Personnes concernées	Méthode de démarrage	Pré-requis
API du moteur (moteur principal)	Développeur	Docker Compose exécute le service Engine	Docker, MongoDB, clé API LLM
API d'entreprise (toutes les fonctionnalités)	Développeur/Administrateur informatique	Docker Compose exécute les 4 services	Docker, MongoDB, clé API LLM de base de données vectorielles
Console d'administration (interface d'administration)	Analyste/Administrateur de données	Lancé avec Enterprise, accès par navigateur	API d'entreprise en cours d'exécution
Slackbot	Équipes commerciales	Lancé avec Enterprise, configuration de l'application Slack	API d'entreprise + autorisations de l'application Slack
API REST	Développeur	Appeler directement le point de terminaison Engine/Enterprise	URL de base de l'API déployée

Déploiement et démarrage rapides (auto-hébergé)

Exigences de configuration minimales (niveau PoC) :

# 1. Cloner le référentiel
clone git https://github.com/Dataherald/dataherald.git
cddataherald

# 2. Configurez les variables contextuelles (reportez-vous à .env.example dans chaque répertoire de service)
# Au moins configuration requise : OPENAI_API_KEY, MONGODB_URI

# 3. Démarrez tous les services en un seul clic
./docker-run.sh

La commande ci-dessus démarrera Engine (port 80), Enterprise (port 81), Admin Console (port 3000) et Slackbot et créera automatiquement un réseau Docker. Après le démarrage, la console de gestion est accessible via « http://localhost:3000 ».

Exemple d'appel API

Créer une connexion à la base de données :

curl -X POST http://localhost:80/api/v1/database-connections \
  -H "Type de contenu : application/json" \
  -d '{
    "alias": "production_db",
    "connection_uri": "postgresql://user:password@host:5432/mydb",
    "llm_api_key": "<VOTRE_LLM_API_KEY>"
  }'

Synchroniser le schéma :

curl -X POST http://localhost:80/api/v1/table-descriptions/sync-schemas \
  -H "Type de contenu : application/json" \
  -d '{"db_connection_id": "<connection_id>"}'

Lancer une requête en langage naturel :

curl -X POST http://localhost:80/api/v1/prompts/sql-generations \
  -H "Type de contenu : application/json" \
  -d '{
    "db_connection_id": "<connexion_id>",
    "question": "Classement des ventes par région au dernier trimestre"
  }'

Modèle affiné :

curl -X POST http://localhost:80/api/v1/finetuning \
  -H "Type de contenu : application/json" \
  -d '{
    "db_connection_id": "<connexion_id>",
    "golden_sql_ids": ["<id1>", "<id2>"]
  }'

Processus d'utilisation typique

1. Initialisation : Déployer le service → Créer une connexion à la base de données → Synchroniser le schéma → Confirmer que l'état de l'analyse est SYNCHRONISÉ.
2. Vérification : Soumettez plusieurs requêtes de base (SELECT simple, filtrage conditionnel) pour vérifier la qualité de la génération et l'exactitude de l'exécution.
3. Accumuler des échantillons : pour les requêtes commerciales à haute fréquence, stockez les paires Question-SQL vérifiées dans des Golden SQL.
4. Finetuning : le réglage fin est déclenché après avoir accumulé plus de 50 échantillons pour améliorer la précision du domaine vertical.
5. Allez en ligne : configurez les autorisations du rôle de console d'administration → Ouvert aux équipes commerciales → Surveillez les journaux de requêtes et les taux d'erreur.
6. Itération : examinez régulièrement les journaux de requêtes, ajoutez de nouveaux modèles de requêtes aux Golden SQL et continuez les réglages.

Notes prédéfinies

• Si les noms de table et de champ de la base de données de l'utilisateur sont dans une langue autre que l'anglais (comme le chinois), l'analyse de schéma et la compréhension LLM de Dataherald seront considérablement réduites - c'est l'une des principales limitations linguistiques de la version actuelle.
• Pour les utilisateurs de production, il est recommandé d'activer d'abord le mode lecture seule, puis d'assouplir les autorisations après avoir confirmé que la génération SQL ne provoquera pas d'opérations UPDATE/DELETE inattendues.
• L'analyse automatique du schéma peut prendre plusieurs minutes pour les grandes bibliothèques. Le point de terminaison « /refresh » introduit dans la version 1.0.1 peut réduire considérablement le temps de mise à jour incrémentielle.

Prix des produits pour Dataherald

Le système de tarification de Dataherald est divisé en deux voies : la version communautaire open source et la version commerciale d'entreprise. Le prix officiel de la version entreprise n'a pas été divulgué.

Édition communautaire Open Source (Apache-2.0) :

• Frais : Entièrement gratuit, aucune limite sur le nombre d'utilisateurs, le volume de requêtes ou les connexions à la base de données.
• Contenu inclus : Tout le code source d'Engine (moteur principal) + Enterprise (API multi-tenant) + Admin Console (interface de gestion) + Slackbot (intégration Slack).
• Conditions applicables : Vous avez besoin de votre propre serveur ou hôte cloud pour exécuter Docker Compose et configurer vous-même MongoDB, la base de données vectorielle et la clé API LLM.
• Restrictions d'utilisation commerciale : La licence Apache-2.0 permet une utilisation et une modification gratuites, mais le produit ne peut pas être redistribué directement en tant que service SaaS (sous réserve des termes de la licence).

Édition Entreprise (tarif non divulgué) :

• Estimatif pour inclure : intégration SSO (SAML/OIDC), journaux d'audit, prise en charge SLA dédiée, assistance technique prioritaire, guide de déploiement de niveau entreprise.
• Spéculation de la dimension de facturation : un modèle d'abonnement combiné basé sur le nombre de connexions à la base de données + les appels API mensuels + le nombre de sièges utilisateur. En ce qui concerne des projets de commercialisation open source similaires (tels que N8n, Appsmith), les frais annuels pour la version entreprise peuvent être compris entre 5 000 et 50 000 dollars, mais il ne s'agit que d'une inférence de l'industrie et le devis officiel prévaudra.
• Méthode d'acquisition : Vous devez contacter l'équipe commerciale officielle pour obtenir un devis et un essai. Le site officiel ne propose pas d’entrée d’achat en libre-service.

Frais d'appel LLM (séparés des frais de produit Dataherald) :

• Il s'agit d'un coût supplémentaire pour l'utilisation de Dataherald et dépend directement du choix de l'utilisateur du fournisseur LLM et du volume d'appels.
• Une requête NL2SQL typique de GPT-4 consomme environ 2 000 à 5 000 jetons (schéma d'entrée + question) et coûte environ 0,01 à 0,03 $/heure sur la base de GPT-4. Les frais mensuels LLM pour les scénarios à haute fréquence (en moyenne 10 000 fois par jour) sont de 3 000 $ à 9 000 $.
• L'utilisation de GPT-3.5-Turbo ou d'un modèle auto-hébergé peut réduire ce coût de 10 à 30 fois, au détriment possible de la précision de la construction.
• Il est recommandé que le coût des appels LLM soit réservé dans le modèle budgétaire, qui dépasse généralement le coût de la propre infrastructure de Dataherald.

Scénarios d'application de Dataherald

Scénario 1 : L'équipe commerciale collecte elle-même les données

Description de la tâche : Les équipes non techniques telles que les opérations de marché, la gestion des ventes et l'analyse financière doivent fréquemment obtenir des rapports de l'entrepôt de données. Le processus traditionnel nécessite ① Demander des rapports dans l'outil BI → ② Attendre que l'équipe de l'entrepôt de données planifie → ③ Communiquer à plusieurs reprises les détails sur demande → ④ Obtenir des rapports statiques. Dataherald le simplifie comme suit : les utilisateurs posent des questions en langage naturel directement dans Slack ou dans la console d'administration et obtiennent instantanément les résultats de la requête.

Revenu réel :

• Le cycle de requête unique est réduit d'une moyenne de 4 à 6 heures à 1 à 3 minutes (déduction).
• L'équipe données est libérée du répétitif « écrire SQL-modifier SQL » et se concentre sur la modélisation et la gouvernance des données.
• Les équipes commerciales peuvent explorer librement les données sans attendre la planification, et la vitesse de réponse de la prise de décision est améliorée.

Focus de la vérification de la mise en œuvre : si les utilisateurs professionnels sont prêts à changer l'habitude « d'attendre les rapports » et à poser activement des questions en langage naturel ; et si le taux de précision de première génération des requêtes courantes atteint plus de 70 % (en dessous de cette valeur, les utilisateurs abandonneront).

Scénario 2 : Capacités de questions et réponses sur les données intégrées au produit SaaS

Description de la tâche : Les produits SaaS à forte intensité de données tels que le CRM, l'ERP et la gestion de projet espèrent permettre aux utilisateurs finaux d'interroger les données du produit via un langage naturel au lieu de tâtonner dans des interfaces de filtrage complexes. L'API Engine de Dataherald peut être intégrée en tant que fonctionnalité « assistant d'analyse de données » d'un produit.

Revenu réel :

• Réduisez les coûts d'apprentissage des utilisateurs - pas besoin d'apprendre la syntaxe des filtres, vous pouvez obtenir des données en posant des questions dans votre langue maternelle.
• Réduisez le travail de développement et de maintenance des rapports prédéfinis dans le produit - la génération dynamique remplace les rapports fixes.
• Améliorez la fidélité des utilisateurs et l'activité des données, en transformant la visualisation passive en exploration active et passive.

Focus de la vérification de l'implémentation : si l'isolation des données multi-locataires peut être réalisée avec précision (les utilisateurs du locataire A ne peuvent pas voir les données du locataire B via l'injection SQL) ; et si les performances de réponse du moteur dans des conditions de concurrence élevée (telles que les heures de pointe du SaaS) se situent dans une plage acceptable.

Scénario 3 : Accélération de l'analyse des données - génération de squelettes de requêtes complexes

Description de la tâche : Lorsque les analystes de données professionnels sont confrontés à des exigences d'analyse complexes qui nécessitent des JOIN multi-tables, des fonctions de fenêtre et des sous-requêtes, ils utilisent Dataherald pour générer rapidement des squelettes SQL, puis affinent et optimisent sur cette base.

Revenu réel :

• On estime que l'efficacité de l'écriture SQL augmente de 2 à 3 fois, en particulier pour les structures de tables inconnues (pas besoin de vérifier manuellement la définition du schéma).
• Réduire les erreurs de syntaxe de bas niveau - Les erreurs de condition JOIN, les omissions GROUP BY, l'utilisation abusive des fonctions d'agrégation, etc. peuvent être évitées grâce à la génération d'IA.
• Les analystes peuvent se concentrer davantage sur l'analyse des données et l'interprétation commerciale plutôt que sur le débogage de la syntaxe SQL.

Points clés de la vérification de l'implémentation : Qualité de génération Dataherald pour les requêtes complexes (plus de 4 tables JOIN, CTE récursif, PIVOT dynamique). La version actuelle a une stabilité limitée sur les requêtes très complexes, et les analystes doivent disposer de capacités SQL pour examiner et corriger, plutôt que de se fier entièrement aux résultats générés.

Scénario 4 : opération de données intégrées Slack

Description de la tâche : Les entreprises intègrent des fonctionnalités de requête de base de données dans les canaux de communication professionnels quotidiens via les composants Slackbot. La direction a directement demandé « le nombre de nouveaux clients cette semaine » dans le canal, et le robot a répondu avec les données ; les opérationnels ont demandé « répartition par région », et le contexte est resté cohérent.

Revenu réel :

• Zéro friction dans l'acquisition de données : l'ensemble du processus de comptage, d'analyse et de partage peut être effectué sans quitter Slack.
• Les résultats des requêtes et les enregistrements de conversations sont naturellement enregistrés dans les canaux Slack, formant ainsi un historique de discussion de données traçable.
• Réduire l'effet « îlot de données » au sein de l'entreprise : les rôles non techniques voient les conversations de données dans les canaux publics et apprennent et imitent subtilement les comportements de requête de données.

Points clés de la vérification de la mise en œuvre : la capacité de Slackbot à maintenir un contexte de conversation longue ; et les risques de non-conformité des données sensibles affichées dans les canaux Slack (si les champs PII doivent être filtrés).

Groupes applicables de Dataherald

Foule d'adaptation de base

• Data Analyst : vous pouvez utiliser Dataherald pour générer rapidement des squelettes SQL, réduire la duplication du travail et consacrer plus de temps à l'analyse des données. La condition préalable à l’adaptation est que les analystes disposent de capacités d’audit SQL et puissent corriger le SQL imparfait généré par l’IA. Scénarios inappropriés : scénarios de production qui ont des exigences de qualité strictes pour les requêtes complexes et ne peuvent tolérer aucune erreur SQL.

• Équipe d'opérations commerciales/marketing/ventes : obtenez des rapports de données directement via le langage naturel, éliminant ainsi la dépendance à l'égard de l'équipe de données. La condition préalable à l'adaptation est que le modèle de données de l'entreprise soit relativement standardisé (les noms de champs sont clairs et annotés) et que les exigences de requête soient principalement basées sur des rapports agrégés (sommes, décomptes, classements, tendances) plutôt que sur une analyse complexe en plusieurs étapes. Scénarios inappropriés : situations qui nécessitent une précision des données extrêmement élevée (comme un rapprochement financier), ou dans lesquelles la langue de la requête est le chinois et les noms des tables/champs sont également en chinois.

• Ingénieur informatique/données : Responsable du déploiement, de la maintenance et de la gestion des échantillons Golden SQL du système Dataherald. La condition préalable à l'adaptation est que l'équipe dispose de capacités d'exploitation et de maintenance de Docker et soit prête à investir du temps dans l'optimisation continue de la configuration du schéma, l'accumulation d'échantillons et le réglage fin du modèle. Scénarios inapplicables : équipes qui ne disposent pas de personnel d'exploitation et de maintenance à temps plein, ou la base de données est un ancien système (les noms de champs n'ont aucun sens et ne sont pas commentés), ou la fréquence de mise à jour des données est extrêmement élevée (niveau par minute) et nécessite une connaissance du schéma en temps réel.

• Chef de produit SaaS/responsable technique : évaluer l'intégration de Dataherald dans ses propres produits pour fournir des capacités d'analyse de données. Le principe de l'adaptation est que le scénario de données du produit est principalement destiné aux utilisateurs orientés requêtes sur le marché anglais américain/européen. Scénarios non applicables : produits ciblant le marché chinois (la précision diminue considérablement lorsque les noms de tables de données et de champs sont en chinois) ou produits nécessitant un audit d'autorisation avancé et une isolation des données multicouche.

Limites et conditions préalables inappropriées

• Limitation de langue : l'analyse de schéma et la génération NL de Dataherald utilisent l'anglais comme langue de travail principale. Bien que le LLM sous-jacent puisse gérer la saisie en chinois, les descriptions des champs de schéma, les messages d'erreur et les interfaces de gestion de l'ensemble du système sont conçus pour l'anglais. Dans les scénarios avec des noms de tables et de champs chinois, il est recommandé de donner la priorité aux solutions d'optimisation chinoises telles que DB-GPT.
• Fragmentation de la base de données : si la base de données d'une entreprise est distribuée sur plus de 50 instances indépendantes, chacune nécessitant une configuration distincte des connexions et des analyses de schéma, les coûts de maintenance augmentent de manière linéaire. Il est recommandé d'accéder uniquement à l'entrepôt de données principal, et les bases de données périphériques nécessitent toujours des méthodes traditionnelles.
• Risque de dépendance au modèle : Dataherald ne lie pas un seul modèle, mais la qualité de la génération SQL dépend fortement des capacités du LLM choisi. Si vous choisissez des modèles peu coûteux tels que GPT-3.5-Turbo, la précision des requêtes complexes peut ne pas répondre aux exigences de production ; si vous choisissez GPT-4, le coût d'inférence peut devenir une charge budgétaire. Il est recommandé de tester simultanément plusieurs combinaisons de modèles pendant la phase PoC.
• Audit de sécurité des données : bien que le composant Entreprise fournisse une authentification de base et une prise en charge multi-tenant, le responsable ne divulgue pas les informations de certification de conformité telles que SOC2/GDPR. Les secteurs où la conformité est forte, comme la finance et le secteur médical, doivent confirmer les conditions de conformité avec l'équipe commerciale avant d'acheter.

Résumé et Outlook

Dataherald fournit une solution open source hautement sophistiquée dans le cadre du parcours NL2SQL au niveau de l'entreprise. Sa valeur fondamentale réside dans l'architecture de pipeline en trois étapes, la récupération de vecteurs prenant en compte les schémas et le mécanisme de réglage fin fermé de Golden SQL. Ces conceptions le distinguent d’un simple wrapper LLM Prompt.

Avantages actuels :

• Large couverture de bases de données (9 types de bases de données relationnelles + 3 types de stockage vectoriel), leader de la solution open source NL2SQL.
• Composants complets (Engine + Enterprise + Admin Console + Slackbot), proches du formulaire de livraison au niveau de l'entreprise.
• Conception indépendante du modèle, non liée à un seul fournisseur LLM, permettant une commutation par coût et scénario.
• Plus la relation « plus vous l'utilisez, plus elle devient précise » formée par Golden SQLs + Finetuning, qui améliore continuellement la précision dans les domaines commerciaux propriétaires.

Limites actuelles :

• Le projet est entré dans une période de maintenance peu active depuis la v1.0.3. Il n'y a pas de nouvelles versions de fonctionnalités d'ici six mois et les contributions de la communauté restent principalement des réparations marginales. Les risques de maintenance à long terme doivent être évalués lors de la sélection d'un modèle, et un plan d'auto-maintenance du fork doit être conservé si nécessaire.
• Prise en charge insuffisante du langage naturel chinois. - L'analyse des schémas et la description des champs. La génération NL est principalement en anglais et l'applicabilité des scénarios des noms de tables/noms de champs chinois est limitée.
• La qualité de génération du SQL ultra-complexe (JOIN avec plus de 5 tables, CTE récursif, PIVOT dynamique, imbrication de sous-requêtes multi-niveaux) n'est pas assez stable, nécessite une révision secondaire par des analystes, et ne peut pas être entièrement automatisée.
• Les informations commerciales clés telles que le prix de la version entreprise, l'engagement SLA et la certification de conformité (SOC2/GDPR) n'ont pas été officiellement divulguées. Les entreprises doivent confirmer une par une via les canaux de vente avant d'acheter.

Perspectives de l'industrie : NL2SQL passe de « utilisable » à « facile à utiliser », et la voie d'ingénierie représentée par Dataherald (connaissance des schémas + fermeture de réglage fin + collaboration multi-composants) est la bonne direction. À mesure que les capacités de base de LLM continuent de s'améliorer (comme la progression de nouveaux modèles tels que DeepSeek-V4 et GPT-5 dans la génération SQL), le goulot d'étranglement en matière de précision de NL2SQL sera progressivement atténué. D’ici là, les plates-formes de niveau intermédiaire comme Dataherald qui disposent de suffisamment de préparations techniques en bénéficieront directement. Mais le principe est que le projet peut reprendre son rythme de maintenance, sinon il sera dépassé en termes de fonctionnalité et d'écologie par des alternatives avec une activité communautaire plus élevée (telles que DB-GPT, Vanna).

Évaluation des risques d'approvisionnement/d'adoption : Il est recommandé que Dataherald soit présenté comme un « accélérateur de requêtes de données à chemin non critique » plutôt que comme une « infrastructure de données de base ». Utilisez d'abord la version open source pour effectuer un PoC dans une petite zone (1 à 2 équipes commerciales et 5 à 10 tables principales) pendant 2 à 4 semaines, en vous concentrant sur la vérification ① si la précision des requêtes en anglais atteint plus de 70 %, ② les performances d'analyse de schéma et de récupération de vecteurs sur la propre base de données, et ③ l'amélioration de l'effet après un réglage fin. Une fois le PoC adopté, nous évaluerons s’il peut être étendu à un plus large éventail de scénarios commerciaux et si des services de support de versions d’entreprise sont nécessaires. Si le projet ne revient pas à la maintenance active pendant une longue période, il est recommandé de donner la priorité à l'évaluation des alternatives avec une communauté plus active comme cibles de migration.

Outils associés : github-copilot, Curseur

Informations de version

• Version stable ：La première version stable prend en charge le contexte de dialogue à plusieurs tours, les JOIN complexes et la génération de sous-requêtes. Il n’y a pas encore de date officielle précise. （~2025-06）
• Bêta ：Version bêta test, prend en charge les requêtes Text-to-SQL de base, pas encore de date officielle précise. （~2025-03）