Les outils de guidage font en sorte que l’approche RAG agente suive trois étapes au lieu d’une seule invocation spectaculaire.

Les parties précédentes de cette série ont construit un arbre de résumé, maintenu les chiffres bruts à l’écart du modèle linguistique, extrait du texte des figures, cherché ce qui avait changé entre les déclarations, analysé comment tout est retrouvé, et déterminé à quelle entreprise se référait une requête. Ce chapitre porte sur l’interface restreinte à laquelle ces éléments accèdent réellement : un bref texte de description d’outil que le modèle examine avant de choisir une action.

Les trois outils

La partie 4 analyse les changements annuels des facteurs de risque. Fournir les deux documents 10-K à un modèle et demander quels éléments ont changé a échoué non seulement en raison des coûts : la méthode Context Rot de Chroma maintient la tâche constante et ne varie que la longueur des entrées entre différents modèles — les performances déclinent à mesure que le contexte augmente, de manière inégale et imprévisible uniquement à partir de la tâche elle-même. Les échecs restent silencieux : un modèle qui indique six changements ne vous dit jamais qu’il a manqué un septième. Même les annotations au niveau des caractères peinent avec le réajustement du texte ; les deux résumés simultanés sont encore pires. Ceux qui ont fonctionné utilisaient trois outils, et non deux :

1. L1 pour la pertinence — des résumés de sections au style RAPTOR (un résumé AI précis par section du document, comme dans la partie 1). Cela indique quels sujets ont changé. Une seule mention par côté. Perçoit des significations que les paires de caractères ne peuvent pas détecter.

Diff pour les preuves — une mise en évidence au niveau des clauses qui fournit le texte exact à citer pour chaque thème identifié. Entièrement mécanique, exhaustive et révisable.

Décompte pour la vérification — vérifier si le libellé distinctif diffère réellement entre les deux documents. Des formulations identiques des deux côtés indiquent généralement un simple réarrangement, et non un véritable changement.

Cette triade reste correcte. Écrit sous forme de paragraphe d’article, elle est également complètement inerte. Rien à l’intérieur ne fait fonctionner d’outil. Un modèle qui s’est demandé ce qui avait changé dans les facteurs de risque d’Apple n’a jamais lu cet essai. Il contient une question, une liste d’outils et ce que ces outils disent d’eux-mêmes. En voyant diff_filings, son instinct raisonnable est d’appeler cet outil et de décrire le résultat. L’AGI RAG passe souvent à côté de cela : la récupération est la partie facile ; la partie difficile consiste à apprendre au modèle quels sont les trois étapes à suivre et dans quel ordre, en utilisant uniquement le texte associé aux outils.

_SECTION_SLUGS = (
    "overview", "routing", "setup", "deal_walkthrough", "diff_workflow",
    "tools", "warmth", "time_axes", "sql_track", "metrics", "alpha", "fields",
    "idempotency", "presentation", "response_bounds",
)


def _split_sections() -> dict[str, str]:
    parts = _GUIDANCE_MD.split("\n## ")[1:]
    assert len(parts) == len(_SECTION_SLUGS), (
        f"guidance has {len(parts)} sections, {len(_SECTION_SLUGS)} slugs"
    )

Si les indications sont erronées, les outils ne se combinent jamais. Même si elles sont correctes mais non lues, ils ne se combinent toujours pas. Le reste de cet article porte sur la manière de faire en sorte que ces indications s’affichent, restent brèves et survivent à la recherche d’outils.

Sélection, invocation et ce qui n’est ni l’un ni l’autre

L’utilisation d’outils se divise en deux étapes que les gens savent déjà nommer.

La sélection consiste à décider quel outil doit faire partie du ensemble actif pour cette manche : orientation des actions, recherche d’outils, filtrage de catalogues. L’invoquation consiste à envoyer une requête structurée avec des arguments une fois qu’un outil est disponible. Les frameworks et les API de modèles s’intéressent beaucoup à ces deux étapes.

