¿Qué es un LLM? Fundamentos para agentes de IA

¿Qué significa «LLM como motor de razonamiento»?

Un agente de IA es más que un chatbot: persigue un objetivo a lo largo de varios pasos, llama a herramientas, observa los resultados y decide qué hacer a continuación. En el centro de este bucle está un gran modelo de lenguaje (LLM) que actúa como motor de razonamiento, es decir, la instancia que planifica, sopesa, selecciona herramientas e interpreta resultados.

Una metáfora que ha marcado la práctica procede de Andrej Karpathy (junio de 2025): el LLM es la CPU, la ventana de contexto es la memoria de trabajo (RAM) y el ingeniero asume el papel del sistema operativo, que en cada paso llena esa memoria con la información adecuada. De ahí se desprende la idea central para 2026: en producción, los agentes casi nunca fallan porque el modelo sea «demasiado pequeño». Fallan porque el contexto está mal construido. El equipo Applied AI de Anthropic describe el Context Engineering como la evolución natural del prompt engineering: la selección de los tokens que acaban en la ventana de contexto limitada. De esa selección depende que un agente funcione de forma fiable.

Si construyes agentes, necesitas por tanto una base sólida en cuatro componentes: tokens, ventana de contexto, Function Calling y elección del modelo (open source frente a propietario). Esta página de resumen reúne los fundamentos; los temas de profundización (Context Engineering, RAG, FinOps, cumplimiento normativo) tienen cada uno su propio módulo.

Tokens: la unidad de procesamiento y de coste

Los LLM no procesan el texto como palabras, sino como tokens, es decir, unidades de subpalabra que un tokenizador genera a partir del texto. Los tokens son a la vez la unidad de facturación: los proveedores cobran por separado los tokens de entrada y los de salida, normalmente por millón de tokens.

En la región DACH (Alemania, Austria y Suiza), la tokenización no es un tema menor, sino un factor de coste medible. Con los tokenizadores BPE habituales, el alemán genera un 30-50 % más de tokens que el inglés para un contenido equivalente. Las causas:

• Sustantivos compuestos: «Lebensversicherungsgesellschaftsangestellter» se descompone en una larga cadena de subpalabras, mientras que «life insurance company employee» se divide en tokens de palabras conocidas.
• Flexión: las desinencias de caso y las terminaciones verbales del alemán generan variantes morfológicas que se registran como subpalabras independientes.
• Sesgo del tokenizador: los datos de entrenamiento de los tokenizadores habituales están dominados por el inglés; las subpalabras alemanas poco frecuentes se fragmentan más.

De ello se derivan tres consecuencias prácticas. Primero, las ventanas de contexto efectivas admiten menos contenido (en una ventana de 200K solo cabe tanto contenido en alemán como el que en inglés ocuparía unos 130K-150K tokens). Segundo, los costes por llamada son, en consecuencia, un 30-50 % más altos. Tercero, el prompt caching compensa todavía más en cargas de trabajo DACH que en las inglesas, porque el descuento se aplica a un número mayor de tokens.

Una advertencia importante sobre la migración de modelos: Claude Opus 4.7 se lanzó con un nuevo tokenizador que, para muchas entradas, genera hasta un 35 % más de tokens que Opus 4.6; con precios por token idénticos, el coste efectivo por petición puede subir solo por el cambio de tokenizador. Antes de cualquier migración, haz un benchmark con tu propio perfil de carga de trabajo.

La ventana de contexto: nominal frente a efectiva

La ventana de contexto es el número máximo de tokens que un modelo puede «ver» por petición, es decir, el prompt del sistema, las definiciones de herramientas, los contenidos recuperados, el historial de la conversación y el espacio para la respuesta, todo junto. En 2026, las ventanas nominalmente grandes son estándar: Claude Opus 4.7 y Sonnet 4.6 admiten 1M de tokens, y Gemini 3.1 Pro también ronda el 1M.

Lo decisivo, sin embargo, es esto: la capacidad nominal no equivale a la efectiva. El estudio «Context Rot» de Chroma (julio de 2025, 18 modelos frontier) demostró empíricamente que todos los modelos se degradan a medida que aumenta la longitud del input. Tres mecanismos se refuerzan entre sí:

1. Lost-in-the-Middle: los modelos prestan más atención al principio y al final del contexto, y menos a la parte central.
2. Dilución de la atención: la complejidad cuadrática de la atención implica que con 100K tokens ya existen unos 10 mil millones de relaciones entre pares.
3. Interferencia de distractores: los contenidos semánticamente similares pero irrelevantes inducen activamente a respuestas erróneas.

El resultado depende de la tarea: en la recuperación simple de datos factuales, los modelos más recientes han mejorado notablemente, pero en el razonamiento multi-hop el efecto sigue siendo estructural. Como heurística para producción, la capacidad de trabajo efectiva se sitúa en el 30-50 % de la nominal en tareas centradas en el razonamiento y en el 60-80 % en tareas centradas en la recuperación. Llenar por completo una ventana de 1M es derrochar recursos y, encima, perder calidad.

