L'astuce méconnue pour réduire la facture de l'IA : le cascade de modèles

EXTRAIRE DES CHAMPS DE DOCUMENTS : UN CASSE-TÊTE COÛTEUX

Imaginons que vous devez extraire des centaines de champs typés d'une pile de documents : des montants, des dates, des limites de couverture, une valeur structurée par champ. La première idée qui vient à l'esprit ? Envoyer chaque champ vers une API haut de gamme comme GPT-4. Ça marche, mais la facture devient le poste de dépense le plus lourd de votre pipeline. Pourtant, la plupart de ces champs sont de simples recherches que même un tout petit modèle peut gérer parfaitement. Vous payez donc le prix fort pour des tâches qui n'en valent pas la peine.

LE PROBLÈME DU MODÈLE UNIQUE : TOUT OU RIEN

La réaction évidente ? Remplacer le grand modèle par un petit modèle local et économiser des milliers d'euros. Mais attention : un modèle trop faible pour la tâche peut retourner des données erronées, ou rater une transformation. Si personne ne vérifie, c'est une erreur qui part en production. La solution n'est donc ni d'utiliser uniquement le grand modèle, ni d'utiliser uniquement le petit modèle. Il faut choisir le bon modèle selon des critères précis, puis vérifier systématiquement le résultat avant de l'utiliser.

LA CASCADE DE MODÈLES : UNE APPROCHE INTELLIGENTE

Cette méthode s'inscrit dans la philosophie de la série Enterprise Document Intelligence, qui construit des systèmes RAG (Retrieval-Augmented Generation) en quatre étapes : parsing des documents, parsing des questions, récupération des informations, Génération des réponses. L'article développe ici une décision cruciale dans l'étape de génération : quel modèle exécute l'appel, et que faire quand le modèle peu coûteux n'est pas assez bon ?

Cette approche s'appuie sur trois articles précédents :

• Article 6C (dispatch) : lit un niveau de modèle suggéré à partir de la question parsée avant même la génération
• Article 8C (validation) : déclenche une escalade quand la validation échoue
• Article 10 (parsing adaptatif) : applique la même logique de départ peu coûteux et escalade à la demande

Tout ce qui suit est validé par un benchmark réel : une tâche d'extraction de champs sur quelques centaines de champs typés, répartis sur des dizaines de documents. Vingt modèles locaux ont été testés contre un flagship hébergé, tous à température 0 avec sortie en JSON. Les chiffres présentés sont des agrégats. Aucun document, libellé de champ ou chiffre précis de ce benchmark n'apparaît ici.

Un cahier d'exercices exécutable est disponible sur GitHub : doc-intel/notebooks-vol1. Il passe le même champ à travers la cascade, affiche le coût par champ et le verdict de validation à chaque niveau, et montre l'escalade ne se déclenchant que sur les champs que le modèle local peu coûteux a mal gérés.

DEUX RAISONS DE S'INTÉRESSER À LA SÉLECTION DE MODÈLE

Deux angles complémentaires rendent cette approche incontournable.

1. L'ANGLE COÛT : ÉCONOMISER SANS PERDRE EN QUALITÉ

Les modèles flagship coûtent dix fois plus cher par appel qu'un petit modèle local. Sur une tâche d'extraction avec des milliers d'appels par champ, ou un assistant de corpus répondant à des milliers de questions par jour, la facture du modèle domine les coûts d'exécution. La plupart de ces appels n'ont pas besoin d'un flagship. Router les tâches simples vers un modèle moins cher, c'est de l'argent économisé jusqu'à ce que vous le fassiez vraiment.

2. L'ANGLE BOUCLE : CORRECTNESS SOUS CONTRAINTE

Vous ne pouvez pas réduire les coûts en supposant qu'un petit modèle fera l'affaire. Vous commencez avec un modèle, vérifiez si sa réponse tient la route, et n'escaladez vers un modèle plus puissant que si la vérification échoue. C'est cette boucle qui rend l'économie de coûts sûre : le modèle peu coûteux est l'essai par défaut, pas un pari, car un essai raté est détecté et réessayé sur un modèle plus grand plutôt que d'être livré tel quel.

Le coût pousse à descendre l'échelle des modèles. La boucle empêche de tomber trop bas. Cette logique de départ peu coûteux, puis escalade en cas d'échec, porte un nom dans la littérature : une cascade LLM.

LES DEUX FAITS QUI FONDENT LA CASCADE

La conception présentée dans la section 3 repose sur deux observations mesurées. Prenons-les d'abord, car elles expliquent pourquoi la cascade a cette forme.

Regardons ce que vingt modèles locaux ont fait sur la tâche brute en une seule passe : lire le snippet récupéré, retourner la valeur typée. Même prompt, mêmes champs, température 0.

1. PLUS GRAND NE VEUT PAS DIRE MEILLEUR

