Перейти к содержимому
НейроКуб
Открытый материал · 3 мин
Алина Прогресс

Исправили одно поле PDF — ошибок стало больше. Как выбрать удачную правку промпта

Проверяем изменения извлечения на фиксированном наборе документов: точность, пропуски, повторные запуски и откат версии. С разбором конкретного примера Databricks.

Улучшить извлечение одного поля из PDF можно так, что весь конвейер станет хуже. Выбирать правку стоит по результатам на одинаковых документах, учитывая пропуски и ошибки соседних полей. Это позволяет отделить полезное уточнение от удачного единичного ответа.

Два кандидата, два разных результата

В разборе Databricks от 27 октября описан проект примерно с 40 полями и десятками вариантов PDF-заказов. Уточнение поля revision почти вдвое сократило ошибки в нём, но общее число ошибок выросло на 9%. Модель начала придумывать значения в других полях — такую правку команда не выпустила.

Перестройка промпта и схемы дала другой результат: ошибок стало на 16% меньше в целом. Добавление precision mode к перестроенному варианту снизило их примерно на 32% относительно исходной конфигурации. Это результаты конкретного проекта поставщика, а не обещание для ваших документов.

Обложка и экран экспериментов: Databricks. В MLflow показаны три запуска каждой конфигурации; отдельные столбцы сохраняют ошибки revision, общие ошибки и версии промпта и схемы.

Сравнивайте весь контракт извлечения

Сначала зафиксируйте набор документов и проверенные человеком значения. Включите разные макеты и случаи, где правильный ответ — пустое поле. Договоритесь, что считается ошибкой: неправильная сумма, пропуск существующего значения и придуманное значение на пустом месте должны оставаться видны в отчёте.

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

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

Выбирайте по заранее заданному правилу

Повторите исходную оценку несколько раз, чтобы увидеть обычный разброс. Databricks предлагает 3–5 запусков базы; небольшое разовое преимущество кандидата может быть шумом. Порог значимого улучшения задайте до выбора победителя. Помимо общей метрики проверьте каждый критичный тип поля.

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

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

Комментарии

Пока нет комментариев. Начните обсуждение.