Je te veux comme modèle !
‍

Plus de 1 300 000 modèles ?

Hugging Face pour ceux qui ne connaissent pas est le point de rencontre de tout ce qui se fait en matière de modèles d’IA. Les modèles sont catégorisés en fonction de leurs usages :

• Traitement du langage naturel (classification, génération de texte, traduction,...)
• Vision (classification d'images, classification de vidéos, image vers texte,....)
• Audio ( Classification, son vers texte, texte vers son,...)
• "Tabulaire" : Classification, prévision à partir de séries temporelles)
• Modèles multimodaux (modèles capable de réaliser différentes tâches)

Comment ne pas y perdre son latin ? Pourquoi autant de modèles ?

Pour commencer, comme sur Github, n'importe qui peut publier un modèle. Par conséquent, les modèles se multiplient un peu comme les forks se multiplient sur GitHub. Certains vont proposer des modèles compressés ("quantizés"), d'autres vont proposer des modèles fine-tunés pour des tâches bien spécifiques.
‍

Depuis 2022, les LLM sortent du lot avec leurs capacités qui dépassent l'entendement. Les multimodaux repoussent encore les limites de ce qu'il est possible de faire avec ces monstres. Les SLM (Small Language Modèle) ont également le vent en poupe. Avec des capacités de génération dans les règles de l'art, les SLM sont spécialisés et peuvent s'exécuter avec moins de ressources. Si mon IA doit manipuler des données financières, je n'ai pas besoin qu'elle puisse me donner la recette des crêpes ou la procédure pour changer la batterie d’une voiture ! Un plus petit modèle peut suffire.

Certes, les LLM des plus grands acteurs sont impressionnants et seront difficiles à remplacer pour adresser les tâches les plus complexes.

D'ailleurs comme l'hybridation du cloud, nous assistons à une hybridation de l'IA. Par exemple : Les données privées peuvent être traitées par de l'IA interne ou alors préalablement être anonymisées avant d'être soumises aux grands LLM.

‍

{{cta-modernisez-votre-it-digital-factory="/cta"}}
‍

Mais quel modèle choisir ?

Lorsque vous souhaitez déployer une IA en local, la réalité c'est que vous déployez rarement un seul modèle, vous en aurez probablement besoin de plusieurs. Il faut les tester, les étudier et avoir une vision précise de ce que l'on attend du modèle pour répondre aux différents cas d'usage.

• Vous voulez juste un modèle capable de répondre à des questions courantes, faire des résumés, catégoriser etc, le choix est large ! (les modèles de MistralAI, Deepseek, Llama, etc,...)
• Vous voulez mettre en place un RAG, il y a fort à parier que vous utiliserez un autre modèle plus petit pour réaliser l'embeddings de vos chunks avant de les stocker dans une base vectorielle par exemple.
• Vous voulez mettre en place un assistant capable de répondre en temps réel sur les données de votre ITSM ou de votre solution de supervision. Ici, ce sont vraisemblablement les capacités de "function calling" du modèle qui vous intéresserons.

Lorsque nous testons un nouveau modèle. Au-delà de la précision de sa génération de texte, nous accordons une grande importance à la notion de "function calling ou tool calling" (voir en bas de l'article si cela ne vous évoque rien). Il est essentiel de tester les modèles pour s'assurer qu'ils répondent au cahier des charges :

• le modèle est-il capable de détecter un tool call malgré un historique conversationnel important ?
• le modèle est-il capable de retourner plusieurs tools au sein d'une même conversation ?
• Les appels aux tools peuvent-ils être parallélisés ?
  ‍

Quand cela se complique

Lorsqu'un modèle ne répond pas aux exigences, les choses peuvent se compliquer si une manipulation habile du prompt ne suffit pas pour atteindre les résultats escomptés.

Pour "ré-entrainer" complètement un LLM, il vous faudra quelques cartes GPUs. En effet, l'entraînement complet d'un gros LLM (nécessite généralement des centaines, voire des milliers de GPU pendant plusieurs semaines ou mois). Pour fine-tuner un modèle sans avoir à recalculer les poids de ses milliards de paramètres, on peut se tourner vers LORA ( Low-Rank Adaptation) qui consiste à figer les paramètres existants et à entraîner d'autres paramètres. Le plus difficile étant d'avoir à sa disposition un jeu de données propre et vérifié pour entrainer le modèle.

‍

{{cta-modernisez-votre-it="/cta"}}
‍

Function call

La notion de tool-calling ou function-calling est très intéressante.

La notion de function call n'est pas éloignée du RAG car elle permet de générer du texte à partir de données sur lesquelles le LLM n'a pas été entraîné. Nous utilisons cette notion essentiellement pour conversationner avec des données en temps réel ou pour effectuer des requêtes sur le web.

Par exemple : Quel est l'état du serveur MONSERVEUR1 ? Dans combien de temps le disque de mon serveur sera-t-il saturé ? Mon dernier incident a-t-il été résolu ?

Comment ça marche ? C'est "simple". Prenons l'exemple d'un assistant qui permet d'obtenir des infos depuis un outil ITSM.
‍

1) Vous créez une fonction "get_all_tickets()" dans votre langage préféré qui permet de lister tous les tickets d'un utilisateur.

2) Vous envoyez la description de cette fonction au LLM en même temps que la question de l'utilisateur.

3) Le LLM va évaluer la pertinence d'appeler ou non cette fonction, puis retourner le résultat :

• sous la forme d'un texte si la fonction n'est pas pertinente dans le contexte
• Un "toolcall" si la fonction est pertinente

4) S'il s'agit d'un tool call. Vous devrez exécuter la fonction puis retourner le résultat de cette exécution avec la question initiale de l'utilisateur au LLM.

[Tu peux utiliser les outils suivants pour répondre à la question de l'utilisateur :

<Description de la fonction>

get_all_tickets()

Description : cette fonction permet de récupérer la liste des tickets

Parameters: ...

...

<Fin de description>

Peux-tu lister mes incidents en cours ?

Le LLM devrait répondre par un tool call (get_all_ticket()) car le contexte de la question est bien lié à un outil qu'il peut utiliser.

ChatCompletionMessage(content='[{"name": "get_all_tickets", "arguments": {}}]', refusal=None, role='assistant', function_call=None, tool_calls=[])

Comme on peut le voir dans le retour du LLM. Pas de réponse à notre question mais plutôt la proposition d'exécuter un tool. C'est vous qui devez l'exécuter, pas le LLM.

Le prompt (simplifié) final sera par exemple :

[ Résultats de l'exécution de get_all_tickets() :

R-120391 : Problème d'impression depuis mont poste, date ouverture...

R-120392 : Impossible d'accéder à l'application X... ]

Peux-tu me lister mes incident en cours ?

En conclusion, Function call et RAG ont le même but. Utiliser une IA générative pour traiter des données privées en temps réel ou non.

[Function call, nous n'avons pas d'autre explications...]

A l'heure actuelle, nous testons le modèle d'unsloth Mistral-Small-24B-Base-2501-bnb-4bit sur une seule carte A10G de 24Go. Nous avons réduit la taille du contexte, mais cela fonctionne vraiment bien, il coche beaucoup de cases !

Attention ! Il faut être conscient que la quantization réduit nécessairement la précision. Le choix du modèle doit donc être adapté au cas d'usage.

‍

{{cta-contact="/cta"}}

‍

Article rédigé par Davy NEDELEC, Responsable du Pôle Innovation & Performance chez Ozitem

‍