Avant d'embaucher une société de développement de logiciels d'IA
Recherchez ceci et chaque résultat est une page de vente. Embauchez nos développeurs, nos ingénieurs sont sélectionnés, notre équipe est expédiée en quelques semaines, les logos sont classés par secteur. Ils vendent la même chose dans des polices différentes, et aucun d’entre eux ne répond à la question que vous vous posiez réellement lorsque vous l’avez tapé, à savoir si vous devez embaucher quelqu’un.
Cette question a une vraie réponse et ce n’est pas toujours non. Cela implique une distinction : si ce que vous voulez est un appel de modèle ou un système. Un appel modèle est une demande adressée à un fournisseur qui revient avec un texte. Un système est tout ce qui doit exister autour de cette demande avant que la réponse puisse être fiable, transmise à la bonne personne et fiable lorsque le fournisseur est lent. Le premier est quelque chose que votre équipe existante peut construire ce trimestre. Le second est un projet logiciel, et les projets logiciels sont destinés aux sociétés de développement.
Le problème est que les deux semblent identiques dans une démo. Les deux produisent une réponse sur un écran. La différence n'apparaît que plus tard, dans un trafic réel, avec de vraies autorisations et de réelles conséquences en cas de mauvaise réponse, c'est pourquoi tant d'engagements sont évalués par rapport à la première et tarifés par rapport à la seconde, ou l'inverse.
La ligne, tracée à quatre endroits précis
Nous avons rédigé les quatre parties d'une intégration dans un article sur ce que les services d'intégration d'IA ne citent pas. Ce sont les quatre mêmes ici, utilisés différemment : là, ils représentent ce qu'une proposition doit couvrir, et ici, ils constituent le test pour savoir si vous avez un projet. Parcourez-les honnêtement au sujet de votre propre cas et la réponse tombe généralement.
D'où vient le contexte. Si le modèle peut faire le travail avec ce que l'utilisateur tape plus une instruction fixe, il n'y a pas de problème de récupération et vous n'avez pas de système. S'il a besoin de connaître des informations sur votre entreprise, quelque chose doit trouver ces informations, les tenir à jour et décider lesquelles d'entre elles sont pertinentes pour cette demande. Il s’agit d’un problème d’indexation et de fraîcheur, c’est de l’ingénierie ordinaire, et c’est là que réside réellement la qualité des réponses. Au moment où cela apparaît, vous avez franchi la ligne.
Qui est autorisé à le voir. Si chaque utilisateur de l'objet peut voir tout ce qu'il peut atteindre, vous n'avez aucun problème d'autorisations. Si ce n'est pas le cas, l'application doit avoir lieu lors de la récupération plutôt que dans une instruction adressée au modèle, car l'instruction et le contenu partagent un canal et toute personne tapant dans la boîte écrit également dans ce canal. La récupération basée sur les autorisations n'est ni difficile ni facultative, et c'est la chose qui manque le plus souvent dans une démo où une personne est connectée en tant qu'elle-même.
Que se passe-t-il lorsque rien ne répond. Les fournisseurs de modèles ont tendance à échouer lentement plutôt que bruyamment : la demande se bloque. Un jouet peut être accroché. Tout ce dont dépend un client ou un collègue nécessite un comportement défini pour ce cas, y compris si une nouvelle tentative peut répéter un effet secondaire déjà survenu. Si votre objet écrit un enregistrement, envoie un e-mail ou déplace de l'argent, ce n'est pas un détail que vous ajouterez plus tard.
Comment une mauvaise réponse est détectée. Une mauvaise réponse qui atteint un client est l'échec qui coûte le plus cher et celui qui est invisible lors des tests, car pendant les tests, vous lisez chaque sortie. En production, personne ne l'est. L'attraper signifie une manière de mesurer la qualité des résultats qui est construite à partir de vos propres échecs plutôt qu'à partir d'un point de référence, qui est un ensemble de travaux en soi et fait l'objet de [notre article sur l'évaluation LLM] (/en/blog/llm-evaluation).
Zéro ou un de ces quatre et vous avez une fonctionnalité. Trois ou quatre et vous avez un système, avec une surface qui continue d'exister après le lancement.
Ce qu'un système coûte qu'une fonctionnalité ne coûte pas
Ce qui surprend les gens, ce n’est pas la construction. C'est qu'un système a un propriétaire, pour toujours. La récupération dérive à mesure que les documents sources changent. Les autorisations changent lorsque quelqu'un quitte. Un fournisseur désapprouve un modèle et l’invite qui a été adaptée à celui-ci se comporte différemment. Rien de tout cela n’est un défaut et tout cela est un travail qui arrive, que quelqu’un l’ait budgétisé ou non.
Les infrastructures en constituent la moitié visible et la moitié la plus facile à estimer. Si votre plan implique d'exécuter quelque chose par vous-même plutôt que d'appeler uniquement un fournisseur, le calculateur de coûts AWS ici est un moyen plus rapide de trouver la forme de ce numéro qu'une conversation avec un fournisseur, et cela vaut la peine de l'avoir avant la conversation plutôt qu'après.
La moitié invisible est l’attention. Quelqu’un doit remarquer que les réponses se sont détériorées, et il est plus difficile de le remarquer que de le corriger. Il s’agit d’une question de dotation plutôt que d’approvisionnement, et c’est celle qu’un énoncé de travail ne résoudra pas pour vous.
Alors, quand embaucher la bonne réponse
Trois cas, et ils sont plus restreints que ne le suggèrent les résultats de la recherche.
La première est que vous disposez d’un véritable système selon les quatre tests ci-dessus et qu’aucune équipe n’a le temps de le construire. C’est un cas simple et c’est à cela que servent ces entreprises. Ce que vous achetez, c'est le débit, et la chose à vérifier est si la proposition aborde les quatre parties ou si elle vous en laisse discrètement deux.
La seconde est que vous avez l'équipe mais pas l'expérience particulière, et que le travail est dans un délai où l'apprendre en public coûte cher. Ici, ce que vous voulez, ce n'est pas une équipe dédiée mais un engagement plus restreint qui laisse vos propres collaborateurs capables de la gérer par la suite, ce qui est une forme de contrat différente et que vous devez demander explicitement, car ce n'est pas la valeur par défaut.
La troisième est que vous ne savez pas encore dans lequel vous vous trouvez. C'est la position la plus courante et elle est mal servie par les pages des fournisseurs, puisque chacune d'elles résout l'ambiguïté dans le sens d'un engagement plus large. C'est le cas un consultant en IA pour petites entreprises est véritablement pour : un travail court et délimité dont le seul livrable est une décision.
Et les arguments pour ne pas embaucher : une des quatre parties, une audience contenue, et rien d'irréversible ne se produit en aval d'une mauvaise réponse. Construisez-le, gardez-le petit et découvrez ce qu'il fait en utilisation réelle avant de commander quelque chose de plus grand. Les informations que vous obtenez après un mois de trafic réel valent plus que n’importe quelle phase de découverte, et elles sont moins chères.
Questions à poser avant la démo
Une démo est conçue pour montrer la partie qui fonctionne déjà. Ce sont les questions qui touchent le reste, et elles fonctionnent pour n'importe quel fournisseur, quelle que soit la façon dont la page est rédigée.
Demandez d'où vient le contexte, et plus précisément combien de temps il faut pour qu'une modification dans un document source aboutisse à une réponse. Une réponse vague ici signifie que la conception de récupération n'existe pas encore.
Demandez comment les autorisations sont appliquées. Si la réponse implique de dire au modèle ce qu’il ne doit pas révéler, c’est la mauvaise réponse et elle est courante.
Demandez ce qui se passe lorsque le fournisseur est lent plutôt que en panne et si une nouvelle tentative peut répéter une action déjà terminée. C’est la question qui différencie ceux qui en ont exploité un de ceux qui en ont construit un.
Demandez-leur comment ils sauront que la production s'est dégradée des mois après le lancement. Si la réponse est un tableau de bord de métriques génériques, demandez lesquels de vos échecs ces métriques auraient détectés.
Demandez ce que vous possédez à la fin et qui l’entretient. La distinction entre un livrable et une dépendance est la chose la plus facilement ambiguë et la plus coûteuse à découvrir plus tard.
Aucune de ces questions n’est piège et un bon partenaire accueillera les cinq, car ce sont les questions que leurs propres ingénieurs se posent déjà en interne. Un fournisseur qui ne peut pas y répondre n'est pas nécessairement mauvais dans la création de logiciels. Ils décrivent une fonctionnalité et vous êtes venu ici pour savoir si vous en possédez une.