RAG, fine-tuning y contexto largo: los tres paradigmas

Séptima entrega y cierre del bloque de fundamentos. Hay tres formas de que un modelo de lenguaje responda sobre información que no estaba en su entrenamiento, y se presentan a menudo como alternativas excluyentes. No lo son: resuelven problemas distintos y la pregunta útil no es cuál elegir sino qué parte del problema resuelve cada una.

Los tres paradigmas, en una frase cada uno

RAG —recuperación aumentada por generación— busca en un corpus externo, en el momento de la consulta, los fragmentos relevantes, y se los entrega al modelo dentro del prompt. El conocimiento vive fuera del modelo y se consulta cuando hace falta.

Fine-tuning —ajuste fino— continúa el entrenamiento de un modelo base con ejemplos propios, modificando sus pesos. El conocimiento, o más bien el comportamiento, queda dentro del modelo.

Contexto largo aprovecha ventanas de cientos de miles de tokens para meter directamente en el prompt todo el material relevante, sin selección previa. El conocimiento se entrega entero en cada consulta.

Las tres cambian lo que el modelo puede responder. La diferencia está en dónde reside la información, cuánto cuesta cambiarla y si se puede saber de dónde salió cada afirmación.

Qué hace bien cada uno

Fine-tuning enseña comportamiento, no hechos

Es la confusión más extendida y la más cara de deshacer. El ajuste fino es excelente para enseñar a un modelo cómo hacer algo: adoptar un registro, seguir una taxonomía de clasificación propia, producir siempre un formato de salida concreto, dominar la jerga de un dominio, aprender a razonar sobre un tipo de tarea recurrente. También sirve para hacer que un modelo pequeño y barato se comporte, en una tarea acotada, como uno grande y caro. Ese es su caso de uso más rentable.

Como mecanismo para inyectar hechos es una herramienta pobre. Los hechos quedan disueltos en los pesos sin rastro de procedencia: no se puede preguntar de dónde viene una afirmación, no se puede borrar un dato que dejó de ser cierto, no se puede aplicar un permiso de acceso a un hecho concreto. Cada actualización del corpus exige un nuevo ciclo de entrenamiento con su coste y su latencia de días. Y el modelo sigue sin tener forma de distinguir entre lo que aprendió y lo que reconstruye por parecido: entrenarlo con tus documentos aumenta la probabilidad de que acierte, no su capacidad de reconocer que no sabe.

RAG entrega hechos verificables

RAG hace justo lo contrario. El conocimiento está fuera, en un índice que se actualiza en segundos, con metadatos que permiten filtrar por permisos antes de que el modelo vea nada, y con una cadena de procedencia que va de la afirmación al fragmento y del fragmento al documento. Es la única de las tres que da trazabilidad real.

A cambio introduce un sistema entero que mantener: ingesta, troceado, embeddings, índice, recuperación. Y hereda el principio que atraviesa toda esta serie: la calidad de la recuperación pone el techo a la calidad del sistema. Si el fragmento correcto no se recupera, ningún modelo lo arregla. RAG no enseña comportamiento: un modelo que redacta mal seguirá redactando mal con los mejores fragmentos del mundo delante.

Contexto largo elimina la selección

Su virtud es que no hay recuperación que ajustar, y por tanto no hay recuperación que falle. Si todo el material cabe, el modelo lo ve todo y puede razonar sobre el conjunto: comparar dos contratos completos, seguir un hilo argumental a lo largo de un informe, detectar que algo no aparece en ningún sitio. Eso último es notable, porque es precisamente lo que un sistema RAG hace peor: las preguntas de cobertura global —«¿cuántos de estos documentos mencionan X?»— no se responden con cinco fragmentos.

Sus límites son de escala y de economía. Se paga el corpus entero en cada consulta, la latencia crece con la longitud del contexto, y el efecto «perdido en el medio» degrada la recuperación de datos situados en el centro de contextos muy largos. Cualquier corpus corporativo real supera con holgura incluso las ventanas más generosas: una ventana de cientos de miles de tokens suena enorme hasta que se compara con un archivo documental de veinte años.

Tabla de decisión

Cómo se lee esta tabla

Hay tres criterios que suelen decidir por sí solos, y conviene comprobarlos antes que los demás.

Si el dato cambia, el fine-tuning queda fuera como mecanismo para almacenarlo. No es una cuestión de grado: un precio, un plazo o una versión de producto que cambia cada trimestre no puede vivir en los pesos de un modelo.

