LLM system cuts control-card preparation at a steel plant from 2 hours to 5 minutes

A practical case from a metallurgical plant shows that large language models can do more than answer questions: they can also take heavy regulatory routine off engineers' hands. The system was taught to read scans of Soviet-era GOST standards and automatically build control cards in 3–5 minutes instead of more than two hours of manual work. In labor terms, the project's author estimates this removes a workload comparable to the work of three technologists.

The problem was very down-to-earth. The full-cycle plant employs about 3,200 people, and its product range exceeds 4,500 items and keeps growing. For each item, a technologist had to open a GOST, OST or other normative document, find the relevant tables and notes, plug in parameters such as steel grade, billet diameter and group, and then fill in more than 40 control parameters by hand.

The difficulty is that there are more than two hundred documents, and a significant share of them exist as not-so-convenient PDF scans from the Soviet era. The first idea was an ordinary parser, but it was quickly dropped. The formats of the standards are too heterogeneous: in one document the needed values sit in table rows, in another they are hidden in notes, in a third they are scattered through the text with references to other sections.

A simple template-based extraction scheme breaks down here, because the task requires understanding the meaning of a document, not just its visual structure. So the author turned to LLMs and built a setup in which the model receives a PDF of the standard, the product parameters and a set of rules on how to determine specific control parameters. The next hypothesis looked logical: write one universal prompt for all normative documents.

On the first test this approach gave a decent result. According to the author, Claude Sonnet 4.6 in thinking mode correctly identified 85% of the parameters for one GOST, and GPT 5.

4 got 72%. But on later documents the universality fell apart. The models got confused by nested tables, misread boundary conditions such as "at least" and "at most", and sometimes skipped constants or links between sections.

It turned out that an elegant general approach was worse here than a narrower but more controllable architecture. The working solution emerged after the product range was analyzed using the Pareto principle. It turned out that 80% of the plant's items are described by roughly 18% of the GOSTs.

For the pilot, the team picked the 20 most frequently used documents and wrote a separate prompt for each, with concrete rules: where to look for a parameter, which table or section describes it, and how to interpret disputed cases. The system received a PDF and the product's characteristics, and returned a table with the parameter, its value and a reference to the place in the standard. When an error appeared, the author sent a screenshot into the conversation, showed the correct answer and asked the model to update the rule so the failure would not recur.

Tuning took nine iterations and 14 working days, after which parameter extraction for the selected GOSTs worked without errors. The project is now being moved from experimental mode to one better suited to production. The rules are being pulled out of the prompts into an Excel table so that technologists can edit the logic themselves without getting into prompt engineering.

The model now receives not only the PDF and product parameters but also this rules table, and outputs data in a form that can be loaded into the plant's internal information system. This layer makes the solution scalable: new standards can be added gradually without tying all support to a single developer. The main takeaway from the case is simple: in industry, LLMs work better not as a "universal intelligence for every occasion" but as a carefully tuned tool for a specific class of documents.

If you start with the most frequent standards, make the model cite the source of each parameter and keep the rules editable by subject-matter specialists, AI turns from a demo into a production mechanism with clear economics. This approach may well repeat not only in metallurgy but also in mechanical engineering, construction, chemicals, pharma and energy — wherever people still move data by hand from regulations into working systems.