Arquitectura RAG para Drupal: qué desarrollar y qué delegar a un servicio gestionado

Una arquitectura RAG para Drupal es mucho más que un chatbot. Una solución nativa suele requerir extracción de contenido, división en fragmentos, embeddings, recuperación vectorial, configuración de Search API, un LLM, citas, comprobaciones de acceso, tareas de actualización, una interfaz y operaciones. Un servicio gestionado para sitios públicos desplaza varias capas fuera de Drupal; el límite adecuado depende del acceso a los datos y de quién se responsabiliza de los fallos.

Michael Shamanoff Founder, Achla AI Para quién: propietarios, arquitectos e implementadores de Drupal que evalúan la búsqueda semántica o las respuestas con fuentes citadas. Cómo se preparó: a partir de páginas oficiales de proyectos Drupal y archivos actuales del producto Achla revisados el 3 de agosto de 2026, junto con una matriz de responsabilidades y una ficha de evaluación del piloto originales. Se utilizó IA como apoyo para redactar; las afirmaciones factuales relevantes están vinculadas a sus fuentes en el registro adjunto. Por qué: las guías de instalación enumeran componentes, pero quienes toman decisiones también necesitan saber quién opera cada capa, cómo puede fallar y qué requisitos descartan una vía gestionada basada en el rastreo público.

La arquitectura RAG para Drupal, capa por capa

RAG tiene dos flujos. La indexación convierte el contenido en registros recuperables. El flujo de consulta convierte una pregunta en recuperación, contexto, generación y pruebas que se pueden inspeccionar.

Flujo de indexación: del contenido a fragmentos recuperables

1. Selecciona las entidades, los campos y los modos de visualización de Drupal que contienen material de origen útil.
2. Extrae el texto conservando identidad, idioma, URL, metadatos de acceso y señales de actualización o eliminación.
3. Divide el contenido largo en fragmentos que mantengan suficiente contexto para conservar su significado.
4. Genera embeddings y guárdalos en un backend compatible con vectores.
5. Actualiza, sustituye o elimina los registros cuando cambie el contenido de Drupal.

El proyecto oficial AI Search integra embeddings vectoriales con Search API y documenta un backend vectorial, fragmentación, umbrales de puntuación, comprobaciones de acceso a entidades posteriores a la consulta, búsqueda híbrida e integración RAG. Son componentes básicos, no un modelo operativo completo.

Flujo de consulta: de la pregunta a la respuesta con citas

1. Convierte o dirige la pregunta hacia el método de recuperación seleccionado.
2. Recupera los fragmentos candidatos y aplica umbrales, filtros o lógica de búsqueda híbrida.
3. Reúne el contexto para el LLM sin perder la identidad de la fuente ni las restricciones de acceso.
4. Genera una respuesta o un resultado vacío honesto.
5. Muestra citas y registra suficientes pruebas para diagnosticar la recuperación por separado de la generación.

Mantén las fuentes recuperadas, el texto generado y las citas visibles para el visitante como pruebas distintas: una recuperación relevante puede resumirse mal, mientras que una redacción fluida puede basarse en la fuente equivocada.

Qué hace Search API y qué no hace por sí solo

Search API es el marco de búsqueda extensible de Drupal. Define índices y funciona con backends, campos, procesadores, Views, filtros y facetas. Por sí solo no elige un modelo de embedding, no opera todos los backends, no compone el prompt de un LLM, no genera respuestas, no diseña una interfaz de chat ni evalúa el arraigo en las fuentes.

Su página oficial también señala un límite de seguridad importante: Search API no puede proporcionar restricciones de acceso genéricas para todos los casos de uso. Los propietarios del sitio siguen siendo responsables de garantizar que solo se indexen o muestren elementos accesibles, aunque en partes del ecosistema haya alteraciones de node-access y comprobaciones adicionales.

Una página de resultados semánticos no tiene por qué convertirse en un chat. Decide si los visitantes necesitan resultados semánticos ordenados, una respuesta con citas, una conversación o varias superficies.

El estado actual de los proyectos Drupal debe orientar la decisión de riesgo

Las etiquetas de las versiones y la cobertura de seguridad cambian. Actualiza esta tabla periódicamente y de nuevo antes de tomar cualquier decisión de implementación. Los siguientes datos se observaron en las páginas oficiales de Drupal.org el 3 de agosto de 2026.

