Cómo funcionan los LLM

docs.scrimba.com

Primero, el nombre. LLM es la abreviatura de large language model (modelo de lenguaje grande): el tipo de IA detrás de herramientas como ChatGPT, a la que le envías un prompt y recibes texto de vuelta. Este capítulo es la imagen funcional de qué es realmente uno.

Escribes una pregunta y unos segundos después aparece una respuesta fluida y confiada. Se lee como si el modelo te hubiera entendido y buscado la respuesta. Esa impresión es útil, y también está equivocada en formas que importan, y la brecha entre las dos es de donde vienen la mayoría de los errores de principiantes.

Este es el capítulo que da sus frutos para el resto de tu carrera con estas herramientas. No necesitas saber las matemáticas detrás del entrenamiento de un modelo para construir con uno. Sí necesitas una imagen funcional de qué está pasando realmente cuando responde, porque esa imagen explica todo lo demás: por qué funciona el prompting, por qué la misma pregunta da diferentes respuestas, por qué los modelos inventan hechos, por qué cuestan lo que cuestan, y por qué algunas características son difíciles cuando se ven como si deberían ser triviales. Todo lo que viene después en este manual es una consecuencia de las ideas aquí.

Este capítulo es el modelo mental debajo de estos sistemas: qué es un modelo, el bucle único que ejecuta, y los pocos atributos que explican el resto del manual. Nada es matemática. Todo es la diferencia entre codificar contra una caja negra y saber por qué se comporta como lo hace.

Cada técnica en capítulos posteriores, prompting, salida estructurada, recuperación, agentes, es una consecuencia de lo que estás a punto de leer. Entiende bien esta imagen y lo que parecía un bolsón de trucos empieza a sentirse como una máquina que puedes predecir.

Estos modelos fallan de formas específicas y repetibles, y este capítulo es por qué. Despoja la interfaz y un modelo de lenguaje es una función congelada que predice texto un trozo a la vez, y casi todos los modos de falla en producción, no determinismo, explosiones de costo, contexto perdido, respuestas confidentes equivocadas, salen de ese único hecho.

No hay matemática nueva aquí, y ese es el punto: la ventaja de ingeniería duradera está en el mecanismo, no en el modelo del mes. Léelo como el sustrato en el que descansa cada decisión posterior.

Qué es realmente un modelo

Despoja la interfaz de chat y un modelo de lenguaje grande es una cosa: una función matemática enorme, un conjunto fijo de miles de millones de números llamados parámetros (también los escucharás llamar pesos). Ese es el modelo completo. No una base de datos, no un motor de búsqueda, no una personita en una caja. Es una pila muy grande de números que toma texto y produce texto.

Esos números no vinieron de un programador escribiéndolos. Se establecieron durante el entrenamiento. El proveedor alimentó el modelo con una cantidad asombrosa de texto, libros, código, artículos, páginas web, y ejecutó un ejercicio simple miles de millones de veces: oculta la siguiente palabra, pídele al modelo que la prediga, y ajusta sus números un poco siempre que adivine mal. Repite eso a una escala enorme y los números se asientan lentamente en valores que son buenos para predecir texto. Eso es lo que es el entrenamiento: ajustar miles de millones de diales hasta que la predicción sea buena.

Dos cosas se desprenden de esto, y explican mucho del comportamiento que encontrarás después. Primero, el entrenamiento ocurre una vez, por adelantado, y es tremendamente caro. Para cuando llamas al modelo, los números están congelados. El modelo no aprende de tu conversación. Nada de lo que digas cambia sus parámetros. Se siente como si recordara y se adaptara, pero eso es el software a su alrededor, no el modelo mismo, un punto que regresa fuertemente en la sección de ventana de contexto.

Segundo, no hay una tabla de hechos dentro. El "conocimiento" vive como patrones cocidos en esos números, la forma en que un panadero que ha hecho diez mil panes tiene la técnica en sus manos sin leer una receta. El modelo aprendió la forma del texto correcto y sensato. Es por eso que puede ser fluido y estar equivocado en la misma oración: está reproduciendo la forma de una buena respuesta, no leyendo un hecho almacenado 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 fueron ajustados una vez durante el entrenamiento y luego congelados. No aprende de ti mientras charlas, y no tiene una tabla ordenada de hechos dentro, tiene patrones. Es por eso que puede sonar seguro y estar equivocado, así que siempre verifica cualquier cosa que importe.

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 fijos durante el entrenamiento; la entrada es el texto que envías. Porque es una función, la misma entrada bajo las mismas configuraciones produce las mismas puntuaciones subyacentes cada vez. Cualquier variación que veas entre ejecuciones proviene del paso de muestreo que elige palabras de esas puntuaciones, no del modelo cambiando de opinión.

El conocimiento que esa función lleva se almacena de manera imperfecta, extendido y comprimido en los pesos todo a la vez, no archivado como registros recuperables. No hay fila que puedas leer, no hay celda que puedas editar. Un hecho que el modelo "sabe" es realmente un patrón fuerte que los pesos reconstruyen bajo demanda, y a veces reconstruyen ligeramente mal. No puedes señalar dónde vive un hecho, y no puedes arreglar un hecho sin reentreneamiento.

El movimiento práctico es tratar el modelo como una función fija que llamas, no como una base de conocimiento que consultas. Confía 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 en la entrada tú mismo en lugar de confiar en que los pesos la guarden. Ese único hábito, suministrar los hechos en lugar de esperar que los recuerden, previene una gran parte de respuestas confidentes equivocadas.

JunoQué es realmente un modelo Piensa en el modelo como una función pura de pesos e entrada: misma entrada, misma configuración, mismas puntuaciones subyacentes, con variación de ejecución a ejecución viniendo del muestreo. Su conocimiento se comprime de manera imperfecta en los pesos, así que no puedes buscar o editar un hecho individual. Construye en consecuencia: trata el modelo como una función fija que llamas, y alimenta hechos específicos o actuales a través de la entrada en lugar de esperar que los pesos los recuerden.

Un modelo implementado es pesos congelados detrás de una API: miles de millones de números aprendidos, fijos en el momento del entrenamiento, calculando una función pura de (pesos, entrada). El único momento en que su comportamiento realmente cambia es cuando el proveedor envía un modelo diferente.

