Cómo funcionan los LLM

docs.scrimba.com

Primero, el nombre. LLM es la sigla de large language model (modelo de lenguaje grande): el tipo de IA que hay detrás de herramientas como ChatGPT, esa a la que le envías un prompt y de la que recibes texto como respuesta. Este capítulo es la imagen de trabajo de lo que realmente es un LLM.

Escribes una pregunta y, unos segundos después, aparece una respuesta fluida y segura de sí misma. Da la impresión de que el modelo te entendió y buscó la respuesta. Esa impresión es útil, y también es errónea de maneras que importan, y en esa brecha es donde nacen la mayoría de los errores de quienes recién empiezan.

Este es el capítulo que te va a servir durante el resto de tu carrera trabajando con estas herramientas. No necesitas conocer las matemáticas detrás del entrenamiento de un modelo para construir con uno. Sí necesitas una imagen clara de lo que en realidad ocurre cuando responde, porque esa imagen explica todo lo demás: por qué funciona el prompting, por qué la misma pregunta da respuestas distintas, por qué los modelos inventan datos, por qué cuestan lo que cuestan y por qué algunas funciones son difíciles aunque parezcan triviales. Todo lo que viene después en este manual es una consecuencia de las ideas que ves aquí.

Este capítulo es el modelo mental detrás de estos sistemas: qué es un modelo, el único ciclo que ejecuta y el puñado de propiedades que explican el resto del manual. Nada de esto es matemática. Todo es la diferencia entre programar contra una caja negra y saber por qué se comporta como se comporta.

Cada técnica de los capítulos siguientes —prompting, salida estructurada, retrieval, agentes— es una consecuencia de lo que estás a punto de leer. Si entiendes bien esta imagen, el resto deja de sentirse como una bolsa de trucos sueltos y empieza a sentirse como una sola máquina que puedes predecir.

Estos modelos fallan de maneras específicas y repetibles, y este capítulo explica por qué. Si le quitas la interfaz, un modelo de lenguaje es una función congelada que predice texto un fragmento a la vez, y casi todos los modos de falla en producción —no determinismo, costos que se disparan, contexto perdido, respuestas equivocadas dichas con total seguridad— se derivan de ese único hecho.

Aquí no hay matemática nueva, y ese es justamente el punto: la ventaja de ingeniería que dura en el tiempo está en el mecanismo, no en el modelo de moda del mes. Léelo como la base sobre la que descansa cada decisión posterior.

Qué es realmente un modelo

Si le quitas la interfaz de chat, un modelo de lenguaje grande es una sola cosa: una función matemática enorme, un conjunto fijo de miles de millones de números llamados parámetros (también los vas a escuchar llamar pesos, o weights). Eso es todo el modelo. No es una base de datos, ni un motor de búsqueda, ni una persona pequeña dentro de una caja. Es una pila muy grande de números que recibe texto y produce texto.

Esos números no salieron de un programador que los escribió a mano. Se fijaron durante el entrenamiento. El proveedor le dio de comer al modelo una cantidad descomunal de texto —libros, código, artículos, páginas web— y repitió un ejercicio simple miles de millones de veces: ocultar la siguiente palabra, pedirle al modelo que la prediga y ajustar sus números un poco cada vez que se equivoca. Repite eso a una escala enorme y los números se van acomodando poco a poco en valores que son buenos para predecir texto. Eso es el entrenamiento: afinar miles de millones de perillas hasta que la predicción mejora.

De esto se desprenden dos cosas, y explican bastante del comportamiento que vas a encontrar más adelante. Primero, el entrenamiento ocurre una sola vez, con anticipación, y es enormemente costoso. Para cuando tú llamas al modelo, los números ya están congelados. El modelo no aprende de tu conversación. Nada de lo que dices cambia sus parámetros. Da la sensación de que recuerda y se adapta, pero eso lo hace el software que lo rodea, no el modelo en sí, un punto que retomamos con fuerza en la sección de la ventana de contexto.

Segundo, no hay ninguna tabla de datos dentro del modelo. El "conocimiento" existe como patrones incrustados en esos números, de la misma forma en que un panadero que ha hecho diez mil panes tiene la técnica en las manos sin necesidad de leer una receta. El modelo aprendió la forma de un texto correcto y coherente. Por eso puede ser fluido y estar equivocado en la misma frase: está reproduciendo la forma de una buena respuesta, no leyendo un dato guardado en un estante.

JunoQué es realmente un modelo Entonces un modelo es una pila enorme de números fijos que convierte texto en texto, y esos números se ajustaron una sola vez durante el entrenamiento y luego quedaron congelados. No aprende de ti mientras chateas, y no tiene una tabla ordenada de datos adentro, tiene patrones. Por eso puede sonar seguro y estar equivocado igual, así que siempre verifica lo que realmente importa.

Un modelo es una función pura: le das (pesos, entrada) y calcula una salida, nada más. Los pesos son los miles de millones de números aprendidos y fijados durante el entrenamiento; la entrada es el texto que envías. Como es una función, la misma entrada bajo la misma configuración produce los mismos puntajes subyacentes cada vez. Cualquier variación que veas entre ejecuciones viene del paso de muestreo que elige palabras a partir de esos puntajes, no de que el modelo "cambie de opinión".

El conocimiento que esa función lleva dentro está almacenado con pérdida, disperso y comprimido a lo largo de todos los pesos a la vez, no archivado como registros que se pueden recuperar. No hay una fila que puedas leer, ni una celda que puedas editar. Un dato que el modelo "sabe" es en realidad un patrón fuerte que los pesos reconstruyen sobre la marcha, y a veces lo reconstruyen un poco mal. No puedes señalar dónde vive un dato, y no puedes corregir un solo dato sin volver a entrenar el modelo entero.

La jugada práctica es tratar al modelo como una función fija que llamas, no como una base de conocimiento que consultas. Apóyate en él para dar forma al lenguaje, razonar sobre texto y seguir instrucciones. Cuando necesites algo específico, actual o auditable, pon esa información tú mismo en la entrada en lugar de confiar en que los pesos la retengan. Ese único hábito —aportar los datos en lugar de esperar que el modelo los tenga— evita una buena parte de las respuestas equivocadas dichas con seguridad.

JunoQué es realmente un modelo Piensa en el modelo como una función pura de pesos y entrada: misma entrada, misma configuración, mismos puntajes subyacentes, con la variación de ejecución a ejecución viniendo del muestreo. Su conocimiento está comprimido con pérdida a lo largo de los pesos, así que no puedes buscar ni editar un solo dato ahí dentro. Construye en consecuencia: trátalo como una función fija que llamas, y entrégale los datos específicos o actuales por medio de la entrada, en vez de esperar que los pesos los recuerden.

