Ladebeze66/coffreobsidian
1
0
Fork 0
mirror of https://github.com/Ladebeze66/coffreobsidian.git synced 2025-12-16 10:17:45 +01:00
Code Issues Packages Projects Releases Wiki Activity
coffreobsidian/Stage/Recherches llama3.2-vision 90b.md
Ladebeze66 3d0079a231 Mise à jour rapide
2025-03-27 16:48:21 +01:00

34 KiB
Raw Permalink Blame History

Recherche de tous les paramètres modifiables pour le modèle multimodal llama3.2-vision:90b dans le cadre d'une utilisation avec Ollama. Cela inclura :

  • Les paramètres exploitables via l'API (JSON, Python)

  • Les paramètres personnalisables via un fichier Modelfile

  • La manière d’utiliser ces paramètres dans un contexte d’analyse d’image et de texte (dans ton cas : image + JSON support client)

Paramètres du modèle Llama 3.2-Vision 90B avec Ollama

1. Paramètres disponibles via l’API Ollama (Python, CLI, JavaScript)

Ollama expose plusieurs paramètres de génération pour contrôler les réponses du modèle. Les principaux incluent : la température (pour moduler la créativité, 0 = déterministe, >1 = plus aléatoire, défaut ~0.8) (ollama/docs/modelfile.md at main · ollama/ollama · GitHub), le top_p (filtrage nucléaire, défaut ~0.9) (ollama/docs/modelfile.md at main · ollama/ollama · GitHub), le top_k (taille du vocabulaire échantillonné, défaut 40) (ollama/docs/modelfile.md at main · ollama/ollama · GitHub), la pénalité de répétition (repeat_penalty, défaut 1.1) pour éviter les redites (ollama/docs/modelfile.md at main · ollama/ollama · GitHub), la longueur du contexte (num_ctx, fenêtre de tokens, défaut 2048) (ollama/docs/modelfile.md at main · ollama/ollama · GitHub), le nombre max de tokens générés (num_predict, -1 = illimité par défaut) (ollama/docs/modelfile.md at main · ollama/ollama · GitHub), ainsi que des options avancées comme Mirostat (contrôle adaptatif de perplexité, désactivé par défaut) (ollama/docs/modelfile.md at main · ollama/ollama · GitHub) et min_p (seuil probabiliste minimal alternatif à top_p) (ollama/docs/modelfile.md at main · ollama/ollama · GitHub). Vous pouvez aussi fixer un seed aléatoire pour reproductibilité (ollama/docs/modelfile.md at main · ollama/ollama · GitHub). La plupart de ces paramètres sont accessibles via l’API en les passant dans le champ options de la requête JSON ou via des drapeaux en CLI (ex : --temperature 0.7 --top-p 0.9) (Ollama Cheatsheet - How to Run LLMs Locally with Ollama).

Pour les images, Llama 3.2-Vision attend une liste d’images dans les messages d’entrée. Via l’API ou les librairies, on fournit un tableau de chemins de fichiers image (ou leur contenu encodé en base64) associé au message utilisateur (llama3.2-vision:90b) (ollama/docs/api.md at main · ollama/ollama · GitHub). Par exemple en Python : messages=[{'role': 'user','content': 'Question sur l’image','images': ['image.png']}] (llama3.2-vision:90b). En CLI, on peut glisser-déposer une image dans le terminal ou indiquer son chemin après le prompt (Llama 3.2 Vision · Ollama Blog) (Llama 3.2 Vision · Ollama Blog). Formats supportés : les formats standards (PNG, JPG, BMP…) conviennent. Notez que la taille de l’image ne doit pas excéder ~1120×1120 pixels (Chat with Your Images Using Llama 3.2-Vision Multimodal LLMs | by Lihi Gur Arie, PhD | TDS Archive | Medium) pour être entièrement prise en compte. (Si une image dépasse, il peut être utile de la redimensionner en amont.)

Plusieurs paramètres de format de réponse et de comportement peuvent être passés dans la requête API :

