coffreobsidian/inbox/Mise en place process (llmticket) avec Llama-vision3.2-90b.md

Utilisation du mdèle multimodal via Ollama

1. Capacités du modèle llama3.2-vision:90b-instruct-q8_0

Multimodalité native (texte + image) ce modèle est nativement multimodal: il a été entraîné sur des paires image-texte (environ 6 milliards) afin de raisonner sur du contenu visuel tout en tenant compte d'un contexte textuel.

Analyse croisée texte-image, il sait interpréter des images complexes graphiques, tableaux, interfaces logicielles, etc... et en extraire les informations pertinentes pour les mettre en regard du texte fourni. Cette capacité de "cross-analyse" signifie qu'il peut, par exemple, confronter la description d'un problème dans un ticket texte avec ce qui est affiché sur la capture d'écran jointe, pour produire une syntèse cohérente.

Base technologique du modèle Llama3.2-Vision repose sur un modèle de langage de base Llama3.1 (dérivé des Llama de Meta) auquel a été greffé un encodeur visuel et un adapter de vision. plus précisément, l'image est d'abord traitée par un réseau de vision pré-entraîné (un ViT-H/14, un tranformeur visuel de grande taille) pour obtenir des vecteurs représentant son contenu. Ces vecteurs d'image sont ensuite injectés dans le modèle de langage via des couches de cross-attention qui permettent au modèle de prêter attention à des parties spécifiques de l'image en fonction du texte en cours de traitement. Le modèle de bas environ 88 milliards de paramètres pour la version 90b reste principalement un modèle de langafe (type Llama) optimisé en mode instruct (affiné par apprentissage supervisé et RLHF pour suivre des consignes). Cette architecture combinée fait de lui l'un des modèes multimodaux open-source les plus performants de fin 2024, rivalisant avec des solutions propriétaires.