Eso tiene un borde operacional afilado. Una actualización silenciosa debajo del mismo endpoint puede cambiar tus salidas sin que una sola línea de tu código cambie, así que fija una versión específica del modelo, trata esa versión como parte de tu contrato, y re-ejecuta tus evals antes de adoptar una nueva. Adoptar "la última" con confianza es cómo un sistema funcionando se regresa silenciosamente.

Los pesos son memoria paramétrica comprimida, y es tanto imperfecta como inauditable. No puedes diff lo que un modelo "sabe" entre versiones, no puedes enumerar sus hechos, y no puedes probar que un hecho dado está ahí o es correcto. Así que nunca pongas la corrección de un hecho crítico en el recuerdo paramétrico. Si una respuesta incorrecta te costaría, suministra el hecho en la entrada desde una fuente que controlas y puedes citar, y mantén el modelo en el papel de fraseología y razonamiento sobre esa fuente, no siendo la fuente.

Cambiar deliberadamente los pesos es lo que hace fine-tuning, y vale la pena ser claro sobre qué compra. El fine-tuning desplaza de manera confiable el comportamiento y la forma, tono, formato, hábitos de tarea, pero no te da un almacén de hechos dependible y consultable. Úsalo para dar forma a cómo responde el modelo, no para instalar conocimiento que necesites confiar. Mantén los hechos en la entrada, mantén el estilo en los pesos, y no te sorprenderás por ninguno.

JunoQué es realmente un modelo Los pesos están congelados, así que el comportamiento solo se mueve cuando el proveedor envía un modelo diferente: fija la versión, hazla parte de tu contrato, y re-ejecuta evals antes de actualizar o un intercambio silencioso te regresará mientras duermes. La memoria paramétrica es imperfecta e inauditable; no puedes diff lo que sabe, así que mantén los hechos críticos en la entrada desde una fuente que controlas, no en el recuerdo. Y el fine-tuning desplaza el comportamiento y la forma, no un almacén de hechos confiable, 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 en lugar, el modelo hace exactamente un trabajo: predice el siguiente trozo de texto, una y otra vez.

Aquí está el bucle en cámara lenta. Le das algo de texto. Ejecuta ese texto a través de todos esos parámetros y produce una probabilidad para cada posible siguiente trozo que conoce, decenas de miles de opciones a la vez. Después de "La capital de Francia es", el trozo "París" podría obtener una puntuación del 97%, "un" del 1%, y todo lo demás casi nada.

El modelo luego elige un trozo, lo añade al texto, y ejecuta el todo nuevamente para elegir el siguiente. Repite hasta que la respuesta esté completa.

Ese es el motor completo. Una respuesta que lees como un pensamiento único fue construida un trozo a la vez, cada trozo elegido de un ranking fresco de probabilidades, sin plan sobre a dónde va la oración más allá de "qué es probable después". Cada capacidad que usarás, chat, código, traducción, uso de herramientas, razonamiento, es este mismo bucle ejecutándose por debajo.

El teclado del teléfono que sugiere tu siguiente palabra es la misma idea en miniatura. La diferencia es los miles de millones de parámetros detrás de la adivinanza. Entrenado en suficiente texto, "cuál es el trozo probable siguiente" resulta ser lo suficientemente bueno para escribir código funcionando y explicaciones claras. Pero el movimiento subyacente nunca cambia: es predicción, no comprensión, y no buscar una respuesta almacenada.

JunoPredecir el siguiente token El motor completo es un pequeño bucle: lee el texto hasta ahora, puntúa cada posible siguiente trozo, elige uno, y ve de nuevo hasta que la respuesta esté terminada. El modelo no tiene plan para la oración más allá de qué es probable después, así que una respuesta que lees como un pensamiento único fue construida un trozo a la vez. Eso es predicción, no comprensión, y no una respuesta almacenada siendo buscada.

El modelo hace una cosa una y otra vez: en cada paso lee todo el texto hasta ahora y emite una puntuación para cada token (un token es un trozo de texto, a menudo parte de una palabra) en su vocabulario, decenas de miles a la vez. Esas puntuaciones se convierten en una distribución de probabilidad, y el modelo muestrea un token de ella. Luego añade ese token al texto y ejecuta el todo nuevamente para elegir el siguiente. Después de "La capital de Francia es", "París" podría sostener casi toda la probabilidad y casi nada el resto.

Este alimentarse de nuevo es por qué se llama autorregresivo: cada nuevo token depende de todo el texto hasta ahora, incluyendo los tokens que ya ha escrito esta vez. No hay plan global y no hay borrador para revisar. El modelo se compromete un token a la vez, y porque no puede retractarse de un token, puede pintarse en una esquina: una palabra temprana confiada puede forzar el resto de la oración por un camino incómodo que luego tiene que terminar.

Ese único hecho explica algunas cosas que usarás en la práctica. Dejar que el modelo escriba su razonamiento antes de su respuesta final ayuda, porque más tokens significan más pasos y más computación gastada en el problema antes de que se comprometa con una respuesta. La estructura de salida se decide estrictamente de izquierda a derecha, así que la forma de una respuesta se establece conforme avanza, no se planifica por adelantado. Y el mismo bucle es lo que impulsa el uso de herramientas: el modelo predice los tokens que forman una llamada, la ejecutas, y el resultado se alimenta de nuevo como más texto para la siguiente predicción.

JunoPredecir el siguiente token En cada paso el modelo puntúa cada token en su vocabulario, muestrea uno, lo alimenta de nuevo, y repite: ese bucle de retroalimentación es lo que autorregresivo significa. No hay plan y no hay deshacer, así que se compromete token por token y puede pintarse en una esquina. Es por eso que escribir el razonamiento antes de la respuesta ayuda, y por qué el uso de herramientas es el mismo bucle con un resultado alimentado de nuevo.

