De quoi a besoin le retour sur investissement de l'IA avant de pouvoir le calculer
Recherchez ceci et vous obtenez deux choses. Une formule, qui représente les avantages moins les coûts divisés par les coûts, et un tableau des rendements de référence par cas d'utilisation. La formule est correcte et le tableau est le marketing de quelqu'un, et ni l'un ni l'autre n'est la raison pour laquelle vous ne pouvez pas répondre à la question.
L'arithmétique n'a jamais été un obstacle. L’obstacle est que le numérateur n’existe pas encore, et dans la plupart des projets qui posent cette question, il n’existera jamais, car ce qui rend un rendement mesurable doit se produire avant la construction du système et la question est posée après.
Il s'agit donc d'une page sur la mesure plutôt que sur le nombre. Que faut-il enregistrer, dans quelle unité l'enregistrer, où une économie est comptée deux fois et que faire dans le cas courant où le modèle fait son travail et le rendement est toujours nul.
Un retour que vous n'avez pas instrumenté n'est pas un retour
Les tableaux de référence sont inutilisables pour une raison qui n’a rien à voir avec l’honnêteté de leurs chiffres. Un rendement est un ratio et le dénominateur est votre ancien processus. Deux organisations exécutant ce qu'elles décrivent comme le même flux de travail peuvent différer considérablement en termes de temps nécessaire, de fréquence à refaire et de nombre de personnes qui y participent. Un ratio publié basé sur le dénominateur de quelqu’un d’autre ne vous dit rien du vôtre.
Ce qui signifie que le travail utile est effectué avant que quoi que ce soit ne soit expédié. Pour le processus que vous êtes sur le point de modifier, enregistrez quatre choses pendant qu'il est toujours effectué selon l'ancienne méthode :
Durée par instance. Pas le temps que prend en principe le processus. Le temps que cela prend, mesuré sur des instances réelles, y compris celles qui tournent mal.
Volume. Combien d'instances par semaine, sur une période suffisamment longue pour capturer les semaines calmes et les semaines chargées.
Taux de retouche. Fréquence à laquelle une instance revient et doit être refaite. C’est la ligne qui porte le plus souvent le coût réel, et elle n’est presque jamais enregistrée.
Qui le touche. Le nombre de personnes distinctes par lesquelles passe une instance, car chaque transfert est une attente et les attentes sont généralement plus longues que le travail.
Si le système a déjà été expédié et que rien de tout cela n’a été capturé, vous avez deux options honnêtes et une option malhonnête. Vous pouvez échantillonner l’ancien processus là où il s’exécute encore quelque part, sur une autre équipe ou un autre type de document, et l’utiliser comme référence rétroactive. Vous pouvez organiser une scission, où une équipe conserve l'ancien processus et une autre utilise le nouveau, ce qui est la chose la plus rigoureuse disponible et est souvent politiquement impossible. L’option malhonnête consiste à demander aux utilisateurs du système combien de temps cela leur fait gagner et à traiter la réponse comme des données. Les gains de temps autodéclarés sont généreux et fiables, et tout l'intérêt d'une référence est qu'elle a été enregistrée par quelqu'un qui ne savait pas encore quelle réponse serait pratique.
Le temps par instance est la seule unité honnête à petite échelle
La tentation est d’exprimer immédiatement le retour en argent, car c’est l’argent qui est ce dont l’approbation a besoin. Résistez-y encore un pas.
Une conversion précoce en argent vous oblige à choisir un taux, et le taux que vous choisissez décide de la réponse. Pire encore, cela invite aux deux conversions qui rendent un retour infalsifiable : les revenus attribués à un système qui a touché une étape d'une vente longue et les effectifs qui n'allaient de toute façon jamais être embauchés. Les deux sont défendables dans une grande organisation dotée d’une fonction financière capable de les arbitrer. Ni l’un ni l’autre n’est défendable à l’échelle à laquelle la plupart de ces projets sont réellement exécutés.
Le temps par instance, multiplié par le volume, est reproductible. Quelqu’un qui n’est pas d’accord avec votre conclusion peut la vérifier, et cette propriété vaut plus qu’un plus grand nombre. Convertissez-le en argent une fois, à la fin, en utilisant un taux horaire chargé que vous êtes prêt à défendre à haute voix, et affichez le chiffre non converti à côté.
Les deux endroits où une économie est comptée deux fois
L'embauche évitée. Un gain de temps de tâche et un effectif évité sont souvent une même économie, notée à deux endroits. Si les heures libérées constituent une justification, alors l’embauche que ces heures auraient nécessité ne constitue pas un avantage distinct. Choisissez-en un. La version honnête habituelle est celle des heures, car l'embauche était une projection et les heures sont une mesure.
L'étape de révision. C'est l'étape courante et il est facile de la manquer, car la révision ressemble à de la diligence plutôt qu'à un coût. Si une personne lit toujours chaque sortie avant de l'utiliser, le coût d'une instance correspond à l'exécution du modèle plus cette lecture, et la lecture représente souvent l'essentiel de ce qu'était l'ancien processus. Pour le dire sous forme d'arithmétique plutôt que de constatation : si une instance a nécessité quarante minutes d'écriture et prend maintenant cinq minutes de génération plus trente minutes de vérification, l'économie est de cinq minutes et non de trente-cinq. Mesurez l'ensemble de l'instance de bout en bout, du déclencheur jusqu'au point où le travail est réellement utilisé, sinon l'économie que vous rapportez sera l'économie sur une étape de celle-ci.
Il en existe un troisième, moins courant mais qui mérite d’être mentionné : un gain dans une file d’attente qui n’était pas le goulot d’étranglement. Faire un pas rapide plus rapidement ne change rien en aval. Si la contrainte est l'approbation qui a lieu deux étapes plus tard, le temps que vous avez libéré se trouve dans la même file d'attente qu'auparavant.
Le coût correspond à la moitié que vous pouvez obtenir exactement
C’est la partie agréable de l’exercice. Vos coûts sont connus de manière très approximative avant de vous engager, ce qui est inhabituel dans tout type de prévision.
Prenez un exemple réaliste, écrivez ce qui entre dans la demande et ce que vous attendez en retour, et transmettez-le via notre calculateur de coûts LLM au volume de votre référence. Si une partie de la conception s'exécute sur une infrastructure que vous possédez, le AWS cost calculator vous donne cette ligne au cours de la même session. Ajoutez ensuite celui que personne ne budgétise : quelqu'un qui remarque quand les réponses empirent et y corrige le problème. Nous avons un article plus long sur ce qui décide du coût de développement de l'IA, et la moitié récurrente est celle qui décide si un projet est vivant au cours de sa deuxième année.
Comparez votre propre coût à votre propre gain de temps et vous obtenez un ratio qui vous appartient. Cela ne correspondra à aucun benchmark publié, et c’est là le point.
Quand le modèle fonctionne et que le retour est toujours nul
Il s’agit du résultat décevant le plus courant, et il est régulièrement diagnostiqué à tort comme un problème modèle.
Le modèle ressemble à ceci. La précision est acceptable lors des tests. Le système est mis en ligne. Rien de changement mesurable. L’instinct est de revenir à l’invite, et l’invite n’est généralement pas là où se situe le problème.
Ce qui se produit généralement, c'est que le flux de travail autour du modèle reste inchangé. Le résultat arrive dans un endroit que personne ne regarde dans le cadre de son travail réel. Le transfert qui suivait l’étape manuelle la suit toujours. La personne qui effectuait la tâche lit désormais le résultat avec le même soin qu'elle avait l'habitude de l'écrire, car personne ne lui a dit qu'elle pouvait s'arrêter, et personne ne lui a donné de règle sur le moment où lui faire confiance. L’étape s’est accélérée, mais pas le processus.
Le diagnostic est la même mesure que précédemment : le temps de cycle de bout en bout par instance, et non la latence de l'étape du modèle. Si le pas du modèle est rapide et que le temps de cycle n'a pas bougé, le modèle ne fait pas l'objet de l'investigation. Ce qui manque, c'est généralement une règle énoncée pour savoir quand un humain doit regarder, qui est une décision que quelqu'un doit prendre en charge plutôt qu'un paramètre à régler, et cela dépend de la disponibilité d'un ensemble d'évaluation suffisamment bon pour dire à quelle fréquence le système se trompe et dans quelle direction.
Ce qu'il faut noter avant d'expédier
Quatre lignes, sur une seule page, convenues par celui qui jugera le résultat plutôt que par ceux qui le construisent. La référence, en temps par instance et en volume. La métrique que vous allez re-mesurer, qui devrait être la même. La date à laquelle vous le mesurerez à nouveau. Et quel nombre compterait comme un échec, décidé à l’avance, car un pilote qui est déclaré ni réussi ni échoué est un résultat pire qu’un pilote qui échoue, et la plupart d’entre eux se terminent ainsi.
Si vous n'êtes pas sûr que l'organisation soit prête à respecter ces quatre lignes, notre évaluation gratuite de l'état de préparation de l'IA pose six questions qui prédisent chacune qu'un déploiement ne survivra pas à sa première année, et la réponse qu'elle vous donne est plus utile avant la construction qu'après.
Un rendement mesuré de cette manière est inférieur à celui des tableaux de référence, et il vous appartient, et il survit à la remise en question. Pour en savoir plus sur la création de ces systèmes, consultez le reste de nos écrits.