Перейти к содержимому

Страхование · ИИ

Klarim

Разбирает пакет сканов по страховому обращению: находит поля в справках, фотографиях и выписках и переносит их в учётную систему.

Роль
Бэкенд, интеграции, ИИ-пайплайн
Срок
5 месяцев
Стек
Python · FastAPI · Anthropic API

Что изменилось

40 → 6 минут
медиана времени оператора на обращение. Среднее — около десяти: его поднимают обращения, которые пайплайн отдаёт человеку целиком.
1 час
от загрузки пакета до запроса недостающего документа. Раньше нехватку замечали на второй-третий день, когда до обращения доходила очередь.
12 из 100
обращений пайплайн не берёт: рукописные бланки, нечитаемые сканы, редкие типы документов, противоречия между документами. Их по-прежнему разбирает человек — за те же сорок минут.
1,1%
полей, которые оператор исправил в уже принятом черновике за месяц замера. Каждая такая правка уходит в набор проверки.

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

Что было до

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

  • Девять операторов, около восьмидесяти обращений в рабочий день, сорок минут на каждое: разбор занимал у отдела почти всё рабочее время.
  • Нехватку документа в пакете замечали, когда до обращения доходила очередь, — на второй-третий день. Запрос клиенту уходил тогда же, и обращение ждало ещё столько же.
  • В пиковые недели поток доходил до ста сорока обращений в день. Очередь на разбор росла быстрее, чем разбиралась, и сходила только к следующему месяцу.

Что сделали

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

  • Каждое поле в черновике подписано фрагментом скана, из которого взято; спорное подсвечено, а обращения, за которые пайплайн не берётся, помечены отказом целиком.

  • Интеграция с учётной системой: подтверждённое оператором обращение заводится без ручного ввода, а каждая правка оператора возвращается в набор проверки пайплайна.

Результат

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

Кто заказчик

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

Обращение — это не документ, а пакет: заявление, справка аварийной службы или управляющей компании, фотографии повреждений, чеки и выписки на пострадавшее имущество, копия договора. Медиана — двенадцать файлов, в тяжёлом случае их за сорок. Типов документов, которые заводятся в учёт, четырнадцать; полей, которые оператор переносил руками, — двадцать три.

Задача

Как ставил заказчик
«Поставьте распознавание документов»: чтобы оператор не набирал поля руками, а обращение заводилось само. В идеале — совсем без оператора.
Как задача выглядела после разбора
Хронометраж шестидесяти обращений разложил сорок минут не так, как их представляли в отделе. Набор полей — девять минут. Остальное: разложить пакет и понять, что где, — одиннадцать; заметить, что документа не хватает, — шесть; сверить даты, суммы и имена между документами — восемь; оформить запрос клиенту — шесть. Идеальное распознавание сняло бы девять минут из сорока. Второе выяснилось там же: убирать оператора нельзя, и не потому, что модель слаба. Её ошибка не выглядит ошибкой — неверная сумма возвращается тем же ровным тоном, что верная, — а одно обращение, заведённое с чужой цифрой, стоит дороже, чем экономия на сотне прочитанных верно. Задачу переписали: не «распознать документы», а «разложить пакет, сразу сказать, чего в нём нет, и отдать оператору черновик, в котором видно, откуда взято каждое поле».

Почему нельзя было в лоб

Одно из пяти — свойство самой модели, остальные четыре стояли у заказчика до нас. Ни одно не снимается тем, чтобы взять модель посильнее.

Ошибка модели не выглядит ошибкой
У неверно прочитанной суммы нет ни подчёркивания, ни вопросительного знака: она приходит в том же виде, что верная. Значит, от общей цифры точности толку мало — нужен способ на каждом поле сказать, откуда значение взято и почему ему верят. Всё остальное в архитектуре растёт отсюда.
Пакет собирает не специалист
Клиент фотографирует документы телефоном: угол, блик, палец на краю. PDF на десять страниц, где нужное — на седьмой. Один и тот же чек в трёх качествах. Медиана пакета — двенадцать файлов, максимум в нашей выборке — сорок один.
Персональные данные
В пакете паспортные данные, адреса, номера счетов. Что и в каком виде может уходить за периметр, задала служба безопасности заказчика до начала работы: это было условие, а не предмет обсуждения. Пакет целиком во внешний сервис не уходит ни при каком раскладе.
Учётная система
Своя, писалась годами, менять её никто не дал: наружу торчат API создания обращения и справочники. И её собственное правило: обращение заводит человек, автомат создать запись не может. Это ограничение сняло вопрос о полной автоматизации раньше, чем мы успели его задать.
Эталона не существовало
«Правильный ответ» жил только в виде готового обращения в учётной системе, набранного оператором, и не был привязан к месту на скане. Пока корпус не собрали руками, отличить «стало лучше» от «кажется, стало лучше» было нечем.

Как шла работа

  1. 01

    Замер и корпус

    1 месяц

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

  2. 02

    Разбор пакета

    1,5 месяца

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

  3. 03

    Извлечение и пороги

    1 месяц

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

  4. 04

    Интеграция и параллельная работа

    1,5 месяца

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

Технические решения

Python и FastAPI здесь — обычный выбор для сервиса, который много ходит по чужим API и много ждёт. Интересное начинается там, где к ним добавляется модель: почти каждое решение ниже — про границу доверия, то есть про то, что пайплайн делает молча, что показывает оператору и от чего отказывается.

  • Сначала разложить, потом читать

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

  • Поле без источника — не поле

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

  • Три исхода вместо процента точности

    У поля один из трёх исходов: принято, показать оператору, не берусь. Порог стоит не на числе, которое модель называет своей уверенностью, — уверенной она бывает и когда ошибается. Он стоит на согласии: значение читается дважды и независимо — второй проход по странице и, где документ это позволяет, то же поле из другого документа пакета, — а рядом идут проверки, которым модель не нужна вовсе: существует ли такая дата, сходится ли сумма со строками, есть ли договор с таким номером в справочнике. Разошлось хоть что-то — поле подсвечено. Тот же порог работает и на обращении целиком: из ста обращений пайплайн не берёт двенадцать — пять с бланками, заполненными от руки, три со снимками экрана и сканами, где текста не видно, два с типами документов вне четырнадцати известных, два с противоречиями, которых не разрешает правило. Эти двенадцать оператор разбирает так же, как разбирал раньше.

  • Модель по API, а не своя

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

  • Что уходит наружу и что нет

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

  • Что происходит, когда пайплайн ошибся

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

Что осталось за рамками

Часть этого не входила в работу по решению, часть проверили и решили не выпускать.

  • Рабочее место оператора. Черновик и подсветку рисует команда учётной системы в своём интерфейсе; на нас разбор, координаты и правила — что именно считать сомнительным, договаривались вместе.

  • Рукописные бланки. На корпусе оператор правил в них каждое четвёртое поле против одного процента на печатных: при такой доле подсветка перестаёт помогать, потому что подсвечено всё. Теперь такие обращения пайплайн помечает отказом сразу.

  • Оценка ущерба и сумма выплаты. Пайплайн читает документы и не считает деньги: сколько платить, решают эксперт и правила продукта. Это не следующий этап, а граница, проведённая сознательно.

  • Другие линии страхования. Четырнадцать типов документов и правила полноты собраны под имущественную линию; на другой линии другой набор документов, другой корпус и другие правила. Это перенос, а не настройка.

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

Другие проекты

Все проекты

Контакты

Пришлите описание задачи

Ответ с объёмом работ, сроками и оценкой бюджета придёт в течение 24 часов.

Получить оценку

Первый звонок — 30 минут, без обязательств с вашей стороны.