- Beaucoup de produits d’IA restent de simples wrappers qui appellent des modèles externes comme ChatGPT via une API, et font entrer dans le produit des risques de différenciation, de coût, de vitesse et de personnalisation
- Une simple approche consistant à appeler un LLM permet de construire rapidement, mais tout le monde peut la copier ; si OpenAI ajoute la même fonctionnalité à ChatGPT, il devient difficile de protéger sa valeur propre
- Les LLM généralistes ont des coûts d’exécution élevés : comme GitHub Copilot, on peut se retrouver avec une structure où l’on facture 10 $ par mois, mais où le coût moyen est de 20 $, et certains utilisateurs coûtent jusqu’à 80 $ par mois
- Visual Copilot de Builder a essayé d’utiliser uniquement des LLM pour transformer des designs Figma en code, mais en raison de la latence des réponses et des limites de qualité, l’équipe est passée à sa propre toolchain
- En pratique, il est plus rapide, moins cher et plus contrôlable de résoudre d’abord le problème avec du code classique, puis d’ajouter des modèles d’IA spécialisés uniquement dans les domaines étroits difficiles à traiter avec du code standard
Les limites d’une simple approche de wrapper LLM
- Beaucoup de produits d’IA créés aujourd’hui ressemblent à des wrappers au-dessus d’autres modèles : ils envoient une entrée en langage naturel à l’API ChatGPT et récupèrent une sortie en langage naturel
- C’est facile à implémenter et cela permet de créer rapidement des fonctionnalités intéressantes, mais si la valeur propre du produit repose sur une technologie d’IA avancée, le risque de copie augmente
- Le schéma où, après qu’une personne a créé une application de chat avec des PDF, plusieurs autres créent des apps similaires, puis OpenAI intègre directement cette fonction dans ChatGPT, se produit lorsqu’il manque une technologie différenciante
- Si le produit se contente d’envoyer une requête à ChatGPT via un bouton et d’afficher la réponse à l’utilisateur, sa défensibilité est la plus faible
- Si la technologie propriétaire est importante et que le LLM n’assiste qu’une petite partie, mais essentielle, la position est meilleure, mais les problèmes de coût et de vitesse demeurent
Le coût et la vitesse sont des contraintes concrètes de mise en produit
- Les LLM sont devenus grands et complexes pour obtenir une large polyvalence, ce qui augmente d’autant leurs coûts d’exécution
- Selon le Wall Street Journal, GitHub Copilot facturait 10 $ par mois à ses utilisateurs, mais son coût moyen était de 20 $, et certains utilisateurs coûtaient à GitHub jusqu’à 80 $ par mois
- Beaucoup de produits n’ont pas besoin d’un gigantesque modèle entraîné sur tout Internet ; 99,9 % du périmètre d’entraînement peut être sans rapport avec un cas d’usage précis
- Il peut arriver que le coût d’exploitation d’un service basé sur un LLM dépasse ce que les utilisateurs sont prêts à payer
- La vitesse influence aussi fortement l’expérience produit
- Dans une expérience comme ChatGPT, où l’on lit les mots un par un, une sortie lente reste acceptable dans une certaine mesure
- Dans une application qui a besoin de la réponse complète avant de passer à l’étape suivante du workflow, la latence dégrade directement l’utilisabilité
- Visual Copilot de Builder a essayé de transformer des designs en code de haute qualité via une conversion par LLM, mais le fait d’envoyer toute la spécification du design puis de recevoir une nouvelle représentation token par token prenait plusieurs minutes, ce qui n’était pas pratique
- La représentation renvoyée par le LLM n’était pas lisible par un humain, si bien que l’état de chargement se résumait presque à un simple spinner, et l’expérience utilisateur était mauvaise
Le fine-tuning seul ne suffit pas à personnaliser efficacement
- Les LLM prennent en charge le fine-tuning, ce qui permet certains ajustements pour les rapprocher de la direction souhaitée
- Builder a appliqué le fine-tuning à une approche consistant à fournir un design Figma en entrée et à obtenir du code en sortie, mais même avec de nombreux exemples, la qualité ne s’est pas améliorée
- Résultat : l’approche était lente, coûteuse et de faible qualité, et il fallait une autre solution
- L’alternative choisie a été de construire sa propre toolchain
- un LLM fine-tuné
- un compilateur personnalisé écrit en interne
- un modèle entraîné en interne
- Aujourd’hui, entraîner son propre modèle n’est plus réservé aux data scientists ou aux titulaires d’un Ph.D. en machine learning ; des développeurs ayant une expérience raisonnable peuvent aussi le faire
- Cette approche aide à créer un produit plus rapide, plus fiable, moins coûteux et plus différencié
Les produits d’IA complexes reposent sur une toolchain, pas sur un seul grand modèle
- Une idée reçue fréquente sur les produits d’IA est que la technologie centrale serait entièrement assurée par un seul modèle intelligent
- Les voitures autonomes ne fonctionnent pas non plus en donnant à une immense IA les entrées des caméras, des capteurs et du GPS pour qu’elle produise directement une action comme tourner à droite
- En réalité, plusieurs modèles spécialisés et du code classique sont reliés entre eux
- Les modèles de vision par ordinateur trouvent et identifient les objets
- Les modèles prédictifs de prise de décision anticipent le comportement des autres
- Les modèles de traitement du langage naturel comprennent les commandes vocales
- Beaucoup de code et de logique classiques produisent le résultat final
- Les voitures autonomes sont un cas beaucoup plus complexe, et il n’est pas nécessaire d’atteindre ce niveau de complexité pour lancer un produit d’IA courant
- Les fonctions automobiles n’ont pas non plus été achevées en une seule fois : elles ont commencé par le stationnement automatique ou l’arrêt automatique de proximité, puis des couches ont été ajoutées pour la correction de sortie de voie et les décisions de conduite complètes
- Comme en logiciel, les fonctionnalités d’IA se construisent en empilant une couche sur la précédente
Résoudre d’abord avec du code classique, puis ajouter de l’IA spécialisée seulement là où c’est nécessaire
- Dans l’approche de Visual Copilot, le point de départ important est de ne pas utiliser l’IA dès le début
- Il faut explorer l’espace du problème avec des méthodes de programmation classiques et d’abord identifier les zones où un modèle spécialisé est réellement nécessaire
- L’approche du « supermodèle », qui consisterait à injecter beaucoup de données Figma dans un modèle pour recevoir directement du code finalisé, est trop complexe
- Les frameworks à prendre en charge sont nombreux
- Les options de styling et de personnalisation sont nombreuses
- Il est difficile de continuer à réentraîner le modèle pour intégrer de nouvelles données
- Cela peut devenir complexe, lent et coûteux, au point de rendre le lancement du produit lui-même difficile
- Builder a d’abord exploré jusqu’où il pouvait aller sans IA
- Chaque nœud de design devait être converti en une cible exprimable en code
- Il fallait comprendre finement des éléments comme les images, l’arrière-plan et le premier plan
- Il fallait traiter avec précision la manière de rendre n’importe quelle entrée responsive
- L’équipe a créé plusieurs algorithmes sophistiqués avec de la logique écrite à la main, par exemple pour convertir des éléments empilés verticalement en flex column et des éléments côte à côte en flex row
- L’IA a été ajoutée au moment où les limites du code standard étaient atteintes
- Détecter automatiquement quelles couches devaient être fusionnées en une seule image est facile pour la perception humaine, mais difficile avec du code JavaScript impératif
- Des types de modèles bien établis, comme la détection d’objets, peuvent être entraînés dans des produits comme Google Vertex AI en choisissant une option via une GUI, puis en préparant et en important les données
- On peut exploiter Internet pour générer les données
- Ouvrir des sites web dans un navigateur avec puppeteer et prendre des captures d’écran
- Parcourir le HTML pour trouver les balises
img - Utiliser la position des images comme données de sortie, et la capture d’écran de la page web comme données d’entrée
- Obtenir ainsi les coordonnées des sous-images et l’image d’origine pour les utiliser comme données d’entraînement d’un modèle de détection d’objets
- En combinant code et modèles d’IA spécialisés, on peut sélectionner un design, cliquer sur Generate code, puis attendre environ une seconde avant d’être redirigé vers Builder.io
- Dans Builder, on obtient un site web entièrement responsive et du code de haute qualité personnalisable, avec prise en charge de divers frameworks et options
Les avantages produit du contrôle de ses propres modèles
- Posséder ses propres modèles permet de ne pas se limiter à envelopper un modèle externe, mais de continuer à améliorer le modèle
- Si l’on dépend uniquement de modèles externes comme ceux d’OpenAI, on ne peut pas garantir le moment où ils deviendront plus intelligents, plus rapides ou moins chers pour un cas d’usage précis
- Le périmètre que l’on peut contrôler uniquement avec du prompt engineering et du fine-tuning reste limité
- Visual Copilot est en bêta et ne parvient pas encore à importer correctement certains designs ; des améliorations sont déployées chaque jour à partir des retours utilisateurs
- Contrôler sa propre technologie permet aussi de mieux répondre aux exigences de confidentialité
- De grandes entreprises très centrées sur la confidentialité indiquent souvent qu’elles ne peuvent pas utiliser OpenAI ni des produits qui utilisent OpenAI
- Certaines exigences imposent que les données n’entrent pas dans des systèmes non autorisés
- Comme Builder contrôle toute la technologie, il peut appliquer des standards de confidentialité élevés
- L’étape LLM n’est pas indispensable, mais plutôt optionnelle, et peut être désactivée
- Les entreprises peuvent aussi connecter leur propre LLM
- un modèle entièrement interne
- un fork de
llama2 - leur propre instance enterprise d’OpenAI
- ou tout autre modèle
- Il faut utiliser l’IA le moins possible, et conserver le code classique comme base rapide, fiable, déterministe, facile à déboguer, à modifier, à gérer et à tester
- La magie du produit ne vient pas du remplacement de tout par l’IA, mais de l’usage de modèles d’IA dans de petits domaines décisifs
1 commentaires
Avis sur Hacker News
Je suis d’accord avec l’idée générale de l’article, mais je ne pense pas que je choisirais la méthode de mise en œuvre proposée par l’auteur.
La conclusion que j’en tire, c’est qu’il ne faut pas trop dépendre des LLM. Cela vaut pour le périmètre des tâches qu’on leur confie, mais aussi pour le fait d’éviter d’être lié à un LLM en particulier.
Par exemple, même si l’on utilise OpenAI en interne, un produit qui concurrence frontalement ChatGPT peut être désavantagé à long terme. Si l’on crée une app permettant de réserver hôtels et billets d’avion via un chatbot, il est très possible qu’un jour ChatGPT, Microsoft ou Google proposent une fonctionnalité similaire, en mieux, et neutralisent ce petit business.
Je pense aussi qu’une dépendance excessive à des choses comme le SDK OpenAI est une perte de temps, et qu’appeler directement l’API REST est plus flexible.
En revanche, ajouter un compilateur à la chaîne d’outils est une autre question. Chaque fois qu’on ajoute un compilateur, on accroît une complexité inutile et la dépendance à un outil spécifique. Si React ou Svelte suffisent, utiliser un transpileur de composants me semble simplement ajouter une chose de plus à apprendre pour créer une application web.
Le message final de l’article devrait, selon moi, être : « construisez la chaîne d’outils la plus efficace pour atteindre votre objectif ». Ajouter beaucoup d’outils ne crée pas de valeur en soi, suivre la façon dont les autres font les choses non plus, et cela vaut non seulement pour l’intégration de LLM dans les apps, mais aussi pour l’ingénierie logicielle en général.
Je ne vois pas bien en quoi l’IA changerait cela, ni si elle ne finira pas par se heurter aux mêmes contraintes.
Ce sera certes unique et pas facile à répliquer, mais vu les langages à prendre en charge, le coût de maintenance sera énorme.
Cette couche d’abstraction supplémentaire donne un peu une impression de factory-factory-factory.
Au contraire, l’IA offre plus de possibilités de spécialisation que la recherche de billets d’avion.
Dans les chatbots destinés à des tâches spécialisées, maintenant que l’interprétation de base du langage est suffisamment bonne, la qualité du modèle de langage généraliste n’est pas le facteur le plus important. Un chatbot de réservation de voyage adapté à mes préférences et intégré à des API de niche pertinentes ne se fera pas facilement évincer par un outil généraliste qui parse un peu mieux les questions, mais veut tout réserver via Expedia.
Sur ce type de marché, une bonne ou une mauvaise recommandation peut aussi créer de la fidélité à la marque ou un rejet ; il est donc difficile d’y voir un marché proche du winner-takes-all.
Ce n’était pas vraiment le cœur du billet.
Leur produit est un outil qui convertit automatiquement des fichiers de design Figma en code React. Pour résoudre ce problème avec du code ordinaire, l’outil approprié est justement un compilateur.
Ils ne disent pas à tout le monde d’utiliser un compilateur.
Dans ce contexte, les critiques générales sur les compilateurs ne tombent pas vraiment juste. L’alternative consiste à utiliser ChatGPT comme un compilateur, et l’article explique de façon assez convaincante pourquoi c’est pire. À moins que vous vouliez dire que le produit consistant à générer du code React est mauvais en soi ?
C’est un article qui donne matière à réflexion, et je suis d’accord avec l’idée de « ne pas utiliser l’IA aussi longtemps que possible ».
L’IA est surtout utile pour les choses qui ne sont possibles qu’avec l’IA. S’il existe une manière de créer une fonctionnalité ou de résoudre un problème sans IA, il vaut mieux le faire ainsi.
Maintenant que tout le monde a accès à des modèles de tout premier plan à peu près dans les mêmes conditions, les bons produits seront forcément définis par ce qui n’est pas l’IA : le workflow, l’UI, l’expérience utilisateur, les performances, bref les bons vieux fondamentaux.
En revanche, je ne suis pas convaincu par le conseil « entraînez votre propre modèle ». Cela peut être une façon de rendre rapidement votre produit obsolète. Il peut vous différencier brièvement, mais si, dans les 6 à 12 mois, OpenAI ou un concurrent très financé sort un modèle nettement meilleur, ce modèle différenciant devient tel quel de la dette technique.
Pour une petite startup, essayer de rivaliser sur les modèles me semble être une énorme distraction. C’est un peu comme créer sa propre base de données au lieu d’utiliser Postgres ou MySQL. Bien sûr, il faut un moat et un produit difficile à copier, mais cela doit se situer dans un domaine où l’on peut réellement devenir le meilleur avec les ressources dont on dispose.
Puis ChatGPT est arrivé, et le travail des concurrents est devenu obsolète du jour au lendemain ; lui a pu rattraper les fonctionnalités d’IA en quelques semaines.
Il avait raison sur ce qu’il fallait construire, mais pas sur les raisons ; au final, cela a été extrêmement bénéfique pour son entreprise.
La différenciation est en réalité un facteur assez important.
C’est un bon article, et je pense qu’il parlera à la plupart des nouvelles startups IA. Mon conseil serait de ne carrément pas créer de produit IA
Le cadre du « produit X » mène rarement à quelque chose qui ajoute de la valeur pour le client. Par exemple : produit web3, produit d’observabilité, produit de vision industrielle, produit IA, etc.
Comme pour toute bonne idée de startup, l’essentiel est de partir d’un besoin utilisateur réel, et non de vouloir utiliser une technologie émergente puis de la plaquer sur un problème. Ajouter une UI à une technologie survendue ne satisfait pas pour autant un besoin utilisateur
Je ne dis pas ça parce que je déteste les LLM, mais la plupart des gens que je connais hors ligne détestent interagir avec des chatbots en tant que produit. Lors de mon récent déménagement, j’ai dû traiter avec les bots de support client de fournisseurs d’énergie, d’eau et d’accès Internet, et ils étaient tous horribles
Partir de « GPT est cool » pour créer un chatbot personnalisé me semble peu susceptible de résoudre un vrai besoin utilisateur ou de mener à une activité durable
Même découvrir un problème suffisamment réel pour justifier un coût technologique sort de la zone de confort de beaucoup de techniciens. Nous supposons qu’un problème est réel ou, pire, nous espérons qu’il l’est, puis nous nous jetons immédiatement sur la solution. Parce que construire est le terrain qui nous est familier
Cette attitude ou ce processus n’est pas mauvais en soi. Dans de nombreux cas où des techniciens ont résolu de vrais problèmes, ce vrai problème est apparu par hasard au fil de la construction, des itérations et des abandons
Ainsi, pour un technicien, la meilleure façon de trouver un vrai problème n’est peut-être pas de rester longtemps dans la découverte du problème, mais d’avoir un meilleur cycle lancement-itération-abandon. Un cycle où l’on observe l’usage actuel pour estimer l’avenir, et où l’on décide vite quoi ne pas construire
Après avoir lu les biographies de plusieurs leaders tech, j’en suis venu à penser que la compétence clé qui les distingue est leur capacité à partir d’un MVP très basique et à affiner de façon exponentielle leur intuition de la demande future en peu de temps
Il y a quelques années déjà, les chatbots existaient, et presque toutes les grandes entreprises avaient une stratégie autour d’eux. L’idée était de réduire fortement les effectifs des centres d’appel et d’améliorer l’expérience client
Le problème n’était pas seulement la qualité de la conversation. Pour beaucoup d’utilisateurs, l’important n’était pas seulement d’obtenir une réponse à leur problème, mais aussi de ressentir une connexion humaine, le fait que quelqu’un les écoute
Ce que je veux, c’est que les choses soient réglées le plus vite possible ; que je parle à une vraie personne ou non m’importe peu
Si les chatbots n’ont pas été utiles jusqu’ici, c’est parce qu’ils ajoutaient du temps et de l’irritation au processus. La première étape consistait à faire cracher un numéro de téléphone au chatbot, ou à réussir péniblement à être mis en relation avec un conseiller
Évidemment, les chatbots d’avant OpenAI étaient médiocres. Mais si les chatbots d’après OpenAI sont vraiment excellents, je ne vois pas pourquoi les gens ne les utiliseraient pas
Il y a quelques années, c’était la blockchain. Je ne sais pas ce qui viendra ensuite, mais on voit déjà le réseau de « techniciens » de LinkedIn passer des startups crypto aux startups IA
Cela ressemble à un arbitrage très coûteux sur la vitesse de lancement
Si vous mettez 6 à 12 mois à lancer, d’autres équipes auront peut-être déjà fait deux itérations avec des modèles hébergés directement et construit une vraie base de clients. À ce moment-là, vous montrerez une v0.1 à votre premier client, qui pourra vous dire qu’en réalité il voulait autre chose
Il ne s’agira alors pas seulement de retoucher un peu le prompt : il faudra recoder le compilateur et la chaîne d’outils, de haut en bas de la stack
Si vous connaissez vraiment bien vos clients et leurs exigences, cela peut se défendre, mais dans une situation aussi favorable, je suis plutôt sceptique face au choix de ne pas valider tôt le concept avec un modèle hébergé, même généraliste et coûteux. C’est le problème du type : l’optimisation prématurée est la racine de tous les maux
Il y avait beaucoup de discussions sur la technologie et le pipeline, mais sans produit à construire ni problème à résoudre, cela n’a aucun sens
C’est un peu comme débattre auprès des utilisateurs pour savoir si SOAP est mieux que REST. Les utilisateurs se moquent de la façon dont c’est construit
Vous réfléchissez beaucoup trop sous l’angle de la concurrence. Il suffit de construire quelque chose qui ne se copie pas facilement
Il y a plusieurs façons d’y parvenir, mais du point de vue concurrentiel, c’est la seule règle nécessaire
Dans presque tous les marchés verticaux, près de 100 % du marché total reste encore ouvert
La différenciation technique n’est qu’une petite partie du sujet ; ce qui compte d’abord, selon moi, c’est la portée
C’est une course vers le milliard d’utilisateurs, et pour du B2B comme nous, probablement une course vers le million d’utilisateurs. En même temps, c’est une course à la meilleure valeur, c’est-à-dire au problème résolu et à l’expérience utilisateur, pas une course aux meilleures spécifications techniques
Si votre différenciation est quelque chose que les autres ne peuvent pas copier avec OAI, alors utiliser OAI est sans risque
Si votre seule différenciation est d’utiliser OAI, vous êtes de toute façon fichu
En conclusion, je suis globalement d’accord avec l’état proposé. Notre produit utilise aussi des LLM dans un flux de contrôle de type machine à états, et cela fonctionne bien
En revanche, je ne partage pas le ressenti de l’auteur. Si un développeur n’a utilisé que l’UI web de ChatGPT, il devrait absolument tester et construire une technologie de « wrapper IA »
Tant qu’on n’a pas exploré soi-même les limites des meilleurs modèles, il est difficile de voir où et comment utiliser les LLM dans une stack logicielle traditionnelle
La société de l’auteur semble d’ailleurs avoir suivi ce chemin. Au départ, elle a construit un prototype basé sur des LLM pour convertir Figma en code, et après que cela a fonctionné « dans une certaine mesure », elle a découvert les failles du processus
Donc je pense qu’il vaut mieux construire ce qu’on veut avec quelque chose comme GPT-4-Vision, que ce soit un « système IA de notation de cartes à collectionner » ou autre, puis chercher ensuite comment en faire un vrai produit fonctionnel, comme builder.io
Il semble probable que l’IA sera bientôt intégrée à de nombreux logiciels. À ce moment-là, cela deviendra à la fois vraiment génial et effrayant
Un exemple simple est le client e-mail. Quand quelqu’un demande une décision ou une confirmation, l’IA pourrait extraire la question et proposer des boutons radio
Exemple : accepter le créneau proposé : [vendredi 10:00] [lundi 11:30] [proposer un autre créneau]
George demande s’il peut présenter le brouillon : [oui] [non]
Les logiciels de tickets de support client comme Zendesk semblent déjà intégrer de l’IA. Il est très probable que beaucoup de demandes de support reçoivent déjà des réponses presque automatiquement
Les services RH pourraient aussi utiliser l’IA pour trier les candidatures, lui faire rechercher sur Internet des informations supplémentaires sur les candidats, puis créer des entrées de base de données standardisées. Bien sûr, cela pourrait être très imparfait
Ce qui est intéressant, ce sont ce type d’applications, pas encore une extension ou un plug-in ChatGPT
Pour chaque nouvel e-mail, je compte exécuter un pipeline afin qu’il suggère quelques actions
Je réfléchis encore à plusieurs approches, mais cela semble déjà tout à fait faisable
L’introduction paraît un peu trop flamboyante et exagérée. Par exemple, les LLM ne sont pas si chers que ça, l’affirmation du WSJ selon laquelle Copilot ferait perdre de l’argent par utilisateur n’est pas très convaincante, et il est difficile de dire que les LLM sont toujours « douloureusement lents »
Cela dit, les recommandations concrètes de l’article sont plutôt raisonnables
Il s’agit de traiter autant de choses que possible avec du code, et d’utiliser une IA spécialisée pour ce que le code ne peut pas faire
C’est raisonnable, mais ce n’est pas particulièrement nouveau
J’espérais que l’article irait plus en profondeur sur la façon de créer des produits d’IA réellement utiles et de qualité. Il y a eu beaucoup de tentatives récemment, comme le lancement de Humane, mais on ne voit pas encore beaucoup de réussites
Cet article se concentre beaucoup sur la façon de construire des produits d’IA, mais personnellement, je pense que le succès ou l’échec des « produits d’IA » dépend moins de la différenciation, du coût, de la vitesse ou de l’adaptation du modèle que de leur utilité réelle
Malheureusement, la plupart des produits que j’ai vus jusqu’à présent ressemblent à des solutions en quête d’un problème
À mon avis, la voie à suivre pour les entreprises est d’identifier les parties les plus ennuyeuses et répétitives de l’utilisation de leur produit, puis de trouver comment les simplifier de manière fiable avec l’IA
Comme dans tous les cycles de surchauffe, quand on n’a qu’un marteau, tout ressemble à un clou
Le marteau d’il y a peu, c’était la blockchain, et maintenant c’est l’IA
Si vous avez été assez naïf pour croire aux promesses de la blockchain, il est normal que vous soyez déçu que l’IA ne soit pas une pyramide d’enrichissement rapide permettant de gagner des millions de dollars sans temps, sans énergie ni réflexion originale
Si c’est tout ce que vous cherchez, vous continuerez à être déçu, et ce sera mérité
L’IA offre beaucoup plus que la blockchain. Les mettre sur le même plan signifie que vous ne comprenez correctement ni l’une ni l’autre