Un modèle de 4 milliards de paramètres (qwen3:4b) et un de 7 milliards (mistral:7b) arrivent en tête des modèles locaux. Un modèle de 12 milliards et un de 14 milliards (gemma3:12b, phi4:14b) se retrouvent en dessous. Deux modèles de la même famille, l'un deux fois plus grand que l'autre, font jeu égal. Le nombre de paramètres est un mauvais indicateur. Ce qui compte, c'est la famille du modèle et la façon dont il a été entraîné. C'est exactement pour cela que la boucle ne doit pas escalader aveuglément une échelle de taille : la prochaine marche n'est souvent pas la prochaine taille.

2. IL EXISTE UN SEUIL PLANCHER

Les modèles sous 2 milliards de paramètres chutent d'une falaise (qwen2.5:1.5b à 12%, llama3.2:1b à 6%). Un modèle de 0,5 milliard testé a retourné un JSON vide sur la plupart des champs : pas une mauvaise réponse, mais aucune réponse du tout. Commencer par là gaspille une itération de boucle sur une marche qui n'était jamais censée tenir. Les critères doivent permettre de commencer au-dessus du seuil, pas en dessous.

3. COÛT ≠ VITESSE

Le flagship hébergé a répondu en environ 1,4 seconde par champ, plus vite que la plupart des modèles locaux de 7 à 14 milliards (environ 2,6 à 7,6 secondes chacun sur un seul GPU grand public). Le jeu du modèle local peu coûteux offre une facture plus basse et des documents qui ne quittent jamais la machine. Il ne réduit pas la latence. Si la vitesse est la contrainte principale, le modèle local peu coûteux est souvent le mauvais choix par défaut, et cela doit figurer dans les critères du dispatcher.

Un petit modèle local n'est viable que quand la boucle le soutient : un snippet de récupération précis, le bon contenu dans le prompt, une validation sur chaque champ, et du code qui gère le formatage difficile. Les trois sections suivantes détaillent ce soutien.

LE PROMPT : LEVIER INSOUPÇONNÉ POUR AMÉLIORER LES RÉSULTATS

Avant de dépenser un modèle plus puissant, dépensez le prompt. Le plus grand bond en avant dans tout le benchmark ne venait pas de plus de paramètres. Il venait de l'ajout du vocabulaire métier de la tâche dans le prompt : le glossaire que les champs supposent.

Les deux modèles progressent. Le petit modèle local passe de 38% à 62% de bonnes réponses. Le flagship passe de 62% à 100%. Le flagship n'est pas magique non plus sans le glossaire. Il avait besoin des définitions pour terminer le travail.

L'échec concret que cela corrige ? Le vocabulaire que le modèle ne partage pas avec le document. Un champ libellé franchise par sinistre dans un document est rétention dans un autre et un simple nombre dans un troisième ; une prime est appelée différemment par chaque assureur. Un petit modèle face à un snippet brut fait des hypothèses. Donnez-lui la définition du champ à remplir, les synonymes, les unités, et la devinette devient une lecture. C'est le même vocabulaire de brique 2 qui améliore la récupération, réutilisé au moment de la génération, et c'est moins cher que n'importe quelle mise à niveau de modèle car cela aide chaque niveau en même temps.

LA MÉCANIQUE DE LA CASCADE : TROIS MOUVES CLÉS

Les deux faits précédents pointent vers une mécanique précise. Choisissez un modèle de départ selon des critères, validez son résultat et n'escaladez qu'en cas d'échec, puis divisez la tâche au lieu d'escalader quand l'échec est une transformation complexe. Trois étapes, dans cet ordre.

Le modèle de départ n'est pas le plus petit que vous avez. Trois critères définissent un seuil raisonnable, pour que la boucle commence au bon niveau plutôt qu'au bas de l'échelle.

1. CONFIDENTIALITÉ

Un document confidentiel ne peut pas être envoyé à une API hébergée du tout. Cela force l'utilisation d'un modèle local, quel que soit le modèle le plus économique ou le plus puissant dans le cloud. Le choix de départ devient donc le meilleur modèle local qui correspond à la machine. (Détecter et étiqueter un document comme confidentiel relève d'un volume plus important ; cet article suppose que l'étiquette arrive en entrée.)

2. FIABILITÉ DE LA SORTIE TYPÉE

La réponse de la série est toujours un objet typé. Le contrat d'extraction du benchmark est petit et strict : un nombre pur, sa devise, le qualifiant de précision séparé, et un booléen indiquant si le champ était présent. Les modèles forts émettent cela proprement. Les modèles plus petits et plus faibles émettent moins fiablement, omettant la devise, fusionnant « par événement » dans le nombre, ou inventant une valeur quand ils devraient mettre found=False.

Un petit modèle de départ n'est viable que s'il est couplé à une validation : vous ne faites pas confiance à sa sortie typée, vous la vérifiez (Article 8C) et laissez l'échec déclencher l'escalade.

3. COMPLEXITÉ DE LA TRANSFORMATION

Certaines tâches cachent une transformation complexe en une seule passe qui fait trébucher les petits modèles même quand la récupération était parfaite. C'est le troisième critère, et il a sa propre solution dans la section 3.3.

LA GÉNÉRATION COMME BOUCLE BORNÉE

