Кейс про новое и хорошо забытое старое Вот еще один кейс внедрения LLM-ок в бизнесе с низким риском и высокой отдачей из категории Data Extraction. Бизнесу присылают всяческие счета-фактуры в электронно-бумажном формате. Эти документы необходимо прочитать и сопоставить с товарами в условных SAP/Dynamics/1С. Самая проблема не в парсинге документов, а в том, что товарные позиции в присланном документе (или его кривом скане) могут заметно отличаться от того, как они записаны в базе. Поэтому искать нужно умеючи. Эксперты, которые делают это вручную, иногда начинают распутывать эту головоломку не с названия продукта, а наименования поставщика и других вторичных признаков. В данном кейсе изначальная точность получилась в ~60%, под капотом был Azure Document Intelligence (напоминает этот старый кейс, да?). Для бизнеса 60% настолько плохо, что использовать невозможно. Ситуацию можно и нужно было улучшить.__ __ Итак, что было под капотом у решения? Пайплайн разбили на две части - парсинг и матчинг. Парсинг - самая простая часть. Его мы знаем, любим. Его можно быстро реализовать на любой Frontier модели. Поэтому сделали универсальный parsing всех типов документов. Эксперты клиента заполняли шаблон для извлечения на каждый тип (какие поля и как надо доставать), его конвертировали в SO/SGR, и на этом все. Эта часть изначально была сделана на базе Gemini Pro, но структура дала такой запас по прочности, что на проде его переключили на flash без потери качества. Матчинг - самая интересная часть. В этой части пайплайна использовался старый добрый ML для получения качественных результатов в полностью оффлайн режиме. Алгоритм смотрел на retrieval/scoring сигналы от TF‑IDF / BM25 вместе с семантической близостью (cosine от векторов) и кучей фич специфичных для этой предметной области. Всего их было больше 40. Сверху эту конструкцию украшал небольшой обученный CatBoost. Чтобы не тратить ручное время, пайплайн разрабатывался при помощи OpenAI Codex, у которого были: Engineering Harness для оценки финального качества, возможность менять код и задача повысить точность. Благодаря ему получилось достаточно быстро перейти от гипотезы “можно ли сделать matching на базе LLM” до “а можно ли сделать локальный matching без LLM совсем?” В итоге получилось быстрое, точное и экономное отраслевое решение, которое выдало ~95-97% точности и пошло в прод (а там еще и модель попроще поставили). Все, как мы любим. Ваш, @llm_under_hood 🤗 __ PS: Цифры скачка качества от 60% до рабочего решения здорово напоминают кейс Hail Mary со спасением (см части ____1,____ ____2,____ ____3,____ ____4,____ ____5,____ ____6+7____), но данный кейс с локальными моделями уже другой. Его полностью вел ____@AigizK__