Capítulo 1 — La disciplina de la ingeniería de IA
Primera entrega del recorrido capítulo por capítulo de LLM Primer V: Building Real-World LLM Applications. El capítulo que sostiene que la razón por la que tu demo funciona y tu sistema en producción no lo hace no es un problema de modelo — es un problema de ingeniería, y la ingeniería tiene nombre.
Por qué existe este capítulo
Todo equipo que envía una funcionalidad LLM descubre la misma brecha. La demo va bien con las veinte entradas que el equipo eligió; el sistema en producción va mal con las veinte mil que nunca ve. El modelo no ha empeorado. El equipo ha salido de la región donde una única salida plausible cuenta como éxito y ha entrado en la región de la carga, la deriva, las entradas adversariales y clientes que pagan y cuya métrica de queja es implacable. El Capítulo 1 le pone nombre a esa región y le da una disciplina. La ingeniería de IA no es la ciencia de entrenar el modelo y no es la práctica de escribir un prompt ingenioso. Es la ingeniería del comportamiento determinista de un sistema alrededor de un núcleo probabilístico. El resto del libro es un recorrido por las superficies donde vive esa disciplina; este capítulo es el marco.
1.1 La brecha de fiabilidad entre demo y producción
Una demo y un sistema en producción se ven idénticos en el diagrama de arquitectura. Difieren en carga, en la distribución de entradas de la cola, en presupuesto de latencia, en presión de coste y en modo de fallo. La diferencia dominante es estadística: una demo procesa unas pocas decenas de entradas elegidas a mano, mientras que un sistema en producción procesa millones contra la cola larga — las consultas mal formuladas, en parte en otro idioma, sin contexto, o intencionadamente adversariales. La fiabilidad es una pregunta sobre las colas, no sobre las medias. Encima de eso, el propio modelo es no determinista — el muestreo, el balanceo de carga del proveedor y las actualizaciones silenciosas del modelo se apilan — y los fallos son silenciosos. Una respuesta incorrecta parsea limpiamente, pasa todas las comprobaciones de tipo que el equipo escribió y llega al usuario sin alerta. La observabilidad clásica, que cuenta HTTP 200, no puede ver este modo de fallo. El primer movimiento del equipo es reconocer que repetibilidad, corrección y coste son propiedades de ingeniería que hay que construir, no supuestos que se heredan del stack clásico.
1.2 El envoltorio determinista alrededor del núcleo probabilístico
La respuesta arquitectónica es dejar el modelo probabilístico y envolverlo en software clásico. El envoltorio es el dueño del formato de entrada, del formato de salida, de la validación, de los reintentos, de los fallbacks, del caché, de la observabilidad y de la contabilidad de coste. Por fuera presenta una función determinista — entra una petición, sale una respuesta validada. Por dentro contiene un componente probabilístico que se invoca con un timeout, un esquema y un plan de recuperación para el caso en que el modelo devuelva basura. El envoltorio tiene cuatro bandas: validación de entrada, preparación del prompt, ejecución bajo contrato, y recuperación y emisión. Solo después de atravesar las cuatro la respuesta se convierte en la salida oficial del envoltorio. La tentación recurrente es empujar lógica de vuelta al interior del modelo — "que el modelo se autocorrija" — y cada paso en esa dirección es un paso lejos de la testeabilidad. La disciplina es mantener el núcleo probabilístico pequeño, bien definido y contenido, y mantener el máximo posible del comportamiento del sistema en código determinista que el equipo pueda versionar y razonar.
1.3 Los cinco pilares: fiabilidad, calidad, rendimiento, coste, evolución
El Capítulo 1 recorre cinco posturas de ingeniería que se repiten en todo sistema de producción. La fiabilidad viene de la redundancia: reintentos con retroceso exponencial, cadenas de fallback que van de un primario barato a un secundario más fuerte y a un default basado en reglas, abstracción multi-proveedor y circuit breakers que evitan que un proveedor que sufre arrastre al resto. La calidad viene de la validación en dos capas: la validación de esquema atrapa errores de forma, y la validación de contenido — comprobaciones de fundamentación, umbrales de confianza, guardrails — atrapa los errores semánticos que pasan el esquema. El rendimiento viene del caché en tres capas: coincidencia exacta, semántico y por prefijo de prompt. El control de coste viene de la medición y la atribución, de enrutar el tráfico al modelo más pequeño que basta, de presupuestos por usuario y por petición que impiden que un bucle de agente gaste mil dólares en silencio, y de la economía del prompt. La evolución viene de los cinco bucles de realimentación — logging, evaluación, trazado, feedback humano y despliegue canario — conectados en un circuito donde una traza de producción se convierte en un caso de evaluación, una regresión en evaluación bloquea un deploy y el sistema mejora mes a mes.
Lo que prepara el Capítulo 1
El resto del libro es el envoltorio, capa por capa. El Capítulo 2 se mete en la propia llamada al modelo — tramos de modelo, parámetros de muestreo, prompts defensivos y salidas estructuradas. El Capítulo 3 expande hacia fuera hasta la recuperación, para que el modelo tenga el contexto correcto sobre el que razonar. El Capítulo 4 convierte el envoltorio en un agente que puede llamar herramientas. Los Capítulos 5 y 6 añaden los raíles de evaluación y observabilidad. Los Capítulos 7 y 8 cierran con seguridad y economía del serving. El encuadre del Capítulo 1 es lo que hace legible cada capítulo posterior: cada técnica es o bien un modo de apretar el envoltorio o bien un modo de hacer que el núcleo probabilístico de dentro sea más fácil de envolver.
Próximamente — Capítulo 2: Modelos base e ingeniería de prompts. La capa que hay dentro del envoltorio — selección del modelo, muestreo, prompts y salidas estructuradas — tratada como superficie de ingeniería, no como arte.
