Cómo Mendral redujo los costos de LLM al actualizar a Opus: Patrón de Triaje, Acceso SQL y Arquitectura de Subagentes

Mendral publicó recientemente detalles sobre cómo actualizaron a Opus 4.6 para el análisis de fallos de CI mientras reducían los costos generales de LLM en comparación con su configuración anterior con Sonnet 4.0. La clave es una arquitectura que separa la clasificación de la investigación y utiliza subagentes baratos para el trabajo pesado.

Arquitectura: clasificador barato, planificador caro

De aproximadamente 4000 fallos de CI analizados, 3187 eran duplicados: una prueba inestable conocida, un problema de infraestructura o un fallo de red. Despertar un modelo caro para eso es un desperdicio. Pero la deduplicación no es determinista: el mismo trabajo puede fallar por diferentes razones. Su solución es un patrón de clasificador:

• Un agente Haiku maneja la tarea específica: decidir si un fallo ya está registrado. Utiliza coincidencia exacta y búsqueda semántica (pgvector) contra mensajes de error conocidos. Dos cadenas diferentes como operator does not exist bigint character varying y migration type mismatch on installation_id son la misma causa raíz: la búsqueda semántica lo detecta.
• Ante la duda, Haiku escala a Opus 4.6. Un falso positivo cuesta poco; un falso negativo pierde un error real.
• 4 de cada 5 fallos nunca llegan a Opus. Una coincidencia del clasificador cuesta aproximadamente 25 veces menos que una investigación completa.

Deja que los agentes obtengan contexto, no lo envíes

En lugar de meter registros de más de 200 000 líneas en los prompts, los agentes reciben una interfaz SQL a ClickHouse. Hay una tabla sin procesar (github_logs, una fila por línea de registro) y vistas materializadas con datos preagregados: tasas de fallo por flujo de trabajo, tiempos de trabajo, recuentos de resultados. La mayoría de las investigaciones comienzan con las vistas para reducir el alcance y luego profundizan en los registros sin procesar. Si una consulta devuelve demasiadas filas, el sistema trunca y sugiere una vista más específica. Si los registros aún no se han ingerido, los agentes recurren a la CLI de GitHub.

Los modelos caros planifican, los baratos ejecutan

Opus forma una hipótesis y genera subagentes Haiku limitados a un nivel de profundidad, sin expansión ilimitada. Cada subagente recibe un prompt de Opus: exactamente qué buscar y cómo. Ejemplo de un caso real:

Tres trabajos de CI de Storybook fallaron en el mismo commit, fallando en pnpm install. Opus envió un subagente para obtener los mensajes de error de ese paso. ClickHouse aún no tenía los registros, por lo que el subagente usó la CLI de GitHub y devolvió: gyp ERR! not found: make — [email protected] no pudo compilar porque make no estaba en el ejecutor. Opus luego consultó ClickHouse para la tendencia de fallos durante 14 días, encontró el punto de inflexión y escaló. Los prompts de los subagentes son explícitos: "Obtén los registros de CI de esta ejecución. Devuelve los mensajes de error exactos del paso pnpm install, la salida de error completa, especialmente las últimas 50-100 líneas."

Para quién es esto

Equipos que construyen agentes impulsados por LLM para depuración de CI o cualquier tarea donde el tamaño del contexto y el costo sean preocupaciones.