LLMs para el juicio, código para contar: escalando a 500K sensores con 300x menos tokens

Los ingenieros de Phaidra tuvieron que hacer que un LLM razonara sobre 500,000+ nombres de sensores en centros de datos a escala de gigavatio, y cada enfoque ingenuo — vector RAG, LLM puro, sharding paralelo — falló en recuperación o alucinó equipos fantasma. Su solución es un patrón arquitectónico limpio: el LLM planifica y juzga, el código determinista realiza la búsqueda y operaciones de conjunto, y el costo escala con la profundidad de la jerarquía en lugar del número de instancias. Los números de producción son el mejor argumento: de 116M tokens y 30% de precisión a 390K tokens y 100% de precisión en 66 casos reales.

• Diseña el sistema para escalar con la profundidad de la jerarquía (centro de datos → pasillo → rack → GPU), no con el número de instancias — su linearizador de rutas produce el mismo resumen de tamaño para 64 GPUs o 460,000.
• El LLM produce planes estructurados (qué recopilar, alcance, filtros) en lugar de procesar nombres crudos, manteniendo el costo constante en ~9,000 tokens por consulta independientemente del tamaño del sistema.
• Su enfoque antiguo se degradó de 80% de precisión en 64 GPUs a 30% en 460,000; el enfoque híbrido alcanzó 100% con 300x menos tokens.
• Una inversión útil del marco de Karpathy: los sistemas nativos de IA deberían comenzar en Software 3.0 para demostraciones rápidas, luego madurar hacia 1.0 determinismo para producción.

Un desglose técnico apropiado de dónde proviene realmente la latencia de LLM, con experimentos en lugar de especulaciones. La lección central: prefill (procesar tu prompt) es paralelo y vinculado a computación, mientras que decode (generar tokens) es secuencial y vinculado a memoria — y decode es casi siempre tu cuello de botella. Si estás construyendo productos de agentes, solo la sección de multiplicación de costos justifica el tiempo.

• Generar un token de salida cuesta aproximadamente 300x más tiempo que procesar un token de entrada — limita max_tokens antes de gastar semanas optimizando tu pipeline de recuperación.
• En un bucle de agente de 5 pasos, el costo se multiplicó 11.9x porque cada paso reenviaba el historial completo anterior; la gestión de contexto es la diferencia entre un producto viable y uno eliminado por su factura.
• Las solicitudes pequeñas desperdician GPU: 143 tokens/seg en 25 tokens vs 2,271 tokens/seg en 1,205 tokens — el continuous batching existe para arreglar exactamente esto.
• El calentamiento de GPU se omite rutinariamente en producción y los arranques en frío destruyen silenciosamente los SLAs.

Litt nombra el problema que la mayoría de nosotros sentimos pero no hemos articulado: los agentes escriben código más rápido de lo que construimos la comprensión del mismo, y esa brecha — la que él llama deuda cognitiva — eventualmente te bloquea de contribuir ideas. En lugar de una lamentación, ofrece tres técnicas concretas que puedes adoptar esta semana: documentos de explicación generados por IA con cuestionarios, 'micro-mundos' personalizados que visualizan tu sistema específico, y espacios compartidos donde humanos y agentes construyen comprensión colectiva.

• La deuda cognitiva funciona como la deuda técnica: deja que tu comprensión del sistema se degrade lo suficiente y pierdes la capacidad de participar creativamente, no solo de verificar la corrección.
• Ten agentes escribiendo código desechable cuyo propósito no sea envío — depuradores personalizados y simulaciones efímeras construidas puramente para que entiendas mejor tu propio sistema.
• Los cuestionarios generados automáticamente al final de las explicaciones de IA actúan como un gobernador de velocidad: no puedes continuar hasta que hayas absorbido realmente el material.
• Estructura las explicaciones de IA deliberadamente: contexto primero, intuición antes de detalle, y 'diffs de código literario' presentados en orden de lectura en lugar de orden de archivo.

Una charla corta y densa sobre un modo de fallo que todos los constructores de agentes alcanzan: los agentes producen más trabajo del que alguien puede revisar, y 'hecho' se convierte silenciosamente en una mentira que el sistema se cuenta a sí mismo. Dotta reenmarca la finalización como un conjunto de aserciones — artefacto producido, evidencia adjunta, verificador separado del autor, propietario nombrado, siguiente paso definido — y muestra cómo el modelo de liveness de Paperclip mantiene el trabajo fluyendo sin ahogar a los humanos en colas de revisión. Termina con una lista de verificación que puedes aplicar a tu propio pipeline de agentes independientemente del arnés.

• 'Hecho' no es un booleano; es una escalera — el productor lo afirma, un revisor lo verifica, se valida contra estándares, una persona autorizada lo aprueba, y sobrevive a condiciones del mundo real.
• El compromiso central: demasiada autonomía produce basura, demasiada revisión produce colas improcesables. Diseña para liveness con bloqueadores explícitos, no aprobaciones generales.
• Separa el verificador del autor — idealmente con un modelo diferente — y exige evidencia explícita de finalización en lugar del auto-informe del agente.
• Dale a los agentes sus propias herramientas de verificación (navegadores, capturas de pantalla, ganchos personalizados) para que prueben su trabajo antes de que un humano lo vea.

Cinco técnicas para reducir alucinaciones de agentes que viven en código, no en prompts — que es exactamente el lugar correcto para ellas. Fuentes demuestra cada una: selección semántica de herramientas vía búsqueda vectorial, GraphRAG para consultas que RAG simple falla, una cadena de agente validador/crítico, y reglas de negocios implementadas como ganchos que interceptan llamadas de herramientas para que no se pueda hablar alrededor. El tercio final es material de producto AWS; los primeros 50 minutos son transferibles a cualquier stack.

• Filtrar herramientas con búsqueda vectorial antes de enviarlas al modelo reduce el consumo de tokens de ~3,000 a ~300 por llamada — y swap_tools mantiene las conversaciones largas delgadas.
• GraphRAG supera a RAG tradicional en agregaciones, conteos y razonamiento multi-salto porque las consultas Cypher devuelven resultados computados en lugar de muestras de texto.
• Las reglas de negocios como ganchos a nivel de código que interceptan llamadas de herramientas son inquebrantables; las mismas reglas como instrucciones de prompt son meramente sugerencias.
• Los guardrails en tiempo de ejecución pueden dirigir en lugar de bloquear: el agente se autocorrige y completa la tarea (por ejemplo, dividir una reserva de 60 huéspedes en habitaciones) en lugar de fallar completamente.