En pratique, ces paramètres sont utilisables via toutes les interfaces d’Ollama : par exemple avec la librairie JavaScript on peut passer temperature ou format dans l’objet options du chat (ollama/docs/api.md at main · ollama/ollama · GitHub), et en CLI on dispose de flags correspondants (--temperature, --top-p, etc.) (Ollama Cheatsheet - How to Run LLMs Locally with Ollama). Par exemple, ollama run llama3.2-vision:90b --temperature 0.1 --top-p 1.0 "Votre question" lancera le modèle 90B localement avec une température basse (sortie plus focalisée) (Ollama Cheatsheet - How to Run LLMs Locally with Ollama). De même, l’API REST (POST /api/chat) accepte un JSON contenant model, messages (avec éventuellement images intégrées) et un champ options pour les hyperparamètres (ollama/docs/api.md at main · ollama/ollama · GitHub).

2. Paramètres supplémentaires via un fichier Modelfile personnalisé

Ollama permet de créer un fichier Modelfile pour personnaliser la configuration d’un modèle. Ce fichier agit comme une recette de modèle, où l’on peut définir :

En résumé, le Modelfile permet de prérégler le modèle sans fine-tuning lourd. Pour l’utiliser, on crée le fichier puis on exécute ollama create nom-modele -f Modelfile, ce qui génère un modèle personnalisable qu’on peut ensuite ollama run comme n’importe quel modèle local (ollama/docs/modelfile.md at main · ollama/ollama · GitHub). Tous les paramètres définis (température par défaut, message système, etc.) s’appliqueront alors aux réponses de ce modèle par défaut, sauf override via l’API (champs system, options, etc. peuvent encore venir écraser ces valeurs si besoin) (ollama/docs/api.md at main · ollama/ollama · GitHub).

3. Utilisation des paramètres pour un cas d’analyse conjointe image + ticket JSON

