/api/v1/fill принимает пустую форму и ваши значения, а затем возвращает форму с введенными в нее данными. С сегодняшнего дня этот процесс работает на базе нашего агента по работе с документами, а не через старый конвейер.
API не изменился. Тот же эндпоинт, тот же запрос, те же поля output_base64 / fields_filled / fields_not_found в ответе. Изменилось то, как выполняется работа, и — что более важно — проверяется ли результат ее выполнения.
Вот пример на форме CERFA 12485, французской медицинской форме, поля которой размечены бледно-голубым цветом, а номер страховки состоит из пятнадцати отдельных ячеек для одного символа:
Стоит прочитать вторую строку этой формы: inscrire les chiffres lisiblement — un chiffre par case (пишите цифры разборчиво — по одной цифре в клетку). Никто не передавал это правило в API. Оно напечатано на странице, на французском языке, и оно соблюдается: номер страховки поступает как 1 85 03 75 116 042 38, а дата как 14/03/2018, и у обоих удалены разделители, поэтому в каждую напечатанную ячейку попадает ровно один символ, измеренный относительно разделителей, а не просто равномерного деления строки.
В этом и заключается разница между заполнением формы и написанием текста по координатам. Форма определяет, как она должна быть заполнена, и эти инструкции являются частью документа.
Проблема старого дизайна
Предыдущий конвейер рисовал текст по заданным координатам. Основная проблема заключалась в том, что не было простого способа проверить результат для каждого поля, а также внести корректировки или перерисовать его.
Измерение вместо угадывания
Новый профиль получает геометрию из данных, которые можно измерить:
- Позиции слов из парсинга. Наш парсер уже возвращает ограничивающую рамку (bounding box) для каждого слова на странице, поэтому мы можем определить, где именно нужно вписать значения формы.
- Пустые области на основе чернил страницы. Линии, рамки и границы ячеек определяются путем анализа пикселей.
- Размещение относительно привязки. Мы можем определить, где записывать значения полей относительно меток.
Для флажков мы используем многопроходный подход, при котором изолируем область, требующую отметки.
Проверка результата
Агент выполняет девять проверок созданного документа:
- каждое значение, которое, как предполагается, было размещено, визуально присутствует в предназначенной для него области
- каждое значение находится на линии или в рамке, в которую оно было вписано
- чернила не выходят за пределы объявленных областей
- исходный документ сохранен — ничего не стерто
- внутри одной исключающей группы не выбрано два варианта
- каждое записанное значение соответствует вашим данным (ничего не выдумано)
- каждый отправленный вами ключ учтен: либо заполнен, либо явно помечен как отсутствующий
- все значения находятся в правильных ячейках
- значения аккуратно расположены внутри ячеек
Вторая проверка новее остальных, и она существует из-за пробела, который другие не могли заметить. Значение может присутствовать в своей области, соответствовать вашим данным и находиться внутри всех границ, но при этом «парить» над линией, к которой оно относится — область, которую форма оставляет для значения, обычно выше самого значения. Все проверки проходили, но страница все равно выглядела неправильно для человека. Эта проверка сопоставляет каждое значение с напечатанной линией или ячейкой, в которую оно попало, поэтому, если заполнение выглядит неровным, оно перерисовывается, а не возвращается как готовое.
Доказательство и выявленные проблемы
Мы создали эталонный набор из 22 общедоступных государственных форм — IRS, USCIS и OPM в США, CERFA во Франции, Национальное налоговое агентство в Японии, IRCC в Канаде.
За 88 прогонов на идентичных входных данных с тем же механизмом оценки:
Медианная стоимость составляет около $0,03 за форму.
В рамках этой работы мы также нашли и исправили несколько ошибок:
Ячейки для отдельных символов получали многосимвольные фрагменты. Французский номер страховки на CERFA 12485 состоит из 15 отдельных ячеек для одного символа. Старый конвейер записывал '3 7' и '75 1' в ячейки, предназначенные для одного символа каждая. Новый агент разделяет их правильно.
Обе панели — это одна и та же форма и одни и те же входные данные, пропущенные через каждый конвейер.
Заполнялись листы продолжения. В форме I-765 старый конвейер записывал имя заявителя в Часть 6, «Дополнительная информация» — страницу, используемую только в том случае, если нужно дополнительное место — для листа, не имеющего контента.
Формы без текстового слоя
Ничто из этого не зависит от того, является ли форма цифровой. Сканированное изображение не имеет текстового слоя и полей формы, поэтому каждая позиция должна определяться по пикселям. Это растрированная форма SF-144, заполненная через тот же вызов API — обратите внимание на даты, распределенные по ячейкам Год / Месяц / День, и две отмеченные галочки:
Использование
Ничего менять не нужно. Выполняйте POST /api/v1/fill с вашим документом и field_data, как и раньше.
field_data сопоставляет ваш ключ со значением и необязательным описанием. Описание помогает уточнить поле, когда в форме есть несколько подходящих мест для него, поэтому его стоит заполнять:
Это вызов, который создал французскую форму выше.
Вложенность работает и преобразуется в ключи, о которых говорит отчет — {"employee": {"name": {...}}} возвращается как employee.name, а список блоков как documents[0].title. Это полезно, когда форма повторяет блок, как в I-9 и 2848.
Обычный HTTP, если вы не используете SDK. Эндпоинт работает по принципу submit-and-poll: он возвращает request_id и request_check_url, и вы опрашиваете этот URL до тех пор, пока статус не станет complete.
Завершенный ответ содержит заполненный документ в формате base64 вместе с двумя списками:
Изображение на входе дает изображение на выходе — output_format сообщает, что вы получили, потому что форма — это документ, который кто-то подает, и изменение его типа нарушает этот процесс.
Читайте fields_not_found — каждый отправленный вами ключ возвращается в одном из списков, поэтому значение, которое не удалось разместить, будет зафиксировано, а не записано в случайное место. confidence_threshold по-прежнему принимается, но больше ничего не делает: он ограничивал показатель уверенности, который старый конвейер заставлял модель выдумывать о своей собственной работе. Проверка полученного документа — лучший вопрос, чем спрашивать модель о том, что она «чувствовала» по поводу документа на входе.