Что именно проверяла La Foneria

La Foneria — испанская микрокомпания из сферы цифровых гуманитарных исследований. Она помогает музеям, архивам и центрам документации обрабатывать и публиковать оцифрованные коллекции. В карточке European Digital Innovation Hubs указаны размер 1–9 сотрудников и оборот €200 тыс. Один из типовых процессов компании — вручную находить географические названия в массиве из 10 000 изображений, связывать их с контролируемым справочником Dédalo и готовить данные к поиску и публикации.

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

La Foneria вместе с DIH4CAT и группой анализа документов Computer Vision Center провела этап «test before invest». Это важно: речь шла не о покупке готового продукта, а о проверке, можно ли технически автоматизировать конкретный поток документов до крупной инвестиции.

Два маршрута, а не одна «умная модель»

В опубликованном описании выделены два основных маршрута.

  • OCR → NLP/NER. Сначала движок распознаёт текст, затем модель ищет и классифицирует имена, места, центры заключения и типы приговоров. Словари и предметные справочники помогают исправлять варианты написания и привязывать сущности к нормализованным записям.
  • Word Spotting → выборочная транскрипция. Система ищет на изображении слова или устойчивые фрагменты, после чего распознаёт только найденные области. Такой путь может быть полезен для повторяющихся формулировок и сильно повреждённых страниц.

По отчёту, связка OCR и последующей обработки текста дала более многообещающий результат, чем Word Spotting. Распознавание рукописного текста оказалось лучше ожиданий исследовательской команды, а методы Topic Spotting показали потенциал для повторяющихся формулировок. Но числовой точности в карточке кейса нет. Авторы прямо пишут, что нужен более крупный проект с размеченными изображениями и объективной оценкой.

Это главный вывод для бизнеса: «подход выглядит жизнеспособным» и «процесс готов к автоматическому исполнению» — разные статусы. В карточке также приведён план довести решение от TRL 2–3 до TRL 4 к декабрю 2026 года. Это дорожная цель, а не подтверждённый производственный результат. Прогноз удвоения оборота после запуска новых функций тоже остаётся прогнозом компании, а не измеренным эффектом пилота.

Как перенести подход на документы малого бизнеса

Та же логика применима не только к историческим архивам. У производственной, логистической или сервисной компании могут быть тысячи сканов актов, договоров, паспортов оборудования, заявок и старых карточек клиентов. Полезный результат — не «чат с папкой», а структурированная запись, которую можно проверить и передать в ERP, CRM, архив или поисковый индекс.

Практический конвейер выглядит так:

1. Оригинал сохраняется неизменным. Файл получает стабильный идентификатор, контрольную сумму, источник, дату загрузки и правила доступа.
2. Предобработка исправляет поворот, перспективу, шум и сегментацию страницы. Таблицы, печати, рукописные поля и машинописный текст помечаются отдельно.
3. OCR возвращает не только текст, но и координаты блоков и уверенность распознавания. Низкая уверенность должна влиять на последующие решения.
4. Извлечение сущностей формирует поля по утверждённой схеме: контрагент, номер договора, дата, сумма, объект, подразделение или иной бизнес-справочник.
5. Нормализация связывает вариант написания с эталонной записью. «ООО Ромашка», «Ромашка, ООО» и старое название компании не должны превращаться в три независимых контрагента.
6. Человек подтверждает спорные значения. Порог зависит от цены ошибки: неверная тема документа терпимее, чем неверная сумма, персональные данные или основание платежа.
7. В целевую систему уходит только принятая версия вместе с координатами на странице, версией модели, временем проверки и журналом исправлений.

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

Сначала эталон, затем модель

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

В эталон стоит включить:

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

Разметчики должны работать по единой инструкции. Для каждого поля заранее определяют границы, допустимые форматы, правила неопределённости и порядок разрешения конфликтов. Без этого модель сравнивают не с истиной, а с разными мнениями сотрудников.

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

Метрики должны повторять производственный процесс

Одна «точность 90%» скрывает почти всё важное. Измерять нужно каждый этап и итог операции.

  • Для OCR: character error rate и word error rate отдельно по типам документов.
  • Для извлечения: precision, recall и F1 по каждому полю, а не только среднее.
  • Для связывания: доля сущностей, привязанных к правильной записи справочника.
  • Для процесса: доля страниц, принятых без исправлений; среднее время проверки; пропускная способность; очередь и повторная обработка.
  • Для риска: доля ложных подтверждений — ошибок, которые прошли порог и попали в систему без правки.
  • Для экономики: стоимость одной принятой записи, включая подготовку, инфраструктуру, разметку и работу проверяющего.

Опубликованный корпус средневековых документов показывает, насколько широким бывает диапазон даже в исследовательской установке: precision по сущностям менялась примерно от 72,8% до 94,0%, recall — от 58,1% до 81,8% в зависимости от класса. Эти числа нельзя переносить на La Foneria или российские документы; они лишь иллюстрируют, почему средняя оценка без разбивки опасна.

Модельная экономика для 10 000 страниц

Ниже не результат La Foneria, а пример расчёта для руководителя.

Допущения:

  • ручная обработка одной страницы занимает 3 минуты;
  • 60% страниц после пилота принимаются за 45 секунд проверки;
  • остальные 40% требуют 2 минут проверки и исправления;
  • подготовка схемы, выборки, интеграции и тестов требует 120 человеко-часов;
  • стоимость часа сотрудника вместе с накладными расходами задаётся компанией отдельно.

Полностью ручной процесс займёт 500 часов. Проверка автоматизированного потока — около 208 часов: 75 часов для 60% страниц и 133 часа для остальных. Валовая экономия — примерно 292 часа. После 120 часов первоначальной подготовки первая партия даёт около 172 часов чистого выигрыша; следующая сопоставимая партия — уже около 292 часов, если качество документов и схема не изменились.

Денежный предел пилота считается просто:

`допустимая стоимость пилота = сэкономленные часы × полная стоимость часа − инфраструктура − резерв на ошибки`.

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

План пилота на шесть недель

1. Неделя 1: выбрать один документный поток и не более 5–8 полей; зафиксировать ручной baseline по времени и ошибкам.
2. Неделя 2: собрать стратифицированную выборку, инструкцию разметки и замороженный тест.
3. Неделя 3: сравнить минимум два маршрута — полный OCR+NER и более узкий поиск полей или шаблонов.
4. Неделя 4: добавить справочники, пороги уверенности и интерфейс проверки с подсветкой исходного фрагмента.
5. Неделя 5: запустить теневой режим; система предлагает данные, но не записывает их автоматически.
6. Неделя 6: посчитать стоимость принятой записи, ложные подтверждения и время исправления; принять решение о масштабировании.

Условия перехода в продуктив лучше утвердить заранее. Например: ни одного ложного подтверждения по критическим полям в тесте, заданный recall по обязательным реквизитам, измеримое сокращение времени и возможность удалить или переобработать запись по стабильному идентификатору.

Что взять руководителю

Кейс La Foneria полезен не обещанным будущим оборотом, а дисциплиной раннего этапа. Команда разделила задачу на OCR, извлечение и связывание, сравнила маршруты и остановилась на честном выводе: технология перспективна, но для решения об автоматизации нужен размеченный эталон и числовая проверка.

Для собственного пилота возьмите один тип документов, несколько дорогих полей и 200–500 репрезентативных страниц. Сначала измерьте ручной процесс, затем запустите теневой конвейер с человеком на подтверждении. Если после этого нельзя назвать стоимость принятой записи и цену ложного подтверждения, пилот ещё не закончен — независимо от того, насколько убедительно выглядит демонстрация.