Les complexités et défis de l’intégration des LLM dans les applications

Intégration des LLM dans les applications' - Complexity and challenges.

Planifier d’intégrer un service LLM dans votre code? Voici quelques défis courants auxquels vous devriez vous attendre lorsque vous le faites

Les grands modèles de langage (LLMs) existaient avant la sortie de ChatGPT et GPT API d’OpenAI. Mais grâce aux efforts d’OpenAI, GPT est désormais facilement accessible aux développeurs et aux non-développeurs. Ce lancement a sans aucun doute joué un rôle important dans la résurgence récente de l’IA.

Il est vraiment remarquable de voir à quelle vitesse l’API GPT d’OpenAI a été adoptée en seulement six mois après son lancement. Pratiquement tous les services SaaS l’ont intégré d’une manière ou d’une autre pour augmenter la productivité de leurs utilisateurs.

Cependant, seules les personnes ayant réalisé la conception et l’intégration de telles API comprennent réellement les complexités et les nouveaux défis qui en découlent.

Au cours des derniers mois, j’ai mis en œuvre plusieurs fonctionnalités qui utilisent l’API GPT d’OpenAI. Tout au long de ce processus, j’ai rencontré plusieurs défis qui semblent communs à toute personne utilisant l’API GPT ou toute autre API LLM. En les recensant ici, j’espère aider les équipes d’ingénierie à se préparer et à concevoir correctement leurs fonctionnalités basées sur LLM.

• La prescription de l’improvisation Utiliser l’improvisation pour aider les praticiens de l’analyse à effectuer des changements
• Certains pensent que ces emplois seront remplacés par l’IA. Nous ne sommes pas d’accord.
• 9 points clés à retenir de Comment devenir un scientifique des données par Adam Ross Nelson

Jetons un coup d’œil à certains des obstacles typiques.

Mémoire contextuelle et limitations de contexte

C’est probablement le défi le plus courant de tous. Le contexte pour l’entrée LLM est limité. Récemment, OpenAI a publié une prise en charge du contexte pour 16K tokens, et dans GPT-4, la limitation de contexte peut atteindre 32K, ce qui correspond à quelques pages (par exemple, si vous voulez que le LLM travaille sur un grand document contenant quelques pages).

Il existe différentes techniques pour surmonter ce défi, et d’autres sont en train d’émerger, mais cela signifierait que vous devez implémenter une ou plusieurs de ces techniques vous-même. Encore un travail supplémentaire à implémenter, tester et maintenir.

Enrichissement des données

Il est probable que vos fonctionnalités basées sur LLM prennent en entrée une sorte de données propriétaires. Que vous saisissiez des données utilisateur dans le cadre du contexte ou que vous utilisiez d’autres données ou documents collectés que vous stockez, vous avez besoin d’un mécanisme simple qui abstrait les appels de récupération de données à partir des différentes sources de données que vous possédez.

Modélisation

La consigne que vous soumettez au LLM contiendra du texte codé en dur et des données provenant d’autres sources de données. Cela signifie que vous allez créer un modèle statique et remplir dynamiquement les blancs avec les données qui devraient faire partie de la consigne au moment de l’exécution. En d’autres termes, vous allez créer des modèles pour vos consignes et en avoir probablement plusieurs.

Cela signifie que vous devriez utiliser une sorte de framework de modélisation car vous ne voulez probablement pas que votre code ressemble à une concaténation de chaînes de caractères.

Ce n’est pas un gros défi mais une autre tâche à considérer.

Tests et ajustement fin

Obtenir un niveau de précision satisfaisant pour le LLM nécessite beaucoup de tests (parfois c’est juste de l’ingénierie de consignes avec beaucoup d’essais et d’erreurs) et d’ajustements basés sur les commentaires des utilisateurs.

Il y a bien sûr aussi des tests qui s’exécutent dans le cadre de l’intégration continue pour vérifier que tout fonctionne correctement, mais ce n’est pas le véritable défi.

Quand je parle de tests, je parle d’exécuter la consigne de manière répétée dans un environnement isolé pour affiner les résultats en termes de précision.

Pour les tests, vous voudriez une méthode permettant à l’ingénieur de test de modifier les modèles, de les enrichir avec les données requises, et d’exécuter la consigne avec le LLM pour tester si nous obtenons ce que nous voulions. Comment mettre en place un tel cadre de test ?

De plus, nous devons constamment ajuster le modèle LLM en obtenant des commentaires de nos utilisateurs concernant les sorties du LLM. Comment mettons-nous en place un tel processus ?

Mise en cache

Les modèles LLM, tels que le GPT d’OpenAI, disposent d’un paramètre permettant de contrôler le caractère aléatoire des réponses, ce qui permet à l’IA d’être plus créative. Cependant, si vous traitez des demandes à grande échelle, vous devrez payer des frais élevés pour les appels à l’API, vous risquez de dépasser les limites de taux et les performances de votre application pourraient se dégrader. Si certaines entrées dans le LLM se répètent dans différents appels, vous pouvez envisager de mettre en cache la réponse. Par exemple, vous gérez 100 000 appels à une fonction basée sur le LLM. Si tous ces appels déclenchent un appel à l’API du fournisseur LLM, les coûts seront très élevés. Cependant, si les entrées se répètent (ce qui peut potentiellement se produire lorsque vous utilisez des modèles et les alimentez avec des champs utilisateur spécifiques), il y a de fortes chances que vous puissiez enregistrer une partie de la sortie prétraitée du LLM et la servir à partir du cache.

