Comment l'Ingénierie du Contexte Rend un LLM Local Faible un Agent Fiable

L'auteur d'un article sur Habr a démontré : pour un modèle de langage local fonctionnant dans une boucle fermée sur du matériel limité, la fiabilité d'un agent n'est pas déterminée par la taille du modèle, mais par la façon dont son contexte est organisé.

Pourquoi simplement « prendre un modèle plus grand » ne fonctionne pas

Lorsqu'un modèle s'exécute localement — au sein du périmètre d'une entreprise, sur du matériel limité — augmenter sa taille n'est simplement pas possible : il n'y a pas moyen de prendre un modèle cloud de haut niveau avec un grand nombre de paramètres. L'auteur affirme que dans ces conditions, le principal levier de qualité n'est pas le modèle lui-même, mais le contexte : exactement ce qui lui est montré, dans quel ordre et comment les informations inutiles sont filtrées.

Ce qui compose le contexte « correct »

Selon la description de l'auteur, le contexte n'est pas simplement du texte inséré, mais un assemblage tenant compte de trois paramètres : qui pose la question, d'où elle vient et ce qui est exactement demandé. Deux éléments supplémentaires s'ajoutent à cela :

• Un seuil de pertinence honnête — le modèle ne reçoit que ce qui se rapporte réellement à la question, pas tout « au cas où »
• Un ordre de section réfléchi — les informations importantes pour répondre sont placées de sorte que le modèle ne les « perde » pas parmi les détails secondaires

En d'autres termes, pour la même question, le contexte sera différent en fonction du rôle de l'utilisateur, du canal de communication et du sujet : un employé du support et un développeur devraient voir des fragments différents de la base de connaissances, même s'ils posent formellement « la même question ».

Comment les modèles forts se différencient des modèles faibles dans ce scénario

L'observation clé de l'article — comment un modèle pardonne les erreurs dans l'organisation du contexte — dépend de sa taille et de sa puissance. Sur un modèle cloud puissant, un contexte maladroitement assemblé est souvent pardonné par des réserves de raisonnement — le modèle comprendra par lui-même ce qui est important et ce qui ne l'est pas. Sur un modèle local de gamme moyenne, il n'y a pas de tel réserve : le même contexte maladroit casse directement la qualité de la réponse.

En pratique, cela signifie que les prompts et le context-pipeline doivent être testés sur le modèle cible (faible), pas sur un modèle cloud de haut niveau — ce qui semble viable sur un modèle fort peut s'effondrer lorsqu'il est transféré sur un modèle local.

Où c'est particulièrement critique

Les modèles locaux sont le plus souvent choisis où les données ne peuvent pas quitter le périmètre — banques, secteur public, médecine, industrie manufacturière. Dans de tels environnements, l'équipe n'a pas la possibilité de « simplement prendre un modèle plus puissant » : le matériel et les licences pour les API cloud de haut niveau ne sont soit pas disponibles, soit interdits par la politique de sécurité. Dans ces conditions, l'ingénierie contextuelle — le seul levier qui peut être directement géré, contrairement à l'architecture du modèle lui-même.

L'auteur souligne particulièrement la différence entre « contexte en général » et « contexte pour une demande spécifique » : si un système a une fois assemblé un ensemble universel de documents et les alimente au modèle indifféremment, indépendamment de qui demande et de quoi, les chances d'obtenir une réponse fragmentaire ou incorrecte sur un modèle faible sont notablement plus élevées qu'avec un assemblage précis pour chaque cas.

Que cela signifie

Pour les équipes contraintes — par les exigences de sécurité, les limites budgétaires du matériel ou la portée des données — de travailler avec des modèles locaux, peu puissants, la discipline de l'ingénierie contextuelle devient non une amélioration optionnelle, mais une condition sans laquelle un agent ne fonctionne tout simplement pas de manière fiable.