Как мы «приручали» ИИ в WMS

Хочу выразить свою благодарность всем сотрудникам ИТ отдела, за помощь в изучении CWMS 3000.

Добрый день. Я работаю разработчиком в компании Аэросиб-С. Аэросиб-С – крупная российская логистическая и транспортно-экспедиционная компания, специализирующаяся на складской логистике, логистике для интернет-магазинов и ответственном хранении товаров на складах класса «A».

Через склады ежедневно проходят несколько тысяч товарных единиц, в системе WMS (Warehouse Management System – система управления складом) фиксируются сотни миллионов транзакций. Для успешного функционирования бизнеса требуется снижение ручной работы, за счет автоматизации всех бизнес-процессов.

Недавно я реализовывал задачу автоматизации выставления счетов за оказание логистических услуг на основании данных из WMS и ТСД (терминалов сбора данных). Данная система позволяет сократить ручной ввод информации сотрудниками, и экономит финансовые средства за счет более точного выставления счетов и избежания ошибок расчета. В процессе разработки я использовал параметризованные SQL-запросы к базе данных. Однако это создает определенную сложность: для описания новых услуг или изменения логики расчета требуется менеджер, владеющий SQL, что на практике маловероятно. Чтобы снизить нагрузку на разработчика по сопровождению системы, я принял решение использовать технологии искусственного интеллекта. На сегодняшний день существует множество открытых LLM-моделей, способных генерировать корректные SQL-запросы по текстовому описанию, используя предоставленную схему данных.

Хочу поделиться с Вами процессом выбора LLM модели, тестированием и результатами эксплуатации. Изначально, в постановке задачи, не было условия использования LLM моделей. Поэтому при реализации не было предусмотрено использование серьёзных вычислительных средств.

Для решения поставленной задачи мной были определены следующие этапы работы и ключевые ограничения:

• «В начале было Слово». С помощью текстового описания, с использованием специфических для логистики терминов и конкретной WMS, формировать SQL запросы к базе данных;

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

• Требуется использование доступного оборудования: Linux Debian с 30Gb RAM.

  Анализ SQL запросов, которые были созданы для описания автоматически выставляемых счетов за услуги, позволил:

• Сузить круг таблиц WMS, подлежащих документированию через DDL;

• Разработать эталонный запрос для последующего тестирования моделей.

Для описания части схемы WMS, для моей задачи, потребовалось описать только 10 таблиц. Для задачи подобного рода — Text-to-SQL, понимания связей в базе данных, и формированием сложных запросов (JOIN, GROUP BY), требуются LLM модели с 16B/32B параметрами.

Вот список моделей, которые я протестировал, используя следующий тестовый запрос:

Создать запрос, который получает количество уникальных идентификаторов паллет – cnt и пустое поле nomenklatura_n из таблицы стока, для оприходованных на склад записей, на основании уникального идентификатора приходной накладной, используемого в качестве параметра :ST_DOC, для Европейских типов паллет.

Модели тестировались с использование сервера ollama и тестовым modelfile, содержащим описание схемы:

# Use an existing base model

FROM model-name

 

# Set parameters to adjust creativity and context length

PARAMETER temperature 0.1

PARAMETER num_ctx 8192

 

# Bake in a custom system prompt

SYSTEM “””

Ты — ведущий разработчик баз данных Oracle.

Твоя задача — переводить текст в SQL-запросы.

Используй ТОЛЬКО диалект Oracle SQL.

Выдавай только чистый SQL-код внутри блока “`sql, без лишних объяснений.

Используй ТОЛЬКО следующую схему данных:

[СТРУКТУРА ТАБЛИЦ (DDL)]:

“””

ollama create test_model -f test_modelfile
ollama run test_model

Результаты тестирования выявили следующие моменты:

• Специализированные coder модели работают хуже, чем размышляющие модели. Возможно, это связано с ограничением LLM моделей 16B/32B параметрами;

• Без использования видео ускорителей с VRAM, время ответа моделей, измеряется десятками минут. Очевидно – но это первая попытка использования ИИ без привлечения дополнительного финансирования;

• Текстовое описание условий формирования автоматически выставляемых счетов за услуги, скорее сформулирует аналитик, а не менеджер ответственный за счета и услуги.

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

  Как я вижу развитие: услуги разных компаний, примерно одинаковы и обычно повторяются. Можно создать экспертную систему, которая будет классифицировать виды автоматически выставляемых услуг по группам. Это позволит пользователю подбирать текстовое описание SQL-запроса для новых услуг из существующих;

• Победителем я выбрал модель gemma4:26b, так как она генерирует самый корректный SQL-код.

Сейчас на habr’е появилось много статей про использование искусственного интеллекта. От “AI-программирование: как я решил задачу, не написав ни строчки кода” (https://habr.com/ru/articles/825478/), до “Кризис найма (как в IT) журналисты прошли ещё в 2013. Как у них получилось выйти?” (https://habr.com/ru/articles/1058218/). Данная статья заканчивается мрачным прогнозом: “ИИ может срезать половину офисных позиций начального уровня и поднять безработицу до десяти-двадцати процентов в ближайшие один-пять лет, и «большинство людей не подозревают, что это вот-вот произойдёт»”.

Появление новых технологий — это всегда вызов. Требуется найти такое решение, использования искусственного интеллекта, чтобы с одной стороны повысить скорость разработки, а с другой формировать код, который не будет вести к тех долгу и не будет ситуации, что код никому не понятен. Мое мнение: ИИ — это инструмент. Изучайте его, используйте самым свободным, дерзким и оригинальным способом, экспериментируйте в своих проектах.