Il existe une troisième étape qui n’appartient à aucune des deux : l’orientation — c’est-à-dire le texte qui explique au modèle pourquoi un outil existe dans un flux de travail, ce qui doit se produire avant son utilisation et à quoi ressemble le résultat une fois l’opération terminée. L’orientation n’est pas un choix entre récupérer ou générer des informations. C’est la phrase qui transforme trois outils inactifs en une séquence cohérente.

La plupart des systèmes cachent les informations d’orientation dans des prompts système qui s’allongent indéfiniment, ou bien les omettent en espérant que le nom de l’outil suffit. Aucune de ces approches ne fonctionne efficacement lorsque l’on dispose de dizaines d’outils MCP et que l’utilisateur pose une question simple concernant deux documents.

L’outil de guidage

outil de guidage est un outil dont la seule fonction est de fournir une procédure : une description courte et fiable du processus en plusieurs étapes. Il ne récupère pas de documents, il ne calcule pas de différences non plus. Il renvoie simplement le texte que le modèle doit suivre pour les étapes suivantes.

For the full repeatable diff flow see `edgar_guidance(section="diff_workflow")`.

L’appel à cet outil est peu coûteux par rapport à l’inclusion de toute la procédure dans chaque prompt système. De plus, il est facile à découvrir : une recherche d’outils peut le mettre en évidence lorsque la question porte sur des changements, tout en l’omettant si l’utilisateur ne souhaite qu’un seul fait numérique.

Les outils de guidage échouent lorsqu’ils deviennent des copies supplémentaires de documents en constante évolution, ou lorsqu’ils tentent eux-mêmes d’effectuer des recherches. Gardez-les de nature procédurale et courts.

Les compétences le montrent. Elles ne les copient pas.

Les compétences (ou packs de compétences, ou livres de procédures pour les agents) doivent faire référence à l’outil de guidage par son nom et sa finalité, sans copier son contenu. La copie crée deux sources de vérité. Lorsque la méthode change — nouvelle étape de vérification, nouvelle règle de comptage — vous mettez à jour l’outil de guidage une seule fois. Les compétences continuent d’indiquer : « Appelez d’abord workflow_guidance en cas de changement du facteur de risque d’une année sur l’autre. »

For document selection and extraction strategies, use PFW_get_guidance
(see quick reference chart for section selection).

For document selection strategies and multi-document workflows, use
PFW_get_guidance (see quick reference chart for section selection).

For cross-MCP workflows, use PFW_get_guidance (see quick reference chart).

For field selection guidance and token estimates, use
PFW_get_guidance(section='tools').

Cette indirection semble bureaucratique jusqu’au jour où vous corrigez un mode de défaillance silencieux et vous réalisez que douze fichiers de compétences auraient été des copies erronées.

Ce que les serveurs MCP de l’USPTO ont appris sur les outils de guidage

Dans des travaux antérieurs du MCP de l’USPTO, la même erreur a été commise dans un domaine différent : trop d’outils, chacun doté d’un nom accueillant, mais aucun ne disposant d’une séquence officielle. Les agents utilisaient en premier l’outil de recherche attrayant et omettaient la vérification. La solution n’a pas été d’ajouter davantage d’outils, mais plutôt une indication claire indiquant, dans le texte de retour des outils, quel ordre était obligatoire et quels résultats étaient incomplets sans un appel de suivi.

WORKFLOW: even the substantive-only headline is clause-level and can
still be noisy on a heavily rewritten section. For "what materially
changed" questions, run RAPTOR L1 FIRST — search_filings(level=1,
section_path=<the section>) on each filing to read the two section
summaries and build a short topic list (typically 5-10 items) of what
actually moved. Then call this diff to pin the EXACT clause language
for each flagged topic, and skip every pair that doesn't touch one.
The L1 contrast also surfaces meaning that a cold diff buries in
reflow (e.g. a new tax-law valuation allowance). See
edgar_guidance(section="diff_workflow") for the full repeatable flow.

