Utiliser des LLM sans dépenser d'argent - Différentes stratégies de requête de base de données

La convergence continue des technologies d’IA et des systèmes de santé a apporté de nombreuses avancées convaincantes. Plantons le décor. Si vous avez interagi avec des modèles dynamiques comme ChatGPT, vous avez peut-être, comme beaucoup d'entre nous, commencé à envisager son application à l'aide de vos ensembles de données uniques. Supposons que, dans le secteur de la santé, vous souhaitiez associer cette technologie aux dossiers de santé électroniques (DSE) ou aux dossiers médicaux électroniques (DME), ou peut-être que vous visiez une interopérabilité accrue en utilisant les ressources de FHIR.  Tout se résume à la façon dont nous transférons/recevons des données contextuelles vers/depuis les LLM disponibles sur le marché.

Des techniques plus précises incluent le réglage fin et la formation des LLM exclusivement avec les ensembles de données contextuelles. Sauf que cela coûte aujourd’hui des millions de dollars pour y parvenir. L'autre méthode consiste à fournir du contexte aux LLM via des requêtes ponctuelles ou en quelques étapes et à obtenir une réponse. Certaines façons d'y parvenir sont les suivantes : générer des requêtes SQL, générer du code à interroger/analyser, effectuer des appels avec des informations provenant des spécifications de l'API, etc. Mais il existe un problème de consommation élevée de jetons et certaines de ces réponses peuvent ne pas toujours être exactes.

Il n’existe pas de solution unique, mais comprendre les avantages et les inconvénients de ces techniques peut être utile pour élaborer votre propre stratégie. En outre, tirer parti des bonnes pratiques d’ingénierie (comme les caches, le stockage secondaire) et se concentrer sur la résolution de problèmes peut aider à trouver un équilibre entre les méthodes disponibles. Cet article est une tentative de partager certaines stratégies et de les comparer selon différentes mesures.

Génération de requêtes SQL

Tout d'abord, nous avons la méthode la plus conventionnelle : charger et analyser la structure de la base de données SQL et l'exemple de contenu via LangChain et exécuter des requêtes GPT. Cette méthode a fait ses preuves en facilitant une communication efficace et dynamique avec nos systèmes de santé, se présentant comme une technique éprouvée dans notre industrie.

Il existe des solutions qui transmettent uniquement la structure de la base de données (schéma de table par exemple) et d'autres qui transmettent des données rédigées pour aider le LLM à générer des requêtes précises. La première solution présente l’avantage d’une utilisation fixe des jetons et de coûts prévisibles, mais elle perd en précision car elle n’est pas complètement adaptée au contexte. Cette dernière solution pourrait nécessiter davantage de jetons et nécessiter une attention particulière en matière de techniques d'anonymisation.  Ces solutions pourraient être parfaites pour certains cas d’utilisation, mais existe-t-il une stratégie plus optimale ?

Utiliser des LLM pour générer du code afin de naviguer dans les API et les requêtes de base de données

Une autre technique sophistiquée consiste à laisser les LLM générer du code pour décomposer une question en plusieurs requêtes ou appels d'API. Il s'agit d'une manière très naturelle de résoudre des questions complexes et de libérer le pouvoir de la combinaison du langage naturel et du code sous-jacent.

Cette solution nécessite une bonne ingénierie des invites et un réglage précis des invites du modèle pour qu'elles fonctionnent bien dans tous les cas particuliers. L'intégration de cette solution dans un contexte d'entreprise peut s'avérer difficile en raison des incertitudes liées à l'utilisation des jetons, à la génération de code sécurisé et au contrôle des limites de ce qui est et n'est pas accessible par le code généré. Mais dans son ensemble, le pouvoir de cette technique d’agir de manière autonome pour résoudre des problèmes complexes est fascinant et de nouvelles avancées dans ce domaine sont à espérer.

Chargement des spécifications OpenAPI comme contexte pour les LLM

Notre équipe souhaitait essayer une approche différente pour contrôler l'utilisation des jetons, mais également exploiter le contexte disponible pour obtenir des résultats précis. Que diriez-vous d’utiliser LangChain pour charger et analyser les spécifications OpenAPI de FHIR ? OpenAPI se présente comme une alternative percutante, dotée de procédures adaptatives et standardisées, validant l'importance des normes API complètes de FHIR. Son avantage distinct réside dans la promotion d’un échange de données sans effort entre divers systèmes. Le contrôle ici réside dans la possibilité de modifier les spécifications elles-mêmes et non les invites ou les sorties générées par le LLM.

