Placez les faits changeants là où vous pouvez les corriger

Un catalogue ou un contrat d’API évolue. S’il réside dans le prompt d’un agent, chaque correction exige une modification et chaque appel doit le relire.

agent knowledge retrieval

Quelle est la réponse courte ?

Le prompt doit porter les comportements durables. Les faits changeants doivent se trouver dans une source actualisable, limitée au bon contexte et citable au moment de l’usage. Si un agent se trompe sur un champ fournisseur, vérifiez le contrat récupéré avant de modifier le prompt ou d’ajuster le modèle. Conservez les règles déterministes d’autorisation et d’écriture dans le code.

En savoir plus
Sur cette page

Imaginez un catalogue de produits qui change le lundi. Le prompt d’un assistant contient encore la liste du vendredi. L’équipe le met à jour. Une deuxième copie de l’ancienne liste subsiste dans les exemples utilisés pour entraîner le modèle. L’assistant donne maintenant une réponse actuelle et une réponse périmée au cours de la même session.

Cet échec est illustratif, mais son mécanisme est courant : un même fait possède plusieurs domiciles.

Une présentation sur les prompts, la récupération et les poids du modèle trace une frontière utile. Le prompt indique à l’assistant comment se comporter. La récupération apporte une connaissance actuelle et citable à une tâche précise. L’adaptation du modèle peut lui apprendre un schéma stable. Traiter ces trois éléments comme une échelle, avec d’abord le prompt, puis la récupération et enfin l’ajustement dès que la réponse est encore fausse, conduit à mal diagnostiquer les erreurs factuelles.

Un prompt est un mauvais catalogue

Les prompts séduisent parce qu’ils sont faciles à modifier. Ajoutez un paragraphe et la requête suivante le transporte. Cette simplicité cache deux coûts. Le fait est envoyé à chaque appel, même lorsqu’il est inutile. Et un long prompt rend plus difficile de savoir quelle copie d’une règle le modèle a utilisée.

Une instruction durable comme « demander avant d’envoyer une campagne » a sa place près de l’agent. Une liste des champs personnalisés actuels de cette boutique, non. Elle peut changer après l’ajout d’un attribut par un administrateur. Elle peut différer selon les comptes. Elle peut être visible dans un espace de travail et interdite dans un autre.

Le guide du connecteur Brevo montre pourquoi les définitions des champs comptent dans une synchronisation de contacts. Si un attribut n’est pas déclaré dans le compte de destination, une correspondance plausible d’après son nom risque de ne pas produire le champ attendu. L’agent doit examiner le contrat actuel du compte, plutôt que de se souvenir d’une liste générique apprise pendant l’entraînement.

Un résultat de recherche utile doit être assez petit pour être contesté. Il doit indiquer à quel compte il s’applique, quand il a été lu et quelle opération ou quel champ il décrit. Si deux passages récupérés se contredisent, le système doit montrer le conflit au lieu de choisir silencieusement le plus fluide. La prochaine étape peut être une nouvelle consultation ou un examen, pas une reformulation plus insistante du prompt.

Récupérer le fait avec son périmètre

Une fiche de connaissance utile porte plus que du texte. Elle a besoin d’une source, d’une version ou d’une heure de lecture, du périmètre du compte et d’un moyen clair d’être supprimée ou remplacée. La définition d’un champ trouvée dans le compte d’un commerçant ne doit jamais devenir une règle universelle pour un autre.

Une question sur un attribut de contact peut alors récupérer le plus petit passage qui y répond : le nom du champ, son type et le compte où il existe. La réponse peut renvoyer à cette source. Si la correspondance échoue, l’équipe peut demander si le fait était périmé, si le résultat provenait du mauvais compte ou si le modèle a mal compris un passage correct.

Ces problèmes exigent des réparations différentes. Modifier le prompt ne peut pas corriger un filtre de recherche qui traverse les limites entre comptes. Un modèle plus grand ne peut pas fournir une définition d’attribut que personne n’a récupérée.

