La Marcha de los Nueve de Karpathy muestra por qué el 90% de confiabilidad de la IA no es suficiente

“Cuando recibes una demostración y algo funciona el 90% de las veces, son solo las primeras nueve”. – Andrej Karpatia

El “Marcha de los Nueve“enmarca una realidad de producción común: se puede lograr el primer 90% de confiabilidad con una demostración sólida, y cada nueve adicionales generalmente requiere un esfuerzo de ingeniería comparable. Para los equipos empresariales, la distancia entre “funciona normalmente” y “opera como software confiable” determina la adopción.

Las matemáticas compuestas detrás de la Marcha de los Nueve

“Cada nueve es la misma cantidad de trabajo”. -Andréj Karpathy

Los flujos de trabajo agentes exacerban los fallos. Un flujo de negocios típico podría incluir: análisis de intención, recuperación de contexto, planificación, una o más llamadas a herramientas, validaciónformateo y registro de auditoría. Si un flujo de trabajo tiene n pasos y es probable que cada paso tenga éxito pagEl éxito de un extremo a otro es aproximadamente p^n.

En un flujo de trabajo de 10 pasos, el éxito de un extremo a otro aumenta debido a los fallos de cada paso. Las interrupciones correlacionadas (autenticación, límites de velocidad, conectores) dominarán a menos que imponga dependencias compartidas.

Definir la confiabilidad como SLO mensurables

“Tiene mucho más sentido dedicar un poco más de tiempo a ser más concreto en tus instrucciones”. – Andrej Karpatia

Los equipos logran mejores resultados al convertir la confiabilidad en objetivos mensurables y luego invertir en controles que reduzcan la variación. Comience con un pequeño conjunto de SLI que describen el comportamiento del modelo y el sistema circundante:

• Tasa de finalización del flujo de trabajo (éxito o escalamiento explícito).

• Tasa de éxito de llamadas a herramientas dentro del tiempo de espera, con validación estricta del esquema en entradas y salidas.

• Tasa de salida válida para el esquema para cada respuesta estructurada (JSON/argumentos).

• Tasa de cumplimiento de políticas (PII, secretos y restricciones de seguridad).

• p95 Latencia de extremo a extremo y costo por flujo de trabajo.

• Tasa de respaldo (modelo más seguro, datos almacenados en caché o revisión humana).

Establezca objetivos de SLO por nivel de flujo de trabajo (bajo/medio/alto impacto) y administre un presupuesto de errores para que los experimentos permanezcan controlados.

Nueve palancas que suman nueves de forma fiable

1) Limite la autonomía con un diagrama de flujo de trabajo explícito

La confiabilidad aumenta cuando el sistema tiene estados acotados y un manejo determinista de reintentos, tiempos de espera y resultados terminales.

• Las llamadas de plantilla se ubican dentro de una máquina de estado o DAG, donde cada nodo define las herramientas permitidas, el número máximo de intentos y un predicado de éxito.

• Conserve el estado con claves idempotentes para que los reintentos sean seguros y depurables.

2) Hacer cumplir los contratos a través de las fronteras

La mayoría de los fallos de producción comienzan como una desviación de la interfaz: JSON con formato incorrecto, campos faltantes, unidades incorrectas o identificadores inventados.

• Utilice JSON Schema/protobuf para cada salida estructurada y valídelo en el lado del servidor antes de ejecutar cualquier herramienta.

• Utilice enumeraciones, ID canónicos y normalice el tiempo (ISO-8601 + zona horaria) y las unidades (SI).

3) Validadores de capa: sintaxis, semántica, reglas de negocio.

La validación del esquema captura el formato. Las comprobaciones de reglas semánticas y comerciales evitan respuestas plausibles que rompan los sistemas.

• Comprobaciones semánticas: integridad referencial, límites numéricos, comprobaciones de permisos y uniones deterministas por ID cuando estén disponibles.

• Reglas comerciales: aprobaciones para acciones de escritura, restricciones de residencia de datos y restricciones a nivel de cliente.

4) Ruta por riesgo utilizando señales de incertidumbre

Las acciones de alto impacto merecen mayores garantías. El enrutamiento basado en riesgos convierte la incertidumbre en una característica del producto.

• Utilice señales de confianza (clasificadores, comprobaciones de coherencia o un segundo verificador de modelo) para decidir el enrutamiento.

• Asegure pasos arriesgados detrás de modelos más sólidos, verificación adicional o aprobación humana.

5) Llamadas a herramientas de ingeniería como sistemas distribuidos

Los conectores y las dependencias suelen dominar las tasas de error en los sistemas de agentes.

• Aplique tiempos de espera por herramienta, esperas nerviosas, disyuntores y límites de concurrencia.

• Versionar esquemas de herramientas y validar respuestas de herramientas para evitar interrupciones silenciosas cuando cambian las API.

6) Hacer que la recuperación sea predecible y observable

La calidad de la recuperación determina el fundamento de su solicitud. Trátelo como un producto de datos versionado con métricas de cobertura.

