5 мин

1.7K

За последние годы большинство AI-проектов в компаниях стартуют одинаково: сначала делают чат-бота, затем добавляют агентов, автоматизируют отдельные процессы и ожидают роста эффективности.

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

Основная причина — отсутствие единого слоя знаний.

В проекте для ресторанной группы с 10+ заведениями и историей более 15 лет мы сознательно начали не с агентов и не с интерфейсов, а с построения корпоративной RAG-инфраструктуры. Этот слой стал основой всей последующей AI-архитектуры.

Почему AI без корпоративной памяти не работает

В большинстве компаний проблема не в отсутствии данных, а в их фрагментации.

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

Если подключить LLM к таким данным напрямую, возникают типовые эффекты:

• модель даёт разные ответы на одинаковые вопросы;

• информация противоречит сама себе;

• часть ответов устаревает;

• контекст бизнеса игнорируется;

• появляются «галлюцинации».

В результате AI становится нестабильным инструментом, который генерирует тексты, но не опирается на реальные стандарты компании.

Поэтому первым этапом была не автоматизация, а создание единого интеллектуального слоя.

Мы собрали более 1000 страниц документов, накопленных за 15 лет: меню, регламенты, техкарты, внутренние инструкции, обучающие материалы и гайды. После этого данные были очищены, структурированы, размечены и объединены в единую RAG-инфраструктуру.

Этот слой стал единым источником фактов для всех последующих AI-сервисов.

Что такое RAG в прикладной архитектуре

RAG (Retrieval-Augmented Generation) — это подход, при котором модель не генерирует ответ «из памяти», а сначала получает релевантные данные из корпоративной базы знаний и только затем формирует ответ.

В упрощённой схеме:

• модель отвечает за генерацию текста;

• RAG отвечает за достоверность.

Технически это реализуется через векторизацию документов и семантический поиск. Данные из корпоративных источников преобразуются в векторное представление и сохраняются в специализированном хранилище (например, Qdrant), а структурированные данные и служебная логика — в PostgreSQL.

При запросе система:

1. ищет релевантные фрагменты в базе знаний;

2. передаёт их модели;

3. формирует ответ на основе найденных данных.

Такой подход ограничивает произвольную генерацию и делает ответы привязанными к реальным документам компании.

Это критично для корпоративной среды, где важно контролировать, какие данные использует AI и как они обновляются.

Интеграция с Notion как источником знаний

В проекте корпоративная память была связана с Notion.

Это позволило оставить для заказчика привычную среду работы с документами. Менеджеры продолжают редактировать материалы в Notion, а система автоматически синхронизирует изменения с RAG-слоем.

После обновления документа:

• данные переобрабатываются;

• обновляются векторные представления;

• становятся доступны всем AI-сервисам без участия разработчиков.

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

Архитектура: от контента к AI-продуктам

RAG-инфраструктура в проекте построена как многоуровневая система.

Нижний слой — корпоративный контент: документы, регламенты, меню, инструкции (Notion).

Следующий слой — обработка и синхронизация: очистка, разметка, обновления.

Далее — слой хранения:

• Qdrant — векторное хранилище;

• PostgreSQL — структурированные данные и служебная логика.

Верхний слой — AI-продукты:

• Telegram-интерфейсы;

• CRM;

• веб-интерфейсы;

• внутренние сервисы;

• потенциальные интеграции с кассовыми системами.

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

Что можно построить на единой RAG-базе

После появления корпоративной памяти AI перестаёт быть точечным инструментом и становится платформой.

В рамках проекта на этом слое можно запускать:

• AI-ассистента управляющего (ответы по стандартам и регламентам);

• AI-метрдотеля (меню, рекомендации, бронирования);

• AI-онбординг сотрудников (обучение на базе внутренних данных);

• автоматизацию создания документов, чек-листов и инструкций.

Также появляется возможность запускать агентов в разных интерфейсах — Telegram, web, CRM, внутренние системы — без дублирования логики и данных.

Подготовка данных без нагрузки на бизнес

Одна из задач проекта — не вовлекать заказчика в длительную подготовку данных.

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

• собрали и оцифровали 1000+ страниц документов;

• очистили и структурировали данные;

• выделили сущности, связи, версии и теги;

• загрузили данные в Qdrant и PostgreSQL;

• настроили автоматическое обновление;

• реализовали архитектуру с ролевым доступом.

В результате заказчик получил рабочую корпоративную память без многомесячной подготовки.

Ролевая сегментация и контроль доступа

В системе реализована ролевая модель:

• гость;

• официант;

• менеджер;

• шеф-повар;

• управляющий;

• другие роли.

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

• restaurant_id;

• object_type;

• tags.

Пользователь получает только те данные, которые соответствуют его роли и контексту.

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

Администрирование и аудит

Система включает административный интерфейс, который позволяет:

• управлять доступами;

• назначать роли;

• приглашать пользователей;

• отслеживать запросы;

• анализировать использование данных.

Все обращения к RAG-слою фиксируются, что даёт прозрачность и возможность аудита.

Безопасность как часть архитектуры

Безопасность была встроена на уровне инфраструктуры:

• изолированные базы данных по ролям;

• отдельные ключи доступа;

• запрет межролевого доступа;

• фильтрация на уровне запросов;

• логирование всех операций;

• ротация ключей.

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

Вывод

Большинство AI-проектов теряют устойчивость не из-за качества модели, а из-за отсутствия единой базы знаний.

Без корпоративной памяти AI начинает противоречить сам себе, использовать устаревшие данные и требовать постоянных исправлений.

RAG-инфраструктура решает эту проблему, превращая AI из демонстрационного инструмента в управляемую систему, которая опирается на реальные данные компании и масштабируется вместе с бизнесом.

Поэтому в проектах с реальной нагрузкой правильная последовательность выглядит так:

1. формирование корпоративной памяти;

2. построение RAG-слоя;

3. запуск AI-продуктов и автоматизации.

Попытка поменять порядок обычно приводит к обратному эффекту: росту затрат, усложнению архитектуры и снижению качества результата.