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](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=1,pattern%20is%20encountered%20the%20LLM)), le _top_p_ (filtrage nucléaire, défaut ~0.9) ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=top_p%20Works%20together%20with%20top,05)), le _top_k_ (taille du vocabulaire échantillonné, défaut 40) ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=top_k%20Reduces%20the%20probability%20of,9)), 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](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=repeat_last_n%20Sets%20how%20far%20back,Setting%20this%20to%20a)), la _longueur du contexte_ (_num_ctx_, fenêtre de tokens, défaut 2048) ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=num_ctx%20Sets%20the%20size%20of,1)), 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](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=stop%20Sets%20the%20stop%20sequences,100)), 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](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=disabled%2C%201%20%3D%20Mirostat%2C%202,to%20generate%20the%20next%20token)) et _min_p_ (seuil probabiliste minimal alternatif à top_p) ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=top_p%20Works%20together%20with%20top,05)). Vous pouvez aussi fixer un _seed_ aléatoire pour reproductibilité ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=temperature%20The%20temperature%20of%20the,AI)). 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](https://apidog.com/blog/ollama-cheatsheet#:~:text=adjustments)).

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](https://ollama.com/library/llama3.2-vision:90b#:~:text=model%3D%27llama3.2,)) ([ollama/docs/api.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=,llava)). Par exemple en Python : `messages=[{'role': 'user','content': 'Question sur l’image','images': ['image.png']}]` ([llama3.2-vision:90b](https://ollama.com/library/llama3.2-vision:90b#:~:text=model%3D%27llama3.2,)). 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](https://ollama.com/blog/llama3.2-vision#:~:text=ollama%20run%20llama3.2)) ([Llama 3.2 Vision · Ollama Blog](https://ollama.com/blog/llama3.2-vision#:~:text=To%20add%20an%20image%20to,to%20the%20prompt%20on%20Linux)). _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](https://medium.com/data-science/chat-with-your-images-using-multimodal-llms-60af003e8bfa#:~:text=Llama%2C%20short%20for%20%E2%80%9CLarge%20Language,complex%20visual%20and%20textual%20information)) 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 :

- `format` : pour demander une sortie structurée JSON ou imposer un schéma JSON ([ollama/docs/api.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=,than%20a%20stream%20of%20objects)). Par exemple, `format: "json"` force la réponse à être un objet JSON valide (en veillant à le préciser dans l’instruction du prompt) ([ollama/docs/api.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=Structured%20outputs%20are%20supported%20by,the%20structured%20outputs%20example%20below)).
    
- `system` : pour fournir un message système (contexte/personalité) qui _surpasse_ celui du Modelfile ([ollama/docs/api.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=,than%20a%20stream%20of%20objects)).
    
- `template` : pour spécifier un gabarit de prompt custom au lieu de celui par défaut du modèle ([ollama/docs/api.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=,than%20a%20stream%20of%20objects)).
    
- `stream` : pour choisir entre une réponse _streaming_ (flux de tokens) ou complète en une fois (`false` renvoie la réponse entière dans un seul objet JSON) ([ollama/docs/api.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=,than%20a%20stream%20of%20objects)).
    
- `raw` : pour envoyer le prompt tel quel sans formatage automatique (utile si l’on a déjà formé manuellement le prompt complet, y compris les balises) ([ollama/docs/api.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=,a%20full%20templated%20prompt%20in)).
    
- `keep_alive` : durée pendant laquelle garder le modèle en mémoire après la requête (ex. `"5m"` par défaut) ([ollama/docs/api.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=,will%20stay%20loaded%20into%20memory)).
    

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](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=,than%20a%20stream%20of%20objects)), et en **CLI** on dispose de flags correspondants (`--temperature`, `--top-p`, etc.) ([Ollama Cheatsheet - How to Run LLMs Locally with Ollama](https://apidog.com/blog/ollama-cheatsheet#:~:text=adjustments)). 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](https://apidog.com/blog/ollama-cheatsheet#:~:text=ollama%20run%20deepseek,p%200.9)). 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](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=Advanced%20parameters%20)).

## 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 :

- **FROM** : le modèle de base à utiliser (ex. `FROM llama3.2-vision:90b`) et éventuellement son format (Safetensors, GGUF…) ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=,SYSTEM)). C’est le point de départ (poids initiaux).
    
- **PARAMETER** : des paramètres par défaut pour l’exécution du modèle ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=,ADAPTER)). On peut y fixer toutes les valeurs listées plus haut (température, top_p, etc.) afin qu’elles s’appliquent à chaque requête sur ce modèle. Par exemple : `PARAMETER temperature 0.5` pour rendre le modèle plus cohérent (créativité réduite) ou `PARAMETER num_ctx 4096` pour étendre la fenêtre de contexte à 4096 tokens ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=FROM%20llama3.2%20,next%20token%20PARAMETER%20num_ctx%204096)). Ces paramètres dans le Modelfile sont équivalents à ceux passés via l’API (ils peuvent être surchargés à la requête au besoin).
    
- **TEMPLATE** : un gabarit de prompt sur mesure ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=,Notes)). C’est ici qu’on définit comment le système formate les messages (par exemple en ajoutant des balises spéciales autour des rôles, etc.). Le template utilise des variables comme `{{ .System }}` (insère le message système), `{{ .Prompt }}` (message utilisateur) et `{{ .Response }}` (réponse du modèle) ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=)). En personnalisant le template, on peut ajuster la manière dont le dialogue est présenté au modèle – par exemple, certains modèles attendent un format de prompt particulier, qu’on peut implémenter ici.
    