Un modelo desplegado son pesos congelados detrás de una API: miles de millones de números aprendidos, fijados en el momento del entrenamiento, que calculan una función pura de (pesos, entrada). El único momento en que su comportamiento realmente cambia es cuando el proveedor lanza un modelo distinto.

Eso tiene un filo operacional muy claro. Una actualización silenciosa por debajo del mismo endpoint puede modificar tus salidas sin que cambies una sola línea de tu código, así que fija una versión específica del modelo, trátala como parte de tu contrato y vuelve a correr tus evals antes de adoptar una nueva. Adoptar "la última versión" por confianza ciega es la forma en que un sistema que funcionaba empieza a fallar sin que nadie lo note.

Los pesos son memoria paramétrica comprimida, y es a la vez con pérdida y no auditable. No puedes comparar (hacer un diff de) lo que un modelo "sabe" entre versiones, no puedes enumerar sus datos y no puedes probar que un dato determinado esté ahí o sea correcto. Así que nunca hagas depender la corrección de un dato crítico de la memoria paramétrica. Si una respuesta equivocada te va a costar caro, entrega el dato en la entrada desde una fuente que controlas y puedes citar, y mantén al modelo en el rol de redactar y razonar sobre esa fuente, no de ser la fuente.

Cambiar los pesos deliberadamente es lo que hace el fine-tuning, y vale la pena tener claro qué te da. El fine-tuning modifica de manera confiable el comportamiento y la forma —tono, formato, hábitos de tarea—, pero no te da un almacén de datos confiable y consultable. Recurre a él para moldear cómo responde el modelo, no para instalar conocimiento en el que necesites confiar. Mantén los datos en la entrada y el estilo en los pesos, y ninguno de los dos te va a tomar por sorpresa.

JunoQué es realmente un modelo Los pesos están congelados, así que el comportamiento solo cambia cuando el proveedor lanza un modelo distinto: fija la versión, hazla parte de tu contrato y vuelve a correr los evals antes de actualizar, o un reemplazo silencioso te va a hacer regresar mientras duermes. La memoria paramétrica tiene pérdida y no es auditable; no puedes comparar lo que sabe, así que mantén los datos críticos en la entrada, desde una fuente que controlas, no en la memoria del modelo. Y el fine-tuning cambia comportamiento y forma, no es un almacén confiable de datos, así que úsalo para cómo responde el modelo, no para qué debería saber.

Predecir el siguiente token

Con esa pila de números ya lista, el modelo hace exactamente un trabajo: predecir el siguiente fragmento de texto, una y otra vez.

Veamos el ciclo en cámara lenta. Le das algo de texto. Él pasa ese texto por todos esos parámetros y produce una probabilidad para cada fragmento posible que podría seguir, decenas de miles de opciones a la vez. Después de "La capital de Francia es", el fragmento "París" podría recibir un puntaje de 97%, "una" un 1%, y todo lo demás casi nada.

Luego el modelo elige un fragmento, lo agrega al texto y vuelve a ejecutar todo el proceso para elegir el siguiente. Repite esto hasta que la respuesta está completa.

Ese es todo el motor. Una respuesta que tú lees como un pensamiento único se construyó fragmento por fragmento, cada uno elegido a partir de un nuevo ranking de probabilidades, sin ningún plan sobre hacia dónde va la frase más allá de "qué es probable a continuación". Cada capacidad que vas a usar —chat, código, traducción, uso de herramientas, razonamiento— es este mismo ciclo funcionando por debajo.

El teclado del celular que te sugiere la siguiente palabra es la misma idea en miniatura. La diferencia son los miles de millones de parámetros detrás de la sugerencia. Entrenado con suficiente texto, "cuál es el fragmento siguiente más probable" resulta ser suficientemente bueno para escribir código funcional y explicaciones claras. Pero el movimiento de fondo nunca cambia: es predicción, no comprensión, y no es una búsqueda de una respuesta guardada.

JunoPredecir el siguiente token Todo el motor es un pequeño ciclo: leer el texto hasta ahora, puntuar cada fragmento posible que sigue, elegir uno y repetir hasta que la respuesta esté terminada. El modelo no tiene ningún plan para la frase más allá de qué es probable a continuación, así que una respuesta que lees como un solo pensamiento en realidad se construyó fragmento por fragmento. Eso es predicción, no comprensión, y no es una respuesta guardada que se busca.

El modelo hace una sola cosa en bucle: en cada paso lee todo el texto acumulado hasta el momento y emite un puntaje para cada token (un token es un fragmento de texto, muchas veces parte de una palabra) de su vocabulario, decenas de miles a la vez. Esos puntajes se convierten en una distribución de probabilidad, y el modelo muestrea un token de ella. Luego agrega ese token al texto y ejecuta todo el proceso otra vez para elegir el siguiente. Después de "La capital de Francia es", "París" podría concentrar casi toda la probabilidad y todo lo demás casi ninguna.

Esta realimentación es la razón por la que se le llama autoregresivo: cada token nuevo depende de todo el texto anterior, incluyendo los tokens que ya escribió en este mismo turno. No hay un plan global ni un borrador que se pueda revisar. El modelo se compromete con un token a la vez, y como no puede retroceder un token, puede meterse en un callejón sin salida: una palabra inicial dicha con confianza puede forzar el resto de la frase por un camino incómodo que después tiene que terminar.

Ese único hecho explica algunas cosas que vas a usar en la práctica. Dejar que el modelo escriba su razonamiento antes de la respuesta final ayuda, porque más tokens significan más pasos y más cómputo invertido en el problema antes de comprometerse con una respuesta. La estructura de la salida se decide estrictamente de izquierda a derecha, así que la forma de una respuesta se fija a medida que avanza, no se planifica de antemano. Y el mismo ciclo es lo que impulsa el uso de herramientas: el modelo predice los tokens que forman una llamada, tú la ejecutas, y el resultado se realimenta como más texto para la siguiente predicción.

JunoPredecir el siguiente token En cada paso, el modelo puntúa cada token de su vocabulario, muestrea uno, lo realimenta y repite: ese ciclo de realimentación es lo que significa autoregresivo. No hay plan ni deshacer, así que se compromete token por token y puede meterse en un callejón sin salida. Por eso ayuda escribir el razonamiento antes de la respuesta, y por eso el uso de herramientas es el mismo ciclo con un resultado realimentado.

La generación es secuencial por construcción: el modelo produce un token (un fragmento de texto), lo realimenta y predice el siguiente, así que cada token de salida es una pasada distinta hacia adelante por la red. Leer tu entrada es relativamente barato, se procesa de una sola vez; la parte lenta y costosa es cuando el modelo escribe. La latencia y el costo escalan con la longitud de la salida, no con la de la entrada. Las palancas prácticas se derivan de eso: mantén las salidas cortas, transmite los tokens en streaming para que el usuario vea progreso en lugar de esperar la respuesta completa, y no pagues por formato verboso que después vas a descartar.

