Solutions d'IA personnalisées : les quatre conditions
Recherchez ceci et la réponse que vous obtenez est un équilibre. Voici les avantages de la construction, voici les avantages de l’achat, voici un paragraphe recommandant un hybride, tenez compte des besoins uniques de votre entreprise. Chaque page atterrit au même endroit, ce qui n'est pas un endroit, et la raison est structurelle : la plupart d'entre elles sont écrites par des entreprises qui feraient la construction.
Une décision qui s’avère équilibrée à chaque fois n’est pas une décision. Cette page adopte donc l’autre approche. La coutume est la bonne réponse dans quatre conditions spécifiques. En dehors d’eux, acheter est moins cher, plus rapide et moins exposé, et la partie utile de cette question est de pouvoir savoir de quel côté de cette ligne vous vous situez avant que quiconque rédige une proposition.
Les quatre ne constituent pas un système de notation et ne sont pas pondérés. L’un d’eux étant clairement vrai suffit à justifier la construction. Aucun d’eux n’est vrai, cela signifie que la proposition personnalisée qui vous est présentée constitue un chemin plus coûteux vers quelque chose que vous pouvez déjà acheter.
Première condition : la capacité est le produit
Si le modèle correspond à ce pour quoi les clients vous paient, il ne peut pas s'agir du produit d'un fournisseur sur votre facture. Non pas à cause de la qualité, mais parce que vous ne pouvez pas créer un fossé à partir d'une API à laquelle votre concurrent peut s'inscrire cet après-midi.
Le test est de savoir si un client remarquerait et s'intéresserait si vous échangez l'implémentation contre celle d'un concurrent. Si la réponse est non, il s’agit d’une infrastructure et vous devriez acheter la version fiable la moins chère. Si la réponse est oui, vous êtes face à la seule condition qui ne peut véritablement pas être externalisée, et de toute façon, la chose à protéger est rarement le modèle. Ce sont les données dont vous disposez et personne d’autre ne les possède, ainsi que l’ensemble d’évaluation qui vous indiquent si un changement a amélioré les choses.
La plupart des travaux définis comme personnalisés échouent immédiatement à ce test. Triage des supports, résumé des documents, notes de réunion, notation des leads, contenu de la première ébauche : tous sont réels, tous précieux, aucun d'entre eux n'est le produit. Ce sont les cas où le marché a déjà construit ce que vous étiez sur le point de commander.
Deuxième condition : les données ne peuvent pas sortir
Parfois, la contrainte n’est pas la préférence. Des dossiers médicaux soumis à une réglementation musclée, des documents juridiques protégés par un privilège, des travaux de défense, un contrat indiquant où le traitement peut avoir lieu, un client dont la propre équipe de conformité doit approuver vos sous-traitants. Dans ces cas, la question de savoir où l'inférence s'exécute est réglée avant que quiconque ne discute des fonctionnalités.
Soyez précis sur la version dont vous disposez, car la version forte est plus rare que ne le suggère la conversation. Une obligation écrite concernant la résidence des données ou les sous-traitants ultérieurs est une contrainte stricte. Les conditions de l'API payante comportent désormais un engagement contractuel de ne pas former sur ce que vous envoyez : les conditions commerciales d'Anthropic indiquent clairement qu'Anthropic ne peut pas former de modèles sur le contenu client des services et que le client conserve tous les droits sur ses entrées. Cela suffit à satisfaire un grand nombre de politiques internes qui semblaient absolues au premier abord.
Ce qui reste après ce filtre est le cas réel : les données ne peuvent physiquement pas parvenir à un tiers, le modèle s'exécute donc à l'intérieur de vos limites. C’est une véritable raison de construire, et cela change la forme du coût plutôt que simplement le fournisseur, auquel arrive la section sur les coûts ci-dessous.
Troisième condition : le workflow n'a pas d'équivalent sous forme de produit
Les logiciels packagés codent une hypothèse sur la manière dont le travail est effectué. Lorsque votre processus correspond, vous bénéficiez d'années d'ingénierie de quelqu'un d'autre contre un abonnement. Dans le cas contraire, vous obtenez un outil que tout le monde combat, et les combats sont invisibles sur la facture.
La distinction qui mérite d'être établie est celle entre inhabituel et simplement spécifique. Un processus spécifique est celui que la configuration du fournisseur peut exprimer : vos champs, vos étapes, vos règles d'approbation. Inhabituel signifie que la forme elle-même est différente, ce qui ressemble généralement à l'un des rares motifs. Vos données résident dans un système auquel le fournisseur n’a jamais intégré et ne le fera pas. La tâche nécessite une séquence d'étapes dans plusieurs systèmes internes, vos propres règles déterminant l'ordre. Ou bien le résultat doit atterrir dans un système d’enregistrement qui a été écrit avant que quiconque ici n’ait entendu parler d’un modèle.
Avant d'accepter celui-ci, effectuez une vérification ennuyeuse : prenez les trois meilleurs fournisseurs de la catégorie et essayez de configurer votre processus réel, avec vos données réelles, dans le cadre d'un essai. Le nombre de projets personnalisés qui meurent une fois que quelqu'un l'a fait est le principal argument en faveur de le faire en premier.
Condition quatre : le volume a dépassé
C’est la seule condition qui relève de l’arithmétique plutôt que du jugement, et c’est celle qui est la plus souvent affirmée sans être calculée.
La tarification par siège et par demande est une ligne droite. Votre propre déploiement est une étape : un coût fixe pour la construction, un coût fixe mensuel pour l'infrastructure et la personne qui la maintient, et un petit coût par demande en plus. En dessous d'un certain volume, la ligne est moins chère. Au-dessus se trouve la marche. Tout le monde le sait dans l'abstrait et presque personne n'a trouvé le point de passage pour sa propre charge de travail, ce qui est dommage, car c'est un après-midi de travail et cela règle souvent toute la dispute.
Coûter les deux parties pour une seule charge de travail
Voici comment procéder correctement. Prenez la charge de travail sur laquelle vous discutez réellement, et non une charge représentative, et obtenez-en deux chiffres.
Commencez par la forme par requête. Extrayez une transcription réaliste de la tâche, y compris le contexte envoyé avec, et comptez ce qu'un appel contient réellement avec un compteur de jetons. Multipliez-le ensuite par le volume attendu dans le calculateur de coût LLM. Ici, deux choses surprennent généralement les gens. La première est qu'une tâche en plusieurs étapes renvoie son contexte accumulé à chaque étape, car les modèles sont sans état en dessous, donc une étape tardive coûte un multiple de la première. La seconde est que la figure que la plupart des gens ont en tête vient de la réflexion sur un seul message court.
Ensuite, chargez l’autre côté de la même charge de travail. L'auto-hébergement d'un modèle signifie une machine avec un accélérateur attaché, et cette machine est facturée qu'une demande arrive ou non, ce qui fait toute la différence entre la ligne et l'étape. Indiquez le type d'instance et les heures pendant lesquelles vous l'exécuteriez réellement via le calculateur de coûts AWS, y compris le stockage et la sortie, puis ajoutez les éléments qui ne figurent pas sur la facture : l'ingénieur qui en est propriétaire, l'astreinte et la mise à niveau du modèle que vous effectuerez dans un an parce que celui que vous avez déployé a cessé d'être à la pointe de la technologie.
Vous disposez désormais de deux courbes pour une même charge de travail, et le croisement est un chiffre plutôt qu’une opinion. Trois résultats sont communs. C'est loin, auquel cas achetez et arrêtez d'en discuter. C'est proche, auquel cas achetez quand même, car l'économie réalisée ne couvre pas le risque de se tromper. Ou vous l'avez déjà dépassé, ce qui est le seul cas où l'arithmétique vous a dit quelque chose, et il convient de noter que c'est un volume élevé et constant qui vous y amène, et non un volume de pointe, puisque les accélérateurs au ralenti sont la partie coûteuse de la possession de l'étape.
Ce que signifie réellement la réponse hybride
La plupart des pages recommandent un mélange et le laissent là, ce qui n'est d'aucune utilité, car un mélange peut signifier deux choses très différentes.
La version utile est une division par composant. Achetez les pièces de base du pipeline et construisez uniquement la pièce qui vous appartient. En pratique, cela signifie utiliser le modèle d'un fournisseur via son API et conserver votre préparation de données, votre récupération, votre ensemble d'évaluation et votre orchestration comme votre propre code. Cette répartition coûte très peu, permet au fournisseur de être remplacé et signifie que changer de modèle ultérieurement est un changement de configuration plutôt qu'un projet.
La version à éviter consiste à créer une couche mince sur une API et à l'appeler une solution personnalisée. Si la seule chose entre vos utilisateurs et un fournisseur est un texte d'invite et un formulaire Web, vous avez acheté la fonctionnalité et payé les prix de construction pour le wrapper. Il s’agit de la forme la plus courante d’un projet d’IA personnalisé décevant, et elle est généralement visible dans la proposition si vous demandez ce qui se passe lorsque le modèle sous-jacent change.
La cinquième réponse que personne sur ce marché ne propose
Attendez. Pas pour toujours, et non pas comme une évasion, mais comme une position avec une condition de sortie claire.
Une fonctionnalité nouvelle et coûteuse ce trimestre pourrait arriver sous forme de fonctionnalité dans un logiciel pour lequel vous payez déjà. Si ce que vous voulez figure sur la feuille de route évidente d'un fournisseur que vous utilisez déjà, le mettre en service vous-même vous fait gagner quelques mois d'avantage et vous permet de conserver quelque chose qui sera ensuite expédié gratuitement. La bonne solution est alors d’écrire la condition dans laquelle vous arrêteriez d’attendre, avec une date dessus, afin qu’attendre reste une décision plutôt que de devenir une habitude.
L’autre réponse que personne ne propose est plus petite. Créez la version la plus étroite qui touche les utilisateurs réels, instrumentez-la et laissez un mois de trafic réel répondre aux questions que la proposition devinait : ce que les gens demandent réellement, à quelle fréquence cela se trompe et quel est le volume. Un mois de cette somme règle les arguments qu'aucun travail stratégique ne peut résoudre, et c'est considérablement moins cher que l'une ou l'autre des options que vous choisissiez. Notre article sur ce que le conseil en stratégie d'IA est censé produire couvre les décisions qui méritent d'être prises avant d'y arriver, et l'article sur ce que les services d'intégration d'IA ne citent pas couvre les coûts qui surviennent après l'approbation de la construction.
Questions à quiconque propose la construction
Demandez laquelle des quatre conditions s'applique, par son nom, et écoutez si la réponse est une condition ou un enthousiasme.
Demandez quel est le volume de croisement pour votre charge de travail et à partir de quoi il a été calculé. Aucune réponse n’incluant le coût d’un accélérateur au ralenti n’a été calculée.
Demandez ce qui reste à vous. Les données, l'ensemble d'évaluation et l'orchestration devraient. Si la réponse est que les poids des modèles restent les vôtres, demandez qui les mettra à niveau l'année prochaine et avec quel budget.
Demandez quels sont les trois produits qu'ils ont évalués en premier et lesquels ont spécifiquement échoué. Une proposition qui ne peut pas nommer les alternatives qu’elle bat n’a été comparée à rien.
Demandez-leur ce qui pourrait vous inciter à acheter à la place. Tous ceux qui construisent devraient avoir une réponse à cette question, et ceux qui le font sont ceux avec qui il vaut la peine de travailler.