La generación es secuencial por construcción: el modelo produce un token (un trozo de texto), lo alimenta de nuevo, y predice el siguiente, así que cada token de salida es un paso hacia adelante separado a través de la red. Leer tu entrada es comparativamente barato, procesado de una sola vez; la parte lenta y cara es el modelo escribiendo. La latencia y el costo escalan con la longitud de salida, no la longitud de entrada. Las palancas prácticas salen de eso: mantén las salidas cortas, transmite tokens para que el usuario vea progreso en lugar de esperar la respuesta completa, y no pagues por formato verboso que descartarás.

La otra consecuencia es la corrección. Porque no hay plan global, una sola pasada no se auto-corrige: el modelo se compromete de izquierda a derecha y no puede revisar un token una vez que está fuera. Es por eso que cualquier cosa que tenga que ser correcta quiere verificación o una segunda pasada sobre el primer borrador, y por qué un modelo que escribe su razonamiento antes de su respuesta tiende a hacerlo mejor, estás comprándole más pasos para comprometerse. Trata la primera generación como un borrador, no un veredicto.

Una palanca que vale la pena cableara: muchas configuraciones exponen probabilidades por token (logprobs, la puntuación de confianza del modelo para cada token que eligió). Puedes leerlas para marcar tramos de baja confianza, validar una respuesta que el modelo no estaba seguro, o dirigir casos inciertos a una segunda pasada o a una persona. Es una señal barata que ya tienes, y convierte "el modelo podría estar equivocado aquí" en algo en lo que puedas actuar programáticamente en lugar de adivinar.

JunoPredecir el siguiente token Cada token de salida es su propio paso hacia adelante, así que el costo y la latencia rastrean la longitud de salida, no la entrada: mantén las respuestas cortas, transmítelas, y deja de pagar por formato que descartas. No hay plan y no hay deshacer, así que una pasada no se auto-corrige; trata la primera generación como un borrador y añade una pasada de verificación para cualquier cosa que tenga que ser correcta. Si puedes leer por token logprobs, úsalos para marcar o dirigir los tramos en los que el modelo estaba menos seguro, es confianza que ya tienes y rara vez gastas.

El dial de aleatoriedad

Si el modelo siempre agarrara el trozo con la puntuación más alta, te daría la misma respuesta al mismo prompt cada vez, y esa respuesta a menudo sería plana y repetitiva. Así que la mayoría de las veces la selección tiene un poco de aleatoriedad: generalmente toma un trozo de alta probabilidad, pero no siempre el muy superior. Es por eso que puedes hacer exactamente la misma pregunta dos veces y obtener dos respuestas diferentes. Ese es el sistema funcionando como se diseñó, no un defecto.

Controlas cuánta aleatoriedad hay a través de una configuración llamada temperatura, que estableces cuando llamas el modelo en el capítulo sobre llamar modelos desde código. La intuición vale la pena tenerla ahora. A una temperatura baja, el modelo se mantiene cerca de sus mejores selecciones: 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, se eligen trozos de menor probabilidad más a menudo: más variado y creativo, y más probable que deambule hacia algún lugar equivocado. El brainstorming y la escritura creativa quieren el extremo más alto; cualquier cosa con una respuesta correcta quiere el extremo más bajo.

Así que un único dial desliza el modelo entre "cuidadoso y repetible" e "sorpresivo e inventivo". Es el mismo bucle de predicción de cualquier manera; la temperatura solo cambia qué tan atrevidamente el modelo llega más allá de su adivinanza más segura.

JunoEl dial de aleatoriedad La temperatura es tu dial 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 brainstorming y trabajo creativo, y obtienes más variedad junto con más posibilidades de deambular. Mismo bucle de predicción, solo un alcance más atrevido o más seguro.

Antes de que el modelo elija su siguiente trozo, tiene una probabilidad para cada candidato. La temperatura remodela esa distribución antes de que el modelo muestree de ella. Una temperatura baja agudiza la distribución hacia el token más probable único (más cercano a siempre tomar la mejor opción), así que la salida se vuelve enfocada y repetible. Una temperatura alta la aplana, dándole a los tokens menos probables una oportunidad real, así que la salida se vuelve más variada y más probable que deambule hacia el lado equivocado. Es por eso que el mismo prompt puede devolver respuestas diferentes: hay un sorteo sucediendo, y la temperatura establece cuán sesgadas son las probabilidades.

La temperatura no es el único botón aquí. Top-p (muestrea solo del conjunto más pequeño de tokens cuyas probabilidades se suman a p) y top-k (solo los k tokens más probables) ambos recortan el grupo de candidatos antes del muestreo. Se superponen con la temperatura en efecto, así que ayuda pensar en ellos como una configuración de aleatoriedad en lugar de tres independientes.

El movimiento práctico es establecer la temperatura explícitamente por tarea en lugar de confiar en lo que sea que default se envíe. Baja para extracción, clasificación, y cualquier cosa que emita salida estructurada que analices después; más alta para ideación y redacción donde la variedad es el punto. Observa las interacciones: apilar una temperatura alta con un top-p de 1 deja la cola completa en juego, lo cual funciona en tu contra cuando necesitas resultados confiables y parseables.

JunoEl dial de aleatoriedad La temperatura remodela la distribución de probabilidad antes del muestreo: baja la agudiza hacia el token superior para salida enfocada, alta la aplana para variedad. Trata temperature, top_p, y top_k como una configuración de aleatoriedad, no tres. Establécela por tarea: baja para extracción, clasificación, y salida estructurada; más alta para ideación. No parejes una temperatura alta con top_p de 1 cuando necesites resultados parseables.

La temperatura escala la distribución de puntuaciones antes del muestreo, y el atajo tentador es establecerla en 0 y llamar determinista a la salida. Está cerca, pero no es una garantía. Las matemáticas de punto flotante, el lote en el servidor, y el enrutamiento dentro de modelos grandes todos introducen pequeño no determinismo incluso a 0. Así que no construyas caching de coincidencia exacta o pruebas de coincidencia exacta que asuman salida idéntica de bytes para un prompt repetido; esa suposición falla intermitentemente, y las fallas intermitentes son el tipo caro de perseguir.

Esto forma 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 ejecutándolo varias veces y mirando la distribución de salidas: con qué frecuencia aterrizas en especificación, cuán ancho es la varianza, a dónde va la cola equivocada. Ese es el trabajo que hacen tus evals, y quieren suficientes muestras para ver la propagación, no una pasada afortunada.