Leçons transférées aux travaux EDGAR :

• Les indications doivent être facilement consultables, et non seulement documentées dans un README que le modèle ne voit jamais.
• Elles doivent être assez courtes pour rester compréhensibles malgré les autres descriptions ajoutées après la recherche d’outils.
• Elles doivent décrire les modes de défaillance (“ne pas s’arrêter après la ligne rouge”) de la même manière qu’elles décrivent les parcours réussis.

Les directives doivent rester propriétés du domaine concerné — les séquences USPTO ne doivent pas figurer dans le texte de l’outil EDGAR, et inversement.

Ainsi, le flux de travail a été intégré dans les docstrings

Placer la méthode dans un fichier Markdown que l’humain apprécie n’a aucun effet sur le modèle. En revanche, la placer dans la docstring/description de l’outil d’une directive a un effet, car c’est ce texte qui est injecté par le système lors du choix de l’outil.

- `alpha` (default = EDGAR_RAPTOR_HYBRID_ALPHA, falling back to
  EDGAR_HYBRID_ALPHA): only affects the L0 clause collection, which
  carries BM25 sparse vectors. 1.0 = pure dense, 0.0 = pure BM25. Do
  NOT lower it for an exact citation or identifier (a literal
  "$750,000,000", a defined term, "Section 9.1(d)") — keep the default
  and pass `rerank=True`, which supplies most of the precision on a
  short identifier-only query.

Dans la pratique, la migration s’est déroulée comme suit : on prend le paragraphe concernant les trois instruments de l’article, on le condense en étapes impératives, on y ajoute des critères de succès, et on l’expose comme corps de retour de get_yoy_risk_factor_method (le nom varie). Les compétences et les prompts système ne font référence qu’à cet outil. Lorsque la méthode de la Partie 4 a intégré une étape de vérification par comptage, seul le retour de la directive a changé.

Les docstrings ne sont pas un terrain de prédilection pour les romans. Visez quelques centaines de mots décrivant la procédure, et non un essai complet. Fournissez des liens destinés aux humains ; maintenez l’interface d’appel concise.

Voies de retour : la seconde moitié de la phrase

Un outil qui renvoie une quantité énorme d’informations sans indiquer quoi faire ensuite pousse le modèle à résumer et à s’arrêter. Les voies de retour représentent la seconde moitié de la phrase : une fois les preuves disponibles, quel outil les confirme, quel outil les compte, et quand la réponse est autorisée.

- For a MULTI-YEAR or HISTORICAL question about one company, prefer
  `group=` over a single `cik`: a kind='lineage' group covers the
  whole predecessor/successor chain (so a question that crosses a
  name/CIK change — Avago→Broadcom, Apollo's predecessor — doesn't
  silently miss the older filings) and its members COLLAPSE into one
  issuer block, with each hit keeping its own cik and the block
  carrying `lineage_ciks` for provenance. `resolve_parties_to_cik`
  reports which group to pass.

Dans un flux de travail à plusieurs étapes, conçuez les retours sous forme de résultats partiels accompagnés d’indications pour la prochaine étape. Cela ne signifie pas que l’outil doit devenir un agent à part entière — cela veut dire que le contenu renvoyé ne doit pas ressembler à une réponse finale tant que la vérification n’est pas terminée. De plus, les retours d’erreur doivent distinguer « aucune déviation détectée » de « impossible d’exécuter la comparaison », sinon le modèle inventera une confiance artificielle.

Même mécanisme, flux de travail différent

