las ecuaciones de esta slide
pθ(xt+1 | x1:t) = softmax(WOht)(Ec. 1)
el LLM entero, en una línea: dado el prefijo x1:t (todo lo escrito hasta ahora), el Transformer lo comprime en un vector ht ∈ ℝd (el último estado oculto), la matriz de salida WO ∈ ℝ|𝒱|×d lo proyecta a un número por palabra del vocabulario 𝒱 (los logits), y el softmax los convierte en una distribución de probabilidad sobre el siguiente token.
softmax(z)i = eziΣj ezj    ℒ(θ) = Σt=1..T−1 log pθ(xt+1 | x1:t)(Ec. 2)
el softmax exponencia cada logit y divide por la suma: salen números positivos que suman 1 (compruébalo en el lector). El entrenamiento maximiza ℒ(θ): la log-probabilidad del token verdadero en cada posición, sobre ~1013 tokens de internet. No hay más objetivo que ese.
guion paso a paso
  1. Cambia de prefijo con el desplegable mirando las barras de arriba. La distribución entera cambia con el contexto: el "conocimiento" del modelo es esta tabla condicional, no una base de datos de frases.
  2. Pulsa "muestrear 1 token" diez veces con el mismo prefijo. Casi siempre sale el token más probable, pero no siempre: generar texto es tirar un dado cargado, no consultar una respuesta fija.
  3. Pulsa "muestrear 100" varias veces y compara el panel de abajo con el de arriba. Las frecuencias empíricas (barras huecas) se pegan a las probabilidades teóricas: la ley de los grandes números, en vivo.
  4. Lee en el lector la suma de probabilidades. Siempre 1.000: el softmax reparte toda la probabilidad entre los 12 tokens, no inventa ni pierde masa.
Comprueba que entiendes: ¿dónde está "guardada" la respuesta del LLM antes de pulsar muestrear?
En ningún sitio. Antes de muestrear solo existe la distribución pθ(·|prefijo): 12 números que suman 1. La "respuesta" nace al tirar el dado. Por eso dos llamadas idénticas pueden dar textos distintos, y por eso la slide siguiente (temperatura) puede hacer al modelo más o menos atrevido sin tocar ni un peso de la red: solo deforma estos 12 números antes de tirar el dado.

Setup. Un LLM de juguete con vocabulario de 12 tokens de negocio (churn telco: cliente, contrato, precio, cancela, renueva…). Para cada prefijo he fijado el vector de logits z = WOht que produciría el Transformer; el JS aplica el softmax de la Ec. (1) de verdad y pinta arriba la distribución resultante. Abajo, las frecuencias con que de verdad han salido los tokens al pulsar "muestrear" (el dado usa mulberry32, reproducible).

Juega. Un LLM real hace exactamente esto con |𝒱| ≈ 50 000 subwords y un ht de miles de dimensiones, una vez por token generado: una respuesta de 500 tokens son 500 tiradas de este dado, cada una condicionada a todo lo anterior.

Mensaje. "Predecir el próximo token" suena humilde, pero obliga al modelo a aprender gramática, hechos y razonamiento: todo lo que ayude a acertar la siguiente palabra de internet. La "creatividad" que verás en las dos slides siguientes es solo cómo de cargado está el dado.

Términos. token: unidad mínima de texto (≈ trozo de palabra). logit: puntuación real previa al softmax, una por token. softmax: exponenciar y normalizar; convierte puntuaciones en probabilidades. x1:t: el prefijo, todo el texto visible hasta el paso t.