Trata temperatura, top-p (muestrea solo del conjunto más pequeño de tokens cuyas probabilidades alcanzan un p acumulativo) y top-k (mantén solo los k tokens más probables) como un presupuesto de muestreo que sintonizas juntos en lugar de tres diales que estableces por reflejo. Elige la aleatoriedad más baja que aún da variedad aceptable para la tarea: apretando los tres a la vez puede colapsar la salida en algo repetitivo y frágil, mientras que dejarlos todos abiertos te da variedad que luego tienes que validar alrededor. El costo es real en ambos lados, así que gástalo deliberadamente.

JunoEl dial de aleatoriedad Temperatura 0 es casi determinista, no garantizado: punto flotante, lote, y enrutamiento interno filtran no determinismo, así que omite caching de coincidencia exacta y pruebas de coincidencia exacta. Evalúa el comportamiento muestreado sobre varias ejecuciones y lee la distribución, no una pasada; eso es para lo que son tus evals. Sintoniza temperature, top_p, y top_k como un presupuesto de muestreo, y elige la aleatoriedad más baja que aún da variedad aceptable.

Tokens

Los "trozos" que predice un modelo tienen un nombre: tokens. Un token es un trozo de texto, a menudo una palabra completa, a veces solo parte de una. Las palabras comunes suelen ser un único token, mientras que las palabras más largas o raras se dividen en varias.

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

¿Por qué dividir el texto en estos trozos extraños en lugar de usar palabras completas o letras individuales? Es un tradeoff. Las letras individuales harían cada secuencia enormemente larga, y la longitud es lo que el modelo tiene que calcular. Las palabras completas necesitarían un vocabulario de millones de entradas y aún se romperían la primera vez que alguien inventa una palabra o comete un error tipográfico. Los tokens son el camino medio: un vocabulario fijo de decenas de miles de piezas comunes que pueden ser encajadas juntas para deletrear cualquier cosa, incluyendo palabras que el modelo nunca ha visto.

Aquí está la consecuencia por debajo del capó que sorprende a la gente. El modelo nunca ve letras. Ve tokens, que para él son realmente números de ID para esos trozos. Así que tareas que nos parecen sin esfuerzo pueden ser difíciles para él: contar las letras en una palabra, invertir una cadena, notar que "fresa" tiene tres r.

No es ser tonto. No percibe los caracteres individuales en absoluto, la forma en que no puedes saborear los granos separados de harina en un pan terminado. Cuando un modelo se tropieza con una tarea de deletreo o conteo de caracteres, esto es por qué, y la solución suele ser hacer esa parte en código normal en lugar.

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

• Dinero: los proveedores cobran por token, tanto los tokens que envías como los tokens que escribe el modelo de vuelta, así que un documento largo dentro y una respuesta larga fuera ambos cuestan más. Una medida aproximada para inglés es aproximadamente cuatro caracteres por token, o 100 tokens por cada 75 palabras; el código y otros lenguajes a menudo se dividen en más tokens, que es parte de por qué pueden costar más. Lo encontrarás directamente cuando empieces a llamar modelos desde código.
• Límites: hay un techo en cuántos tokens el modelo puede manejar a la vez, que es la siguiente sección.

JunoTokens Un token es un trozo de texto, generalmente una palabra o parte de una, y el modelo lee esos trozos como números de ID, no como letras. Es por eso que puede tropezar en conteo o deletreo, así que entrega ese trabajo al código simple. Y ya que pagas por token en ambas direcciones y hay un tope en cuántos caben a la vez, menos tokens significa menos costo y más espacio.

El modelo predice tokens, trozos de texto que a menudo son una palabra completa y a veces un fragmento. La pieza que hace la división es el tokenizador, y funciona fuera de un vocabulario aprendido construido mediante la fusión repetida de los pares de caracteres más comunes hasta que tienes un conjunto fijo de decenas de miles de piezas (un esquema generalmente llamado codificación de pares de bytes, o BPE). Ese historial es por qué las palabras frecuentes terminan como un token único mientras que las raras se fragmentan en partes: los patrones comunes se fusionaron durante el entrenamiento, los incomunes nunca lo hicieron.

Dos hechos prácticos salen de esto. Primero, el modelo nunca maneja caracteres, solo IDs de token, así que cualquier operación a nivel de carácter (contar letras, invertir una cadena, cortar en una posición exacta) es tambaléante dentro de un prompt y confiable en tu propio código. Empuja ese trabajo al código y deja que el modelo haga la parte de lenguaje. Segundo, la tokenización es específica del modelo, así que los conteos de tokens no son portátiles. La misma oración puede costar un número diferente de tokens en un tokenizador diferente, que importa el momento en que presupuestes costo o ajustes contenido en una ventana.

El punto para construir: no estimes los conteos de tokens a partir de la longitud de caracteres. Cuenta con el tokenizador real que usa el modelo, porque ese es el número por el que se te factura y se te limita. Lo encuentras todo esto concretamente cuando empiezas a llamar modelos desde código, donde el conteo que envías más el conteo que recibes de vuelta es la factura.

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

Los tokens son el medidor en todo lo que envías. Un token es un trozo de texto del vocabulario aprendido del tokenizador, y la factura por token más el techo de contexto fijo son los dos números que moldean tu costo y tu diseño. La cómoda regla de cuatro caracteres por token se sostiene para prosa inglesa simple y se desmorona exactamente donde vive la producción: código, JSON, formato profundamente anidado, y scripts no latinos todos se fragmentan en muchos más tokens de los que la heurística predice. Así que presupuesta con el tokenizador real, no el calibre, o tus estimaciones de costo y capacidad estarán equivocadas precisamente en los payloads que realmente envías.

La fragmentación no se distribuye uniformemente, y es un problema de equidad y costo a escala. El mismo significado en un idioma no latino puede costar varios veces los tokens de su versión en inglés, así que la misma característica es silenciosamente más cara, y más lenta, para algunos de tus usuarios que para otros. Vale la pena medir por idioma antes de prometer a alguien un precio fijo o una latencia fija.

