RAG sin humo: cuándo necesitas búsqueda vectorial y cuándo no

RAG se vende como la forma de conectar un modelo con tu información. Es una solución concreta para un problema concreto: el modelo no tiene tus datos y no caben en el contexto. Cuando el problema es otro, añade infraestructura y una nueva fuente de errores. Antes de montar un índice vectorial, descarta las alternativas que suelen resolverlo mejor.

Qué problema resuelve RAG

RAG recupera fragmentos relevantes de una colección y los pone delante del modelo para que responda con ellos. Sirve cuando el conocimiento es privado, cambia con el tiempo o es demasiado grande para incluirlo entero.

No sirve para que el modelo razone mejor, siga un procedimiento o elija bien entre opciones. Si la información ya está en el prompt y la respuesta sigue mal, el problema es de instrucciones o de capacidad, no de recuperación.

El cambio importante es que trasladas el fallo. Antes tenías un sistema que generaba mal. Ahora tienes dos: uno que elige fragmentos y otro que redacta. El de recuperación falla en silencio, con la seguridad de un texto plausible.

Las tres alternativas que la gente salta

Contexto completo

Si tu corpus es un manual de producto, una política interna o un catálogo pequeño y estable, pégalo entero. Sin índice, sin chunking, sin reindexar. Menos piezas, menos fallos.

El límite no es técnico, es económico y de atención: pagas por cada llamada y el modelo puede perder detalle en medio de un contexto enorme. Pero un prompt largo con la sección correcta suele superar a un buscador mediocre. Mide antes de asumir que necesitas infraestructura.

Búsqueda por palabra clave

Tu base de datos ya sabe buscar texto. Un índice de texto completo resuelve códigos de producto, nombres propios, referencias legales y números de contrato mejor que cualquier embedding, porque busca exactamente lo que el usuario escribió.

Es barato, explicable y fácil de depurar: ves por qué apareció un resultado. Donde falla es en paráfrasis y sinónimos, y ahí sí aporta la búsqueda vectorial. La combinación de ambas es menos glamorosa y más efectiva que reemplazar una por otra.

Datos estructurados

Si la pregunta es cuántos, cuáles, cuánto costó o en qué estado está, la respuesta vive en una tabla. RAG sobre tablas convierte una consulta exacta en una aproximación redactada.

La solución es una consulta, una API o un panel. Si el usuario necesita lenguaje natural, pon una capa de texto a SQL con validación y permisos, no un índice de documentos. La mayoría de los proyectos de "chatea con nuestros datos" son proyectos de reportes con otra interfaz.

Cómo decidir

Si la pregunta... | Señal en el negocio | Empieza con
Cabe en un manual estable | Pocas páginas y cambia poco | Contexto completo
Usa códigos, nombres o referencias exactas | El usuario copia y pega el término | Búsqueda por palabra clave
Pide cifras, estados o agregados | La respuesta está en una tabla | Consulta a datos estructurados
Parafrasea documentos largos y cambiantes | Soporte, legales, documentación técnica | RAG
Necesita citar la fuente | El riesgo de inventar es alto | RAG o buscador con citas
Cruza varios documentos | Comparar contratos, sintetizar incidentes | RAG con evaluación estricta

Una prueba útil antes de escribir código: toma veinte preguntas reales e intenta responderlas a mano señalando el documento exacto. Si no puedes nombrarlo, el buscador tampoco. Si necesitas tres documentos y una resta, RAG no es el problema que tienes.

Chunking: donde se rompe el proyecto

El error más caro no es elegir mal el modelo de embeddings. Es indexar el corpus equivocado: versiones viejas, borradores, PDFs escaneados con OCR sucio, duplicados que ocupan todo el top de resultados.

• Corta por estructura, no por número de caracteres. Un apartado con su título vale más que tres fragmentos que empiezan a mitad de frase.
• Guarda metadatos: fuente, sección, fecha, versión, permisos. Sin fecha, el sistema citará la política derogada con total confianza.
• Recupera pequeño y devuelve el contexto padre. El fragmento sirve para encontrar; la sección completa, para responder.
• Arregla tablas y listas antes de indexarlas. Un cuadro de precios partido en filas sueltas produce respuestas sin sentido.
• Deduplica. Cinco copias del mismo párrafo no dan más información, solo menos variedad en el top de resultados.
• Excluye lo que no se debe responder: notas internas, datos personales, documentos obsoletos.

El solapamiento entre fragmentos es un parche para cortes malos, no una estrategia. Si dependes de él para que las respuestas tengan sentido, el problema está en los límites.

Evaluar recuperación y respuesta por separado

Son dos sistemas y dos formas de fallar. Si el fragmento correcto no aparece, ningún prompt lo salva. Si aparece y la respuesta lo ignora, el problema es de generación.

Para recuperación, arma un conjunto de preguntas con el documento que debería salir. Mide si está en el top de resultados y en qué posición. Cincuenta casos reales bastan para ver la tendencia.

Para respuesta, revisa tres cosas: si se apoya en las fuentes, si está completa y si cita el documento correcto. Incluye preguntas sin respuesta en el corpus. La métrica más reveladora es cuántas veces el sistema admite que no sabe.

No mezcles ambas métricas en un solo número. Un ochenta por ciento global puede esconder un sesenta de recuperación y un noventa y cinco de redacción, y las soluciones son opuestas: una pide mejor índice, la otra, mejores instrucciones.

Cuándo no implementarlo

• El corpus cabe en el contexto y cambia poco.
• La pregunta pide un dato exacto que vive en una base de datos.
• Nadie va a mantener el corpus: RAG amplifica la deuda documental, no la resuelve.
• No hay forma de evaluar ni de revisar respuestas: tendrás una demo que suena bien y se equivoca sin avisar.
• El contenido cambia cada hora y no puedes reindexar: consulta la fuente directamente.
• Un error tiene consecuencias legales o económicas y no hay fuente verificable: deriva a una persona.

RAG no vuelve más listo al modelo. Solo le da mejores papeles. Si eliges mal los papeles, obtendrás una mentira mejor redactada.

La pregunta correcta no es si puedes implementar RAG, sino si tu problema es de acceso a información. Si el corpus es grande, cambiante y en lenguaje natural, adelante. Si no, acabas de ahorrarte un índice que nadie iba a mantener.