OCR для базы знаний: распознанные буквы ещё не проверенный документ

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

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

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

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

Что именно возвращает распознавание помимо букв

Когда говорят «OCR», обычно представляют поток символов. Современные модели разметки документа отдают гораздо больше: области страницы, тип каждой области (текст, таблица, заголовок, колонтитул, картинка), координаты, уверенность по словам. Модель чтения ориентирована на сплошной текст и печатные/рукописные строки, модель разметки — на структуру вроде таблиц и секций; это разные инструменты с разными задачами, и путать их при приёмке нельзя. Об этом прямо сказано в документации Microsoft по модели layout и модели read.

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

Есть и третий слой, о котором забывают: доступность. Если распознанный документ потом показывают человеку в интерфейсе, у изображений страниц должны быть осмысленные альтернативные описания, а не «image1.png». Базовые требования к текстовым альтернативам собраны в руководстве W3C по изображениям — это не про OCR напрямую, но про то, каким документ увидит сотрудник, который им пользуется.

Если ваша задача — проверить распознавание документов, на странице соответствующего направления 404ai можно посмотреть опубликованные возможности и оставить описание текущего процесса. Конкретные подключения, исходные данные и критерии приёмки согласуем отдельно.

Приёмка распознанного документа: паспорт распознанного фрагмента

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

Ключевое свойство паспорта — он живёт до индексации. Пока фрагмент не получил статус, поиск либо не видит его, либо помечает как непроверенный. Это дисциплинирует: нельзя «на всякий случай» залить всё и потом разбираться, потому что непроверенное не притворяется проверенным.

Поворот страницы, из-за которого таблица теряет колонки

Условный эпизод. Отдел закупок загружает сканы спецификаций от поставщика. Один файл — три страницы, средняя повёрнута на девяносто градусов: кто-то положил лист боком при сканировании. Модель разметки текст распознала, но таблица на повёрнутой странице собралась как «строка за строкой», и колонки «артикул», «количество», «цена» слились в одну последовательность значений. В базе знаний появился фрагмент, где количество и цена стоят рядом без разделителя смысла.

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

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

Таблица через разворот: где кончается одна строка

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

Здесь помогает правило границ: таблица считается единой, только если совпадает набор колонок и есть явный признак продолжения (повтор шапки, отсутствие нового заголовка раздела, совпадение числа колонок). Всё остальное — две таблицы, и это нормально. Паспорт фрагмента в этом случае хранит ссылку «продолжение таблицы T-17, страницы 4–5», а не сливает их в один бесформенный кусок.

Смысл таблицы выше в том, что решение принимается по наблюдаемым признакам, а не по «похоже, это продолжение». Каждое решение записывается в паспорт, чтобы потом можно было объяснить, почему строка попала в ответ.

Сноска, которая меняет смысл цифры

Сноска — самый недооценённый элемент приёмки. В договоре стоит «штраф 0,1%», а внизу мелким шрифтом: «если иное не предусмотрено приложением». Если сноска оторвалась от маркера и уехала в конец документа, поиск выдаст «штраф 0,1%» как факт, без оговорки. Формально текст распознан верно, но ответ опасен.

Поэтому в паспорте фрагмента нужна связь «маркер сноски → текст сноски». Проверка на приёмке: у каждого маркера в тексте есть найденная сноска, и наоборот, каждая сноска привязана к маркеру. Сноски без маркера и маркеры без сноски — в спорные. Это дешёвая проверка, которая ловит дорогие ошибки.

Отдельно стоит решить, индексировать ли сноску вместе с основным абзацем или отдельно. Рекомендация: индексировать вместе, но помечать, что фраза содержит оговорку. Тогда система, отвечая на вопрос о штрафе, не сможет процитировать цифру, не показав оговорку рядом.

Рукописная пометка поверх печатного текста

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