Dos más hábitos del campo. El formato es gasto: espacios en blanco, delimitadores verbosos, y markdown decorativo todos cuestan tokens por cero significado añadido, así que mantén la estructura que alimentas al modelo compacta y deja que tu código añada presentación después. Y alimenta texto limpio y normal, porque los tokens raros o malformados (mojibake, caracteres de control extraviados, codificaciones extrañas) se sientan en los rincones delgados y entrenados insuficientemente del vocabulario y pueden desencadenar salida extraña. Nada de esto es exótico; es la diferencia entre un presupuesto de tokens en el que confías y uno que te sorprende en la factura.

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

La ventana de contexto

La ventana de contexto es cuánto texto puede tomar el modelo a la vez, medido en tokens. Imagínalo como el tamaño del escritorio del modelo. Todo lo involucrado en una sola solicitud tiene que caber en ese escritorio de una vez: tus instrucciones, la conversación hasta ahora, cualquier documento que hayas pegado, y la respuesta que el modelo está escribiendo.

¿Por qué hay un límite en absoluto? Viene de cómo funciona la predicción. Para elegir el siguiente token, el modelo pesa cómo cada token en la entrada se relaciona con todos los demás tokens, así que puede decir que "eso" se refiere al gato tres oraciones atrás. Esa comparación de todos con todos es lo que permite que el modelo rastreee significado en un pasaje, y también es lo que hace que las entradas largas sean costosas de procesar. El proveedor establece un techo, la ventana de contexto, para mantener cada solicitud manejable.

Cuando el escritorio está lleno, algo tiene que salir. Si una conversación dura lo suficiente para desbordar la ventana, las primeras partes desaparecen y el modelo ya no puede verlas. Por eso un chat largo parece "olvidar" lo que dijiste al inicio. No olvidó en ningún sentido humano; esos tokens están fuera del escritorio. También ayuda saber que los modelos tienden a prestar la máxima atención al principio y al final de lo que está en el escritorio y pueden perder de vista las cosas enterradas en el medio, así que dónde pones el texto importante importa cuando llenas la ventana.

Ahora el punto que atrapa a casi todo principiante, e importa más que todo el resto. 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, o cualquier cosa de hace un minuto.

Una aplicación de chat se siente como una conversación fluida solo porque la aplicación silenciosamente reenvía el historial completo con cada nuevo mensaje. La continuidad es algo que el software alrededor del modelo construye, no algo que el modelo tenga.

Ese único hecho moldea cómo construyes todo a partir de aquí. Si quieres que el modelo sepa algo, tienes que ponerlo en el escritorio en esa solicitud: la conversación hasta ahora, los detalles del usuario, los documentos relevantes, todo ello, cada vez. Una gran parte de este manual es realmente sobre hacer esa una cosa bien, obtener el texto correcto en el escritorio.

JunoLa ventana de contexto La ventana de contexto es el escritorio del modelo: cada solicitud tiene que caber en él, y cuando desborda el texto más antiguo cae. El modelo no guarda memoria entre llamadas, así que la aplicación reenvía el historial completo cada vez para fingir un chat continuo. Tu trabajo a partir de aquí es obtener el texto correcto en ese escritorio en cada solicitud.

Piensa en la ventana de contexto como un presupuesto fijo de tokens que una solicitud obtiene para gastar, cubriendo tus instrucciones, la conversación en ejecución, cualquier documento pegado, y la respuesta siendo generada. La ventana existe por cómo el modelo lee la entrada: un mecanismo llamado atención compara cada token contra cada otro token para trabajar qué se relaciona con qué. Esa comparación es lo que permite que el modelo resuelva un "eso" de vuelta al sustantivo al que apunta, y su costo crece aproximadamente con el cuadrado de la longitud de entrada. Dobla los tokens y haces más del doble el trabajo, que es la razón real por la que las entradas largas son lentas y elevan el costo.

Caber dentro de la ventana no es lo mismo que el modelo usando todo en ella. Hay un efecto bien documentado llamado perdido en el medio: los modelos atienden más confiablemente al inicio y al final de la entrada y pueden hojear material estacionado en el centro. Así que coloca tus instrucciones y datos más importantes cerca de la parte superior o inferior del prompt, no enterrado en una pared de texto pegado.

La otra mitad de esto es memoria, y el hecho clave es que el modelo es sin estado: no recuerda nada entre solicitudes separadas. Cada llamada comienza con una ventana vacía, así que la única forma en que el modelo sabe la conversación hasta ahora es que la envías de nuevo cada vez. Reenviar y moldear ese historial es tu trabajo, no del modelo. Mientras el chat crece más allá de la ventana, manéjalo tú mismo recortando turnos antiguos o reemplazándolos con un resumen corto, así que los tokens que mantienes son los que aún importan.

Eso pone la construcción de contexto en el centro de construir con estos modelos. Decidir qué entra en la ventana, en qué orden, y cómo comprimir lo que vino antes es la mayoría del trabajo, y prompting es donde aprendes a moldearlo deliberadamente.

JunoLa ventana de contexto La ventana es un presupuesto de token cubriendo 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 perdido en el medio, así que pon lo que importa cerca del inicio o fin. El modelo es sin estado, así que reenviar y recortar el historial de conversación es tu trabajo, cada llamada.

Trata la ventana de contexto como un techo, no una meta. Es el presupuesto de token que una sola solicitud obtiene, abarcando tus instrucciones, el historial en ejecución, documentos recuperados, y la salida.

Cada token que pones en él cuesta dinero y latencia, porque el paso de atención (la comparación de todos con todos de token que el modelo ejecuta para leer entrada) escala aproximadamente con el cuadrado de la longitud. Peor, la evocación efectiva se degrada bien antes de que alcances el límite: el efecto perdido en el medio significa que la precisión en material enterrado en el centro se cae incluso cuando técnicamente cabe. Así que cura el contexto en lugar de dumping todo en, y cuando los datos fuente 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 la computación para un prefijo sin cambios a través de cache de prompt, donde el estado interno cacheado es el cache KV, el trabajo almacenado del modelo para tokens que ya ha leído. Pon contenido estable primero (instrucciones del sistema, material de referencia fijo) y contenido variable al final, y las llamadas repetidas se vuelven más baratas y rápidas porque el frente del prompt se sirve desde cache. Reordena ese prefijo descuidadamente y invalidas el cache y pagas precio completo nuevamente.

