Naive RAG: la línea base y sus límites estructurales

El patrón mínimo, qué resuelve bien y en qué cuatro puntos concretos se rompe siempre.

Naive RAG: la línea base y sus límites estructurales
Foto de Imad Clicks en Pexels

Arranca el tercer bloque de la serie, dedicado a las técnicas de recuperación. Antes de mejorar nada conviene tener claro qué se está mejorando: el patrón más simple de RAG, el que aparece en todos los tutoriales, funciona mejor de lo que se admite y falla de formas muy concretas y muy predecibles.

El patrón mínimo, descrito sin adornos

Lo que la literatura llama Naive RAG —RAG ingenuo, o RAG de un paso— es el pipeline reducido a lo indispensable. Con el corpus ya troceado e indexado (los bloques anteriores de la serie se dedicaron a eso), cada pregunta recorre exactamente cuatro pasos, siempre los mismos, siempre en el mismo orden:

  1. Se convierte la pregunta del usuario en un vector con el mismo modelo de embeddings que se usó para indexar.
  2. Se buscan en la base vectorial los k fragmentos cuyo vector queda más cerca, normalmente por similitud coseno.
  3. Se pegan esos k fragmentos en una plantilla de prompt junto con la pregunta.
  4. Se envía el prompt al modelo generador y se devuelve lo que responda.

No hay ramas, no hay condiciones, no hay reintentos. La misma secuencia de operaciones se ejecuta para «¿cuál es el plazo de devolución?» y para «compara la política de devoluciones de 2022 con la actual y dime qué cambió y por qué». El sistema no tiene forma de saber que la segunda pregunta es mucho más difícil que la primera, porque no evalúa nada: hace lo que hace y ya está.

Conceptualmente, todo el tiempo de ejecución cabe en unas pocas líneas:

def responder(pregunta, k=5):
    v = embed(pregunta)
    fragmentos = indice.buscar_por_similitud(v, k)
    contexto = "\n\n---\n\n".join(f.texto for f in fragmentos)
    prompt = PLANTILLA.format(contexto=contexto, pregunta=pregunta)
    return llm.generar(prompt)

Esa función tiene tres parámetros libres y ninguno más: el modelo de embeddings, el valor de k y la plantilla. Todo lo demás se decidió en la indexación. Conviene retener el dato, porque explica a la vez su virtud y su límite: hay muy poco que ajustar cuando algo va mal.

Qué resuelve bien, que no es poco

La tentación al abrir un bloque sobre técnicas avanzadas es presentar la línea base como un espantajo. Sería un error: una parte considerable de los sistemas RAG en producción son exactamente esto, y responden bien.

El patrón mínimo funciona cuando se dan tres condiciones simultáneas. La primera es que la pregunta sea atómica: pide un hecho, no una comparación ni una síntesis. La segunda es que la respuesta esté localizada en un fragmento o en dos contiguos, no repartida por el corpus. La tercera es que exista solapamiento de vocabulario o de significado entre cómo pregunta el usuario y cómo lo escribió el redactor del documento.

Un centro de ayuda con artículos bien estructurados, un manual de producto, unas preguntas frecuentes internas, una base de conocimiento de soporte: en ese material, las tres condiciones se cumplen la mayor parte del tiempo. Añadir reranking, descomposición de consultas y bucles de verificación a un sistema así multiplica el coste y la latencia para mejorar el margen de casos que ya funcionaban.

Hay además una razón metodológica para empezar aquí, y es la que da título a la entrega: sin línea base no hay mejora medible. Cualquier afirmación del tipo «el reranking nos subió la calidad» sólo significa algo comparada contra el mismo conjunto de preguntas resuelto por el pipeline simple. La entrega 40 se dedicará al conjunto de preguntas con respuesta verificada que hace posible esa comparación; sin él, las decisiones sobre técnicas de recuperación se toman por intuición y por moda.

Los cuatro puntos donde se rompe

Los fallos del patrón mínimo no son aleatorios. Son cuatro, son estructurales —derivan del diseño, no de una mala configuración— y cada uno tiene su propio remedio en las entregas siguientes.

1. El usuario no usa las palabras del documento

La búsqueda densa mide proximidad semántica, y eso resuelve el caso fácil: «¿cuánto tarda el envío?» encuentra un fragmento que habla de «plazos de entrega». Pero la representación vectorial es aproximada por naturaleza. Comprime el significado de un fragmento entero en unos cientos o miles de números, y en esa compresión se pierden precisamente los elementos que no tienen sinónimos: un código de referencia como RD 1619/2012, un número de pieza, una sigla poco frecuente, un apellido.

