LLM Fundamentals

Un modelo de lenguaje de gran escala

Un Large Language Model, o LLM, es un modelo de lenguaje de gran escala que aprende regularidades sobre representaciones de lenguaje para estimar distribuciones, producir continuaciones u ofrecer representaciones útiles según su objetivo y entrenamiento. «Large» es una caracterización contextual que ha cambiado históricamente; no se fija aquí un umbral universal de parámetros. El concepto identifica un modelo, no una interfaz de chat, proveedor o agente.

Un language model asigna o estima posibilidades sobre secuencias. En modelos generativos autoregresivos, predecir el siguiente token condicionado por el contexto es una operación central. Otros objetivos pueden aprender representaciones mediante partes ocultas u otras formulaciones. No todo modelo de lenguaje utiliza exactamente el mismo objetivo ni todas sus capacidades se describen adecuadamente como un único producto conversacional.

Machine Learning Fundamentals conserva entrenamiento, inferencia y generalización. Neural Networks explica la familia amplia de modelos; Transformers desarrolla una arquitectura utilizada por muchos LLMs modernos. Es una ruta de lectura, no una afirmación de que cualquier Transformer sea un LLM o de que otras familias hayan dejado de existir.

La obra académica Speech and Language Processing de Jurafsky y Martin, manuscrito de 2026 consultado el 2026-10-30, organiza modelos de lenguaje, tokenización, pretraining y post-training en capítulos relacionados. Aquí interesa su conexión para ingeniería de sistemas, sin reproducir un curso completo de NLP ni un catálogo de modelos disponibles.

Texto, tokens y representaciones

Un tokenizer transforma texto en unidades que el modelo puede representar mediante un vocabulario o esquema definido. Un token puede corresponder a parte de una palabra, a una palabra, a puntuación o a otros fragmentos según el sistema. Token no equivale a palabra: contar palabras visibles no permite deducir exactamente cuánta capacidad tokenizada consume un contenido.

Los límites pueden cambiar entre tokenizers, idiomas y tipos de entrada. Código, identificadores o texto con caracteres poco frecuentes pueden dividirse de maneras distintas. La longitud en caracteres tampoco define por sí sola longitud tokenizada. Las convenciones de representación forman parte de la compatibilidad del modelo y deben examinarse cuando importa un límite concreto.

El trabajo SentencePiece, de 2018, es una referencia primaria de tokenización subword independiente del preprocesamiento de palabras tradicional. Ilustra que diseñar unidades y representaciones es una decisión técnica, sin establecer que todos los LLMs utilicen ese método.

El identificador de un token se convierte en una representación numérica; transformaciones posteriores la relacionan con otras posiciones. Embeddings distingue esas representaciones de vectores externos para tareas como similitud. Un vector interno no es automáticamente un documento recuperado, una memoria durable o una explicación legible de lo que el modelo conoce.

Las aplicaciones pueden agregar marcas de roles, delimitadores o representaciones de otras modalidades bajo un contrato específico. Esas estructuras afectan cómo se presenta la entrada. Que un fragmento parezca una instrucción para una persona no significa que tenga autoridad de plataforma: la autoridad pertenece al sistema y a sus políticas, no a cualquier secuencia textual que el modelo recibe.

Pretraining y aprendizaje de regularidades

El pretraining ajusta parámetros sobre datos y objetivos amplios para aprender regularidades reutilizables. En un modelo autoregresivo puede utilizar continuaciones como señal de aprendizaje; otros objetivos ocultan o relacionan partes de una entrada. La información de entrenamiento condiciona qué asociaciones y capacidades pueden desarrollarse, sin convertirse en una base de datos que permita consultar con exactitud cada fuente.

La pérdida de entrenamiento evalúa una formulación concreta. Mejorarla no prueba por sí sola verdad factual, seguimiento fiable de instrucciones o utilidad en un dominio. Un sistema puede aprender a producir secuencias plausibles y conservar asociaciones equivocadas, información desactualizada o patrones que no corresponden a las condiciones actuales.

