AI Engineering: de la demo al producto

Qué es AI engineering

Los “modelos base” (foundation models) son los LLM que usamos todos los días: ChatGPT, Gemini, Claude, Llama. AI engineering es la disciplina que los convierte en algo que la gente puede usar de verdad, medida en cuatro pilares:

Por qué esta disciplina existe justo ahora

• Mejores capacidades del modelo: los modelos actuales razonan, escriben, resumen, programan y hasta colaboran entre sí como agentes.
• Acceso fácil: APIs y protocolos como MCP hacen trivial conectar herramientas externas.
• Menor tiempo de construcción: herramientas como Replit o Lovable arman un primer prototipo en minutos. No es perfecto, pero arrancar nunca fue tan rápido.

Más demanda + menor barrera de entrada = una disciplina de ingeniería nueva.

Una demo no es un producto

Una demo es un prompt, una prueba manual, una sola llamada al modelo, bajo riesgo y sin monitoreo. Se ve muy bien, corre en tu laptop, se la puedes mostrar a un par de amigos. Lo que no puede hacer es sostener cientos de usuarios con respuestas rápidas, costos controlados y fallas detectadas a tiempo.

El ciclo de vida completo de AI engineering

1. Caso de uso: qué problema estás resolviendo, antes que nada.
2. Modelo: ¿OpenAI, Claude, Gemini? Cuál eliges y por qué.
3. Evaluación: qué métrica de éxito estás optimizando.
4. Mejora de calidad: prompts, RAG, agentes, fine-tuning.
5. Arquitectura de producción: confiable y usable a escala.
6. Monitoreo: fallas, costos y latencia, en vivo.
7. Feedback: el sistema nunca está “terminado”.

Qué es un foundation model

Un modelo de propósito general adaptable a distintas tareas: piensa en ChatGPT respondiendo preguntas, ayudando a investigar o generando código, todo con el mismo modelo base.

• Multimodal: puede tomar y generar texto, audio, video e imágenes.
• Adaptable vía RAG: le inyectas tu propio contexto para que lo use al responder.
• Adaptable vía fine-tuning: ajustas el modelo para tu caso de uso específico.

Ejemplos: GPT, Claude, Gemini, Llama.

De los modelos de lenguaje a las aplicaciones de IA

• Modelos de lenguaje: aprenden patrones del texto.
• LLM: lo mismo, a escala: más datos, más cómputo, más parámetros.
• Foundation models: propósito general, casi siempre multimodales.
• Aplicaciones de IA: se construyen adaptando el modelo base a un problema real.

Escala + post-entrenamiento + mejores interfaces de entrada = las aplicaciones de IA de hoy.

Tokens y auto-supervisión

Un token es la unidad mínima que el modelo lee y predice: a veces una palabra completa, a veces una fracción de ella. El modelo aprende por auto-supervisión, prediciendo el siguiente token a partir de una cantidad enorme de texto sin etiquetar.

Son máquinas de predicción probabilísticas, no deterministas. Por eso la misma pregunta, hecha dos veces, puede darte dos respuestas distintas.

Por qué las respuestas cambian cada vez

• Temperature: cerca de 0 favorece respuestas factuales; cerca de 1, respuestas más creativas.
• Top P: limita las opciones a la masa de probabilidad más alta.
• Top K: limita las opciones a los K tokens más probables.
• Penalizaciones de presencia/frecuencia: reducen la repetición.
• El sistema y el no determinismo del modelo también influyen.

Por eso Claude, ChatGPT y Gemini “opinan” distinto ante el mismo prompt: cada uno se entrenó distinto.

Alucinaciones: cuando el modelo inventa con total seguridad

El modelo asegura algo falso con el mismo tono seguro que usaría para algo cierto. Tres causas principales:

• Vacío de conocimiento: todo lo posterior a la fecha de corte del entrenamiento, el modelo no lo sabe, a menos que pueda buscar en internet.
• Completado de patrones: llena el hueco con lo que suena probable, no necesariamente con lo que es verdad.
• Fundamentación débil: sin buen contexto, la respuesta puede derivar hacia algo completamente inventado.