Si hay que justificar la respuesta, RAG es la única opción real. En cualquier contexto con implicaciones legales, regulatorias o reputacionales, poder mostrar el párrafo del que salió una afirmación no es un adorno: es la diferencia entre poder usar el sistema y no poder.

Si distintos usuarios deben ver distintas cosas, RAG es la única que lo hace de forma granular. Un modelo ajustado con toda la documentación de la empresa la ha aprendido entera para cualquiera que le pregunte, y no hay permiso que aplicar después. El contexto largo permite decidir qué se adjunta, lo que resuelve el caso de grano grueso, pero obliga a gestionar esa decisión fuera del sistema.

El contexto largo gana claramente en un escenario concreto: corpus pequeño y estable que cabe entero con holgura, preguntas que requieren visión de conjunto, y tolerancia al coste por consulta. Analizar un contrato de ochenta páginas, revisar un informe completo, comparar dos documentos. En esos casos montar un pipeline RAG es resolver un problema que no se tiene.

Por qué en la práctica se combinan

El reparto natural, cuando el sistema madura, es bastante estable: fine-tuning para el comportamiento, RAG para los hechos, contexto largo para lo que cabe.

Un asistente de soporte técnico real puede ajustar un modelo pequeño para que siga siempre el protocolo de escalado de la empresa y produzca respuestas con la estructura que espera el sistema de tickets —comportamiento—, mientras recupera de un índice vectorial la documentación del producto actualizada esta mañana —hechos—. El ajuste no contiene ni un dato de producto; el índice no enseña ningún formato. Cada pieza hace lo suyo.

Las combinaciones más habituales son tres. La primera, fine-tuning más RAG, que es la anterior y también la que permite bajar de un modelo grande a uno pequeño ajustado sin perder calidad, con el consiguiente ahorro por consulta. La segunda, RAG con contexto largo: en lugar de recuperar fragmentos pequeños, se recuperan documentos enteros o secciones amplias y se aprovecha la ventana grande para no tener que afinar tanto el troceado. Es un buen punto intermedio cuando la ventana lo permite, aunque se paga en coste por consulta. La tercera, recuperación en dos etapas, donde una primera búsqueda reduce el corpus a los veinte documentos candidatos y esos veinte se meten enteros en un contexto largo para que el modelo razone sobre el conjunto: resuelve algunas preguntas de cobertura global que un RAG clásico no alcanza.

Los errores caros de esta decisión

Hay tres que se repiten y merecen decirse con claridad.

El primero es ajustar un modelo para inyectar documentación. Se invierten semanas, se obtiene un modelo que a veces acierta y a veces inventa con el mismo aplomo, no se puede auditar, y a los dos meses la documentación ha cambiado. Casi siempre era un caso de RAG.

El segundo es montar un pipeline RAG completo para un corpus diminuto. Con doscientos documentos que caben en una ventana grande, la infraestructura vectorial añade complejidad, parámetros que ajustar y modos de fallo nuevos sin mejorar la respuesta.

El tercero es suponer que un contexto más largo hace innecesaria la recuperación. Cada ampliación de ventana viene acompañada del anuncio de que RAG ha quedado obsoleto, y no ocurre por tres razones que no dependen del tamaño de la ventana: el coste por consulta crece con el material adjunto, la atención se degrada con la longitud, y ningún corpus corporativo cabe en ninguna ventana. Lo que sí cambia con las ventanas largas es el diseño del RAG: menos presión sobre el troceado fino, más margen para recuperar contexto amplio, fragmentos más grandes. El componente de recuperación no desaparece, se relaja.

Qué viene ahora

Aquí termina el bloque de fundamentos. Hasta ahora hemos mirado el sistema desde arriba: qué problema resuelve, de qué piezas se compone, cómo se representa el significado, dónde se guardan los vectores, cómo se busca entre ellos, cómo se monta el prompt y cuándo conviene otra cosa. El siguiente bloque baja al material y se queda ahí un buen rato, porque es donde se decide casi todo: la ingesta y la preparación del corpus. Extraer texto limpio de PDF, HTML y bases de datos; las estrategias de troceado, de las más simples a las más recientes; el diseño del esquema de metadatos; y el ciclo de vida del corpus, que incluye actualizar, deduplicar, resolver contradicciones y borrar de verdad.

Si prefieres leerlo todo de golpe y en orden, los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.