las ecuaciones de esta slide
pτ(x | x1:t) = softmax(logits(x)τ)  ⇔  pi ∝ ezi/τ(Ec. 3)
la temperatura τ divide todos los logits antes del softmax. Con τ<1 las diferencias entre logits se agrandan y el token líder acapara la probabilidad (τ→0 = greedy, determinista); con τ>1 se encogen y la distribución se aplana (τ→∞ = uniforme, 1/12 cada uno). Los logits no cambian: solo su reparto.
H(p) = −Σi pi log2 pi   (bits),    perplejidad = 2H
la entropía mide la incertidumbre del dado: 0 bits si un token tiene probabilidad 1; log212 ≈ 3.58 bits si los 12 son equiprobables. La perplejidad 2H se lee como "número efectivo de tokens entre los que duda el modelo".
guion paso a paso
  1. Baja τ a 0.1 mirando las barras. El token líder se come casi toda la probabilidad y la entropía cae hacia 0 bits: dado casi seguro.
  2. Sube τ a 2. Las barras se igualan y la entropía sube hacia los 3.58 bits del dado justo de 12 caras: el modelo "duda de todo".
  3. Con τ = 0.2, pulsa "generar 12 tokens" tres veces seguidas sin cambiar la semilla. Salen los mismos tokens, dominados por el líder: misma semilla + dado afilado = texto reproducible y monótono.
  4. Sube a τ = 1.5 y vuelve a generar tres veces con la misma semilla. La secuencia cambia de carácter: los mismos números aleatorios ahora caen en tokens distintos porque la distribución es plana. La diversidad viene de τ, no de la suerte.
Comprueba que entiendes: ¿por qué τ no cambia nunca el ORDEN de los tokens?
Porque dividir por τ>0 es una transformación monótona de los logits: si zi > zj, entonces zi/τ > zj/τ y, como la exponencial es creciente, pi > pj para cualquier τ. La temperatura redistribuye probabilidad entre los mismos candidatos en el mismo orden; jamás hace al segundo más probable que al primero. Por eso "bajar la temperatura" nunca puede corregir un modelo que pone el token equivocado en cabeza.

Setup. Mismos 12 tokens y mismos logits que la slide anterior (prefijo "Si subimos el precio, la demanda…"). El slider de τ alimenta la Ec. (3) tal cual: el JS divide los logits por τ, aplica softmax y pinta las barras; la curva de abajo es la entropía H(τ) calculada en una rejilla de temperaturas, con el punto dorado en tu τ actual.

Juega. El botón "generar 12 tokens" tira el dado 12 veces con la misma semilla (mulberry32): así la única diferencia entre corridas es τ, no el azar. Es el experimento limpio que en producción nunca ves.

Mensaje. En producción: extracción de campos de una factura τ = 0 (greedy, reproducible); asistente corporativo τ ≈ 0.2–0.3; redacción τ ≈ 0.7; brainstorming de campañas τ ≈ 0.9–1.1. Cualquier respuesta crítica de negocio: τ ≤ 0.3.

Términos. greedy: elegir siempre el token más probable (τ→0). entropía H: incertidumbre media del dado, en bits. perplejidad: 2H, nº efectivo de opciones. semilla: estado inicial del generador pseudoaleatorio; fijarla hace el muestreo reproducible.

las ecuaciones de esta slide
top-k:  Vk = {los k tokens de mayor p},   p̃i = pi·𝟙[i∈Vk]Σj∈Vk pj
top-k trunca: ordena los tokens por probabilidad, se queda con los k primeros y renormaliza (divide por la masa superviviente para que vuelva a sumar 1). k es fijo: corta igual de ancho esté la distribución afilada o plana.
top-p:  Sp = el menor conjunto con Σi∈Sp p(i) ≥ p  (núcleo),  luego renormalizar
top-p (nucleus) acumula desde el token más probable hacia abajo y corta en cuanto la suma alcanza p: el nº de supervivientes es adaptativo — pocos si la distribución está concentrada, muchos si está plana. Los APIs suelen traer τ = 0.7, top-p = 0.9 por defecto.
guion paso a paso
  1. Con τ = 1 y k = 12, baja p de 1.00 a 0.50 despacio. Los tokens de cola se tachan uno a uno y los supervivientes crecen al renormalizar: la masa descartada se reparte entre los que quedan.
  2. Pon p = 1 y baja k de 12 a 1. Con k = 1 sobrevive solo el líder con p̃ = 1.000: top-k extremo = greedy, da igual la temperatura.
  3. Fija p = 0.9 y compara τ = 0.4 con τ = 1.8 mirando el nº de supervivientes. Con τ baja el núcleo son 1–2 tokens; con τ alta, 8 o más: top-p se adapta a la forma de la distribución, top-k no.
  4. Activa los dos a la vez: k = 4, p = 0.6. Sobrevive la intersección (primero corta k, luego p dentro de los k): los filtros se componen, siempre gana el más estricto.
