hh.ru a expliqué comment concevoir des prompts de production pour des services d'AI sans mauvaises surprises

hh.ru a partagé une pratique sur la façon d'écrire des prompts pour ses services d'IA en production. L'idée principale est simple : un prompt dans un produit n'est pas une conversation avec un chatbot, mais un système d'ingénierie avec des contraintes, des tests et des ajustements constants.

La Production n'est pas du Chat

Dans l'utilisation typique de LLM, tout est assez flexible : un utilisateur pose une question, obtient une réponse, affine la formulation, redémarre le dialogue et continue. Dans un produit, il n'y a pas ce luxe. Ici, une réponse échouée peut atteindre des milliers d'utilisateurs, casser un scénario, créer un risque réputationnel ou simplement aggraver la conversion.

Par conséquent, un prompt en production n'est pas une seule phrase comme « rends-le joli », mais un ensemble d'instructions interconnectées, de données, de règles et d'appels d'outils, parfois s'étendant sur des centaines de lignes. L'auteur de l'article appelle cela la bataille d'un ingénieur contre un « perroquet stochastique ». Le modèle ne comprend pas le sens de la manière dont les humains le font ; il prédit le prochain token basé sur les probabilités.

La tâche de l'équipe est de maximiser la réduction de l'espace d'aléatoire : donner au modèle un rôle clair, un contexte, des contraintes et un format de réponse attendu. Plus cette boucle est bien conçue, plus grande est la chance d'obtenir un résultat prévisible, sûr et utile pour les affaires réelles. C'est pourquoi travailler avec des prompts ressemble de plus en plus au développement régulier plutôt qu'à une expérience créative.

Le Cadre d'un Bon Prompt

Chez hh.ru, ils recommandent d'écrire les instructions en anglais, tout en laissant les exemples de messages des utilisateurs dans la langue du produit — dans ce cas, le russe. La raison n'est pas seulement que les instructions en anglais sont souvent interprétées avec plus de précision par le modèle. L'anglais économise aussi des tokens, et dans les systèmes avec des milliers et des millions d'appels, cela affecte déjà le coût et la latence. Les modèles et le balisage aident également : markdown ou XML rendent les longues instructions plus structurées et réduisent l'ambiguïté. Un cadre typique inclut généralement le rôle du modèle, l'objectif, le contexte, les étapes de résolution et le format de réponse.

• rôle du modèle
• objectif et tâche spécifique
• contexte des données d'entrée
• algorithme d'action ou étapes de vérification
• contraintes et format de réponse

Les exemples few-shot sont particulièrement risqués. Ils aident vraiment le modèle à mieux comprendre la tâche, mais se transforment tout aussi facilement en un modèle qu'il commence à transférer mécaniquement à de nouvelles situations. Le modèle s'accroche souvent littéralement aux formulations et les reproduit hors contexte. L'article fournit un cas illustratif : ils ont ajouté un exemple de question de clarification pour un candidat au prompt système, après quoi l'agent a commencé à la poser même là où c'était complètement inapproprié.

« Êtes-vous prêt pour les voyages d'affaires à Riazan ? »

Après cela, l'assistant posait périodiquement des questions sur les voyages même dans les offres d'emploi où les voyages n'étaient pas nécessaires.

La conclusion de l'équipe est sévère : tout ce qui est risqué doit être explicitement interdit. Si un bot ne doit pas discuter d'autres entreprises, exprimer son opinion, sortir du sujet ou accomplir des tâches non liées, cela doit être clairement énoncé. Un autre conseil pratique est de ne pas craindre les longs prompts s'ils sont logiquement assemblés et ne se contredisent pas. Il est également important de transmettre explicitement la date actuelle, d'ajuster soigneusement la température et de se souvenir que les prompts doivent presque toujours être réécrits pour différents modèles.

Comment Ils le Testent

Même un bon prompt ne peut pas être considéré comme prêt après quelques exécutions réussies. Le comportement des LLM n'est pas entièrement déterministe : avec des demandes identiques et des paramètres identiques, les réponses peuvent toujours varier légèrement. Par conséquent, l'assurance qualité ressemble plus à une évaluation d'ingénierie d'un système qu'à une relecture manuelle de texte. Vous avez besoin de grands ensembles de cas de test, d'exécutions multiples et de couverture de différents scénarios d'utilisateurs — presque comme dans les tests classiques, mais avec des ajustements pour la nature probabiliste du modèle.

La source la plus précieuse de nouveaux tests est les journaux réels des utilisateurs. C'est là que surgissent des questions inattendues, des tentatives de détourner le bot et des cas limites que l'équipe n'avait pas anticipés. À mesure que ces cas s'accumulent, l'ensemble de données d'évaluation doit être constamment réapprovisionné. Une autre conclusion importante : les prompts doivent être testés dans un environnement aussi proche que possible de la production. Les LLM sont sensibles même aux petits changements de format d'entrée, donc un environnement « presque identique » donne facilement une fausse confiance en la stabilité.

Ce Que Cela Signifie

L'article de hh.ru montre bien que l'ingénierie des prompts se transforme rapidement en ingénierie de produit régulière. Ici, la victoire ne va pas à la demande la plus créative, mais à une combinaison de structure, de contraintes, d'évaluations, de journaux et de raffinement itératif. Pour les équipes construisant des fonctionnalités d'IA en production, c'est un signal : les prompts doivent maintenant être versionnés, testés, suivis par des métriques, liés à des scénarios réels d'utilisateurs et adaptés à des modèles spécifiques aussi sérieusement que le code.