Une fois le modèle de départ choisi, la génération devient une boucle bornée courte, pas un seul appel.

Exécutez le modèle choisi. Validez le résultat avec les vérifications de l'Article 8C : la forme typée est-elle correcte, les spans cités existent-ils, le texte cité apparaît-il vraiment dans la source ? Si la validation passe, livrez, et le modèle peu coûteux vient de faire le travail d'un flagship pour une fraction du coût. Si elle échoue, escaladez : relancez le même champ sur le modèle suivant, et validez à nouveau. La boucle est bornée, donc un champ pathologique ne peut pas tourner indéfiniment ; il escalade jusqu'au modèle le plus puissant et, si même celui-ci échoue, retourne un non répondu typé plutôt qu'une valeur erronée.

C'est l'écho côté génération de l'Article 10. Là, une page commence par le parseur peu coûteux et n'escalade vers un parseur plus lourd que si un contrôle peu coûteux indique que le parse est insuffisant. Ici, un champ commence par le modèle peu coûteux et n'escalade que si la validation indique que la réponse est insuffisante. Même logique d'ingénierie de boucle : payer pour l'outil coûteux uniquement sur les cas qui en ont besoin, et laisser un contrôle déterministe, pas une devinette, décider quels cas sont concernés.

DÉCOMPOSER LA TÂCHE : UNE AUTRE ISSUE QUE L'ESCALADE

Escalader vers un modèle plus grand n'est pas la seule solution à un échec, et ce n'est pas toujours la bonne. Certains échecs viennent d'une transformation complexe, pas d'un modèle trop faible, et le remède est de décomposer l'étape plutôt que de payer pour plus de capacité.

Prenons un exemple concret : un montant monétaire dans un format numérique clair. Face à « 3M », un petit modèle peut ne pas retourner fiablement « 3000000 », un trois suivi de six zéros ; il trébuche sur la reconnaissance et la mise à l'échelle en une seule passe. Un modèle plus grand masque le problème, mais une décomposition fait aussi bien : laissez le modèle pointer vers la ligne source, puis laissez un code déterministe transformer « 3M » en « 3000000 ». Chaque moitié est facile. Le modèle lit, le code calcule, et le formatage difficile ne dépend plus du tout de la capacité du modèle.

Cette décomposition a un deuxième avantage : le document brut peut rester entièrement local. Le modèle pointe vers une ligne, le code formate, et seuls des fragments anonymes sont éligibles pour quitter la machine vers un formatteur hébergé en aval. Mais cette décomposition n'est pas un repas gratuit, et le benchmark est sans pitié à ce sujet. Exécuter l'architecture entièrement locale « modèle pointe, code formate » a réduit la précision sur les mêmes champs par rapport à laisser un modèle capable extraire et formater en une seule passe. La raison est simple : pointer vers la bonne ligne est en soi difficile, et une ligne erronée condamne le champ avant même que le code ne s'exécute.

La décomposition est donc un outil réel avec un vrai coût. Utilisez-la quand l'échec est une transformation complexe que le modèle rate systématiquement, ou quand la confidentialité force le document à rester local. Mesurez la précision que vous sacrifiez. Ne supposez pas que la décomposition est toujours gagnante ; sur une tâche où un modèle capable peut extraire et formater proprement en une passe, une seule passe l'emporte.

La boucle dispose donc de deux échappatoires quand la validation échoue, pas une seule : escalader le modèle, ou diviser la tâche en étapes que le modèle actuel peut gérer. Le flag needsstepsplit du dispatcher enregistre laquelle de ces deux options est appliquée à ce champ.

LA CASCADE FERME LA BOUCLE DE LA SÉRIE

Cette sélection n'est pas une nouvelle idée greffée. Elle ferme une boucle que la série a déjà ouverte.

L'Article 6C (dispatch) lit un niveau de modèle suggéré à partir de la question parsée : une simple recherche factuelle et une synthèse multi-sauts nécessitent des niveaux différents avant même que la génération ne commence. C'est le signal côté question. Cet article ajoute le signal côté document et réponse (confidentialité, fiabilité de la sortie typée, complexité de la transformation) et, crucialement, le retour : 6C propose un niveau de départ, la génération tente, 8C juge, et la boucle escalade. Les trois s'emboîtent : 6C suggère, la génération tente, 8C juge, la boucle escalade.

Le benchmark est la raison de faire confiance à cette forme et de se méfier des raccourcis : la taille n'ordonne pas la précision, un petit modèle local seul n'obtient qu'un tiers des champs, et le levier le plus puissant est le vocabulaire que vous mettez dans le prompt, pas le nombre de paramètres pour lequel vous payez. Le coût baisse parce que la plupart des champs ne quittent jamais le niveau peu coûteux. La justesse tient parce que ceux qui ont besoin de plus l'obtiennent, sur preuve, pas sur une intuition.

Les articles de la série entre lesquels cette cascade s'insère, déjà publiés :

Essay : Une discussion à la frontière entre science et fiction. L'intelligence humaine, avec son extraordinaire…