L’explication de MCP montre comment un agent interroge des outils. L’outil doit renvoyer le contrat pertinent, tandis que l’application impose qui a le droit de le consulter. Une instruction textuelle disant « ne révèle pas les données d’un autre compte » ne remplace pas une requête limitée au bon compte.

Cette répartition accélère aussi les réparations. Si un champ de destination est renommé, mettez à jour la source du schéma et invalidez la correspondance concernée. Si l’agent comprend mal de façon répétée une instruction stable, modifiez celle-ci ou testez un entraînement ciblé. Si la réponse est fausse parce que le système de recherche a choisi le mauvais compte, changer les poids du modèle manquerait la cause. Chaque catégorie d’erreur a un responsable et un chemin de correction distincts.

  1. Instruction durable

    Comment l’assistant doit agir

  2. Recherche limitée au bon contexte compte · version · date

    Ce qui est vrai maintenant

  3. Décision de correspondance

    Employer le fait actuel pour cette tâche

  4. Écriture contrôlée

    Le code vérifie l’autorisation et le périmètre

Emplacements conceptuels d’une décision d’intégration Les instructions durables guident le comportement, une recherche limitée apporte les faits actuels, la décision de correspondance utilise les deux et le code contrôle l’écriture.

N’enseigner les schémas qu’une fois stabilisés

Une objection raisonnable serait : « Si un fait sert constamment, pourquoi ne pas l’enseigner à un plus petit modèle ? » La répétition ne suffit pas. Le fait doit rester correct entre deux mises à jour du modèle et celui-ci doit pouvoir distinguer les contextes.

Une manière stable de classer des cas peut finir par justifier un ajustement. La liste actuelle des champs d’un fournisseur est un mauvais candidat. Même si elle change rarement, une seule réponse périmée peut produire une mauvaise correspondance appliquée à de nombreux enregistrements. Gardez le fait là où une personne peut l’inspecter et l’actualiser.

La source met aussi en garde contre l’usage de la récupération pour résoudre tous les problèmes de raisonnement. Si le modèle ne sait pas comparer correctement deux documents pertinents, en ajouter cinquante ne lui apprendra pas à raisonner. Demandez d’abord si le bon passage est arrivé. Demandez ensuite si le jugement porté sur ce passage était solide.

Pour une personne qui construit une intégration, cela donne une séquence de réparation : identifier l’affirmation incorrecte, examiner le passage récupéré sur le champ ou l’API, vérifier son compte et sa version, corriger si nécessaire la source ou la recherche, puis tester de nouveau la décision. Ce n’est qu’ensuite qu’il faut envisager un changement de modèle.

Le coût est l’entretien d’une véritable couche de connaissance : mises à jour des sources, contrôles d’accès et citations. Le gain est un fait corrigeable à un seul endroit.

Un contrat changeant ne devrait jamais attendre qu’un modèle l’oublie.

Questions fréquemment posées

Que faut-il placer dans le prompt d’un agent ?

De brèves instructions durables sur le comportement et les limites. Un catalogue changeant, une liste de champs propre à un compte ou une règle fournisseur actuelle doivent être récupérés auprès d’une source autorisée au moment utile.

Pourquoi ne pas ajuster un modèle sur la documentation actuelle ?

L’ajustement peut inscrire un fait changeant dans des poids difficiles à inspecter et à actualiser. Vérifiez d’abord que le bon document est récupéré et cité au moment de la décision.

Comment réparer une réponse factuelle erronée ?

Examinez le document source, sa version, le filtre de recherche et le passage renvoyé. Corrigez le fait ou le chemin de récupération avant de changer le modèle.

Demandez un accès anticipé

Indiquez votre prénom et votre adresse e-mail professionnelle. Nous vous enverrons un lien pour confirmer votre demande d’accès à Tajo.

Obtenir Brevo