Introducción

Detente un momento y respóndete esto, con honestidad:

¿Qué sabes realmente sobre inteligencia artificial, más allá de saber usar Claude, ChatGPT, o Gemini? ¿Qué entiendes por LLM, en términos concretos y verificables? ¿Sabes por qué un token —no una palabra, no una letra— es la unidad real de intercambio con la que trabaja un modelo, y por qué eso determina cuánto te cuesta cada consulta, cuánto puede “recordar” en una conversación, y por qué a veces falla en tareas que parecen triviales? ¿Podrías explicar, con precisión, qué ocurre mecánicamente entre el momento en que escribes tu pregunta y el momento en que aparece la respuesta?

Si alguna de esas preguntas te generó duda, quédate — este compendio existe exactamente para cerrar esa distancia.

Qué es, en realidad, un LLM

Empecemos por desarmar el término que usamos como si fuera obvio. Un LLM (large language model, modelo de lenguaje grande) es, en su definición más precisa, una red neuronal entrenada para predecir texto — nada más y nada menos que eso en su núcleo, aunque de ese mecanismo simple emerja un comportamiento que se siente como comprensión.

El tamaño de un LLM se mide por su número de parámetros: los valores numéricos que la red ajusta durante el entrenamiento, y que terminan almacenando, de forma distribuida y estadística, todo lo que el modelo “sabe”. No son reglas escritas a mano ni una base de datos de hechos — son millones o miles de millones de números, cada uno ajustado gradualmente para que el modelo prediga mejor el siguiente fragmento de texto dado lo que vino antes. GPT-3, por ejemplo, tiene 175 mil millones de parámetros — 175,000,000,000 valores numéricos individuales, cada uno contribuyendo una fracción minúscula a cada predicción que el modelo hace. Vamos a desarmar exactamente cómo se organizan y qué hace cada uno de esos números en el Capítulo de Anatomía de un Transformer — aquí basta con que quede claro que “más parámetros” no es una cifra de marketing, es literalmente más capacidad de almacenar patrones estadísticos del lenguaje.

El LLM no es el producto que usas

Aquí hay una distinción que casi nadie hace, y que vale la pena grabarse desde el inicio: cuando hablas con ChatGPT, Claude, o Gemini, no estás hablando directamente con un LLM desnudo. Esas herramientas son productos de asistencia — toman un LLM como motor central, y lo envuelven con capas adicionales: interfaces de usuario pensadas para que cualquiera pueda escribir y recibir respuestas sin fricción, sistemas de seguridad y moderación que filtran o bloquean ciertos comportamientos, y herramientas externas que el modelo puede invocar —acceso a un navegador, a bases de datos, a ejecución de código— que el LLM por sí solo, como red neuronal aislada, jamás podría hacer.

Esta distinción importa porque a lo largo de este compendio vamos a hablar de ambas cosas, y confundirlas lleva a conclusiones equivocadas: cuando discutimos los límites de un modelo base (Parte II), hablamos del LLM desnudo, sin ninguna de esas capas de producto — y entender esa versión “cruda” es precisamente lo que te permite entender qué está resolviendo cada capa que se le agrega encima.

Por qué existe este compendio

Nada de lo que vas a leer aquí es información inédita. Los conceptos que cubrimos —cómo funciona la atención, por qué existen los tokens, cuándo usar RAG en vez de fine-tuning, cómo se diseña un sistema de agentes en producción— viven dispersos en papers académicos, documentación oficial de laboratorios y proveedores de infraestructura, libros técnicos, videos, y artículos de blog — cada fuente cubriendo una pieza del rompecabezas, casi nunca el panorama completo, y casi nunca en español con el nivel de profundidad que un arquitecto o practicante realmente necesita.

Mi objetivo con este compendio es reunir esos fundamentos dispersos en un solo lugar, tratados con el rigor que merecen — pensado para quien diseña arquitecturas de IA y necesita justificar decisiones de infraestructura con criterio real, para el practicante y desarrollador que construye con estas herramientas todos los días y quiere dejar de operar por ensayo y error, y para cualquiera con la curiosidad genuina de ver bajo el capó — de dejar de tratar al modelo como una caja negra mágica, y empezar a entender el mecanismo real que hay dentro.

El camino: cuatro partes

Este compendio se organiza en cuatro partes, cada una construyendo sobre la anterior — no son piezas independientes que puedas leer en cualquier orden sin perder contexto, aunque cada capítulo intenta señalar explícitamente de qué otros capítulos depende.

Parte I — Fundamentos

Aquí desarmamos el mecanismo básico de un modelo de lenguaje, desde cero: qué es exactamente un token y por qué es la “moneda” con la que opera el modelo, cómo un texto se convierte en números que una red neuronal puede procesar (tokenización, embeddings), la arquitectura completa de un transformer —el diseño que hace posible a GPT, Claude, y prácticamente todo LLM moderno—, cómo se entrena un modelo desde los datos hasta un checkpoint funcional, y cómo ese modelo pasa de ser un simple predictor de texto a comportarse como un asistente que sigue instrucciones. Si nunca entendiste con precisión qué pasa “dentro” de un LLM, esta parte es la base de todo lo demás.

Parte II — Ingeniería

Con los fundamentos claros, pasamos a cómo se usa un LLM con criterio profesional en un proyecto real: los límites reales de un modelo base, técnicas de prompting que van más allá de “escribir bien”, cómo evaluar sistemáticamente si un cambio realmente mejoró algo (en vez de confiar en intuición), cuándo el fine-tuning vale la pena y cuándo es la decisión equivocada, cómo darle a un modelo acceso a conocimiento externo (RAG) y a capacidad de actuar sobre sistemas reales (MCP), y cómo diseñar arquitecturas de agentes con patrones probados en vez de improvisar.

Parte III — Infraestructura

Aquí la pregunta cambia de “¿cómo lo uso bien?” a “¿cómo lo sirvo en producción, a qué costo, y con qué garantías?” — cuánta velocidad de generación realmente necesitas según tu caso de uso, las técnicas que existen para optimizar inferencia y bajar costos, cómo se relacionan latencia, throughput, y los límites de tasa que imponen los proveedores, el trilema real entre latencia/throughput/costo que ningún arquitecto puede evadir, cómo observar y evaluar sistemas de IA ya en producción, y los riesgos de seguridad específicos de sistemas agénticos —con un caso real de cómo un sistema así puede fallar catastróficamente si se diseña sin criterio.

Parte IV — Casos aplicados

Todo lo anterior, aterrizado en un caso completo y evolutivo: una arquitectura que empieza sirviendo a 10 usuarios de negocio y escala hasta 1,500 vendedores, mostrando con números y decisiones concretas cómo cambian las prioridades de diseño cuando el volumen crece varios órdenes de magnitud.