La memoria entre turnos no es una característica que el modelo tenga; es una opción de ingeniería que haces, y cada opción falla de su propia manera:

• Ventanas simples, manteniendo los turnos más recientes, es barato pero silenciosamente deja caer hechos tempranos que el usuario aún espera que sepas.
• Summarización sostiene más historial en menos tokens pero pierde detalle y puede silenciosamente codificar sus propios errores.
• Recuperación tira de vuelta solo lo que es relevante pero depende completamente de que tu índice devuelva las piezas correctas.

Elige por caso de uso, y asume que cualquiera que escojas eventualmente expondrá lo incorrecto; instrumento para él en lugar de confiar en él.

JunoLa ventana de contexto La ventana es un techo, no una meta: el costo y la latencia suben con cada token y la evocación se pudre antes de que golpees el límite, así que cura y confía en recuperación para cualquier cosa grande. Contenido estable primero, variable al final, así que cache de prompt (el cache KV) realmente paga. La memoria entre turnos es tu opción de diseño entre ventanas, summarización, y recuperación, y he sido atrapado por los tres, así que instrumenta el que escojas.

Lo que el modelo no sabe

Todo el conocimiento de un modelo fue cocido mientras se entrenaba, así que solo sabe lo que estaba en esos datos de entrenamiento, y esos datos se recopilaron hasta algún punto de corte en el pasado. Dos límites salen directamente de esto.

Primero, no sabe nada que haya sucedido después de su punto de corte. Pregunta sobre noticias de la semana pasada o una biblioteca que salió este mes y no tiene idea real, aunque puede felizmente producir una respuesta que suene plausible de todas formas. Segundo, nunca supo nada privado. Los documentos internos de tu compañía, el historial de pedidos de un usuario, los contenidos de tu base de datos: nada de eso estaba en el texto público en el que se entrenó, así que no puede saberlo, sin importar cuán agradablemente preguntes.

Hay un límite más tranquilo también. El modelo generalmente no puede decirte de dónde vino algo que "sabe", porque el conocimiento se mezcla dentro de él en lugar de ser archivado como hechos separados y originales. Puede escribirte una cita, pero está prediciendo cómo debería verse una cita, no buscando una real.

Esta es la razón de una técnica que encontrarás después llamada recuperación, o RAG. Si quieres que un modelo responda sobre eventos recientes o tus propios datos privados, no lo reentrenas. Buscas el texto relevante tú mismo y lo pones en el escritorio en el momento de la solicitud, así que el modelo tiene los hechos enfrente de él en lugar de adivinar. Un modelo es un razonador sobre el texto que le das mucho más que un pozo confiable de hechos específicos.

JunoLo que el modelo no sabe Un modelo solo sabe lo que estaba en sus datos de entrenamiento, hasta un punto de corte en el pasado, así que se pierde eventos recientes y cualquier cosa privada, y no puede confiablemente decir de dónde vinieron sus hechos. Cuando necesitas información actual o privada, no reentrenes: busca el texto relevante y entrégalo al modelo en la solicitud. Trata el modelo como algo que razona sobre lo que le das, no como una memoria confiable.

El conocimiento construido de un modelo, su conocimiento paramétrico (los hechos codificados en sus pesos, los números ajustables establecidos durante el entrenamiento), está congelado en el punto de corte de entrenamiento. Nada que pasó después de esa fecha está en allí, y nada privado jamás fue, porque los pesos fueron moldeados por texto público. Así que la memoria te da dos brechas predecibles: recencia, cualquier cosa después del punto de corte, y privacidad, cualquier cosa que nunca estuvo en datos de entrenamiento público.

Esas dos brechas son realmente una brecha vista desde dos lados, y se cierran del mismo modo: pon el texto necesario en la solicitud. Buscas el artículo reciente o la fila de base de datos relevante tú mismo y la suministras junto a la pregunta, así que el modelo lee el hecho en lugar de recordarlo. Esta es la idea central detrás de RAG, generación aumentada por recuperación, que usarás cada vez que las respuestas deben reflejar información actual o propietaria.

El conocimiento paramétrico también lleva sin source adjunto. Los hechos se mezclan en los pesos, no se almacenan como entradas discretas con procedencia, así que el modelo no puede confiablemente decirte de dónde vino algo. Una cita que produce es generada para verse bien, no recuperada de un registro, que es exactamente por qué basar la respuesta en texto que proporcionas vale el esfuerzo.

La regla práctica para construir: no pidas al modelo que recuerde hechos actuales o propietarios de la memoria. Si un hecho debe estar bien, búscalo y suministralo, y deja que el modelo razone sobre él.

JunoLo que el modelo no sabe El conocimiento paramétrico, los hechos codificados en los pesos, está congelado en el punto de corte de entrenamiento y no lleva source, así que el modelo se pierde información reciente y privada y no puede confiablemente citar nada. Ambas brechas se cierran del mismo modo: busca el texto relevante y ponlo en la solicitud, que es la idea detrás de RAG. Como regla, no tengas el modelo recordando hechos actuales o propietarios de la memoria; suministraalos y deja que razone sobre ellos.

La memoria paramétrica del modelo, el conocimiento sostenido en sus pesos (los números ajustables fijos durante el entrenamiento), no se versiona y no es auditable. No puedes diff, señalar dónde vive una afirmación, o confirmar que no se ha derivado. Así que para cualquier cosa que debe ser correcta, actual, o conforme, no confíes en lo que el modelo dice: basa la respuesta en una fuente recuperada y cita esa fuente. Trata el conocimiento construido como un prior fluido, no un sistema de registro.

El punto de corte también es más borroso que una fecha única sugiere. Los datos de entrenamiento no son uniformes justo hasta esa fecha: el material reciente es más delgado y menos digerido que lo más antiguo, material bien cubierto, así que los hechos recientes pero pre-corte se saben de manera desigual. Un modelo puede estar confiado y equivocado sobre algo de un año antes de su punto de corte mientras clava un hecho de una década atrás, que es por qué "¿está antes del punto de corte?" es una garantía más débil de lo que parece, y por qué recuperas cualquier cosa que deba estar bien.

