Разбор кейса AvtoUM: архитектура и разработка цифрового сотрудника

Есть проекты, которые начинаются со спецификации, а есть те, что начинаются с наблюдения. AvtoUM родился из второго: бизнес уже платит за сайт, за рекламу, за трафик, а между первым вопросом посетителя и реальной заявкой зияет разрыв. Менеджер отвечает поздно. Клиент приходит вечером. Информация о товарах разбросана по разным местам. История общения теряется между сайтом, Telegram, VK и внутренней CRM. Обычный чат отвечает на отдельный вопрос и на этом останавливается. Разберём, как этот проект превратился в цифрового сотрудника и что стоит за его архитектурой.

Отправная точка: молчащая витрина

Сайт — самая дорогая витрина бизнеса. В него вложены годы работы, деньги, реклама, позиции в поиске. Сюда стекается основной поток клиентов. И у этой витрины есть изъян: она немая. Она умеет показать товар, найти нужное и принять оплату. Она не видит живого человека, который прямо сейчас ходит по страницам и вот-вот уйдёт.

Посетитель зашёл, посмотрел, засомневался и закрыл вкладку. Молча. Возможно, у него были вопросы, но ему никто не ответил. Он не позвонил, не написал — просто ушёл к тому, кто оказался понятнее и быстрее. И так происходит постоянно. Днём, когда менеджеры не успевают ответить всем сразу. Вечером, когда отвечать уже некому.

По оценкам российского рынка, до шестидесяти процентов обращений приходят вне рабочего времени. Пик — с пяти до девяти вечера. Днём человек занят на работе, ему некогда выбирать и оформлять заказ. Он берётся за свои дела вечером, когда возвращается домой. А в этот самый час менеджеры уже ушли. Получается парадокс: клиент готов купить именно тогда, когда ответить ему уже некому.

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

Что именно проектировалось

AvtoUM создавался как цифровой сотрудник, а не как чат-бот. Разница принципиальная. Чат-бот отвечает на отдельный вопрос. Цифровой сотрудник знает контекст компании, понимает страницу, с которой пришёл посетитель, поддерживает разговор, помогает квалифицировать обращение, сохраняет его в CRM и при необходимости передаёт диалог человеку.

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

Инженерное доказательство этой идеи — цепочка Visitor → Dialogue → Contact → Request → Message. Каждый шаг этой цепочки должен быть реализован, проверен и учтён в CRM. Если хотя бы одно звено отсутствует, система превращается в красивую игрушку.

Первый пользовательский сценарий: виджет на сайте

Начинается всё с самого видимого слоя — общения на сайте. Компания получает токен виджета и подключает его к своему ресурсу. Посетителю не нужно устанавливать приложение или переходить в отдельный сервис.

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

Связь работает через WebSocket. Это двусторонний realtime-канал: посетитель видит ответы без перезагрузки страницы, а менеджер может подключиться к уже открытому разговору. Для возвращающегося посетителя сохраняется псевдонимный идентификатор и краткая история — разговор продолжается осмысленно, а не начинается каждый раз с нуля.

Управляемое поведение: слои контекста

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

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

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

Единый контур каналов и CRM

AvtoUM выходит за пределы окна на сайте. В архитектуре предусмотрен единый контур сообщений для сайта, VK, Telegram и MAX. Каждый канал имеет собственный адаптер, но основная бизнес-логика не копируется четыре раза.

После нормализации событие попадает в единый messaging pipeline. Система проверяет компанию и тариф, восстанавливает контакт, создаёт или находит заявку, сохраняет сообщение, проверяет график и лимиты, а затем выбирает способ ответа.

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

В результате владелец бизнеса видит разрозненные чаты, а связанную CRM-цепочку: компания, контакт, заявка и история сообщений.

Контроль человека и realtime

Автоматизация исключает человека там, где требуется ответственность, и здесь работает принцип: живой менеджер может перехватить активный диалог. В момент перехвата AI прекращает отправлять ответы. Сообщение сотрудника через Redis Pub/Sub возвращается в активную WebSocket-сессию посетителя. После завершения разговора управление можно вернуть автоматизированному контуру.

Redis здесь используется как основная база бизнеса. Он хранит краткосрочную историю, состояние диалога, presence и realtime-события. Долгоживущие сущности — контакты, заявки и сообщения — сохраняются в PostgreSQL. Это разделение помогает не смешивать временное состояние с транзакционными данными и позволяет независимо развивать realtime и CRM.

Ключевая мысль, которую стоит держать в голове: human control — это системное состояние, а не аварийный костыль.

AI-контур и выбор моделей

Теперь часть, которая отличает production-систему от демонстрационного прототипа.