Capacités visuelles spécifiques - Grâce à cette architecture, le modèle est capable de reconnaissance visuelle avancée: identification d'objects, de texte présent dans l'image (OCR), interprétation de scènes complexes et même analyse de diagrammes ou graphiques. Des évaluations ont montré qu'il sait lire et interpréter du texte présent dans une image avec une grande fiablilité. Il peut également générer des légendes d'image (décrire en langage naturel ce qu'il voit) et répondre à des questions détaillées sur le contenu visuel. Toutes ce capacités en font un candidat idéal pour analyser des tickets support incluant des captures d'écran: il peut reconnaître une fenêtre d'erreur, lire le message d'erreur à l'écran, identifier des éléments d'interface, etc., puis formuler en langage naturel ce qu'il observe.

2. Support de la langue française

Compréhension du français - Le modèle comprend le français. En effet, Llama 3.2 a étét entraîné sur un large corpus multilingue et supporte officiellement 8 langues, dont le français, pour les tâches pruement textuelles. Ceal signifie qu'on peut fournir un ticket rédigé en français et s'attendre à ce que le modèle en saisisse le sens. Par exemple, il saura interpréter une description de bug ou un messge d'erreur en français dans le texte du ticket.

Qualité de génératon en français - Il peut générer des réponses en français de manière cohérente et grammaticalement correcte. Durant son fine-tuning instruct, il a été aligné non seulement sur l'anglais mais aussi sur plusieurs langues, ce qui inclut la capacité de répondre en français de façon naturelle. On peut donc lui demander une synthèse de ticket en français et obtenir un résultat fluide avec le vocabulaira adpaté au contexte. Il convient de noter toutefois que, la plupart des grands modèles étant dominés par l'anglais, il est toujours possible que le modèle soit légèremnt moins précis ou moins riche en français sur certains détails. Mais dans l'ensemble, son français est jugé fiable et utilisable en production, il fait partie des langeus prises en compte explicitement pendant son entraînement.

Instruction en anglais recommandées pour l'analyse d'images - Important : pour les tâches impliquant des images conjointement à du texte, les concepteurs du modèle indiquent que seul l'anglais est pleinement supporté dans les invites. En d'autres termes, les consignes ou questions portant sur le contenu visuel devraient de préférence être formulées en anglais pour que le modèle exploite au mieux l'image. Recommandation : dans un pipeline automatisé, il peut être utile de traduire la consigne en anglais lors de l'appel au modèle (tout en conservant la possibilité de traduire ensuite lea réponse en français pour l'utlisateur final). Alternativement, on peut inclure une instruction finale demandant au modèle de répondre en français, tout en écrivant le reste de l'invite en anglais pour bien analyser l'image. Par exemple: "Analyze the following ticket and screenshot, then summarize the issue. Answer in French" - cela combien une analyse une analyse optimisée en anglais et une restitution en français. En résumé, le français fonctionne très bien pour les entrées texte seules, mais pour les prompts multimodaux, l'anglais est recommandé afin d'exploiter pleinement la vision du modèle.

3. Best practices pour les prompts multimodaux

Structure du prompt (consigne + texte + image) - Il est crucial de structurer clairement le prompt pour distinguer l'instruction de la donnée du ticket. Une bonne approche est de séparer en segments logiques :

• D'abord, une consigne générale expliquant la tâche à l'IA.
• Ensuite, le text du ticket en tant que tel. Il est conseillé de le délimiter clairement, par exemple en le préfaçant d'un en-tête "Ticket utilisateur :" on en le plaçant entre guillemets ou balises markdown. On peut par exemple utiliser un bloc Markcown pour le ticket, cela permet au modèle de distinguer le texte du ticket de la consigne.
• Enfin, indiquer qu'une image est jointe. Avec Ollama, on ne met pas l'image dnas le texte même, mais on peut ajouter une ligne du type "Capture d'écran attrachée ci-dessous". Pour signaler son existence, puis fournir effectivemnt l'image via le format d'entrée (voir section suivante). Le modèle, en mode chat, reçoit l'image séparément mais on peut dans le texte y faire référence, par exemple "Voir image attachée" ou "voir capture d'écran fournie".

Cette structure aide le modèle à savoir qu'il doit prendre en compte deux sources d'information. Evitez de tout mêler dans un seul paragraphe confus : séparer clairement l'instrcution, le texte du ticket et l'indication d'image rnd le contexte plus compréhensible pour le modèles.

Formatage pour améliorer la qualité - l'utilisation de certains formats Markdown peut aider:

• Si le ticket contient des éléments techniques (extraits de log, code d'erreur, chemins de fichier...) il est judicieux de les mettre en forme comme du code ou une citation. Par exemple: “Le message d’erreur était : NullReferenceException at MyApp.ModuleX” ou en bloc de code. Le modèle reconnaîtra ainsi plus facilement que c'est un élément technique du ticket.
• Vous pouvez mettre en gras ou en italique des points importants dans la consigne pour guider l'attention du modèle. bien que le modèle ne voie pas la mise en forme comme un humain, cela structure tout de même le prompt textuellement et peut prévenir des malentendus.
• N'hésitez pas à poser plusieurs questions ou points à couvrir de façon structurée. Structurer ainsi la demande (par des numéros ou des puces) peut pousser le modèle à organiser s& réponse de manière similaire.

Intégration d'OCR ou métadonnées - Le modèle possède d'excellemntes capacités d'OCR intégrées (lecture de texte dans les images), ce qui lui permet souvent de lire directement les messages d'erreur ou labels présents sur une capture d'écran. Toutefosi, dans certains cas, il peut être utile d'aider le modèle:

• Si l'image contient beaucoup de texte en français (par ex, une longue trace d'eeruer ou un paragraphe dans la capture d'écran), et que vous craignez que le modèle n'en rate une partie, vous pouvez effectuer un pré-traitemnt OCR avec un outil externe. Le texte extrait peut alors être fourni en complément du prompt. Par exemple, après le texte du ticket, ajouter : "Texte détecté dans l'image: ..." suivi du contenu OCR principal. Le modèla aura ainsi explicitement le texte de l'image en entrée, ce qui garantit qu'il ne passe pas à côté.
• De même, vous pouvez ajouter des métadonnées contextuelles si elles sont pertinentes, comme le titre de la fenêtre capturée, le type d'écran. Cela peut orienter le modèle et désambiguïser l'iamge. Attention toutefois à ne pas introduire d'interprétation erronée: les métadonnées fournies doivent être bbjectives et certaines (sinon, mieux vaut laisser le modèle inférer par lui-même).

En résumé, le prompt doit clairemnt distinguer (a) la tâche demandée, (b) le contenu textuel du ticket, et (c) l'existence de l'iamge. L'utilisation de formats structurés (Markdown, listes , citations) rend le contexte plus lisibles. Le modèle étant très performatn en compréhension d'image, on n'a pas forcément besoin de tout lui mâcher, mais fournir le texte cru d'une image via OCR peut renforcer l'analyse, surtout pour du texte non-anglais dans l'image.

4. utilisation du modèle via Ollama

Nom et chargemnt du modèle - "llama3.2-vision:90b-instruct-q8_0". On peut le télécharger:

ollama pull llama3.2-vision:90b-instruct-q8_0

Configuration optimale

Par défaut, Ollama fournit des hyperparamètres adaptés:

• Temeprature: 0.6
• Top_p: 0.9 Ces valeurs conviennent à la plupart des cas pour obtenir des réponses utiles et fluides. Toutefois, pour une analyse de ticket factuelle (où l'on souhaite minimiser l'imagination du modèle et se concentrer sur les faits), il peut être judicieux de réduire la température vers 0.2 ou même 0.0. Une ptemératire basse force le modèle à des réponses plus déterministes et factuelles (moins de risque d'hallucination). On eut donc ajuster :
• temperature = 0 (ou très faible) pour un rapoort analytique neutre des faits du ticket
• top_p = 0.9 (par défaut) est généralement bien, mais peut-être abaissé (0.1-0.3) avec temp=0 pour forcer le modèle à ne choisir que les tokens les plus probables.
• max_tokens(longeur de réponse): définissez-le suffisamment haut (par ex. 1000 ou plus) si vous voulez une synthèse détaillée. Par défaut Ollma peut limiter la réponse à une certaine longueur.

Inclusion d'images (Base64, JSON) - Pour passer une image au modèle via Ollama, on utilise le champ dédié images dans le format JSON des messages. Par exemple, via l'API locale d'Ollama, on enverra une requête JSON du type:

{
  "model": "llama3.2-vision:90b-instruct-q8_0",
  "messages": [
    {
      "role": "user",
      "content": "Here is an image, what does it show?",
      "images": ["<DONNÉES_BASE64_DE_L_IMAGE>"]
    }
  ]
}

L'image doit être encodée en base64 dans ce JSON (ou bien, si vous utilisez le cleint python d'Ollama, vous pouvez passer directement le chamin du fichier image et la mibrairie se chage de l'encoder).

Limites connues - Malgré ses capacités impressionnantes, voici quelques limites techniques à garder en tête :

• Fenêtre de contexte : Le contexte maximal est rès grnas (128k tokens). Cela siginfie qu'en théorie le modèle peut avaler un ticket extrêmement long (des dizaines de pages de texte) et plusieurs images à la fois. Cependant, en pratique, triter un contexte géant peut être lent et gourmand en mémoire? Pour un usage vourant (analyse d'un ticket courant), on reste bien en-deçà de cette limite. Mais c'est rassurant de savoir qu'il est possible d'inclure, l'historique complet d'un échange avec le client ou de très longs logs si nécessaires, sans que le modèle oublie le début.
• Taille/résolution des images : Le modèle supporte des images haute résolution jusquà 1120 x 1120 pixels environ. Au-delà, l'necodeur d'image tronquera ou nécessitera un redimensionnement. En pratique, ceal couvre la pluaprt des capture d'écran partiellement. Il est donc préférables de redimensionner les captures trop larges avant l'envoi, pour rester dans cette fourchette. Gardez également un poids raisonnable pour ne pas alourdir inutilment la requête.
• Taille de sortie : La réponse du modèle étantdu texte, sa longuer est aussi soumise à la fenêtre de contexte (128k tokens max sortie comprise). En pratique, Ollama fixe une limite par défaut (souvent 512 tokens) que vous pouvez augmenter via max_tokens. Générer de très longues explications(plusieurs milliers de mots) est possible; mais cela peutprendre du temps. Il n'y a pas de "hard limit" autre que la mémoire disponible et les paramètres de décodage que vous choisissez. Assurez-vous simplement d'adapter max_tokens si vous attendez un rapport détaillé.
• Nature de la sortie : Le modèle ne génère que du texte. Il ne renverra pas d'images ni peut agir en dehors de la génération textuelle. C'est un modèle purement génératif textuel, ce qui conveitn au cas d'usage (écrire un rapport). De plus, comme tous les modèles de langage, ses connaissances du monde s'arrêtent à la date de fin de son entraînement(décembre 2023). Pour un ticket support, ce n'est généralement pas un problème.
• Ressources matérielles : Un mot sur la performance - la version 90b quantifiée 8bit pèse 95Go. il faut donc une machine avec suffisamment de VRAM pour l'inférer.

5. Exemples de prompts efficaces

Voici quelques exemples de prompts bien structurés pour différents scénarios, illustrant comment formuler la demande au modèle llama3.2-vision:90b-instruct-q8_0 dans le contexte de tickets support. Ces prompts sont rédigés en fonction des best practices ci-dessus.

• Exemple 1 – Analyse d’un ticket texte seul (sans image)
  Contexte: Un utilisateur a envoyé un ticket détaillé en français, sans capture d’écran.
  Prompt (utilisateur) :

  text

  CopierModifier

  Vous êtes un assistant de support technique. Lisez le ticket client ci-dessous et fournissez un compte-rendu factuel du problème. N’incluez pas de solution, contentez-vous de résumer les symptômes et informations fournies. Ticket utilisateur : "Bonjour, depuis la mise à jour de ce matin, mon application ne démarre plus. J’obtiens le message d’erreur `Erreur 500 : Service Indisponible`. J’ai essayé de redémarrer mon PC mais rien n’y fait. Pouvez-vous m’aider à comprendre d’où vient le problème ?"

  Explication: Ici, la consigne initiale indique le rôle du modèle et la tâche (« compte-rendu factuel sans solution »). Le texte du ticket est clairement délimité entre guillemets. Le modèle, en lisant ce prompt, identifiera les éléments clés : contexte (mise à jour ce matin, appli ne démarre pas), message d’erreur exact, tentative déjà effectuée par l’utilisateur, etc. La réponse attendue sera en français, par exemple un paragraphe récapitulant ces points.

• Exemple 2 – Analyse d’une image seule (capture d’écran isolée)
  Contexte: On dispose uniquement d’une capture d’écran montrant une erreur à l’écran, sans texte d’accompagnement du client. Par exemple, un écran bleu d’erreur Windows ou une boîte de dialogue d’erreur.
  Prompt (utilisateur) :
  (envoyé avec l’image attachée)

  text

  CopierModifier

  The user provided a screenshot of an error. Without additional context, please describe what the screenshot shows and any error messages visible.

  (L’image erreur_windows.png est fournie via Ollama dans le champ images.)
  Explication: Dans cet exemple, on pose la question en anglais, car on veut exploiter au mieux l’analyse visuelle de l’image seule. La consigne demande de décrire ce que montre la capture et de relever tout message d’erreur visible. Le modèle va examiner l’image : par exemple, s’il s’agit d’un Blue Screen of Death, il pourra lire le code d’arrêt affiché et retourner une description du type “The screenshot shows a Windows blue screen error with the code 0x00000050 (PAGE_FAULT_IN_NONPAGED_AREA).”. Si on souhaite la réponse en français, on aurait pu ajouter “Réponds en français.” à la fin du prompt. Cet exemple montre comment formuler la question spécifiquement sur l’image lorsqu’aucun texte de ticket n’est présent.

• Exemple 3 – Analyse croisée d’un ticket + capture d’écran
  Contexte: Un utilisateur soumet un ticket avec du texte et une capture d’écran. Le texte dit par exemple “…voir capture pour le message exact” en référence à l’erreur affichée.
  Prompt (utilisateur) :
  (envoyé en deux parties : texte + image)

  text

  CopierModifier

  Vous êtes un assistant support. Un client a soumis un ticket et une capture d’écran. Analysez les deux pour fournir un rapport synthétique du problème rencontré, en français. Ne proposez pas de solution. Ticket : "Lorsque j’essaie d’imprimer un document, rien ne se passe et j’ai une erreur. Voir capture pour le message exact affiché." (Image attachée : capture_ecran_erreur_imprimante.png)

  Explication: Ce prompt combine une instruction en français et le texte du ticket (qui mentionne une erreur lors d’une impression). L’image attachée supposée montre peut-être une fenêtre avec un message d’erreur spécifique (ex: « Printer not found » en anglais, ou « Imprimante introuvable » en français). Le modèle va lire le texte du ticket, puis analyser l’image pour trouver le “message exact affiché”. Grâce à ses capacités, il pourrait en extraire : « Le message d’erreur sur la capture indique : Imprimante introuvable*». La synthèse qu’il produira intègrera les deux sources : par exemple “L’utilisateur ne parvient pas à lancer une impression. Une erreur s’affiche à l’écran (Imprimante introuvable d’après la capture). Le problème est survenu lorsqu’il a essayé d’imprimer un document et aucune impression ne se lance.” Ceci fournit au support un rapport clair combinant le texte du ticket et l’information clé extraite de l’image (le message d’erreur précis).

Ces exemples illustrent comment structurer vos entrées pour tirer le meilleur parti de llama3.2-vision:90b-instruct. En suivant ces modèles – consigne claire, séparation du texte et des images, et éventuellement utilisation judicieuse de l’anglais pour l’analyse visuelle – vous pourrez concevoir un agent local intelligent capable de lire un ticket client en français, de prendre en compte les captures d’écran associées, et d’en produire une synthèse factuelle croisée texte + image sous forme de rapport clair (sans proposer de solution technique, si tel est le cahier des charges). Avec des réglages appropriés, ce modèle d’Ollama vous permettra d’automatiser efficacement l’analyse de tickets support multimodaux tout en conservant la qualité et la précision attendues.