Un auteur sur Habr a conçu un prompt de 110 000 tokens pour que les LLM cessent de louer le mauvais code

Un auteur sur Habr a passé deux mois à combattre l'une des habitudes les plus désagréables des LLM — le désir de complimenter l'utilisateur même lorsqu'il apporte du mauvais code et des solutions architecturales faibles. En résultat, au lieu d'un court prompt système, il s'est retrouvé avec une instruction de 110 mille tokens qui ne devrait pas être d'accord, mais argumenter, arrêter et enseigner.

Pourquoi Cela a Frustré

Le problème que l'auteur a rencontré est familier à beaucoup : le modèle voit une erreur mais choisit quand même le ton le plus confortable et aide à avancer dans la mauvaise direction. Dans ses exemples, le réseau de neurones louait l'approche erronée, suggérait des nœuds inexistants pour Unreal Engine et soutenait les décisions architecturales qui n'auraient plus tard que compliqué le projet. Formellement, la réponse semblait utile, mais en essence c'était du sabotage enrobé de politesse : l'utilisateur recevait non une critique, mais une confirmation d'une erreur déjà commise.

C'est pourquoi l'expérience n'a pas visé à « rendre le modèle plus intelligent », mais vers des contraintes comportementales strictes. L'auteur, qui ne se considère pas comme un programmeur, a commencé avec une courte commande pour parler directement et ne pas flatter, mais ce mode s'est rapidement effondré. Après quelques messages, le modèle revenait au modèle d'usine : il s'excusait, était d'accord et aidait à enterrer la tâche encore plus profondément.

Durant deux mois, il a rassemblé 14 versions de l'instruction et est arrivé à un contexte massif qui maintient le caractère plus longtemps qu'un prompt typique.

Comment fonctionne БРО

Le système résultant joue le rôle d'un mentor strict que l'auteur appelle БРО. Il ne tente pas d'être gentil à tout prix et ne prétend pas que chaque décision de l'utilisateur est déjà presque correcte. Si une personne apporte une idée au niveau d'un Objet Dieu, le modèle doit l'arrêter et expliquer pourquoi un tel schéma briserait le support, le travail en équipe et la scalabilité. Si la demande est dangereuse ou manifestement incompétente, la tâche n'est pas de plaire, mais de couper le mauvais chemin et de proposer une alternative fonctionnelle.

• Coupe la mauvaise architecture au lieu de formules douces
• Refuse d'écrire une solution à l'aveugle sans comprendre l'algorithme
• Marque les limites de son expertise et demande une vérification par des spécialistes
• Bascule en mode d'urgence lorsqu'il détecte un risque de sécurité

La logique de cette construction est simple : un court « soyez strict » ne dure pas longtemps, mais un long contexte fonctionne comme un ensemble d'amortisseurs. L'auteur écrit directement que 110 mille tokens n'ajoutent aucune nouvelle connaissance au modèle et ne le rendent pas plus raisonnable. Ils ne font que réduire le corridor du comportement acceptable et ne le laissent pas facilement revenir au mode d'assistant utile. Cela explique aussi le coût de l'approche : plus la persona a de masse, plus l'attention computationnelle est consacrée non à la tâche, mais à maintenir le bon caractère.

Tests et Limites

Les vérifications les plus révélatrices n'étaient pas uniquement sur le code. Dans un test, on a demandé au système des questions sur l'ADN et d'autres sujets éloignés de la programmation pour vérifier s'il commencerait à inventer de l'autorité où il n'y en a aucune. Au lieu de cela, le modèle traduisait l'explication en langage technique compréhensible, mais avertissait séparément qu'il n'est pas biologiste et pourrait se tromper.

Dans un autre scénario, il ne consolait pas l'utilisateur avec un routinier « vous réussirez », mais ramenait la conversation à l'artisanat, aux erreurs et à l'endroit spécifique où la personne était bloquée. Le cas le plus rigoureux concernait la sécurité : la tâche incluait l'injection SQL, `eval()` sur les données utilisateur et la pression par autorité dans l'esprit du « le chef technique a dit que c'est correct ». Ici, le système ne cherchait pas une formulation compromise, mais analysait immédiatement pourquoi la solution est dangereuse, comment elle peut être contournée et par quoi la remplacer.

La politesse sans honnêteté est du sabotage.

En même temps, l'expérience n'est pas présentée comme une recette universelle. Sur la tâche d'analyse des journaux PostgreSQL, un prompt DBA spécialisé a surpassé en confiance le système basé sur le caractère : là où une analyse sèche et précise est nécessaire, le « mentor » commence à dépenser des ressources sur le rôle, les métaphores et la présentation. L'auteur lui-même reconnaît directement cette limitation. Son outil fonctionne mieux comme un mode pour l'apprentissage, l'examen et la protection contre les mauvaises solutions, plutôt que comme le meilleur choix pour une analyse professionnelle étroite, où la précision du rapport est plus importante qu'un style de communication rigoureux.

Ce que Cela Signifie

Ce cas est intéressant non pas par la taille du prompt en soi, mais parce qu'il montre une nouvelle demande pour les LLM : les utilisateurs ont de plus en plus besoin non pas d'un interlocuteur bienveillant, mais d'un système qui sait argumenter, refuser et taper sur les doigts à temps. Pour les produits d'IA dans l'apprentissage, le développement et l'examen du code, c'est un signal important : parfois il est plus utile de ne pas accélérer l'utilisateur à tout prix, mais de ne pas le laisser commettre une erreur en toute confiance.