За последние годы большинство AI-проектов в компаниях стартуют одинаково: сначала делают чат-бота, затем добавляют агентов, автоматизируют отдельные процессы и ожидают роста эффективности.
На практике такие проекты часто не дают устойчивого результата. Модель может корректно генерировать текст, демонстрации выглядят убедительно, но в реальной работе ответы оказываются нестабильными, противоречивыми и не связанными с внутренними стандартами компании.
Основная причина — отсутствие единого слоя знаний.
В проекте для ресторанной группы с 10+ заведениями и историей более 15 лет мы сознательно начали не с агентов и не с интерфейсов, а с построения корпоративной RAG-инфраструктуры. Этот слой стал основой всей последующей AI-архитектуры.
Почему AI без корпоративной памяти не работает
В большинстве компаний проблема не в отсутствии данных, а в их фрагментации.
Меню, технологические карты, стандарты, регламенты, обучение персонала, винные карты, внутренние инструкции и гайды накапливаются годами, но хранятся в разных форматах и системах. Эти данные не связаны между собой и не образуют единого источника знаний.
Если подключить LLM к таким данным напрямую, возникают типовые эффекты:
модель даёт разные ответы на одинаковые вопросы;
информация противоречит сама себе;
часть ответов устаревает;
контекст бизнеса игнорируется;
появляются «галлюцинации».
В результате AI становится нестабильным инструментом, который генерирует тексты, но не опирается на реальные стандарты компании.
Поэтому первым этапом была не автоматизация, а создание единого интеллектуального слоя.
Мы собрали более 1000 страниц документов, накопленных за 15 лет: меню, регламенты, техкарты, внутренние инструкции, обучающие материалы и гайды. После этого данные были очищены, структурированы, размечены и объединены в единую RAG-инфраструктуру.
Этот слой стал единым источником фактов для всех последующих AI-сервисов.
Что такое RAG в прикладной архитектуре
RAG (Retrieval-Augmented Generation) — это подход, при котором модель не генерирует ответ «из памяти», а сначала получает релевантные данные из корпоративной базы знаний и только затем формирует ответ.
В упрощённой схеме:
модель отвечает за генерацию текста;
RAG отвечает за достоверность.
Технически это реализуется через векторизацию документов и семантический поиск. Данные из корпоративных источников преобразуются в векторное представление и сохраняются в специализированном хранилище (например, Qdrant), а структурированные данные и служебная логика — в PostgreSQL.
При запросе система:
ищет релевантные фрагменты в базе знаний;
передаёт их модели;
формирует ответ на основе найденных данных.
Такой подход ограничивает произвольную генерацию и делает ответы привязанными к реальным документам компании.
Это критично для корпоративной среды, где важно контролировать, какие данные использует 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 из демонстрационного инструмента в управляемую систему, которая опирается на реальные данные компании и масштабируется вместе с бизнесом.
Поэтому в проектах с реальной нагрузкой правильная последовательность выглядит так:
формирование корпоративной памяти;
построение RAG-слоя;
запуск AI-продуктов и автоматизации.
Попытка поменять порядок обычно приводит к обратному эффекту: росту затрат, усложнению архитектуры и снижению качества результата.