El modelo generador: criterios para elegir quién redacta

Quinta entrega del bloque de modelos. Terminados los embeddings, toca la pieza que todo el mundo mira primero y que, en un RAG bien construido, es de las que menos determinan el resultado. Eso no significa que dé igual cuál se elija: significa que los criterios para elegirlo no son los que se usan habitualmente.

En un sistema RAG el modelo generador ocupa el último tramo del pipeline. Recibe un prompt que contiene la pregunta del usuario y un puñado de fragmentos recuperados, y su trabajo consiste en redactar una respuesta apoyada exclusivamente en esos fragmentos. No tiene que saber de tu negocio, ni recordar nada, ni razonar sobre conocimiento propio. Tiene que leer bien y no inventar.

Esa descripción del trabajo es la que debería guiar la elección, y casi nunca lo hace. Lo habitual es coger el modelo que encabeza las clasificaciones generales, que están construidas para medir otra cosa: conocimiento enciclopédico, razonamiento matemático, programación. Un modelo excelente en esas tareas puede ser mediocre en la única que aquí importa.

Los siete criterios y cómo se prueba cada uno

Fidelidad al contexto: la capacidad que decide

Es la propiedad más importante y la que menos aparece en las clasificaciones públicas. Consiste en que, cuando el prompt dice «responde usando exclusivamente estos fragmentos», el modelo obedezca de verdad: que no complete huecos con conocimiento propio, que no suavice una afirmación del documento porque le parece extraña, que no mezcle lo que dice el fragmento con lo que aprendió durante el entrenamiento.

El conflicto es real y frecuente. Tu documentación interna dice que el plazo de devolución es de veinte días; el modelo ha leído mil veces que el plazo habitual es de catorce. Un modelo con baja fidelidad responde catorce, o responde veinte añadiendo una coletilla que siembra dudas. Un modelo con alta fidelidad responde veinte y punto.

La prueba es directa y merece hacerla siempre. Prepara cinco o diez fragmentos con datos deliberadamente distintos de lo que el modelo «sabe» —una fecha, una cifra, un nombre— y comprueba qué responde. Es una prueba de diez minutos que descarta candidatos con una eficacia que ninguna tabla iguala.

Un matiz importante: la fidelidad no depende sólo del modelo, sino también del prompt. Instrucciones explícitas y una separación clara entre las instrucciones y los datos mejoran mucho el comportamiento de casi cualquier modelo, como vimos en la entrega 6. Pero mejoran desde un punto de partida que sí depende del modelo, y ese punto de partida varía bastante entre familias.

Seguimiento de instrucciones

Un RAG en producción rara vez pide sólo una respuesta en prosa. Pide citas con el identificador del fragmento, un formato estructurado que la interfaz sabe pintar, un límite de longitud, un registro concreto, y a veces todo a la vez. La capacidad de cumplir esas restricciones de forma consistente —no el ochenta por ciento de las veces— es lo que separa un prototipo de un sistema que no necesita vigilancia.

Aquí conviene medir la varianza, no la media. Un modelo que produce el formato correcto casi siempre pero se desvía una de cada quince veces obliga a escribir código defensivo, reintentos y validación de esquema. Esa cola de fallos cuesta más ingeniería que la diferencia de precio con un modelo más obediente. Los modos de salida estructurada garantizada que ofrecen varios proveedores resuelven buena parte del problema y son un criterio de selección legítimo por sí mismos.

Decir «no lo sé»

Un RAG que responde a todo es un RAG que miente parte del tiempo. Cuando la recuperación no ha traído la respuesta —porque no está en el corpus, porque el troceado la partió, porque la pregunta estaba mal formulada—, lo correcto es abstenerse.

Los modelos difieren mucho en esto, y la diferencia no se correlaciona bien con su tamaño ni con su posición en las clasificaciones generales. Hay modelos entrenados con un fuerte sesgo hacia la utilidad que casi nunca se niegan a responder, y ese sesgo, que es una virtud en un asistente conversacional, es un defecto en un RAG.