Основная модель в AvtoUM — YandexGPT. Это осознанный выбор, а не техническая случайность. Для российского бизнеса критично, чтобы обработка персональных данных происходила в правовом поле РФ. YandexGPT работает на серверах, расположенных в России, и соответствует требованиям ФЗ-152 «О персональных данных». Для корпоративных клиентов это не мелочь, а условие, без которого система не может быть допущена к работе с реальными обращениями.

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

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

Ключевой принцип: персональные данные клиентов обрабатываются в защищённом контуре на серверах в РФ, а архитектура маршрутизации позволяет управлять и качеством, и стоимостью, и соответствием требованиям регулятора. Это три вещи, которые в AI-продукте для бизнеса проектируются вместе.

Работа со знаниями: точная формулировка

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

Здесь важно использовать точные термины. В текущем подтверждённом коде знания подключаются как структурированный блок контекста. Полноценный vector RAG с embeddings, отдельным encoder, hybrid search и reranker — это следующий архитектурный уровень для больших и постоянно обновляемых баз.

Границы системы и точка подключения такого retrieval pipeline предусмотрены: его можно добавить, когда объём документов и требования к поиску действительно это оправдывают. Это честная позиция: текущее состояние описано как есть, а следующий уровень обозначен как возможность, а не как внедрённая функция.

Аналитика и интеллект лида

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

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

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

Для меня это принципиально: генеративная модель дополняет учёт. Она помогает интерпретировать данные, которые уже собраны системой. Сначала факты, затем AI-интерпретация.

Биллинг и экономика продукта

Чтобы AI-продукт существовал как бизнес, нужна экономика сервиса.

В AvtoUM реализованы тарифы, месячные лимиты диалогов, пробный период, дополнительные пакеты, продление, смена тарифа и перерасчёт. Платёжный контур связан с ЮKassa.

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

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

Паспорт архитектуры

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

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

Отдельно формируется ER-модель данных. Она показывает, как связаны компании, пользователи, контакты, заявки, сообщения, платежи, сотрудники, записи и аналитические сущности.

API-реестр фиксирует реальные маршруты и уровень доступа. Sequence-схемы раскрывают путь сообщения через виджет и мессенджеры, а также платёжный сценарий. Матрица ролей отвечает на вопрос, кто имеет право выполнять действие и кто несёт ответственность.

Есть и реестр отказов: что происходит при недоступности модели, Redis, внешней CRM или платёжного провайдера; как система обнаруживает проблему, какой безопасный fallback применяет и как восстанавливается.

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

Технологический стек и production

Стек выбирался по ролям внутри системы.

Интерфейс построен на React 18, Vite и Tailwind CSS. React Flow используется для интерактивных карт, Recharts — для аналитических представлений.

Backend работает на Python 3.12 и FastAPI. Асинхронная работа с данными построена на SQLAlchemy и asyncpg, миграции ведутся через Alembic. FastAPI dependencies используются для авторизации, tenant-контекста и разграничения доступа.

PostgreSQL хранит транзакционные данные продукта. Redis отвечает за краткосрочное состояние, историю, presence и Pub/Sub. APScheduler запускает фоновые процессы: агрегации, тарифные события, классификацию и уведомления.

Production собран в Docker Compose. Контейнеры backend и frontend опубликованы только на loopback-портах, а внешний трафик проходит через системный Nginx с HTTPS.

На текущем этапе Kubernetes и Kafka или RabbitMQ отсутствуют. Для существующей нагрузки Docker Compose и Redis дают более простой операционный контур. Если нагрузка и число независимых обработчиков вырастут, оркестрация контейнеров и отдельная событийная шина станут обоснованным следующим шагом, а не технологией ради резюме.

Метод разработки

В этом проекте я отвечал за один изолированный модуль. Я сформировал продуктовую концепцию и спроектировал frontend, backend, CRM, realtime-контур, модель промптов, маршрутизацию моделей, биллинг, AI-экономику, администрирование и production-инфраструктуру.

В работе я использую AI-native подход и агентские инструменты, включая Claude Code и Codex. Это ускоряет исследование, реализацию, тестирование и поддержку больших кодовых баз. Архитектурные решения, границы безопасности, приоритеты продукта и финальная проверка остаются моей ответственностью.

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

Честная граница текущей реализации

Я сознательно разделяю то, что уже подтверждено кодом и production-конфигурацией, и то, что относится к следующему уровню развития.

Сейчас подтверждены async FastAPI, WebSocket, PostgreSQL, Redis, многослойные промпты, маршрутизация LLM, CRM, human takeover, аналитика, биллинг, учёт AI-расходов и контейнерный production.

Полноценный vector RAG с encoder и reranker, tool-driven ReAct, формальный контур Evals и LLM-as-a-Judge, Kafka или RabbitMQ, Kubernetes и автоматизированный CI/CD добавляются под конкретную нагрузку и критерии качества. Это отдельные инженерные подсистемы со своей стоимостью.

Колонка автора

Кульминация: что показывает этот кейс

