Quel modèle d’IA utiliser pour générer une application

Pourquoi il n’y a pas de vainqueur unique

Une compilation complète traverse des étapes qui ne se ressemblent pas :

Planifier, c’est décider quoi construire à partir d’une demande ambiguë. Cela demande du raisonnement et tolère la latence : dix secondes pour une décision qui évite une demi-heure de travail à côté sont bien dépensées.

Générer, c’est écrire beaucoup de fichiers qui suivent des règles connues. Cela demande du débit et de l’obéissance au format, et c’est l’étape où le modèle cher rend presque exactement ce que rend le modèle bon marché.

Corriger, c’est lire une erreur de compilateur et modifier le bon passage. C’est l’étape la plus sensible au raisonnement, parce qu’une correction fausse casse ce qui marchait.

Relire ce qui a été construit, c’est comparer du code à un critère écrit en langage courant. C’est de la lecture, pas de l’écriture, et un petit modèle le fait bien.

Relire les écrans exige la vision. Ce n’est pas une préférence : un modèle sans vision ne peut tout simplement pas regarder la capture et dire que le texte a débordé de la carte.

Un modèle qui gagnerait les cinq relèverait de la coïncidence. En pratique, ce qui gagne, c’est le système qui utilise un modèle différent à chaque étape.

Ce que mesurent les benchmarks, et ce qu’ils ne mesurent pas

Les chiffres qui circulent viennent presque tous de benchmarks de génie logiciel : étant donné un dépôt existant et un défaut signalé, le modèle produit un correctif qui fait passer le test.

C’est une bonne mesure, et elle mesure autre chose. Générer une application de zéro s’en écarte sur trois points que le benchmark ne capte pas :

Il n’y a pas de dépôt à comprendre. La moitié de la difficulté du benchmark consiste à localiser où intervenir dans du code que le modèle n’a jamais vu. En génération, ce problème n’existe pas, et ce qui le remplace, c’est la cohérence entre trente fichiers qui naissent ensemble.

Il n’y a pas de test à faire passer. Dans le benchmark, le critère de succès est objectif et déjà écrit. Dans une application neuve, le critère est ce que la personne a demandé, en langage naturel, probablement incomplet.

Rien ne mesure si c’est beau. Une application qui compile et qui est laide échoue auprès de l’utilisateur et réussit n’importe quel benchmark.

Conclusion pratique : servez-vous des benchmarks pour écarter un modèle mauvais en code, jamais pour départager les deux premiers.

Les familles, et à quoi elles servent

Sans citer de versions, parce qu’elles changent chaque mois et que la page vieillirait avant que vous n’arriviez ici.

Modèles de raisonnement. Ils réfléchissent avant de répondre, dépensent plus de jetons et plus de temps, et tranchent juste là où les autres se trompent. Ils justifient leur prix aux étapes de décision : planifier, et corriger après l’échec d’une correction simple.

Modèles rapides. Une fraction du prix, l’essentiel de la qualité sur les tâches à règle claire. C’est là que doit tourner la majeure partie du volume d’une compilation, parce que la majeure partie est mécanique.

Modèles avec vision. Nécessaires pour tout ce qui implique de regarder le résultat rendu. Sans cela, il n’y a pas de revue visuelle, seulement une revue de code.

Modèles ouverts. Ils ont comblé une bonne part de l’écart en génération de code et facturent bien moins. Ils expliquent la chute du coût par application en deux ans.

Comment Fabapp s’y prend

Nous sommes juge et partie, donc ce qui suit est une description, pas une recommandation. Jugez-la sur ce qui se vérifie en ouvrant la plateforme.

Un catalogue, pas un modèle. La plateforme tient un catalogue de modèles de plusieurs fournisseurs, chacun avec un coût pour mille jetons dérivé du tarif public du fournisseur. Ce catalogue permet de changer quel modèle exécute quelle étape sans toucher au code du produit. Ce que la plateforme fait par ailleurs est sur fonctionnalités.

C’est l’étape qui choisit, pas vous. Par défaut, chaque étape de la compilation utilise le modèle qui lui convient : planification et correction sur des modèles plus solides, génération sur des modèles de débit, revue d’acceptation sur un petit modèle, revue visuelle sur un modèle avec vision. Vous n’avez besoin de rien savoir de tout cela pour construire une application.

Vous pouvez choisir quand même. Le sélecteur de modèle existe, et la clé personnelle aussi : à partir de l’offre Builder, vous connectez votre clé de fournisseur et la consommation passe sur votre compte. Cela intéresse qui a déjà un contrat avec un fournisseur ou qui a besoin que les données transitent par un compte précis.

Le crédit est une unité de coût. La consommation est normalisée par rapport à un modèle de référence, donc un crédit correspond à peu près au même travail quel que soit le modèle qui l’a exécuté. C’est ce qui empêche un changement de modèle de modifier en silence la portée de votre offre.

La correction n’est pas à votre charge. Quand la vérification échoue et que le système corrige, ce tour ne vous est pas facturé. La plateforme corrigeant sa propre sortie n’est pas un service rendu.

Quand il vaut la peine de changer de modèle

Dans la plupart des cas, non. Trois situations où si :

Vous avez un contrat avec un fournisseur. Votre clé transforme un coût de plateforme en un coût que vous payez déjà.

Vous avez une exigence sur le trajet des données. Certains contrats d’entreprise et certaines réglementations l’imposent, et c’est une exigence légitime à laquelle le sélecteur répond.

Vous générez quelque chose d’inhabituel. Un domaine très spécifique, une langue peu représentée, un format rare. Là, tester deux modèles sur la même demande répond plus vite que n’importe quelle analyse.

En dehors de ces trois cas, changer de modèle optimise la partie qui n’est pas le goulot. Le goulot, c’est presque toujours la clarté de la demande.

Ce qui améliore réellement le résultat

Si votre but est une meilleure application et non une expérience sur les modèles, voici l’ordre de rendement :

1. Décrivez mieux. L’écart entre une demande vague et une demande précise est plus grand que l’écart entre deux modèles de pointe. Dites qui s’en sert, ce que chaque personne peut voir, et ce qui doit arriver quand quelqu’un envoie le formulaire.

2. Demandez par morceaux. Une grosse demande produit une grosse application médiocre. Trois demandes enchaînées produisent une application que vous avez vérifiée en trois points.

3. Vérifiez sur la base, pas sur l’écran. Le message de succès est exactement ce qu’affiche aussi un formulaire cassé.

4. Seulement ensuite, le modèle. Et vous découvrirez probablement que ce n’était pas nécessaire.

La fin du choix de modèle

C’est la direction de toute l’industrie, et elle est bonne : le choix du modèle est une décision d’infrastructure qui a débordé jusque chez l’utilisateur parce que, pendant un temps, l’écart entre les modèles était trop grand pour être caché. Il se resserre.

Ce qui ne se resserre pas, c’est l’écart entre un système qui se contente d’appeler le modèle et un système qui vérifie ce qui est revenu. C’est là que se décide aujourd’hui la qualité d’une application générée, et c’est la partie qu’aucun fournisseur de modèle ne livre toute faite.

Chez Fabapp, l’offre Free ne demande pas de carte, ce qui en fait la façon la moins chère de comparer cela à n’importe quelle alternative.