El resultado incómodo es que un sistema puramente denso puede fallar en la búsqueda más literal imaginable. Preguntas por un identificador exacto que aparece escrito tal cual en un fragmento, y te devuelve tres fragmentos que hablan del mismo tema general sin contener el identificador. La búsqueda por palabras clave, que parecía superada, resuelve ese caso sin despeinarse. De ahí la búsqueda híbrida.

2. La pregunta contiene varias preguntas

«¿Qué cubre el seguro básico y en qué se diferencia del prémium?» es, para el sistema de recuperación, un único vector. Ese vector cae en algún punto intermedio entre la región del espacio donde viven los fragmentos sobre el seguro básico y la región donde viven los del prémium. Un punto medio entre dos zonas densas suele estar en tierra de nadie: los vecinos más cercanos serán fragmentos genéricos sobre seguros, o todos de una de las dos pólizas y ninguno de la otra.

El fallo es especialmente traicionero porque el modelo generador responderá igualmente. Con cinco fragmentos sobre el seguro básico y ninguno sobre el prémium, redactará una comparación en la que la mitad de las afirmaciones son inventadas o inferidas. La respuesta parecerá completa. Ese es el peor tipo de fallo posible.

3. La respuesta está repartida entre documentos

Hay preguntas cuya respuesta no está escrita en ningún sitio, sino que resulta de agregar información dispersa. «¿Cuántas veces hemos cambiado la política de teletrabajo desde 2020?» exige localizar todas las versiones y contarlas. «¿Qué proveedores aparecen mencionados en las actas del último trimestre?» exige recorrer todas las actas.

La recuperación por similitud devuelve los k fragmentos más parecidos a la pregunta, y k es un número pequeño y fijo. No hay ningún k que resuelva una pregunta de agregación sobre cuatrocientos documentos: si es pequeño, faltan datos; si es grande, el contexto se satura y el modelo se pierde en él, con el efecto de «perdido en el medio» que vimos en la entrega 06. El problema no es de tamaño, es de naturaleza: la similitud no es una operación de agregación.

4. Nadie comprueba nada

El cuarto fallo es el que engloba a los tres anteriores. En el patrón mínimo no existe ningún punto en el que el sistema se pregunte si lo que ha recuperado sirve. Los fragmentos entran en el prompt por el hecho de ser los más cercanos, no por ser relevantes: si el corpus no contiene nada sobre la pregunta, la base vectorial devolverá igualmente los cinco fragmentos menos malos, con puntuaciones de similitud mediocres que nadie mira.

Tampoco se comprueba nada después. El modelo genera una respuesta y esa respuesta se devuelve al usuario sin que ningún componente verifique si se apoya en el contexto entregado o si el modelo ha rellenado los huecos con conocimiento paramétrico. Un sistema sin verificación no es que falle más: es que no puede distinguir sus aciertos de sus fallos, y por tanto tampoco puede avisar al usuario.

Dónde ataca cada técnica

Punto de rotura Síntoma observable Remedio en esta serie
Vocabulario distinto Falla con códigos, siglas y nombres propios exactos Búsqueda híbrida (15), reranking (16)
Pregunta compuesta Responde sólo a una mitad, e inventa la otra Descomposición y multi-query (17)
Respuesta dispersa Falla en preguntas globales, de conteo o de relación GraphRAG (20), agentes (21)
Sin verificación Nunca dice «no lo sé»; falla en silencio Corrective RAG y Self-RAG (19)

Los límites de esta lectura

Dos advertencias antes de seguir. La primera: no todos los fallos de un pipeline simple son fallos del pipeline simple. Una parte importante de lo que se atribuye a la ingenuidad del patrón viene en realidad de un troceado mal dimensionado, de una ingesta que destrozó las tablas del PDF o de una ausencia total de metadatos. Antes de añadir un reranker conviene descartar que el problema esté aguas arriba, porque una técnica de recuperación sofisticada sobre un corpus mal preparado sigue siendo un sistema mal preparado.

La segunda: cada técnica de las que vienen ataca uno o dos de estos cuatro puntos, no los cuatro. Apilarlas todas «por si acaso» produce sistemas caros, lentos y difíciles de depurar, en los que nadie sabe qué componente está aportando qué. La secuencia sensata es medir la línea base, identificar cuál de los cuatro fallos domina en tus preguntas reales y añadir exactamente el remedio correspondiente.

Qué viene ahora

La siguiente entrega ataca el primero de los cuatro puntos, el del vocabulario. Veremos qué captura la búsqueda vectorial y qué captura la búsqueda léxica clásica, por qué BM25 sigue ganando en códigos, referencias y nombres propios, y cómo se combinan dos rankings heterogéneos: normalización de puntuaciones frente a fusión recíproca de rangos, con la fórmula y un ejemplo resuelto con números.

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.