La prueba consiste en incluir en tu conjunto de evaluación un diez o veinte por ciento de preguntas sin respuesta en el corpus, y contar abstenciones. Es la parte del golden dataset que más se olvida y la que más problemas evita.

Ventana, latencia y coste

La ventana necesaria en un RAG es más modesta de lo que sugiere el marketing de contexto largo. Con diez fragmentos de 500 tokens, instrucciones y algo de historial conversacional, un prompt típico ronda los pocos miles de tokens. Prácticamente cualquier modelo actual lo admite. Las ventanas enormes sólo hacen falta si recuperas muchos fragmentos o muy grandes, y meter más contexto del necesario empeora el resultado por el efecto de «perdido en el medio» que vimos en la entrega 6, además de encarecer y ralentizar cada consulta.

En latencia hay dos números distintos y conviene no mezclarlos. El tiempo hasta el primer token determina la sensación de rapidez, y es lo que percibe el usuario si la respuesta se emite en streaming. Los tokens por segundo determinan cuánto tarda en completarse. Con streaming activado, un modelo con buen tiempo hasta el primer token y velocidad media se percibe más rápido que uno con el patrón inverso. Ambos empeoran con prompts largos, así que hay que medirlos con el tamaño real del prompt.

En coste, la asimetría estructural de un RAG es que la entrada domina. Se envían miles de tokens de fragmentos y se reciben unos cientos de respuesta. Eso hace que el precio del token de entrada pese mucho más en la factura, y que el número de fragmentos recuperados sea una palanca de coste tan importante como la elección del modelo. Reducir de diez fragmentos a cinco, si la evaluación dice que no pierdes recall, ahorra casi la mitad.

Por qué un modelo pequeño suele bastar

Aquí está la conclusión que más ahorra de toda esta entrega. En un RAG bien construido, la tarea del generador es cerrada: tiene delante los fragmentos correctos y sólo debe sintetizarlos con fidelidad. Esa tarea —leer, seleccionar, redactar— es mucho más fácil que las tareas de razonamiento abierto para las que se diseñan las clasificaciones.

Los modelos pequeños y medianos de las familias actuales hacen esa tarea bien. La diferencia con los grandes se nota cuando la respuesta exige razonar sobre varios fragmentos que se contradicen, encadenar inferencias o manejar preguntas ambiguas. Si tus consultas son mayoritariamente factuales, el modelo grande está cobrando por capacidades que no usas.

La consecuencia práctica es un consejo de asignación de esfuerzo. Ante un presupuesto fijo, el dinero rinde más en mejorar la recuperación —mejor troceado, metadatos, búsqueda híbrida, reranking— que en subir de gama de modelo. Un modelo grande con fragmentos equivocados redacta magníficamente una respuesta equivocada. Vuelve a valer el principio de la primera entrega: la calidad de la recuperación pone el techo, y el generador trabaja por debajo de ese techo.

Un patrón que funciona bien en producción es el enrutado por dificultad: modelo pequeño por defecto y escalada a uno mayor sólo cuando se detecta una consulta compleja o cuando una verificación posterior indica que la respuesta es insuficiente. Añade complejidad, así que conviene medir antes que ese enrutado paga por sí mismo.

Límites

Ninguno de estos criterios se evalúa bien con dos o tres pruebas manuales. Las diferencias entre modelos en fidelidad y abstención se ven en distribuciones, no en anécdotas, y el conjunto de evaluación propio vuelve a ser la única herramienta honesta.

Y una advertencia de mantenimiento: las familias de modelos cambian rápido, así que la elección conviene tratarla como reversible. A diferencia del modelo de embeddings, cambiar de generador no obliga a reindexar nada, sólo a revalidar los prompts. Aprovecha esa asimetría: aísla la llamada al generador tras una interfaz propia y podrás cambiarlo en un día cuando salga algo mejor o más barato.

Qué viene ahora

La siguiente entrega cierra el bloque de modelos con los rerankers: los modelos que reordenan los candidatos recuperados antes de pasárselos al generador. Comparamos las opciones comerciales con las abiertas, la latencia por par consulta-documento, el efecto del número de candidatos sobre el coste total y el punto exacto en que el reranking deja de compensar.

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.