Un système d'analyse en langage naturel.

• Un SQL généré vérifié avant d'atteindre la base de données, et non après
• Une exécution en lecture seule, avec une borne sur ce qu'une requête peut coûter
• La requête montrée au lecteur, pas cachée derrière le graphique
• Un fournisseur de modèle remplaçable sans toucher aux appelants

Présentés comme des décisions plutôt que comme des fonctionnalités, parce que chacune a un contraire défendable. Voici dans quel sens celle-ci a tranché et pourquoi.

1. 01

   Valider la requête analysée, pas la chaîne de caractères

   Le SQL généré est analysé et inspecté sous forme d'arbre syntaxique avant l'exécution : ce qui est vérifié, c'est l'instruction que la base de données exécutera réellement, et non un texte qui correspond par hasard à un motif. La recherche de motifs dans du SQL généré échoue dès qu'un modèle formule quelque chose d'une manière que le motif n'avait pas prévue, ce qui est le seul type de cas qui compte.

2. 02

   En lecture seule, borné, à chaque fois

   L'exécution passe par un chemin en lecture seule avec un délai d'expiration par instruction : dans le pire des cas, une mauvaise requête échoue, au lieu de modifier une table ou de bloquer une base de données sous un balayage incontrôlé. C'est cette propriété qui rend tout simplement défendable le fait de brancher le système sur des données réelles.

3. 03

   Montrer le SQL

   La requête générée est affichée et modifiable à côté de son résultat. Elle transforme une mauvaise réponse en réponse déboguable, et c'est la différence entre un outil dont un analyste peut répondre et une boîte noire qu'il doit soit croire entièrement, soit ne pas utiliser.

4. 04

   Le modèle se trouve derrière une interface

   La génération passe par une abstraction de fournisseur plutôt que par le SDK d'un fournisseur appelé directement. Les modèles sont la dépendance qui évolue le plus vite dans la pile, et celle qui risque le plus de voir son prix changer, d'être abandonnée ou d'être dépassée ; l'interface fait de ce changement une modification de configuration plutôt qu'une réécriture.

L'alternative

La cacher. Une question en entrée, un graphique en sortie, rien entre les deux. C'est l'interface la plus nette, c'est ce que promet la catégorie, et c'est la version qui fait bonne figure auprès de quelqu'un qui n'écrit pas de SQL, soit précisément l'acheteur auquel ce type de produit est vendu.

Ce que cela a coûté

L'illusion, et une partie du public avec elle. Une requête visible rappelle qu'une machine a écrit du code exécuté sur votre base de données, et pour un lecteur qui ne peut pas l'évaluer, le panneau est au mieux du bruit, au pire alarmant. Elle expose aussi chaque jointure maladroite que produit le générateur : le produit est donc jugé sur une sortie qu'il préférerait ne pas montrer.

Pourquoi le compromis tient

Le mode de défaillance de cette catégorie n'est pas une erreur, c'est une réponse fausse énoncée avec assurance, et un chiffre sans dérivation visible ne se distingue pas d'un chiffre exact. Cacher la requête supprime le seul mécanisme par lequel un lecteur pourrait un jour s'en apercevoir. Le coût se paie en finition ; l'alternative se paie la première fois que quelqu'un prend une décision sur un chiffre qui n'a jamais été juste.

• ArticleDes scripts shell qui passent à l'échelleÉchouer bruyamment plutôt qu'en silence, au niveau du code de liaison. Un système qui avale une erreur et renvoie quand même un chiffre est exactement la défaillance autour de laquelle cette réalisation est écrite.
• ServiceInfrastructure d'IA et orchestration d'agentsL'offre permanente dont relève cette réalisation, avec ce qui est livré et ce que cela vous apporte, offre par offre.