Infraestructura primero
Un modelo es un motor. La mayoría de los "problemas de modelo" se deben a una infraestructura faltante: nada define una salida correcta, nada verifica los cambios, nada limita el gasto, los datos no tienen definiciones acordadas, las acciones no tienen aprobación y no hay rastros para encontrar la llamada incorrecta. Audita eso antes de tocar el modelo.
1. Reproduce el síntoma con evidencia, no con corazonadas
- Lee el código del agente que toca el síntoma: el bucle, las definiciones de herramientas, el ensamblaje del prompt, el acceso a datos, las herramientas con efectos secundarios.
- Lee los registros/trazas/transcripciones existentes. Agrúpalos (por conversación, por herramienta, por error): quién gasta los tokens, qué llamadas fallan, qué respuestas son incorrectas. Generalmente unos pocos valores atípicos dominan.
- Indica la causa raíz como un mecanismo con evidencia (archivo:línea, IDs de registro, números que calculaste). "El modelo es malo" no es un mecanismo.
Mecanismos comunes:
- Quema de tokens: bucle sin número máximo de iteraciones, reintento en un error determinista, historial completo o resultado enorme de herramienta reenviado en cada turno, sin caché de contexto estable.
- "Alucinación": el agente usó fielmente una fuente ambigua o incorrecta (dos tablas/campos con el mismo nombre y significado diferente, documentación desactualizada). Vuelve a calcular ambos números tú mismo para demostrarlo.
- Fragilidad: cambios en el prompt enviados sin un conjunto de regresión; comportamiento que solo el autor verificó manualmente.
2. Puntúa las seis partes de la infraestructura
Para cada una, marca presente / parcial / ausente con la evidencia que encontraste:
| Parte | Presente significa |
|---|---|
| Conjunto de datos de oro | ~20+ casos con respuestas/restricciones esperadas, extraídos de tráfico real, incidentes y casos límite |
| Juez | Verificaciones deterministas primero (números, reglas de política, contenido prohibido), rúbrica LLM solo para lo que el código no puede verificar; se ejecuta en cada cambio de prompt/modelo/herramienta |
| Gobernanza de costos | Límites duros de tokens/costo por usuario y por flujo de trabajo, iteraciones máximas por ejecución, parada elegante con un mensaje |
| Capa de datos | Credenciales de solo lectura para consultas, un diccionario de datos que define cada métrica/campo que el agente puede usar |
| Seguridad de acciones | Las acciones irreversibles o externas (enviar, pagar, eliminar, escribir, reembolsar) son reversibles o están controladas por aprobación humana |
| Trazabilidad | Cada llamada al modelo y herramienta registrada con ID de conversación, flujo de trabajo, entrada, salida, tokens, costo, latencia, error |
3. Decide antes de construir
- Nunca recomiendes un cambio de modelo sin evidencia de evaluación. Si alguien pregunta "¿deberíamos cambiar de modelo?", la respuesta es: arregla el mecanismo, luego ejecuta el conjunto de datos de oro en ambos modelos y compara calidad y costo. Indica lo que se espera ahorrar solo con la corrección, con tus números.
- Nunca apruebes el envío de un cambio de prompt/agente sin una ejecución del conjunto de datos de oro. Si existen salidas registradas, evalúalas tú mismo contra las respuestas esperadas e informa las fallas por ID de caso.
- Las brechas de seguridad (efectos secundarios sin control, acceso de escritura en una ruta de lectura, fuga de datos internos) son bloqueantes, incluso cuando nadie preguntó sobre ellas.
4. Construye la infraestructura mínima, en este orden
- Detén la hemorragia: iteraciones máximas, sin reintento en errores no transitorios, truncar/resumir la salida grande de herramientas, límite duro de costo por ejecución.
- Controla los efectos secundarios: paso de aprobación o modo borrador para herramientas irreversibles; conexión de solo lectura para herramientas de consulta.
- Archivo de conjunto de datos de oro (
evals/golden.jsonlo similar): entrada, respuesta esperada o restricciones, fuente (ID de registro / incidente / cláusula de política). Incluye los casos que acaban de fallar. - Script de juez que ejecuta el conjunto de datos de oro e imprime aprobado/fallado por caso más totales. Verificaciones deterministas antes de la calificación con LLM.
- Diccionario de datos para cada métrica que el agente reporta (definición, tabla/campo de origen, exclusiones).
- Campos de trazabilidad listados anteriormente, si faltan.
Escribe archivos reales, no una descripción de archivos. Ejecuta lo que se pueda ejecutar e informa el resultado.
5. Informe
- Respuesta de una línea a la pregunta realmente formulada (ej. "No cambies de modelo todavía: 3 ejecuciones atascadas en un bucle de reintento gastaron el 71% de los tokens").
- Causa raíz con evidencia y números.
- Tarjeta de puntuación de infraestructura (las seis partes).
- Lo que cambiaste o creaste, y lo que ejecutaste.
- Riesgos bloqueantes, luego una lista corta de próximos pasos priorizados.
Crédito
El método que sigue esta Habilidad proviene de una publicación pública de Mark Ajzenstadt (@mardehaym): https://x.com/mardehaym/status/2099562230647804152. El argumento es suyo; el procedimiento, la redacción y la evaluación aquí son propios de Edge, y el autor no los revisó.