LLM пишут планы дорожных работ для WisDOT: 14B почти не лучше 7B

Департамент транспорта Висконсина (WisDOT) для каждой зоны дорожных работ требует план управления движением, Transportation Management Plan, или TMP. Это документ о том, как не угробить ни рабочих, ни водителей и при этом не перекрыть дорогу целиком. Авторы препринта на arXiv (cs.CL, 2610.10650) попробовали автоматизировать его составление. Они взяли несколько открытых языковых моделей двух масштабов, 7B/8B и 14B параметров, дообучили их на архиве документов системы WisTMP и развернули локально. Дообучение заметно подняло качество по стандартным метрикам генерации текста. Но прирост от увеличения модели с 7B/8B до 14B оказался небольшим, а обоснования под конкретный проект и расчёт стоимости остались слабыми местами.

Как собрана система

ТМР готовят вручную, и качество документа зависит от опыта конкретного инженера. Это трудоёмкая работа: для каждого проекта нужно выбрать стратегии управления движением, описать их и объяснить, почему они подходят именно здесь.

Готового обучающего набора у авторов не было, поэтому они собрали его сами. Исторические документы WisTMP лежали в PDF. Их преобразовали в структурированные пары «вопрос-ответ» в формате JSON, где вопрос соответствует разделу плана, а ответ содержит текст, написанный специалистами. Так получился предметный датасет для supervised fine-tuning.

Отдельное решение связано с безопасностью. Модели не вызываются через внешние API, их запускают локально. Для госструктуры это практическое условие: данные о проектах и инфраструктуре не уходят наружу.

Что показали эксперименты

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

Ключевые наблюдения из статьи:

• дообучение значительно улучшает показатели по стандартным метрикам генерации текста;
• общий результат моделей оценивается как сильный;
• LLM склонны к избыточной генерации: они предлагают больше стратегий, чем нужно;
• модели с трудом пишут обоснования, привязанные к конкретному проекту;
• оценки стоимости получаются неточными;
• масштабирование с 7B/8B до 14B даёт ограниченный выигрыш.

Последний пункт самый интересный для практиков. Если 14B почти не лучше моделей поменьше, то для такой узкой задачи выгоднее брать компактную модель. Она дешевле в инференсе и проще разворачивается на локальном железе. Качество упирается не в размер сети, а в данные и в то, насколько они отражают специфику проекта.

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

Как применять такие результаты

Авторы осторожно формулируют вывод: потенциал для повышения эффективности подготовки TMP есть, но проблемы остаются. Это честная оценка. Разумный сценарий сегодня выглядит как черновик, который модель готовит, а инженер проверяет.

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

• начинать с небольшой открытой модели и локального развёртывания, а не гнаться за размером;
• вкладываться в архив: чистые структурированные пары «вопрос-ответ» из старых PDF дают больше, чем лишние миллиарды параметров;
• расчёт стоимости оставить человеку или отдельному детерминированному модулю;
• проверять лишние стратегии вручную: модель перестраховывается и раздувает план;
• в запрос закладывать параметры проекта, иначе обоснования получатся общими.

Код и демо-видео авторы обещают опубликовать на странице проекта TMP-LLM. Когда они появятся, можно будет проверить, насколько подход переносится на документы других штатов. Пока это аккуратный кейс о том, где LLM уже экономят время в инженерной бюрократии, а где без специалиста не обойтись.