Реальный кейс: как LLM заменяет трех технологов на металлургическом заводе — и почему «универсальный подход» не сработал.

Вначале было... 2 часа на одну карту контроля

Представьте металлургическое предприятие полного цикла: 3200 человек и 4500 тыс номенклатуры, которая все время добавляется....

Как раньше происходила подготовка к испытаниям? Технолог открывал ГОСТ (или ОСТ, или другой нормативный документ), находил таблицу, подставлял в нее параметры номенклатуры, например, диаметр поковки. Находил нужное значение контроля и записывал в карту ... Дальше технолог повторял эту процедуру для 40+ параметров контроля.

Фрагмент ГОСТ 8479-70. Технолог ищет значение относительного сужения
Фрагмент ГОСТ 8479-70. Технолог ищет значение относительного сужения

Оцените масштаб: более 4500 позиций номенклатурысвыше 200 нормативных документов (ГОСТы, ОСТы), большинство из них - отсканированные документы советской эпохи в формате pdf.

На подготовку одной карты требовалось больше двух часов. Моя задача: сократить это время

Вариант №1. Парсер

Первый вопрос: почему не реализовать задачу через шаблонный парсер?

Не получится, потому что каждый ГОСТ оформлен по-своему. В одном ГОСТе параметры находятся в строках таблицы, в другом в примечаниях, в третьем размазаны по тексту с отсылками на другие разделы.

Нужен подход, который понимает смысл, а не только структуру.

Идея: LLM как технолог

А если использовать LLM как интеллектуальный парсер. Тогда задача выглядит так:

Вход:

  • Нормативный документ (ГОСТ/ОСТ) — скан в PDF

  • Характеристики номенклатуры (марка стали, диаметр заготовки, группа)

Промт:

  • Параметр контроля №1. Название + алгоритм, как его определить

  • Параметр контроля №2. Название + алгоритм, как его определить

  • ...

Выход:

  • Таблица: Параметр контроля — Значение — Источник (раздел/таблица ГОСТа)

Я вижу цель. Дело за реализацией ...

Вариант №2 Общий промт

Вторая гипотеза была проста и красива: сделать универсальный промт для всех нормативных документов.

Я начал тестировать разные модели в Рerplexity. Первый ГОСТ зашел на "ура" - Claude Sonnet 4.6 верно определил 85% параметров, GPT 5.4 - 72%. Обе модели запускались в режиме Thinking.

Но победа оказалась сильно условной. На следующих ГОСтах обе модели упрямо ошибались. Я правил промт, однако ошибки продолжались.

Что же, надежда на то, что LLM подсторится под все нормативные документы, не оправдалась. Система спотыкается на отличиях между ГОСТами - то параметр считается через вложенные таблицы, то задается константой.

Оставался один вариант: сделать промт привязанный к конкретному ГОСТу. Единственная неприятность, что на предприятие используется более 200 ГОСТов

Вариант №3 Архитектура, которая сработала

Я уточнил, что 80% номенклатуры завода описывается в 18% ГОСТов. Знакомый со студенческой скамьи принцип Парето в действии.

Для пилота было решено взять 20 наиболее используемых документов.

Структура решения

Для каждого ГОСТа я создал свой промт с правилами:

  • Название параметра: ГОСТ

  • В какой таблице/разделе ГОСТа описывается параметр

  • Как интерпретировать граничные случаи (диапазоны, «не менее», «не более»)

Пример простых правил
Пример простых правил
Правило для обработка таблиц и граничные случаи
Правило для обработка таблиц и граничные случаи

Процесс отладки

На вход промта я подавал параметры номенклатуры и ГОСТ в pdf формате.

Пример входных данных
Пример входных данных

На выходе получал таблицу:

Результат работы промта
Результат работы промта

Если возникали ошибки (куда без них?), то в диалог Perplexity скидывал скриншот, указывал верные параметры и просил объяснить ошибку. Получив верный результат, давал волшебную команду

Обнови Правило XX так чтобы ошибка больше не повторялась

Потребовалось 9 итераций: зато сейчас система извлекает параметры для выбранных ГОСТов без ошибок.

Потраченное время - 14 рабочих дней.

И главный результат: время подготовки карты контроля теперь составляет 3-5 минут минут. То есть в 24 раза меньше чем было

Что делаю сейчас

Добавляю в систему новые ГОСТы и строю следующий слой:

  • Все правила хранятся в Excel-таблице (а не в промте - чтобы технологи сами правили параметры).

  • На вход промта подается Excel таблица

  • На выходе — таблица для загрузки во внутреннюю информационную систему предприятия

Выводы

  • Современные ИИ справляются с обработкой pdf сканов документов. Сложные структуры, вложеннне таблицы и даже качество сканирования уже не проблема.

  • Принцип Парето вам в помощь. Не пытайтесь сразу оцифровать все документы. Найдите 20% документов, которые содержат большую часть номенклатуры и начните с них.

  • Промт под конкретный документ, а не универсальный. Это противоречит интуиции и не так красиво, однако практично.

  • Итеративная отладка.  Большинство ошибок у меня было с распознованием вложенных таблиц разных ГОСТов. Я сделал единые правила для таблиц и ошибки исчезли.

  • Claude Sonnet. Лучше всего разбирает сложные документы