La respuesta práctica al context rot no es «meter más», sino seleccionar: almacenar en caché los componentes estables, cargar los contenidos dinámicos de forma selectiva, podar los contenidos antiguos y comprimir al llegar a un 70-85 % de ocupación (compaction). De eso trata el módulo Context Engineering.

Function Calling y uso de herramientas: el LLM como actor

Para que un LLM se convierta en el motor de un agente, tiene que poder actuar, es decir, generar llamadas estructuradas a funciones externas. El Function Calling (también llamado tool use) es el mecanismo para ello: el modelo recibe definiciones de herramientas en formato JSON Schema y, cuando hace falta, devuelve una llamada estructurada con parámetros que la aplicación ejecuta.

El hallazgo práctico más importante de 2026: cuando un agente actúa mal, la causa no suele estar en el modelo, sino en la definición de la herramienta. Anthropic formula la pauta sin rodeos: si un ingeniero humano no puede decir con claridad qué herramienta usar en una situación, un agente tampoco puede. Consecuencias concretas:

• Número de herramientas: lo óptimo son 3-7 herramientas cargadas activamente; a partir de unas 10 herramientas empieza una degradación medible. En las evaluaciones MCP internas de Anthropic, la precisión en la selección de herramientas con búsqueda dinámica de herramientas subió del 49 % al 74 % (Opus 4) y del 79,5 % al 88,1 % (Opus 4.5).
• El solapamiento de herramientas es fatal: dos herramientas que podrían responder de forma plausible a la misma petición son el único problema que ningún prompt, por bueno que sea, resuelve. Una cláusula clara de «cuándo no usarla» en la descripción es el componente más eficaz y el que más a menudo se olvida.
• Outputs estructurados: para los sistemas posteriores, los outputs deben ser legibles por máquina de forma fiable. OpenAI Structured Outputs (disponible de forma general desde agosto de 2024) alcanza un 100 % de conformidad con el esquema mediante constrained decoding; Anthropic logra algo equivalente con tool use y JSON Schema; los modelos open-weight, mediante grammar-constrained decoding (Outlines, jsonformer, vLLM).

En 2026, el estándar para conectar herramientas es el Model Context Protocol (MCP), publicado por Anthropic en noviembre de 2024 como estándar basado en JSON-RPC. Según informes del sector, las descargas del SDK pasaron de ~100.000 al mes (nov. 2024) a ~97 millones al mes (marzo de 2026), con la adopción por parte de OpenAI, Google y Microsoft. (Estas cifras de descargas proceden de informes de proveedores y del sector y no se han validado de forma independiente; el patrón de adopción en sí se considera indiscutible.) Para evaluar la calidad del tool calling, el Berkeley Function-Calling Leaderboard (BFCL) sigue siendo el benchmark más relevante, con la salvedad de que ningún modelo lidera en todas las categorías y de que los modelos closed-weight siguen yendo por delante en el tool use complejo de varios turnos.

Open source frente a propietario: la elección del modelo

La elección del modelo base es la decisión estratégica de mayores consecuencias. En 2026 ya no es una cuestión binaria, sino una asignación de cartera. Primero, una aclaración de conceptos, porque «abierto» tiene varias dimensiones:

• Cerrado/propietario: solo vía API, pesos no disponibles (Claude, GPT-5.5, Gemini).
• Open-weight: pesos descargables, a veces con licencias restrictivas. Llama es open-weight, pero la OSI y la FSF dejan claro expresamente que no es open source, entre otras razones por un umbral de 700 millones de MAU y una restricción multimodal para la UE en Llama 4.
• Open Source AI según la definición de la OSI (OSAID 1.0, oct. 2024): exige además código abierto de entrenamiento e inferencia y una transparencia suficiente sobre los datos de entrenamiento. La mayoría de los modelos comercializados como «open source» no alcanzan ese umbral.

La tendencia central: la brecha de capacidades entre los mejores modelos open-weight (DeepSeek V4 Pro, Kimi K2.6, Mistral Large 3, Qwen 3.6, Llama 4 Maverick) y los modelos frontier cerrados (a mayo de 2026: Claude Opus 4.7, GPT-5.5 Pro, Gemini 3.1 Pro) se ha reducido de 12-18 meses (2024) a 3-6 meses (2026). En algunas cargas de trabajo estándar, como la programación rutinaria o las tareas matemáticas por debajo del nivel frontier, es prácticamente nula. Así, Kimi K2.6 (1 billón de parámetros, open-weight) ocupa el puesto 4 en el Artificial Analysis Intelligence Index (puntuación 54), justo detrás de Anthropic, Google y OpenAI (57 cada uno).