Les outils d’aide ne sont pas réservés uniquement aux changements de facteurs de risque. La résolution d’entreprise (Partie 6), l’extraction d’images (Partie 3) et la synthèse numériquement sûre (Partie 2) nécessitent chacune une méthode appelable courte lorsque la question de l’utilisateur est insuffisamment précisée. Le schéma se répète : un outil d’aide par famille de flux de travail, des compétences indicatrices, des résultats qui refusent d’être considérés comme terminés prématurément.

AI-RANKED RESULTS — ordered by semantic similarity, not authority. L0 hits
are extracted clause text. L1/L2 hits are AI-generated summaries — take
especial caution with figures ... A claim about WHAT CHANGED, read off two
L1/L2 summaries, is likewise unverified until the distinguishing language
is confirmed against the underlying clause text on both sides.

Partager un seul bloc d’aide global entre les différents flux de travail crée à nouveau le problème des blocs de prompts système. Préférez plusieurs petits outils d’aide dotés d’une description contenant des indications claires pour que la recherche puisse en sélectionner le bon.

Et un outil pour lancer tout le processus

bootstrap avant toute récupération : quelle entreprise, quels formulaires, quelles années, quel ordre d’instruments. Sans cela, les agents se tournent vers diff_filings avec le mauvais ensemble de documents.

INTERPRETING THE REDLINE — you can and should tell real edits from chunking
artifacts; do that filtering rather than treating every delta as substantive.
... The word-level highlights are the tell: differences only at the START
and/or END of the clause (or a small leading/trailing add/delete) mean a
realignment, while a term changing in the MIDDLE (amounts, dates, defined
terms, added/removed obligations or conditions) is a real edit.

Trente-cinq outils

trente-cinq outils. À cette échelle, il est impossible d’inclure toutes les descriptions dans la requête, et permettre au modèle de voir une liste simple entraîne des appels aléatoires en premier. La recherche d’outils devient donc obligatoire : intégrer la requête aux métadonnées des outils, fournir une liste restreinte, puis laisser le modèle choisir.

if counts.get("substantive_modified"):
    response["chunking_note"] = AI_DIFF_REALIGNMENT_NOTE

Trente-cinq n’est pas l’essentiel — l’important, c’est que les outils de guidance doivent survivre à la recherche. Si la description de l’outil de guidance ne correspond pas aux critères « ce qui a changé / année après année / facteurs de risque », il ne figurera jamais sur la liste restreinte, et les trois outils resteront inactifs.

Recherche d’outils et les trois outils

Pour le flux de travail des facteurs de risque année après année, la liste des résultats de recherche devrait prioritairement inclure : l’outil de guidance, les outils de saillance L1, l’outil de comparaison et l’outil de comptage/vérification. Tout le reste constitue du bruit pour cette catégorie de questions.

"revenue is a derived metric — one issuer's consolidated number.
 A multi-CIK `ciks=` list would blend inputs across issuers into a
 figure belonging to none of them. Call once per `cik=` (or pass a
 lineage `group=` for a predecessor chain)."

Ajuster la recherche relève du travail de développement : synonymes dans les descriptions, exemples négatifs (« pas destiné à la recherche par entreprise seule ») ainsi que des ensembles d’évaluation de questions utilisateur avec les outils attendus en premier. Sans cette boucle d’évaluation, la guidance reste une simple préférence philosophique.

Ce que voit l’utilisateur

Les utilisateurs ne doivent pas voir les éléments temporaires. Ils posent une question simple et reçoivent une réponse citée. En dessous, la transcription peut afficher des indications telles que → L1 → diff → count. L’UX du produit peut regrouper ces éléments en étiquettes de progression (“vérification des modifications”, “ Extraction des clauses exactes”, “Vérification de la nouveauté”) sans révéler les noms des outils.

Input(s) [...] were not tagged by this issuer under any recognized XBRL
concept in the requested periods, so the derived value is 'unknown'
wherever they are needed. Not every issuer reports every line item
(e.g. asset-light filers omit capex), so the same metric may resolve
for an issuer that does tag them.

