Qué es realmente un LLM — y cómo medirlo con Artificial Analysis
Hay mucho vocabulario cognitivo alrededor de estos sistemas. Inteligencia, razonamiento, comprensión. Y sí, los resultados son impresionantes. Pero el vocabulario no es neutral: instala expectativas sobre cómo funciona el sistema, cómo falla y qué garantías ofrece. Después llevás esas expectativas a producción y ahí aparecen los problemas.
Acá dejo cómo entiendo el mecanismo: los conceptos básicos (LLM, MCP, AGI), qué ocurre realmente dentro de un transformer, y qué uso para medir en lugar de discutir. Para lo último recurro a Artificial Analysis, que es la fuente que consulto con más frecuencia.

Tres términos que no están al mismo nivel
LLM, MCP y AGI aparecen en el mismo párrafo todo el tiempo, y no son la misma clase de cosa. Uno es un tipo de modelo, otro es un protocolo, el tercero es una hipótesis sin definición operativa.
LLM (Large Language Model). Un modelo preentrenado sobre grandes volúmenes de texto con un objetivo de predicción del siguiente token. Ese preentrenamiento, sin embargo, es sólo una parte del proceso: los modelos actuales pasan además por ajuste supervisado, optimización por preferencias y reinforcement learning. No hay adentro una base de datos de hechos consultable ni, en la arquitectura básica, un motor de inferencia simbólica. El conocimiento queda distribuido en los parámetros.
MCP (Model Context Protocol). Un estándar abierto para conectar modelos con herramientas y fuentes de datos. Un servidor MCP expone tools, resources y prompts con una interfaz uniforme, y cualquier cliente compatible los consume sin integración específica. Reemplaza la integración puntual por un conector común. Lo que no es: un requisito para construir un agent. Un sistema agéntico puede funcionar igual con APIs directas, function calling propietario o browser automation. MCP aporta interoperabilidad, no agencia.
AGI (Artificial General Intelligence). Un sistema capaz de resolver tareas intelectuales arbitrarias con transferencia entre dominios. El problema es que no existe una definición operativa consensuada ni un test acordado. Cada organización maneja la suya, y varias están convenientemente atadas a su propio roadmap. Mientras no especifiques los criterios de antemano, el término aporta poco.
El mecanismo: de tokens a una distribución
Antes de los pasos, qué es un transformer. Es la arquitectura de red neuronal sobre la que están construidos todos estos modelos — apareció en 2017, en Attention Is All You Need, y desplazó a las arquitecturas recurrentes que procesaban el texto posición por posición. Su aporte es el mecanismo de attention: cada posición de la secuencia mira a todas las demás y pondera cuáles importan para predecir lo que sigue. Eso lo hizo paralelizable, y por lo tanto entrenable a la escala actual. La T de GPT es por transformer.
La inferencia de un transformer se puede describir en cinco pasos.
- Tokenización — el texto se segmenta en tokens y cada uno se convierte en un índice entero. El modelo nunca ve letras ni palabras: ve índices.
- Embeddings — cada índice se proyecta a un vector de alta dimensionalidad. Esa representación no es estática: en las capas siguientes se transforma de forma contextual. La semántica no reside en la proximidad entre embeddings iniciales, sino distribuida en el espacio de representación.
- Capas de attention — decenas o cientos de capas donde cada posición combina información de las otras, mediante operaciones matriciales sobre queries, keys y values.
- Proyección a vocabulario — la última capa produce un vector de logits, uno por token del vocabulario. Un softmax lo normaliza a distribución de probabilidad.
- Decodificación — se elige el token siguiente con una estrategia de decoding, que puede ser estocástica (sampling con temperature o top-p) o determinista. Se agrega al contexto y el proceso se repite íntegramente para la posición siguiente.
El entrenamiento fue ajustar parámetros por descenso de gradiente para minimizar el error de predicción sobre un corpus. En el modelo base no hay ningún paso que verifique un hecho contra una fuente. Que una respuesta salga correcta es consecuencia de que la continuación correcta tenga alta probabilidad. Y acá está la distinción que más se pasa por alto: el sistema que construís alrededor sí puede verificar — búsqueda, ejecución de código, consulta a una base. Eso es una propiedad del sistema, no del modelo.
Qué cambia en los modelos frontier
Esos cinco pasos son el esquema base. Los modelos frontier operan sobre los mismos principios pero con arquitecturas considerablemente más avanzadas que el transformer de 2017: las capas feed-forward densas suelen ser Mixture of Experts, donde un router activa sólo un subconjunto de parámetros por token; la multi-head attention clásica dio paso a variantes como Grouped-Query Attention o Multi-head Latent Attention, para reducir el costo en secuencias largas y el tamaño del KV cache; y algunos modelos intercalan bloques de state-space models con unas pocas capas de attention completa.
Lo que no programó nadie
El resultado que importa es que un procedimiento así produzca texto coherente a nivel de discurso. Sintaxis válida. Argumentación que se sostiene varios párrafos. Código que compila y hace lo que dice.
Nadie codificó reglas gramaticales ni restricciones de coherencia discursiva. Eso emergió como subproducto de optimizar una predicción estadística a gran escala. Y admite dos lecturas: una sobre la capacidad de un aproximador estadístico de gran tamaño, y otra sobre cuánta regularidad estructural tenía el lenguaje natural, que resultó ser más de la que suponíamos.
Por qué el vocabulario importa en producción
El problema no es usar términos funcionales para describir comportamiento. El problema es dar por sentadas propiedades que la fluidez no garantiza: comprensión en sentido humano, veracidad, trazabilidad causal, o que un historial de aciertos implique conocimiento confiable del dominio. Nada de eso se sigue del mecanismo.
A mí me resulta más útil pensarlos como sistemas probabilísticos de alta complejidad. Esa caracterización explica los comportamientos que condicionan cualquier diseño en producción:
- Las hallucinations son un modo de fallo inherente, no un bug — la distribución optimiza plausibilidad de la continuación, no veracidad. Por eso el resultado puede ser convincente y factualmente incorrecto incluso cuando la información relevante está en el contexto.
- La confianza expresada no es por sí sola una medida fiable de exactitud — el tono asertivo es un patrón estilístico aprendido del corpus. Los modelos pueden estar mal calibrados, aunque la calibración se puede medir y mejorar.
- La variabilidad depende del decoding — con decoding estocástico, la misma entrada puede producir salidas distintas. En sistemas reales también varía según el estado de las herramientas o del entorno.
- El rendimiento se degrada fuera de distribución — algunos tipos de distribution shift producen comportamientos especialmente frágiles, aunque el deterioro no siempre es abrupto. Es la zona donde más conviene tener guardrails.
El reasoning no es un módulo nuevo
Los modelos de reasoning rinden sustancialmente mejor en tareas difíciles, y de ahí se salta a suponer que incorporan un proceso inferencial de otra naturaleza. Conviene separar tres niveles: la generación del modelo, su entrenamiento, y el sistema completo que lo rodea.
Estos modelos están optimizados para dedicar más cómputo antes de responder, en varios casos mediante reinforcement learning sobre cadenas de razonamiento. La secuencia intermedia se genera con el mismo procedimiento autoregresivo descrito arriba: en el modelo no aparece un módulo lógico ni un verificador simbólico. El sistema completo sí puede incorporar herramientas, búsqueda o verificadores. Lo que se observa es que generar ese texto intermedio condiciona al modelo sobre su propia salida y desplaza la distribución final hacia regiones donde las respuestas correctas son más probables. En términos prácticos: más cómputo en inferencia.
Y acá viene la parte incómoda para cualquiera que necesite trazabilidad. Hay evidencia de que la cadena intermedia no siempre refleja el proceso que determinó la respuesta — el modelo puede producir una justificación plausible que no corresponde a los factores que realmente influyeron. La cadena es texto generado. No conviene tomarla automáticamente como registro causal fiel ni como traza completa de ejecución.
Artificial Analysis: medir en lugar de discutir
Si el comportamiento de estos sistemas es estadístico, elegir modelo o provider es una decisión que requiere datos. Artificial Analysis es un sitio independiente que corre sus propias evaluaciones sobre modelos, providers y agents y publica los resultados en formato comparable. Estas son las secciones que más uso.
Intelligence Index
Índice compuesto, en lugar de un benchmark único. La v4.3 agrega diez evaluaciones: AA-Briefcase, GDPval-AA v2, AutomationBench-AA, Terminal-Bench v4.0, SciCode, Humanity’s Last Exam, GDP.pdf, CritPt, AA-Omniscience y AA-LCR. La ventaja del compuesto es que reduce el riesgo de sobreajuste: optimizar para diez evaluaciones heterogéneas es bastante más difícil que para una.
Cost per Task y Time per Task
Esta es la vista que más me cambió la forma de comparar. En lugar de precio por millón de tokens, calculan cuánto cuesta y cuánto tarda resolver una tarea completa del índice, con el consumo de tokens incluido — los reasoning tokens también, cuando el modelo los expone. La diferencia es material: un modelo con precio por token bajo puede tener un costo por tarea alto si consume muchos reasoning tokens. El scatter de Intelligence Index contra Cost per Task, con su frontera de Pareto, permite identificar las opciones no dominadas para el nivel de calidad que necesitás.
Benchmarks agénticos
Además del índice, publican evaluaciones especializadas de trabajo agéntico. No conviene confundirlas con los diez componentes de la v4.3 — algunas están dentro del índice y otras se publican por separado. Es la categoría que más creció y la más pertinente si tu sistema ejecuta tareas en lugar de contestar preguntas:
- AA-Briefcase — knowledge work de horizonte largo: generar spreadsheets, presentaciones y memos dentro de workflows de negocio.
- GDPval-AA — tareas de valor económico real en distintas ocupaciones, con Elo anclado a un baseline humano de 1.000. Medir la distancia respecto de una persona es una referencia exigente.
- AutomationBench-AA y EnterpriseOps-Gym-AA — workflows sobre aplicaciones SaaS y operaciones de negocio.
- Terminal-Bench — uso agéntico de terminal y coding end-to-end.
- APEX-Agents-AA — horizonte largo, donde la acumulación de errores entre pasos es el factor de fallo principal.
- ITBench-AA — root-cause analysis de incidentes en Kubernetes. Especialmente pertinente si trabajás en IT ops.
- AA-AnalystAgent — análisis cuantitativo sobre spreadsheets y documentos, reportado como pass^5: la proporción de tareas resueltas correctamente en las cinco ejecuciones. Es reproducibilidad, no capacidad máxima. Sirve para evaluar la robustez de una automatización, aunque por sí sola no determina si podés quitar la supervisión humana.
Coding Agent Index
Va separado del ranking de modelos, y con razón: un agent es modelo + scaffold + herramientas, y el scaffold pesa. La v1.5 combina DeepSWE, Terminal-Bench y SWE-Atlas-QnA, y reporta además costo por tarea y tiempo de ejecución. Hay también una tabla comparativa de agents de general work — Claude Cowork, ChatGPT Work, Microsoft Copilot Cowork, Manus, OpenClaw, Hermes Agent, Gemini Enterprise, entre otros — con plataforma, si es open source, si soporta bring-your-own-model, acceso a archivos locales, browser automation y precio.
