# Un LLM predice; vos hacés la ingeniería del resto Curso exprés sobre cómo construir con grandes modelos de lenguaje. 24 conceptos — predicción del próximo token, context window, alucinación, few-shot, salida estructurada, ingeniería de contexto, RAG, embeddings, grounding, tool use, agent loop, evals, guardrails y más — cada uno con su nombre en inglés, un diagrama, una ficha y un ejemplo. Termina con una hoja de referencia de una página con todos los conceptos y cómo se conectan. - **Author:** Fedor Chishchin - **Level:** intro - **Reading time:** ~35 minutos de lectura - **Published:** 2026-06-02 - **Source:** https://fedorthinks.com/es/learn/building-with-llms-express --- ## 1. Qué es un LLM (y qué no) 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. _Diagram: Siete grupos de conceptos — los capítulos los siguen._ ### 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.** _Diagram: El modelo puntúa los posibles próximos tokens, elige uno probable, lo agrega y repite._ #### Next-token prediction (predictor del próximo token) - **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. _Diagram: El modelo solo ve lo que hay en la ventana de esta llamada. Si no está en la ventana, para el modelo no existe._ #### Context window (la memoria de trabajo del modelo) - **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.** _Diagram: La verdad y la invención salen del modelo con la misma confianza — por el tono no se distinguen._ #### Hallucination (invención confiada) - **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. _Diagram: Tres llamadas con un mismo prompt — tres respuestas ligeramente distintas. Por eso la salida siempre se revisa._ #### Non-determinism (misma entrada, distinta salida) - **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**. > **Antes de construir:** «¿Lo estoy tratando como una función confiable — o como un pasante brillante, olvidadizo y que a veces miente?» > Un LLM no sabe cosas. Las predice. Construí todo lo demás alrededor de esa única verdad. ## 2. El prompt 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. _Diagram: Cuatro partes de un buen encargo: rol, tarea, restricciones, ejemplo._ #### Prompt (el encargo) - **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. _Diagram: El system prompt enmarca cada turno; el user prompt cambia en cada turno._ #### System prompt (instrucciones permanentes) - **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. _Diagram: Dos ejemplos entrada → salida en el prompt — y el modelo continúa el mismo patrón con la entrada nueva._ #### Few-shot prompting (ejemplos en el prompt) - **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.** _Diagram: El texto libre hay que parsearlo a ojo; un JSON que cumple un esquema se puede verificar y pasar directo al código._ #### Structured output (modo JSON, salida por esquema) - **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**. > **La pregunta del prompt:** «Un desconocido inteligente, con exactamente este prompt y nada más, ¿produciría lo que quiero?» > No hay palabras mágicas. Un buen prompt es un encargo claro — rol, tarea, restricciones, ejemplos. ## 3. De prompts a contexto 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.** _Diagram: De muchas fuentes, elegí lo que importa y armá la ventana — nueva en cada llamada._ #### Context engineering (armar la ventana) - **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. _Diagram: Izquierda: una ventana repleta donde la señal se ahoga en el ruido. Derecha: solo lo que la respuesta necesita._ ### 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.** _Diagram: La ventana se reparte entre sus partes y choca con un tope duro. Cuatro palancas: recortar, resumir, recuperar, cachear._ #### Context budget (presupuesto de tokens) - **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**. > **La pregunta del contexto:** «¿Todo lo que hay en esta ventana se está ganando su lugar — o estoy tirando texto y esperando lo mejor?» > Prompt engineering es la redacción. Context engineering son los documentos. En el segundo vive la calidad. ## 4. Darle los hechos 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. _Diagram: Pregunta → búsqueda en tus documentos → los mejores fragmentos van al prompt junto con la pregunta → una respuesta con citas._ #### RAG (Retrieval-Augmented Generation) - **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. _Diagram: Los textos con significado parecido quedan cerca unos de otros. Buscar es encontrar a los vecinos más cercanos de la pregunta._ #### Embeddings (búsqueda vectorial) - **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.** _Diagram: Cada afirmación lleva a una fuente. Una afirmación sin fuente es una señal: marcala o descartala._ #### Grounding (citas) - **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. _Diagram: Cualquier paso antes del modelo puede romperse — y el resultado igual suena seguro._ #### Chunking & retrieval quality (la mitad poco glamorosa del RAG) - **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**. > **La pregunta del RAG:** «¿El modelo responde a partir de hechos recuperados y citables — o de su propia memoria borrosa?» > No le preguntes al modelo qué sabe. Dale los hechos y pedile que responda a partir de ellos. ## 5. Herramientas y agentes 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.** _Diagram: El modelo solo pide la llamada a la herramienta. Tu código la ejecuta — y le devuelve el resultado al modelo._ #### Tool use (function calling) - **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í. _Diagram: Razonar → Actuar → Observar, y otra vez — hasta cumplir el objetivo._ #### Agent loop (agente) - **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. _Diagram: El agente escribe lo importante en un almacén externo y trae de vuelta solo lo que necesita ahora._ #### Agent memory (memoria fuera de la ventana) - **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. _Diagram: La correa del agente: un límite de pasos, una lista de herramientas permitidas, logs y una persona antes de cualquier acción riesgosa._ #### Human-in-the-loop (la correa del agente) - **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**. > **La pregunta del agente:** «¿Esto de verdad necesita un bucle adaptativo de varios pasos — o una llamada, o una cadena fija, haría el trabajo con más seguridad?» > Las herramientas le permiten al modelo actuar. Un bucle le permite persistir. Los dos necesitan una correa — capacidad sin límites es una responsabilidad. ## 6. Volverlo confiable 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.** _Diagram: Conjunto de pruebas → tu sistema → puntuación automática. Cambiás el prompt, volvés a correr, comparás._ #### Evals (baterías de tests para IA) - **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. _Diagram: Un control a la entrada y un control a la salida — en tu código, a ambos lados del modelo._ #### Guardrails (controles de entrada y de salida) - **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. _Diagram: Costo ≈ tokens por llamada × cantidad de llamadas. Cuatro palancas para bajarlo._ #### Cost & latency (plata y tiempo por llamada) - **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. _Diagram: Capas de defensa: cada una atrapa algunas afirmaciones falsas, así que lo que llega al usuario ya fue verificado._ > **La pregunta de la fiabilidad:** «¿Cómo mido que esto está bien, acoto dónde puede salir mal y lo atrapo cuando sale mal?» > Una demo confía en el modelo. Un producto lo mide, lo acota y lo vigila — porque es no determinista por naturaleza. ## 7. Construir bien 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. _Diagram: Cinco peldaños: cada uno más alto es más poderoso, más caro y más frágil. Empezá por el primero._ #### Complexity ladder (el menor poder que funcione) - **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.) _Diagram: La app habla con una interfaz; los proveedores se enchufan como adaptadores; la entrada y la salida se verifican._ #### LLM as a component (LLM como adaptador) - **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. _Diagram: Los vínculos principales entre los conceptos del curso._ #### Antes de enviar una función con LLM a producción - **¿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? #### Señales de que te pasaste de complicado - 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. #### Señales de que lo construiste bien - 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 prediction** (predictor del próximo token): El modelo genera una continuación probable; no busca hechos. - **Context window** (memoria de trabajo): La única memoria del modelo — el texto de esta llamada. - **Hallucination** (invención confiada): Invención fluida y plausible. No se puede eliminar, solo acotar. - **Non-determinism** (misma entrada, distinta salida): Una entrada, muchas salidas. Por eso hay que revisar y medir. ### Prompting - **Prompt** (el encargo): Un encargo claro: rol, tarea, restricciones, ejemplo. - **System prompt** (instrucciones permanentes): Reglas duraderas para toda la conversación; el user prompt es el pedido concreto. - **Few-shot prompting** (ejemplos en el prompt): 2–3 ejemplos entrada → salida en lugar de un párrafo de explicación. - **Structured output** (JSON por esquema): Una respuesta con una forma que el código puede validar y usar. ### Contexto - **Context engineering** (armar la ventana): Poné exactamente lo necesario en la ventana, en cada llamada. - **Relevance over completeness** (menos, pero lo correcto): El texto de más diluye la atención y aumenta la probabilidad de alucinación. - **Context budget** (presupuesto de tokens): La ventana es un presupuesto escaso: recortá, resumí, cacheá. ### Hechos (RAG) - **RAG** (Retrieval-Augmented Generation): Primero encontrá los fragmentos correctos de tus documentos, después respondé a partir de ellos. - **Embeddings** (búsqueda vectorial): Búsqueda por significado: los textos cercanos son vectores cercanos. - **Grounding** (citas): Cada afirmación lleva a una fuente — así se puede verificar. - **Chunking & retrieval quality** (la mitad poco glamorosa del RAG): Basura entra, basura confiada sale. Arreglá primero la recuperación. ### Agentes - **Tool use** (function calling): El modelo pide una llamada a una función; tu código la ejecuta. - **Agent loop** (agente): El modelo en un bucle "pensar → actuar → observar". - **Agent memory** (memoria fuera de la ventana): Notas y resúmenes fuera de la ventana, traídos cuando hacen falta. - **Human-in-the-loop** (la correa del agente): Límites de pasos, permisos, logs y una persona antes de las acciones riesgosas. ### Fiabilidad - **Evals** (baterías de tests para IA): Tests para tu IA: sin ellos, ajustás a ojo. - **Guardrails** (controles de entrada y de salida): Código antes y después del modelo: bloquear, filtrar, validar. - **Cost & latency** (plata y tiempo por llamada): Tokens × llamadas. Una restricción de diseño, no un detalle. ### Construir bien - **Complexity ladder** (el menor poder que funcione): Prompt → structured output → RAG → herramientas → agente. Subí solo cuando te obliguen. - **LLM as a component** (LLM 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. Fin del curso exprés · 7 capítulos · 24 conceptos Lo que sigue es la práctica: leé la documentación de tu proveedor de modelos — las guías de Anthropic y de OpenAI sobre prompting, tool use y evals — y construí algo chico de punta a punta: un prompt, después un RAG, después una herramienta. Pero quedate con una idea por encima de las demás. El modelo es la parte fácil. La ingeniería alrededor — contexto, grounding, medición, límites — es donde se hace un producto de verdad.