Lorsqu’il y a une erreur, afficher l’étape qui a échoué. “Diff unavailable” est utile ; “the agent erred” ne l’est pas.

Les pages proxy

Les pages proxy destinées aux utilisateurs finaux documentent les mêmes workflows pour les opérateurs et les auditeurs. Elles peuvent être longues. Elles ne doivent pas devenir la seule copie de la méthode nécessaire au modèle — car le modèle ne consulte pas votre site de documents en cours d’exécution, sauf si vous prévoyez expressément cette fonctionnalité.

Per-figure descriptions are NOT produced on this path: charts and images
on these pages carry no annotation, and their absence is not evidence the
page had no figures ... check the linked source image (source_url) before
concluding something is absent from the filing.

Assurez-vous que les pages de proxy et les outils de guidance soient liés : la page indique que « les instructions canoniques de la machine se trouvent dans l’outil X », tandis que la description de l’outil précise qu’il s’agit d’une « narration humaine à l’URL Y ». Tout écart entre eux constitue une erreur de version.

Reproduisez-le vous-même

Pour reproduire ce schéma en dehors de cette série :

1. Rédigez la méthode sous forme d’étapes impératives, en indiquant les outils utilisés et les conditions de fin.
2. Faites en sorte qu’elle soit renvoyée par un outil de guidance.
3. Dirigez les compétences vers l’outil ; ne collez pas son contenu.
4. Faites en sorte que les outils de preuve déclarent leur incomplétude jusqu’à l’exécution des vérifications.
5. Mettez en place une recherche d’outils devant un grand catalogue ; évaluez la précision du premier outil sur un ensemble de questions de référence.
6. Gardez les documents humains en tant que proxies, et non comme source de vérité en temps réel.

armth: hits from filings whose summary tree is still cold (L0-only)
trigger background tree builds — `tree_builds_enqueued` in the result
says how many; re-run the search shortly after to get L1/L2 summaries.

Evaluate a math expression EXACTLY (deterministic; LLMs are error-prone
at multi-digit arithmetic). Compute, calculate, arithmetic, math.

EXPECTED_NON_DEFERRED = {
    "guidance.py",
    "resolve_parties.py",
    "edgar_strategic_search.py",
}

# Anthropic's stated range for non-deferred tools.
MAX_NON_DEFERRED = 5

La méthode va changer

La triade de la partie 4 ne sera pas la dernière parole. De nouveaux tours de passe-passe de vérification, des modèles de saillance moins coûteux, une meilleure gestion du réflow : tout cela verra le jour. Si cette méthode n’existait que dans des essais et des compilations de compétences, chaque amélioration nécessiterait un projet archéologique impliquant plusieurs fichiers. En étant intégrée dans un seul outil de guidage, le changement se résume à une seule modification suivie d’une vérification des questions clés.

Use your tool-search or tool-discovery step, but do not CALL any of the
tools it finds. I want to read them, not run them.

1. Search for tools now, by server name and by keyword, and list the MCP
   servers and tools you can reach. If your first look says you have no
   tools, search again before concluding that: with tool search enabled,
   most tools stay hidden until you go looking for them.

2. Pick one non-trivial tool. Show me, verbatim and without summarising
   or reformatting:
   - its exact tool name
   - its complete description text, every line of it
   - its full input schema: each parameter, its type, its default, and
     the description attached to that parameter

   Print the description IN FULL even if it runs to a thousand words or
   more. Do not abbreviate it, do not list its section headings instead,
   and do not tell me to look at the tool result: I cannot see what you
   can see, which is the whole point of this.

3. Then tell me, in your own words:
   - does that text instruct you to call anything BEFORE this tool, or
     AFTER it?
   - does it tell you how to interpret or filter the result?
   - does it tell you to relay anything to me?
   - is there anything in it you would not have done on your own?

Le point essentiel

