Aller au contenu principal

Module 3 — Session interactive et paramètres de génération

Les modules précédents nous ont donné un service qui tourne et des modèles téléchargés. Nous entrons enfin dans la partie où l'on parle au modèle. La commande ollama run ouvre une session interactive dans le terminal ; c'est le laboratoire dans lequel les collaborateurs du cabinet, avant même d'écrire une ligne de Python, éprouvent la qualité d'un modèle et calibrent ses paramètres pour leur usage réel.

Ouvrir et quitter une session​

ollama run llama3.1:8b-instruct-q4_K_M

Au premier lancement, le modèle est chargé en mémoire (quelques secondes), puis apparaît une invite >>>. Toute ligne saisie est envoyée au modèle, la réponse arrive en flux. On quitte la session par /bye (ou Ctrl+D), ce qui ne décharge pas le modèle immédiatement : il reste en mémoire pendant OLLAMA_KEEP_ALIVE (5 minutes par défaut). C'est très pratique, parce que la session suivante démarre sans temps de chargement — au prix de quelques gigaoctets de RAM immobilisés.

Les commandes de session​

Dans une session run, les lignes commençant par / ne sont pas envoyées au modèle mais interprétées localement. Les cinq utiles au quotidien :

  • /set parameter temperature 0.2 — modifie un paramètre à la volée
  • /show info — affiche modèle, contexte, paramètres actifs
  • /show system — affiche la consigne système courante
  • /clear — efface l'historique de la conversation en cours
  • /save nom puis /load nom — sauvegarde et recharge un état de session, y compris ses paramètres et sa consigne

Ces commandes servent d'atelier de mise au point : la personne au secrétariat teste plusieurs formulations et plusieurs températures sur une même question client, puis, quand elle a trouvé un réglage satisfaisant, /save cabinet-fr-formel conserve ce point de départ.

Les cinq paramètres qui comptent vraiment​

Ollama expose des dizaines de paramètres. En pratique, cinq d'entre eux couvrent 95 % des besoins.

temperature contrôle l'aléa dans le choix du prochain jeton. À 0, le modèle prend systématiquement le jeton le plus probable — sortie quasi-déterministe, utile pour des extractions structurées ou pour reproduire un résultat. À 0,7 (défaut), le modèle varie ses formulations et devient plus « créatif », au prix d'une variabilité. Pour les réponses du cabinet à ses clients, la valeur 0,2 s'est révélée être le bon compromis : formulations naturelles, mais faits stables entre deux exécutions consécutives d'une même question.

num_ctx est la taille de la fenêtre de contexte exprimée en jetons — combien de texte le modèle voit à la fois, entrée et sortie confondues. C'est le paramètre le plus incompris. Le beurre n'est pas gratuit : num_ctx de 8 192 double la mémoire nécessaire au cache d'attention par rapport à 4 096. Sur un poste à 16 Go, augmenter num_ctx à 16 384 fait souvent basculer le modèle en CPU seul (module 7), et une réponse qui prenait 3 secondes en prend 30. La règle est simple : la plus petite valeur qui contient la question, la consigne et la réponse attendue.

num_predict borne le nombre de jetons générés dans la réponse. Le défaut de -1 laisse le modèle décider. Pour des réponses brèves de type extraction, fixer num_predict à 128 empêche des dérives à 2 000 jetons qui bloquent la machine pour rien.

seed rend la génération reproductible à paramètres identiques. À 42, deux exécutions identiques renvoient exactement la même sortie — indispensable pour comparer objectivement deux consignes ou deux modèles sur les mêmes questions. Une valeur négative (défaut) tire une graine aléatoire à chaque appel.

stop est une liste de chaînes qui, si elles apparaissent en génération, arrêtent immédiatement le flux. Extrêmement utile : stop=["\nUtilisateur :", "\n\n\n"] évite qu'un modèle mal élevé se mette à jouer les deux rôles d'une conversation.

Un test mesurable sur une question du cabinet​

Avant de laisser un modèle répondre à des clients, on veut savoir de combien chaque paramètre change la sortie. Voici la petite discipline que nous imposons au cabinet :

ollama run llama3.1:8b-instruct-q4_K_M
>>> /set parameter seed 42
>>> /set parameter temperature 0
>>> Un locataire cesse de payer son loyer depuis trois mois.
    Quelles sont les étapes non contentieuses recommandées
    avant toute assignation ? Réponse en cinq points.

On lance la même question trois fois, avec temperature à 0, puis 0,2, puis 0,7 (en gardant seed=42). À 0, les trois sorties sont identiques mot pour mot. À 0,2, l'ordre des points et quelques tournures varient, mais la substance est stable. À 0,7, un point change de contenu entre les exécutions : c'est acceptable pour un brouillon, dangereux pour une réponse partant aux clients sans relecture. Ce genre de mesure, faite en dix minutes, remplace des heures de débat sur les valeurs « conseillées ».

Ce que la session interactive ne remplace pas​

ollama run est un excellent laboratoire, mais il ne convient pas pour intégrer Ollama à une application, ni pour envoyer 500 questions en lot, ni pour brancher un système de récupération de documents. La session est mono-utilisateur, mono-thread, et ne renvoie que du texte brut. Pour tout le reste — et notamment pour l'assistant que le cabinet compte déployer — il faut passer par l'API HTTP locale, ce à quoi le module suivant est entièrement consacré.

Le trio à retenir pour un usage professionnel

Pour les réponses au client : temperature=0.2, num_ctx calé au strict nécessaire, seed fixée pendant la mise au point de la consigne puis libérée en production. Pour une extraction structurée : temperature=0, num_predict court, stop défini pour couper à la fin de la structure attendue. Pour un brainstorming interne : temperature=0.8 sans seed.

En résumé​

  • ollama run ouvre une session interactive dans le terminal ; les commandes /set, /show, /save transforment ce shell en atelier de mise au point.
  • La temperature gouverne l'aléa (0 = déterministe, 0,7 = varié) ; pour le cabinet, 0,2 est le bon compromis stable-naturel.
  • num_ctx a un coût mémoire réel : le régler au strict nécessaire, sinon le modèle bascule en CPU et la latence explose.
  • seed rend une génération reproductible pour comparer deux réglages ; stop arrête proprement une génération qui déborde.

Module suivant : appeler ces mêmes modèles depuis Python via l'API locale et la compatibilité OpenAI.