Архитектура Drupal RAG: что создавать самим, а чем управлять через сервис

Архитектура RAG для Drupal — это больше, чем чат-бот. Для нативной сборки обычно нужны извлечение контента, деление на фрагменты, эмбеддинги, векторный поиск, настройка Search API, LLM, цитаты, проверки доступа, задания обновления, интерфейс и эксплуатация. Управляемый сервис для публичного сайта выносит несколько слоёв за пределы Drupal; правильная граница зависит от доступа к данным и от того, кто отвечает за сбои.

Michael Shamanoff Founder, Achla AI Для кого: владельцы, архитекторы и разработчики Drupal, оценивающие семантический поиск или ответы с источниками. Как подготовлено: по официальным страницам проектов Drupal и актуальным файлам продукта Achla, проверенным 3 августа 2026 года, с оригинальной матрицей ответственности и оценочной картой пилота. При подготовке использовался ИИ; существенные фактические утверждения сопоставлены с источниками в приложенном реестре. Зачем: инструкции по установке перечисляют компоненты, но принимающим решение также важно знать, кто эксплуатирует каждый слой, как он может отказать и какие требования исключают управляемую схему с публичным обходом сайта.

Архитектура Drupal RAG по слоям

У RAG два потока. Индексация превращает контент в доступные для поиска записи. Обработка запроса превращает вопрос в поиск, контекст, генерацию и проверяемые доказательства.

Поток индексации: от контента к доступным для поиска фрагментам

1. Выберите сущности, поля и режимы отображения Drupal с полезным исходным материалом.
2. Извлеките текст, сохранив идентификатор, язык, URL, метаданные доступа и сигналы обновления или удаления.
3. Разделите длинный контент на фрагменты с достаточным контекстом.
4. Создайте эмбеддинги и сохраните их в бэкенде с поддержкой векторов.
5. Обновляйте, заменяйте или удаляйте записи при изменениях контента Drupal.

Официальный проект AI Search связывает векторные эмбеддинги с Search API и описывает векторный бэкенд, чанкинг, пороги оценки, проверку доступа к сущности после запроса, гибридный поиск и интеграцию RAG. Это строительные блоки, а не готовая операционная модель.

Поток запроса: от вопроса к ответу с источниками

1. Преобразуйте или направьте вопрос в выбранный механизм поиска.
2. Получите фрагменты-кандидаты и примените пороги, фильтры или логику гибридного поиска.
3. Соберите контекст для LLM, не теряя идентификаторы источников и ограничения доступа.
4. Сформируйте ответ либо честный пустой результат.
5. Покажите цитаты и запишите достаточно данных, чтобы диагностировать поиск отдельно от генерации.

Храните найденные источники, сгенерированный текст и видимые посетителю цитаты как разные виды доказательств: релевантный материал можно плохо пересказать, а убедительный текст может опираться не на тот источник.

Что делает Search API — и чего он сам по себе не делает

Search API — расширяемая поисковая платформа Drupal. Она определяет индексы и работает с бэкендами, полями, обработчиками, Views, фильтрами и фасетами. Сама по себе она не выбирает модель эмбеддингов, не эксплуатирует любой бэкенд, не собирает промпт LLM, не генерирует ответ, не проектирует чат-интерфейс и не оценивает обоснованность.

На официальной странице также указана важная граница безопасности: Search API не обеспечивает универсальные ограничения доступа для всех сценариев. Владельцы сайта отвечают за то, чтобы индексировались и показывались только доступные материалы, хотя в экосистеме есть изменение node-access и дополнительные проверки.

Страница семантических результатов не обязана становиться чатом. Решите, нужны ли посетителям ранжированные результаты, ответ с цитатами, диалог или несколько интерфейсов.

Текущее состояние проектов Drupal должно влиять на оценку риска

Метки релизов и покрытие политикой безопасности меняются: обновите таблицу перед человеческим одобрением и перед внедрением. Эти данные наблюдались на официальных страницах Drupal.org 3 августа 2026 года.

Номер 1.0.x не заменяет покрытие безопасностью. Отдельно проверяйте зрелость, сопровождение, версии Drupal, зависимости от провайдеров и статус политики безопасности.

Самостоятельная сборка: компоненты под ответственностью вашей команды

Нативная Drupal-сборка сохраняет больше контроля рядом с Drupal, но создаёт больше эксплуатационных зон ответственности. Проект RAG Search показывает векторный индекс Search API, питающий сборку промпта и LLM, с необязательными точным и семантическим кэшами, ограничением частоты и повторной проверкой доступа перед выдачей кэшированных фрагментов. Исключение из политики безопасности остаётся существенным предупреждением.

Drupal as RAG демонстрирует Drupal 11, PostgreSQL с pgvector и Ollama на локальном или сетевом хосте. Наблюдаемый релиз был alpha и вне покрытия, поэтому это пример архитектуры, а не рекомендация.

Более широкий компромисс описан в материале корпоративный AI-поиск против DIY.

Управляемая схема: какие слои уходят за пределы Drupal

Управляемый путь для публичного сайта передаёт оператору обход, индексацию, поиск, вызовы модели, выдачу ответа и часть мониторинга. Drupal предоставляет публичные страницы и скрипт или коннектор. Стек внутри Drupal уменьшается, но сервис не знает нативно о полях, ревизиях, ролях и решениях доступа, если это явно не реализовано и не проверено.

Проверенные файлы Achla описывают коннектор Drupal 10/11 через Composer, матрицу проверки PHP 8.3 и автоматические обновления, доступные по состоянию на 16 июля 2026 года. Сервис обходит и индексирует публичный сайт, а виджет показывает ответы со ссылками на источники. Есть варианты размещения bubble, inline и attach.