La otra consecuencia es la corrección. Como no hay un plan global, una sola pasada no se autocorrige: el modelo se compromete de izquierda a derecha y no puede revisar un token una vez que ya salió. Por eso cualquier cosa que tenga que ser correcta necesita verificación o una segunda pasada sobre el primer borrador, y por eso un modelo que escribe su razonamiento antes de la respuesta suele hacerlo mejor: le estás comprando más pasos antes de comprometerse. Trata la primera generación como un borrador, no como un veredicto.

Una palanca que vale la pena incorporar: muchas configuraciones expuenen probabilidades por token (logprobs, el propio puntaje de confianza del modelo para cada token que eligió). Puedes leerlas para marcar tramos de baja confianza, bloquear una respuesta sobre la que el modelo dudó, o enrutar los casos incierto a una segunda pasada o a una persona. Es una señal barata que ya tienes disponible, y convierte "el modelo podría estar equivocado aquí" en algo sobre lo que puedes actuar de forma programática en vez de adivinar.

JunoPredecir el siguiente token Cada token de salida es su propia pasada hacia adelante, así que el costo y la latencia siguen la longitud de la salida, no la de la entrada: mantén las respuestas cortas, transmítelas en streaming y deja de pagar por formato que descartas. No hay plan ni deshacer, así que una pasada no se autocorrige; trata la primera generación como un borrador y agrega una pasada de verificación para lo que tenga que ser correcto. Si puedes leer los logprobs por token, úsalos para marcar o enrutar los tramos en los que el modelo estuvo menos seguro; es confianza que ya tienes y casi nunca aprovechas.

La perilla de la aleatoriedad

Si el modelo siempre tomara el único fragmento con el puntaje más alto, te daría la misma respuesta al mismo prompt cada vez, y esa respuesta suele ser plana y repetitiva. Por eso, la mayor parte del tiempo la elección tiene un poco de aleatoriedad: casi siempre toma un fragmento de alta probabilidad, pero no siempre el que está en el primer lugar. Por eso puedes hacer exactamente la misma pregunta dos veces y obtener dos respuestas distintas. Eso es el sistema funcionando como fue diseñado, no una falla.

Controlas cuánta aleatoriedad hay mediante una configuración llamada temperatura, que ajustas cuando llamas al modelo, tema que verás en el capítulo sobre llamar modelos desde código. Conviene tener ya la intuición desde ahora. A una temperatura baja, el modelo se apega a sus elecciones más probables: enfocado, consistente, predecible, que es lo que quieres para extraer un número de una factura o clasificar texto en categorías. A una temperatura más alta, los fragmentos de menor probabilidad se eligen con más frecuencia: más variado y creativo, y con más probabilidad de irse por un camino equivocado. La lluvia de ideas y la escritura creativa quieren el extremo alto; cualquier tarea con una respuesta correcta quiere el extremo bajo.

Entonces una sola perilla desliza al modelo entre "cuidadoso y repetible" y "sorprendente e inventivo". Es el mismo ciclo de predicción en ambos casos; la temperatura solo cambia cuán audazmente el modelo se aleja de su elección más segura.

JunoLa perilla de la aleatoriedad La temperatura es tu perilla de aleatoriedad. Bájala para tareas con una respuesta correcta, como extracción o clasificación, y obtienes respuestas enfocadas y repetibles. Súbela para lluvia de ideas y trabajo creativo, y obtienes más variedad junto con más probabilidad de que se desvíe. Mismo ciclo de predicción, solo un alcance más audaz o más seguro.

Antes de que el modelo elija su siguiente fragmento, tiene una probabilidad para cada candidato. La temperatura reconfigura esa distribución antes de que el modelo muestree a partir de ella. Una temperatura baja agudiza la distribución hacia el token más probable (más parecido a siempre tomar la primera opción), así que la salida se vuelve enfocada y repetible. Una temperatura alta la aplana, dándole a tokens menos probables una oportunidad real, así que la salida se vuelve más variada y más propensa a desviarse. Por eso el mismo prompt puede devolver respuestas distintas: hay un sorteo ocurriendo, y la temperatura define cuán sesgadas están las probabilidades.

La temperatura no es la única perilla en juego. Top-p (muestrear solo del conjunto más pequeño de tokens cuyas probabilidades sumen p) y top-k (solo los k tokens más probables) recortan el grupo de candidatos antes del muestreo. Se superponen en su efecto con la temperatura, así que conviene pensarlos como una sola configuración de aleatoriedad y no como tres independientes.

La jugada práctica es fijar la temperatura explícitamente según la tarea, en lugar de confiar en el valor por defecto que venga configurado. Bájala para extracción, clasificación y cualquier cosa que emita salida estructurada que vayas a parsear después; súbela para ideación y borradores donde la variedad es el punto. Cuidado con las interacciones: combinar una temperatura alta con un top-p de 1 deja abierta toda la cola de la distribución, lo cual juega en tu contra cuando necesitas resultados confiables y parseables.

JunoLa perilla de la aleatoriedad La temperatura reconfigura la distribución de probabilidad antes del muestreo: baja la agudiza hacia el token principal para una salida enfocada, alta la aplana para dar variedad. Trata temperature, top_p y top_k como una sola configuración de aleatoriedad, no como tres. Ajústala según la tarea: baja para extracción, clasificación y salida estructurada; más alta para ideación. No combines una temperatura alta con un top_p de 1 cuando necesites resultados parseables.

La temperatura escala la distribución de puntajes antes del muestreo, y el atajo tentador es fijarla en 0 y llamar determinista a la salida. Se acerca, pero no es una garantía. Las operaciones en punto flotante, el procesamiento por lotes del lado del servidor y el enrutamiento interno en modelos grandes introducen todos pequeñas fuentes de no determinismo incluso a temperatura 0. Así que no construyas caché de coincidencia exacta ni pruebas de coincidencia exacta que asuman una salida idéntica byte por byte para un prompt repetido; ese supuesto falla de forma intermitente, y las fallas intermitentes son las más costosas de rastrear.

Esto define cómo pruebas el comportamiento muestreado. Una sola ejecución te dice casi nada sobre un sistema estocástico (uno cuya salida varía de ejecución a ejecución), así que evalúa un prompt corriéndolo varias veces y observando la distribución de las salidas: con qué frecuencia cae dentro de la especificación, cuán amplia es la varianza, hacia dónde se va la cola cuando falla. Ese es el trabajo que hacen tus evals, y necesitan suficientes muestras para ver la dispersión, no un solo golpe de suerte.

Trata la temperatura, el top-p (muestrear solo del conjunto más pequeño de tokens cuyas probabilidades alcanzan una p acumulada) y el top-k (conservar solo los k tokens más probables) como un solo presupuesto de muestreo que ajustas en conjunto, en lugar de tres perillas que fijas por reflejo. Elige la menor aleatoriedad que todavía dé la variedad aceptable para la tarea: apretar las tres a la vez puede colapsar la salida en algo repetitivo y frágil, mientras que dejarlas todas abiertas te da una varianza que después tienes que validar. El costo es real en ambos extremos, así que gástalo con criterio.