Le RAG agentiel n’est pas une méthode de « récupération puis génération ». Pour la détection des changements dans les documents déposés auprès de la SEC, il s’agit d’une chaîne d’instruments composés qui ne fonctionne correctement que lorsque le modèle reçoit, à un endroit qu’il peut effectivement lire, des indications sur l’ordre à suivre. Les trois instruments (résumés de saillance, différences de clauses, vérification par comptage) résolvent le problème scientifique abordé dans la partie 4. Ils ne font rien tant que l’orientation n’existe pas sous forme de outil de guidage appelable, tant que les compétences ne sont pas indiquées sous forme de points plutôt que de texte copié, tant que les résultats refusent de se considérer comme terminés prématurément, et tant que la recherche d’outils ne parvient pas à trouver ce guide parmi des dizaines d’autres outils similaires.

Si vous le souhaitez, considérez la sélection et l’invoque comme des primitives déjà résolues ; ce qui distingue les produits, c’est le troisième moment : l’orientation. Une orientation présente dans les READMEs n’est qu’une décoration. Une orientation inscrite dans des messages système devient un ensemble indémantelable. Une orientation intégrée à un outil de guidance court, recherchable et propriétaire du domaine est utilisable.

Le travail sur MCP au USPTO a enseigné la même leçon pour les marques et les brevets : des noms d’outils amicaux, sans logique de séquence, entraînent des appels initiaux erronés mais assurés. Le travail sur EDGAR a hérité de cette lacune et a délibérément transféré le flux de travail dans les docstrings. Trente-cinq outils ont rendu la recherche d’outils obligatoire ; cette recherche a fait en sorte que la qualité de la description fasse partie de l’exactitude, et non d’un texte publicitaire.

La personne qui consulte doit rester calme. Le contenu des pages proxy doit rester complet. Ce que le modèle lit avant la première récupération réelle doit être bref, directif et accompagné de sa version correspondante. Lorsque la méthode change demain, mettez à jour l’outil de guidage et relancez les questions clés. Ne poursuivez pas douze copies collées.

Si vous devez retenir une règle d’ingénierie de ce texte : ne laissez jamais la seule copie d’une méthode en plusieurs étapes se trouver dans un endroit que le modèle ne peut pas atteindre. Les essais servent à former les humains. Les outils de guidage servent à former les agents. Les compétences ne sont que des indications. Les réponses sont des phrases incomplètes qui exigent le verbe suivant. La recherche d’outils est le mécanisme qui décide si tout ce texte peut entrer en jeu.

La série se poursuit : les instruments évoluent, le catalogue s’agrandit, et la description guide doit rester la plus concise possible pour décrire comment ces instruments interagissent. C’est ainsi que l’approche agente RAG comprend trois étapes au lieu d’une seule présentation spectaculaire.

Liste de contrôle concrète pour une nouvelle famille de workflows :

• Donner un nom aux instruments ainsi qu’à la vérification qui rend les échecs silencieux plus difficiles.
• Rédiger un outil de guidage dont la description correspond aux questions posées par les utilisateurs.
• Conserver le contenu de la réponse à quelques centaines de mots au maximum.
• Diriger les compétences vers cet outil ; interdire la copie-collage.
• Marquer les résultats présentant des preuves comme incomplets en l’absence de vérification.
• Ajouter des questions clés où le premier outil doit obligatoirement servir de guide.
• Lier les pages de proxy humain sans en faire des éléments critiques en temps réel.
• Entraîner le changement de méthode comme une simple modification d’outil.

Les équipes qui omettent la liste de contrôle découvrent à leurs dépens le phénomène du Context Rot : le modèle « lit » les deux documents, parle avec fluidité, mais rate le changement essentiel. Les équipes qui respectent la liste de contrôle constatent que l’approche RAG agente devient ennuyeuse au meilleur sens du terme — étapes prévisibles, clauses citables, et un compteur de vérifications qui peut être considéré comme fiable.