Comprueba que entiendes: ¿para qué truncar, si la temperatura ya controla el riesgo?
Porque la temperatura aplana o afila TODA la distribución, pero nunca pone un cero: con τ alta, un token absurdo de probabilidad 0.1% sigue pudiendo salir (y en una respuesta de 500 tokens, tienes 500 oportunidades de que salga uno). Top-k/top-p ponen probabilidad exactamente 0 en la cola: permiten diversidad entre los candidatos razonables (gracias a τ) sin exponerse jamás a los disparates. Por eso en producción se combinan: τ da el "tono" y top-p pone la red de seguridad.

Setup. Mismos logits del prefijo de demanda. El pipeline del JS es el real de los APIs: logits → dividir por τ → softmax → filtro top-k → filtro top-p sobre lo que quede → renormalizar. Arriba: las barras grises tenues son la probabilidad antes del filtro en los tokens descartados (con aspa); las doradas, la probabilidad renormalizada de los supervivientes. Abajo: la probabilidad acumulada ordenada de mayor a menor, con la línea de corte de tu p; es la definición visual del núcleo.

Juega. El lector te da los dos recuentos (cuántos pasan el top-k, cuántos el top-p), la masa que retenía el núcleo antes de renormalizar y la comprobación Σp̃ = 1.000 tras renormalizar.

Mensaje. Para un chatbot bancario tipo BBVA querrás τ ≈ 0.3 y top-p ≈ 0.9: respuestas estables que jamás muestrean la cola; para brainstorming de campañas, τ ≈ 1 y top-p alto. Son dos mandos distintos: forma del dado (τ) y qué caras se pegan con cinta (k, p).

Términos. truncar: poner probabilidad 0 fuera del conjunto elegido. renormalizar: dividir por la masa superviviente para volver a sumar 1. núcleo (nucleus): el menor conjunto de tokens que acumula masa ≥ p. p(i): probabilidades ordenadas de mayor a menor.

las ecuaciones de esta slide
p(x1:T) = Πt=1..T−1 pθ(xt+1 | x1:t)(regla de la cadena)
una frase entera es un producto de condicionales: el modelo nunca "planifica" la frase, solo encadena predicciones del siguiente token. La probabilidad de la frase completa es el producto de las probabilidades de cada elección (por eso frases largas y raras tienen probabilidad minúscula).
bucle:  x̂t+1 ∼ pτ,k,p(· | x1:t) →  x1:t+1 = [x1:t, x̂t+1] →  repetir hasta FIN
la generación autorregresiva: muestrear con el pipeline τ/top-k/top-p de las slides anteriores, concatenar el token al contexto y volver a empezar. Cada token generado condiciona todos los siguientes: un mal token temprano arrastra al resto de la frase.
guion paso a paso
  1. Con τ = 0.1, pulsa "generar 5 frases". Las cinco son idénticas (la frase modal): dado afilado = generador casi determinista, como un autocompletar.
  2. Sube a τ = 0.7 y genera otras 5. Frases distintas pero todas gramaticales: la diversidad útil vive en temperaturas moderadas.
  3. Sube a τ = 2 con top-p = 1 y genera 5. Aparecen incoherencias ("el contrato baja el modelo…"): a temperatura alta el dado visita transiciones de probabilidad ínfima.
  4. Deja τ = 2 pero pon top-p = 0.6. Las incoherencias casi desaparecen sin perder variedad: el truncamiento poda la cola absurda. Mira en el panel inferior cómo sube la probabilidad media por paso.
Comprueba que entiendes: ¿por qué un token malo al principio estropea TODA la frase?
Por la regla de la cadena: el token t entra en el condicionante de todos los posteriores. Si a τ alta sale "mañana" justo después de "el cliente", el modelo queda atrapado: debe continuar un prefijo que ya es raro, y todas sus condicionales están ahora evaluadas en una zona del espacio de frases donde tiene poca probabilidad buena que repartir. En los LLM reales es igual: las alucinaciones suelen empezar en UNA mala elección temprana que el resto de la respuesta se ve obligado a justificar.