JunoLa perilla de la aleatoriedad Temperatura 0 es casi determinista, no garantizada: el punto flotante, el procesamiento por lotes y el enrutamiento interno filtran no determinismo, así que evita el caché de coincidencia exacta y las pruebas de coincidencia exacta. Evalúa el comportamiento muestreado sobre varias ejecuciones y lee la distribución, no una sola pasada; para eso están tus evals. Ajusta temperature, top_p y top_k como un solo presupuesto de muestreo, y elige la menor aleatoriedad que todavía dé una variedad aceptable.

Tokens

Los "fragmentos" que predice un modelo tienen un nombre: tokens. Un token es un pedazo de texto, muchas veces una palabra completa, a veces solo una parte de ella. Las palabras comunes suelen ser un solo token, mientras que las palabras más largas o poco frecuentes se dividen en varios.

"tokenización"  ->  "token" + "ización"
"increíble"     ->  "in" + "creíble"
"gato"          ->  "gato"

¿Por qué picar el texto en pedazos tan raros en lugar de usar palabras completas o letras sueltas? Es una decisión de compromiso. Las letras sueltas harían que cada secuencia fuera enormemente larga, y la longitud es justo lo que el modelo tiene que procesar. Las palabras completas necesitarían un vocabulario de millones de entradas y de todos modos se romperían la primera vez que alguien invente una palabra o cometa un error de tipeo. Los tokens son el camino intermedio: un vocabulario fijo de unas pocas decenas de miles de pedazos comunes que se pueden ensamblar para formar cualquier cosa, incluyendo palabras que el modelo nunca ha visto.

Acá está la consecuencia interna que sorprende a la gente. El modelo nunca ve letras. Ve tokens, que para él en realidad son números de identificación de esos fragmentos. Por eso tareas que a nosotros nos resultan sencillas pueden ser difíciles para él: contar las letras de una palabra, invertir una cadena de texto, notar que "fresa" tiene dos "r".

No es que sea torpe. Simplemente no percibe los caracteres individuales en absoluto, de la misma forma en que tú no puedes saborear los granos de harina por separado en un pan ya horneado. Cuando un modelo se equivoca en una tarea de ortografía o de conteo de caracteres, esta es la razón, y la solución suele ser hacer esa parte con código normal en lugar de pedírsela al modelo.

Los tokens también son la unidad de dos cosas que te van a importar constantemente:

• Dinero: los proveedores cobran por token, tanto los tokens que envías como los que el modelo te devuelve, así que un documento largo de entrada y una respuesta larga de salida cuestan más los dos. Una medida aproximada para el inglés es de unos cuatro caracteres por token, o 100 tokens cada 75 palabras; el código y otros idiomas suelen dividirse en más tokens, lo cual es parte de por qué pueden costar más. Vas a ver esto de forma directa cuando empieces a llamar modelos desde código.
• Límites: hay un tope de cuántos tokens puede manejar el modelo a la vez, que es el tema de la siguiente sección.

JunoTokens Un token es un fragmento de texto, casi siempre una palabra o parte de una, y el modelo lee esos fragmentos como números de identificación, no como letras. Por eso puede fallar al contar o deletrear, así que dale ese trabajo al código común. Y como pagas por token en ambos sentidos y hay un tope de cuántos entran a la vez, menos tokens significa menos costo y más espacio disponible.

El modelo predice tokens, pedazos de texto que muchas veces son una palabra completa y a veces un fragmento. La pieza que hace la división es el tokenizador, y funciona a partir de un vocabulario aprendido que se construye fusionando repetidamente los pares de caracteres más comunes hasta llegar a un conjunto fijo de unas pocas decenas de miles de piezas (un esquema que suele llamarse byte-pair encoding, o BPE). Esa historia es la razón por la que las palabras frecuentes terminan siendo un solo token mientras que las poco comunes se fragmentan en partes: los patrones comunes se fusionaron durante el entrenamiento, los poco comunes nunca lo hicieron.

De esto se desprenden dos hechos prácticos. Primero, el modelo nunca maneja caracteres, solo IDs de tokens, así que cualquier operación a nivel de carácter (contar letras, invertir una cadena, cortar en una posición exacta) es poco confiable dentro de un prompt y confiable en tu propio código. Empuja ese trabajo hacia el código y deja que el modelo se encargue de la parte del lenguaje. Segundo, la tokenización es específica de cada modelo, así que los conteos de tokens no son portables. La misma frase puede costar un número distinto de tokens en un tokenizador diferente, algo que importa en el momento en que presupuestas costos o intentas hacer que el contenido entre en la ventana.

La conclusión práctica para construir: no calcules a ojo el número de tokens a partir de la longitud en caracteres. Cuenta con el tokenizador real que usa el modelo, porque ese es el número por el que te cobran y con el que te limitan. Todo esto se vuelve concreto cuando empieces a llamar modelos desde código, donde el conteo que envías más el que recibes de vuelta es tu factura.

JunoTokens Un tokenizador divide el texto usando un vocabulario aprendido (BPE), y por eso las palabras comunes son un solo token y las poco frecuentes se fragmentan. La tokenización es específica de cada modelo, así que cuenta con el tokenizador propio del modelo en lugar de adivinar a partir de caracteres. Y mantén el trabajo a nivel de carácter (contar, invertir, cortar exacto) en tu código, no en el prompt.

Los tokens son el medidor de todo lo que despliegas. Un token es un pedazo de texto del vocabulario aprendido del tokenizador, y la tarifa por token más el tope fijo del contexto son los dos números que determinan tu costo y tu diseño. La regla práctica reconfortante de cuatro caracteres por token se sostiene para la prosa común en inglés y se cae exactamente donde vive la producción real: código, JSON, formato profundamente anidado y escrituras no latinas se fragmentan en muchos más tokens de los que predice la heurística. Así que presupuesta con el tokenizador real, no con la regla aproximada, o tus estimaciones de costo y capacidad van a estar mal justo en las cargas que realmente envías.

La fragmentación no se distribuye de manera uniforme, y eso es un problema de equidad y de costo a gran escala. El mismo significado en un idioma no latino puede costar varias veces más tokens que su versión en inglés, así que la misma funcionalidad resulta silenciosamente más cara, y más lenta, para algunos de tus usuarios que para otros. Vale la pena medirlo por idioma antes de prometerle a alguien un precio fijo o una latencia fija.

