AI-консультант для оптовой компании: как менеджеры перестали 100 раз в день искать товары по 9 каталогам

Расскажу, как мы собрали AI-помощника для менеджеров оптовой компании в сфере электротехники. У клиента было 9 источников номенклатуры, 200 000+ позиций SKU и сотрудники, которые тратили половину рабочего дня на поиск товаров по сайтам разных дистрибьюторов и сверку цен. Сейчас этим занимается бот: менеджер пишет запрос на русском языке — бот сам ищет, сравнивает, отдаёт результат таблицей. Объясняю, что внутри и как воспроизвести у себя. Я разработчик-практик, 12 лет в вебе.

Статья — про конкретный технический подход, без брендов и продажи; для тех, кто примерно прикидывает похожий проект себе.

Дано: оптовая компания в сфере электротехники, средний чек заказа — от 50 тыс. до миллиона рублей. Их клиенты — это монтажные организации, проектные институты, склады. Сценарий типичный: клиент шлёт менеджеру список позиций («ВВГнг 3×2.5 — 500 метров, лоток ЛНМЗТ — 80 штук, светильник такой-то — 30 штук»). Менеджер должен:

- Найти каждую позицию в 9 каталогах своих источников номенклатуры.

- Сравнить цены и остатки.

- Понять, у кого выгоднее купить с учётом доставки и кратности упаковки. - Дать клиенту коммерческое предложение. На одну заявку из 20–30 позиций уходило 1,5–2 часа. У одного менеджера — 4–6 таких заявок в день. То есть весь рабочий день — это копипаст артикулов в поисковые строки разных сайтов.

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

В результате клиент терял возможные более выгодные предложения. Запрос на старте был мягкий: «можно ли как-то ускорить поиск».

Я предложил собрать прототип AI-консультанта.

Веб-чат на одном HTML-файле, доступный менеджерам через корпоративный URL. Внутри:

- Распознавание запроса. Менеджер пишет в чат: «найди ВВГнг 3×2.5, нужно 500 метров, и аналог СИП 4×16 без алюминия». Бот понимает естественный язык, выделяет позиции, количество, бренды, признаки «искать аналог».

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

- Поиск по 9 источникам параллельно. Каждый источник — отдельный сервис-парсер на сервере. Бот шлёт запросы во все сразу.

- Сборка таблицы топ-5 по каждой позиции. Менеджер видит цену, наличие, источник и matchScore — насколько найденная позиция совпадает с запросом.

- База знаний для аналогов. Если клиент попросил «аналог такого-то бренда», бот по справочнику определяет 3–5 других брендов той же категории и в нужных каталогах ищет именно их.

> Менеджер тратит на одну заявку 10–15 минут вместо 1,5–2 часов. Сложные позиции, где у бота низкий matchScore — добивает руками, как и раньше.

Не «магия искусственного интеллекта», а нормальный конвейер. Постарался описать по слоям — без привязки к конкретным брендам инструментов, потому что важна архитектура, а не названия.

Тонкий промпт + лёгкая модель определяет, что хочет пользователь: поиск по артикулу, поиск аналога, общий вопрос. От этого зависит маршрут дальше.

Для «найди артикул» — обычный поиск по каталогам. Для «найди аналог бренда X» — классификатор сначала исключает источник этого бренда из выборки, потом выбирает 3–5 ID других производителей той же категории и ищет в каталогах именно их. Для «общих вопросов» — обычный диалог с RAG-индексом по базе знаний клиента.

Один сервис на один источник — Python + headless-браузер в Docker-контейнере. Каждый знает локальную специфику:

- У одного — поддержка авторизованной сессии (без неё не отдаёт оптовые цены).

- У другого — JWT-токены с регулярным обновлением.

- У третьего — обход антибот-защиты через эмуляцию поведения пользователя.

- У четвёртого — поддержка корзинной сессии и конвертация километров в метры (там длинно-измеряемые товары идут в км).

Каждый сервис принимает HTTP-запрос с поисковой фразой, отдаёт массив товаров с ценой, наличием и URL карточки. Если падает — фиксируем в журнале и идём дальше: бот не должен застрять из-за одного источника.

Получает результаты от 9 источников, строит таблицу. Сортировка внутри группы: «достаточно ли товара на остатке для нужного количества» → «есть ли в наличии вообще» → «по цене возрастающей» → «по matchScore». Сначала смотрит, у кого можно сразу купить нужный объём, а уже потом — у кого дешевле.

Markdown с эмодзи-акцентами + HTML-таблица с чекбоксами. Менеджер отмечает позиции, которые хочет включить в КП, и одной кнопкой получает CSV или копирует в свою CRM.

Postgres. Каждое сообщение, каждое прогресс-событие пишется в БД — это важно для дальнейших разборов «почему бот не справился». > Всё это работает на одном среднем сервере (8 GB RAM, 8 vCPU), в Docker. Никаких особенных GPU, никакой ML-команды.