Setup. Un "LLM" mínimo de verdad: 13 estados (palabras o sintagmas de negocio: el cliente, la demanda, renueva, cancela… y FIN) y una matriz de logits de bigramas Z[i][j] = puntuación de pasar de la palabra i a la j. En cada paso el JS aplica el pipeline completo de las slides anteriores (dividir por τ, softmax, top-k, top-p, renormalizar, muestrear con mulberry32) a la fila del estado actual, concatena y repite hasta FIN (máx. 9 tokens). Arriba: la matriz de transición a tu τ como heatmap (blanco→dorado→sepia = probabilidad creciente). Abajo: para la última frase generada, la probabilidad que tenía el token elegido en cada paso.

Lee así. El heatmap es el "modelo"; las frases son muestras de la regla de la cadena. La probabilidad de la frase (producto de las barras de abajo) sale en el lector junto a su log-probabilidad.

Mensaje. Esto, escalado de 13 estados a 50 000 subwords y de bigramas a contextos de 200K tokens, ES un LLM generando la respuesta de tu chatbot: una cadena de dados condicionados. Spotify generando descripciones de playlists o Inditex redactando fichas de producto ajustan exactamente estos tres mandos.

Términos. autorregresivo: cada salida se realimenta como entrada. bigrama: par (palabra actual, palabra siguiente); aquí el contexto es solo la última palabra, en un LLM real es todo x1:t. frase modal: la de máxima probabilidad, la que produce τ→0.

las ecuaciones de esta slide
Ntokens ≈ caracteres4 ≈ palabras × 1.3(regla de pulgar)
los LLM no cobran por palabras sino por tokens (subwords). En español/inglés, un token son ~4 caracteres o ~0.75 palabras: dos estimaciones independientes que el lector calcula a la vez para que veas que casi coinciden.
C = Nin106 pin + Nout106 pout,    Cmes = 30 · R · C(Ec. 4)
el coste de una llamada: tokens de entrada y de salida, cada uno a su precio por millón (pout suele ser ~5× pin: generar es más caro que leer). R = peticiones/día. Todo coste de LLM en cloud se reduce a esta ecuación.
guion paso a paso
  1. Deja los valores por defecto (email comercial de ~2.600 caracteres, Sonnet a 3/15 $/M). Una llamada cuesta ~0.011 $: leer el email son ~650 tokens (0.002 $) y la respuesta de 600 tokens cuesta 0.009 $ — la salida domina aunque sea más corta.
  2. Sube el prompt a 40.000 caracteres (un informe entero). La entrada pasa a dominar: con contexto largo, leer es lo que pagas. Esta es la motivación del prompt caching (slide siguiente).
  3. Sube R a 50.000 peticiones/día con el resto por defecto. ~16.000 $/mes en LLM frente a 4.5 M$/mes del call center humano a 3 $/consulta (línea gris del panel inferior): más de dos órdenes de magnitud, el argumento del caso BBVA.
  4. Baja pin/pout a 0.5/2 (un modelo pequeño). El coste cae ~7× sin tocar el tráfico: elegir modelo ES una decisión de coste, no solo de calidad (slide de elección).
Comprueba que entiendes: ¿por qué la salida cuesta ~5 veces más cara por token que la entrada?
Por la slide anterior: la entrada se procesa en paralelo en una sola pasada del Transformer (leer 8.000 tokens es UNA pasada), pero cada token de salida exige una pasada completa nueva del modelo, porque la generación es autorregresiva: token a token, 600 pasadas para 600 tokens. El precio refleja el cómputo: generar es secuencial y caro; leer es paralelo y barato. Por eso pedir respuestas concisas ("responde en 3 frases") es la optimización de coste más barata que existe.

Setup. El caso: un asistente que lee emails comerciales de clientes (churn telco) y redacta la respuesta. El slider de longitud parte de un email real de ~2.600 caracteres; el JS estima Nin por las dos reglas de pulgar (caracteres/4 y palabras×1.3, suponiendo ~5.8 caracteres por palabra con espacios) y aplica la Ec. (4) con tus precios. Arriba: desglose del coste de una llamada (leer vs generar). Abajo: coste mensual frente a peticiones/día en escala log-log, con tu punto en dorado y la referencia del call center humano (3 $/consulta) en gris.

Lee así. El slider de R es logarítmico (10 a 100.000 peticiones/día). El lector da Nin por ambas reglas, el coste por llamada desglosado y el coste mensual a 30 días.

