AI-система для обращений с Авито: модель классифицирует, отвечает клиент

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

Летом 2026 года я взялся за систему, которая отвечает на эти обращения сама и заводит лиды в Битрикс24. Я был архитектором и единственным исполнителем. С сентября система работает на сервере клиента с реальными покупателями, 28 октября я сдал её с документацией.

Код и устройство системы — конфиденциальная информация заказчика, поэтому здесь только подходы, решения и замеры.

Задача и ограничения

Что требовалось:

• принять сообщение с Авито, понять, чего хочет покупатель, и ответить в рабочее время с разумной задержкой;
• посчитать доставку до города покупателя;
• завести лид в CRM или дописать существующий и позвать дежурного менеджера, когда нужен человек;
• напомнить покупателю, если он замолчал.

Ограничения задал заказчик:

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

Решение 1. Модель только классифицирует, тексты пишет клиент

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

Модель выбирал замером. Собрал набор из 63 размеченных обращений и прогнал кандидатов, доступных в России как услуга. Считал точность по каждому полю отдельно: одно общее число скрывает ровно то, ради чего всё считается. Модель может хорошо понимать города и путаться в товарах.

Первая находка замера: из восьми названий моделей кандидатов оказалось пять. Три пары дали ноль расхождений на всех 63 обращениях: это одни и те же веса под старым и новым именем. Без этой проверки в таблице было бы три дубля, выданных за независимое подтверждение.

Выиграла модель GigaChat среднего уровня: город верно в 60 из 63, намерение — в 58, товар — в 57, ни одного обращения без вердикта. В октябре я перепроверил выбор на 109 синтетических и 56 живых обращениях и перевёл бой на GigaChat-3-Pro в облаке. По оценке расхода в облаке, сообщение обходится примерно в 0,66 ₽. Провайдер меняется настройкой: все модели стоят за одним интерфейсом, а в тестах их заменяет подделка.

Решение 2. Одна база и для данных, и для очереди

Обращения приходят вебхуками, разбор идёт в фоне, по расписанию работают напоминания, сверки и ночные копии. Классический ответ — очередь на Redis. Я оставил одну PostgreSQL: задачи лежат в таблице, воркер берёт их через SELECT … FOR UPDATE SKIP LOCKED.

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

Пропущенные вебхуки не теряются: каждые 5 минут система сверяет чаты с Авито и догоняет то, что не пришло.

Решение 3. Зона клиента: настройки без разработчика

Тексты ответов, прайс, темп, рабочие часы, график дежурств, регионы, доставка — всё это 22 файла настроек. Клиент правит их в веб-панели. Каждая правка проверяется до записи и применяется без перезапуска, у каждой версии есть откат. Сломанный файл не применяется и поднимает тревогу.

Панель руководителя — 21 экран: выключатели чтения и отправки, разговоры, воронка, скорость ответа, причины потерь, аналитика каналов, расход на модель. Тревоги — 29 видов, они уходят в Telegram-ветки клиента и в Битрикс24.

Решение 4. Сначала аудит CRM, потом код

До первой строки кода я разобрал портал клиента: 5 воронок, 11 447 сделок, 66 пользовательских полей.. Выяснилось, что лиды из чатов Авито уже заводит штатная интеграция через открытую линию CRM. Без этого система плодила бы дубли рядом с ней. Дубли убрала одна настройка линии, а менеджеры сохранили привычный инструмент.

Отдельно замерил лимиты API Авито: площадка присылает заголовки с лимитом, и он оказался ниже, чем стоял у нас в ограничителе. Ограничитель опустил до первого живого запуска.

Передача

Перед каждой выкладкой — копия базы с проверкой, что она читается, и метка образа для отката. Пробное восстановление копии провёл до сдачи, оно сошлось. Систему перенёс на сервер клиента и передал с комплектом из 18 документов. Для людей там руководства владельца, менеджеров и юриста. Для ИИ-помощника — технические описания с картой «вопрос → документ и раздел».

Требования 152-ФЗ: данные только в России, работа по поручению на обработку персональных данных, журнал разбора не хранит переписку, секреты лежат файлами, контейнеры работают без root.

Замеры и результат

• пилот на одном кабинете — 14 августа, первый живой разговор — 15 августа: лид появился в CRM через 0,33 с после вебхука;
• с 16 сентября система работает на сервере клиента;
• с 11 августа по 28 октября — 879 сообщений покупателей, 2 289 ответов бота и менеджеров, 243 новых лида;
• 908 коммитов и около 350 тикетов за 12 недель, 5 400+ автотестов на настоящей PostgreSQL.

Что не сработало и чего я не утверждаю

• Каналов меньше, чем задумывали. В брифе были Авито, формы сайта и звонки. Звонки клиент оставил встроенному ИИ своей CRM, формы сайта как источник обращений не подключали. В бою только Авито.
• Из трёх транспортных компаний работает одна. Адаптер второй написан и покрыт тестами, но выключен: клиент работает с другими перевозчиками. Третью не подключили, ждём доступ.
• Локальные и часть облачных моделей отпали. Маленькая локальная модель не держала даже простое перекрёстное правило. YandexGPT проиграл замер по товарам. Локальные модели клиент исключил сам: держать их негде.
• Внешнего монитора живости нет. Тревоги работают, пока работает сам сервер. Если сервер остановится целиком, система не сообщит. Внешний монитор я рекомендовал клиенту.
• Рост продаж не измерен. Цели брифа по числу лидов остались целями. Связь «бот → выручка» никто не считал, поэтому я её не заявляю.
• Точность на живом потоке в процентах не заявляю. Её мерили на наборах для выбора модели, постоянной метрики в бою нет.

Стек: Python 3.12, FastAPI, SQLAlchemy 2, Alembic, PostgreSQL 18 (очередь на SKIP LOCKED), Jinja2, Docker Compose, pytest + testcontainers, GigaChat в облаке, API Авито, Битрикс24 REST, API перевозчика, Яндекс Метрика и Директ. Разработка — через Claude Code: спецификация, малые тикеты, тесты на каждое изменение.