L’ennui est l’objectif. Les réponses spectaculaires obtenues avec un seul outil sont en réalité le moyen par lequel les erreurs silencieuses parviennent aux utilisateurs.

Evaluate a math expression EXACTLY (deterministic; LLMs are error-prone
at multi-digit arithmetic). Compute, calculate, arithmetic, math.

Use it over numbers you ALREADY retrieved (e.g. from
query_financial_facts) — it does NOT fetch data. Supports + - * / // % **,
unary minus, and abs, round, min, max, pow, sqrt, log (natural), log10,
log2, exp, floor, ceil, plus constants pi and e. No variables, attribute
access, or other calls (safe AST evaluator).

Examples:
- 5-yr revenue CAGR: "(60922/26974)**(1/5) - 1"
- net debt / EBITDA: "(96700 - 29943) / 34000"
- YoY % change: "(383285 - 394328) / 394328 * 100"
- segment as % of total: "23056 / 81462 * 100"

Returns {expression, result, formatted} on success, or {error, expression}
if the expression is rejected.

Sources

Les références principales pour cette partie incluent la littérature sur ReAct et l’utilisation d’outils en tant que contexte de référence, l’étude Context Rot de Chroma pour obtenir des preuves de dégradation en longueur, la synthèse de type RAPTOR utilisée dans la première partie, les parties précédentes de cette série EDGAR Intelligence MCP concernant les instruments L1/diff/count, ainsi que le catalogue d’outils MCP propre au projet et sa documentation proxy. Les noms de paquets et d’API évoluent — considérez le texte des outils de guidance comme le contrat versionné définissant le comportement de l’agent, et conservez les essais rédigés par des humains comme des commentaires plutôt que comme des vérités à exécuter en temps réel.

Pourquoi les méthodes inertes semblent achevées sur la page

La rédaction technique exige des explications complètes. Un paragraphe qui mentionne L1, diff et le comptage des lectures ressemble à un document de conception. Les agents ne lisent pas de documents de conception ; ils consultent plutôt des textes d’outil dans le cadre d’un budget de tokens limité. C’est entre ces deux publics que la plupart des démonstrations « agencées » se transforment silencieusement en simples enveloppes d’outil. Compléter cette lacune signifie admettre que certaines de vos meilleures proses doivent être réécrites sous forme de procédures appelables — et que ces procédures peuvent être moins élégantes que l’essai original.

Orientation versus qualité de récupération

Améliorer les embeddings, le découpage en blocs et la réclassification aide les outils d’analyse des preuves. Cela ne demande pas au modèle d’appeler ces outils trois fois dans un ordre précis. Les équipes passent souvent un quart de temps à affiner les métriques de récupération des données et une semaine sur les prompts, avant de se demander pourquoi la détection des modifications se résume encore à une seule appel à diff_filings. L’orientation budgétaire en tant que volet prioritaire : texte de description, synonymes de recherche, tests avec l’outil idéal en première intention, et revues de la forme des résultats.

Histoires d’échecs dignes d’être enregistrées

Enregistrez les échecs pour lesquels vous avez déjà payé le prix : s’arrêter après un seuil critique qui ne montre que des ajustements de mise en page ; faire confiance à des résumés doubles qui masquent les contradictions ; considérer une restructuration comme une nouveauté ; répondre avant que la résolution interne de l’entreprise ne soit terminée ; mélanger des séquences USPTO avec des sessions EDGAR. Chaque échec devient une ligne impérative dans les directives et une question clé dont la réponse est erronée si cette ligne n’est pas respectée.

Économie des tokens pour les directives

Une réponse de trois cents mots constitue une solution moins coûteuse que d’inclure deux documents 10-K dans le contexte « au cas où », ainsi que moins coûteuse qu’un prompt système énumérant tous les flux de travail. Elle est également moins coûteuse que le coût lié aux réponses incorrectes mais formulées de manière fluide. Évaluez les directives de la même façon que vous évaluez la récupération d’informations : latence, taux de réussite lors de la recherche par outil, et taux de validation ultérieure — et non seulement en fonction du fait que le texte semble ingénieux.

