Кейсы: Структурированное извлечение данных из документов, типичные проблемы и советы
Вчера консультировал компанию, которая занимается логистикой в Европе. Они пилят внутренний продукт с LLM под капотом.
Кейс - нужно извлекать информацию из таможенных деклараций, чтобы автоматически загружать в дальнейший бизнес-процесс. Ситуация осложняется тем, что в каждой стране EU свой формат деклараций, а единого электронного формата пока нет.
Текущий статус - используют Google Gemini, которому скармливают страницы и просят извлечь ответ по структуре. Есть даже evaluation datasets. По ним видно, что точность пока недостаточна.
Но вот как этот прототип масштабировать до стабильного продукта в компании и осознанно двигаться к повышению качества - они пока не знают. А галлюцинаций там хватает.
У меня было минут 30, поэтому быстро прошлись по их решению и сразу перешли к обсуждению того, как с этим работать. Мои советы были очень типичны - просто подсветить приоритет того, что нужно сделать в первую очередь:
(1) Закрыть Feedback Loop и сделать так, чтобы можно было очень быстро тестировать качество работы всего пайплайна после любого изменения. В идеале, если на выходе будет визуализация ошибок в виде heatmap.
(вот пример визуализации: https://labs.abdullin.com/res/ai-assistants-ru-S02M13-heatmaps.png)
Тогда можно будет повысить качество просто подбором параметров pipeline. Причем это будет делать не от балды, а осознанно - по паттернам ошибок.
(2) Выкинуть ненужный мусор из промпта и начать использовать SO/CoT на всю катушку. У них был текстовый промпт, который не использовал ни Literals (вместо этого добавили вручную правило в текст) ни встраивал цепочки рассуждений перед проблемными полями. Из-за этого точность была сильно хуже того, что можно было получить.
(3) Следить за Signal vs Noise и декомпозировать, если сложные задачи. Но извлечение данных - это обычно задача простая.
И, в принципе, все. Этих вещей достаточно для того, чтобы начать двигаться в правильном направлении с технической стороны.
А одной команде это и вовсе помогло решить полностью конкретную проблему в инструменте для командной работы. Было:
Оно по сути работает, но надежности добиться не получается никак… Причем иногда оно стабильно работает неделями, а потом чето рандомно ломается) Довольно плохо слушает инструкции, даже жесткие. Модели разные пробовали, лучше всего на гпт 4о.
Подскажи пожалуйста, в нашем кейсе реально добиться надежности или пока технологически ограничены?
После подсветки приоритетов команда сфокусировалась на главном и быстро получила результат:
Да действительно так все и оказалось как ты говорил.
Нормальный промпт, SO+checklist показали приемлемую надежность в ответах даже на датасете со сложными переменными даты и времени.
Спасибо 🤝
Так что если у вас в продукте с LLM под капотом есть схожая ситуация, то для начала можно свериться с тремя пунктами выше. А для осознанности и понимания контекста можно еще прочитать разборы других кейсов продуктов с LLM под капотом.
Кто-нибудь еще валидирует ошибки не одной accuracy, а интересной таблицей или графиком? Поделитесь скриншотами своих визуализаций!
Ваш, @llm_under_hood 🤗
>>Click here to continue<<