Límites del modelo base: por qué los LLMs necesitan ingeniería a su alrededor

Cuando usamos un modelo de lenguaje directamente —como cuando abres un chat y le preguntas algo, sin ninguna capa adicional entre tú y el modelo— estamos usando lo que se conoce como un modelo base (o modelo “vainilla”). Es el modelo que sale del preentrenamiento y, quizás, del post-entrenamiento (SFT + DPO) que vimos en Parte I, pero sin ninguna personalización adicional para tu dominio o caso de uso específico.

Estos modelos son increíblemente capaces — mantienen conversaciones fluidas, resumen documentos, escriben código, responden sobre una variedad enorme de temas. Pero usarlos así, directamente, en el mundo real, tiene límites serios que vale la pena entender en profundidad.

La razón por la que este capítulo aparece ahora —antes de hablar de prompting, RAG, agentes, o fine-tuning— es que cada una de esas técnicas existe específicamente para resolver uno de estos límites. Si no entiendes primero qué falla, no vas a entender realmente por qué las soluciones funcionan.

Falta de conocimiento del dominio

El modelo se entrenó con una porción enorme de internet público, libros, artículos, y código. Pero no conoce la información privada de tu empresa, ni el vocabulario hiper-especializado de sectores muy específicos, ni los datos internos que nunca se publicaron en la web.

El problema en detalle: un modelo base sabe de medicina general porque leyó millones de artículos médicos — pero no sabe el protocolo específico de tu hospital para administrar cierto fármaco, porque ese protocolo nunca estuvo en internet. Sabe de agricultura porque leyó libros de agronomía, pero no sabe cómo se ve una enfermedad específica en el cultivo de tu región particular, porque eso no se publica masivamente.

Ejemplo concreto: un equipo diseñando un vehículo agrícola autónomo con cámaras para detectar plantas enfermas tiene miles de imágenes etiquetadas de “mancha foliar por Cercospora en soja de la variedad X”. Esa información no está en ningún corpus público. El modelo base no puede reconocer esa enfermedad porque nunca la vio — no es que “razone mal”; el conocimiento simplemente no existe en sus parámetros, por las razones que ya vimos en el capítulo de datos de entrenamiento de Parte I.

¿Por qué no se soluciona con más preentrenamiento? Porque el preentrenamiento es estático y general — incluir conocimiento de dominio requeriría reunir todos los documentos internos, continuar el preentrenamiento con ellos (costoso), y actualizar el modelo cada vez que la información cambie (constantemente). No es práctico para la mayoría de organizaciones. Por eso la solución típica no es reentrenar, sino inyectar conocimiento en el momento de la consulta — lo que veremos como RAG más adelante en esta parte.

Matiz importante: el modelo base sí puede tener conocimiento general sobre el dominio (sabe qué es la soja, qué es una enfermedad de plantas, qué es Cercospora en términos generales) — lo que no tiene son los detalles específicos de tu caso particular. Esa distinción entre conocimiento general y específico es la clave para entender qué puede y no puede resolver un modelo base por sí solo.

Falta de información actualizada

Los modelos tienen una fecha de corte de conocimiento (knowledge cutoff) — no saben nada de lo que ocurrió después de esa fecha, y cada modelo tiene la suya.

¿Por qué no se actualizan constantemente? Reentrenar un modelo de cientos de miles de millones de parámetros cuesta decenas de millones de dólares y meses de cómputo. Nadie va a hacer eso cada semana solo para incorporar noticias. Existen técnicas de continual learning (entrenamiento continuo), pero siguen siendo costosas y pueden degradar el rendimiento en tareas anteriores — el llamado “olvido catastrófico”.

Ejemplos concretos: pregúntale a un modelo sobre un evento posterior a su fecha de corte, y simplemente no lo sabrá. Un caso histórico curioso: en 2017, un tuit de Donald Trump con la palabra mal escrita “covfefe” volvió locos a varios sistemas automatizados de la época, porque esa secuencia de caracteres no existía en ningún corpus previo. Lo mismo ocurre constantemente con jerga nueva, nombres de productos recientes, o cambios normativos posteriores al corte — el modelo dará información plausible pero obsoleta, sin saberlo.

¿Cómo se resuelve? Consultando fuentes externas en tiempo real — conectando el modelo a una API de búsqueda, una base de datos de noticias, o un sistema interno actualizado. Esto es RAG con fuentes en vivo, o más generalmente, tool use.

Dificultad de control

Es extremadamente difícil predecir o acotar con precisión lo que un LLM va a responder, especialmente bajo provocación deliberada o en contextos ambiguos.