Кому это может быть полезно

Этот подход работает для любой отрасли, где есть:

  • Большой массив нормативных документов (ГОСТы, ОСТы, СНиПы)

  • Документы без конфиденциальной информации

  • Ручной перенос параметров из документов в информационные системы

  • Разнородное форматирование — документы разного качества и формата

Например, металлургия, машиностроение, химическая промышленность, строительство, фармацевтика, энергетика.

Если у вас похожие задачи: нормативная документация, параметры контроля, рутинное извлечение данных из регламентов, напишите в комментарии или в личку. Расскажу, с чего начать и подарю самые неочевидые грабли. Кейс живой, замечания и вопросы однозначно приветствуются.

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


  1. Damnt
    02.04.2026 20:17

    1. Перепроверка не занимала много времени или она была частичная? Ведь по сути надо пройти по всем таблицам и перепроверить все данные.

    2. На проверку теперь тратится всего 3-5 минут - это общее время или время работы LLM?


    1. Kudryavtsev-AiPrRocknRoll Автор
      02.04.2026 20:17

      1. Перепроверка была частичной - вложенные таблицы, условия 'не более/не менее' и прочие грабли. Это сделал я. Дальше технологи месяц проверяли результаты по ссылкам в документе. Ошибок не возникало 

      2. На получение карты контроля уходит 3-5 минуты. От ввода параметров до получения ответа LLM.


  1. diakin
    02.04.2026 20:17

    Что-то такое было уже )


    1. Kudryavtsev-AiPrRocknRoll Автор
      02.04.2026 20:17

      Где-то однозначно было;)


  1. Arhammon
    02.04.2026 20:17

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


    1. Kudryavtsev-AiPrRocknRoll Автор
      02.04.2026 20:17

      Отличный вопрос — мы как раз с этого и начали. Год назад стартовали оцифровку и упёрлись в объём: сотни документов и таблиц. LLM работает как ускоритель: собирает параметры и всегда даёт ссылку на пункт ГОСТа, по которому технолог может перепроверить цифры. Модель подкрутят? Но правила и ссылки останутся, а модель можно заменить или перетюнить, не ломая саму методику


      1. Arhammon
        02.04.2026 20:17

        технолог может перепроверить

        Перепроверит ведь? Энакин и Падме.jpg


      1. stepigal
        02.04.2026 20:17

        Почему не оцифровать бумажные страницы как есть, целиком, с помощью той же LLM? Потом уже оцифрованные и проверенные человеком страницы точно так же давать на анализ LLM. Если работаете с графическими сканами, то тратите кучу времени на одни и теже операции - LLM при каждом обращении постоянно оцифровывает изображенние в текст. Если вы работаете с LLM через API, то просто выбрасываете кучу токенов на ветер.


        1. Kudryavtsev-AiPrRocknRoll Автор
          02.04.2026 20:17

          ...проверенные человекомстраницы...
          Я переводил в docx и... вылезли проблемы со сложными таблицами - они не бились в нормальный вид. А вот промтом обрабатывались на ура
          Вы предлагаете логичный вариант - на будущее


  1. vadimr
    02.04.2026 20:17

    Так-то за 14 дней таблицы из 20 документов можно было не напрягаясь перенести в базу данных и написать достоверно работающие запросы SQL.


    1. Kudryavtsev-AiPrRocknRoll Автор
      02.04.2026 20:17

      С таблицами согласен, возможно. Однако в таблицах хранится часть параметров. Большая их часть берется из текста. Плюс есть номенклатура, где параметры берутся из двух трёх ГОСТов. Подход с LLM выглядит универсальнее.


  1. maremnev
    02.04.2026 20:17

    Хороший кейс. Вообще есть большая проблема с переводом старой советской документации в электронный вид и обработки с помощью LLM. Хотелось бы иметь сразу такого агента, который напечатает деталь по старой конструкторской документации, которой полно. По моему опыту еще есть проблема с парсером pdf. Как можно быть уверенным, что встроенный в gpt справляется правильно. Не пробовали через внешний парсер? Там хотя бы посмотреть на качество можно


    1. Kudryavtsev-AiPrRocknRoll Автор
      02.04.2026 20:17

      Как можно быть уверенным, что встроенный в gpt справляется правильно.

      Только тестированием и сравнением, которые... показали что внешние парсеры делают больше ошибок


      Хотелось бы иметь сразу такого агента, который напечатает деталь по старой конструкторской документации

      Всё впереди! Пока пробовал обратную задачу. На вход LLM подавал pdf чертеж - на выходе получал параметры детали (внешний диаметр, высоту кольца и тп)