Разработчик довёл заполнение инженерных анкет до 73–86% совпадений с экспертом

Инженеру нужно заполнить анкету для поставщика промышленного прибора: указать давление, материалы, климатическое исполнение и взрывозащиту. Ответы разбросаны по сотням страниц технического задания. Казалось бы, готовая работа для LLM: найти нужный фрагмент и перенести значение в таблицу. В описанном на Habr проекте первая версия правильно заполняла примерно треть ячеек.

За два месяца автор довёл систему до 73–86% совпадений с инженером среди строк, на которые тот ответил, на трёх объектах. Но полезнее итоговой цифры здесь разбор ошибок. Система путала соседние параметры, пыталась угадать внутренние решения отдела и считала вопросами строки, которые вообще не требовали ответа инженера.

Цитата настоящая, ответ неправильный

Первый вариант работал привычным способом: для каждой ячейки поиск приносил двенадцать фрагментов техзадания, модель выдавала значение и цитату. Код проверял, действительно ли цитата существует. Этого оказалось мало.

Простой пример: система записывает «Гарантия: 30 лет». Число действительно есть в документе, только относится к сроку службы агрегата. Настоящая гарантия — 36 месяцев — находится рядом. Проверка источника проходит, инженер получает ошибку.

Автор передал заполнение правилам и справочнику, оставив модели извлечение фактов. На участках, где правила срабатывали, правильными были 86–92% ответов. По всем ячейкам двух других объектов результат составил 58%. Правила тоже переносили особенности одного проекта на другой.

Улучшение поиска само по себе не гарантировало прибавки. После дообучения небольшой модели нужный пункт стал занимать первое место в 63% строк вместо 52%, но правильных значений больше не стало. Следующий этап по-прежнему хватал первый фрагмент, из которого удавалось что-нибудь извлечь. Помогли дополнительные условия: проверять значимое слово параметра и единицу измерения срока.

Для команды, которая строит поиск по корпоративным документам, это важный урок: измерять нужно всю цепочку до готового ответа. Более удачная выдача бесполезна, если следующий шаг неверно ею распоряжается.

Часть знаний хранится у отдела

После проверки инженером обнаружилась более глубокая проблема. Среди нетиповых строк на первых четырёх объектах автор не нашёл в документах ответы для 65–83% случаев. В ручной проверке двадцати таких строк около половины оказались решениями отдела: они годами переходили из одного опросного листа в другой.

Модель не могла достать эти сведения из техзадания. Их там не было. Поэтому в систему добавили прошлые листы и стандарты отдела. Совпадение ответов на двух объектах стало основанием предлагать аналог увереннее, чем единственный найденный пример. При этом параметры конкретной среды требуют осторожности: значение с соседнего объекта может оказаться неподходящим.

В рабочем интерфейсе у ответа есть ссылка на пункт документа, цитата и страница с подсветкой. Если основания нет, строка остаётся пустой и попадает в вопросы заказчику. Выводы по нормам система предлагает отдельно, с объяснением, для проверки инженером.

Такой продукт помогает собирать и проверять информацию. Его практическая ценность зависит в том числе от того, насколько удобно специалисту подтвердить значение, исправить его и сохранить решение для следующего проекта.

Красивые проценты требуют проверки

Автор нашёл несколько ошибок в собственной оценке. Флажки в бланках читались неправильно. Ответы проверяемого объекта попадали в базу через старые стандарты: результат выглядел как 71% вместо честных 61%. Нечёткое сравнение принимало IP54 за IP65, хотя это разные обозначения защиты.

Наконец, больше половины строк бланка оказались требованиями, перечнями и подписями. После их исключения заполненность выросла с 45 до 81%. Ни одного правильного ответа при этом не добавилось: исправился знаменатель.

Есть ограничение и у итоговых 73–86%. Хотя система не видела ответы трёх проверочных объектов, автор подбирал правила по их ошибкам. Для двух объектов таблицы со сканов вручную перенесли в Excel. Это результат стенда; проверка на новом объекте ещё впереди.

Практический вывод для разработчика: прежде чем менять LLM, стоит проверить структуру формы, источники знаний, поиск и способ оценки. Для продакта следующий вопрос — сколько времени инженер тратит на проверку и исправления. Именно это покажет, насколько система помогает в работе.