Mensaje. Con la Ec. (4) y dos reglas de pulgar puedes presupuestar cualquier despliegue LLM en una servilleta antes de hablar con el proveedor. El error de la estimación de tokens (~10%) es despreciable frente al factor 100× de la decisión humano vs LLM.

Términos. Mtoken: un millón de tokens, la unidad de tarificación. Nin/Nout: tokens de entrada (prompt completo) y de salida (respuesta). R: volumen, peticiones/día.

las ecuaciones de esta slide
Ccaché = Nprefijo106 pcache + Nnuevo106 pin + Nout106 pout,   pcache = 0.30 × pin(Ec. 5)
si el prefijo del prompt (instrucciones de sistema + documentos RAG) se repite idéntico entre llamadas, el proveedor lo guarda precomputado y cobra esos tokens a ~30% del precio normal. Solo lo nuevo (la pregunta del usuario) paga tarifa completa. La salida no cambia de precio.
ahorro = 1 − CcachéCsin  →  crece con la fracción NprefijoNprefijo+Nnuevo y con el peso de la entrada en C
la llave del caché son los primeros N tokens del prompt: para activarlo hay que poner lo inmutable (sistema, documentos) AL PRINCIPIO y lo variable (la pregunta) al final. Mover una coma del prefijo invalida el caché.
guion paso a paso
  1. Valores por defecto (prefijo 7.000, pregunta 200, respuesta 800, Sonnet 3/15). Sin caché ~0.034 $/llamada; con caché ~0.019 $: el ahorro ronda el 44% y sale TODO de la columna de entrada.
  2. Sube el prefijo a 50.000 tokens (manual de producto entero, estilo asistente interno de Inditex). El ahorro sube al ~65%: cuanto mayor la parte repetida, más paga el caching.
  3. Sube la respuesta a 2.000 tokens. El ahorro relativo baja aunque el descuento sea el mismo: el caché solo actúa sobre la entrada, y ahora la salida domina el coste. Mira la curva inferior desplazarse.
  4. Mueve el descuento a 0.05 (caché casi gratis) y a 1.00 (sin descuento). Con 1.00 las dos barras coinciden exactamente: la Ec. (5) se reduce a la Ec. (4). Coherencia interna comprobada.
Comprueba que entiendes: ¿por qué puede el proveedor cobrar el prefijo a precio reducido sin perder dinero?
Porque el cómputo caro del prefijo (la pasada del Transformer que construye los estados internos de esos tokens, la "KV cache") ya se hizo en la primera llamada y se guardó en memoria. En las llamadas siguientes el modelo no relee el prefijo: carga los estados guardados y solo computa los tokens nuevos. El 30% que cobras cubre el almacenamiento y la carga, no la inferencia. Es la misma idea que precomputar un índice en una base de datos: pagas una vez el trabajo y lo amortizas en cada consulta.

Setup. Asistente corporativo con base de contexto estable: el mismo system prompt y los mismos documentos en cada llamada, solo cambia la pregunta. El JS calcula Csin con la Ec. (4) y Ccaché con la Ec. (5) y los compara. Arriba: las dos barras apiladas (prefijo / pregunta / respuesta), con el tramo de prefijo encogido por el descuento. Abajo: el ahorro (%) en función del tamaño del prefijo, con tu configuración marcada en dorado.

Lee así. El lector da los dos costes por llamada, el ahorro relativo y el ahorro mensual a 1.000 llamadas/día: con la configuración por defecto, unos 440 $/mes que aparecen solos por ordenar bien el prompt.

Mensaje. Caching, long context y memoria persistente son las tres palancas que bajan 5–10× el coste real de un asistente en producción. La primera es gratis: basta con poner lo inmutable al principio del contexto. Es ingeniería de orden, no de modelos.

Términos. prefijo: tramo inicial e inmutable del prompt. cache key: los primeros N tokens; cualquier cambio la invalida. KV cache: los estados internos precomputados que el proveedor guarda.