Un número 1.0.x no sustituye la cobertura de seguridad. Evalúa por separado la madurez, el mantenimiento, las versiones de Drupal, las dependencias de proveedores y el estado de la política de seguridad.

Vía de desarrollo propio: los componentes que debe gestionar tu equipo

Una solución nativa de Drupal mantiene más control cerca de Drupal, pero también crea más responsables operativos. El proyecto RAG Search muestra un índice vectorial de Search API que alimenta la composición del prompt y un LLM, con cachés exactas y semánticas opcionales, limitación de frecuencia y nuevas comprobaciones de acceso antes de servir fragmentos almacenados. Su exclusión de la política de seguridad sigue siendo una advertencia importante.

Drupal as RAG ilustra otra vía que utiliza Drupal 11, PostgreSQL con pgvector y Ollama en un host local o de red. La versión observada era alpha y estaba fuera de cobertura, así que es un ejemplo de arquitectura, no una recomendación.

La compensación más amplia se aborda en búsqueda empresarial con IA frente al desarrollo propio.

Vía gestionada: qué capas se trasladan fuera de Drupal

Una vía gestionada para un sitio público transfiere el rastreo, la indexación, la recuperación, las llamadas al modelo, la entrega de respuestas y parte de la monitorización al operador del servicio. Drupal aporta páginas públicas y un script o conector. La pila dentro de Drupal se reduce, pero el servicio no conoce de forma nativa los campos, revisiones, roles y decisiones de acceso de Drupal salvo que se implementen y verifiquen expresamente.

Los archivos de producto Achla inspeccionados describen un conector para Drupal 10/11 distribuido mediante Composer, una matriz de validación para PHP 8.3 y actualizaciones automáticas marcadas como disponibles en la última revisión del 16 de julio de 2026. El servicio gestionado rastrea e indexa el sitio público y muestra respuestas vinculadas a las fuentes mediante un widget. El widget admite los modos de colocación bubble, inline y attach.

Achla no es un backend de Search API. Es una vía distinta de rastreo público y widget gestionados. No debe presentarse como solución para contenido Drupal privado o autenticado, recuperación consciente de roles, permisos a nivel de fila ni acciones transaccionales en Drupal. Consulta la configuración gestionada sin desarrollador para entender este límite operativo.

¿Desarrollar o gestionar? Decide según los requisitos, no la moda

Incluye infraestructura, actualizaciones, revisión de seguridad, claves de proveedores, observabilidad, operaciones de contenido, respuesta a incidentes y pruebas de que funcionan las restricciones de acceso, no solo el coste de la licencia.

Proteger el acceso, las citas y el comportamiento de actualización

El contenido privado es una bifurcación arquitectónica estricta. El marco genérico Search API no resuelve automáticamente todas las restricciones. AI Search documenta comprobaciones de acceso a entidades posteriores a la consulta; RAG Search documenta claves de caché asociadas a roles y nuevas comprobaciones de acceso a la fuente. Estos mecanismos propios de cada módulo deben probarse igualmente con roles reales, contenido no publicado, permisos modificados y respuestas almacenadas.

El proyecto AI RAG Search Chat muestra por qué la superficie de producción es más amplia que la recuperación: añade páginas de búsqueda y chat, sesiones, permisos, limitación de frecuencia, proveedores y fuentes vinculadas. La versión 1.0.7 observada estaba fuera de la cobertura de avisos de seguridad de Drupal.

En cualquier arquitectura, conserva las URL y los identificadores de fuente durante la fragmentación, verifica que cada cita respalde la respuesta, define un fallo honesto y prueba la propagación de actualizaciones y eliminaciones. Una respuesta vinculada a fuentes es más fácil de inspeccionar, pero la recuperación y las citas no eliminan el error del modelo. Utiliza esta guía para evaluar si una búsqueda con IA es fiable.

Utiliza una ficha de evaluación reproducible para el piloto

Crea el conjunto de evaluación a partir de tareas reales. Entre veinte y treinta preguntas representativas son un método de planificación, no un benchmark ni un umbral prometido.