Achla не является бэкендом Search API. Это отдельная управляемая схема публичного обхода и виджета. Её нельзя представлять как решение для приватного или аутентифицированного контента Drupal, ролевого поиска, построчных разрешений или транзакционных действий. Граница описана в настройке управляемого поиска без разработчика.

Создавать или передать сервису? Исходите из требований

Учитывайте инфраструктуру, обновления, проверку безопасности, ключи провайдеров, наблюдаемость, контент-операции, инциденты и доказательство работы ограничений доступа, а не только стоимость лицензии.

Защитите доступ, цитаты и обновление

Приватный контент — жёсткое архитектурное разветвление. Search API не решает автоматически все ограничения. AI Search описывает проверки доступа после запроса; RAG Search — ролевые ключи кэша и повторную проверку доступа к источнику. Эти механизмы конкретных модулей всё равно нужно тестировать с реальными ролями, неопубликованным контентом, сменой разрешений и кэшированными ответами.

Проект AI RAG Search Chat показывает, что production-поверхность шире поиска: страницы поиска и чата, сессии, разрешения, rate limiting, провайдеры и связанные источники. Наблюдаемый релиз 1.0.7 был вне покрытия политики безопасности Drupal.

Сохраняйте URL и идентификаторы источников при чанкинге, проверяйте поддержку ответа каждой цитатой, определите честный промах и тестируйте распространение изменений и удалений. Ответ с источниками проще проверять, но поиск и цитаты не исключают ошибку модели. Используйте руководство как оценить доверие к AI-поиску.

Используйте воспроизводимую оценочную карту пилота

Соберите набор из реальных задач. Двадцать–тридцать типичных вопросов — метод планирования, а не бенчмарк или обещанный порог.

1. Запишите вопрос, ожидаемую страницу-источник, класс контента/доступа и допустимый ответ «не найдено».
2. Добавьте точные термины, перефразы, конфликтующие страницы, устаревший или удалённый контент и вопрос без ответа.
3. Для теста приватного нативного решения используйте аккаунты разных ролей; любой показ недоступного источника означает провал.
4. Записывайте найденные источники отдельно от текста генерации и видимых цитат.
5. Проверьте обновление индекса после изменения и удаления, затем повторите с учётом кэшей.
6. Добавьте проверки клавиатуры, мобильного режима, сбоя, пустого результата и fallback интерфейса.
7. Отнесите каждый сбой к загрузке, поиску, генерации, цитатам/UI, доступу или эксплуатации и назначьте владельца для каждой архитектуры.

Пилот провален при раскрытии закрытого контента, выдуманных источниках, неработающих цитатах, отсутствии честного ответа о нехватке данных или сохранении удалённого контента дольше заявленного окна обновления. Не придумывайте универсальную точность. Таблица доказательств RAG разделяет утверждение, источник, ожидаемое и наблюдаемое поведение.

Типичные архитектурные ошибки

• Считать LLM механизмом поиска вместо измерения найденных доказательств.
• Индексировать приватные поля без сохранения и тестирования правил доступа.
• Терять URL, язык, ревизию или идентификатор сущности при чанкинге.
• Тестировать добавления, но не изменения, удаления, инвалидацию кэша и честные промахи.
• Называть версию безопасной из-за отсутствия alpha, игнорируя покрытие рекомендациями.
• Называть публичный краулер бэкендом Search API или интеграцией приватного контента.
• Сравнивать цену лицензии без инфраструктуры и ответственности за инциденты.

Практический следующий шаг для публичного Drupal-сайта

Прототипируйте DIY, если критичны поля и разрешения Drupal, контроль провайдера и действующая эксплуатация Search API. Оценивайте управляемый публичный поиск, если источник намеренно публичен и команда хочет передать слои RAG другому оператору.

Если нужны ответы с цитатами по публичным страницам и документам Drupal без эксплуатации RAG внутри Drupal, оцените настройку Achla для Drupal. Achla не является бэкендом Search API и не предназначена для описанного выше приватного контента.

Вопросы команд Drupal

Нужен ли мне Search API?

Для нативного маршрута на модулях Search API — да. Отдельный управляемый сервис публичного обхода использует собственный индекс. Это разные архитектуры; коннектор или виджет не превращает управляемый индекс в бэкенд Search API.

Всегда ли нужна векторная база данных?

Не для любого поиска. Ключевой или фасетный поиск может работать на других бэкендах. AI Search использует векторные бэкенды для семантического поиска, а управляемый сервис может скрывать инфраструктуру за своей границей.

Может ли семантический поиск работать без чата?

Да. Он может вернуть ранжированные результаты. Добавляйте генерацию, только когда письменный ответ полезен, источники сохраняются, честные промахи обрабатываются, а текст тестируется отдельно от поиска.

Что насчёт приватного контента?

Учитывайте контроль доступа с самого начала. Нативная схема может сохранять разрешения Drupal, если полностью проверены индексация, поиск, кэш и показ. Путь Achla в этой статье ограничен публичным контентом, доступным краулеру.

Как сравнить пилоты?

Используйте один набор вопросов, ожиданий по источникам, сценариев доступа, тестов обновления, проверок цитат, условий интерфейса и категорий сбоев. Сравнивайте доказательства и ответственность, а не выбранное поставщиком демо или неподтверждённый общий балл.

Общая иллюстрация

Выбор архитектуры RAG распределяет извлечение, поиск, генерацию, цитирование и эксплуатацию между разными владельцами.

*Выбор архитектуры RAG распределяет извлечение, поиск, генерацию, цитирование и эксплуатацию между разными владельцами.*