Хочу выразить свою благодарность всем сотрудникам ИТ отдела, за помощь в изучении 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, для Европейских типов паллет.

Модель

Результат тестирования

Скорость TTFT

deepseek-coder-v2:16b

Ответ не верный

total duration: 1m47.8427644s

prompt eval count: 2572 token(s)

prompt eval duration: 1m16.365931s

prompt eval rate: 33.68 tokens/s

gemma4:26b

Ответ верный

total duration:       21m33.7271745s

prompt eval count:    2165 token(s)

prompt eval duration: 2m55.275504s

prompt eval rate:     12.35 tokens/s

qwen3-coder:30b

Ответ не верный

total duration:       3m41.5797713s

prompt eval count:    2143 token(s)

prompt eval duration: 2m53.76253s

prompt eval rate:     12.33 tokens/s

qwen3:14b

Ответ верный, но не оптимальный

total duration:       15m5.865913s

prompt eval count:    2145 token(s)

prompt eval duration: 2m59.894633s

prompt eval rate:     11.92 tokens/s

qwen3:30b

Ответ верный

total duration:       16m9.3425841s

prompt eval count:    2145 token(s)

prompt eval duration: 2m53.397548s

prompt eval rate:     12.37 tokens/s

qwen3.5:9b

Не справился с заданием

total duration:       19m36.3051479s

prompt eval count:    1995 token(s)

prompt eval duration: 1m16.513861s

prompt eval rate:     26.07 tokens/s

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

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

Комментарии (2)


  1. CratosArt
    23.07.2026 07:04

    А точно нужно было использовать LLM в данном проекте? Это финансово оправдано или использовалось для эксперимента в целях определения применимости данных механизмов?


  1. OldNileCrocodile
    23.07.2026 07:04

    А текст запроса я Вам не покажу, т.к. он не выполняется в Вашей системе.
    Классика ИИ-шизы.
    То, что google эффективнее китайцев - это аксиома по деньгам и связам - у гугла контекста больше.

    Ну и уже были прецеденты, когда ИИ запросом сносил данные и целые БД. Но прикол в том, что это нужно ловить, а про ловлю тут ничего.
    Нет, конечно если гнать только SELECT запросы, машина ничего не сносит, ну кроме того, что может только взаимную блокировку создать (deadlock).

    В Oracle это происходит при неиндексированных полях и нескольких синонимах между машинами (например, отчеты по DWH, или же получение из КИС данных). Либо когда планировщик пользуется битовой картой, которую он ПИШЕТ. Или когда он выбрал
    взаимоисключающие планы по одному и тому же объекту в разных сессиях.
    Но, внезапно, надо читать форумы и разбираться, а что же наша БД так часто в deadlock уходит, ведь ИИ запрос создаёт быстрый и правильный.

    *The deadlock seems to be due to the query execution plan Oracle selected for servicing the statements.

    P. S. ИИ не оперирует множеством сессии и не скажет Вам как поведёт себя планировщик - ибо среды исполнения разные.