Generalizar tampoco significa conocer cualquier dato nuevo. Una actualización del repositorio que el modelo no observó no aparece automáticamente en sus parámetros. El sistema puede aportar esa información mediante contexto o herramientas; eso es diferente de afirmar que el modelo fue reentrenado con ella. La fecha o versión de una fuente importa aunque la respuesta suene familiar.

La escala puede ampliar capacidad, datos y recursos utilizados, pero no define una garantía universal de calidad. El tamaño de un modelo aislado no permite deducir cuánto contexto utiliza, qué acciones puede ejecutar ni si una respuesta cumple el contrato del producto. Esas preguntas requieren conocer el sistema y evidencia pertinente.

Post-training y comportamiento de instrucciones

Después del pretraining pueden aplicarse ajustes para tareas, instrucciones o preferencias. Fine-tuning, ajuste supervisado y métodos de optimización de preferencias son categorías posibles con procedimientos diferentes. No todos los LLMs pasan por la misma secuencia ni una etiqueta como aligned implica una garantía general de obediencia, seguridad o corrección.

Una instancia orientada a instrucciones puede responder a pedidos de forma distinta de un modelo base, sin convertirse por ello en una aplicación completa. El formato de conversación, los mensajes que aporta el sistema y las herramientas disponibles todavía pertenecen a una composición externa. La experiencia final no se explica solamente mediante un nombre de etapa de entrenamiento.

El trabajo Direct Preference Optimization, de 2023, ejemplifica investigación sobre adaptación de modelos mediante preferencias. Se cita para mostrar que existen métodos distintos de post-training, no para imponer uno ni describir una receta de implementación.

Aprender a responder a instrucciones tampoco equivale a que cualquier instrucción esté autorizada. Un texto obtenido desde un archivo externo puede contener imperativos; el sistema necesita distinguir su procedencia y papel. Persistent Instructions trata guía y autoridad en desarrollo, sin reducirlas a una propiedad garantizada de los pesos del modelo.

Inferencia, distribución y decoding

Durante inferencia, el modelo calcula resultados a partir de entrada, parámetros y configuración. En generación autoregresiva produce puntuaciones que se utilizan para seleccionar el siguiente token; ese token se incorpora al contexto de los siguientes pasos. La salida completa depende de esa trayectoria y de las condiciones del sistema.

El decoding define cómo se eligen candidatos a partir de esas puntuaciones. Una selección greedy toma una opción de máxima puntuación bajo las reglas aplicadas. El muestreo puede seleccionar entre alternativas según una distribución transformada. Temperature puede modificar su concentración; top-k o top-p restringen candidatos mediante criterios distintos. Son orientaciones, no controles necesariamente expuestos o idénticos en todas las APIs.

Elegir un token probable no garantiza una afirmación verdadera. La probabilidad de continuación corresponde al modelo de secuencias y su condicionamiento, no a una certificación directa de veracidad de cada frase. Una respuesta bien formada puede inventar una referencia o combinar hechos incompatibles si el sistema no aporta o verifica evidencia suficiente.

Reducir variación del decoding tampoco garantiza reproducibilidad integral. Pueden cambiar modelo, contexto, herramientas, servicios o implementación numérica. Non-Determinism desarrolla esas fuentes y probabilistic-vs-deterministic-software distingue un mecanismo probabilístico de la variación observable de todo el sistema.

Una llamada de inferencia no implica necesariamente aprendizaje de parámetros. Una aplicación puede adaptar la respuesta mediante instrucciones, historia o información recuperada sin actualizar pesos. Confundir adaptación al contexto con entrenamiento dificulta explicar qué información se conserva y qué se perderá al terminar la interacción.

Context Window: capacidad de la inferencia

Context Window es el límite o capacidad de información tokenizada que un modelo y su runtime pueden hacer disponible en un contexto de inferencia, bajo restricciones de arquitectura e implementación. No es todo el conocimiento del modelo ni toda la información guardada por una aplicación. Se mantiene como subtema de LLM Fundamentals porque describe una frontera fundamental de uso del modelo.