Dans un cas de ticket de support technique comportant un historique (texte) et des captures d’écran associées, voici comment exploiter les paramètres :

  • Inclusion des images : on peut fournir une ou plusieurs images en entrée du modèle en les attachant au message utilisateur. Concrètement, via l’API ou les SDK, on crée un message avec role: "user", puis on place le texte décrivant la demande dans content et on ajoute la liste des images dans images (ollama/docs/api.md at main · ollama/ollama · GitHub). Par exemple, si l’utilisateur fournit deux captures (“screen1.png” et “error.bmp”), on aura :

    {
  "role": "user",
  "content": "Voici le dialogue du ticket support (voir ci-dessous) et deux captures d’écran en pièce jointe.",
  "images": ["screen1.png", "error.bmp"]
}

    Remarque : Llama 3.2-Vision est officiellement optimisé pour une image à la fois – il peut accepter plusieurs images, mais les développeurs notent que le modèle n’est pas encore fiable avec plusieurs images simultanées (meta-llama/Llama-3.2-11B-Vision-Instruct · Does Llama-3.2 Vision model support MultiImages?). Il est donc prudent, si possible, de limiter à une image par requête pour une analyse précise, ou d’analyser les images une par une. Dans le contexte d’un ticket, on peut par exemple d’abord interroger le modèle sur la première capture puis sur la seconde, et combiner les résultats. Si les images contiennent beaucoup d’informations textuelles (ex: capture d’écran de log), le modèle peut en extraire le texte (OCR) et le comprendre (llama3.2-vision:90b), mais assurez-vous de décrire ou nommer chaque image dans le prompt pour qu’il sache à quoi elles correspondent.

  • Fournir la chronologie de discussion : Le contenu JSON du ticket (conversations entre le client et le support) doit être intégré d’une manière compréhensible par le modèle. Vous pouvez concaténer les messages du ticket en un seul bloc de texte structuré (par ex. en précisant les interlocuteurs et timestamps) et le placer dans le content du message utilisateur. Alternativement, Ollama gère les conversations multi-tour : on pourrait reconstruire la chronologie comme une suite de messages user/assistant pour mimer le dialogue d’origine dans le contexte. Par exemple, utiliser des entrées messages=[{"role":"user","content":"[client] ..."}, {"role":"assistant","content":"[support] ..."}, ...] reprenant l’échange original. Toutefois, comme le modèle est instruction-tuned (format question/réponse), il peut être plus simple de tout fournir dans un seul message utilisateur avec une distinction claire entre les tours de parole (texte formaté, listes, etc.), puis de demander une analyse. L’important est que le modèle reçoive toutes les informations textuelles du ticket dans le contexte. Si le JSON est complexe, on peut extraire les champs pertinents (par ex. seulement la timeline des messages) plutôt que coller le JSON brut.

  • Paramètres de contexte et longueur : Les tickets de support peuvent être longs. Assurez-vous que le modèle a une fenêtre de contexte suffisante (num_ctx). Llama 3.2-Vision 90B supporte une contexte étendu jusqu’à 128k tokens maximum (Chat with Your Images Using Llama 3.2-Vision Multimodal LLMs | by Lihi Gur Arie, PhD | TDS Archive | Medium), mais cela dépend de la configuration. Par défaut, Ollama limite à 2048 tokens si non modifié (ollama/docs/modelfile.md at main · ollama/ollama · GitHub). Dans un Modelfile custom ou via options, on peut augmenter num_ctx (ex. 4096, 8192, etc.) pour englober un long historique. Gardez à l’esprit que plus de contexte consomme plus de VRAM/temps. La 90B est lourde (≥64 Go VRAM requis) (Llama 3.2 Vision · Ollama Blog), donc ajustez en fonction de votre hardware. Si le ticket dépasse la limite, envisagez de le résumer par étapes (par ex. fournir d’abord la première moitié, obtenir un résumé, puis la seconde).

  • Paramètres de format de sortie : Dans ce cas d’analyse, il peut être utile de demander une réponse structurée. Par exemple, on pourrait définir format: "json" dans la requête pour que le modèle renvoie son analyse du ticket dans un format JSON structuré (ollama/docs/api.md at main · ollama/ollama · GitHub) – pratique pour extraire automatiquement des champs (comme problème, diagnostic, solution proposée). On fournira alors dans le prompt une instruction du type “Analyse ce ticket et fournis la réponse au format JSON suivant : {...}”. Le paramètre format garantira que la réponse est effectivement bien formée en JSON selon le schéma donné (ollama/docs/api.md at main · ollama/ollama · GitHub).

  • Message système et indications : Pour guider le modèle, on peut inclure un message système spécial (via l’API ou le Modelfile) qui précise le rôle : par ex. « Tu es un assistant support technique expert. On te fournit un historique de conversation client-support et des captures, analyse la situation… ». Ce message contexte peut améliorer la pertinence de l’analyse (en orientant le modèle à adopter un ton analytique et à ne pas halluciner d’informations externes). C’est une bonne pratique pour les cas de support client.

  • Langue : Notez que pour les tâches image + texte, Llama 3.2-Vision est entraîné principalement en anglais (llama3.2-vision:90b). Il comprend plusieurs langues en entrée textuelle (le français fait partie des langues supportées pour le texte seul (llama3.2-vision:90b)), mais lorsqu’il s’agit de raisonner sur une image, ses capacités ont été calibrées sur des instructions en anglais. Cela signifie que si l’on pose la question ou décrit l’image en français, le modèle pourrait être moins performant. Une approche consiste éventuellement à poser la question en anglais pour la partie image (par ex. “Que montrececi ?” sur l’image) puis de traduire la réponse en français. Dans un contexte de ticket francophone, on peut tout de même lui fournir le contenu tel quel en français – il saura le lire – mais il pourrait être utile de reformuler la consigne d’analyse d’image en anglais dans le prompt système ou utilisateur pour tirer le meilleur de la vision. C’est un compromis à considérer pour améliorer la compréhension conjointe.

4. Paramètres et approches pour améliorer l’analyse conjointe image+texte