• Realice un seguimiento de la tasa de recuperación de documentos vacíos, la actualidad de los documentos y la tasa de aciertos en consultas etiquetadas.

• La tasa de empuje cambia con los canarios, por lo que sabes si algo va a fallar antes de que falle.

• Aplique acceso con privilegios mínimos y redacción en la capa de recuperación para reducir el riesgo de fugas.

7) Construir un canal de evaluación de producción

Los últimos nueve se basan en encontrar rápidamente fallas raras y prevenir regresiones.

• Mantenga un conjunto de tráfico de producción basado en incidentes y ejecútelo en función de cada cambio.

• Ejecute el modo sombra y canarios A/B con reversión automática en regresiones SLI.

8) Invertir en observabilidad y respuesta operativa

Cuando las fallas se vuelven raras, la velocidad del diagnóstico y la reparación se convierte en el factor limitante.

• Emita seguimientos/extensiones por paso, almacene indicaciones editadas y E/S de herramientas con controles de acceso sólidos y clasifique cada falla en una taxonomía.

• Utilice runbooks y alternancias de “modo seguro” (deshabilite herramientas riesgosas, cambie plantillas, requiera aprobación humana) para una mitigación rápida.

9) Envíe un control deslizante de autonomía con alternativas deterministas

Los sistemas falibles necesitan supervisión y el software de producción necesita una forma segura de aumentar la autonomía con el tiempo. Tratar autonomía como un botón, no un interruptor, y haga que la ruta segura sea la predeterminada.

• El valor predeterminado es acciones de solo lectura o reversibles, requiere confirmación explícita (o flujos de trabajo de aprobación) para operaciones y escrituras irreversibles.

• Cree alternativas deterministas: respuestas de solo recuperación, respuestas almacenadas en caché, controladores basados ​​en reglas o escalamiento a revisión humana cuando la confianza es baja.

• Exponga modos de seguridad por inquilino: deshabilite herramientas/conectores riesgosos, fuerce un modelo más sólido, reduzca la temperatura y reduzca los tiempos de espera durante los incidentes.

• Diseñe transferencias reanudables: persista en el estado, muestre el plan/diferencia y deje que un revisor apruebe y reanude el paso exacto con una clave de idempotencia.

Bosquejo de implementación: un resumen de pasos limitado

Un pequeño envoltorio alrededor de cada paso del modelo/herramienta convierte la imprevisibilidad en control basado en políticas: validación estricta, reintentos limitados, tiempos de espera, telemetría y respaldos explícitos.

def run_step(nombre, intento_fn, validar_fn, *, max_attempts=3, timeout_s=15):

# rastrear todos los intentos en un período

intervalo = inicio_intervalo (nombre)

para intento de alcance (1, max_attempts + 1):

para probar:

# latencia limitada para que un paso no pueda detener el flujo de trabajo

con fecha límite (timeout_s):

salida = intento_fn()

# puerta: esquema + semántica + invariantes comerciales

validar_fn(fuera)

# camino del éxito

métrica(“paso_éxito”, nombre, intento=intento)

devolver

excepto (TimeoutError, UpstreamError) como y:

# transitorio: reintento con jitter para evitar tormentas de reintentos

span.log({“intento”: intento, “error”: str(e)})

dormir(jittered_backoff(intento))

excepto ValidationError como y:

# salida incorrecta: inténtelo de nuevo una vez en modo “más seguro” (temperatura más baja/mensaje más estricto)

span.log({“intento”: intento, “error”: str(e)})

out = tentative_fn(modo=”más seguro”)

# respaldo: mantiene el sistema seguro cuando se agotan los reintentos

métrica(“step_fallback”, nombre)

devolver EscalateToHuman(razón=f”{nombre} falló”)

Por qué las empresas insisten en los últimos nueve puestos

Las brechas de confiabilidad se traducen en riesgos comerciales. Encuesta global McKinsey 2025 informa que el 51% de las organizaciones que utilizan IA han experimentado al menos una consecuencia negativa y casi un tercio ha informado consecuencias relacionadas con la inexactitud de la IA. Estos resultados impulsan la demanda de mediciones, salvaguardias y controles operativos más sólidos.

Lista de verificación de cierre

• Elija un flujo de trabajo principal, defina su SLO de finalización y los códigos de estado del terminal del instrumento.

• Agregue contratos + validadores alrededor de cada salida del modelo y entrada/salida de la herramienta.

• Trate los conectores y la recuperación como un trabajo de confiabilidad de primera clase (tiempos de espera, disyuntores, canarios).

• Dirigir acciones de alto impacto a través de caminos de mayor seguridad (verificación o aprobación).

• Convierte cada incidente en una prueba de regresión en tu set dorado.

Los nueve llegan a través de una ingeniería disciplinada: flujos de trabajo restringidos, interfaces rígidas, dependencias resilientes y ciclos rápidos de aprendizaje operativo.

Nikhil Mungel lleva más de 15 años creando sistemas distribuidos y equipos de inteligencia artificial en empresas SaaS.

Fuente