RAG: The LLM Cascade, an Economic Asset Against Leading Models

RAG : la cascade LLM, un atout économique face aux modèles phares

Modèles de langage de grande taille

L'ingénierie des boucles pour la génération RAG : une cascade LLM d'un modèle local peu coûteux jusqu'à un modèle phare hébergé.

Dans le domaine de l'intelligence documentaire d'entreprise, deux angles sont à considérer concernant la cascade : le coût et une boucle de validation, soutenus par une véritable évaluation de vingt modèles locaux face à un modèle phare hébergé.

Les champs typés à extraire d'un ensemble de documents réels comprennent : montants, dates, limites de couverture, un valeur structurée par champ. Le réflexe par défaut est d'envoyer chaque champ à une API hébergée de classe GPT-4. Cela fonctionne, mais la facture est la plus importante dans le coût d'exploitation de la chaîne. La plupart de ces champs sont des recherches simples qu'un modèle beaucoup plus petit peut gérer correctement, et vous payez des prix de modèle phare pour tous.

La réaction évidente est de remplacer par un petit modèle et d'encaisser les économies. Cependant, fait à l'aveugle, cela peut échouer. Un modèle trop faible pour la tâche renvoie une sortie typée erronée, ou échoue dans une transformation, et si personne ne vérifie, la mauvaise valeur est expédiée. Ainsi, la réponse n'est pas de "utiliser le grand modèle" ni "d'utiliser le petit modèle". Il s'agit de choisir le modèle comme les briques précédentes choisissent une méthode : par critères, puis vérifier, et escalader uniquement lorsque la vérification échoue.

Cet article est un complément à l'intelligence documentaire d'entreprise, dont la philosophie est exposée dans "Amplify the Expert", une série qui construit le RAG d'entreprise à partir de quatre briques : parsing de documents, parsing de questions, récupération, génération. Il développe une décision à l'intérieur de la brique de génération : quel modèle exécute l'appel, et que se passe-t-il lorsque le modèle peu coûteux n'est pas suffisant ? Il s'appuie sur l'Article 6C (dispatch), qui lit déjà un niveau de modèle suggéré à partir de la question analysée, l'Article 8C (validation), le signal qui déclenche une escalade, et l'Article 10 (parsing adaptatif), la même structure de départ bon marché et d'escalade à la demande appliquée au parser.

Tout ce qui suit est soutenu par un véritable benchmark : une tâche d'extraction de champs typés de quelques centaines à travers des dizaines de documents, plus une évaluation ciblée de vingt modèles locaux contre un modèle phare hébergé, le tout à température 0 avec une sortie JSON. Les chiffres sont agrégés. Aucun document, étiquette de champ ou chiffre de ce benchmark n'apparaît ici.

Deux angles : coût et boucle

Il y a deux raisons de se soucier de la sélection des modèles, et elles se renforcent mutuellement.

• L'angle coût est direct. Les modèles phares coûtent un ordre de grandeur plus cher par appel qu'un petit modèle local. Sur une tâche d'extraction avec des milliers d'appels au niveau des champs, ou un assistant de corpus répondant à des milliers de questions par jour, la facture du modèle domine le coût d'exploitation. La plupart de ces appels ne nécessitent pas un modèle phare. Diriger les simples vers un modèle moins cher est de l'argent laissé sur la table jusqu'à ce que vous le fassiez.

• L'angle boucle concerne la correction sous cette contrainte. Vous ne pouvez pas réduire les coûts en devinant qu'un petit modèle va s'en sortir. Vous commencez avec un modèle, vérifiez si sa réponse est correcte, et escaladez vers un modèle plus puissant uniquement lorsque la vérification échoue. La boucle est ce qui rend l'économie de coûts sûre : le modèle peu coûteux est la tentative par défaut, pas un pari, car une tentative échouée est détectée et réessayée sur un modèle plus grand plutôt que d'être expédiée.

Le coût vous pousse vers le bas de l'échelle des modèles. La boucle vous empêche de tomber. Cette structure de départ bon marché et d'escalade en cas d'échec a un nom dans la littérature : une cascade LLM.

Ce que disent les chiffres

La conception de la section 3 repose sur deux faits mesurés. Prenez-les d'abord, car ils expliquent pourquoi la cascade est structurée de cette manière.

L'évaluation : plus grand n'est pas forcément mieux

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

• Un modèle de 4B et un de 7B dominent le champ local, un modèle de 12B et un de 14B se trouvent en dessous, et un modèle de 1B est à la traîne : la taille est un mauvais prédicteur.

Trois conclusions se dégagent directement de ce tableau, et chacune façonne la conception.

• Plus grand n'est pas mieux. Un modèle de 4B (qwen3:4b) et un de 7B (mistral:7b) dominent le champ local. Un modèle de 12B et un de 14B (gemma3:12b, phi4:14b) se trouvent en dessous. Deux modèles de la même famille, l'un deux fois plus grand que l'autre, sont à égalité. Le nombre de paramètres est un mauvais prédicteur. La famille du modèle et la manière dont il a été entraîné comptent davantage. C'est exactement pourquoi la boucle ne doit pas grimper une échelle de taille à l'aveugle : le prochain échelon n'est souvent pas la prochaine taille.

