arXiv cs.CL→ original

LLMs Draft Road-Work Plans for WisDOT: 14B Barely Beats 7B

Researchers have proposed an LLM framework that automatically drafts Transportation Management Plans (TMPs) for road work zones. It builds on WisTMP, the Wisconsin Department of Transportation's system. The team fine-tuned open models at two scales, 7B/8B and 14B, on a dataset of historical PDF documents converted into question-answer pairs in JSON. They deployed the models locally to keep data secure. Fine-tuning noticeably improved standard text-generation metrics. The weak spots: the models generate unnecessary strategies, justify decisions poorly for a specific project, and get cost estimates wrong. • Moving from 7B/8B to 14B produced only a limited gain. • Running locally addresses data privacy. • The authors promise to publish the code and a demo.

AI-processed from arXiv cs.CL; edited by Hamidun News
LLMs Draft Road-Work Plans for WisDOT: 14B Barely Beats 7B
Source: arXiv cs.CL. Collage: Hamidun News.
◐ Listen to article

The Wisconsin Department of Transportation (WisDOT) requires a Transportation Management Plan, or TMP, for every road work zone. The document describes how to avoid endangering workers and drivers without shutting down the road entirely. The authors of an arXiv preprint (cs.CL, 2610.10650) tried to automate its preparation. They took several open language models at two scales, 7B/8B and 14B parameters, fine-tuned them on the archive of documents from the WisTMP system, and deployed them locally. Fine-tuning noticeably improved quality on standard text-generation metrics. But scaling the model from 7B/8B to 14B brought only a small gain, and project-specific justifications and cost calculations remained weak spots.

How the system is built

TMPs are prepared by hand, and the quality of a document depends on the experience of the individual engineer. The work is labor-intensive: for each project, the engineer has to choose traffic management strategies, describe them, and explain why they fit that particular site.

The authors had no ready-made training set, so they built one themselves. The historical WisTMP documents were stored as PDFs. The team converted them into structured question-answer pairs in JSON format, where each question corresponds to a section of the plan and each answer contains text written by specialists. The result is a domain-specific dataset for supervised fine-tuning.

A separate design decision concerns security. The models are not called through external APIs; they run locally. For a government agency, this is a practical requirement: data about projects and infrastructure does not leave the premises.

What the experiments showed

The authors compared models of different scales before and after fine-tuning and evaluated the results at three levels: overall text metrics, individual plan sections, and specific traffic management strategies.

Key observations from the paper:

  • fine-tuning significantly improves results on standard text-generation metrics;
  • the models' overall performance is rated as strong;
  • LLMs tend to over-generate: they propose more strategies than needed;
  • the models struggle to write justifications tied to a specific project;
  • cost estimates come out inaccurate;
  • scaling from 7B/8B to 14B gives a limited gain.

The last point is the most interesting for practitioners. If 14B is barely better than the smaller models, a compact model is the better choice for such a narrow task. It is cheaper to run at inference time and easier to deploy on local hardware. Quality is limited not by network size but by the data and by how well it reflects the specifics of a project.

The complaints about cost estimates and justifications are also understandable. The text of a strategy can be assembled from an archive template, but cost depends on the scope of work, the region, and current prices. A model trained on past documents cannot see that information. Tying a plan to a specific project requires input data that the text of the question may simply not contain.

How to apply these results

The authors word their conclusion cautiously: there is potential to make TMP preparation more efficient, but problems remain. That is an honest assessment. A sensible scenario today is a draft that the model prepares and an engineer reviews.

The work suggests several practical takeaways for agencies and contractors:

  • start with a small open model and local deployment instead of chasing size;
  • invest in the archive: clean, structured question-answer pairs from old PDFs deliver more than extra billions of parameters;
  • leave cost calculation to a human or to a separate deterministic module;
  • review extra strategies by hand: the model plays it safe and pads the plan;
  • include project parameters in the prompt, otherwise the justifications will come out generic.

The authors promise to publish the code and a demo video on the TMP-LLM project page. Once they appear, it will be possible to test how well the approach transfers to documents from other states. For now, this is a careful case study of where LLMs already save time in engineering bureaucracy and where a specialist is still indispensable.

ZK
Hamidun News
AI news without noise. Daily editorial selection from 50+ sources. A product by Zhemal Khamidun, Head of AI at Alpina Digital.
✦ Hands-On AI Engineering

Build & Ship Production AI Apps with Vibe Coding

Join Zhemal Khamidun's hands-on Vibe Coding Intensive at hamidun.com/vibecoding — master Claude Code, Cursor, and autonomous agentic workflows.

Explore Vibe Coding →Vibe Academy Platform
What do you think?
Loading comments…