Qué es RAG y por qué importa
Retrieval Augmented Generation, normalmente abreviado como RAG, es el patrón que permite que una aplicación basada en modelos de lenguaje responda usando información externa al propio modelo. La idea es sencilla: antes de pedirle al LLM que genere una respuesta, la aplicación recupera contenido relevante de una base de conocimiento, lo añade al prompt como contexto y pide una respuesta fundamentada en ese material.
El valor de RAG aparece en cualquier escenario donde el modelo por sí solo no basta. Un LLM no conoce automáticamente la documentación interna de una empresa, los tickets de soporte, los contratos, los manuales operativos ni las últimas versiones de un repositorio privado. RAG conecta la capacidad generativa del modelo con conocimiento específico, actualizado y gobernado por la organización.
También aporta trazabilidad. En vez de confiar únicamente en la memoria estadística del modelo, la aplicación puede conservar qué fragmentos se recuperaron, qué documentos se usaron y qué fuentes justifican una respuesta. Esa trazabilidad es esencial cuando el asistente se usa para soporte técnico, búsqueda documental, operaciones internas o toma de decisiones.
El flujo mínimo tiene tres pasos:
- Retrieve: buscar documentos, fragmentos o registros relevantes en un índice o repositorio.
- Augment: combinar la pregunta del usuario, las instrucciones del sistema y los fragmentos recuperados.
- Generate: pedir al modelo que genere una respuesta apoyada en ese contexto.
La parte difícil no es describir el patrón, sino hacerlo fiable: preparar bien el contenido, recuperar los fragmentos correctos, filtrar por permisos, evitar contexto irrelevante y medir si la respuesta está realmente fundamentada.
La arquitectura básica de un sistema RAG
Un sistema RAG productivo empieza antes del prompt. Primero hay que preparar el conocimiento que se va a recuperar. Eso suele implicar limpiar documentos, dividirlos en fragmentos, enriquecerlos con metadatos y almacenarlos en una estructura optimizada para búsqueda.
Una arquitectura típica incluye:
- Ingesta desde documentos, blobs, wikis, bases de datos, APIs o repositorios internos.
- Chunking, para dividir el contenido en unidades que puedan recuperarse con precisión sin perder demasiado contexto.
- Embeddings, que convierten texto en vectores numéricos para búsqueda por similitud semántica.
- Campos textuales, necesarios para búsqueda por palabras clave, filtros, facetas y ordenación.
- Metadatos, como título, URL, fecha, versión, idioma, categoría, propietario o permisos.
- Orquestación, que decide cómo buscar, cuántos resultados traer y cómo construir el prompt final.
Cuando llega una pregunta, la aplicación consulta el índice, recupera candidatos, descarta lo que no corresponde al usuario o al caso de uso y entrega al modelo un contexto limitado por el presupuesto de tokens. Si el retrieval falla, el modelo tendrá poco margen para corregir el problema: responderá con información incompleta, genérica o directamente equivocada.
Búsqueda vectorial: útil, pero no suficiente
La búsqueda vectorial es una pieza importante porque permite encontrar fragmentos conceptualmente similares aunque no compartan exactamente las mismas palabras. Durante la indexación, cada chunk se transforma en un vector mediante un modelo de embeddings. Durante la consulta, la pregunta se transforma con el mismo tipo de modelo y se buscan los vectores más cercanos.
Esto funciona bien para preguntas formuladas en lenguaje natural. Por ejemplo, una consulta como “cómo reduzco respuestas inventadas en mi asistente interno” puede recuperar documentación sobre grounding, citas, evaluación de respuestas o diseño de prompts aunque no use exactamente esos términos.
Pero la búsqueda vectorial no resuelve todos los casos. Códigos de error, nombres de producto, identificadores, comandos, versiones, URLs o siglas internas suelen necesitar coincidencia literal. Si el usuario busca un código concreto, una política interna o el nombre exacto de una API, una estrategia puramente semántica puede devolver resultados plausibles pero incorrectos.
Por eso, en producción, la pregunta no debería ser “vector search o keyword search”, sino cómo combinar ambas de forma controlada.
Búsqueda híbrida como punto de partida práctico
La búsqueda híbrida combina búsqueda textual y búsqueda vectorial. La parte textual aporta precisión en términos exactos; la parte vectorial aporta recuperación conceptual. Después, el sistema fusiona ambos rankings para producir una única lista de resultados.
Este enfoque es especialmente útil en dominios técnicos porque cubre dos tipos de intención:
- Intención conceptual, cuando el usuario describe un problema con lenguaje natural.
- Intención exacta, cuando el usuario busca un identificador, una función, una versión o un término técnico específico.
En un sistema RAG empresarial, la búsqueda híbrida suele ser un baseline más robusto que la búsqueda vectorial aislada. Reduce el riesgo de perder resultados importantes por diferencia de vocabulario y, al mismo tiempo, evita depender únicamente de coincidencias exactas.
El siguiente paso suele ser añadir una capa de reranking para reordenar los candidatos iniciales según su relevancia real para la pregunta.
Reranking: reducir ruido antes de generar
Recuperar candidatos no equivale a recuperar buenos candidatos. Un fragmento puede compartir palabras con la pregunta o estar cerca en el espacio vectorial y, aun así, no responder realmente a lo que el usuario necesita.
El reranking introduce una segunda fase de calidad. En vez de aceptar directamente el orden inicial, el sistema vuelve a evaluar los mejores candidatos y prioriza los que tienen más relación con la pregunta. Esta fase es más costosa que la recuperación inicial, pero puede mejorar mucho la calidad del contexto que llega al modelo.
Hay dos principios importantes:
- El reranker no arregla un retrieval que nunca encontró el documento correcto.
- El reranker funciona mejor cuando los campos del índice están bien estructurados y el chunking conserva suficiente contexto.
Por eso conviene medir el pipeline por capas: primero comprobar si el documento correcto aparece entre los candidatos, después si aparece suficientemente arriba, y finalmente si el modelo usa bien ese contexto.
Límites reales del RAG clásico
RAG clásico funciona bien cuando la pregunta puede resolverse con una búsqueda relativamente directa sobre un corpus preparado. Pero aparecen límites cuando el sistema crece.
El primer límite es la fragmentación del conocimiento. Si cada aplicación o agente mantiene su propio índice, aparecen versiones distintas de la verdad. Un asistente puede recuperar información actualizada mientras otro responde con documentación antigua.
El segundo límite son las preguntas multi-aspecto. Una consulta puede requerir combinar texto, fechas, permisos, relaciones entre documentos, filtros por producto y contexto conversacional. Resolver eso con una única búsqueda simple suele ser insuficiente.
El tercer límite es la frescura del contenido. Un índice que se actualiza poco puede funcionar para documentación estable, pero no para incidencias, cambios de configuración, estado de servicios o información operativa que cambia con frecuencia.
El cuarto límite es la seguridad. RAG no puede tratar todos los documentos como contexto genérico. Debe aplicar permisos antes de generar, evitar que contenido recuperado manipule el prompt y registrar qué fuentes se usaron para cada respuesta.
Estos límites no invalidan RAG; simplemente obligan a diseñarlo como una arquitectura de búsqueda, gobierno y generación, no como un truco de prompt engineering.
Buenas prácticas para llevar RAG a producción
Un prototipo puede funcionar con unos cuantos PDFs y un prompt largo. Un sistema de producción necesita controles más estrictos:
- Evaluar retrieval por separado del modelo: medir si los fragmentos correctos aparecen entre los primeros resultados antes de evaluar la respuesta generada.
- Usar búsqueda híbrida como baseline: combinar texto y vectores cuando el dominio tenga acrónimos, identificadores o jerga técnica.
- Diseñar chunks con intención: respetar títulos, secciones, tablas, listas y dependencias de contexto.
- Conservar metadatos de fuente: título, URL, fecha, versión y permisos son tan importantes como el texto.
- Aplicar seguridad antes de generar: el modelo solo debe recibir contenido que el usuario pueda consultar.
- Pedir respuestas fundamentadas: el prompt debe indicar qué hacer cuando el contexto no contiene la respuesta.
- Monitorizar frescura: un índice correcto hoy puede quedar obsoleto si no existe una estrategia de actualización.
- Registrar trazabilidad: guardar consulta, documentos recuperados, puntuaciones, respuesta y feedback permite depurar errores.
Muchos fallos atribuidos al LLM son, en realidad, fallos de retrieval, chunking, metadatos, permisos o evaluación.
Conclusión
RAG sigue siendo fundamental porque conecta modelos de lenguaje con conocimiento específico, actualizado y gobernado. Pero una implementación madura no consiste solo en vectorizar documentos y pegarlos al prompt. Requiere búsqueda híbrida, ranking de calidad, control de acceso, trazabilidad y evaluación continua.
La tesis es simple: un modelo solo puede responder bien si recibe el contexto correcto. La ingeniería de RAG consiste en encontrar ese contexto, demostrar de dónde viene y entregarlo al modelo sin romper seguridad, precisión ni consistencia editorial.