• Il existe un seuil. Les modèles de moins de 2B chutent brutalement (qwen2.5:1.5b à 12 %, llama3.2:1b à 6 %), et un modèle de 0.5B que nous avons essayé a renvoyé un JSON vide sur la plupart des champs : pas de réponse erronée, pas de réponse du tout. Commencer là brûle une itération de boucle sur un échelon qui n'allait jamais tenir. Des critères existent pour commencer au-dessus du seuil, pas à celui-ci.

• Le coût n'est pas la vitesse. Le modèle phare hébergé a répondu en environ 1,4 secondes par champ, plus rapidement que la plupart des modèles locaux de 7B à 14B (environ 2,6 à 7,6 secondes chacun sur un seul GPU grand public). Le jeu local peu coûteux permet d'avoir une facture plus basse et des documents qui ne quittent jamais la machine. Cela n'achète pas la latence. Si la vitesse est la contrainte, 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 dernier chiffre à prendre en compte. Le meilleur petit modèle local, exécuté seul sur la tâche brute, a obtenu environ un tiers des champs corrects. Rapide (quelques secondes par champ) mais pas assez bon pour être expédié. Un petit modèle local n'est viable que lorsque la boucle le soutient : un extrait de récupération serré, le bon contenu de prompt, une validation sur chaque champ, et du code effectuant le formatage difficile. Les trois sections suivantes constituent ce soutien.

Le plus grand levier est le contenu du prompt, pas la taille du modèle

Avant de dépenser un modèle plus grand, investissez dans le prompt. Le plus grand bond dans tout le benchmark n'est pas venu de plus de paramètres. Il est venu de l'intégration du vocabulaire commercial de la tâche, le glossaire que les champs supposent, dans le prompt.

Les mêmes définitions qui corrigent la récupération corrigent la génération : le modèle phare n'atteint 100 % qu'une fois qu'elles sont dans le prompt.

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

L'échec concret que cela corrige est le vocabulaire que le modèle ne partage pas avec le document. Un champ étiqueté "franchise par réclamation" dans un document est "retenue" dans un autre et un simple chiffre dans un troisième ; une prime est appelée d'une manière par un assureur et d'une autre par le suivant. Un petit modèle exposé au fragment brut devine. Donnez-lui la définition du champ qu'il remplit, les synonymes, les unités, et la devinette se transforme en une lecture. C'est le même vocabulaire de la brique 2 qui élève la récupération, réutilisé au moment de la génération, et c'est moins coûteux que toute mise à niveau de modèle car cela aide chaque échelon à la fois.

La cascade : critères, boucle et séparation

Voici le mécanisme que les deux faits pointent. Choisissez un échelon de départ par critères, validez sa sortie et escaladez uniquement en cas d'échec, et divisez la tâche au lieu d'escalader lorsque l'échec est une transformation difficile. Trois mouvements, dans cet ordre.

Choisir le modèle de départ par critères

Le modèle de départ n'est pas le plus petit que vous ayez. Trois critères établissent un seuil raisonnable, de sorte que la boucle commence au bon échelon plutôt qu'au bas.

• Confidentialité. Un document confidentiel ne peut pas être envoyé à une API hébergée. Cela impose un modèle local, peu importe ce qui serait le moins cher ou le plus puissant dans le cloud, et le choix de départ devient le meilleur modèle local qui s'adapte à la machine. (Détecter et étiqueter un document comme confidentiel est une préoccupation de volume ultérieur ; cet article suppose que l'étiquette arrive en entrée.)

• 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 qualificateur de précision gardé séparé, et un booléen pour indiquer si le champ était présent ou non.

class ExtractedValue(BaseModel):
    value: float | None
    currency: str | None
    precision: str | None

Les modèles puissants émettent cela de manière claire. Les modèles plus faibles et plus petits l'émettent moins de manière fiable, omettant la devise, intégrant "par événement" dans le nombre, ou inventant une valeur alors qu'ils auraient dû définir found=False. Ainsi, un petit modèle de départ n'est viable que s'il est associé à une validation : vous ne faites pas confiance à sa sortie typée, vous la vérifiez (Article 8C) et laissez l'échec conduire à l'escalade.

• Complexité de transformation. Certains travaux cachent une transformation difficile en un coup qui fait trébucher les petits modèles même lorsque la récupération était parfaite. C'est le troisième critère, et il a sa propre solution dans la section 3.3.

Le dispatcher qui lit ces trois critères est petit.

class GenerationPlan(BaseModel):
    needs_validation: bool
    needs_step_split: bool
    max_escalations: int = 2

def plan_generation(doc, shape):
    if doc.confidential:
        return local_plan(shape)
    return tier_plan(shape)

La fonction local_plan fixe le meilleur modèle local et définit needs_validation=True, car la sortie typée d'un petit modèle est toujours vérifiée. La fonction tier_plan commence à partir du niveau suggéré de l'Article 6C et demande uniquement une validation lorsque ce niveau est petit. Les deux lisent needs_step_split à partir de la forme de la réponse, le troisième critère, développé dans la section 3.3.

Valider, puis escalader uniquement en cas d'échec

Avec un modèle de départ choisi, la génération devient une courte boucle limitée, pas un appel unique.

def generate_with_escalation(question, context, plan, ladder):
    for model in ladder.from_(plan.model, up_to=plan.max_escalations):
        answer = generate(question, context, model=model)
        if validate(answer, context):        # Article 8C
            return NotAnswered()

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 plages citées existent-elles, le texte cité apparaît-il réellement dans la source ? Si la validation réussit, expédiez, et le modèle peu coûteux a juste réalisé le travail d'un modèle phare.