Dos hábitos más del terreno. El formato es gasto: los espacios en blanco, los delimitadores verbosos y el markdown decorativo cuestan tokens sin agregar significado, así que mantén compacta la estructura que le pasas al modelo y deja que tu código agregue la presentación después. Y alimenta texto limpio y normal, porque los tokens raros o malformados (mojibake, caracteres de control sueltos, codificaciones extrañas) caen en los rincones delgados y poco entrenados del vocabulario y pueden disparar salidas extrañas. Nada de esto es exótico; es la diferencia entre un presupuesto de tokens que puedes confiar y uno que te sorprende en la factura.

JunoTokens La regla de cuatro caracteres por token se rompe en código, JSON y escrituras no latinas, que es justo donde vive tu tráfico real, así que presupuesta con el tokenizador real. Los idiomas no latinos pueden costar varias veces más tokens para el mismo significado, una brecha real de costo y equidad que vale la pena medir por idioma. Elimina el formato decorativo para ahorrar tokens, y alimenta texto limpio para que los tokens raros o malformados no te compren un comportamiento extraño.

La ventana de contexto

La ventana de contexto es cuánto texto puede recibir el modelo de una sola vez, medido en tokens. Imagínala como el tamaño del escritorio del modelo. Todo lo que interviene en una sola solicitud tiene que entrar en ese escritorio al mismo tiempo: tus instrucciones, la conversación hasta el momento, cualquier documento que hayas pegado y la respuesta que el modelo está escribiendo.

¿Por qué existe siquiera un límite? Viene de cómo funciona la predicción. Para elegir el siguiente token, el modelo compara cómo se relaciona cada token de la entrada con todos los demás, de modo que puede darse cuenta de que "eso" se refiere al gato mencionado tres frases atrás. Esa comparación de todos-contra-todos es lo que le permite al modelo seguir el significado a lo largo de un pasaje, y también es lo que hace que las entradas largas sean costosas de procesar. El proveedor fija un tope, la ventana de contexto, para mantener manejable cada solicitud.

Cuando el escritorio se llena, algo tiene que salirse. Si una conversación se extiende lo suficiente como para desbordar la ventana, las partes más antiguas se caen y el modelo ya no puede verlas. Por eso un chat largo parece "olvidar" lo que dijiste al principio. No lo olvidó en ningún sentido humano; esos tokens simplemente ya no están sobre el escritorio. También ayuda saber que los modelos tienden a prestar más atención al principio y al final de lo que hay en el escritorio, y pueden perder de vista cosas enterradas en el medio, así que dónde ubicas el texto importante importa cuando llenas la ventana.

Ahora viene el punto que atrapa a casi todo el que recién empieza, y pesa más que todo lo demás. El modelo no tiene memoria entre solicitudes separadas. Recuerda que sus números están congelados. Cada llamada empieza con un escritorio en blanco. El modelo no recuerda tu última pregunta, tu nombre, ni nada de hace un minuto.

Una aplicación de chat se siente como una sola conversación fluida solo porque la aplicación, en silencio, vuelve a enviar todo el historial con cada mensaje nuevo. La continuidad es algo que construye el software alrededor del modelo, no algo que el modelo tenga por sí mismo.

Ese único hecho da forma a cómo construyes todo lo demás a partir de aquí. Si quieres que el modelo sepa algo, tienes que ponerlo sobre el escritorio en esa solicitud: la conversación hasta el momento, los datos del usuario, los documentos relevantes, todo, cada vez. Buena parte de este manual trata en realidad de hacer bien esa única cosa: poner el texto correcto sobre el escritorio.

JunoLa ventana de contexto La ventana de contexto es el escritorio del modelo: cada solicitud tiene que entrar en él, y cuando se desborda, el texto más antiguo se cae. El modelo no guarda memoria entre llamadas, así que la aplicación vuelve a enviar todo el historial cada vez para simular un chat continuo. Tu trabajo de aquí en adelante es poner el texto correcto sobre ese escritorio en cada solicitud.

Piensa en la ventana de contexto como un presupuesto fijo de tokens que una solicitud puede gastar, y que cubre tus instrucciones, la conversación en curso, cualquier documento pegado y la respuesta que se está generando. La ventana existe por cómo el modelo lee la entrada: un mecanismo llamado atención compara cada token contra todos los demás para determinar qué se relaciona con qué. Esa comparación es lo que le permite al modelo resolver un "eso" y hacerlo apuntar al sustantivo correcto, y su costo crece aproximadamente con el cuadrado de la longitud de la entrada. Duplica los tokens y más que duplicas el trabajo, que es la razón real por la que las entradas largas son lentas y elevan el costo.

Que algo entre en la ventana no es lo mismo que el modelo use todo lo que hay adentro. Existe un efecto bien documentado llamado perdido en el medio: los modelos atienden con mayor fiabilidad al principio y al final de la entrada, y pueden pasar por alto material ubicado en el centro. Así que coloca tus instrucciones y datos más importantes cerca del inicio o del final del prompt, no enterrados en medio de un muro de texto pegado.

La otra mitad de esto es la memoria, y el dato clave es que el modelo es sin estado (stateless): no recuerda nada entre solicitudes separadas. Cada llamada empieza con una ventana vacía, así que la única forma en que el modelo conoce la conversación hasta el momento es que tú se la envías de nuevo cada vez. Reenviar y dar forma a ese historial es tu trabajo, no el del modelo. A medida que el chat crece más allá de la ventana, adminístralo tú mismo recortando turnos antiguos o reemplazándolos con un resumen corto, para que los tokens que conservas sean los que todavía importan.

Eso pone la construcción del contexto en el centro de trabajar con estos modelos. Decidir qué va en la ventana, en qué orden, y cómo comprimir lo que vino antes es la mayor parte del trabajo, y prompting es donde aprendes a darle forma de manera deliberada.

JunoLa ventana de contexto La ventana es un presupuesto de tokens que cubre instrucciones, historial, documentos y la respuesta; la atención hace que las entradas largas cuesten aproximadamente el cuadrado de su longitud. Los modelos sufren un efecto de perdido-en-el-medio, así que pon lo importante cerca del principio o del final. El modelo no tiene estado, así que reenviar y recortar el historial de la conversación depende de ti, en cada llamada.

Trata la ventana de contexto como un techo, no como una meta. Es el presupuesto de tokens que recibe una sola solicitud, y abarca tus instrucciones, el historial en curso, los documentos recuperados y la salida.

Cada token que pones en ella cuesta dinero y latencia, porque el paso de atención (la comparación de todos-contra-todos entre tokens que el modelo ejecuta para leer la entrada) escala aproximadamente con el cuadrado de la longitud. Peor aún, la recuperación efectiva se degrada bastante antes de llegar al límite: el efecto de perdido en el medio significa que la precisión sobre material enterrado en el centro cae incluso cuando técnicamente sí entra en la ventana. Así que cura el contexto en lugar de vaciarlo todo dentro, y cuando los datos de origen son grandes, recupera solo las piezas relevantes con RAG en lugar de pegar el corpus completo.

