L'or ne se trouve pas en surface — il est caché dans des tonnes de stérile. Pour extraire un gramme de métal précieux, les chercheurs d'or tamisent des mètres cubes de terre. C'est à peu près ainsi que s'entraînent les grands modèles de langage modernes : des milliers de réponses candidates passent par un modèle d'évaluation coûteux (l'oracle — un modèle qui donne des évaluations précises), afin d'en sélectionner une — la meilleure. Le processus évoque un tapis roulant où chaque coup de pelle coûte des ressources de calcul.

Lors du fine-tuning du modèle Llama 3, pour chaque exemple, jusqu'à 32 réponses sont générées et une seule — celle avec la note la plus élevée — passe au tour suivant. Le cycle se répète six fois, et l'oracle est appelé des dizaines de millions de fois. Cette approche est héritée de l'apprentissage par renforcement basé sur le retour humain — RLHF. Mais si l'on considère le processus comme une requête SQL « sélectionner le meilleur, trié par note », il devient évident qu'il n'est pas nécessaire de faire appel à l'évaluateur coûteux pour chaque candidat. C'est là que les techniques classiques des bases de données viennent à la rescousse.

La première méthode est l'agrégation approximative (Approximate Query Processing). Comme lors de la prospection d'un gisement, on prélève des échantillons de terre, on estime la teneur moyenne en or et on s'arrête lorsque l'intervalle de confiance (la plage dans laquelle se trouve la valeur réelle avec une probabilité donnée) se rétrécit jusqu'au seuil souhaité. En apprentissage automatique, cela correspond à un échantillonnage progressif : l'oracle est appelé pour de nouvelles réponses aléatoires jusqu'à ce que l'estimation de l'agrégat — somme, moyenne ou maximum — se stabilise. Pour des requêtes comme « top-1 », le critère devient la stabilité du meilleur résultat. La deuxième méthode est le modèle de substitution (Proxy Model). Sur un petit ensemble de réponses déjà étiquetées par l'oracle, on entraîne un arbre de décision léger. Il examine des caractéristiques simples — longueur du texte, présence de formules, caractères spéciaux — et élimine instantanément les variantes manifestement faibles. Contrairement aux proxies à base de réseaux de neurones, qui nécessitent des accélérateurs graphiques, l'arbre fonctionne sur un processeur ordinaire et ne consacre que quelques millisecondes à chaque candidat. C'est un filtrage en cascade : l'oracle coûteux ne s'intéresse qu'aux cas « litigieux ».

Lors des tests avec des requêtes analytiques, la méthode d'agrégation approximative a donné une erreur inférieure à 10%, en n'utilisant que 10 à 15% des appels à l'oracle. Sur les pipelines de fine-tuning des modèles LLaMA et Qwen pour le raisonnement mathématique et la génération de code, elle se contentait de 20 à 50% des appels, avec une perte de précision ne dépassant pas 5%. Quant aux arbres de substitution, ils réduisaient le temps de scoring jusqu'à 19 fois — par exemple, de 1079 secondes à 56 pour un LLaMA de huit milliards de paramètres. Le processus d'évaluation stochastique converge d'autant plus vite que la distribution des données est uniforme. Sur des instructions simples, l'accélération est plus modeste, mais reste significative.

Ces résultats brisent le mythe selon lequel l'accélération de l'intelligence artificielle nécessite nécessairement de nouvelles architectures. Parfois, il suffit de repenser le flux de données : cesser de creuser chaque pelletée de terre, mais la tamiser intelligemment. Les optimisations classiques de requêtes connaissent une seconde vie à l'ère des grands modèles de langage. Et ce n'est que le début : de telles approches s'étendront au raisonnement multi-étapes et à la recherche documentaire. Le système, tel un géologue expérimenté, écartera les zones peu prometteuses dès les premiers indices. Ainsi, la batée se transforme en séparateur automatique — et l'or commence à briller plus vite.