las ecuaciones de esta slide
máx 𝔼[calidad]  s.a.  Σi=1..5 ti ≤ B(Ec. 6)
el problema central del context engineering: repartir el presupuesto de tokens B (la ventana de contexto del modelo) entre las cinco piezas t1…t5: instrucciones de sistema, memoria persistente, documentos RAG, histórico de conversación y pregunta actual. Es un problema de asignación con restricción, no de redacción.
histórico resumido:  t4 → ρ·t4 (ρ ≈ 0.25),    coste:  C = Σti106 pin + Nout106 pout
las dos estrategias cuando desborda: truncar (tirar los turnos más antiguos: gratis pero pierde información) o resumir (comprimir el histórico ~4× con una llamada extra al modelo). Y como el coste es lineal en la entrada, cada token de contexto que no aporta calidad es dinero quemado en cada llamada.
guion paso a paso
  1. Con B = 32K, sube el RAG a 25.000 y el histórico a 10.000. La barra desborda y aparece el badge rojo: la llamada fallaría (o el proveedor truncaría por ti, en silencio, lo último que añadiste).
  2. Activa "resumir histórico". El tramo de histórico se encoge 4×, vuelve el badge verde y el coste por llamada baja: comprimes lo barato de comprimir.
  3. Cambia B a 200K con la misma carga. Sobra ventana… pero mira el coste por llamada en el panel inferior: la ventana grande no abarata nada, sigue cobrándose cada token. Long context no es contexto gratis.
  4. Deja solo sistema + pregunta (RAG, memoria e histórico a 0). Ocupación mínima y coste mínimo: todo lo demás es una decisión de ingeniería que debe justificar su calidad marginal (Ec. 6).
Comprueba que entiendes: ¿por qué truncar el histórico por el principio y no por el final?
Porque la información más reciente es la que condiciona la respuesta: la pregunta actual suele referirse a los últimos turnos ("¿y eso cuánto costaría?"). Truncar por el final rompería la conversación en curso; truncar por el principio pierde contexto antiguo, normalmente ya agotado. Cuando lo antiguo SÍ importa (el cliente dio su número de póliza en el turno 2), truncar es destructivo: ahí entra resumir, o mejor, mover ese dato a memoria persistente, que es exactamente para lo que existe la pieza t2.

Setup. Asistente bancario tipo BBVA con RAG sobre la normativa interna. La barra superior es la ventana del modelo B llenándose con las cinco piezas del contexto (colores por pieza); si Σti > B, desborda y el badge avisa. El selector de B recorre cuatro modelos reales: 8K (modelo local pequeño), 32K, 200K (Claude Sonnet), 1M (Gemini Pro). Abajo: el coste por llamada de la Ec. (4) para tu reparto actual, con y sin resumen, a precios 3/15 $/M y respuesta fija de 600 tokens.

Lee así. El lector da la ocupación (tokens y %), el badge cabe/desborda y el coste por llamada. El resumen añade el coste de la llamada de resumen (los t4 tokens originales leídos una vez a pin más su salida), amortizado: aún así casi siempre compensa si reutilizas el resumen varios turnos.

Mensaje. Prompt engineering era buscar la frase mágica; context engineering es ESTO: decidir qué entra, en qué orden y a qué precio. El 80% de la mejora de un asistente viene de qué contexto pasas, no de cómo lo redactas. Es la habilidad central de los Temas 5 (agentes) y 6 (RAG).

Términos. ventana de contexto B: máximo de tokens que el modelo acepta por llamada. RAG: recuperar documentos relevantes y pegarlos al contexto. memoria persistente: lo aprendido en sesiones previas, guardado en disco y recuperado selectivamente. truncar/resumir: las dos salidas al desbordamiento.

las ecuaciones de esta slide
acc(s) = a − def·4s(1−s) − b·s,    s ∈ [0,1](modelo en U)
probabilidad de que el modelo recupere un dato colocado en la posición relativa s del contexto (0 = principio, 1 = final). El término 4s(1−s) vale 0 en los extremos y 1 en el centro: resta hasta def puntos justo en mitad del contexto. El término b·s inclina la U (algunos modelos recuerdan mejor el principio que el final). Es un modelo didáctico calibrado sobre el fenómeno medido por Liu et al. (2023), "Lost in the Middle".
def = d · log10(N/2000)log10(100)  (0 si N ≤ 2000)
la profundidad del valle crece con la longitud del contexto N: con 2K tokens apenas hay valle; con 200K, el centro es una zona ciega. Meter más contexto no es gratis ni en coste (slide anterior) ni en recuperación.
guion paso a paso
  1. Con los valores por defecto, arrastra s de 0 a 1 mirando el punto dorado. La recuperación cae del ~96% al ~65% en el centro y se recupera al ~91% al final: la U canónica de "lost in the middle".
  2. Baja N a 3.000 tokens. El valle casi desaparece: en contextos cortos da igual dónde pongas el dato. El problema es de contexto largo.
  3. Sube N a 200K y pon s = 0.5. La recuperación en el centro se hunde: el contrato que pegaste "en medio" de los 40 documentos RAG es funcionalmente invisible.
  4. Pulsa "simular 200 consultas" en s = 0.5 y luego en s = 0.95. Los aciertos empíricos (Bernoulli con mulberry32) confirman la curva: ~65% frente a ~86%. La curva no es decorativa, es la probabilidad que gobierna la simulación.