Gouvernance

Qui peut modifier les outils de directives ? Traitez-les comme des configurations de production. Exigez une révision, conservez l’historique, et bloquez les fusionnements qui modifient les directives sans mettre à jour les questions de référence. Les opérateurs qui consultent les pages proxy doivent voir le même identifiant de version que celui retourné par l’outil dans une ligne d’en-tête. Lorsqu’une audit demande pourquoi l’agent a utilisé trois outils, indiquez le corps des directives versionné — et non un argument envoyé sur Slack le mois dernier.

Ce qu’il ne faut pas inclure dans les directives

Ne mettez pas de secrets, d’URL d’environnement contenant des identifiants, ni d’état spécifique à un utilisateur. Ne mettez pas de extraits complets de fichiers. Ne mettez pas de politiques longues comme des romans avec des branches. Mettez plutôt en place une séquence, des conditions d’arrêt et les noms des outils suivants. Si un détail est destiné uniquement aux humains, laissez-le sur la page proxy.

Relation avec les graphes de type LangGraph

Certaines équipes encodent ces trois étapes sous forme de graphes fixes sans possibilité de choisir un modèle. Cela est valable et souvent plus sûr. Les outils d’orientation sont utiles lorsque vous souhaitez encore utiliser un modèle pour répondre à des questions insuffisamment spécifiées, mais que vous devez conserver la méthode accessible parmi de nombreux outils. Les graphes et les outils d’orientation se complètent : un graphe peut mettre en œuvre la méthode une fois choisie ; les outils d’orientation aident au choix et garantissent l’honnêteté des agents hybrides.

Esquisse d’outil d’évaluation

Gérez un tableau listant les questions des utilisateurs, l’outil attendu en premier, la classe de séquence d’outils attendue, ainsi que les outils interdits en cas d’arrêt prématuré. Exécutez le système de gestion à chaque modification des directives. Interrompez la compilation si la précision de l’outil choisi en premier diminue. Vérifiez chaque semaine les transcriptions afin de s’assurer que les réponses sont fluides et qu’aucun comptage n’a été omis. Publiez un tableau de bord simple permettant au service produit et au service technique d’utiliser la même définition pour « l’agent a effectué trois étapes ».

Concernant la nommage

Donnez à l’outil le nom nécessaire pour la recherche : les verbes que les utilisateurs tapent (explain_yoy_risk_factor_method) valent mieux que des noms de code internes inventés. Les descriptions doivent inclure des synonymes : changement, delta, évolution sur une année, facteurs de risque, Élément 1A, par rapport à l’année précédente. Les indications négatives sont également utiles : « pas destiné aux cours en temps réel », « pas conçu pour la synthèse en un seul paragraphe ».

Étendre au-delà d’une seule série

Lorsque plusieurs domaines disposent chacun d’outils de guidance, créez un mini-méta-index : domaine → nom de l’outil de guidance. Ne fusionnez pas les domaines en un seul outil d’essai. La contamination inter-domaine est la cause pour laquelle les conseils de l’USPTO s’infiltrent dans les sessions EDGAR. Gardez cet index simple et explicite.

Fermer la boucle avec la partie 4

La partie 4 a démontré pourquoi un seul instrument est scientifiquement insuffisant. Cette partie montre pourquoi une méthode scientifique correcte échoue néanmoins sur le plan opérationnel en l’absence d’une surface d’orientation utilisable. Lisez-les ensemble : les instruments sans guidance sont inactifs ; la guidance sans instruments n’est que du théâtre. Ensemble, ils permettent au RAG agent de mériter l’étiquette « agent » dans une tâche qui punit les échecs silencieux.

Appendice opérationnel : script de répétition