El caso de Tay (2016): Microsoft lanzó un bot de Twitter diseñado para aprender de conversaciones reales en tiempo real, imitando el lenguaje de los usuarios. En menos de 16 horas, usuarios malintencionados la bombardearon con mensajes ofensivos, y Tay comenzó a replicar ese comportamiento — Microsoft tuvo que apagarla. El problema: Tay aprendía de todo lo que le llegaba, sin ningún filtro de seguridad, y los atacantes explotaron exactamente eso. Los modelos modernos tienen guardrails, pero sigue siendo posible inducirlos (jailbreak) a ignorar sus instrucciones de seguridad bajo la presión adecuada.

El problema de la imprevisibilidad, incluso sin ataques: la misma pregunta puede recibir respuestas ligeramente distintas en dos intentos (por temperatura y muestreo, Parte I), y un prompt redactado de forma ligeramente diferente puede cambiar la respuesta drásticamente. Esto es un problema serio en sistemas legales donde cada palabra importa, o médicos donde el tono debe ser preciso.

¿Cómo se aborda? Prompting estructurado (instrucciones claras sobre formato y contenido esperado), guardrails (sistemas que filtran respuestas o detectan intentos de jailbreak), y fine-tuning (reforzar comportamientos deseados con ejemplos específicos).

Falta de precisión y consistencia

En industrias sensibles —legal, médica, financiera— cada palabra cuenta. Un tono ligeramente equivocado o un formato inconsistente puede arruinar un contrato o generar confusión en un diagnóstico.

El problema de la variabilidad: sin forzar determinismo (temperatura = 0), el modelo genera respuestas ligeramente distintas cada vez que le preguntas lo mismo. Incluso con temperatura = 0, algunas implementaciones no son completamente deterministas por paralelismo y operaciones de punto flotante no conmutativas.

El problema de la precisión fáctica — alucinaciones: los modelos no tienen un mecanismo de verificación de hechos; generan lo estadísticamente probable según su entrenamiento. Si hay una laguna en su conocimiento, la llenan con lo que “debería” ir ahí, no necesariamente con la verdad. Ejemplo: pregúntale a un modelo base “¿cuál es la capital de un país inventado llamado ‘Zarlandia’?” — es bastante probable que invente una respuesta plausible como “Zarlandia tiene su capital en Zarcity”, en vez de reconocer que el país no existe. Es un problema de sobreconfianza, no de falta de inteligencia.

¿Cómo se aborda? Estructurar la salida (forzar JSON o formatos específicos en vez de texto libre), combinar el modelo con sistemas de verificación (RAG con verificación de fuentes), y usar evals (Parte II) para detectar sistemáticamente cuándo el modelo se desvía del formato o contenido esperado.

Límites de la ventana de contexto

Los modelos pueden “leer” el equivalente a un par de libros enteros. Pero su capacidad de atención se degrada en textos gigantescos, incluso cuando el texto técnicamente cabe en la ventana de contexto.

El ejercicio clásico — “aguja en un pajar”: se inserta una oración aleatoria e irrelevante en medio de un documento enorme (“Arun y Max estaban tomando café en Blue Bottle”), y se le pregunta al modelo qué tomaban Arun y Max. Aunque la ventana de contexto sea técnicamente suficiente, el mecanismo de atención a veces falla en encontrar esa “aguja” dentro del pajar.

Esto no es solo una anécdota — está medido y documentado. El paper “Lost in the Middle: How Language Models Use Long Contexts” (Liu et al., Transactions of the Association for Computational Linguistics, 2024) probó esto sistemáticamente con tareas de preguntas sobre múltiples documentos: colocaron el documento con la respuesta correcta en distintas posiciones dentro del contexto (inicio, medio, final), rodeado de documentos distractores, y midieron la precisión resultante. El hallazgo central: una curva de precisión en forma de U — la precisión es más alta cuando la información relevante está al inicio o al final del contexto, y cae de forma marcada cuando está en el medio. Este patrón se repitió de forma consistente en varios modelos, incluyendo modelos diseñados explícitamente para contexto largo.

Gráfica: el efecto “Lost in the Middle”

Por qué ocurre: el mecanismo de atención es paralelo y denso — cada token puede atender a todos los demás — pero en la práctica, con miles de tokens de por medio, esa atención se vuelve difusa: la “señal” de la información relevante se diluye en el “ruido” del resto del contexto. Además, los modelos tienden a prestar más atención a los tokens al principio (sesgo de primacía) y al final (sesgo de recencia) del contexto, descuidando relativamente el centro. Esto conecta con algo que ya vimos: la arquitectura del transformer da acceso directo a cualquier parte del contexto a través de la atención, pero eso no garantiza que el entrenamiento haya enseñado a usar bien esa conexión cuando la información relevante está enterrada entre miles de tokens irrelevantes.

