Hay una palabra que aparece en casi todos los roadmaps de producto que nos llegan este año: RAG. Retrieval-Augmented Generation. Se pronuncia con la misma confianza con la que antes se decía "blockchain" o "microservicios". Y eso, precisamente, es la señal de que algo va a salir mal.
RAG no es una solución. Es una familia de arquitecturas de recuperación de información que tienen perfiles de coste, latencia, complejidad y precisión completamente distintos. Elegir "RAG" sin más es como decir que vas a construir un sistema de transporte sin especificar si necesitas una bicicleta, un camión de reparto o una línea de metro. Todas son válidas. Ninguna sirve para todo.
El problema real no es técnico: es de diagnóstico. Muchos equipos adoptan RAG porque leyeron que funciona, no porque hayan analizado qué tarea concreta están resolviendo y qué tipo de recuperación esa tarea exige. El resultado predecible: un sistema que recupera mal, genera respuestas mediocres y deja al usuario con menos confianza en el producto que antes de la "mejora".
- Existen al menos cinco variantes arquitectónicas de RAG con casos de uso claramente diferenciados.
- La elección incorrecta no solo afecta a la calidad de las respuestas: impacta directamente en costes de infraestructura y en la percepción de velocidad del producto.
- El diagnóstico correcto empieza por la tarea del usuario, no por la arquitectura disponible.
El Problema: RAG como Etiqueta Vacía
Cuando un cliente nos dice "queremos implementar RAG", la primera pregunta que hacemos no es sobre embeddings ni sobre bases de datos vectoriales. Es: ¿qué tarea concreta tiene que resolver tu usuario que hoy no puede resolver bien? Esa pregunta incomoda, porque obliga a salir del territorio técnico y entrar en el territorio del propósito.
RAG nació como solución a un problema específico: los modelos de lenguaje tienen un conocimiento congelado en el tiempo (su fecha de corte de entrenamiento) y no pueden acceder a información privada o actualizada sin ser reentrenados. La recuperación externa resuelve ambas limitaciones. Hasta aquí, todo claro.
El error empieza cuando RAG se convierte en el destino en vez de en el camino. Equipos que implementan RAG básico (un índice vectorial plano, recuperación por similitud coseno, contexto inyectado al prompt) para casos que requieren razonamiento sobre múltiples documentos relacionados, jerarquías de conceptos o síntesis de información contradictoria. El resultado es un modelo que recupera los fragmentos "más parecidos semánticamente" a la pregunta, pero no los fragmentos que realmente responden la pregunta.
Recuperar el fragmento más similar a una pregunta no es lo mismo que recuperar el fragmento que mejor la responde. Esa distinción, ignorada, arruina el 80% de las implementaciones de RAG que vemos.
Y aquí conecta algo que ya hemos señalado en otro contexto: el peligro silencioso de delegar el diagnóstico a la herramienta. RAG mal configurado no falla de forma ruidosa; falla con confianza. El modelo genera una respuesta coherente, bien redactada, apoyada en un fragmento que no era el correcto. El usuario no sabe que la respuesta es incorrecta. El equipo tampoco, hasta que alguien lo descubre de la peor manera.
Arquitectura: Las Cinco Variantes que Importan
No existe "RAG" en singular. Existe un espacio de decisiones de diseño que produce variantes con perfiles muy distintos. Veamos las cinco que aparecen con más frecuencia en casos de producto real y cuándo tiene sentido cada una.
RAG Denso (Vector Search)
Es el punto de partida. Los documentos se fragmentan, se convierten en embeddings y se almacenan en una base de datos vectorial (Pinecone, Weaviate, pgvector). En tiempo de consulta, la pregunta del usuario se embede y se buscan los fragmentos más cercanos en el espacio vectorial.
Funciona bien cuando: el corpus es relativamente homogéneo, las preguntas son semánticamente directas y el usuario busca información puntual ("¿cuál es la política de devoluciones?"). Es rápido, barato de mantener y predecible en comportamiento. Para un chatbot de soporte de ecommerce con una base de conocimiento bien estructurada, esta arquitectura es suficiente y no necesitas nada más complejo.
Falla cuando: el corpus tiene documentos con estructura jerárquica fuerte (normativas legales, contratos, manuales técnicos con secciones interdependientes), cuando las preguntas requieren síntesis de múltiples fuentes o cuando el vocabulario del usuario no coincide con el vocabulario del corpus.
RAG Híbrido (Denso + Sparse)
Combina búsqueda vectorial semántica con búsqueda léxica clásica tipo BM25. El sistema puntúa y fusiona ambos rankings. Esto resuelve el problema de vocabulario: si el usuario escribe un término técnico exacto que el embedding no captura bien por frecuencia baja en el entrenamiento, la búsqueda léxica lo encuentra.
Es el upgrade natural del RAG denso para la mayoría de productos B2B con documentación técnica. El coste añadido es moderado y la ganancia en recall es significativa. Un caso frecuente: sistemas de consulta sobre documentación de software donde los nombres de funciones, parámetros o errores son términos muy específicos que los modelos de embedding no siempre capturan bien.
RAG con Reranking
Añade una fase intermedia: el sistema recupera un conjunto amplio de candidatos (top-50, por ejemplo) y luego un modelo de reranking —más pequeño y especializado que el LLM principal— los reordena por relevancia real para la pregunta concreta. Models como Cohere Rerank o los modelos de cross-encoding de Sentence Transformers hacen este trabajo.
El reranking desacopla la fase de recuperación (optimizada para cobertura, recall alto) de la fase de precisión (optimizada para que los 3-5 fragmentos que llegan al LLM sean realmente los mejores). Para casos donde el error de recuperación es caro —sistemas médicos, legales, financieros— este paso es casi obligatorio. El coste es latencia adicional (50-200ms) y una capa más de infraestructura.
RAG Jerárquico (HippoRAG / Parent-Child)
Los documentos se indexan en dos niveles: fragmentos pequeños y precisos para recuperación, pero enlazados a sus fragmentos padre (secciones completas, documentos enteros) para construcción del contexto. Cuando se recupera un fragmento hijo, se incluye también su contexto padre para que el LLM entienda el marco en que aparece ese dato.
Este es el patrón correcto para corpus legales, normativos o técnicos donde un dato aislado sin su contexto circundante puede interpretarse de forma incorrecta o incompleta. También es adecuado para documentación de producto donde un paso de un proceso solo tiene sentido dentro de la secuencia completa.
RAG Agéntico (Multi-hop / Graph RAG)
La versión más compleja. El sistema no hace una única recuperación: razona sobre qué necesita recuperar, ejecuta múltiples búsquedas encadenadas, evalúa la suficiencia de la información recopilada y decide si necesita más contexto antes de generar la respuesta final. Algunas implementaciones añaden un grafo de conocimiento sobre el corpus vectorial (Microsoft GraphRAG es el ejemplo más citado).
Funciona para preguntas que requieren razonamiento multi-paso sobre corpus complejos: análisis de contratos cruzados, investigación sobre normativa regulatoria con múltiples excepciones interdependientes, o sistemas de inteligencia competitiva. El coste es alto: latencia de segundos, múltiples llamadas al LLM, infraestructura más sofisticada. Justificado solo cuando la tarea lo requiere y cuando el usuario tolera o incluso espera una respuesta que tarda.
Decisión: El Marco de Selección que Usamos
La pregunta que ordena toda la decisión es siempre la misma: ¿qué penalización tiene un error de recuperación en este sistema? Cuanto más cara es la equivocación —en términos de confianza del usuario, consecuencias regulatorias o decisiones de negocio basadas en la respuesta—, más sofisticada debe ser la arquitectura de recuperación.
Desde ahí, proponemos tres vectores de evaluación antes de comprometerse con una arquitectura:
Naturaleza del corpus. ¿Es homogéneo o heterogéneo? ¿Tiene estructura jerárquica fuerte (normativas, contratos) o es relativamente plano (artículos de blog, FAQs)? ¿El vocabulario del corpus coincide con el vocabulario del usuario o hay brecha terminológica? Un corpus legal en español de España tiene particularidades léxicas que un modelo de embedding entrenado mayoritariamente en inglés no captura bien. Eso ya apunta hacia RAG híbrido como mínimo.
Tipología de consultas. ¿Son preguntas directas de recuperación puntual ("¿cuánto vale X?") o preguntas analíticas que requieren síntesis ("¿cuáles son las implicaciones del artículo 23 en los contratos firmados antes de 2022?")? Las segundas necesitan multi-hop o al menos reranking. Las primeras, no.
Perfil de coste-latencia aceptable. Un asistente de atención al cliente tiene un SLA de respuesta de 1-2 segundos. Un sistema de análisis de contratos para un departamento legal puede tolerar 15 segundos si la respuesta es fiable. Esa diferencia determina qué arquitecturas están disponibles en la práctica.
La arquitectura de recuperación correcta no es la más sofisticada. Es la mínima que cubre la penalización máxima que tu caso puede tolerar.
Hay un factor adicional que suele ignorarse en las discusiones técnicas: la latencia percibida por el usuario en sistemas RAG complejos puede arruinar la experiencia incluso cuando la respuesta es correcta. RAG agéntico con cuatro llamadas encadenadas puede tardar 8-12 segundos. Si el usuario no entiende que ese tiempo es necesario porque el sistema está "razonando", percibirá el producto como lento y poco confiable. El diseño de la experiencia de espera es parte de la arquitectura, no un afterthought.
Fine-tuning vs. RAG: La Pregunta que Nadie Quiere Responder
Antes de comprometerse con cualquier variante de RAG, conviene hacerse una pregunta incómoda: ¿realmente necesito RAG, o lo que necesito es un modelo fine-tuneado sobre mi dominio?
RAG es la respuesta correcta cuando el conocimiento es dinámico (cambia frecuentemente), cuando el corpus es muy grande para caber en el contexto, o cuando necesitas citabilidad (poder señalar de dónde viene cada respuesta). Fine-tuning es la respuesta correcta cuando el modelo necesita aprender un estilo de razonamiento, un vocabulario muy específico del dominio, o un formato de respuesta consistente que no se puede lograr solo con instrucciones en el prompt.
El Caso del Fine-tuning sobre Corpus Pequeño
Los titulares recientes sobre resultados sólidos al fine-tunear modelos locales pequeños (Qwen 3 en sus variantes más compactas, por ejemplo) para clasificación y categorización apuntan a algo que llevamos defendiendo un tiempo: para tareas acotadas y predecibles, un modelo pequeño bien entrenado supera en coste y latencia a un modelo grande con RAG complejo. Y se ejecuta on-premise, sin dependencia de APIs externas, sin coste por token, con soberanía total sobre los datos.
La decisión entre fine-tuning y RAG no es técnica en su raíz: es funcional. ¿Qué necesita saber el sistema que no puede saber de otra forma? Si la respuesta es "información actualizada o muy voluminosa", RAG. Si la respuesta es "cómo razonar sobre mi dominio específico", fine-tuning. Muchos casos de uso reales combinan ambos: un modelo fine-tuneado para el estilo de razonamiento del dominio, con RAG para el acceso a información actualizada.
Esta tensión entre especialización y generalidad conecta directamente con cómo los productos SaaS están replanteando su arquitectura de IA desde la raíz: no añadiendo capas sobre modelos generales, sino construyendo capas especializadas que aportan ventaja real en un nicho concreto.
Conclusión: Diagnostica Primero, Arquitectura Después
RAG bien implementado puede transformar la utilidad de un producto. RAG mal elegido —la variante incorrecta para la tarea incorrecta— añade complejidad, coste y latencia sin mejorar la experiencia del usuario. Y lo peor: falla silenciosamente, generando respuestas plausibles pero incorrectas que erosionan la confianza del usuario más despacio pero más profundamente que un error obvio.
El camino correcto empieza por la tarea. ¿Qué tiene que poder hacer el usuario que hoy no puede hacer bien? ¿Cuánto cuesta equivocarse? ¿Con qué latencia puede vivir? ¿El corpus cambia frecuentemente o es estable? Esas cuatro preguntas bastan para descartar tres de las cinco variantes y centrar el diseño en las dos que realmente compiten.
Si estás en ese punto de decisión —arquitectura de RAG, fine-tuning, combinación de ambos— y necesitas un diagnóstico sin compromiso previo con ninguna tecnología, eso es exactamente lo que hacemos en Room 714. La arquitectura correcta no es la más cara ni la más moderna. Es la que resuelve tu caso con la mínima complejidad necesaria.
