В логистике всё редко выглядит как аккуратная 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 знает правду. Его задача проще и практичнее: понять запрос, сходить в правильный источник данных, вернуть результат и, если возможно, сразу запустить следующее действие в интерфейсе.
Для внутренней автоматизации это, кажется, главный принцип: не «добавить нейросеть», а встроить её в конкретный рабочий процесс так, чтобы она экономила клики, уменьшала ручную сверку и не подменяла собой источник истины.