Aller au contenu principal

Module 5 — Fichiers Modelfile et modèles dérivés

Le module précédent nous a montré comment appeler Ollama depuis Python et fixer la consigne système à chaque appel. Cela fonctionne, mais chaque application, chaque script, chaque intégration doit alors re-transporter la même longue consigne — et deux consignes qui devraient être identiques finissent inévitablement par diverger. Le Modelfile résout ce problème en cristallisant, dans une nouvelle étiquette de modèle, la consigne système, les paramètres et le gabarit d'un modèle prêt à l'emploi pour un usage précis.

Le Modelfile, en une image

Un Modelfile est à un modèle Ollama ce qu'un Dockerfile est à une image Docker : un fichier texte qui décrit comment produire une nouvelle étiquette à partir d'une étiquette existante, en ajoutant des couches de configuration. Il n'y a pas de « compilation » lourde : la commande ollama create combine simplement les couches et enregistre un manifeste. Une fois créée, l'étiquette dérivée s'utilise exactement comme n'importe quelle autre : ollama run cabinet-fr ou, dans le code Python du module 4, model="cabinet-fr".

Les instructions à connaître

Six instructions couvrent 99 % des Modelfiles écrits en pratique.

FROM désigne le modèle de base, obligatoirement présent en cache local (ou téléchargeable). C'est la seule instruction strictement obligatoire.

SYSTEM fige la consigne système. Elle sera automatiquement injectée en tête de toute conversation, sans qu'aucun appelant n'ait à la fournir. C'est là que passera l'identité, le ton, les garde-fous et les rappels métier du cabinet.

PARAMETER fige un paramètre de génération : PARAMETER temperature 0.2, PARAMETER num_ctx 4096, PARAMETER stop "\nUtilisateur :". Ces valeurs deviennent les défauts du modèle dérivé, et restent surchargeables au moment de l'appel.

TEMPLATE définit la mise en forme des messages envoyée au moteur d'inférence (les jetons spéciaux qui séparent le rôle système, l'utilisateur et l'assistant). En pratique, on hérite de celui du modèle de base sans y toucher — ollama show --modelfile llama3.1:8b le fait apparaître, et le réécrire à la main est un exercice à haut risque.

ADAPTER greffe un adaptateur LoRA (issu du cours 19 sur l'affinage) sur le modèle de base sans dupliquer ses poids. Le fichier .gguf de l'adaptateur, souvent quelques dizaines de Mo, se chargera dynamiquement au démarrage du modèle.

LICENSE permet d'attacher un texte de licence à l'étiquette dérivée. Le cabinet y met une mention interne rappelant que le modèle ne doit pas être distribué à l'extérieur.

Créer le modèle du cabinet

Le fichier Modelfile.cabinet que nous écrivons pour le cabinet ressemble à ceci :

FROM llama3.1:8b-instruct-q4_K_M

SYSTEM """
Tu es l'assistant interne d'un cabinet juridique francais.

Regles imperatives :
- Tu reponds en francais soutenu, precis et concis.
- Tu ne rends jamais de conseil juridique final : tu resumes le droit
applicable et tu recommandes systematiquement de valider avec un
avocat du cabinet avant toute action envers un tiers.
- Tu cites les articles de loi ou de code que tu evoques (article,
code) sans jamais inventer une reference.
- Tu ne divulgues aucun contenu qui ne t'a pas ete fourni dans la
question ou dans le contexte de conversation courant.
- Si la question sort du droit francais, tu le signales.
"""

PARAMETER temperature 0.2
PARAMETER num_ctx 4096
PARAMETER num_predict 800
PARAMETER stop "\nUtilisateur :"
PARAMETER stop "\n\n\n"

LICENSE """
Modele interne du Cabinet Exemple, base sur llama3.1:8b.
Distribution externe interdite.
"""

Puis, en une seule commande :

ollama create cabinet-fr -f Modelfile.cabinet

Ollama parcourt les couches, monte le nouveau manifeste, et l'étiquette cabinet-fr apparaît immédiatement dans ollama list. Testons :

ollama run cabinet-fr "Delai legal pour contester une facture de loyer ?"

La réponse commence par la formule attendue, cite l'article pertinent, et se termine par le rappel de validation par un avocat. Zéro instruction dans l'appel : tout vient du SYSTEM figé dans le Modelfile.

Importer un GGUF affiné

Le cours 19 sur l'affinage produit un fichier GGUF quantifié — mettons cabinet-jurisprudence-v1.gguf, 4,6 Go, qu'une équipe interne a affiné sur 3 000 questions-réponses de la jurisprudence de la maison. Pour le rendre utilisable dans Ollama sans passer par la bibliothèque publique :

FROM ./cabinet-jurisprudence-v1.gguf

SYSTEM "Tu es l'assistant du cabinet, specialise sur la jurisprudence interne."

PARAMETER temperature 0.15
PARAMETER num_ctx 8192
ollama create cabinet-jurisprudence -f Modelfile.jurisprudence

Ollama copie le GGUF dans son cache et enregistre l'étiquette locale. C'est la voie la plus propre pour intégrer un affinage sans dépendre d'un dépôt externe — les modèles restent physiquement sur le serveur du cabinet.

Partager entre postes

Deux options pratiques. La première consiste à copier le Modelfile et laisser ollama create refaire l'assemblage sur chaque poste — c'est immédiat si le modèle de base est déjà pull-é sur les postes cible. La seconde utilise ollama push vers un dépôt Ollama interne (un simple registre compatible Docker), qui permet ensuite un ollama pull classique. Pour le cabinet, la première voie suffit largement à trois postes ; la seconde deviendrait utile au-delà de dix.

Un Modelfile n'apprend rien au modèle

Le Modelfile ne modifie pas les poids du modèle de base : il change sa consigne système et ses paramètres par défaut. Si le cabinet a besoin que le modèle « connaisse » sa jurisprudence, la voie est l'affinage (cours 19) suivi d'un import du GGUF, ou le système de questions-réponses par récupération de documents (module 9). Une consigne système, aussi longue soit-elle, ne remplace ni l'un ni l'autre.

En résumé

  • Un Modelfile combine FROM, SYSTEM, PARAMETER et éventuellement ADAPTER pour figer une variante prête à l'emploi ; ollama create produit une nouvelle étiquette locale.
  • Le modèle dérivé s'utilise comme n'importe quel autre : plus besoin de re-transporter la consigne système à chaque appel Python, ce qui élimine la dérive entre applications.
  • FROM ./fichier.gguf importe un modèle affiné (cours 19) sans passer par la bibliothèque publique — utile quand les poids doivent rester internes.
  • Un Modelfile ne modifie pas les poids : pour apprendre au modèle un contenu métier, il faut l'affinage ou la récupération de documents.

Module suivant : ce que signifie exactement la quantification, et combien de RAM chaque étiquette réclame réellement.