Кейсы: Структурированное извлечение данных из документов, типичные проблемы и советы Вчера консультировал компанию, которая занимается логистикой в Европе. Они пилят внутренний продукт с 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 🤗