Curso exprés · No. 07
Un modelo de lenguaje es un brillante adivinador de la próxima palabra, sin memoria y con la costumbre de inventar cosas. Construir con él no se trata de prompts mágicos — es la ingeniería que envolvés alrededor de un componente poderoso e inestable para volverlo confiable.
24 conceptos · un diagrama para cada uno · hoja de referencia al final
Antes de construir con un modelo de lenguaje, entendé qué es realmente — porque casi todos los errores vienen de esperar que sea algo que no es.
El mapa del curso: 24 conceptos en siete grupos
Un mapa de subte: primero ves las líneas enteras, después viajás estación por estación.
El curso va de lo simple a lo complejo. Primero, qué es el modelo y cómo se comporta. Después cómo hablarle (prompting), qué poner en su ventana (contexto), cómo darle tus hechos (RAG), cómo dejar que actúe (agentes), cómo volver confiable todo eso (fiabilidad) y cómo construir sin pasarte de complicado.
Cómo leer cada concepto
Un pasaporte: los mismos campos para todos, así es fácil compararlos.
Cada concepto recibe el mismo tratamiento: su nombre en inglés (el término que vas a buscar en la documentación), una imagen de la vida cotidiana, un diagrama y una ficha con campos — qué es, un ejemplo, el costo o la trampa, cuándo usarlo y cómo se relaciona con los demás. El curso tiene una idea grande: el modelo es la parte fácil; la ingeniería alrededor es el trabajo de verdad.
Next-token prediction — predice la próxima palabra, muy bien
El teclado de tu teléfono sugiriendo la próxima palabra — pero escalado tan lejos que puede escribir un ensayo, depurar código o explicar física, una palabra plausible a la vez.
Un LLM es un predictor del próximo token entrenado sobre una porción enorme del texto humano. No busca cosas; genera lo que es estadísticamente probable que venga después. Por eso es asombroso con el lenguaje y los patrones de razonamiento — y por eso no es una base de datos de hechos. Produce lo que suena bien, que normalmente está bien, y a veces está equivocado con total confianza.
- Qué es
El modelo genera texto un token a la vez, eligiendo una continuación probable.
- Ejemplo
- "El gato se sentó en la…" → "alfombra" es más probable que "sofá".
- Trampa
- No es una búsqueda de hechos: "suena bien" ≠ "está bien".
- Qué hacer
No uses el modelo como base de datos de hechos — dale vos los hechos.
- Relaciones
La raíz de la Hallucination y del Non-determinism; se trata con RAG.
Context window — su única memoria
Un consultor brillante con amnesia total — en cada reunión tenés que volver a entregarle cada documento, porque no recuerda nada de la vez anterior.
Un modelo no recuerda nada entre solicitudes. Su única memoria de trabajo es la context window — el texto que enviás en esta llamada. El historial del chat, tus datos, tus instrucciones: si no está en el contexto, el modelo no lo sabe. Todo en este curso trata, en algún sentido, sobre qué ponés en esa ventana.
- Qué es
Todo el texto de una llamada: system prompt, historial, documentos, herramientas, pregunta.
- Ejemplo
Un chatbot "recuerda" los mensajes anteriores solo porque se los volvés a enviar en cada llamada.
- Trampa
La ventana es finita, y cada token que hay en ella cuesta dinero y tiempo.
- Qué hacer
- Armá la ventana a propósito — eso es la Context engineering.
- Relaciones
La llenan la Context engineering y el RAG; la Memory vive afuera.
Hallucination — va a inventar cosas, con confianza
Un encantador sabelotodo en una cena que preferiría inventar una respuesta convincente antes que admitir que no sabe.
Cuando el modelo no sabe, no se detiene — alucina, produciendo texto fluido, plausible y equivocado con la misma confianza que la verdad. Esto no es un bug que puedas parchear del todo; es la naturaleza de un adivinador. La mayor parte de la ingeniería en este curso existe para manejar ese único hecho.
- Qué es
- Una respuesta fluida, plausible, pero equivocada, dicha con confianza.
- Ejemplo
- Le pedís una fuente — el modelo cita un artículo que no existe.
- Trampa
No se puede eliminar del todo: es la naturaleza de predecir el próximo token.
- Qué hacer
Limitá dónde puede pasar y atrapala cuando pase — mirá el capítulo 6.
- Relaciones
La reducen el Grounding y el RAG; la atrapan los Guardrails y los Evals.
Non-determinism — distinto cada vez
Hacerle la misma pregunta a diez expertos — obtenés diez buenas respuestas ligeramente distintas, no una réplica idéntica.
El mismo prompt puede dar una salida distinta cada vez — eso es el non-determinism. Por eso no podés tratar a un LLM como una función con un valor de retorno fijo; lo tratás como una entrada inteligente, falible y no determinista — para limitarla, validarla y revisarla, nunca para confiar a ciegas. Esa mentalidad es todo el juego.
- Qué es
- La misma entrada puede producir una salida distinta.
- Ejemplo
Pedís dos veces el resumen de un correo — obtenés dos textos distintos.
- Trampa
- Los tests unitarios comunes de "igual / distinto" se rompen acá.
- Qué hacer
Limitá el formato (Structured output), validá, medí la calidad (Evals).
- Relaciones
- La razón por la que necesitás Evals y Guardrails.
Un LLM no sabe cosas. Las predice. Construí todo lo demás alrededor de esa única verdad.
El prompt es cómo le decís al modelo lo que querés. Cuanto más clara la instrucción, mejor la salida — y la mayoría de los momentos de "la IA es tonta" son en realidad prompts poco claros.
Prompt — un encargo, no un hechizo
Entregarle una tarea a un empleado nuevo y astuto: qué papel cumple, qué querés, las restricciones y un ejemplo de "bien hecho". Encargo vago, resultado vago.
Un buen prompt indica el rol ("sos un editor cuidadoso"), la tarea, las restricciones (largo, tono, formato) y, idealmente, un ejemplo. No hay palabras mágicas — solo instrucciones claras, igual que se las darías a una persona capaz. La mayoría de los problemas de prompt son en realidad problemas de especificación.
- Problema
- Un pedido vago → una respuesta vaga, y parece que "la IA es tonta".
- Idea
- Escribí el prompt como un encargo: rol, tarea, restricciones, ejemplo.
- Ejemplo
"Sos un editor cuidadoso. Reducí este ticket a 3 viñetas, en palabras simples. Acá tenés un ejemplo de buen resultado: …"
- Coste
- Casi nada — solo tenés que pensar con claridad qué querés.
- Cuándo usarlo
- Siempre. Es el primer peldaño de la escalera.
- Relaciones
Se divide en el System prompt y el prompt del usuario; se refuerza con ejemplos Few-shot.
System prompt vs user prompt — reglas permanentes vs el pedido
La política permanente de un restaurante — "somos vegetarianos, cerramos a las diez" — frente al pedido concreto de esta noche. Una enmarca todo; el otro es lo que se pide.
El system prompt fija un comportamiento duradero — rol, reglas, tono — que se mantiene durante toda la conversación. El user prompt es el pedido concreto. Poner tu personaje y tus guardrails en el system prompt los mantiene estables mientras los mensajes del usuario varían.
- Qué es
- Instrucciones duraderas para toda la conversación: rol, reglas, tono.
- Ejemplo
Sistema: "Sos el bot de soporte de una tienda. Respondé corto; nunca prometas reembolsos más allá de la política." Usuario: "¿Dónde está mi pedido?"
- Trampa
No es una cerradura: los usuarios pueden intentar esquivarlo — igual necesitás Guardrails.
- Cuándo usarlo
- Todo lo que deba mantenerse estable entre turnos va acá.
- Relaciones
- Parte del Prompt; está al principio de la Context window.
Few-shot prompting — mostrá, no solo digas
Enseñarle un formato a alguien mostrándole tres ejemplos terminados es más rápido y más claro que describirlo con palabras.
Muchas veces la mejor forma de conseguir la forma de respuesta que querés es incluir unos pocos ejemplos de entrada y de salida deseada directamente en el prompt. Eso es few-shot prompting. El modelo reconoce esos patrones mejor de lo que sigue una descripción abstracta. Dos o tres buenos ejemplos pueden superar a un párrafo de instrucciones.
- Problema
- Un formato o un estilo es difícil de describir con palabras.
- Idea
- Mostrá 2–3 pares "entrada → salida deseada" directamente en el prompt.
- Ejemplo
"'¡Otra vez tarde!' → negativo; 'Me encanta' → positivo; 'Anda bien' → ?"
- Coste
Los ejemplos ocupan lugar en la ventana; un mal ejemplo enseña malos hábitos.
- Cuándo usarlo
Cuando necesitás una forma, un tono o una clasificación exactos.
- Relaciones
- Parte del Prompt; a menudo va junto con Structured output.
Structured output — pedí una estructura que tu código pueda usar
Un formulario con casilleros rotulados te da datos que se pueden completar; "escribime un párrafo sobre eso" te da prosa que después tenés que parsear.
Si tu programa va a consumir la salida, pedí structured output — JSON que cumpla un esquema, no texto libre. Los modelos modernos se pueden limitar a JSON válido, lo que convierte al LLM de un chatbot en un componente en el que tu código puede apoyarse. Structured output es el puente entre el lenguaje y el software.
- Problema
- El código no puede parsear de forma confiable prosa libre.
- Idea
- Limitá la respuesta a un esquema JSON y validala antes de usarla.
- Ejemplo
{"order_id": 42, "status": "late"}en lugar de "Tu pedido 42 viene demorado…".- Coste
- Tenés que definir el esquema y manejar el caso en que la validación falle.
- Cuándo usarlo
- Siempre que la respuesta la lea un programa, no una persona.
- Relaciones
La base del Tool use (una llamada a una herramienta es structured output); una capa de defensa contra la Hallucination.
No hay palabras mágicas. Un buen prompt es un encargo claro — rol, tarea, restricciones, ejemplos.
A medida que las apps se vuelven serias, el oficio pasa de redactar el prompt a armar el contexto correcto. Esta es la disciplina de verdad — la "context engineering".
Context engineering — lo que ponés en la ventana
Un abogado no gana por frases ingeniosas sino por entregarle al juez exactamente los documentos correctos, en el orden correcto, sin nada irrelevante.
La prompt engineering trataba de cómo redactar; la context engineering trata de armar la información correcta — los hechos relevantes, el historial y las herramientas — dentro de la ventana en cada llamada. La respuesta del modelo es tan buena como lo que le pongas delante. La mayoría de los problemas de calidad son problemas de contexto, no de redacción.
- Problema
- El modelo responde mal aunque el prompt esté bien redactado.
- Idea
En cada llamada, poné en la ventana exactamente lo necesario: instrucciones, hechos, historial, herramientas.
- Ejemplo
Un bot de soporte recibe no toda la base de conocimiento, sino la política de reembolsos, el estado del pedido y la pregunta del cliente.
- Coste
Necesitás código que seleccione y arme el contexto — ese es el trabajo de verdad.
- Cuándo usarlo
- Apenas la app es más que un simple prompt.
- Relaciones
Llena la Context window; el RAG es su principal proveedor de hechos; la limita el Context budget.
Relevance over completeness — menos, pero lo correcto
Un informe de una sola página afilada vale más que un volcado de 200 páginas — el lector encuentra la señal en vez de ahogarse en ella.
Más contexto no es mejor. Cada token tiene que ganarse su lugar: el texto irrelevante diluye la atención del modelo, cuesta dinero y en realidad aumenta la probabilidad de alucinación en contextos largos. El arte está en elegir las pocas cosas que importan, no en meter todo lo que podría importar.
Context budget — la ventana es un presupuesto
Una valija con límite de peso — llevás lo que realmente vas a necesitar, no todo el guardarropa, porque hay un tope duro y una multa.
La ventana es finita, y cada token cuesta latencia y dinero. Entonces la gastás con criterio, como un context budget: recortá el historial, resumí lo viejo, recuperá solo lo relevante ahora. Tratar el contexto como un presupuesto escaso — no como un basurero infinito — es lo que separa un juguete de un producto.
- Qué es
El límite de tokens de la ventana, compartido entre el system prompt, el historial, los hechos y la respuesta.
- Ejemplo
Un chat largo: los turnos viejos se comprimen en un resumen corto en lugar de enviarse completos cada vez.
- Trampa
- Más tokens es más caro, más lento — y no necesariamente mejor.
- Qué hacer
Recortá, resumí, recuperá solo lo necesario, cacheá la parte estable.
- Relaciones
Limita la Context engineering; impulsa directamente el Cost & latency.
Prompt engineering es la redacción. Context engineering son los documentos. En el segundo vive la calidad.
El modelo no conoce tus datos, ni nada posterior a su fecha de corte de entrenamiento. El RAG es cómo le das los hechos para que responda a partir de ellos — el patrón más importante de las apps serias con LLM.
RAG — Retrieval-Augmented Generation: primero recuperá, después respondé
Un examen a libro abierto — en vez de confiar en la memoria, primero buscás las páginas relevantes, y después escribís la respuesta con lo que tenés delante.
Retrieval-Augmented Generation (RAG) significa: tomás la pregunta del usuario, traés los fragmentos más relevantes de tus documentos, los ponés en el contexto y le pedís al modelo que responda a partir de ellos. Ahora trabaja con tus datos reales, no con su memoria borrosa. Así es como los asistentes responden sobre tu producto, tus docs, tu base de conocimiento.
- Problema
El modelo no conoce tus datos ni nada posterior a su fecha de corte — e inventa.
- Idea
Primero encontrá los fragmentos correctos de tus documentos, y después respondé solo a partir de ellos.
- Ejemplo
Un bot de documentación encuentra las 3 secciones del centro de ayuda que coinciden y responde a partir de ellas, con citas.
- Coste
- Necesitás chunking, un índice, búsqueda — y hay que medir su calidad.
- Cuándo usarlo
Cuando la respuesta debe apoyarse en tus datos o en hechos frescos.
- Relaciones
Funciona sobre Embeddings; te da Grounding; alimenta la Context engineering.
Embeddings — búsqueda vectorial por significado
Un bibliotecario que encuentra libros por de qué tratan, no por el título exacto — "cosas como esta", por significado.
Para encontrar fragmentos relevantes, guardás tus documentos como embeddings (vectores que capturan qué significa un texto) en una base de datos vectorial y buscás por similitud con la pregunta (el motor del curso de bases de datos). La buena recuperación es el corazón del RAG: si entran los fragmentos correctos, la respuesta está fundamentada; si entra basura, el modelo responde con confianza a partir de basura.
- Qué es
Texto → un vector de números; los textos cercanos en significado son vectores cercanos.
- Ejemplo
"¿Cómo recupero mi plata?" encuentra la sección "Política de reembolsos", aunque casi no compartan palabras.
- Trampa
Parecido en significado no garantiza que el fragmento responda la pregunta.
- Cuándo usarlo
Para buscar por significado en el RAG, en lugar de por palabras exactas.
- Relaciones
- El motor del RAG; su calidad depende del Chunking.
Grounding — respuestas que podés rastrear hasta una fuente
Un periodista que debe citar una fuente para cada afirmación escribe muchas menos invenciones que uno que escribe de memoria.
La gran ventaja del RAG es el grounding: como la respuesta se saca del texto recuperado, podés exigir citas y comprobar que las afirmaciones realmente tengan respaldo. No borra la alucinación, pero la reduce muchísimo — y te deja atrapar lo que se cuela. Una respuesta que podés rastrear hasta una fuente es una en la que podés confiar.
- Problema
- No podés comprobar de dónde sacó el modelo una afirmación.
- Idea
Respondé solo a partir del texto recuperado y citá una fuente debajo de cada hecho.
- Ejemplo
- "Reembolsos dentro de 30 días [1]" — donde [1] =
refund-policy.md. - Coste
- Hay que verificar las citas; las respuestas se vuelven más cautelosas.
- Cuándo usarlo
- Donde equivocarse sale caro: dinero, leyes, salud, soporte.
- Relaciones
El premio del RAG; la principal capa de defensa contra la Hallucination.
Chunking & retrieval quality — basura entra, basura confiada sale
Dale a alguien el archivo equivocado y pedile que lo resuma — te va a dar un resumen perfecto de lo que no era.
El RAG solo funciona si la recuperación funciona. Un mal chunking, una búsqueda débil, datos viejos — y el modelo responde fielmente a partir del contexto equivocado, sonando igual de seguro. Por eso la mayor parte del esfuerzo en RAG no es el modelo; es el chunking, la indexación y la medición de la calidad de la recuperación. Arreglá la recuperación antes de culpar al modelo.
- Problema
El modelo responde con confianza a partir de los fragmentos equivocados.
- Idea
Cortá bien los documentos, mantené el índice fresco y medí por separado si la búsqueda encuentra lo correcto.
- Ejemplo
Una tabla de precios se corta por la mitad — el modelo ve los precios sin los nombres de los planes y se confunde.
- Coste
Trabajo de datos poco glamoroso que se lleva la mayor parte del esfuerzo del RAG.
- Cuándo usarlo
Siempre, si tenés RAG. Arreglá primero la recuperación, después el modelo.
- Relaciones
Decide la calidad del RAG y de los Embeddings; lo verifican los Evals.
No le preguntes al modelo qué sabe. Dale los hechos y pedile que responda a partir de ellos.
Un prompt produce texto. Para que el modelo haga cosas — buscar, calcular, enviar, consultar — le das herramientas; para que persiga un objetivo a lo largo de muchos pasos, lo ponés en un bucle. Eso es un agente.
Tool use — function calling: dejá que llame a tus funciones
Un asistente inteligente que no llega solo al archivo — pero puede pedirte que vayas, y decirte exactamente qué carpeta sacar.
Con tool use (function calling), describís las funciones que el modelo puede pedir — search_orders, send_email, get_weather — y cuando quiere una, devuelve una llamada estructurada, tu código la ejecuta y le devolvés el resultado. El modelo decide qué hacer; tu código sigue al mando de hacerlo. Así es como un LLM llega más allá del texto, al mundo real.
- Problema
Solo con texto no se puede revisar un pedido, calcular ni enviar un correo.
- Idea
Describí las funciones; el modelo devuelve una llamada estructurada; tu código la ejecuta y devuelve el resultado.
- Ejemplo
"¿Dónde está el pedido 42?" → el modelo pide
search_orders(42)→ el código llama a la API → el modelo responde.- Coste
- Cada herramienta es una nueva forma de equivocarse en el mundo real.
- Cuándo usarlo
- Cuando la respuesta necesita datos en vivo o una acción.
- Relaciones
Construido sobre Structured output; el bloque de construcción del Agent loop.
Agent loop — un agente es el modelo en un bucle
Una persona resolviendo un problema: piensa, actúa, mira el resultado, piensa de nuevo — repitiendo hasta terminar, no de un solo golpe.
Un agente conecta el modelo en un bucle — razonar, llamar a una herramienta, observar el resultado, razonar de nuevo (el agent loop) — con el LLM como orquestador que decide cada paso siguiente. Esto le permite manejar tareas abiertas ("investigá esto y redactá una respuesta") que ningún prompt solo podría. Los asistentes de programación y los bots de investigación funcionan así.
- Problema
La tarea no se puede hacer en un solo paso: hay que buscar, probar y corregir.
- Idea
El modelo en un bucle "pensar → actuar → observar", eligiendo cada paso por sí mismo.
- Ejemplo
Un asistente de programación lee un archivo, lo edita, corre los tests, ve un fallo, edita de nuevo.
- Coste
- Impredecible: puede divagar, repetirse o disparar el costo.
- Cuándo usarlo
Solo cuando la tarea de verdad necesita muchos pasos adaptativos. Si no — una llamada o una cadena fija.
- Relaciones
Hecho de Tool use; necesita Memory y Human-in-the-loop.
Memory — memoria más allá de la ventana
Un proyecto largo necesita un cuaderno — no podés tener meses de trabajo en la cabeza, así que anotás lo que importa y lo volvés a consultar.
Como la ventana es finita, los agentes necesitan memory: notas, resúmenes e historial recuperable guardados fuera del contexto y traídos de vuelta cuando son relevantes. Sin ella, un agente se olvida del comienzo de una tarea larga cuando llega al final. La memoria es lo que convierte un chat en algo que puede trabajar a lo largo del tiempo.
- Problema
Una tarea larga no entra en la ventana — el agente olvida el comienzo.
- Idea
Guardá notas y resúmenes fuera de la ventana; traé lo necesario cuando haga falta.
- Ejemplo
Después de cada etapa el agente escribe "qué está hecho, qué sigue" y lo lee en el paso siguiente.
- Coste
- Un sistema más: qué escribir, qué recuperar, qué olvidar.
- Cuándo usarlo
- Para tareas más largas de lo que cabe en una ventana.
- Relaciones
Extiende la Context window; se recupera igual que en el RAG; la necesita el Agent loop.
Human-in-the-loop — los bucles son poderosos, así que mantenelos con correa
Una aspiradora robot que casi siempre limpia la casa, pero a veces se queda girando atascada en un rincón o se mete en la pileta.
Un agent loop es impredecible: puede tomar caminos equivocados, repetirse, disparar el costo o actuar sobre una mala decisión. Por eso lo mantenés con correa — límites de pasos, permisos de herramientas, aprobación humana (human-in-the-loop) para acciones riesgosas, registro completo. Recurrí a un agente solo cuando la tarea de verdad necesita muchos pasos adaptativos; una sola llamada o una cadena fija es más barata y segura cuando alcanza.
- Problema
- Un agente puede hacer por error una acción cara o irreversible.
- Idea
Límites de pasos, herramientas permitidas, logs — y una persona confirma las acciones riesgosas.
- Ejemplo
El agente prepara un reembolso, pero lo envía solo después de que un operador hace clic en aprobar.
- Coste
- Más lento y requiere gente — pero el error nunca llega al mundo.
- Cuándo usarlo
Antes de cualquier acción que sea cara o que no se pueda deshacer.
- Relaciones
Limita el Agent loop y el Tool use; primo de los Guardrails.
Las herramientas le permiten al modelo actuar. Un bucle le permite persistir. Los dos necesitan una correa — capacidad sin límites es una responsabilidad.
Una demo que funciona una vez es fácil. Un sistema en el que podés confiar requiere el trabajo poco glamoroso de medir, acotar y vigilar un componente que es no determinista por naturaleza.
Evals — no podés mejorar lo que no medís
Una escuela que nunca califica a nadie no tiene idea de quién está aprendiendo — ni forma de mejorar.
Un eval es una batería de tests para tu IA: entradas con resultados esperados conocidos, puntuadas automáticamente — ¿recuperó los documentos correctos, llamó a la herramienta correcta, respondió con fidelidad? Sin evals estás ajustando prompts a ojo. Y esperá una verdad dura: llegar al 80% de calidad es rápido; pulir desde ahí hasta el 95% es la mayor parte del trabajo.
- Problema
- No sabés si un cambio en el prompt mejoró o empeoró las cosas.
- Idea
Un conjunto de entradas con resultados esperados y una puntuación de calidad automática.
- Ejemplo
50 preguntas reales de soporte: se verifica si se encontró el documento correcto y si la respuesta es correcta.
- Coste
- Hay que armar y mantener el conjunto — trabajo continuo.
- Cuándo usarlo
- Antes de empezar a ajustar prompts. Sin un eval, es a ojo.
- Relaciones
La respuesta al Non-determinism; mide el RAG, el Tool use, el Agent loop.
Guardrails — límites en la entrada y en la salida
Los bordes de una pista de bowling — no tiran la bola por vos, pero la mantienen fuera de la canaleta.
Los guardrails son controles alrededor del modelo: a la entrada, bloquean el prompt injection y los pedidos fuera de alcance; a la salida, filtran contenido inseguro y validan el formato antes de que llegue a un usuario o a otro sistema. Corren antes y después del modelo, en tu código — porque no podés confiar en que el modelo se controle a sí mismo.
- Problema
No podés lograr que el modelo se controle a sí mismo de forma confiable.
- Idea
Revisá la entrada antes del modelo y la salida después de él — con código común.
- Ejemplo
Entrada: rechazar "ignorá todas las instrucciones anteriores y…". Salida: validar el JSON contra el esquema y quitar el texto inseguro.
- Coste
- Latencia extra y falsos positivos.
- Cuándo usarlo
Siempre en producción, sobre todo cuando la salida llega a personas o a sistemas.
- Relaciones
Respalda al System prompt; controla el Structured output; atrapa la Hallucination.
Cost & latency — restricciones de diseño, no ocurrencias tardías
Un taxímetro corriendo todo el viaje — cada kilómetro extra de contexto, cada paso extra, suma a la tarifa y a la espera.
Cada token cuesta dinero y tiempo, y el costo crece con cuánto contexto enviás y cuántas llamadas hacés. Así que diseñás pensando en eso: recortá y cacheá el contexto, elegí el modelo más chico que sea suficientemente bueno, y no corras un agent loop donde alcanza con una llamada. Una gran respuesta que es demasiado lenta o demasiado cara no es una gran respuesta.
- Qué es
Dinero y tiempo por cada llamada; crecen con el contexto y con la cantidad de llamadas.
- Ejemplo
Enviar toda la base de conocimiento en cada llamada, o correr un agente donde alcanzaba con una llamada, es lento y caro.
- Trampa
Una gran respuesta que es demasiado lenta o demasiado cara no es una gran respuesta.
- Qué hacer
Recortá y cacheá el contexto, elegí el modelo más chico que sea suficientemente bueno, hacé menos llamadas.
- Relaciones
Lo encarece el Agent loop; se maneja con el Context budget.
Hallucination defense — el riesgo alrededor del cual diseñás
No le das el micrófono sin supervisión a un narrador brillante pero poco confiable — verificás los datos antes de que salga a imprenta.
Cada técnica de acá — grounding con RAG, salida estructurada, evals, guardrails, citas — existe para manejar un riesgo central: que el modelo afirme falsedades de forma convincente. Nunca lo eliminás del todo; limitás dónde puede pasar, lo detectás cuando pasa, y nunca dejás que una afirmación sin verificar llegue a un lugar donde equivocarse sale caro. Es defensa en profundidad: cada capa atrapa algunos de los errores.
Una demo confía en el modelo. Un producto lo mide, lo acota y lo vigila — porque es no determinista por naturaleza.
Los patrones se apilan de lo simple a lo complejo. El arte está en usar el menos poderoso que resuelva tu problema — y en tratar al modelo como un componente, no como la arquitectura.
Complexity ladder — subí solo hasta donde debas
No reservás un camión de mudanza para llevar una caja al otro lado del cuarto. Ajustás el esfuerzo al trabajo.
Hay una escalera: un solo buen prompt, después structured output, después RAG cuando necesita tus hechos, después herramientas, y por último un agent loop completo cuando la tarea de verdad necesita muchos pasos adaptativos. Cada peldaño suma poder, costo y nuevas formas de fallar. Empezá por abajo y subí solo cuando el problema te obligue — la mayoría de las funciones nunca necesitan llegar arriba.
- Problema
- Es tentador construir un agente cuando alcanzaba con un prompt.
- Idea
Prompt → Structured output → RAG → Tools → Agent loop; subí solo cuando te obliguen.
- Ejemplo
Clasificación de tickets: alcanza con un prompt con structured output — sin RAG, sin agente.
- Coste
- Cada peldaño suma costo y nuevas formas de romperse.
- Cuándo usarlo
- Al elegir el enfoque para cualquier función con LLM.
- Relaciones
Une Prompt, Structured output, RAG, Tool use, Agent loop.
LLM as a component — no la arquitectura
Un auto tiene un motor potente, pero está atornillado detrás de un cortafuego, alimentado con combustible limpio y rodeado de frenos — no es el auto entero.
Poné el modelo detrás de una interfaz, como cualquier otra dependencia, con validación alrededor de sus entradas y salidas y la libertad de cambiar de modelo o de proveedor. El LLM es una parte poderosa e inestable de tu sistema — no su cimiento. (La misma lección de "LLM como adaptador, no como arquitectura" del diseño de sistemas.)
- Problema
El código está soldado a un solo modelo y confía directo en su respuesta.
- Idea
El modelo detrás de su propia interfaz, con controles en la entrada y la salida.
- Ejemplo
La app llama a
complete(prompt); detrás podés cambiar el proveedor A por el B, o por un modelo local.- Coste
- Una capa fina de abstracción.
- Cuándo usarlo
- Siempre — desde el primer día.
- Relaciones
Usa Structured output y Guardrails; la misma idea que Hexagonal (puertos y adaptadores).
Cómo se conecta todo
Una orquesta: instrumentos distintos, pero tocan juntos, y cada uno apoya a los demás.
Los conceptos no viven solos. Los Embeddings impulsan la búsqueda del RAG; el RAG le da hechos a la Context engineering, que llena la Context window. El RAG habilita el Grounding, y el grounding, los Guardrails y los Evals juntos mantienen a raya la Hallucination. Structured output es la base del Tool use, las herramientas forman el Agent loop, y la Memory extiende su vida.
- ¿Cuál es el peldaño más simple — prompt, structured output, RAG, herramientas, agente — que resuelve esto?
- ¿De dónde salen los hechos — de la memoria del modelo (riesgoso), o de datos recuperados y citables?
- ¿Qué pasa cuando se equivoca, y es un lugar barato o caro para equivocarse?
- ¿Cómo voy a medir la calidad — cuál es el eval?
- ¿Cuáles son los guardrails en la entrada y en la salida?
- ¿Cuánto cuesta cada llamada, y qué tan lenta es?
- Un agent loop para algo que un solo prompt respondería.
- RAG sobre tres documentos que podrías simplemente pegar en el prompt.
- Ajustar prompts a ojo, sin un eval que te diga si mejoró.
- Enviar toda la base de conocimiento al contexto en cada llamada.
- Confiar en la salida del modelo directo a una base de datos o a un correo, sin validar.
- La salida es estructurada y validada antes de que tu código la use.
- Las respuestas están fundamentadas y son citables, no sacadas de la nada.
- Tenés un eval que te dice cuándo un cambio ayuda o perjudica.
- Hay guardrails tanto en la entrada como en la salida.
- Usaste el peldaño más simple que funciona — y el modelo está detrás de una interfaz que podrías cambiar.
Hoja de referencia: los 24 conceptos
El modelo
- Next-token predictionpredictor del próximo token
El modelo genera una continuación probable; no busca hechos.
- Context windowmemoria de trabajo
La única memoria del modelo — el texto de esta llamada.
- Hallucinationinvención confiada
Invención fluida y plausible. No se puede eliminar, solo acotar.
- Non-determinismmisma entrada, distinta salida
Una entrada, muchas salidas. Por eso hay que revisar y medir.
Prompting
- Promptel encargo
Un encargo claro: rol, tarea, restricciones, ejemplo.
- System promptinstrucciones permanentes
Reglas duraderas para toda la conversación; el user prompt es el pedido concreto.
- Few-shot promptingejemplos en el prompt
2–3 ejemplos entrada → salida en lugar de un párrafo de explicación.
- Structured outputJSON por esquema
Una respuesta con una forma que el código puede validar y usar.
Contexto
- Context engineeringarmar la ventana
Poné exactamente lo necesario en la ventana, en cada llamada.
- Relevance over completenessmenos, pero lo correcto
El texto de más diluye la atención y aumenta la probabilidad de alucinación.
- Context budgetpresupuesto de tokens
La ventana es un presupuesto escaso: recortá, resumí, cacheá.
Hechos (RAG)
- RAGRetrieval-Augmented Generation
Primero encontrá los fragmentos correctos de tus documentos, después respondé a partir de ellos.
- Embeddingsbúsqueda vectorial
Búsqueda por significado: los textos cercanos son vectores cercanos.
- Groundingcitas
Cada afirmación lleva a una fuente — así se puede verificar.
- Chunking & retrieval qualityla mitad poco glamorosa del RAG
Basura entra, basura confiada sale. Arreglá primero la recuperación.
Agentes
- Tool usefunction calling
El modelo pide una llamada a una función; tu código la ejecuta.
- Agent loopagente
El modelo en un bucle "pensar → actuar → observar".
- Agent memorymemoria fuera de la ventana
Notas y resúmenes fuera de la ventana, traídos cuando hacen falta.
- Human-in-the-loopla correa del agente
Límites de pasos, permisos, logs y una persona antes de las acciones riesgosas.
Fiabilidad
- Evalsbaterías de tests para IA
Tests para tu IA: sin ellos, ajustás a ojo.
- Guardrailscontroles de entrada y de salida
Código antes y después del modelo: bloquear, filtrar, validar.
- Cost & latencyplata y tiempo por llamada
Tokens × llamadas. Una restricción de diseño, no un detalle.
Construir bien
- Complexity ladderel menor poder que funcione
Prompt → structured output → RAG → herramientas → agente. Subí solo cuando te obliguen.
- LLM as a componentLLM como adaptador
El modelo es una pieza intercambiable del sistema, no su cimiento.
Construir con LLMs no es magia de prompts. Es ingeniería común — contexto, recuperación, validación, evals — alrededor de un componente extraordinario e inestable.