Réglages d'échantillonnage

L'échantillonnage est le dernier centimètre de l'inférence : le modèle score chaque jeton du vocabulaire, et vos réglages décident comment cette distribution devient un jeton. Les réglages interagissent, donc l'ordre des opérations compte plus que toute valeur isolée.

Le pipeline, dans l'ordre

La plupart des moteurs appliquent les échantillonneurs à peu près dans cet ordre :

• Logits — scores bruts, un par jeton du vocabulaire (50k–150k entrées).
• Pénalités de répétition — les jetons vus récemment voient leurs logits poussés vers le bas.
• Température — logits divisés par T, aiguisant ou aplatissant tout.
• top_k — plafond dur : seuls les k meilleurs jetons survivent.
• top_p — noyau : le plus petit ensemble de tête couvrant p de la masse de probabilité.
• min_p — plancher relatif : élimine les jetons sous min_p × P(jeton de tête).
• Échantillonner — choisir un jeton parmi le reste, l'ajouter, répéter.

Un filtre appliqué tôt change ce que chaque filtre suivant voit. Gardez cela en tête en empilant.

Température

La température T divise les logits avant le softmax. Un T plus bas aiguise la distribution vers le jeton de tête ; un T plus haut l'aplatit vers l'uniforme. Concret : logits [5.0, 3.0, 1.0] sur trois jetons.

À T → 0, cela s'effondre en glouton : toujours argmax, entièrement déterministe.

Utilisez la température 0 (ou 0.000001 quand un moteur interdit 0) pour l'extraction, la classification et tout ce que vous voulez reproductible d'un run à l'autre. Le chat veut 0.6–0.8 ; l'écriture créative tolère 0.9–1.2.

top_k : un plafond dur

Gardez seulement les k jetons de plus haute probabilité et échantillonnez parmi eux. top_k 40 rend le jeton 41 et au-delà impossibles, quoi qu'il arrive.

C'est un instrument grossier. k=40 est spacieux après « La capitale de la France est » et absurdement gaspilleur sur les positions à jetons rares où deux candidats comptent. Défaut courant : 40. Désactivez-le (0 ou -1, selon le moteur) quand vous utilisez min_p.

top_p : le noyau

Triez par probabilité, gardez le plus petit ensemble dont la probabilité cumulée atteint p, renormalisez, échantillonnez.

Détaillé : probabilités [0.867, 0.117, 0.016] avec top_p 0.9. Le jeton de tête seul couvre 0.867 < 0.9 ; ajouter le second atteint 0.984 ≥ 0.9. Vous échantillonnez sur deux jetons, renormalisés en [0.88, 0.12].

L'ensemble de candidats rétrécit automatiquement quand le modèle est confiant et grossit quand il hésite. Fourchette typique : 0.9–0.95.

min_p : le favori local

Gardez seulement les jetons dont la probabilité atteint au moins min_p × P(jeton de tête). Le plancher est relatif à l'échelle :

• Modèle confiant à 99% → plancher = 0.05 × 0.99 ≈ 0.05 : seuls les vrais prétendants survivent.
• Jeton de tête à 30% → plancher = 0.05 × 0.30 = 0.015 : la diversité survit.

Cela tue les échecs classiques de top_k/top_p — sur-élaguer une distribution confiante, sous-élaguer une plate — et min_p se compose sûrement avec une haute température. La recette « créatif mais cohérent » : temp 1.0–1.5, min_p 0.05–0.1. Réglage local courant : min_p 0.05 avec top_k et top_p désactivés.

repeat_penalty (famille llama.cpp)

Avant l'application de la température, les logits des jetons apparus dans le contexte récent sont divisés par la pénalité. Des valeurs sous 1.0 boostent au contraire la répétition. Fourchette sensée : 1.0–1.1.

Les effets secondaires sont réels, parce que le code et les données répètent des jetons exprès :

• Les identifiants se répètent légitimement : count dans counter.count.
• Les clés JSON et accolades fermantes se répètent dans chaque objet d'un tableau.
• Une pénalité 1.2+ casse le code et le JSON (accolades perdues, guillemets « corrigés ») bien avant de corriger les boucles de prose.

Les modèles instruct modernes dépassent rarement le besoin de 1.05. Pour le code et la sortie structurée, 1.0 est un choix légitime.

Pénalités de fréquence et de présence (style API)

Les APIs compatibles OpenAI exposent frequency_penalty (croît à chaque répétition) et presence_penalty (pénalité plate pour tout jeton déjà vu) là où llama.cpp utilise repeat_penalty. Même intention, maths différentes. Tous les moteurs locaux ne respectent pas les deux — vérifiez ce que le vôtre implémente avant de les empiler : paramètres moteur.

Empiler les échantillonneurs dans un coin

temp 0.1 + top_k 10 + top_p 0.5 + min_p 0.2 + repeat_penalty 1.3, appliqués ensemble, peuvent masquer chaque jeton candidat. Symptômes : avertissements de logprob NaN, générations vides, abandons « sampling returned zero candidates ».

Ce n'est pas un modèle cassé — c'est un ensemble de candidats vide. Desserrez la pile, un réglage à la fois. Triage complet : dépannage.

Préréglages qui marchent

La ligne chat en options llama.cpp :

llama-server -m model.gguf --temp 0.7 --top-p 0.95 --min-p 0.05 --repeat-penalty 1.05

Changez une chose à la fois

Traitez les préréglages comme des points de départ, pas des lois. Si vous bougez température et top_p ensemble et que la sortie s'améliore, vous n'avez rien appris sur le réglage qui comptait.

1. Fixez un jeu de test : 5–10 prompts qui exercent ce qui vous importe.
2. Sauvegardez les sorties par configuration ; comparez-les côte à côte.
3. Changez exactement un réglage par run.
4. Sauvegardez le gagnant comme préréglage nommé — chaque moteur et interface les stocke.

Pour la correspondance de ces réglages avec les options moteur et champs d'API : paramètres moteur.

Voir aussi : paramètres moteur · prompting · sortie structurée · dépannage