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.
Solo la esencia · Una imagen por idea · Ingeniería antes que magia
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.
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.
No tiene memoria entre llamadas
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.
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.
Es no determinista — tratalo como tal
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. Así que no podés tratar a un LLM como una función con un retorno fijo; lo tratás como input inteligente, falible y no determinista — para ser restringido, validado y verificado, nunca confiado a ciegas. Esa mentalidad es todo el juego.
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 qué 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.
Un prompt es un brief, no un hechizo
Entregarle una tarea a un nuevo empleado avispado: quién está siendo, qué querés, las restricciones y un ejemplo de «lo bueno». Brief vago, resultado vago.
Un buen prompt enuncia el rol («sos un editor cuidadoso»), la tarea, las restricciones (largo, tono, formato) e idealmente un ejemplo. No hay palabras mágicas — solo instrucciones claras, las mismas que le darías a una persona capaz. La mayoría de los problemas de prompt son en realidad problemas de especificación.
System vs user: reglas permanentes vs la solicitud
La política permanente de un restaurante — «somos vegetarianos, cerramos a las diez» — versus el pedido específico de esta noche. Una enmarca todo; el otro es lo que se pide.
El system prompt fija el comportamiento duradero — rol, reglas, tono — que se sostiene a lo largo de toda la conversación. El user prompt es la solicitud específica. Poner tu persona y tus guardrails en el system prompt los mantiene estables mientras varían los mensajes del usuario.
Mostrá, no solo describas: ejemplos few-shot
Enseñarle a alguien un formato mostrándole tres ejemplos terminados es más rápido y más claro que describirlo con palabras.
A menudo la mejor manera de obtener la forma de respuesta que querés es incluir unos pocos ejemplos de input y salida deseada justo en el prompt («few-shot»). El modelo los reconoce por patrón mejor de lo que sigue una descripción abstracta. Dos o tres buenos ejemplos pueden ganarle a un párrafo de instrucciones.
Pedí estructura que tu código pueda usar
Un formulario con casillas etiquetadas te da datos rellenables; «escribime un párrafo sobre esto» te da prosa que después tenés que parsear.
Si tu programa va a consumir la salida, pedí salida estructurada — JSON que coincida con un esquema, no texto libre. Los modelos modernos pueden ser restringidos a JSON válido, convirtiendo al LLM de un chatbot en un componente del que tu código puede depender. La salida estructurada es el puente entre el lenguaje y el software.
No hay palabras mágicas. Un buen prompt es un brief claro — rol, tarea, restricciones, ejemplos.
A medida que las apps se ponen serias, el oficio se corre de redactar el prompt a ensamblar el contexto correcto. Esta es la verdadera disciplina — la «ingeniería de contexto».
La parte difícil es qué ponés en la ventana
Un abogado gana no por una frase ingeniosa sino por entregarle al juez exactamente los documentos correctos, en el orden correcto, sin nada irrelevante.
La «ingeniería de prompts» se trataba de la redacción; la ingeniería de contexto se trata de ensamblar la información correcta — los hechos, el historial y las herramientas relevantes — en la ventana para cada llamada. La respuesta del modelo es tan buena como lo que pongas frente a él. La mayoría de los problemas de calidad son problemas de contexto, no de redacción.
La relevancia le gana a la completitud
Un informe que es una página filosa le gana a 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 debería ganarse su lugar: el texto irrelevante diluye la atención del modelo, cuesta dinero y de hecho aumenta la probabilidad de alucinación en contextos largos. La habilidad está en seleccionar las pocas cosas que importan, no en embutir todo lo que podría.
La context window es un presupuesto
Una valija con un límite de peso — empacás lo que realmente vas a necesitar, no todo tu guardarropa, porque hay un tope duro y un recargo.
La ventana es finita, y cada token cuesta latencia y dinero. Así que la gastás deliberadamente: recortás el historial, resumís lo viejo, recuperás solo lo relevante ahora. Tratar el contexto como un presupuesto escaso — no como un vertedero infinito — es lo que separa un juguete de un producto.
La ingeniería de prompts es la redacción. La ingeniería de contexto son los documentos. La segunda es donde vive la calidad.
El modelo no conoce tus datos, ni nada posterior a su corte de entrenamiento. RAG es cómo le entregás los hechos a partir de los cuales responder — el patrón más importante en las apps serias de LLM.
RAG: recuperá primero, después respondé
Un examen a libro abierto — en vez de confiar en la memoria, buscás primero las páginas relevantes, después escribís la respuesta a partir de lo que tenés delante.
Retrieval-Augmented Generation significa: tomar la pregunta del usuario, traer los fragmentos más relevantes de tus documentos, ponerlos en el contexto y pedirle al modelo que responda a partir de ellos. Ahora trabaja desde tus datos reales, no desde su memoria difusa. Así es como los asistentes responden sobre tu producto, tus docs, tu base de conocimiento.
Los embeddings y la búsqueda vectorial encuentran los fragmentos correctos
Un bibliotecario que encuentra libros por lo que tratan, no por el título exacto — «cosas como esta», por significado.
Para encontrar fragmentos relevantes, guardás tus documentos como embeddings en una vector database y buscás por similitud con la pregunta (el motor del curso de bases de datos). Una buena recuperación es el corazón de RAG: metés los fragmentos correctos y la respuesta queda grounded; metés basura y el modelo responde con confianza a partir de basura.
El grounding mata la alucinación — casi siempre
Un periodista que debe citar una fuente para cada afirmación escribe muchas menos fabricaciones que uno que escribe de memoria.
La gran victoria de RAG es el grounding: como la respuesta se extrae de texto recuperado, podés exigir citas y verificar que las afirmaciones estén efectivamente respaldadas. No borra la alucinación, pero la reduce drásticamente — y te deja atrapar lo que se escapa. Una respuesta que podés rastrear hasta una fuente es una en la que podés confiar.
Basura adentro, basura confiada afuera
Entregale a alguien el archivo equivocado y pedile que lo resuma — te dará un resumen perfecto de la cosa equivocada.
RAG solo funciona si la recuperación funciona. Mal chunking, una búsqueda débil, datos desactualizados — y el modelo responde fielmente desde el contexto equivocado, sonando igual de seguro. Así que la mayor parte del esfuerzo en RAG no es el modelo; es el chunking, el indexado y la medición de la calidad de recuperación. Arreglá la recuperación antes de culpar al modelo.
No le preguntes al modelo qué sabe. Entregale 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 loop. Eso es un agente.
Tool use: dejá que llame a tus funciones
Un asistente avispado que no puede alcanzar el archivador por sí mismo — pero puede pedirte que lo hagas, y decirte exactamente qué archivo sacar.
Con tool use (function calling), describís las funciones que el modelo puede solicitar — 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 mantiene el control de hacerlo. Así es como un LLM alcanza más allá del texto hacia el mundo real.
Un agente es el modelo en un loop
Una persona resolviendo un problema: pensar, tomar una acción, mirar el resultado, pensar de nuevo — repitiendo hasta terminar, no de un solo tiro.
Un agente cablea el modelo dentro de un loop — razonar, llamar a una herramienta, observar el resultado, razonar de nuevo — con el LLM como orquestador decidiendo cada paso siguiente. Esto le permite manejar tareas abiertas («investigá esto y redactá una respuesta») que ningún prompt único podría. Los asistentes de código y los bots de investigación funcionan así.
Memoria más allá de la ventana
Un proyecto largo necesita un cuaderno — no podés sostener 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 memoria: notas, resúmenes e historial recuperable guardados fuera del contexto y traídos de vuelta cuando son relevantes. Sin ella, un agente olvida el comienzo de una tarea larga para cuando llega al final. La memoria es lo que convierte un chat en algo que puede trabajar a lo largo del tiempo.
Los loops son poderosos — y un pasivo
Una aspiradora robot que mayormente limpia la casa, pero de vez en cuando se queda trabada girando en un rincón o se mete en la pileta.
Un loop de agente es impredecible: puede tomar caminos equivocados, repetirse, disparar el costo o actuar sobre una mala decisión. Así que lo mantenés con correa — límites de pasos, permisos de herramientas, aprobación humana para acciones riesgosas, logging completo. Echá mano de un agente solo cuando la tarea genuinamente necesita muchos pasos adaptativos; una sola llamada o una cadena fija es más barata y más segura cuando alcanza.
Las herramientas dejan que el modelo actúe. Un loop lo deja persistir. Ambos necesitan correa — capacidad sin límites es un pasivo.
Un demo que funciona una vez es fácil. Un sistema en el que podés confiar lleva el trabajo poco glamoroso — 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 — y ninguna forma de mejorar.
Un eval es un conjunto de pruebas para tu IA: inputs con expectativas conocidas como buenas, puntuados automáticamente — ¿recuperó los docs correctos, llamó a la herramienta correcta, respondió con fidelidad? Sin evals estás ajustando prompts por vibras. Y esperá una verdad dura: llegar al 80% de calidad es rápido; moler desde ahí hasta el 95% es la mayor parte del trabajo.
Guardrails: límites sobre el input y el output
Los topes en una pista de bowling — no tiran la bola por vos, pero la mantienen fuera de la canaleta.
Los guardrails son verificaciones alrededor del modelo: a la entrada, bloquean la prompt-injection y las solicitudes 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 vigile a sí mismo.
El costo y la latencia son restricciones de diseño
El taxímetro corriendo durante 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 escala con cuánto contexto enviás y cuántas llamadas hacés. Así que diseñás para ello: recortás y cacheás el contexto, elegís el modelo más chico que sea suficientemente bueno, y no corrés un loop de agente donde alcanza con una llamada. Una gran respuesta que es demasiado lenta o demasiado cara no es una gran respuesta.
La alucinación es el riesgo alrededor del cual diseñás
No le entregás el micrófono sin supervisión a un narrador brillante pero inestable — verificás los hechos antes de que vaya a la imprenta.
Cada técnica acá — grounding con RAG, salida estructurada, evals, guardrails, citas — existe para manejar un riesgo central: que el modelo enuncie falsedades de forma convincente. Nunca lo eliminás del todo; restringís dónde puede ocurrir, lo detectás cuando ocurre, y nunca dejás que una afirmación no verificada llegue a un lugar donde estar equivocado sale caro.
Un 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 simple a complejo. La habilidad está en usar el menos poderoso que resuelva tu problema — y en tratar al modelo como un componente, no como la arquitectura.
Subí la escalera solo hasta donde debas
No reservás un camión de mudanzas para llevar una caja al otro lado de la habitación. Escalás el esfuerzo al trabajo.
Hay una escalera: un solo buen prompt, después salida estructurada, después RAG cuando necesita tus hechos, después herramientas, después un loop de agente completo cuando la tarea de verdad necesita muchos pasos adaptativos. Cada peldaño suma poder, costo y nuevas formas de fallar. Empezá abajo y subí solo cuando el problema te obligue — la mayoría de las features nunca necesitan la cima.
El LLM es un componente, no la arquitectura
Un auto tiene un motor poderoso, pero está atornillado detrás de un cortafuegos, 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 inputs y outputs y la libertad de intercambiar modelos o proveedores. El LLM es una parte poderosa e inestable de tu sistema — no su cimiento. (La misma lección de «el LLM como un adapter, no como la arquitectura» del diseño de sistemas.)
- Cuál es el peldaño más simple — prompt, salida estructurada, RAG, herramientas, agente — que resuelve esto? - De dónde vienen los hechos — la memoria del modelo (riesgoso), o datos recuperados y citables? - Qué pasa cuando se equivoca, y ese lugar es barato o caro para estar equivocado? - Cómo voy a medir la calidad — cuál es el eval? - Cuáles son los guardrails sobre el input y el output? - Cuánto cuesta por llamada, y qué tan lento es?
- Un loop de agente para lo que un solo prompt respondería. - RAG sobre tres documentos que podrías simplemente pegar en el prompt. - Ajustar prompts por vibras, sin un eval que te diga si mejoró. - Enviar la base de conocimiento entera al contexto en cada llamada. - Confiar la salida del modelo directo a una base de datos o un email, sin validar.
- La salida está estructurada y validada antes de que tu código la use. - Las respuestas están grounded y son citables, no sacadas de la nada. - Tenés un eval que te dice cuándo un cambio ayuda o perjudica. - Los guardrails se sientan tanto sobre el input como sobre el output. - Usaste el peldaño más simple que funciona — y el modelo se sienta detrás de una interfaz que podrías intercambiar.
Construir con LLMs no es magia de prompts. Es ingeniería corriente — contexto, recuperación, validación, evals — alrededor de un componente extraordinario e inestable.