El contexto efectivo puede incluir instrucciones, entrada del usuario, historial seleccionado, datos recuperados y resultados de herramientas. El modo de contabilizar entrada, salida generada o reservas depende del modelo, runtime y API. No se universaliza una ecuación de presupuesto para todos los proveedores ni se congela aquí una cifra de capacidad que cambie con las versiones.

Context es la información efectivamente suministrada o disponible para la inferencia actual. Context Window expresa la capacidad o frontera que condiciona cuánto puede admitirse. Disponer de una ventana grande no demuestra que esté llena ni que contenga la evidencia pertinente. Una aplicación puede enviar poco material o descartar información antes de que el modelo la observe. Context Management conserva la práctica general de seleccionar, refrescar y transferir esa información.

Context Engineering for Software Development organiza selección, estructura, actualización y transferencia de información para trabajar en un repositorio. Una ventana mayor no elimina esa práctica: todavía importa qué se incluye, qué autoridad tiene y si corresponde a la revisión actual. Cargar todo lo accesible puede agregar ruido sin resolver una pregunta concreta.

El sistema también puede resumir, truncar o seleccionar historia para continuar. Esas operaciones cambian el contexto disponible; no amplían mágicamente la capacidad ni garantizan preservar todas las restricciones. Una nota resumida que diga «terminado» no sustituye la evidencia omitida. El límite del modelo y la estrategia de continuidad son responsabilidades diferentes.

Context Window, memoria y límites de contexto largo

Agent Memory conserva información recuperable para uso futuro. Parte puede cargarse en contexto cuando resulta pertinente, pero lo almacenado no está automáticamente presente en cada inferencia. Una ventana amplia no implementa por sí sola retención, selección o actualización de memoria. Una memoria extensa tampoco garantiza que se recupere el fragmento adecuado.

Los parámetros aprendidos son otra forma de estado del modelo, distinta del contexto de una solicitud y de una memoria externa de la aplicación. No conviene llamar a las tres cosas la misma memoria sin precisar el nivel. Una conversación nueva puede mantener el mismo modelo y perder historia; un sistema puede recuperar una nota durable sin volver a entrenarlo.

Más contexto no implica automáticamente mejores respuestas. Material irrelevante, contradictorio o desactualizado puede dificultar utilizar lo pertinente. La capacidad admitida y la calidad de uso de esa información son preguntas distintas. El comportamiento depende de modelo y tarea, no de una regla universal de que toda entrada más larga sea superior o inferior.

La longitud también influye en recursos de cálculo y operación según la implementación. Puede afectar latencia y costo sin justificar aquí cifras ni modelos de AI Economics. La decisión de incluir información debería considerar su aporte a la tarea y las restricciones reales, en vez de consumir toda la ventana por estar disponible.

Un ejemplo de desarrollo es recibir muchos archivos del repositorio y omitir el contrato pequeño que define el comportamiento esperado. Ampliar la capacidad no corrige por sí solo esa selección. A la inversa, una tarea que sí necesita múltiples dependencias puede beneficiarse de disponer de espacio suficiente. Lo importante es la relación entre evidencia y decisión, no maximizar o minimizar contexto indiscriminadamente.

Foundation Model y Generative AI

Foundation Model es un concepto más amplio que LLM: enfatiza modelos entrenados sobre datos amplios que pueden adaptarse a diversos usos. El informe de Stanford On the Opportunities and Risks of Foundation Models, de 2021, ofrece ese encuadre. No impone que todos los foundation models sean únicamente de lenguaje o compartan la misma arquitectura.

Un LLM puede participar de ese encuadre y un sistema multimodal puede extenderse más allá del texto. No hace falta resolver toda taxonomía de investigación para mantener la frontera útil: LLM identifica el foco de modelado de lenguaje; foundation model describe una categoría de adaptación más amplia.

Generative AI incluye generación en otras modalidades y familias de modelos. LLM es una parte importante de ese campo, no un sinónimo. Tampoco toda utilización de un modelo de lenguaje consiste en mostrar texto generado al usuario: puede aportar representaciones o clasificaciones a otro componente.