AvtoUM — пример того, как один архитектор может соединить продукт, данные, AI, backend, frontend и эксплуатацию в один управляемый контур. Это редкость на рынке, где большинство AI-проектов собирается из кусков, написанных разными командами, и потом годами страдает от несогласованности.

Проект показывает и другое. AI-продукт для бизнеса существует как бизнес: с тарифами, лимитами, биллингом, учётом себестоимости и понятной экономикой. Красивый интерфейс и хорошие ответы модели — часть истории. Остальное — это дисциплина, данные и инженерия.

И третье, что стоит держать в голове. Цифровой сотрудник для бизнеса — это не про замену людей. Это про расширение возможностей компании, у которой сайт уже приводит клиентов, а довести их до сделки некому. AI-сотрудник работает круглосуточно, отвечает за секунды, сохраняет всё в CRM и показывает руководителю цифры. А команда занимается живыми, горячими клиентами.

Ваш сайт привлекает посетителей. AvtoUM превращает их в клиентов. В этой фразе — вся суть проекта.

Глоссарий терминов

• Цифровой сотрудник — AI-система, ведущая диалог с клиентом на сайте и в каналах, сохраняющая данные в CRM и передающая диалог человеку при необходимости.
• Виджет — встраиваемый на сайт компонент, через который посетитель открывает диалог с цифровым сотрудником.
• WebSocket — протокол двусторонней связи в реальном времени между браузером и сервером.
• Realtime — режим работы, при котором данные передаются мгновенно, без задержек и перезагрузок.
• Presence — индикатор присутствия участника диалога в системе в данный момент.
• Rate limit — ограничение на количество запросов или действий за период времени.
• Persona — настраиваемая роль и стиль общения цифрового сотрудника.
• Guardrails — ограничения, задающие границы поведения AI-системы.
• Messaging pipeline — автоматизированная цепочка обработки сообщений от поступления до ответа.
• Channel adapter — модуль, приводящий сообщения из конкретного канала к единому внутреннему формату.
• Нормализация событий — приведение сообщений из разных источников к единой структуре.
• Human takeover — перехват диалога живым менеджером с остановкой AI-ответов.
• Redis Pub/Sub — механизм обмена событиями между компонентами через Redis.
• LLM Router — компонент, выбирающий модель для конкретной задачи по типу, стоимости и тарифу.
• Fallback — резервный сценарий при недоступности основного компонента.
• Prompt caching — кеширование частей промпта для ускорения и снижения стоимости вызовов.
• Usage accounting — учёт потребления ресурсов AI: токенов, вызовов, стоимости.
• Vector RAG — подход, при котором модель отвечает, опираясь на найденные через векторный поиск документы.
• Embeddings — числовые представления текста для сравнения смысловой близости.
• Hybrid search — сочетание семантического и ключевого поиска.
• Reranker — модель, переупорядочивающая результаты поиска по релевантности.
• Business Snapshot — сводка ключевых показателей компании для принятия решений.
• ЮKassa — российский платёжный провайдер.
• Webhook — уведомление от внешней системы о наступлении события.
• Идемпотентность — свойство операции давать один и тот же результат при повторном выполнении.
• ER-модель — схема сущностей и связей между ними.
• API-реестр — перечень доступных маршрутов и уровней доступа.
• Sequence-схема — диаграмма последовательности взаимодействия компонентов.
• RACI — матрица распределения ролей и ответственности.
• Failure scenarios — описание поведения системы при сбоях.
• Agent Pack — набор проектных материалов для работы AI-агентов в рамках архитектуры.
• FastAPI — веб-фреймворк на Python для асинхронных API.
• Asyncpg — асинхронный драйвер PostgreSQL для Python.
• SQLAlchemy — библиотека для работы с базами данных на Python.
• Alembic — инструмент миграций для SQLAlchemy.
• APScheduler — планировщик фоновых задач на Python.
• Docker Compose — инструмент запуска нескольких контейнеров как единой системы.
• Nginx — веб-сервер и обратный прокси.
• Loopback-порт — порт, доступный только внутри машины.
• Kubernetes — система оркестрации контейнеров.
• Kafka, RabbitMQ — брокеры сообщений для событийной архитектуры.
• CI/CD — практика непрерывной интеграции и доставки.
• Evals — формальный контур оценки качества AI-системы.
• LLM-as-a-Judge — подход, при котором качество ответов оценивает другая языковая модель.
• AI-native разработка — подход, при котором AI-инструменты встроены в процесс разработки с самого начала.
• YandexGPT — большая языковая модель от Яндекса, работающая на серверах в России.
• ФЗ-152 (Федеральный закон № 152) — российский закон «О персональных данных», регулирующий обработку персональных данных.
• Токеномика — управляемая экономика потребления токенов: маршрутизация, лимиты и контроль стоимости.