Comprueba que entiendes: ¿qué orden de contexto se deduce de la U para un asistente RAG?
Lo inmutable y crítico (instrucciones de sistema, formato de salida) al PRINCIPIO, que además activa el prompt caching; la pregunta del usuario y el documento más relevante al FINAL, pegados; y el relleno (documentos secundarios, histórico antiguo) en el medio, que es donde menos se lee. Y la lección de fondo: si un dato es crítico, no lo entierres entre 30 documentos "por si acaso" — recorta el RAG a los 3 relevantes. Menos contexto mejor colocado bate a más contexto, en calidad Y en coste.

Setup. El experimento clásico: escondo un dato (la cláusula de permanencia del contrato del cliente) en la posición s de un contexto de N tokens y pregunto por él. Arriba: la curva acc(s) del modelo en U con tus parámetros, el punto dorado en tu s y las zonas seguras sombreadas en los extremos. Abajo: barras de aciertos/fallos de la última simulación de 200 consultas independientes, cada una un Bernoulli(acc(s)) con mulberry32.

Lee así. El slider de N es logarítmico (2.5K a 200K). El lector da acc(s), la mejor y la peor posición de la curva actual, y el resultado empírico de la última simulación con su error muestral.

Mensaje. La ventana de contexto no es memoria RAM perfecta: es un foco con penumbra en el centro. Pon lo importante al principio o al final; el medio es para lo prescindible. Este hecho, medido y reproducible, es la mitad del oficio de context engineering.

Términos. s: posición relativa del dato en el contexto. acc(s): probabilidad de recuperación. lost in the middle: degradación de recuperación en posiciones centrales de contextos largos. needle in a haystack: el benchmark estándar que mide exactamente esto.

las ecuaciones de esta slide
Cmes(m) = 30 R (Nin106 pin(m) + Nout106 pout(m)) + fijo(m)
el coste mensual de cada modelo m con tu tráfico: la Ec. (4) escalada a 30 días y R peticiones/día, más el coste fijo (el modelo local no cobra por token pero paga servidor GPU ~300 $/mes).
elegir:  m* = arg máxm calidad(m)  s.a.  Cmes(m) ≤ presupuesto,  lat(m) ≤ latmáx,  Nin ≤ ctx(m)
la elección de modelo es una optimización con restricciones, no un ranking universal: máxima calidad entre los que caben en presupuesto, latencia y ventana. Cambia una restricción y cambia el ganador; no existe "el mejor modelo", existe el mejor modelo PARA tu caso.
modelocalidad$/M in·outlatctx $/mesapto
guion paso a paso
  1. Con los valores por defecto, mira quién gana. Vega M: el equilibrado. El frontier no cabe en presupuesto y el barato pierde en calidad.
  2. Sube el presupuesto a 10.000 $/mes y la latencia tolerable a 8 s. Gana Cumbre 1 (frontier): cuando el dinero y la espera no aprietan, la calidad manda.
  3. Baja la latencia máxima a 1 s. Solo sobrevive Brisa S: en un autocompletar o un chatbot de alta frecuencia, la latencia elimina a los grandes antes de mirar el precio.
  4. Sube R a 50.000 peticiones/día con presupuesto 2.000 $. El local 8B se vuelve competitivo: su coste fijo de 300 $/mes no crece con el tráfico, mientras los de cloud escalan linealmente. El volumen cambia al ganador.
  5. Sube Nin a 40.000 tokens. El local queda descalificado por ventana (32K): la restricción de contexto también veta.
