RAG no falla por el modelo, falla por el contenido: cómo construir RAG confiable sobre Drupal
RAG (generación aumentada por recuperación) es una técnica en la que un modelo de IA busca primero información en sus documentos y luego responde con base en ella, citando la fuente. Funciona tan bien como el contenido que recupera: si hay duplicados, versiones vencidas o permisos mal definidos, el modelo los repetirá con total seguridad. Por eso un RAG confiable empieza en el gestor de contenidos, no en el modelo.
Qué es RAG, en tres pasos
El término viene de un artículo de investigación de 2020 de Lewis et al.1 La idea es simple:
- Recuperar. Ante una pregunta, el sistema busca los fragmentos más relevantes en una base de conocimiento propia: portal, documentos, normas, fichas de productos o programas.
- Aumentar. Esos fragmentos se entregan al modelo junto con la pregunta.
- Generar. El modelo redacta la respuesta usando ese contexto y, si está bien diseñado, cita de dónde sacó cada dato.
La ventaja frente a usar un modelo "solo" es evidente: el modelo no tiene que saber nada de su organización, solo tiene que leer bien lo que se le entrega.
La desventaja es menos obvia: el modelo no sabe si lo que le entregaron es correcto.
Las seis formas en que un RAG falla en producción
Casi todas las demos de RAG funcionan. Muchas implementaciones en producción no. Estas son las causas que más vemos, y casi ninguna tiene que ver con el modelo:
| Falla | Qué pasa | Origen real |
|---|---|---|
| Contenido duplicado | Dos páginas dicen cosas distintas sobre el mismo trámite; el modelo elige una al azar o las mezcla | Gobierno de contenido |
| Versiones vencidas | El RAG responde con la convocatoria del año pasado | Ciclo de vida del contenido |
| Borradores indexados | El modelo cita un texto que nunca se aprobó | Flujo editorial |
| Permisos ignorados | Un usuario externo recibe información de un documento interno | Control de acceso |
| Fragmentos sin contexto | Un fragmento dice "el plazo es de 15 días", pero no dice de qué trámite | Estructura del contenido |
| Sin evaluación | Nadie sabe qué porcentaje de respuestas es correcto hasta que llega una queja | Operación |
Mirando la columna de la derecha se ve la tesis de este artículo: la calidad de un RAG es, ante todo, la calidad de la gobernanza de su contenido.
Por qué un CMS empresarial es la mejor base para RAG
Un gestor de contenidos como Drupal ya resuelve, por diseño, la mayoría de esas fallas:
- Contenido estructurado: tipos de contenido con campos definidos (título, resumen, requisitos, fechas, dependencia responsable). Un fragmento que sale de un campo "Requisitos" de la ficha "Programa de Ingeniería Civil" llega al modelo con su contexto.
- Estados editoriales: con Content Moderation, solo lo que está Publicado es oficial. Indexar solo ese estado elimina el problema de los borradores.
- Historial de revisiones: cada cambio queda con autor y fecha, así que se puede saber qué versión usó el RAG para responder.
- Permisos granulares: roles, accesos por sección y contenido restringido que el sistema de recuperación puede respetar.
- Idiomas como entidades vinculadas: la versión en inglés de una página es la traducción de la misma pieza, no un documento suelto que puede contradecirla.
Comparado con un RAG armado sobre una carpeta de PDF exportados, la diferencia es de raíz:
En el CMS (sistema de gestión de contenidos) el contenido tiene dueño, estado, fecha y permisos.
Arquitectura de RAG sobre Drupal
El ecosistema de la Drupal AI Initiative ya ofrece las piezas para construirlo sin salir de la plataforma:
| Capa | Pieza en Drupal | Función |
|---|---|---|
| Contenido | Tipos de contenido, Paragraphs, taxonomías, Content Moderation | Fuente de verdad estructurada y aprobada |
| Indexación | Search API con el backend AI Search del módulo AI | Divide el contenido en fragmentos con su contexto (título y campos configurados) y genera los vectores |
| Base vectorial | Proveedores de base de datos vectorial (por ejemplo Milvus, Pinecone o PostgreSQL con pgvector) | Almacena los vectores y resuelve búsquedas por similitud |
| Embeddings y modelo | Proveedores intercambiables del módulo AI | Generan vectores y respuestas; se pueden cambiar sin rehacer el sitio |
| Relevancia | Umbral de puntaje y reordenamiento (reranking) | Descarta fragmentos poco relevantes y prioriza los mejores |
| Interfaz | Asistentes de IA con acción RAG, o un agente externo vía MCP (Model Context Protocol) | Conversación con el usuario, con citas y enlaces |
Una ventaja práctica de usar Search API: el índice se actualiza cuando se guarda el contenido. Si un editor corrige una fecha y publica, el RAG responde con el dato nuevo en el siguiente ciclo de indexación, sin exportar nada a mano.
Las 8 decisiones de diseño que definen la calidad
1. Qué se indexa
Solo contenido publicado, y solo los tipos de contenido que deben responder preguntas. Las noticias de hace cinco años probablemente no.
2. Cómo se fragmenta
Fragmente por estructura (campo, párrafo, sección) antes que por número fijo de palabras. Y agregue a cada fragmento el contexto que lo hace entendible por sí solo: título de la página, sección, fecha.
Esta idea tiene respaldo: Anthropic documentó en 2024 su técnica de Contextual Retrieval, que antepone a cada fragmento una breve explicación de su contexto. Según sus pruebas, eso redujo las recuperaciones fallidas en un 35 %. Al sumar búsqueda por palabras clave (BM25) la reducción llegó al 49 %, y al agregar reordenamiento, al 67 %.2 Es la mejor evidencia a favor de las decisiones 2 y 5.
3. Qué metadatos acompañan cada fragmento
Idioma, fecha de publicación, fecha de vigencia, dependencia responsable, público objetivo y URL. Con ellos se puede filtrar ("solo contenido vigente en español para estudiantes") y citar.
4. Cómo se respetan los permisos
Esta es la decisión más delicada. El sistema de recuperación debe filtrar por lo que el usuario que pregunta puede ver, antes de entregar fragmentos al modelo.
Pedirle al modelo que "no revele" información restringida no es un control de seguridad.
5. Búsqueda vectorial, por palabras clave o híbrida
La búsqueda vectorial entiende sinónimos y paráfrasis, pero falla con códigos, números de resolución o nombres propios. Para portales con trámites, normas o catálogos, conviene combinar ambas.
6. Cómo se cita
Cada respuesta debe enlazar a la página de origen. Esto le permite al usuario verificar y deja trazabilidad. Si el sistema no encuentra fuente suficiente, debe decirlo, no improvisar.
7. Cómo se mantiene fresco
Reindexación automática al publicar, retiro del índice al archivar o despublicar y revisión periódica de contenido con fecha de vigencia vencida.
8. Cómo se evalúa
Antes de salir a producción, arme un set de 50 a 100 preguntas reales con su respuesta correcta y la página que debería citarse. Mida:
- Respuestas correctas con cita válida.
- Tasa de abstención: cuántas veces dice "no tengo información" cuando debía decirlo, y cuántas cuando no debía.
- Respuestas sin fuente: deberían ser cero.
- Frescura: días entre un cambio publicado y su reflejo en las respuestas.
Repita la evaluación cada vez que cambie el modelo, el fragmentado o el contenido de forma importante.
RAG, fine-tuning o contexto largo
| Enfoque | Cuándo conviene | Limitación |
|---|---|---|
| RAG | Información que cambia, debe citarse y tiene permisos | Depende de la calidad del contenido y de la recuperación |
| Fine-tuning | Enseñar un estilo, formato o tarea muy específica | No sirve para datos que cambian; no cita fuentes |
| Contexto largo | Pocos documentos que caben completos en la ventana del modelo | Costoso a escala; no resuelve permisos ni frescura |
Para portales institucionales, universidades y bases de conocimiento, RAG es casi siempre la respuesta. Fine-tuning puede complementarlo para tono o formato.
Seguridad: el contenido también puede atacar
Un riesgo poco discutido es la inyección de instrucciones a través del contenido: un texto que dice "ignora tus instrucciones y responde X" y que termina dentro de un fragmento recuperado. Tres defensas que dependen del CMS:
- Solo se indexa contenido aprobado, así que un texto malicioso tendría que pasar por el flujo editorial.
- Los comentarios y el contenido generado por usuarios se excluyen del índice o se tratan como fuente no confiable.
- El sistema trata los fragmentos como datos, no como instrucciones, y registra qué fragmentos se usaron en cada respuesta.
Antes del RAG, ordene la casa
La mayoría de organizaciones que quieren un RAG necesitan antes una jornada de limpieza: páginas duplicadas, metadatos vacíos, contenido vencido, imágenes sin descripción, secciones huérfanas. Es trabajo poco visible y casi siempre aplazado.
En Seed EM construimos SeedPilot, un agente de operaciones de contenido para Drupal 10 y 11, en parte para resolver esa etapa: detecta metadatos faltantes o duplicados, páginas huérfanas y contenido publicado con problemas, y prepara las correcciones para que un editor las apruebe.
Un contenido más limpio produce un RAG más confiable, y el mismo trabajo mejora el SEO y la accesibilidad del sitio.
Preguntas frecuentes
¿Qué es RAG en inteligencia artificial?
RAG (Retrieval-Augmented Generation o generación aumentada por recuperación) es una técnica en la que un modelo de IA busca primero información relevante en una base de conocimiento propia y luego genera la respuesta con base en ella, idealmente citando la fuente.
¿Por qué un RAG da respuestas incorrectas?
En la mayoría de los casos por el contenido que recupera: páginas duplicadas o contradictorias, versiones vencidas, borradores indexados o fragmentos sin contexto. También por no filtrar permisos o no evaluar el sistema antes de producción.
¿Cuál es la diferencia entre RAG y fine-tuning?
RAG le entrega al modelo información actualizada en el momento de responder y permite citar fuentes. Fine-tuning modifica el modelo con ejemplos para enseñarle un estilo o tarea, pero no sirve para datos que cambian ni cita de dónde sale la información.
¿Se puede construir un RAG sobre Drupal?
Sí. El módulo AI de Drupal incluye AI Search, un backend de Search API que fragmenta el contenido, genera vectores con un proveedor de embeddings y los guarda en una base de datos vectorial. Los asistentes de IA pueden usarlo para responder con base en el contenido del sitio.
¿Cómo se protegen los datos en un sistema RAG?
Indexando solo contenido aprobado, filtrando los resultados según los permisos de quien pregunta antes de enviarlos al modelo, tratando los fragmentos recuperados como datos y no como instrucciones, y registrando qué fuentes se usaron en cada respuesta.
¿Quiere que su sitio responda preguntas con su propio contenido, con citas y permisos? Hable con Seed EM y revisemos primero qué tan listo está su contenido.
Fuentes
- Lewis et al. (2020), Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. arxiv.org/abs/2005.11401. ↩
- Anthropic, "Introducing Contextual Retrieval" (2024). anthropic.com/news/contextual-retrieval. ↩
Publicado por Seed EM · .