Mejor contexto, mejor evaluación y guardrails reducen la alucinación. No la eliminan.

Evaluar es la habilidad central

Una buena evaluación te sirve para:

• Medir progreso real, no impresiones.
• Comparar modelos y enfoques entre sí.
• Detectar regresiones antes de que lleguen al usuario.
• Alinear el sistema con los objetivos del negocio.
• Construir confianza con quien lo usa.

Por qué evaluar IA es difícil

• Salidas abiertas: pueden existir varias respuestas igualmente válidas.
• Calidad subjetiva: utilidad, claridad y seguridad son difíciles de puntuar en automático.
• Depende del contexto: una buena respuesta depende de la tarea, la intención del usuario y el dominio.
• Multidimensional: calidad, seguridad, costo y latencia importan a la vez. No es una sola métrica.

Dos familias de evaluación

LLM como juez

1. Se define una rúbrica y ejemplos de referencia.
2. Se generan las salidas candidatas.
3. Un modelo “juez” las puntúa o las compara lado a lado.
4. Se agregan los puntajes y se comparan los resultados.

No está libre de sesgos: hay inconsistencias y preferencias propias de cada modelo juez.

El pipeline general de evaluación

Cinco capas conectadas: los datos de prueba, el modelo bajo evaluación, el evaluador (humano o LLM juez), los puntajes por criterio y, al final, la decisión de enviar o seguir mejorando. Es un loop, no un paso único: vuelve a alimentar el sistema.

Los leaderboards públicos no bastan

Se quedan cortos porque usan datasets, tareas y métricas distintas a las tuyas, no capturan costo ni latencia, y cambian rápido.

Qué hacer en su lugar:

• Define tu caso de uso y tus criterios de éxito.
• Arma tu propio set de evaluación privado.
• Corre comparaciones lado a lado.
• Evalúa calidad, seguridad, costo y latencia juntos.
• Decide con datos, no con el ranking del momento.

El pipeline de evaluación en producción

Reevalúa después de cada cambio de prompt, de modelo, de datos o de herramientas. El monitoreo en producción cierra el loop: rastrea el comportamiento real y alimenta la siguiente ronda de evaluación.

El prompt es la primera palanca

Es la forma más rápida de cambiar el comportamiento del modelo sin tocar el modelo mismo:

• Rápido de probar e iterar.
• Más barato que el fine-tuning.
• Sirve para controlar formato, tono e instrucciones.
• Casi siempre es el primer paso, antes de cambios más grandes.

Consejo del libro: versiona tus prompts. Guarda las versiones anteriores por si necesitas comparar o revertir. Orden recomendado: prompt → RAG → agentes o fine-tuning, solo si hace falta.

La anatomía de un buen prompt

• Rol / sistema: define el comportamiento y las reglas.
• Tarea: di exactamente qué hacer.
• Contexto: aporta los datos y el trasfondo.
• Ejemplos: muestra el patrón que buscas.
• Formato de salida: ¿JSON, HTML, markdown?

El prompting en producción es más que una caja de texto

Seis piezas se ensamblan antes de llegar al modelo: lo que escribe el usuario, el system prompt fijo, el contexto recuperado (RAG), ejemplos few-shot, todo unido por un “prompt builder” y, al final, un parser que valida que la salida tenga el formato pedido.

Ataques e inyección de prompts

Ataques comunes: “ignora las instrucciones anteriores”, pedir que revele el prompt oculto, contenido malicioso escondido en documentos recuperados, o engañar al modelo para que use herramientas de forma insegura.

Defensas:

• Mantener clara la jerarquía de instrucciones.
• Tratar todo el contenido recuperado como no confiable.
• Restringir herramientas con listas de acceso permitido.
• Revisar las salidas antes de que lleguen al usuario.

La inyección casi siempre entra por input de usuario, archivos, páginas web o contexto recuperado.

Guardrails en todo el flujo, no solo al final

