Modèles, contexte et réponses incorrectes

Distinguez les capacités des informations disponibles

Un modèle de langage utilise les régularités apprises et les informations fournies pendant une tâche. Les modèles actuels peuvent mener des raisonnements approfondis et effectuer un travail logiciel utile. Ils peuvent aussi produire une réponse détaillée fondée sur une hypothèse incorrecte.

« Modèle frontier » désigne un niveau de capacité qui évolue. Le terme ne prouve pas que le modèle a lu votre dépôt. Il n’indique pas que le modèle connaît les versions de vos dépendances ou vos règles métier non écrites. L’environnement de la tâche doit fournir ces faits.

Un agent doté des bons outils peut récupérer des informations. Une conversation sans accès ne peut pas inspecter le dépôt. Lorsqu’une réponse semble incorrecte, posez deux questions. Le modèle peut-il résoudre le problème avec les bonnes informations ? Les a-t-il reçues ?

Un autre modèle peut aider à résoudre le premier problème. Une politique manquante ou une vérification des dépendances peut résoudre le second.

Définissez le contexte de cette tâche

Le contexte regroupe les informations disponibles pour la réponse en cours. Il comprend les instructions, les fichiers fournis, les échanges pertinents et les résultats des outils. Chaque produit sélectionne et conserve ces informations à sa manière. Il peut aussi résumer le contenu antérieur.

Ne supposez pas qu’un modèle lit chaque fichier d’un dossier envoyé. Ne supposez pas qu’une instruction initiale reste disponible pendant toute une longue session. Demandez à l’outil quels fichiers et instructions il a utilisés.

Davantage de contexte n’améliore pas toujours la réponse. Une décision d’architecture actuelle peut être plus utile que des fichiers source sans rapport. Un guide de migration obsolète peut induire une réponse incorrecte parce qu’il paraît faire autorité.

Prenons une fonctionnalité fictive de paramètres de compte. Fournissez la route, le middleware d’autorisation, le modèle de données concerné et un test existant. Ajoutez une contrainte précise : « Un membre peut changer son nom d’affichage. Il ne peut pas changer son rôle dans l’organisation. » Le modèle dispose désormais d’une règle explicite à préserver.

Vérifiez les affirmations d’une explication

Une réponse peut déclarer qu’un endpoint est sûr parce qu’un middleware vérifie le propriétaire de la ressource. Vérifiez chaque partie de cette affirmation.

1. Vérifiez que l’endpoint utilise le middleware indiqué.
2. Vérifiez que le middleware contrôle le propriétaire, et pas seulement l’authentification.
3. Identifiez la source de l’identité de l’utilisateur.
4. Effectuez un test de refus avec un autre utilisateur.

Une référence au dépôt indique où regarder. Elle ne prouve pas que l’explication correspond au code.

Appliquez la même méthode aux recommandations d’API. Le code généré peut appeler une méthode que le package installé n’exporte pas. Vérifiez la version du package et sa documentation officielle avant de remplacer des dépendances. Une hypothèse non vérifiée pourrait sinon entraîner une migration inutile.

Transformez l’incertitude en contrôle

« Soyez exact » n’est pas un plan de vérification. Identifiez l’hypothèse, les preuves requises et les conséquences d’un résultat incorrect.

Par exemple : « Nous n’avons pas vérifié l’isolation des tenants pour cet endpoint. Inspectez le gestionnaire de requêtes. Ajoutez un test où un utilisateur d’un autre tenant demande le même enregistrement. » Cette instruction donne à l’agent une investigation précise et un résultat observable.

Pour les questions d’implémentation, examinez la version réelle du système. Un document peut décrire le comportement prévu. L’inspection du code et les tests aident à établir le comportement actuel. S’ils divergent, consignez l’écart jusqu’à sa résolution par un responsable. Ne choisissez pas discrètement la réponse la plus commode.

Les managers peuvent appliquer cette méthode sans lire chaque modification de code. Demandez quelles hypothèses l’équipe a vérifiées. Identifiez celles qui restent ouvertes et leurs responsables. Ces informations soutiennent une décision de mise en production plus directement que le nom du modèle.