1. Registra la pregunta, la página fuente esperada, la clase de contenido/acceso y un resultado aceptable de «no encontrado».
2. Incluye términos exactos, paráfrasis, páginas contradictorias, contenido obsoleto o eliminado y una pregunta cuya respuesta no exista.
3. Para probar contenido privado en una solución nativa de Drupal, usa cuentas con distintos roles y considera fallo cualquier exposición de una fuente inaccesible.
4. Registra las fuentes recuperadas por separado del texto generado y de las citas visibles para el visitante.
5. Prueba la actualización del índice después de editar y eliminar, y repite cuando puedan intervenir cachés pertinentes.
6. Añade pruebas de teclado, móvil, interrupción, resultado vacío y alternativa para la interfaz elegida.
7. Asigna cada fallo a ingesta, recuperación, generación, cita/interfaz, acceso u operaciones, y señala quién lo corrige en cada arquitectura.

El piloto falla si expone contenido restringido, inventa fuentes, presenta enlaces de cita rotos, no reconoce que falta una respuesta o mantiene contenido eliminado más allá del intervalo de actualización documentado. No inventes una puntuación universal de exactitud. La ficha de pruebas de RAG permite separar afirmación, fuente, comportamiento esperado y resultado observado.

Errores habituales de arquitectura

• Tratar un LLM como si fuera el sistema de recuperación en vez de medir las pruebas recuperadas.
• Indexar campos o contenido privado sin conservar y probar las reglas de acceso.
• Perder la URL, el idioma, la revisión o la identidad de la entidad durante la fragmentación.
• Probar las incorporaciones, pero no las ediciones, eliminaciones, invalidación de caché y fallos honestos.
• Calificar una versión como «segura» porque no tiene sufijo alpha e ignorar la cobertura de avisos.
• Llamar backend de Search API o integración de contenido privado a un rastreador público.
• Comparar el precio de la licencia omitiendo la infraestructura y la responsabilidad sobre incidentes.

Un siguiente paso práctico para un sitio Drupal público

Crea un prototipo propio cuando los campos y permisos nativos de Drupal, el control del proveedor y una operación de Search API existente sean requisitos centrales. Evalúa la búsqueda gestionada para un sitio público cuando la fuente sea pública deliberadamente y el equipo quiera que otro operador se responsabilice de las capas del servicio RAG.

Si necesitas respuestas con citas sobre páginas y documentos Drupal públicos sin operar la pila RAG dentro de Drupal, evalúa la configuración de Drupal de Achla. Achla no es un backend de Search API ni la vía para contenido privado descrita anteriormente.

Preguntas que plantean los equipos Drupal

¿Necesito Search API?

Para una vía nativa de Drupal basada en módulos Search API, sí. Un servicio gestionado independiente que rastrea contenido público puede utilizar su propio índice. Son arquitecturas diferentes; un conector o widget no convierte el índice gestionado en un backend de Search API.

¿Necesito siempre una base de datos vectorial?

No para todas las experiencias de búsqueda. La búsqueda por palabras clave o facetas puede utilizar otros backends. El módulo oficial AI Search usa backends vectoriales para la recuperación semántica, mientras que un servicio gestionado puede ocultar su infraestructura de recuperación tras el límite del servicio.

¿Puede funcionar la búsqueda semántica sin chat?

Sí. La recuperación semántica puede devolver resultados ordenados mediante una interfaz de búsqueda. Añade generación solo cuando una respuesta redactada sea útil para la tarea, puedas conservar las fuentes, gestionar con honestidad los fallos y probar la redacción por separado de la recuperación.

¿Qué ocurre con el contenido privado?

Incluye los requisitos de control de acceso en la decisión arquitectónica desde el principio. Un diseño nativo puede conservar los permisos de Drupal si se prueba la ruta completa de indexación, recuperación, caché y visualización. La vía de Achla descrita en este artículo se limita a contenido público rastreable.

¿Cómo comparo los pilotos?

Usa el mismo conjunto de preguntas, expectativas de fuentes, casos de acceso, pruebas de actualización, comprobaciones de citas, condiciones de interfaz y categorías de fallo. Compara pruebas y responsabilidades, no una demostración elegida por el proveedor ni una puntuación universal sin respaldo.

Ilustración compartida

Una decisión de arquitectura RAG asigna extracción, recuperación, generación, citas y operaciones a responsables distintos.

*Una decisión de arquitectura RAG asigna extracción, recuperación, generación, citas y operaciones a responsables distintos.*