- **SYSTEM** : un message système par défaut, qui définit le comportement ou la personnalité de l’assistant ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=SYSTEM)). Par exemple, `SYSTEM Vous êtes un expert support technique…` orientera toutes les réponses du modèle dans ce rôle sans avoir à le répéter à chaque requête. (Ce message système sera injecté via le template, typiquement en en-tête de la conversation.)
    
- **ADAPTER** : un adaptateur LoRA ou Q-LoRA à appliquer au modèle de base ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=ADAPTER)). Cela permet de _charger un fine-tune léger_ sans modifier le modèle de base. On indique le chemin vers le fichier de l’adaptateur (au format Safetensors ou GGUF) ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=adapter%20was%20tuned%20from%20the,behaviour%20will%20be%20erratic)). Par exemple, on pourrait plugger un LoRA spécialisé en support client si disponible, pour ajuster les réponses, le tout via `ADAPTER chemin/vers/adapter.safetensors`.
    
- **LICENSE** : le texte de licence du modèle dérivé (option purement documentaire/juridique) ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=LICENSE)).
    
- **MESSAGE** : un historique de messages exemple à précharger dans le modèle ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=MESSAGE)). Cela sert à **ajuster le comportement par quelques exemples** (technique du _few-shot_). On peut ajouter plusieurs lignes `MESSAGE role contenu` pour construire une mini-conversation type. Les rôles valides sont `system` (équivalent d’un message système initial), `user` (exemple de question utilisateur) et `assistant` (exemple de réponse du modèle) ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=Role%20Description%20system%20Alternate%20way,how%20the%20model%20should%20respond)). En couplant ces messages, on illustre au modèle la façon dont il doit répondre. Par exemple, on peut inclure une série de Q/R de support client résolues pour guider le modèle sur le ton et le format attendus. Ces messages d’exemple seront toujours insérés avant la requête réelle de l’utilisateur, orientant ainsi le modèle ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=The%20,answer%20in%20a%20similar%20way)) ([ollama/docs/modelfile.md at main · ollama/ollama · GitHub](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=)).
    

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](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=1,Start%20using%20the%20model)). 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](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=,than%20a%20stream%20of%20objects)).

## 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](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=The%20,following%20fields)). Par exemple, si l’utilisateur fournit deux captures (“screen1.png” et “error.bmp”), on aura :
    
    ```json
    {
      "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?](https://huggingface.co/meta-llama/Llama-3.2-11B-Vision-Instruct/discussions/43#:~:text=Meta%20Llama%20org%20Sep%2029%2C,2024)). 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](https://ollama.com/library/llama3.2-vision:90b#:~:text=collection%20of%20instruction,models%20on%20common%20industry%20benchmarks)), 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](https://medium.com/data-science/chat-with-your-images-using-multimodal-llms-60af003e8bfa#:~:text=Llama%2C%20short%20for%20%E2%80%9CLarge%20Language,complex%20visual%20and%20textual%20information)), 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](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=num_ctx%20Sets%20the%20size%20of,7)). 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](https://ollama.com/blog/llama3.2-vision#:~:text=to%20the%20image%20to%20the,prompt%20on%20Linux)), 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](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=,than%20a%20stream%20of%20objects)) – 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](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=Structured%20outputs%20are%20supported%20by,the%20structured%20outputs%20example%20below)).
    
- **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](https://ollama.com/library/llama3.2-vision:90b#:~:text=Supported%20Languages%3A%20For%20text%20only,is%20the%20only%20language%20supported)). 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](https://ollama.com/library/llama3.2-vision:90b#:~:text=Supported%20Languages%3A%20For%20text%20only,is%20the%20only%20language%20supported))), 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](https://ollama.com/library/llama3.2-vision:90b#:~:text=collection%20of%20instruction,models%20on%20common%20industry%20benchmarks)). 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](https://apidog.com/blog/ollama-cheatsheet#:~:text=ollama%20run%20deepseek,p%200.9)). 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](https://apidog.com/blog/ollama-cheatsheet#:~:text=ollama%20run%20deepseek,p%200.9)). 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](https://medium.com/data-science/chat-with-your-images-using-multimodal-llms-60af003e8bfa#:~:text=Llama%2C%20short%20for%20%E2%80%9CLarge%20Language,complex%20visual%20and%20textual%20information)), 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](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=parameter,the%20structured%20outputs%20example%20below)). 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](https://github.com/ollama/ollama/blob/main/docs/api.md#:~:text=Enable%20JSON%20mode%20by%20setting,the%20JSON%20mode%20example%20below)).
    
- **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](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=)).
    
- **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](https://apidog.com/blog/ollama-cheatsheet#:~:text=ollama%20run%20deepseek,p%200.9)). À 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](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=repeat_last_n%20Sets%20how%20far%20back,Setting%20this%20to%20a)). 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](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=num_ctx%20Sets%20the%20size%20of,7)). 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](https://github.com/ollama/ollama/blob/main/docs/modelfile.md#:~:text=)). 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](https://ollama.com/library/llama3.2-vision:90b#:~:text=models%20are%20optimized%20for%20visual,models%20on%20common%20industry%20benchmarks)). 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](https://apidog.com/blog/ollama-cheatsheet#:~:text=ollama%20run%20deepseek,p%200.9)) ([llama3.2-vision:90b](https://ollama.com/library/llama3.2-vision:90b#:~:text=collection%20of%20instruction,models%20on%20common%20industry%20benchmarks))