Comprueba que entiendes: ¿por qué el modelo local gana con volumen alto aunque su calidad sea la peor?
Porque su estructura de coste es distinta: coste fijo (servidor) + coste marginal ~0 por petición, frente al cloud, que es coste marginal puro. Con R pequeño el fijo de 300 $/mes no se amortiza y el cloud barato gana; con R enorme, el coste cloud crece linealmente hasta reventar cualquier presupuesto y el local se queda solo dentro de la restricción. Es la regla práctica del curso: borrador y volumen masivo en local, producción crítica en cloud — y la frontera exacta entre ambos la dibuja esta ecuación, no la intuición.

Setup. Cinco modelos sintéticos pero verosímiles (precios estilo 2026): Cumbre 1 (frontier, calidad 96, 5/25 $/M, 6 s), Vega M (equilibrado, 88, 3/15, 2 s), Brisa S (barato, 76, 0.5/2, 0.8 s), Gigas XL (90, 2.5/10, 3.5 s, ventana 1M) y Local 8B (64, 0/0 por token + 300 $/mes fijos, 5 s, ventana 32K). Respuesta fija de 500 tokens. El canvas pinta la frontera calidad-coste: cada modelo es un punto (coste mensual con TU tráfico, en x logarítmica; calidad en y), la línea vertical es tu presupuesto, los descalificados por latencia o ventana van en gris tachado y el ganador lleva el anillo dorado.

Lee así. Los sliders de presupuesto y R son logarítmicos. La tabla recalcula el coste mensual de cada modelo con tu tráfico y marca apto/no con el motivo; la fila dorada es m*.

Mensaje. La elección de modelo es siempre coste × latencia × calidad × privacidad (la cuarta no está en el canvas: datos sensibles pueden vetar el cloud entero, como en banca o sanidad, y entonces el local gana por descarte). Presenta siempre la decisión como esta optimización: convence a un comité de dirección mucho más que "este modelo me gusta".

Términos. frontier: el modelo más capaz del momento, al precio más alto. latencia: segundos hasta completar la respuesta. coste fijo vs marginal: servidor propio vs pago por token; el volumen decide cuál domina. m*: el modelo óptimo bajo tus restricciones.

1 — Next-token prediction
Slides: Next token · Generación
"Un LLM es pθ(xt+1|x1:t) = softmax(WOht), aplicado miles de millones de veces. La respuesta de tu chatbot es una cadena de dados condicionados: cada token muestreado se concatena y condiciona al siguiente (regla de la cadena)."
↓
2 — Sampling: τ, top-k, top-p
Slides: Temperatura · Top-k/p
"La 'creatividad' es geometría del dado: τ afila o aplana (pi ∝ ezi/τ, la entropía lo mide), top-k y top-p tachan la cola y renormalizan. Código y extracción a τ ≤ 0.2; brainstorming a τ ≈ 0.9 con top-p de red de seguridad."
↓
3 — Context engineering
Slides: Contexto · Posición
"Cinco piezas (sistema, memoria, RAG, histórico, pregunta) compitiendo por B tokens: máx 𝔼[calidad] s.a. Σti ≤ B. La ventana tiene penumbra en el centro (lost in the middle): lo crítico al principio o al final, lo inmutable delante para activar el caché."
↓
4 — Coste y elección de modelo
Slides: Coste · Caching · Elección
"Todo coste es C = Ninpin/106 + Noutpout/106; el caching cobra el prefijo repetido al 30% y el modelo se elige como arg máx calidad s.a. presupuesto, latencia y ventana. Borrador en local, producción en cloud, y la frontera la dibuja la ecuación, no la moda."

En una frase. Hoy has abierto la caja: un LLM es un predictor de próximo token cuyo comportamiento gobiernas con tres mandos de sampling, cuyo conocimiento por llamada gobiernas repartiendo la ventana de contexto, y cuyo coste gobiernas con una ecuación lineal que cabe en una servilleta. Con eso ya puedes presupuestar, configurar y defender ante dirección cualquier despliegue de LLM.

Garrido-Merchán — ecgarrido@comillas.edu — Deep Learning para Business Analytics — Día 11 · LLMs y context engineering