Los checks corren antes, durante y después de la generación, no solo al final. Cuando hay incertidumbre, el sistema escala a revisión humana o a un LLM juez.

Por qué el contexto lo cambia todo

Sin contexto, las respuestas son genéricas, alucinan más y no conocen hechos actuales ni de tu dominio.

Con buen contexto: respuestas más relevantes, mejor fundamentación factual, mejor desempeño en tu dominio y mejor experiencia de usuario.

El contexto puede venir de documentos recuperados, datos del usuario, herramientas, sistemas estructurados, memoria de estado o el propio prompt.

RAG básico, en una sola imagen

El retriever trae los fragmentos (chunks) más parecidos a la pregunta desde una base vectorial, y esos fragmentos se agregan al prompt como contexto antes de generar la respuesta.

RAG sirve cuando el modelo necesita hechos que no memorizó, o que cambian con el tiempo.

El pipeline de datos: indexado offline vs consulta en línea

No existe un único método de chunking que funcione para todo tipo de contenido: se prueba y se ajusta según si son PDFs, hojas de cálculo o texto plano. Un enfoque híbrido, combinando palabras clave y significado semántico, suele funcionar mejor que uno solo.

Buscar y mejorar: keyword, semántica e híbrida

• Keyword (BM25): busca palabras exactas. Fuerte para términos raros y coincidencias exactas.
• Semántica: entiende el significado, no solo la palabra. Mejor cuando la forma de preguntar cambia.
• Híbrida: combina ambas. Suele ser la más fuerte en la práctica.

Para mejorar la calidad del RAG:

• Mejor chunking, según el tipo de contenido.
• Reescritura de queries vagas en búsquedas más fuertes.
• Metadata como filtro (autor, fecha, país) para acotar sin escanear todo.
• Re-ranking para reordenar por relevancia real.
• Loops de evaluación que midan qué mejora de verdad.

Los modos de falla más comunes

• Documentos faltantes: la fuente ni siquiera está en el corpus.
• Chunks malos: demasiado grandes, demasiado chicos o mal separados.
• Recuperación débil: no trae el contenido correcto.
• Ranking pobre: lo relevante queda enterrado bajo resultados más débiles.
• Conocimiento desactualizado: los documentos no se refrescaron.
• Respuesta no respaldada: el modelo dice más de lo que el contexto sostiene.

RAG reduce la alucinación solo cuando la recuperación y la fundamentación son sólidas.

RAG vs agentes

RAG es mejor para responder con fundamento, en un solo paso de recuperación y generación.

Los agentes son mejores para tareas de varios pasos con acciones reales: planean, actúan, observan e iteran.

No conviene usar agentes por defecto: primero define si necesitas fundamentar una respuesta, o si necesitas que el sistema tome acciones.

Cómo funciona el loop de un agente

Es un ciclo, no una sola llamada al modelo. Si el agente tiene suficiente contexto, responde; si no, vuelve a planear, elige otra herramienta, observa y actualiza su memoria. Piénsalo como un workflow con retroalimentación, no como magia autónoma.

Herramientas sí, pero con permisos

Sin herramientas, el agente no puede hacer nada fuera de conversar. Los permisos lo mantienen seguro: listas de acceso permitido, alcance definido, límites de tasa, puntos de aprobación y registros de auditoría.

Principio de mínimo privilegio: dale al agente solo lo que de verdad necesita. Mejor varios agentes pequeños y enfocados que uno con acceso a 25 herramientas distintas.

La memoria de un agente

• Corto plazo: los mensajes recientes, el contexto inmediato de la conversación.
• Estado de la tarea: la meta actual, el progreso y los resultados intermedios.
• Largo plazo: conocimiento, preferencias y hechos guardados con el tiempo.
• Historial de interacciones: decisiones pasadas, para dar continuidad.

Los riesgos son reales: memoria obsoleta, problemas de privacidad y un contexto que crece sin control. Guarda solo lo que ayuda a la tarea, y olvida lo que ya no sirve.