Al mismo tiempo, en las cargas de trabajo premium (programación agéntica al más alto nivel, matemáticas frontier, contexto largo, multimodalidad premium) los modelos frontier cerrados siguen siendo realmente superiores. En muchas empresas, solo una pequeña parte del volumen de tokens entra en esa categoría premium, pero sí una gran parte del valor estratégico. Por eso, el enfoque híbrido se vuelve económicamente imprescindible.

Precios según las tarifas públicas de los proveedores a abril-mayo de 2026; verifícalos antes de cualquier compromiso plurianual.

Una lógica de decisión sobria se apoya en cuatro dimensiones: control de los pesos (¿quién puede suministrar el modelo, cuándo y en qué condiciones?), soberanía del alojamiento (¿a qué jurisdicción está sujeto el stack?), vía de personalización (listo para usar, prompt, RAG, LoRA, fine-tuning completo) y perfil de costes (pago por token frente a amortización del autoalojamiento). Para la mayoría de las cargas de trabajo estándar (clasificación, extracción, asistentes de conocimiento basados en RAG, flujos de trabajo en alemán), la prima de los modelos frontier cerrados ya no es económicamente imprescindible.

Contexto DACH: soberanía y cumplimiento normativo

En la región DACH, hay además tres factores que condicionan la elección del modelo. El primero es el sentimiento de soberanía: según Bitkom (estudio Digitale Souveränität 2025, 603 empresas), el 89 % de las empresas que importan tecnología digital se consideran dependientes; en la encuesta a la población (semanas 8-11 de 2026), el 72 % opina que Alemania depende demasiado de EE. UU. en materia de IA y al 67 % le gustaría usar una IA alemana. Mistral ofrece una opción soberana europea comercialmente creíble. Una segunda podría surgir de Cohere y Aleph Alpha: ambas empresas cerraron por contrato en septiembre de 2026 la fusión anunciada en abril de 2026. Según la prensa, en el momento del anuncio la valoración rondaba los 20 mil millones de dólares. Está previsto que el Grupo Schwarz aporte la capacidad de cómputo a través de STACKIT. En septiembre de 2026, el cierre de la operación seguía pendiente de las autorizaciones regulatorias. La empresa fusionada operará como Cohere, con doble sede en Toronto y Berlín. Por tanto, es una opción canadiense-alemana y no puramente europea.

En segundo lugar, una región de la UE en un hiperescalador estadounidense (p. ej., Claude en AWS Bedrock Fráncfort) reduce la latencia y la fricción con el RGPD, pero no elimina la jurisdicción estadounidense (CLOUD Act). La soberanía real requiere un stack soberano europeo (STACKIT, OVHcloud, T-Systems, IONOS) o una infraestructura on-premise.

En tercer lugar, hay aspectos regulatorios que conviene tener presentes (a título informativo, no es asesoramiento jurídico): los modelos de API cerrada son modelos de IA de uso general (GPAI) de sus proveedores; el responsable del despliegue en la UE asume las obligaciones que le corresponden como tal. Si haces un fine-tuning sustancial de un modelo open-weight, puedes convertirte tú mismo en proveedor de GPAI; las directrices de la Oficina de IA de la UE (julio de 2025) fijan un umbral orientativo y no vinculante en >1/3 del cómputo de preentrenamiento del modelo base (por defecto, 3,33 × 10²² FLOPs si se desconoce). LoRA/QLoRA suelen quedar muy por debajo; el preentrenamiento continuado, por encima. Las obligaciones de los proveedores de GPAI se aplican desde el 2 de agosto de 2025. Desde el 2 de agosto de 2026, la Comisión Europea (Oficina de IA) también puede hacerlas cumplir mediante multas (art. 101 y art. 113 del Reglamento de IA). A esto se suman las obligaciones del RGPD que afectan al pipeline de entrenamiento cuando se hace fine-tuning con datos personales. Estos puntos se tratan a fondo en los módulos de cumplimiento correspondientes.

Perspectivas y recomendación práctica

Los fundamentos de los LLM no son una lección que se aprende una sola vez, sino un objetivo en movimiento: los tokenizadores cambian, las ventanas de contexto crecen, salen modelos nuevos cada mes y los resultados de los benchmarks varían entre 5 y 10 puntos porcentuales según el test harness. Para 2026/2027 merecen especial atención tres preguntas abiertas: si la brecha de capacidades entre modelos abiertos y cerrados seguirá reduciéndose, si las ventanas de contexto largas cumplirán la promesa de «meterlo todo» (por ahora, no: el Context Engineering sigue siendo necesario) y si la infraestructura soberana europea alcanzará la paridad de escala con los hiperescaladores estadounidenses.

Por eso, en la práctica rige una disciplina sencilla: no elijas a partir del post de marketing, mide con tu propio conjunto de evaluación. Si validas la elección del modelo, el presupuesto de contexto y el diseño de herramientas con trazas reales en lugar de con la intuición, construirás agentes que aguanten en producción y conservarás la flexibilidad estratégica para cambiar de proveedor ante cambios de precio, licencia o capacidades sin empezar de cero.