Imaginez le scénario : une API POST effectue toutes les vérifications de validation requises avant que les données ne soient ajoutées à la base de données. Imaginez maintenant tirer parti de la même API POST, mais en utilisant une méthode de langage naturel. Elle effectue toujours les mêmes contrôles rigoureux, garantissant cohérence et fiabilité. Cette nature d'OpenAPI simplifie non seulement les interactions avec les services et applications de soins de santé, mais améliore également la compréhensibilité des API, les rendant faciles à comprendre et prévisibles.

Nous comprenons que cette solution n'a pas le même pouvoir que la décomposition autonome des tâches ou la génération de code, mais l'objectif est d'arriver à une solution plus pratique qui peut être adaptée rapidement à la plupart des cas d'utilisation.

Comparaison

Bien que toutes ces techniques démontrent des avantages uniques et le potentiel de servir différents objectifs, évaluons leurs performances par rapport à certains paramètres.

1. Fiabilité - Donnant la priorité à la fiabilité compte tenu de notre alliance avec l'IA, OpenAPI a un avantage en raison de son utilisation d'API standardisées. Cela garantit un accès non autorisé restreint et une authentification précise de l'utilisateur à des données spécifiques, offrant ainsi une sécurité améliorée des données par rapport à la transmission du SQL généré par l'IA pour l'accès à la base de données - une méthode qui pourrait potentiellement soulever des problèmes de fiabilité.

2. Coût - L'efficacité des capacités de filtrage de l'API définies par FHIR joue un rôle dans la réduction des coûts. Cela permet de traiter uniquement les données nécessaires, rationalisées grâce à une ingénierie d'invite intense, contrairement aux bases de données traditionnelles qui peuvent renvoyer plus d'enregistrements que nécessaire, entraînant des augmentations de coûts inutiles.

3. Performances - La présentation structurée et standardisée des données par les spécifications OpenAPI contribue souvent à des résultats de sortie supérieurs à partir des modèles GPT-4, améliorant ainsi les performances. Toutefois, les bases de données SQL peuvent renvoyer des résultats plus rapidement pour les requêtes directes. Il est important de tenir compte du potentiel de surinformation de l'Open API en raison de la définition de plus de paramètres que ce qui pourrait être nécessaire pour une requête.

4. Interopérabilité - Les spécifications OpenAPI brillent en matière d'interopérabilité. Indépendants de la plate-forme, ils s'alignent parfaitement sur la mission de FHIR visant à renforcer l'interopérabilité des soins de santé, en favorisant un environnement collaboratif pour une synchronisation transparente avec d'autres systèmes.

5. Implémentation et maintenance - Bien qu'il puisse être comparativement plus facile de créer une base de données et de fournir le contexte à l'IA pour les requêtes, la méthode de chargement de base de données SQL avec sa couche de contrôle allégée peut sembler plus facile à mettre en œuvre, les spécifications OpenAPI , une fois maîtrisés, offrent des avantages tels que la standardisation et une maintenance plus facile qui dépassent la courbe d'apprentissage et d'exécution initiale.

6. Évolutivité et flexibilité - Les bases de données SQL exigent un schéma rigide qui peut ne pas permettre confortablement l'évolutivité et la flexibilité. Contrairement à SQL, OpenAPI offre une solution plus adaptative et évolutive, ce qui en fait une alternative tournée vers l'avenir.

7. Éthique et préoccupations - Un facteur important, mais complexe à prendre en compte compte tenu de la croissance rapide de l'IA. Seriez-vous à l’aise de fournir un accès direct à la base de données aux clients, même avec des filtres et une authentification ? Réfléchissez à l’importance des désidentifiants de données pour garantir la confidentialité au sein de l’espace de soins de santé. Même si les bases de données OpenAPI et SQL disposent de mécanismes pour répondre à ces problèmes, la standardisation inhérente fournie par OpenAPI ajoute une couche de sécurité supplémentaire.

Bien que cette discussion offre un aperçu de certains des facteurs clés à prendre en compte, il est essentiel de reconnaître que le choix entre SQL, la génération de code et OpenAPI est multiforme et soumis aux exigences spécifiques de vos projets et organisations.

N'hésitez pas à partager vos réflexions et vos points de vue sur ce sujet. Peut-être avez-vous des points supplémentaires à suggérer ou souhaitez-vous partager quelques exemples qui ont le mieux fonctionné pour votre cas d'utilisation.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!