¿Cómo se aborda? Chunking (dividir el texto en fragmentos más manejables), arquitecturas de recuperación como RAG (en vez de meter todo el texto en el contexto, buscar solo las partes relevantes), y gestión de contexto en agentes (mantener solo la información más relevante en cada turno, descartando lo redundante).

Límites computacionales y de latencia

Generar una respuesta larga puede tardar varios segundos incluso en hardware costoso, y cada token generado tiene un costo económico real. La atención requiere memoria que crece con el cuadrado de la longitud del contexto — todo esto ya lo cubrimos a fondo en Parte III (cuántos tokens por segundo necesitas, optimización de inferencia, KV cache, cuantización, y el trilema latencia/throughput/costo). Vale la pena mencionarlo aquí como límite del modelo base porque es, junto con el resto de esta lista, una de las razones por las que “usar el modelo directamente” no basta para producción — pero no vamos a repetir esa discusión completa aquí, ya está desarrollada con el rigor que merece más adelante en el compendio.

Límites en razonamiento de múltiples pasos

Aunque los modelos son excelentes reconociendo patrones estadísticos, fallan con más frecuencia en tareas de razonamiento de largo alcance que requieren encadenar varios pasos lógicos.

Ejemplo: “Si Alice tiene 3 manzanas y Bob le da 2 más, y luego Alice come una, ¿cuántas manzanas tiene Alice?” — un modelo típico lo resuelve sin problema, es simple. Pero un problema que requiere 10 pasos de razonamiento encadenados puede hacer que el modelo “pierda el hilo” en algún punto intermedio.

Los modelos no tienen un “buffer de trabajo” persistente como el razonamiento humano — su capacidad de encadenar pasos emerge de la atención y las capas MLP, que tienen un límite práctico en la profundidad de relaciones que pueden capturar en una sola pasada. Por eso existen técnicas específicas para esto — como el Chain-of-Thought del Capítulo 2 de esta misma parte (obligar al modelo a escribir su razonamiento paso a paso, en vez de saltar directo a la respuesta), o los agentes que descomponen un problema grande en subtareas más manejables (que veremos más adelante).

Por qué este capítulo va primero en Parte II

Límite	Técnica que lo ataca
Falta de conocimiento del dominio	RAG
Falta de información actualizada	RAG con fuentes en tiempo real, tool use
Dificultad de control	Prompting estructurado, guardrails, fine-tuning
Falta de precisión y consistencia	Prompting estructurado, fine-tuning, evals
Límites de la ventana de contexto	Chunking, RAG, gestión de contexto en agentes
Límites computacionales y de latencia	Modelos más pequeños/especializados, KV cache, cuantización (Parte III)
Razonamiento de múltiples pasos	Chain-of-Thought, agentes con planificación

Cuando ves a alguien usando un LLM en producción de forma seria, no está “usando el modelo base” — está usando una pila de técnicas que compensan estos límites. El modelo base es el motor, pero el vehículo completo necesita dirección, frenos, y carrocería. Sin esas capas, el motor es solo un bloque de metal ruidoso.

La trampa más común al adoptar IA: ver una demo impresionante de un modelo base, asumir que resuelve tu problema directamente, intentarlo en un caso real, verlo fallar, y culpar “a la IA” por no ser suficientemente inteligente. Pero el problema casi nunca es que el modelo sea “tonto” — es que se le pidió hacer algo para lo que, estructuralmente, no está equipado sin ayuda: no tiene tus datos internos, no sabe qué pasó ayer, no puede razonar establemente a 10 pasos, y no es determinista. Pedirle que haga todo eso sin ninguna capa de ingeniería alrededor es como pedirle a un motor que te lleve al trabajo sin ruedas.

Resumen del capítulo

Los límites de un modelo base no son “defectos” corregibles — son restricciones inherentes a su arquitectura y método de entrenamiento. La ingeniería de IA no consiste en eliminarlos (muchos son fundamentales), sino en diseñar alrededor de ellos — como en ingeniería civil, donde no se elimina la gravedad, se construyen puentes que la soportan.

Cada uno de los capítulos que siguen en esta parte del compendio es, precisamente, una de esas piezas de ingeniería: prompt engineering para dar mejor dirección, RAG para inyectar conocimiento externo y actualizado, agentes para dar capacidad de planificación y herramientas, fine-tuning para adaptar comportamiento, y evaluación para medir si todo lo anterior realmente funciona.