На приёмке такие фрагменты нельзя пропускать автоматически. Паспорт должен фиксировать: есть ли в области рукописный слой, какова уверенность, перекрывает ли он печатный текст. Если да — фрагмент идёт к человеку с конкретным вопросом: «рукописная пометка читается как „согласовано с правкой по п. 3“ — верно?». Это не проверка всего документа, а точечный вопрос по спорному месту.

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

Пустой текстовый слой PDF и два документа в одном файле

Два исключения, которые ломают наивный конвейер. Первое: PDF, у которого есть текстовый слой, но он пустой или мусорный — например, скан, прогнанный через старый конвертер. Если конвейер видит «текстовый слой есть» и не запускает распознавание, в базу попадёт пустота или случайные символы. Проверка: если текстовый слой короче разумного порога относительно числа страниц — запускать распознавание по изображению, а не доверять слою.

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

Приёмка распознанного документа на экране сотрудника

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

Сотрудник видит карточку: «Страница 4, таблица, строка 7. Сумма 120 000 стоит напротив товара „Кабель“. Это верно?» Рядом — маленький фрагмент изображения страницы, чтобы можно было сверить глазами, не открывая весь файл. Кнопки: «верно», «неверно, вот правильная привязка», «не знаю, передать дальше». Последняя кнопка важна: она не заставляет человека угадывать.

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

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

Что показывать в ответе базы знаний: проверенное отдельно от предположений

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

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

Тесты приёмки: что и как проверять до индексации

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

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

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

Практикум: приёмка спецификации с тремя ловушками

Возьмём условный документ для упражнения — не тот же, что в эпизодах выше. Спецификация на поставку крепежа: две страницы, на первой таблица «наименование — артикул — количество», на второй продолжение с повторной шапкой, внизу первой страницы сноска «цены указаны без НДС», а на полях второй — рукописная пометка «срок уточнить». Все данные вымышлены.

Шаг первый: разметить ожидания. Сколько таблиц в документе (одна, через разворот), сколько сносок (одна), есть ли рукописный слой (да, на второй странице). Это эталон, с которым будем сравнивать результат.

Шаг второй: прогнать распознавание и собрать паспорта фрагментов. Смотрим на типы областей: таблица должна быть одна с тремя колонками (одинаковыми на обеих страницах при сшивке), сноска — привязана к маркеру у слова «цены», рукописная пометка — отдельный фрагмент с низкой уверенностью.

Шаг третий: прогнать структурные тесты. Если таблица распалась на две — тест на признак продолжения (повтор шапки, совпадение колонок) покажет, что части не сшиты. Если сноска уехала в конец — тест «маркер ↔ сноска» покажет разрыв. Если рукописная пометка слилась с печатным текстом — уверенность фрагмента будет низкой, и он уйдёт в спорные.

Шаг четвёртый: сформулировать вопросы сотруднику. Не «проверьте спецификацию», а три конкретных: «строка 4, количество 500 — верно?», «сноска про НДС относится к ценам в таблице?», «рукописная пометка читается как „срок уточнить“ — верно?».

Шаг пятый: зафиксировать решения в паспортах и только после этого индексировать. Фрагменты без решения остаются непроверенными и в ответах помечаются.

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

Где приёмка упирается в объём и что с этим делать

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

Рекомендация: начать с полной проверки на пилотном наборе документов, чтобы понять, какие ловушки реально встречаются в ваших сканах. Часто оказывается, что 80% проблем — это два-три типа документов (например, повёрнутые спецификации и договоры со сносками). Тогда приёмку можно сузить до этих типов, а остальное пропускать по структурным тестам без ручной сверки.

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

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

Что проверить на следующей загрузке

Исходная задача была простой: не дать распознанному скану притвориться проверенным документом. Решение — принимать не буквы, а структуру: паспорт фрагмента с типом области, родительской таблицей, привязкой сноски и статусом проверки; узкие вопросы сотруднику вместо «проверьте документ»; структурные тесты на поворот, разворот, сноску, пустой слой и два документа в файле.

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

Смежный вопрос разобран отдельно: RAG-система: как ИИ находит ответ в ваших документах.