Le défi ici est de construire un mécanisme de mise en cache pour cela. Ce n’est pas difficile à mettre en œuvre, cela ajoute simplement une autre couche et une autre partie mobile qui doit être entretenue et réalisée correctement.

Sécurité et conformité

La sécurité et la confidentialité sont peut-être les aspects les plus difficiles de ce processus – comment nous assurer que le processus créé ne cause aucune fuite de données et comment nous assurer qu’aucune information d’identification personnelle (PII) n’est révélée ?

De plus, vous devrez auditer toutes vos actions afin que toutes les actions puissent être examinées pour garantir qu’aucune fuite de données ou violation de la politique de confidentialité ne s’est produite.

C’est un défi courant pour toute entreprise de logiciels qui dépend de services tiers, et cela doit également être abordé ici.

Observabilité

Comme pour toute API externe que vous utilisez, vous devez surveiller ses performances. Y a-t-il des erreurs ? Combien de temps prend le traitement ? Dépassons-nous ou sommes-nous sur le point de dépasser les limites de taux ou les seuils de l’API ?

De plus, vous voudrez journaliser tous les appels, non seulement à des fins d’audit de sécurité, mais aussi pour vous aider à ajuster votre flux de travail ou vos invitations LLM en évaluant les résultats.

Gestion des flux de travail

Prenons l’exemple du développement d’un logiciel juridique que les avocats utilisent pour augmenter leur productivité. Dans notre exemple, nous avons une fonction basée sur le LLM qui prend les coordonnées d’un client à partir d’un système CRM et la description générale de l’affaire en cours, et fournit une réponse à la question de l’avocat en se basant sur des précédents juridiques.

Voyons ce qu’il faut faire pour y parvenir :

1. Rechercher toutes les coordonnées du client en fonction d’un ID client donné.
2. Rechercher toutes les informations relatives à l’affaire en cours.
3. Extraire les informations pertinentes de l’affaire en cours à l’aide du LLM, en fonction de la question de l’avocat.
4. Combiner toutes les informations ci-dessus dans un modèle de question prédéfini.
5. Enrichir le contexte avec les nombreux cas juridiques. (rappel du défi de la mémoire contextuelle)
6. Demander au LLM de trouver les précédents juridiques qui correspondent le mieux à l’affaire en cours, au client et à la question de l’avocat.

Maintenant, imaginez que vous avez 2 ou plusieurs fonctionnalités avec de tels flux de travail, et essayez enfin d’imaginer à quoi ressemble votre code une fois que vous avez mis en œuvre ces flux de travail. Je parie que rien que d’y penser, vous vous sentez mal à l’aise sur votre chaise.

Pour que votre code soit maintenable et lisible, vous devrez mettre en œuvre différentes couches d’abstraction et peut-être envisager d’adopter ou de mettre en œuvre une sorte de framework de gestion des flux de travail, si vous prévoyez d’autres flux de travail à l’avenir.

Et enfin, cet exemple nous amène au défi suivant :

Fort couplage du code

Maintenant que vous êtes conscient de tous les défis mentionnés ci-dessus et des complexités qui en découlent, vous commencez peut-être à voir que certaines des tâches à accomplir ne devraient pas être de la responsabilité du développeur.

Plus précisément, toutes les tâches liées à la création de flux de travail, aux tests, à l’ajustement fin, à la surveillance des résultats et à l’utilisation de l’API externe peuvent être effectuées par quelqu’un de plus dédié à ces tâches et dont l’expertise ne consiste pas à construire des logiciels. Appelons cette persona l’ingénieur LLM.

Il n’y a aucune raison pour que les flux de travail LLM, les tests, l’ajustement fin, etc., soient placés sous la responsabilité du développeur de logiciels – les développeurs de logiciels sont des experts dans la construction de logiciels. Dans le même temps, les ingénieurs LLM devraient être des experts dans la construction et l’ajustement fin des flux de travail LLM, et non dans la construction de logiciels.

Mais avec les frameworks actuels, la gestion des flux de travail LLM est couplée au code. Celui qui construit ces flux de travail doit avoir l’expertise d’un développeur de logiciels et d’un ingénieur LLM.

Il existe des moyens de réaliser le découplage, comme la création d’un micro-service dédié qui gère tous les flux de travail, mais c’est encore un autre défi qu’il faut relever.

Ce ne sont là que quelques-uns des défis.

Je n’ai pas abordé la résolution de tous ces problèmes, car j’essaie toujours de les comprendre moi-même. Cependant, je peux dire que LangChain semble être le seul framework qui s’approche quelque peu de la résolution de ces problèmes, loin de tous les résoudre, et semble aller dans la bonne direction. Avec le temps, je crois que les fournisseurs de LLM amélioreront leurs offres et proposeront des plateformes capables de relever ces défis dans une certaine mesure.

Si vous avez d’autres défis à partager, n’hésitez pas à le faire dans les commentaires pour le bénéfice des autres lecteurs. De plus, si vous connaissez des outils pouvant aider à relever ces défis, partagez-les également dans les commentaires.

J’espère que vous avez trouvé cet article instructif ! Si c’est le cas, montrez votre soutien en ajoutant des applaudissements et en me suivant pour plus d’articles sur la construction d’équipe, l’ingénierie logicielle et la technologie.

We will continue to update IPGirl; if you have any questions or suggestions, please contact us!