Un proveedor es una organización o servicio que distribuye modelos o capacidades. Su API, UI o política comercial no forma parte de la definición durable de LLM. Dos proveedores pueden ofrecer sistemas con responsabilidades diferentes alrededor del mismo tipo de modelo; el nombre comercial no establece una categoría conceptual nueva.

Modelo, assistant y agent

Un assistant es una aplicación o sistema de interacción que puede utilizar uno o varios modelos y agregar instrucciones, herramientas, memoria, retrieval, UI y estado. Coding Assistants especializa esa interacción al desarrollo. La interfaz conversacional no es la definición del LLM y el comportamiento final puede incluir piezas externas al cálculo del modelo.

Agents conserva el sistema que selecciona acciones, incorpora observaciones y organiza continuación o detención hacia un objetivo. Un LLM no se convierte en agente por producir una lista de pasos o una solicitud textual de herramienta. El runtime debe interpretar y ejecutar capacidades bajo un contrato, con estado y límites pertinentes.

Agent Harness sitúa esa maquinaria alrededor del modelo. Disponer de un LLM no implica acceso a filesystem, red, permisos o procesos. Una respuesta que diga «ejecuté el test» no demuestra que haya existido una herramienta ni una ejecución. La distinción permite investigar qué parte del sistema realmente pudo observar o actuar.

Un producto puede combinar múltiples modelos y mecanismos programados. Un fallo puede provenir del modelo, del contexto suministrado, de una integración o de una política de aceptación incorrecta. Reducir todo al nombre del LLM impide reconocer esas dependencias y atribuir responsablemente lo ocurrido.

Evidencia y alcance práctico

Supongamos que se solicita corregir una validación de pedidos en un repositorio. El modelo puede conocer patrones habituales del lenguaje, pero la regla comercial y la implementación actual necesitan evidencia de esa revisión. Una herramienta puede leer el contrato y aportar un fragmento al contexto. Eso no modifica por sí solo los parámetros del LLM ni garantiza que cada inferencia posterior conserve el fragmento.

Si la sesión se resume y omite una excepción, una respuesta posterior puede ser coherente con el resumen e incorrecta respecto de la tarea. Si se recupera una nota durable, todavía interesa si corresponde a la versión actual. La diferencia permite localizar qué falló: selección o continuidad de información, interpretación del modelo o ejecución del sistema, sin explicar todo como una ventana demasiado pequeña.

Tampoco una respuesta que describe un comando equivale a su ejecución. El harness debe realizar la invocación y relacionar el resultado con la acción adecuada. La aceptación necesita evidencia del cambio y de sus comprobaciones. Un modelo puede contribuir a esa entrega sin adquirir acceso o autoridad para publicar. La escala del modelo, su forma conversacional y el tamaño de contexto no resuelven ninguna de esas fronteras por sí solos.

Al utilizar un LLM para proponer código, interesa contrastar el artefacto real, los requisitos y las comprobaciones ejecutadas. Generated Code Verification desarrolla esa evidencia; una trayectoria generativa idéntica no es su sustituto. Dos implementaciones diferentes pueden satisfacer el mismo contrato y una respuesta repetida puede conservar el mismo error.

La información recuperada puede ayudar a situar una respuesta, pero Information Retrieval no garantiza por sí solo que el modelo la utilice correctamente. Retención, recuperación, generación y verificación son responsabilidades componibles. Los patrones de aplicación detallados permanecen fuera de este fundamento.

Fuentes y alcance

Fuentes consultadas el 2026-10-30: Jurafsky y Martin, Speech and Language Processing, manuscrito de 2026; SentencePiece, 2018; Direct Preference Optimization, 2023; On the Opportunities and Risks of Foundation Models, 2021. Se usan como referencias conceptuales y ejemplos académicos atribuidos. No se fijan tamaños de contexto, precios, rankings, proveedores recomendados ni garantías de APIs actuales. Context Window permanece aquí; no se crea un documento separado ni se materializan RAG, Guardrails o MLOps.