Чат-бот для производства

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

Чем производственный запрос отличается от заказа в рознице

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

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

Что агент делает с чертежом и техзаданием клиента

Файл из чата попадает в действие «Обработка файлов»: оно принимает документ в аргумент, достаёт из него текст в формате Markdown или HTML и кладёт результат в переменную, которую агент дальше использует в диалоге. Работает это с docx, pdf, rtf, txt и заявлено как поддерживающее любой другой формат, то есть спецификация в Word и техзадание в обычном PDF идут одним и тем же путём.

Если чертёж прислан сканом или страницами-картинками, включается отдельный режим распознавания текста на изображениях: «не использовать», «использовать, если в PDF есть хотя бы одна картинка» или «всегда распознавать». Три режима и полная настройка этого действия — в статье про агента, который читает файлы клиента; здесь важно другое: распознавание сканов стоит отдельных денег сверх диалога, и включать его стоит только там, где чертежи реально приходят картинкой, а не аккуратным текстом.

Номенклатура: таблица с числовыми параметрами или запрос в 1С

Номенклатура на производстве — это диаметр, толщина, класс точности, вес и десяток других числовых характеристик, а не текстовое описание, которое можно узнать по смыслу. Для такой таблицы точный отбор работает надёжнее текстового поиска: агент строит запрос к данным и накладывает условие на поле как на число, а не как на строку: «толщина от 3 до 6», «диаметр не меньше 40», «допуск не превышает заданного значения». Условие уходит в выборку тем же способом, что фильтр «количество больше 60» в примере из руководства платформы.

Один нюанс решает, заработает ли отбор по диапазону: колонка с числом должна храниться как число, а не как текст, иначе сравнение «больше» или «меньше» не сработает. Устройство такого поиска, форматы файлов и лимиты по размеру таблицы разбирает статья про ИИ-агента и таблицы.

Часть производств номенклатуру и остатки в отдельную таблицу не выгружает, они живут прямо в 1С. Тогда агент обращается к базе действием «Вебхук»: на стороне 1С публикуется веб-сервис, а для настройки нужны три вещи — URL метода вместе с описанием запроса, список заголовков и способ авторизации, который может отсутствовать вовсе. Если есть возможность влиять на проектирование метода со стороны 1С, стоит заранее заложить поддержку POST-запросов: так проще передать за один вызов сразу несколько параметров, артикул, объём партии, срок. Полная настройка действия и авторизации — в статье про интеграцию с 1С.

База знаний по материалам, допускам и условиям поставки

Точный отбор хорош для чисел и артикулов, а связный текст про допуски по ГОСТу, условия отсрочки, минимальный тираж партии, упаковку и способ доставки в колонку таблицы не укладывается. Для такого текста работает база знаний с векторным поиском: он находит нужный абзац по смыслу вопроса, а не по совпадению формулировки. Клиент может спросить «какой допуск на этот диаметр» словами из своего чертежа, а не из внутреннего документа поставщика, и агент всё равно найдёт нужный кусок текста.

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

Квалификация по объёму партии и срокам, передача технологу

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

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

Доведите первую заявку до готовой сводки, а не до идеальной настройки

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

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

Частые вопросы