El orden es una palanca, no un detalle. Los proveedores pueden reutilizar el cómputo de un prefijo sin cambios mediante el prompt caching, donde el estado interno guardado en caché es la caché KV, el trabajo almacenado del modelo para los tokens que ya leyó. Pone el contenido estable primero (instrucciones del sistema, material de referencia fijo) y el contenido variable al final, y las llamadas repetidas se vuelven más baratas y más rápidas porque el inicio del prompt se sirve desde la caché. Reordena ese prefijo con descuido y vas a invalidar la caché y volver a pagar el precio completo.

La memoria entre turnos no es una función que el modelo tenga; es una decisión de ingeniería que tú tomas, y cada opción falla de una manera propia:

• El ventaneo simple, quedarte solo con los turnos más recientes, es barato pero descarta silenciosamente datos antiguos que el usuario todavía espera que recuerdes.
• La resumidación guarda más historial en menos tokens pero pierde detalle y puede terminar codificando sus propios errores sin que nadie lo note.
• El retrieval trae de vuelta solo lo relevante pero depende por completo de que tu índice devuelva las piezas correctas.

Elige según el caso de uso, y asume que cualquiera que elijas eventualmente te va a mostrar algo equivocado; instrumenta para eso en lugar de confiar ciegamente.

JunoLa ventana de contexto La ventana es un techo, no una meta: el costo y la latencia suben con cada token y la recuperación se deteriora antes de llegar al límite, así que cura el contexto y apóyate en el retrieval para cualquier cosa grande. Contenido estable primero, variable al final, para que el prompt caching (la caché KV) realmente valga la pena. La memoria entre turnos es tu decisión de diseño entre ventaneo, resumidación y retrieval, y me han fallado los tres, así que instrumenta el que elijas.

Lo que el modelo no sabe

Todo el conocimiento de un modelo se incrustó mientras se entrenaba, así que solo sabe lo que estaba en esos datos de entrenamiento, y esos datos se recopilaron hasta cierto punto de corte en el pasado. De esto se desprenden dos límites directos.

Primero, no sabe nada de lo que ocurrió después de su corte. Pregúntale sobre las noticias de la semana pasada o sobre una biblioteca de código que salió este mes y no tiene ninguna idea real, aunque tal vez de todos modos produzca con gusto una respuesta que suena plausible. Segundo, nunca supo nada privado. Los documentos internos de tu empresa, el historial de compras de un usuario, el contenido de tu base de datos: nada de eso estaba en el texto público con el que entrenó, así que no puede saberlo, sin importar con qué amabilidad se lo pidas.

Hay un límite más silencioso todavía. El modelo generalmente no puede decirte de dónde viene algo que "sabe", porque el conocimiento está mezclado en su interior en lugar de estar archivado como datos separados con su fuente identificada. Puede escribirte una cita, pero está prediciendo cómo se debería ver una cita, no buscando una real.

Esta es la razón detrás de una técnica que vas a ver más adelante llamada retrieval, o RAG. Si quieres que un modelo responda sobre eventos recientes o sobre tus propios datos privados, no lo vuelves a entrenar. Tú mismo buscas el texto relevante y lo pones sobre el escritorio en el momento de la solicitud, para que el modelo tenga los datos frente a él en lugar de adivinar. Un modelo es mucho más un razonador sobre el texto que le entregas que un pozo confiable de datos específicos.

JunoLo que el modelo no sabe Un modelo solo sabe lo que estaba en sus datos de entrenamiento, hasta un corte en el pasado, así que se pierde eventos recientes y todo lo privado, y no puede decir con confiabilidad de dónde vienen sus datos. Cuando necesites información actual o privada, no reentrenes: busca el texto relevante y entrégaselo al modelo en la solicitud. Trata al modelo como algo que razona sobre lo que le entregas, no como una memoria confiable.

El conocimiento incorporado de un modelo, su conocimiento paramétrico (los datos codificados en sus pesos, los números ajustables fijados durante el entrenamiento), está congelado en el corte de entrenamiento. Nada de lo que ocurrió después de esa fecha está ahí, y nada privado estuvo nunca ahí, porque los pesos se formaron a partir de texto público. Entonces la memoria te da dos brechas predecibles: recencia, todo lo posterior al corte, y privacidad, todo lo que nunca estuvo en datos públicos de entrenamiento.

Esas dos brechas son en realidad una sola brecha vista desde dos lados, y se cierran de la misma manera: pon el texto necesario en la solicitud. Tú mismo buscas el artículo reciente o la fila relevante de la base de datos y la entregas junto con la pregunta, así el modelo lee el dato en lugar de recordarlo. Esta es la idea central detrás de RAG, generación aumentada por retrieval, que vas a usar siempre que las respuestas deban reflejar información actual o de propiedad exclusiva.

El conocimiento paramétrico tampoco lleva ninguna fuente asociada. Los datos están mezclados a lo largo de los pesos, no almacenados como entradas discretas con procedencia, así que el modelo no puede decirte con confiabilidad de dónde vino algo. Una cita que produce está generada para verse correcta, no recuperada de un registro, y por eso vale la pena el esfuerzo de fundamentar la respuesta en texto que tú proporcionas.

La regla práctica para construir: no le pidas al modelo que recuerde de memoria datos actuales o de propiedad exclusiva. Si un dato tiene que ser correcto, búscalo y entrégalo, y deja que el modelo razone sobre él.

JunoLo que el modelo no sabe El conocimiento paramétrico, los datos codificados en los pesos, está congelado en el corte de entrenamiento y no lleva fuente, así que el modelo se pierde información reciente y privada y no puede citar nada con confiabilidad. Ambas brechas se cierran de la misma manera: busca el texto relevante y ponlo en la solicitud, que es la idea detrás de RAG. Como regla, no hagas que el modelo recuerde de memoria datos actuales o de propiedad exclusiva; entrégaselos y deja que razone sobre ellos.

La memoria paramétrica del modelo, el conocimiento contenido en sus pesos (los números ajustables fijados durante el entrenamiento), no está versionada ni es auditable. No puedes hacerle un diff, no puedes señalar dónde vive una afirmación, ni confirmar que no se haya desviado. Así que para todo lo que deba ser correcto, actual o cumplir alguna normativa, no confíes en la palabra del modelo: fundamenta la respuesta en una fuente recuperada y cita esa fuente. Trata el conocimiento incorporado como un prior fluido, no como un sistema de registro.

El corte también es más difuso de lo que sugiere una sola fecha. Los datos de entrenamiento no son uniformes hasta esa fecha: el material reciente es más escaso y menos digerido que el material más antiguo y ya bien cubierto, así que los datos recientes-pero-anteriores-al-corte se conocen de manera desigual. Un modelo puede estar seguro y equivocado sobre algo de un año antes de su corte mientras acierta con precisión un dato de una década atrás, y por eso "¿es anterior al corte?" es una garantía más débil de lo que parece, y por eso recuperas cualquier cosa que tenga que ser correcta.

