En tant que développeur back-end, j'ai construit des centaines de points de terminaison, de sorte que le flux typique des points de terminaison est profondément ancré dans ma façon de penser les applications Web. Mais lorsque j’ai commencé à créer des points de terminaison basés sur l’IA, j’ai remarqué un changement intéressant.
Au début, les points de terminaison IA ressemblaient à de simples points de terminaison proxy avec une certaine configuration pour se connecter à un modèle :
L'API reçoit la demande ↓ envoyer l'invite au modèle ↓ recevoir la réponse ↓ la renvoyer au clientEt cela a bien fonctionné jusqu'à ce que je découvre que transmettre une invite directement du client n'était pas une bonne idée. Le point de terminaison pourrait être utilisé à mauvais escient dans un but complètement différent, permettant à quelqu'un d'autre de consommer mes crédits d'utilisation de l'IA.
Puis j’ai réalisé que l’entrée avait aussi besoin de limites. L'envoi d'un contexte volumineux pour une tâche spécifique coûte plus cher et peut produire des résultats inattendus.
Ainsi, lorsque j'ai commencé à y regarder de plus près, en particulier lorsque j'avais besoin d'une sortie structurée fiable et d'un comportement d'application prévisible, j'ai rapidement réalisé que ce n'était pas si simple. La validation ne surveillait plus seulement l’exécution, elle était également devenue une étape de post-traitement. Les modèles d'IA sont probabilistes. Même avec la même entrée, ils peuvent renvoyer des sorties différentes, omettre des informations requises, mal comprendre les instructions ou renvoyer quelque chose de techniquement valide mais logiquement erroné. Et comme chaque jeton a un prix, je ne peux pas simplement réessayer la demande et espérer un meilleur résultat.
C’est à ce moment-là que j’ai commencé à me demander si les points de terminaison de l’IA devaient être conçus de la même manière que les points de terminaison conventionnels des API Web.
Un point de terminaison d’API Web conventionnel suit généralement un flux similaire :
valider la demande ↓ exécuter la logique métier ↓ renvoyer la représentationLa première phase est la validation de la demande. Nous validons les données entrantes par rapport aux contraintes de propriété, aux contrats API, aux règles d'autorisation et aux règles métier spécifiques à l'application.
La deuxième phase est l'exécution. L'application traite les données, effectue des opérations d'E/S ou exécute une logique métier.
La phase finale renvoie une représentation du résultat. Le code exécuté par un point de terminaison conventionnel est normalement déterministe dans un état d'application connu. Lorsque le même code s’exécute sur le même état, nous obtenons généralement le même résultat.
Et c’est fondamentalement tout.
Le flux général d’un point de terminaison d’API Web conventionnel est relativement simple, même si les étapes individuelles peuvent bien entendu être très complexes. Mais les modèles d’IA ne fonctionnent pas exactement de la même manière. Ils n’exécutent pas simplement une séquence prédéfinie d’instruction...
[Courte citation de 8% de l'article original]