Plusieurs réglages et approches de prompt peuvent renforcer la compréhension du modèle dans un scénario multimodal de support client :

  • Utilisation optimale du contexte multimodal : Profitez du fait que Llama 3.2-Vision a été entraîné spécifiquement pour relier vision et langage. Il excelle en description d’images, en raisonnement visuel et en Q&R sur des contenus visuels (llama3.2-vision:90b). Pour exploiter cela, assurez-vous que le prompt lie clairement l’image et le texte. Par exemple, faites référence à l’image dans votre question (« …voir image ci-jointe ») afin que le modèle sache qu’il doit l’utiliser. Vous pouvez même demander explicitement « Analyse d’abord la capture, puis corrèle avec la conversation… ». Structurer la requête en deux étapes dans le même message utilisateur peut aider : d’abord « Voici ce que montre l’image… » (le modèle inférera), ensuite « Compte tenu de la conversation… ». Le modèle intégrera ces éléments dans sa réponse globale.

  • Paramètres de génération pour analyses factuelles : Pour une analyse de support, on veut en général une réponse fiable et focalisée sur les données fournies. Il est donc recommandé de baisser un peu la température (par ex. autour de 0.2–0.5) afin de réduire les divagations créatives (Ollama Cheatsheet - How to Run LLMs Locally with Ollama). Une température basse combinée à un top_p élevé (~1.0) donne des réponses plus déterministes et précises, ce qui est adapté à l’explication technique (Ollama Cheatsheet - How to Run LLMs Locally with Ollama). En outre, conserver un repeat_penalty standard ou légèrement supérieur (≥1.1) peut éviter que le modèle ne répète textuellement de longues portions du ticket dans sa réponse. Le but est qu’il reformule et analyse, plutôt que de citer brute­ment.

  • Fenêtre de contexte étendue : Si le ticket est long ou comporte de nombreux détails techniques, augmenter num_ctx comme évoqué plus haut permet de tout inclure sans perte. Llama 3.2-Vision 90B pouvant théoriquement monter à 128k tokens de contexte (Chat with Your Images Using Llama 3.2-Vision Multimodal LLMs | by Lihi Gur Arie, PhD | TDS Archive | Medium), n’hésitez pas à élargir la fenêtre (selon vos ressources) pour ne pas tronquer d’informations essentielles. Cela améliore la compréhension globale du cas par le modèle, évitant qu’il ignore des éléments de début de conversation par manque de contexte.

  • Sortie structurée et ciblée : L’utilisation du paramètre format avec un schéma JSON (ou simplement format: "json") est très pertinente pour des analyses de tickets. En imposant une structure de réponse (par ex. champs Résumé du problème, Cause probable, Solution proposée), on force le modèle à couvrir tous les points de manière organisée (ollama/docs/api.md at main · ollama/ollama · GitHub). Cela réduit les digressions et garantit que les éléments importants du support client sont adressés. Il faut accompagner ce paramètre d’une consigne claire dans le prompt (“Réponds uniquement au format JSON suivant…”) pour guider le modèle (ollama/docs/api.md at main · ollama/ollama · GitHub).

  • Prompt d’exemple (few-shot) : Même sans fine-tuning, on peut insérer un ou deux exemples d’analyse réussie pour guider le modèle. Par exemple, en amont du vrai ticket, ajouter dans le message système ou via le Modelfile MESSAGE une mini-conversation factice : un court échange client-support et une analyse assistant. Cela sert de démonstration. Le modèle, entraîné en mode conversationnel, imitera ce style dans sa réponse réelle. Veillez à ce que l’exemple soit concis pour ne pas monopoliser le contexte. Cette technique de prompt engineering peut sensiblement améliorer la qualité des réponses sur des cas clients spécifiques en montrant au modèle le format d’analyse attendu (ollama/docs/modelfile.md at main · ollama/ollama · GitHub).

  • Gestion des images complexes : Si l’image est particulièrement complexe (ex: une photo de matériel, un graphique, du texte manuscrit), le modèle fera de son mieux pour l’interpréter. Pour l’aider, fournissez du contexte si possible. Par exemple “(L’image est une capture d’erreur système)” ou “(Photo du câblage de l’appareil)” en annotation dans le prompt utilisateur. Cela cadre son attention. Vous pouvez aussi, pour les tableaux ou graphiques, demander au modèle de les décrire d’abord. Diviser l’analyse en sous-tâches (décrire l’image puis conclure) est une approche qui améliore la précision. Certes, cela se fait au niveau du prompt plutôt que via un paramètre, mais c’est crucial pour la compréhension conjointe.

En somme, combinez des paramètres bien ajustés (température, top_p, contexte, format…) avec un prompt structuré et éventuellement un message système adapté. Cela exploitera au mieux la synergie texte + image du modèle pour vos cas de support. Llama 3.2-Vision est conçu pour ce genre de raisonnement multimodal et, correctement guidé, il peut extraire le contexte d’une image et le mettre en regard de la discussion technique pour fournir une analyse pertinente.

5. Recommandations d’affinage des paramètres (sans fine-tuning)