Чтобы не оставлять вопросов — на чём именно собрано в моём кейсе: - Оркестратор воркфлоу: n8n (визуальный конструктор пайплайнов вместо «всё кодом»).

- Шлюз к LLM: OpenAI-compatible API, многомодельный — позволяет переключаться между провайдерами одной строчкой.

- Классификатор намерений и выбор top-N товаров: GPT-4o-mini (через шлюз, temperature=0 для детерминизма).

- Основной диалог-ответчик: GPT-4o.

- Поиск артикулов в открытом вебе: GPT-4o-search-preview.

- Поиск аналогов с жёсткой фильтрацией доменов: Perplexity Sonar Pro (параметр `search_domain_filter`).

- Распознавание файлов (Excel / PDF / изображения): GPT-4o vision.

- Парсеры источников: Python + Playwright в Docker-контейнерах, по одному на источник.

- Хранилище диалогов и метрик: PostgreSQL. Связка `n8n + агрегатор LLM` оказалась удобной по одной причине: всю маршрутизацию между моделями и провайдерами можно менять без редеплоя — прямо в визуальном редакторе. На старте я гонял всё через GPT-4o-mini, потом для тяжёлых сценариев включил GPT-4o и Sonar Pro. Это сэкономило недели разработки.

Чтобы не быть голословным.

Время на сборку: около 2 месяцев на полноценное внедрение. Из них 3 недели на парсеры (это самая нудная часть — каждый источник имеет свои причуды). Ещё месяц — на стабилизацию, разборы кейсов, доработку правил.

Стоимость инфраструктуры:

- VPS под оркестратор + парсеры + Postgres: ~3 500 рублей в месяц.

- LLM-токены (классификатор + основной ответчик): пиковые сутки доходят до 200 рублей, в среднем 50–80 рублей в день. Заложили 5 000 рублей в месяц в бюджет — с большим запасом. Итого на эксплуатацию выходит порядка 8 000–10 000 рублей в месяц. Окупается одним вечером работы менеджера, который теперь занимается не копипастом, а продажами.

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

Поначалу хотелось положить весь поиск на готовую языковую модель с веб-поиском. Дал ей `site:domain1 OR site:domain2` — и ждал, что она сама пойдёт по нужным сайтам. Не пошла. Большинство популярных «поисковых» моделей слабо слушают директивы `site:`, особенно когда нужно жёстко ограничить поиск перечнем доменов. Спасают специализированные поисковые API с явным параметром domain-filter — они умеют нативно фильтровать поисковые домены. Но дороже.

Первая версия делала запросы последовательно. Один таймаут — и пользователь смотрит на спиннер 5 минут. Переделали на параллельный fan-out с таймаутами на каждый источник и graceful degradation (если упал — таблица собирается без него).

Поначалу бот «дофантазировал» наличие и цены, если данные были неполные. Это классическая галлюцинация LLM. Лечится двумя вещами: жёсткие гайдрейлы в промпте («если данных нет — пиши "данных нет", не выдумывай») + структурированный JSON-ответ от каждого парсера, чтобы модель не пыталась интерпретировать сырой HTML.

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

Нет. Бот не заменяет менеджера — освобождает от рутины. Сложные сделки, торг, индивидуальные условия, нестандартные запросы — остаются на людях. Это инструмент, а не «AI-сотрудник».

По опыту — окупаемость отличная, если у вас выполняется хотя бы одно из условий:

- Большой каталог. От 1 000 позиций. На 50–200 SKU поиск можно решить нормальным фильтром на сайте.

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

- Несколько источников/поставщиков/складов. Когда менеджер вынужден сверять данные из нескольких систем.

- Большой поток типовых обращений. «Есть ли в наличии», «оптовая цена», «когда доставка» — десятки раз в день.

> Если у вас одна страничка с услугами и 5 предложений — AI-бот не нужен, поставьте обычный live-чат с тремя кнопками.

Если коротко по шагам:

1. Аудит каталога и базы знаний. Что у вас есть в формате, на котором можно строить RAG (выгрузка из 1С, прайсы, FAQ).

2. Сформулировать 10–20 сценариев, на которые бот должен отвечать. Это самая важная часть — без неё всё развалится.

3. Выбрать стек.Мой текущий рабочий набор: n8n как визуальный оркестратор, многомодельный шлюз к LLM, GPT-4o / 4o-mini для основного диалога и классификации, Perplexity Sonar Pro когда нужен жёсткий поиск по конкретным доменам, Postgres для хранения диалогов, виджет фронта на чистом JS. Всё в Docker, разворачивается на любом VPS.

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

5. Доработать на боевых диалогах. Первый месяц — это разбор «провальных» кейсов и доработка правил. Не «настроил и забыл» — без поддержки качество ответов деградирует.

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

Если планируете похожий проект и есть вопросы по архитектуре — задавайте в комментариях, разберём.