Как я встроил локального нейробота в панель поиска заявок для логистики

В логистике всё редко выглядит как аккуратная CRM из презентации.

Заявки (аукционы/тендеры/грузы приходят из разных источников. Часть данных живёт в 1С/Битрикс/Excel/Амбарная книга, часть — в SQL, часть — в интерфейсах сайтов, часть — в голове менеджера. Перевозчики отвечают неравномерно, менеджеры работают через звонки и таблицы, а руководителю нужно быстро понимать: какие заявки есть сегодня, где рента, какие маршруты повторяются, кто из менеджеров проседает, где найти транспорт.

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

Но довольно быстро стало понятно: сама таблица не закрывает главный сценарий.

Человеку всё равно нужно руками формулировать фильтр, помнить названия полей, переключаться между поиском, аналитикой и рекомендациями. Плюс в логистике своя внутренняя бизнес кухня, прибыль идет от типа ТС (реф/тент/изотерм/прочие) + сезонность, А если надо спросить что-то вроде “какая ставка/руб-км Краснодар — Москва тент?” или “сравни двух менеджеров за неделю”, таблица превращается в набор ручных действий.

Так внутри поиск-панели появился нейро-бот.

Что это вообще такое

Это не Telegram-бот и не отдельный чат “поговорить с AI”.

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

• применять фильтры к форме поиска;

• показывать заявки за период;

• отвечать по маршрутам и ставкам;

• считать ренту;

• сравнивать менеджеров;

• показывать отмены;

• запускать следующее действие “найти транспорт”;

• отдавать действия во frontend;

То есть это дополнительный слой управления рабочей панелью.

Пользователь может написать:

Какая ставка Краснодар — Москва тент?

И получить не фантазию LLM, а ответ по данным.

Или написать:

«Найди реф из Москвы в Краснодар на завтра, от 80 руб км»

И панель сама подставит фильтры, даты, тип транспорта и запустит поиск.

Вот это оказалось намного полезнее отдельного чата.

Зачем понадобился бот внутри поиск панели

В проекте есть несколько типов данных:

• внутренние заявки;

• предложения из внешних источников;

• ставки клиентов и перевозчиков;

• рента;

• отмены;

• менеджеры;

• история маршрутов;

• типы транспорта;

• рекомендации по поиску машин.

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

Покажи заявки за сегодня Что по ренте за месяц? Сравни Иванова и Петрова по заявкам за неделю Найди тент Краснодар Москва Какая ставка по маршруту Москва — Казань?

Технически это разные сценарии:
SQL-запрос, фильтр по источнику, быстрое действие, классификация через нейронку, сервис поиска транспорта.

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

Как работает запрос в чат

Пользователь пишет в виджет:

Ставка Краснодар Москва тент

Браузер не идёт напрямую в основной API. Он отправляет запрос в endpoint панели:

Дальше проксирует тело запроса в основной backend:

Виджет физически находится в поиск-панели, но “мозг” бота живёт в основном API.

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

Почему нельзя просто отправлять всё в LLM

Потому что это бизнес-инструмент, а не демо “поговори с нейросетью”.

Если пользователь пишет:

Покажи заявки за сегодня

не нужно отправлять это в LLM. Такой запрос можно распознать правилами.

Если пользователь нажимает «Что умеет бот», тоже не нужна модель.

LLM не ходит напрямую в базу и не является источником истины.

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

Такой подход скучнее, чем «у нас AI сам всё понимает», зато он намного безопаснее. Особенно когда речь идёт о ставках, ренте, менеджерах и заявках.

«Рента по менеджерам за неделю» «Сравни Иванова и Петрова по заявкам» «Что ты умеешь?»

Часть запросов обрабатывается вообще без LLM. Это важно не только из‑за скорости и стоимости, но и из‑за предсказуемости.

Бот умеет управлять интерфейсом

Самая полезная часть — это поиск «руками» бота

Допустим, пользователь пишет/диктует:

Найди груз Москва - Краснодар реф от 70 руб

Frontend получает это действие и делает обычную UI-работу:

1. подставляет значения в форму; 2. обновляет даты; 3. запускает поиск; 4. перерисовывает таблицу.

В итоге пользователю не нужно знать точные названия фильтров. Он пишет фразу, а панель сама выставляет поля.

Это тот момент, где AI становится полезнее обычного чата. Он не просто отвечает, а двигает рабочий процесс.

“Найти транспорт”

Есть ещё один сценарий.

Пользователь спрашивает:

Какая ставка Краснодар Москва тент от 30 руб км?

Бот отвечает по данным и может вернуть дополнительное действие:

В виджете появляется кнопка «Найти транспорт».

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

Он работает уже не по внутренним заявкам, а по витрине спаршенного транспорта:

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

Озвучка ответов

В виджете есть TTS:

Озвучить Озвучить полностью Стоп

Аудио кэшируется на диске по хэшу обработанного текста, чтобы не синтезировать одно и то же повторно.

Это не ключевая часть системы, но для длинных аналитических ответов оказалось полезно.

Что получилось

Получился встроенный рабочий помощник, который закрывает несколько сценариев:

• отвечает по фактическим данным из SQL;

• показывает заявки, маршруты, ставки, ренту и отмены;

• сравнивает менеджеров;

• применяет фильтры к поиск-панели;

• помогает перейти от аналитики к поиску транспорта;

• использует быстрые действия там, где LLM не нужна;

• использует LLM только как классификатор или аналитический слой;

• умеет озвучивать ответы;

Главный практический результат — пользователь меньше прыгает между таблицей, фильтрами, аналитикой и отдельными инструментами. Часть действий можно запустить прямо из фразы.

Какие были сложности

Грязные данные

Тип кузова может называться по-разному: “тент”, “тентованный”, “реф”, “рефрижератор”, “изотерм” и так далее. Для человека это примерно одно и то же, для фильтра — разные строки.

Пришлось вводить нормализацию и аккуратно разделять business-лейблы для UI и raw-значения из источников.

Города и маршруты

Города тоже не всегда приходят в нормальном виде. Где-то адрес, где-то населённый пункт внутри строки, где-то омонимы, где-то несколько точек маршрута.

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

LLM нельзя считать источником истины

Самое опасное — дать модели слишком много свободы.

В этом проекте LLM не должна придумывать ставки, ренту или количество заявок. Она может помочь понять намерение пользователя, но финальный ответ должен строиться на данных из repo и SQL.

Вывод

Встроенный нейро‑бот в панели поиска оказался полезнее отдельного AI‑чата.

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

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

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