Pensamiento de Sistemas para Ingenieros de IA
El software es frágil. Los sistemas son robustos.
Veo el mismo patrón repetirse: un ingeniero construye un prototipo, el LLM
impresiona, la demo funciona, las partes interesadas asienten, el equipo lo pasa a
producción. Y entonces la API falla un jueves por la noche. El modelo alucina
una cita legal. La factura mensual llega al triple de lo proyectado. El sistema
no falla con gracia. Simplemente falla.
El problema nunca fue el modelo. El problema fue que nadie diseñó el sistema.
La mayoría de ingenieros de IA piensan en funcionalidades, no en sistemas. Optimizan
el prompt pero ignoran el fallback. Evalúan el modelo pero nunca prueban qué
pasa cuando el modelo no está disponible. Este ensayo propone una forma
diferente de pensar. Una que aprendí de 8+ años construyendo software a
escala, donde el uptime no es negociable y "funciona en mi máquina" no es una
estrategia de despliegue.
La Perspectiva de Ingeniería de Hardware
La mejor analogía que he encontrado para sistemas de IA viene de la ingeniería
de hardware, un mundo donde los componentes se sobrecalientan, las señales se
degradan y las fuentes de poder fluctúan. La ingeniería de hardware enseña que
cada componente en un sistema está intentando fallar. Tu trabajo como ingeniero
es diseñar el sistema para que cuando las partes fallen, el todo siga
funcionando.
Tres analogías tomadas del hardware que aplico todos los días:
Los reguladores de voltaje son guardrails. Un regulador toma un voltaje de
entrada impredecible (ruidoso, fluctuante, con picos) y lo estabiliza en un
rango de salida definido. Sin uno, los componentes posteriores se queman. Los
guardrails de un LLM hacen exactamente lo mismo: toman la salida impredecible
del modelo y la restringen a un rango aceptable. Ambos aceptan entrada
variable, producen salida acotada y disipan el exceso. Un regulador disipa
energía como calor. Un guardrail descarta contenido alucinado como tokens
rechazados. Y ambos tienen un límite de diseño. Excederlo significa que la
protección falla. Conocer ese límite separa la ingeniería de la improvisación.
La relación señal-ruido es la tasa de alucinación. En procesamiento de señales, el SNR
mide cuánta señal útil existe respecto al ruido de fondo. En IA, la "señal" es
salida factual y contextualmente relevante; el "ruido" son alucinaciones y
detalles confabulados. Mejor retrieval mejora la señal. Mejores prompts filtran
el ruido. Pero también puedes reducir el ruido en la fuente: en hardware usarías
un filtro pasa-banda para eliminar frecuencias fuera de rango; en IA,
restringes la ventana de contexto a solo los documentos más relevantes. Mismo
principio, diferente medio.
Los circuit breakers son patrones de fallback. Un breaker físico se
dispara cuando la corriente supera un umbral seguro. Sacrifica la
disponibilidad de un circuito para proteger el edificio. Los circuit breakers
de software hacen lo mismo: cuando la tasa de error de una API cruza un umbral,
el breaker se activa, el sistema deja de llamar al servicio que falla y un
fallback toma el relevo. El principio es simple pero fácil de olvidar: una falla sin protección puede
propagar y destruir todo lo que está después. Cada
dependencia externa en mis sistemas de IA tiene un circuit breaker. Cada una.
Las Cinco Propiedades de un Sistema Endurecido
Cinco propiedades que separan software frágil de infraestructura robusta:
1. Redundancia. Sin punto único de falla. Si toda tu funcionalidad de IA depende
de una sola API de un solo proveedor, no tienes un sistema, tienes una
apuesta. Redundancia significa múltiples proveedores de LLM con failover
automático, embeddings cacheados para las consultas más frecuentes, y una capa
de retrieval que pueda caer de búsqueda semántica a búsqueda por keywords sin
que el usuario vea un error.
2. Estados de falla definidos. Cada componente debe tener un modo de falla
conocido y probado. No "podría crashear", sino "cuando este componente retorna
un 503, el sistema responde con X." Documento estados de falla como las hojas
de datos documentan límites de operación.
3. Observabilidad. No puedes arreglar lo que no puedes ver. No puedes
degradar con gracia si no detectas la falla. Esto significa logging de
latencia, uso de tokens y tasas de error por request. Alertas por anomalías de
costo, no solo picos de errores. Capacidad de reproducir un request fallido
desde los logs. La observabilidad no es una funcionalidad que agregas después. Es la
base sobre la que construyes primero.
4. Degradación elegante. Cuando algo se rompe, el sistema empeora, no se
quiebra. La diferencia entre "los resultados son menos precisos ahora" y "500
Internal Server Error." Cada funcionalidad de IA que construyo tiene un fallback sin
IA, aunque sea una respuesta estática o una redirección a un humano.
5. Conciencia de costos. La propiedad que más ingenieros ignoran y la que
más proyectos mata. Si tu costo por request se duplica a escala, tu sistema
tiene un defecto de diseño. Monitoreo el costo igual que la latencia: por
request, con alertas de anomalías y presupuestos claros por funcionalidad. Un sistema
sin conciencia de costos es un sistema esperando que finanzas lo apague.
El Cambio Mental
Tu LLM no es tu sistema. Es un componente dentro de tu sistema.
Suena obvio. No lo es. La mayor parte de la ingeniería de IA actual trata al
modelo como el centro de gravedad. Todo lo demás (retrieval, caching,
fallbacks, monitoreo) es secundario. El pensamiento de sistemas invierte esto.
El modelo es un componente con modos de falla conocidos, igual que un
transistor en un circuito. Y necesita infraestructura de soporte para funcionar
de manera confiable.
El cambio que propongo es de prompt engineering a systems engineering. La
habilidad más importante para un ingeniero de IA no es escribir un mejor
prompt, sino diseñar un mejor sistema alrededor de ese prompt. Cuando evalúo un
sistema de IA, no empiezo leyendo los prompts. Empiezo preguntando: "¿Qué pasa
cuando el modelo no está disponible?" La respuesta dice más sobre la madurez
del sistema que cualquier benchmark.
Checklist: Pensamiento de Sistemas Antes de Lanzar
Preguntas que hago antes de que cualquier funcionalidad de IA llegue a producción:
Redundancia
- ¿Qué pasa si tu proveedor principal de LLM cae por cuatro horas?
- ¿Tienes un fallback cacheado o estático para tus rutas de usuario críticas?
- ¿Puedes cambiar de proveedor sin redesplegar?
Estados de Falla
- ¿Puedes nombrar cada modo de falla de cada dependencia externa?
- ¿Cada modo de falla tiene una respuesta documentada y probada?
Observabilidad
- ¿Estás registrando latencia, conteo de tokens y tasa de error por request?
- ¿Tienes alertas por anomalías de costo, no solo errores?
Degradación Elegante
- Si el componente de IA falla, ¿el usuario aún obtiene valor de la funcionalidad?
- ¿Tu ruta de degradación está probada en CI o solo existe en un documento?
Conciencia de Costos
- ¿Cuál es tu costo por request a 10x tu tráfico actual?
- ¿Tienes un kill switch si los costos se disparan más allá del presupuesto?
Los sistemas no los construyen optimistas. Los construyen ingenieros que
respetan las formas en que las cosas se rompen y diseñan en consecuencia.
El software es frágil. Los sistemas son robustos. Construye el sistema.