Développement IA et LLM
Un modèle de langage est un composant, pas un produit. L’ingénierie intéressante dans une fonctionnalité IA n’est presque jamais l’appel au modèle. C’est ce qu’on lui donne, ce qu’on fait de ce qui revient, ce que cela coûte par utilisateur, et ce que fait le système quand le modèle se trompe avec assurance.
Nous construisons des fonctionnalités LLM dans de vrais produits : des systèmes qui ont déjà des utilisateurs, des données et des conséquences. C’est une discipline différente de la construction d’une démonstration, surtout parce qu’une démonstration a le droit de se tromper.
Ce que nous construisons
La recherche
Des réponses tirées de vos documents, avec la source attachée.
L’extraction
Du texte libre transformé en champs exploitables par un système.
Les assistants
Des modèles qui font le travail, pas seulement le décrivent.
Recherche sur vos propres contenus
La plupart des fonctionnalités IA utiles sont un problème de recherche d’information déguisé en problème de génération. Le modèle ne vaut que ce qu’on lui met sous les yeux, donc le travail est dans le découpage, l’indexation, le classement, et le fait de savoir quand la réponse honnête est que rien de pertinent n’a été trouvé.
Nous préférons un système qui dit qu’il ne sait pas à un système qui produit une réponse fluide assemblée à partir des trois documents les moins hors sujet. Cette préférence doit être construite délibérément, parce que le comportement par défaut de tout modèle est de répondre quand même.
Extraction structurée
Transformer des documents, des courriels et des messages en champs exploitables : des factures en lignes, des demandes en pistes commerciales, du texte libre en catégorie. C’est là que les modèles rentabilisent leur coût le plus sûrement, parce que la sortie est vérifiable. On peut valider une date, un total et une devise, et rejeter ce qui ne s’analyse pas.
Des assistants capables d’agir
Un assistant qui ne sait que parler est un champ de recherche avec une latence moins bonne. La valeur est dans l’usage d’outils : retrouver une commande, lancer un retour, réserver un créneau. Cela suppose pour chaque outil un contrôle de droits, une piste d’audit, et une frontière nette entre ce que l’assistant peut faire seul et ce qui exige la validation d’un humain.
Ce qu’on sous-estime
Le coût est une décision de conception
Le coût par requête est fixé par l’architecture bien avant de l’être par le choix du modèle. Quelle quantité de contexte vous envoyez, si vous l’envoyez à chaque tour, ce que vous mettez en cache, et si un modèle moins cher aurait suffi pour les quatre-vingt-dix pour cent de requêtes simples. Nous concevons le routage d’abord et choisissons les modèles ensuite, et nous vous donnons le coût attendu pour mille interactions avant que vous ne vous engagiez.
La latence est un problème produit
Les utilisateurs tolèrent très différemment une réponse lente selon qu’il se passe visiblement quelque chose ou non. Le streaming, une interface optimiste et une progression honnête font partie de l’ingénierie, pas de la finition. De même que décider quels appels ont lieu pendant que l’utilisateur attend et lesquels passent en file derrière lui.
Se tromper est une exigence fonctionnelle
Toute fonctionnalité LLM a besoin d’une réponse définie à : comment savons-nous qu’elle s’est trompée, que voit l’utilisateur, et combien cela nous coûte. Pour un résumé, la réponse peut être un haussement d’épaules. Pour tout ce qui touche à l’argent, au stock ou à un engagement envers un client, la réponse est un humain dans la boucle et une piste d’audit. Nous insistons pour avoir cette conversation avant de construire, parce que l’ajouter après revient à reconstruire.
Une évaluation, sinon vous devinez
Sans jeu de test, vous ne pouvez pas savoir si un changement de prompt a amélioré quoi que ce soit. Nous constituons tôt un petit jeu d’évaluation à partir de vos cas réels, pour que les changements se mesurent au lieu de se discuter, et pour qu’un changement de modèle soit quelque chose que vous évaluez plutôt que quelque chose qui vous arrive.
Ce que nous vous déconseillerons
Une bonne part des projets IA pour lesquels on nous sollicite se résolvent mieux sans modèle. Si l’entrée est structurée et les règles connaissables, un moteur de règles est moins cher, plus rapide, testable, et n’invente jamais rien. Si le vrai problème est que vos données sont éparpillées dans quatre systèmes, un assistant posé sur ce désordre se trompera avec assurance d’une manière nouvelle et plus coûteuse.
Nous préférons le dire pendant le cadrage plutôt que construire quelque chose d’impressionnant qui ne fonctionne pas vraiment.
Comment se déroule le travail
Le cadrage établit le cas d’usage, ce à quoi ressemble une bonne réponse, ce que coûte une mauvaise, et où vivent réellement les données. Cela produit une architecture, un coût d’exploitation attendu et un plan d’évaluation.
La première construction est volontairement étroite : un processus, de vrais utilisateurs, mesuré. Les fonctionnalités IA ont une propension particulière à paraître terminées en démonstration et à se défaire devant la variété des entrées réelles, donc atteindre vite ces entrées réelles compte ici plus que presque partout ailleurs.
À voir aussi
Les fonctionnalités IA se construisent généralement sur une plateforme qui détient déjà les données, et atteignent le reste de l’entreprise par l’intégration de systèmes. Si l’interface est la partie difficile, voir le design UX et UI.
Questions fréquentes
Quels modèles utilisez-vous ?
Ceux qui conviennent à la tâche, à l’enveloppe de coût et aux contraintes de données, et nous concevons pour que ce choix puisse changer. Les capacités et les tarifs bougent plus vite que tout le reste de cette pile, donc être verrouillé sur un fournisseur est un risque plutôt qu’une simplification.
Nos données servent-elles à l’entraînement ?
Non, sauf si vous en décidez ainsi. Cela dépend du fournisseur et de l’offre, c’est une question contractuelle autant que technique, et nous la réglons explicitement plutôt que par défaut.
Peut-on fonctionner sans envoyer de données hors d’Israël ou de l’UE ?
Parfois, selon la tâche et la précision requise. Des modèles plus petits auto-hébergés traitent honorablement la classification et l’extraction. Pour la génération ouverte l’écart reste réel, et nous vous dirons honnêtement ce que vous perdez plutôt que de vous vendre un déploiement privé décevant.
Combien cela coûte-t-il à exploiter ?
Nous donnons un coût attendu pour mille interactions pendant le cadrage, et nous concevons pour le tenir. Il est généralement plus bas qu’on ne le croit pour l’extraction et la classification, et plus haut qu’on ne le croit pour tout ce qui envoie un contexte volumineux à chaque tour.
Et si le modèle donne une mauvaise réponse à un client ?
C’est une question de conception à laquelle nous répondons avant de construire. Selon l’enjeu, c’est un seuil de confiance, une source que l’utilisateur peut vérifier, un humain qui valide avant envoi, ou simplement ne pas utiliser de modèle à cette étape.
Plus de services
La suite
Dites-nous ce que vous construisez, ou ce qui casse.