Llega por la herramienta correcta para la brecha, porque las dos comunes no son intercambiables. La recuperación suministra hechos al momento de la solicitud y se mantiene actual conforme tus fuentes se actualizan. Fine-tuning, continuar entrenamiento en tus propios ejemplos, desplaza forma y comportamiento, tono, formato, cómo el modelo sigue tus convenciones, y es una forma pobre y caduca de inyectar conocimiento: los hechos entrenados están congelados de nuevo, difíciles de actualizar, y aún sin source. Usa recuperación para qué es verdad, fine-tuning para cómo debería sonar.

JunoLo que el modelo no sabe La memoria paramétrica no se versiona y no es auditable, así que para cualquier cosa que deba estar correcta, actual, o conforme, basa la respuesta en una fuente recuperada y cita eso, no la palabra del modelo. Recuerda el punto de corte es borroso: hechos recientes pero pre-corte se saben de manera desigual, así que recupera cualquier cosa que deba estar bien. Y empareja la herramienta con la brecha: recuperación suministra hechos, mientras que fine-tuning desplaza forma y comportamiento y es una forma caduca de inyectar conocimiento.

Por qué los modelos inventan cosas

A veces un modelo declara algo falso con confianza total: una cita que nadie dijo, una función que no existe, una cita a un estudio que nunca fue escrito. Esto se llama una 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 sentido interno de "verdadero" versus "falso". Solo tiene "texto probable" versus "texto improbable". La mayoría de las veces esos se alinean, porque en el texto en el que aprendió, las declaraciones verdaderas son mucho más comunes que las falsas, así que la continuación probable es generalmente la correcta.

Pero cuando el modelo golpea una brecha, algo en el que nunca fue entrenado, o tus datos privados que nunca pudo haber visto, no se detiene y marca la brecha. No puede confiablemente decir qué no sabe. Hace la única cosa que jamás hace: produce la continuación más probable.

Una respuesta confiada, bien formada, equivocada es a menudo exactamente lo que suena más probable. La misma maquinaria que la hace fluida la hace fluida cuando está equivocada.

Esta es la parte para sentarse con: la alucinación no es un glitch que puedas prompt completamente. Puedes reducirla, y los capítulos posteriores muestran cómo. Decirle al modelo que se le permite decir "No sé" ayuda un poco. Pedirle que responda solo desde texto que proporcionas ayuda mucho más, porque ahora no hay brecha para llenar desde entrenamiento congelado. Pero la tendencia viene de qué es el modelo fundamentalmente, una máquina de probabilidad sin fact-checker adentro, así que los arreglos duraderos son estructurales: dale los hechos para trabajar en lugar de esperar que estén en su entrenamiento, y verifica respuestas que importen en lugar de confiar en ellas.

Lleva una regla fuera de este capítulo por encima de todo lo demás: la confianza de un modelo no te dice nada sobre si está bien. Fluidez y corrección son producidas por el mismo proceso y se separan todo el tiempo. Construye como si cualquier respuesta única pudiera estar equivocada, porque cualquier respuesta única podría ser.

JunoPor qué los modelos inventan cosas Una alucinación es el modelo confiadamente llenando una brecha con texto que suena bien pero no, porque solo sabe "probable" y no "verdadero". Puedes bajar cuán a menudo sucede, pero no puedes prompt eso completamente, así que el movimiento seguro es darle al modelo los hechos que necesita y verificar las respuestas que importen. Y recuerda el grande: un tono confiado no es prueba, así que nunca confíes en la certeza por sí sola.

Cuando un modelo inventa una cita, una función, o una cita y la declara con confianza total, eso es una alucinación, y cae directamente de cómo funciona el modelo. El modelo no tiene señal para verdad. Puntúa continuaciones por "texto probable" versus "texto improbable", y la mayoría del tiempo probable y verdadero se superponen porque declaraciones verdaderas dominaron sus datos de entrenamiento.

La alucinación se dispara exactamente donde esa superposición se rompe: a los bordes de su conocimiento, en temas raros o de nicho, y en tus datos privados en los que nunca fue entrenado. Allí el modelo aún produce su continuación más probable, y una respuesta fluida, bien formada, equivocada es a menudo lo que puntúa más alto.

Así que no puedes arreglar esto solo con palabras, pero puedes clasificar tus mitigaciones por cuánto realmente ayudan. La palanca más grande por lejos es grounding: pon los hechos reales en el prompt y dile al modelo que responda solo desde ese texto suministrado, idealmente citándolo. Ahora no hay brecha para que llene desde el entrenamiento congelado. Recuperar el texto correcto para suministrar es su propia técnica, cubierta en RAG.

Debajo de eso, dale al modelo un escape hatch explícito, permiso de responder "No sé" en lugar de adivinar, que quita algo de la presión de inventar. Y mantén temperatura (el dial de aleatoriedad en selección de token) modesta para trabajo fáctico, ya que alta aleatoriedad abre la puerta a continuaciones improbables y fuera de base.

La consecuencia práctica: constriñe el modelo al contexto que proporcionas, y verifica salidas que importen. Trata fraseo de prompt como un pequeño ajuste en top de esos movimientos estructurales, nunca como la defensa completa. Un modelo que suena seguro no te ha dicho nada sobre si está correcto, porque fluidez y corrección vienen del mismo proceso y rutinariamente divergen.

JunoPor qué los modelos inventan cosas La alucinación es el modelo emitiendo texto fluido, probable sin verificación interna para verdad, y empeora en los bordes de su conocimiento y en datos que nunca vio. Clasifica tus arreglos por impacto: groundearla en texto que suministras (la palanca más grande), dale espacio para decir "No sé", dile que responda solo desde el contexto proporcionado y citelo, y mantén temperature modesta para trabajo fáctico. Constriñe al contexto y verifica las salidas que importen; no confíes en trucos de palabras solos.

La alucinación es el modelo devolviendo texto confiado, bien formado que sucede ser falso, y es una propiedad de la arquitectura, no un bug que parcheas. El modelo clasifica continuaciones por probabilidad sin señal de verdad adjunta, así que a los bordes de su entrenamiento, temas raros, eventos frescos, cualquier cosa privada, aún emite su adivinanza más probable. No eliminarás esto. El trabajo es diseñar el sistema así una respuesta equivocada es atrapada o contenida antes de que llegue a cualquier cosa que importe.

