Vi aparecer una factura de $200 en una cuenta de AWS durante la noche.
No porque el sistema colapsara.
Un agente corrió 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 saludable.
Nadie se dio cuenta hasta que la factura llegó 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. Lograr que algo funcione. Sentir que estás progresando.
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) + Pensamiento (LLM + Tokens) + Acciones (Agentes) + Medición (Evals)
…ensamblado mediante Ingeniería de Contexto.
Eso es todo el campo.
Todo lo que sigue es solo desglosar lo que realmente significa cada parte.
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 un pizarrón en una sala de reuniones.
El modelo solo trabaja con lo que está actualmente en el pizarrón.
Cuando el pizarrón se llena, las notas viejas 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 cobra por token de entrada y salida
→ Los historiales de chat largos llenan la ventana rápido
→ Cuando el contexto se llena, las instrucciones anteriores se descartan silenciosamente
→ Lo que entra en el contexto es una decisión de ingeniería, no un valor por defecto
La falla que lo demuestra:
Un equipo construyó un agente de atención al cliente con el historial completo de 12 meses de chat como contexto en cada solicitud.
Funcionó perfectamente en pruebas con 5 interacciones.
En producción, después de 50 interacciones, el agente empezó a ignorar su propio prompt del sistema.
Las instrucciones todavía estaban ahí.
Estaban enterradas bajo 80,000 tokens de historial de conversación.
El modelo efectivamente había dejado de prestarles atención.
La solución no fue un mejor modelo.
Fue resumir el historial más antiguo 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 lo "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 manera diferente.
Un modelo de embedding convierte el 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" → muy separados
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 basado en tus datos reales — no alucinado
Dónde falla RAG:
→ Mala recuperación = mala respuesta. El modelo solo puede trabajar con lo que recibió
→ Un chunking 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 demostraciones. En producción, las respuestas eran vagas y a veces incorrectas.
El problema: el tamaño del chunk.
Dividieron el manual en chunks de 1,000 tokens por conteo bruto de caracteres.
Las tablas se partían a la mitad de una fila. Las instrucciones paso a paso se partían a mitad de un paso.
La recuperación encontraba el área general correcta — pero fallaba la respuesta real.
Reducir el tamaño del chunk 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 a su alrededor.
Si estás viendo respuestas incorrectas, deja de ajustar tu prompt.
Empieza a medir la precisión de tu recuperación.
Ahí está la respuesta.
4. El Bucle del 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 normal a un LLM es sin estado. Preguntas, responde, termina.
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 en función de 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 funcionan 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. Una falla silenciosa hace que el agente produzca basura con confianza
El fallo de los $200 durante la noche, 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 escalamiento 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í.
Guardarraíles, condiciones de parada, manejadores de errores — construidos desde el principio, no agregados después del primer incidente.
5. Evals (Evaluación)
Los evals son cómo sabes si tu sistema de IA realmente está funcionando — y si un cambio lo mejoró o lo empeoró.
Este es el concepto que la mayoría de los tutoriales omiten porque no es glamoroso.
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 revisar 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 evals:
Desplegar → Medir con evals → Encontrar fallos → Agregar fallos al conjunto de datos dorado → Arreglar → Ejecutar evals de nuevo → Comparar puntajes → Enviar solo si los números mejoraron
La verdad honesta:
"Utilidad: 3.7/5" no te dice nada procesable.
"Recuperó el documento correcto: el 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 queda 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 lo reflejan.
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 profundamente en un contexto largo tiene menos probabilidades de ser utilizada.
Lo que realmente implica la ingeniería de contexto:
→ Selección: ¿qué documentos, hechos o historial necesita esta decisión específica?
→ Compresión: ¿se pueden resumir las partes antiguas de la conversación para ahorrar tokens?
→ Orden: las instrucciones críticas deben ir 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, secciones etiquetadas afectan cuán confiablemente 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 original y las restricciones, incluso cuando el historial llena la ventana.
Ingeniería de contexto: comprimir salidas de herramientas 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 realmente se siguen.
Cómo estos 6 conceptos forman un solo sistema
MEMORIA → RAG + Embeddings (lo que el sistema sabe)
PENSAMIENTO → LLM + Tokens + Ventana de Contexto (cómo razona con lo que sabe)
ACCIONES → Bucle del Agente + Herramientas (lo que puede hacer en el mundo)
MEDICIÓN → Evals (cómo sabes que está funcionando)
PEGAMENTO → Ingeniería de Contexto (lo que decide qué fluye entre todo lo anterior)
Un chatbot simple es solo Pensamiento.
Un agente de atención al cliente es Memoria + Pensamiento + 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 individual:
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 del 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 tokens y 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 del agente cuando necesites automatización
→ Añade evals antes de enviar cualquier cosa a producción
→ Aplica 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 opinión final honesta
La mayoría de los equipos que luchan con IA en producción no están luchando con el modelo equivocado o la librería equivocada.
Están luchando porque omitieron uno de estos seis conceptos.
Los bucles de agentes se ejecutan 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 otra vez.
Más importante aún — nunca gastarás $200 viendo a un agente ejecutarse 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
→ Guárdalo 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.