Elige la herramienta correcta según la brecha, porque las dos comunes no son intercambiables. El retrieval entrega datos en el momento de la solicitud y se mantiene actual conforme tus fuentes se actualizan. El fine-tuning, que continúa el entrenamiento sobre tus propios ejemplos, modifica la forma y el comportamiento —tono, formato, cómo el modelo sigue tus convenciones— y es una forma pobre y desactualizada de inyectar conocimiento: los datos entrenados quedan congelados de nuevo, son difíciles de actualizar y siguen sin fuente. Usa el retrieval para lo que es verdad, el fine-tuning para cómo debería sonar.

JunoLo que el modelo no sabe La memoria paramétrica no está versionada ni es auditable, así que para todo lo que deba ser correcto, actual o cumplir alguna normativa, fundamenta la respuesta en una fuente recuperada y cita esa fuente, no la palabra del modelo. Recuerda que el corte es difuso: los datos recientes-pero-anteriores-al-corte se conocen de manera desigual, así que recupera cualquier cosa que tenga que ser correcta. Y ajusta la herramienta a la brecha: el retrieval entrega datos, mientras que el fine-tuning modifica la forma y el comportamiento y es una forma desactualizada de inyectar conocimiento.

Por qué los modelos inventan cosas

A veces un modelo afirma algo falso con total seguridad: una cita que nadie dijo, una función que no existe, la referencia a un estudio que nunca se escribió. Esto se llama alucinación, y después de las últimas secciones debería sentirse casi inevitable en lugar de misterioso.

La razón es que el modelo no tiene ninguna noción interna de "verdadero" versus "falso". Solo tiene "texto probable" versus "texto improbable". La mayoría de las veces esas dos cosas coinciden, porque en el texto del que aprendió, las afirmaciones verdaderas son mucho más comunes que las falsas, así que la continuación probable suele ser también la correcta.

Pero cuando el modelo se topa con un vacío —algo con lo que nunca se entrenó, o tus datos privados que nunca pudo haber visto— no se detiene a señalar el vacío. No puede saber con confiabilidad qué es lo que no sabe. Hace lo único que siempre hace: producir la continuación que suena más probable.

Una respuesta segura, bien construida y equivocada muchas veces es exactamente lo que suena más probable. La misma maquinaria que lo hace fluido lo hace fluido incluso cuando se equivoca.

Esta es la parte con la que hay que quedarse: la alucinación no es un fallo que puedas eliminar por completo con el prompt. Puedes reducirla, y los capítulos siguientes muestran cómo. Decirle al modelo que puede responder "no lo sé" ayuda un poco. Pedirle que responda solo a partir del texto que tú proporcionas ayuda mucho más, porque ahora no hay ningún vacío que llenar con conocimiento congelado del entrenamiento. Pero la tendencia viene de lo que el modelo fundamentalmente es, una máquina de probabilidades sin ningún verificador de datos interno, así que las soluciones duraderas son estructurales: entrégale los datos con los que trabajar en lugar de esperar que estuvieran en su entrenamiento, y verifica las respuestas que realmente importan en lugar de confiar en ellas.

Llévate una regla de este capítulo por encima de todas las demás: la confianza de un modelo no te dice nada sobre si está en lo correcto. La fluidez y la corrección se producen con el mismo proceso y se separan todo el tiempo. Construye asumiendo que cualquier respuesta individual podría estar equivocada, porque cualquier respuesta individual podría estarlo.

JunoPor qué los modelos inventan cosas Una alucinación es el modelo llenando con confianza un vacío con texto que suena correcto pero no lo es, porque solo conoce "probable" y no "verdadero". Puedes bajar la frecuencia con que ocurre, pero no puedes eliminarla por completo con el prompt, así que la jugada segura es entregarle al modelo los datos que necesita y revisar las respuestas que realmente importan. Y recuerda lo más importante: un tono seguro no es prueba de nada, así que nunca confíes en la certeza por sí sola.

Cuando un modelo inventa una cita, una función o una referencia y la afirma con total seguridad, eso es una alucinación, y se desprende directamente de cómo funciona el modelo. El modelo no tiene ninguna señal de verdad. Puntúa continuaciones por "texto probable" versus "texto improbable", y la mayoría de las veces lo probable y lo verdadero se superponen porque las afirmaciones verdaderas dominaron sus datos de entrenamiento.

La alucinación se dispara justo donde esa superposición se rompe: en los bordes de su conocimiento, en temas raros o de nicho, y en tus datos privados con los que nunca entrenó. Ahí el modelo sigue produciendo su continuación más probable, y una respuesta fluida, bien construida y equivocada suele ser lo que puntúa más alto.

Así que no puedes resolver esto solo con la redacción, pero sí puedes ordenar tus mitigaciones según cuánto realmente ayudan. La palanca más grande, por mucho, es la fundamentación: pon los datos reales en el prompt y dile al modelo que responda solo a partir de ese texto proporcionado, idealmente citándolo. Ahora no hay ningún vacío que llenar con conocimiento congelado del entrenamiento. Recuperar el texto correcto para proporcionar es una técnica en sí misma, que se cubre en RAG.

Por debajo de eso, dale al modelo una salida explícita, permiso para responder "no lo sé" en lugar de adivinar, lo cual quita algo de la presión de inventar. Y mantén la temperatura (la perilla de aleatoriedad en la selección de tokens) modesta para trabajo factual, ya que una aleatoriedad alta le abre la puerta a continuaciones improbables y descarriadas.

La consecuencia práctica: limita al modelo al contexto que tú proporcionas y verifica las salidas que importan. Trata la redacción del prompt como un ajuste pequeño encima de esos movimientos estructurales, nunca como toda la defensa. Un modelo que suena seguro no te ha dicho nada sobre si está en lo correcto, porque la fluidez y la corrección vienen del mismo proceso y de manera habitual se separan.

JunoPor qué los modelos inventan cosas La alucinación es el modelo emitiendo texto fluido y probable sin ninguna verificación interna de verdad, y empeora en los bordes de su conocimiento y en datos que nunca vio. Ordena tus soluciones según su impacto: fundaméntalo en texto que tú proporcionas (la palanca más grande), dale espacio para decir "no lo sé", dile que responda solo desde el contexto proporcionado y que lo cite, y mantén la temperature modesta para trabajo factual. Limita al contexto y verifica las salidas que importan; no te apoyes solo en trucos de redacción.