Eso significa tres movimientos estructurales, ninguno de ellos fraseo de prompt. Valida la forma de cada respuesta: haz que el modelo devuelva datos contra un esquema así salida malformada o fuera de rango falla ruidosamente en lugar de fluir río abajo, que es lo que salida estructurada te compra. Mide tu tasa de alucinación real con evals, un conjunto separado de entradas con respuestas conocidas buenas puntuadas automáticamente, en lugar de verificación puntual algunos prompts y llamarlo bien. Y mantén un humano en el bucle donde sea que el costo de estar equivocado es alto, porque ninguna guardia automatizada atrapa todo.

La trampa debajo de todo esto es 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 información sobre su valor de verdad. Así que nunca puerta una decisión en el modelo sonando seguro.

Construye y prefiere una ruta de abstención, una "No puedo responder esto desde lo que me fue dado" sancionada, y haz que abstener sea barato así el sistema lo alcanza en lugar de inventar. Esa mentalidad estructural, asume cualquier respuesta única puede estar equivocada y contiene el daño, es en qué está construido el capítulo entero seguridad y límites.

JunoPor qué los modelos inventan cosas No puedes borrar alucinación, así que ingeniería para contención: valida estructura con esquemas, mide la tasa con evals en lugar de ojear unos pocos salidas, y mantén un humano donde estar equivocado es caro. La confianza del modelo está mal calibrada, así que un tono seguro no es evidencia y nunca puerta en él. Dale al sistema una forma barata, sancionada de abstener, y prefierela sobre una adivinanza confiada cada vez.

Juntarlo todo

Todo en este capítulo es una idea vista desde diferentes ángulos. Un modelo es una pila congelada de números que predice el siguiente token, y casi cada comportamiento que tratarás sale de eso:

• Predice un token a la vez desde un ranking de probabilidades, así que improvisa en lugar de recuerda, y un toque de aleatoriedad (temperatura) significa respuestas varían.
• Tokens son los trozos en los que funciona: la unidad de tu factura, la unidad de tu límite de tamaño, y la razón por la que no puede confiablemente contar letras.
• La ventana de contexto es el escritorio de una sola solicitud, compartido por todo, y el modelo no recuerda nada entre solicitudes, así que continuidad es tu trabajo.
• Su conocimiento está congelado en un punto de corte de entrenamiento y nunca incluyó tus datos privados, que es por qué buscas hechos y los pones en el prompt.
• La alucinación es el precio de un sistema que predice texto probable sin sentido de verdad, reducido por grounding y verificación, nunca solo por fraseo inteligente.

Sostén estos juntos y una cantidad sorprendente de ingeniería de IA resulta ser una tarea en disfraces diferentes: obtén el texto correcto en el escritorio, en la forma correcta, en el momento correcto, y nunca confíes la salida ciegamente. El siguiente capítulo, Modelos abiertos y cerrados, mira qué tipos de modelos hay y cómo obtienes uno, y luego prompting es donde empiezas a dirigir toda esta predicción hacia lo que realmente quieres.

JunoJuntarlo todo Casi todo sobre un modelo sigue de un hecho: es un conjunto congelado de números prediciendo el siguiente token. De eso vienen respuestas variadas, costo basado en token y límites, sin memoria entre solicitudes, un punto de corte de entrenamiento, y alucinación. Una gran parte de construir con estos modelos es obtener el texto correcto en el escritorio y nunca confiar la salida ciegamente.

Un hecho genera el capítulo completo: un modelo es una función congelada que predice el siguiente token desde una distribución de probabilidad. Traza las consecuencias y tienes tu modelo funcional:

• Predicción más muestreo significa salida varía; temperatura establece cuánto.
• Los tokens son la unidad de costo, la unidad del límite, y por qué tareas a nivel de carácter pertenecen en código.
• La ventana de contexto es finita y sin estado, así que reenexvías y curas todo lo que el modelo necesita.
• El conocimiento está congelado en un punto de corte y sin source, así que hechos actuales y privados vienen de recuperación, no recuerdo.
• La alucinación es estructural, reducida por grounding y verificación, no por palabras.

El patrón debajo de todo es el mismo: obtén el texto correcto en el contexto, en la forma correcta, en el momento correcto, y verifica lo que vuelve. Eso es lo que construye el resto del manual, comenzando con el paisaje de modelos abiertos y cerrados y luego prompting.

JunoJuntarlo todo El capítulo completo es un hecho y su caída: un predictor de siguiente token congelado te da salida variada, costo basado en token y límites, sin estado, un punto de corte de conocimiento, y alucinación. El trabajo que sigue es constante: obtén el texto correcto en el contexto en la forma correcta, luego verifica lo que vuelve. Prompting es donde empiezas a hacerlo.

Todo aquí se reduce a una oración: una función congelada predice el siguiente token sobre el texto que 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 únicas.
• El costo y la latencia rastrean tokens, especialmente salida, así que presupuestas y transmites.
• El contexto es finito y sin estado, así que memoria es una opción de ingeniería con modos de falla.
• El conocimiento paramétrico es congelado, imperfecto, y sin source, así que cualquier cosa crítica obtiene grounding y cita.
• La confianza está mal calibrada, así que verificas en lugar de confiar.

El pago es que nada de esto se mueve cuando el modelo lo hace. Fija una versión, construye el arnés alrededor de los modos de falla, y el siguiente release es una actualización que evalúas, no una sorpresa que absorbes. El resto del manual es ese arnés, y comienza con el paisaje, modelos abiertos y cerrados, luego prompting.

JunoJuntarlo todo Una oración ejecuta el capítulo: un predictor de siguiente token congelado, sin estado, sin señal de verdad. Salida estocástica, costo basado en token, contexto finito, conocimiento congelado, y confianza mal calibrada son todos corolarios, y tu arnés existe para contener cada uno. La ventaja es que no se mueve cuando el modelo lo hace, así que fija una versión y construye alrededor de los modos de falla.