Pour améliorer la qualité de l’analyse sans entraîner à nouveau le modèle, on peut jouer sur les hyperparamètres et la manière de présenter les requêtes :

  • Température et filtrage : Comme mentionné, abaisser la température vers 0 permet d’obtenir des réponses plus directes et factuelles. Pour un ticket technique, une valeur autour de 0.2–0.3 est souvent efficace. Par exemple, Ollama recommande pour les explications techniques temperature=0.1 et top_p=1.0 afin d’avoir un style “codex” (très déterministe) (Ollama Cheatsheet - How to Run LLMs Locally with Ollama). À l’inverse, évitez une température trop haute (>0.8) qui rendrait l’analyse plus hasardeuse ou imaginative – ce n’est pas souhaitable dans un contexte support. Le paramètre top_p peut rester à 0.9–1.0 pour conserver l’exhaustivité des infos pertinentes, et top_k peut éventuellement être réduit (p. ex. 20 au lieu de 40) si vous observez des dérapages, afin de restreindre le choix aux tokens les plus probables.

  • Pénalités de répétition : Si dans vos tests le modèle a tendance à répéter le contenu du ticket mot pour mot, envisagez d’augmenter légèrement repeat_penalty (ex. 1.2 au lieu de 1.1) (ollama/docs/modelfile.md at main · ollama/ollama · GitHub). Cela encouragera des reformulations. Ne montez pas trop haut (>1.5) au risque de dégrader la cohérence. Vous pouvez aussi ajuster repeat_last_n (par défaut 64 tokens) pour étendre ou réduire la fenêtre de texte soumise à pénalisation de répétition (ollama/docs/modelfile.md at main · ollama/ollama · GitHub). Par exemple, mettre repeat_last_n -1 (équivaut à toute la fenêtre contexte) signifie que le modèle évitera de répéter n’importe quel segment présent dans l’historique complet, ce qui peut aider à éviter la paraphrase inutile du ticket. Ces ajustements se font soit dans un Modelfile, soit via options dans la requête.

  • Messages systèmes et exemples : Exploitez à fond le message système pour cadrer l’assistant. Rappelez-lui d’utiliser uniquement les informations fournies et de ne rien inventer. Par exemple : “N’invente pas de faits non présents dans le ticket. Si une information manque, dis-le.”. Cela agit comme une garde-fou contre les hallucinations. De même, utilisez la directive MESSAGE (few-shot) dans un Modelfile pour incorporer un exemple d’analyse idéale (ollama/docs/modelfile.md at main · ollama/ollama · GitHub). Sans entraîner le modèle, on le biaise positivement vers le comportement souhaité en exploitation. C’est souvent suffisant pour améliorer significativement les résultats sur des cas clients similaires.

  • Formatage de la réponse : Nous l’avons souligné, demander une sortie structurée (par ex. via format: "json") est une forme d’affinage “soft”. En imposant une structure, on réduit la variance des réponses et on facilite la comparaison entre résultats. Vous pouvez itérativement peaufiner le schéma ou le style de sortie en fonction de ce qui est le plus utile (par ex., ajouter un champ Niveau de certitude où l’AI indique sa confiance). Ces éléments dans le format de réponse peuvent être intégrés sans aucune reconfiguration du modèle, juste en modifiant le prompt et le paramètre de format.

  • Pas de fine-tuning nécessaire a priori : Llama 3.2-Vision 90B est déjà très performant en compréhension d’images et de langage (llama3.2-vision:90b). Avant d’envisager un fine-tuning coûteux sur vos données de support, exploitez au maximum les leviers ci-dessus. Souvent, le prompt engineering et le réglage des paramètres suffisent pour obtenir une analyse satisfaisante. Si toutefois vous avez des cas très spécifiques où le modèle peine, vous pourriez créer un Modelfile adapter avec quelques LoRA d’exemple (si vous avez des tickets résolus, fine-tuner sur ces cas). Mais même sans aller jusque-là, en jouant sur le contexte (par ex. en fournissant un résumé des docs techniques pertinentes du produit dans le message système), vous pouvez combler certaines lacunes.

En résumé, commencez par affiner les hyperparamètres et le prompt : faible température, pénalités ajustées, format de sortie, contexte supplémentaire via system message. Ces réglages, combinés à la puissance multimodale du modèle 90B, amélioreront notablement la qualité de l’analyse des tickets de support – et ce sans aucune modification lourde du modèle lui-même. Chaque cas d’usage peut nécessiter quelques itérations pour trouver le bon équilibre de paramètres, mais Ollama offre la flexibilité pour le faire facilement (via l’API ou un Modelfile custom), tirant le meilleur de Llama 3.2-Vision dans vos scénarios d’entreprise. (Ollama Cheatsheet - How to Run LLMs Locally with Ollama) (llama3.2-vision:90b)