La alucinación es el modelo devolviendo texto seguro y bien construido que resulta ser falso, y es una propiedad de la arquitectura, no un error que se pueda parchar. El modelo ordena continuaciones por probabilidad sin ninguna señal de verdad asociada, así que en los bordes de su entrenamiento —temas raros, eventos recientes, cualquier cosa privada— de todos modos emite su suposición más probable. No vas a eliminar esto. El trabajo consiste en diseñar el sistema para que una respuesta equivocada se detecte o se contenga antes de que llegue a algo que importe.

Eso implica tres movimientos estructurales, ninguno de ellos relacionado con la redacción del prompt. Valida la forma de cada respuesta: haz que el modelo devuelva datos según un esquema para que la salida malformada o fuera de rango falle de manera ruidosa en lugar de fluir corriente abajo, que es lo que te da la salida estructurada. Mide tu tasa real de alucinación con evals, un conjunto reservado de entradas con respuestas conocidas y correctas evaluado de forma automática, en lugar de revisar unos pocos prompts al ojo y declarar que todo está bien. Y mantén a una persona en el bucle donde el costo de equivocarse sea alto, porque ninguna salvaguarda automatizada lo detecta todo.

La trampa detrás de todo esto es la calibración. La confianza del modelo está mal calibrada: la certeza declarada no es evidencia de corrección, y el tono de una respuesta no lleva ninguna información sobre su valor de verdad. Así que nunca hagas depender una decisión de que el modelo suene seguro.

Construye y prefiere una vía de abstención, un "no puedo responder esto con lo que se me dio" sancionado, y haz que abstenerse sea barato para que el sistema recurra a eso en lugar de inventar. Esa mentalidad estructural —asumir que cualquier respuesta individual puede estar equivocada y contener el daño— es sobre lo que se construye todo el capítulo de seguridad y límites.

JunoPor qué los modelos inventan cosas No puedes eliminar la alucinación, así que diseña para contenerla: valida la estructura con esquemas, mide la tasa con evals en lugar de revisar unos pocos resultados al ojo, y mantén a una persona donde equivocarse sea costoso. La confianza del modelo está mal calibrada, así que un tono seguro no es evidencia y nunca lo debes usar como base para decidir. Dale al sistema una vía barata y sancionada para abstenerse, y prefiérela siempre sobre una suposición segura.

Uniendo todo

Todo lo de este capítulo es una sola idea vista desde ángulos distintos. Un modelo es una pila congelada de números que predice el siguiente token, y casi todo comportamiento con el que vas a lidiar se desprende de eso:

• Predice un token a la vez a partir de un ranking de probabilidades, así que improvisa en lugar de recordar, y un toque de aleatoriedad (la temperatura) hace que las respuestas varíen.
• Los tokens son los fragmentos con los que trabaja: la unidad de tu factura, la unidad de tu límite de tamaño, y la razón por la que no puede contar letras con confiabilidad.
• La ventana de contexto es el escritorio de una sola solicitud, compartido por todo, y el modelo no recuerda nada entre solicitudes, así que la continuidad es tu trabajo.
• Su conocimiento está congelado en un corte de entrenamiento y nunca incluyó tus datos privados, por lo que buscas los datos y los pones en el prompt.
• La alucinación es el precio de un sistema que predice texto probable sin ninguna noción de verdad, y se reduce fundamentando y verificando, nunca solo con redacción ingeniosa.

Junta todo esto y una cantidad sorprendente de la ingeniería de IA resulta ser una sola tarea con distintos disfraces: poner el texto correcto sobre el escritorio, en la forma correcta, en el momento correcto, y nunca confiar ciegamente en la salida. El próximo capítulo, Modelos abiertos y cerrados, examina qué tipos de modelos existen y cómo consigues uno, y luego prompting es donde empiezas a dirigir toda esta predicción hacia lo que realmente quieres.

JunoUniendo todo Casi todo sobre un modelo se sigue de un solo hecho: es un conjunto congelado de números que predice el siguiente token. De ahí vienen las respuestas variadas, el costo y los límites basados en tokens, la falta de memoria entre solicitudes, un corte de entrenamiento y la alucinación. Buena parte de construir con estos modelos es poner el texto correcto sobre el escritorio y nunca confiar ciegamente en la salida.

Un solo hecho genera todo el capítulo: un modelo es una función congelada que predice el siguiente token a partir de una distribución de probabilidad. Sigue las consecuencias y tienes tu modelo de trabajo:

• Predicción más muestreo significa que la salida varía; la temperatura define cuánto.
• Los tokens son la unidad del costo, la unidad del límite, y la razón por la que las tareas a nivel de carácter le pertenecen al código.
• La ventana de contexto es finita y no tiene estado, así que reenvías y curas todo lo que el modelo necesita.
• El conocimiento está congelado en un corte y sin fuente, así que los datos actuales y privados vienen del retrieval, no de la memoria.
• La alucinación es estructural, se reduce fundamentando y verificando, no con redacción.

El patrón detrás de todo esto es el mismo: poner el texto correcto en el contexto, en la forma correcta, en el momento correcto, y verificar lo que vuelve. Eso es lo que construye el resto del manual, empezando por el panorama de los modelos abiertos y cerrados y luego prompting.

JunoUniendo todo Todo el capítulo es un hecho y sus consecuencias: un predictor congelado del siguiente token te da salida variada, costo y límites basados en tokens, ausencia de estado, un corte de conocimiento y alucinación. El trabajo que sigue es constante: poner el texto correcto en el contexto en la forma correcta, y después verificar lo que vuelve. El prompting es donde empiezas a hacerlo.

Todo esto se reduce a una frase: una función congelada predice el siguiente token sobre el texto que tú le proporcionas, sin estado, sin señal de verdad y sin plan. Cada propiedad de producción que manejas es un corolario:

• La salida es estocástica, así que pruebas distribuciones, no ejecuciones individuales.
• El costo y la latencia siguen los tokens, sobre todo los de salida, así que presupuestas y transmites en streaming.
• El contexto es finito y sin estado, así que la memoria es una decisión de ingeniería con sus propios modos de falla.
• El conocimiento paramétrico está congelado, tiene pérdida y no tiene fuente, así que todo lo crítico se fundamenta y se cita.
• La confianza no está calibrada, así que verificas en lugar de confiar.

La recompensa es que nada de esto se mueve cuando el modelo se mueve. Fija una versión, construye el arnés alrededor de los modos de falla, y el próximo lanzamiento es una mejora que evalúas, no una sorpresa que absorbes. El resto del manual es ese arnés, y empieza con el panorama, modelos abiertos y cerrados, luego prompting.

JunoUniendo todo Una sola frase rige el capítulo: un predictor del siguiente token, congelado, sin estado y sin señal de verdad. La salida estocástica, el costo dirigido por tokens, el contexto finito, el conocimiento congelado y la confianza sin calibrar son todos corolarios, y tu arnés existe para contener cada uno de ellos. La ventaja es que no se mueve cuando el modelo se mueve, así que fija una versión y construye alrededor de los modos de falla.