Vi aparecer una factura de $200 en una cuenta de AWS de la noche a la mañana.
No porque el sistema fallara.
Un agente se ejecutó en un bucle durante seis horas sin condición de parada, llamando a la API de OpenAI en cada iteración.
Todos los paneles de monitoreo decían que estaba bien.
Nadie se dio cuenta hasta que llegó la factura por la mañana.
Eso es lo que sucede cuando construyes sistemas de IA sin entender cómo funcionan realmente.
La mayoría de las personas aprenden ingeniería de IA al revés.
Instalar una librería. Seguir un tutorial. Llamar a una API. Conseguir que algo funcione. Sentir que progresas.
Luego algo se rompe de una manera que no tiene sentido.
Cambian números al azar hasta que se arregla.
Eso no es ingeniería. Es esperanza con un teclado.
Aquí están los 6 conceptos que solucionan esto.
La frase que lo explica todo
Cada sistema de IA, sin importar lo complejo que sea, es solo:
Memoria (RAG) + Razonamiento (LLM + Tokens) + Acciones (Agentes) + Medición (Evals)
…ensamblados mediante Ingeniería de Contexto.
Eso es todo el campo.
Todo lo que viene a continuación es solo desglosar lo que cada parte significa realmente.
1. Tokens y la Ventana de Contexto
Los LLM no leen palabras. Leen fragmentos llamados tokens.
"engineering" → 1 token
"unbelievable" → 2 tokens Los espacios y la puntuación también cuentan.
Cada modelo tiene una ventana de contexto — un límite duro de tokens que puede contener a la vez.
→ Claude: 200,000 tokens
→ GPT-5: 400,000 tokens
Piénsalo como una pizarra en una sala de reuniones.
El modelo solo trabaja con lo que está actualmente en la pizarra.
Cuando la pizarra se llena, las notas antiguas se borran para hacer espacio.
El modelo no pierde la capacidad de pensar.
Pierde el acceso a la información anterior.
Por qué esto rompe los sistemas en producción:
→ Los tokens cuestan dinero — cada llamada a la API factura por token de entrada y salida
→ Los historiales de chat largos llenan la ventana rápidamente
→ Cuando el contexto se llena, las instrucciones anteriores se eliminan silenciosamente
→ Lo que entra en el contexto es una decisión de ingeniería, no un valor predeterminado
El fallo que lo demuestra:
Un equipo construyó un agente de atención al cliente con el historial completo de chat de 12 meses como contexto en cada solicitud.
Funcionó perfectamente en las pruebas con 5 interacciones.
En producción, después de 50 interacciones, el agente comenzó a ignorar su propio prompt del sistema.
Las instrucciones todavía estaban allí.
Estaban enterradas bajo 80,000 tokens de historial de conversación.
El modelo había dejado efectivamente de prestarles atención.
La solución no fue un mejor modelo.
Fue resumir el historial anterior para mantener la ventana enfocada.
La verdad incómoda:
La mayoría de los "fallos de prompt engineering" son en realidad fallos de tokens y ventana de contexto disfrazados.
Los ingenieros culpan al prompt cuando el verdadero problema es que la instrucción crítica está en la línea 3 de un contexto de 500 líneas, y el modelo dejó de ponderarla.
2. Embeddings y Búsqueda Vectorial
Los embeddings convierten el significado en números para que "similar" pueda calcularse matemáticamente.
El problema que resuelven:
Tienes 50,000 documentos. Un usuario hace una pregunta. Necesitas los 3 más relevantes — sin leer los 50,000 cada vez.
La búsqueda por palabras clave falla aquí.
Si el documento dice "automóvil" y el usuario pregunta sobre "coches", la búsqueda por palabras clave no lo encuentra.
No porque la respuesta no esté ahí. Sino porque las palabras no coincidieron.
Los embeddings resuelven esto de otra manera.
Un modelo de embedding convierte texto en un vector — una lista de números que representa el significado en un espacio matemático.
Texto semánticamente similar → vectores numéricamente similares.
"coche" y "automóvil" → cercanos
"coche" y "fotosíntesis" → lejanos
Cómo funciona realmente la búsqueda vectorial:
- Cada documento se convierte en un vector y se almacena
- La pregunta del usuario también se convierte en un vector
- El sistema encuentra los vectores almacenados más cercanos al vector de la pregunta
- Esos son tus documentos más relevantes
Esto no es magia aproximada. Es geometría.
La similitud es una propiedad matemática real que puedes calcular.
Dónde aparece esto en producción:
→ Búsqueda semántica en cualquier sistema de documentos
→ Encontrar productos, artículos, perfiles de usuario similares
→ El paso de recuperación en RAG (siguiente concepto)
→ Memoria en agentes de IA
3. RAG (Generación Aumentada por Recuperación)
En lugar de entrenar un modelo con tus datos, recuperas los datos relevantes en el momento de la consulta y se los proporcionas al modelo como contexto.
El problema que resuelve RAG:
Los LLM saben mucho. No conocen tus datos.
Los documentos internos de tu empresa. Tu base de datos de productos. Tu historial de atención al cliente.
Nada de eso estaba en el conjunto de entrenamiento.
Dos opciones: entrenar un modelo con tus datos (costoso, lento, se vuelve obsoleto al instante) o darle al modelo tus datos exactamente cuando los necesita.
RAG es la segunda opción, hecha de manera sistemática.
El pipeline de 3 pasos:
→ RECUPERAR:
la pregunta se convierte en un vector → la base de datos vectorial encuentra los documentos almacenados más similares → se recuperan los 3-5 fragmentos principales
→ AUMENTAR:
los documentos recuperados se añaden al contexto del modelo → el prompt se convierte en "usando este contexto, responde esta pregunta"
→ GENERAR:
el modelo responde basándose en tus datos reales — no alucinados
Dónde falla RAG:
→ Mala recuperación = mala respuesta. El modelo solo puede trabajar con lo que recibió
→ Un fragmentado deficiente separa la respuesta de su contexto
→ El modelo aún puede alucinar si la recuperación no encuentra nada útil
Un fallo real de RAG:
Un equipo construyó un asistente de conocimiento interno para un manual técnico de 500 páginas.
Funcionó perfectamente en demos. En producción, las respuestas eran vagas y a veces incorrectas.
El problema: el tamaño del fragmento.
Dividieron el manual en fragmentos de 1,000 tokens por conteo bruto de caracteres.
Las tablas se dividieron en medio de una fila. Las instrucciones paso a paso se dividieron en medio de un paso.
La recuperación estaba encontrando el área general correcta — pero se perdía la respuesta real.
Reducir el tamaño del fragmento a la mitad y agregar superposición solucionó el 80% de los problemas de la noche a la mañana.
La opinión contundente:
RAG está sobrevalorado cuando tu recuperación es mala.
El LLM no puede arreglar una mala recuperación. Solo puede alucinar alrededor de ella.
Si estás viendo respuestas incorrectas, deja de ajustar tu prompt.
Empieza a medir tu precisión de recuperación.
Ahí está la respuesta.
4. El Bucle de Agente
Los agentes funcionan eligiendo repetidamente una acción, ejecutándola, observando el resultado y decidiendo qué hacer a continuación — hasta que la tarea está completa.
Una llamada regular a un LLM es sin estado. Preguntas, responde, listo.
Un agente tiene estado. Actúa, observa, decide, repite.
El bucle en lenguaje sencillo:
- Recibir un objetivo
- Decidir la siguiente acción
- Ejecutarla — buscar, codificar, leer un archivo
- Observar el resultado
- Decidir la siguiente acción basándose en lo aprendido
- Repetir hasta que el objetivo esté completo
- Devolver la respuesta final
Las herramientas son lo que da poder a los agentes.
Sin herramientas, un LLM solo responde con texto.
Con herramientas, puede buscar en la web, leer archivos, escribir código, llamar a APIs, desencadenar cualquier acción que definas.
Tres cosas que los principiantes siempre hacen mal:
→ Los agentes sin condiciones de parada se ejecutan para siempre. Debes definir cuándo parar — límite de pasos, límite de tiempo o condición de objetivo
→ Más herramientas ≠ mejor rendimiento. Demasiadas herramientas confunden al modelo sobre cuál usar
→ Los errores de herramientas necesitan un manejo explícito. Un fallo silencioso hace que el agente produzca basura con confianza
El fallo de los $200 de la noche a la mañana, en detalle:
El agente no tenía un número máximo de pasos. Su objetivo: investigar un tema y producir un resumen.
Una de sus herramientas de búsqueda web devolvió un resultado vacío.
El agente no sabía cómo parar.
Siguió buscando, reintentando, generando resúmenes intermedios — cada uno desencadenando otra búsqueda.
Seis horas después: 847 llamadas al LLM. 2.1 millones de tokens consumidos. Un resumen coherente pero completamente circular. Una factura de $200.
La solución fueron tres líneas: un contador máximo de pasos, un manejador explícito para resultados vacíos, una ruta de escalada cuando la confianza era baja.
El mismo agente ahora se completa en menos de 12 llamadas en promedio.
La opinión que necesitas escuchar:
La mayoría de los agentes fallan no porque el modelo sea malo, sino porque los ingenieros tratan el bucle como si se gestionara solo.
No es así.
Barandillas, condiciones de parada, manejadores de errores — construidos desde el principio, no añadidos después del primer incidente.
5. Evals (Evaluación)
Los evals son cómo sabes si tu sistema de IA realmente funciona — y si un cambio lo mejoró o empeoró.
Este es el concepto que la mayoría de los tutoriales omiten porque no es glamuroso.
También es lo que separa a los ingenieros que construyen demos de los ingenieros que construyen sistemas en producción.
El problema sin evals:
Cambias tu prompt. Actualizas tu lógica de recuperación. Cambias a un modelo más nuevo.
¿Mejoró?
No lo sabes. Podrías verificar manualmente algunos ejemplos — pero eso es una sensación, no evidencia.
Cómo se ven realmente los evals:
→ Un conjunto de datos dorado: 25-50 entradas reales con salidas correctas conocidas, cubriendo los casos de uso principales más 5 casos límite complicados conocidos
→ Métricas binarias cuando sea posible:
— ¿El sistema RAG recuperó el documento correcto? Sí/No
— ¿El agente se completó sin errores? Sí/No
— ¿La respuesta contenía la información requerida? Sí/No
→ Puntajes agregados rastreados a lo largo del tiempo:
— Precisión de recuperación: 89% → cambio realizado → 84%. Regresión encontrada.
— Tasa de finalización de tareas: 76% → nueva versión del agente → 81%. Mejora confirmada.
El ciclo de eval:
Implementar → Medir con evals → Encontrar fallos → Añadir fallos al conjunto de datos dorado → Arreglar → Ejecutar evals de nuevo → Comparar puntajes → Desplegar solo si los números mejoraron
La verdad honesta:
"Utilidad: 3.7/5" no te dice nada procesable.
"Documento correcto recuperado: 84% de las veces" te dice exactamente dónde está el problema y cuánto lo mejoró una solución.
Un sistema de IA sin evals no es un producto.
Es una demo que no puedes cambiar con confianza.
6. Ingeniería de Contexto
La disciplina de decidir exactamente qué información entra en la ventana de contexto del modelo, cómo está estructurada y qué se deja fuera.
Aquí está la opinión que incomoda a la gente:
La ingeniería de contexto importa más que la ingeniería de prompts.
Un prompt mediocre en un contexto bien curado supera a un prompt brillante enterrado en ruido — todas las veces.
La mayoría de los equipos dedican el 80% de su esfuerzo de optimización al prompt y casi nada al contexto.
Los resultados reflejan eso.
El enfoque ingenuo falla:
Incluir todo. Todo el historial. Todos los documentos recuperados. Cada descripción de herramienta. El prompt del sistema. El mensaje del usuario. Todo.
Esto falla por una razón consistente: el modelo se confunde sobre qué es lo más importante.
Hay un efecto documentado llamado "perdido en el medio": la información enterrada en lo profundo de un contexto largo es menos probable que se use.
Qué implica realmente la ingeniería de contexto:
→ Selección: ¿qué documentos, hechos o historial necesita esta decisión específica?
→ Compresión: ¿se pueden resumir partes antiguas de la conversación para ahorrar tokens?
→ Ordenación: las instrucciones críticas deben estar al principio y al final — no en el medio
→ Poda: ¿qué se puede eliminar sin afectar la calidad de la salida?
→ Estructura: los encabezados, separadores y secciones etiquetadas afectan la fiabilidad con que el modelo usa la información
Un ejemplo práctico:
Un agente ha estado funcionando durante 45 minutos. Ha acumulado 80,000 tokens de historial de conversación. Su ventana es de 128,000.
No quieres perder el objetivo y las restricciones originales, incluso cuando el historial llena la ventana.
Ingeniería de contexto: comprimir salidas de herramientas más antiguas, resumir razonamientos anteriores, mantener la definición de la tarea prominente durante toda la sesión.
La ingeniería de prompts es escribir buenas instrucciones.
La ingeniería de contexto es construir el entorno en el que esas instrucciones se siguen realmente.
Cómo estos 6 conceptos forman un solo sistema
MEMORIA → RAG + Embeddings (lo que el sistema sabe)
RAZONAMIENTO → LLM + Tokens + Ventana de Contexto (cómo razona con lo que sabe)
ACCIONES → Bucle de Agente + Herramientas (lo que puede hacer en el mundo)
MEDICIÓN → Evals (cómo sabes que funciona)
PEGAMENTO → Ingeniería de Contexto (lo que decide qué fluye entre todo lo anterior)
Un chatbot simple es solo Razonamiento.
Un agente de atención al cliente es Memoria + Razonamiento + Acciones.
Un sistema de producción confiable añade Medición.
La sofisticación está en qué tan bien se conectan las piezas.
El flujo para cualquier solicitud única:
Pregunta del usuario
→ La Ingeniería de Contexto decide qué incluir
→ Los Embeddings recuperan la Memoria relevante (RAG)
→ Los Tokens determinan cuánto cabe en la ventana
→ El LLM razona sobre el contexto ensamblado
→ El Bucle de Agente decide si se necesita más información
→ Los Evals miden si la salida fue realmente correcta
Por dónde empezar
No necesitas dominar los seis a la vez.
→ Empieza con los tokens y las ventanas de contexto — afectan todo lo que construyes → Añade embeddings cuando necesites búsqueda semántica o memoria
→ Aprende RAG cuando necesites fundamentar un modelo en tus propios datos
→ Aprende el bucle de agente cuando necesites automatización
→ Añade evals antes de enviar cualquier cosa a producción
→ Aplica la ingeniería de contexto cuando todo lo demás se vuelva intuitivo
Esa secuencia no es arbitraria.
Cada concepto hace que el siguiente sea aprendible.
La conclusión final honesta
La mayoría de los equipos que luchan con la IA en producción no están luchando con el modelo incorrecto o la librería incorrecta.
Están luchando porque se saltaron uno de estos seis conceptos.
El agente se ejecuta para siempre porque nadie pensó en las condiciones de parada.
Las respuestas de RAG son incorrectas porque nadie midió la recuperación.
El prompt deja de funcionar en sesiones largas porque nadie entendió cómo se llena la ventana de contexto.
Estos no son problemas sofisticados.
Son problemas básicos, disfrazados con vocabulario técnico.
Las herramientas cambian cada seis meses.
Estos seis conceptos son cómo funcionan las herramientas.
Aprende los conceptos, y nunca te confundirá una nueva herramienta.
Más importante aún — nunca gastarás $200 viendo un agente en bucle durante la noche, preguntándote qué salió mal.
Si esto fue útil:
→ Republica para compartirlo con cada ingeniero de IA que conozcas
→ Sigue a @sairahul1 para más sistemas y desgloses como este
→ Marca esto como favorito — lo consultarás la próxima vez que algo se rompa en producción
Escribo sobre IA, construcción de productos y sistemas que funcionan mientras duermes.
