ИИ-поиск по архиву сканов и PDF: как построить пайплайн

Зачем вообще нужен ИИ-поиск по архиву

Обычный поиск по папкам и названиям файлов ломается, когда архив рос годами. Один и тот же договор может называться «договор_финал.pdf», «scan_1234.pdf» или «IMG_0007.jpg». А нужная сумма или дата спрятана внутри страницы, а не в имени. В итоге вы ищете не документ, а угадываете, как его когда-то назвали.

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

Больше всего времени обычно уходит не на «найти папку», а на ручную проверку. Открываете 5-10 похожих PDF, пролистываете страницы, сверяете ИИН/БИН, номера, даты, суммы, переносите данные в таблицу или письмо. И легко пропустить важную строку, особенно если скан кривой или документ многостраничный.

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

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

Какие документы у вас есть и что из них нужно получать

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

Возьмите небольшую выборку (например, 100 файлов) и разложите по типам: договоры, счета, акты, письма, заявления, удостоверения, протоколы. Отдельно отметьте, где текст - это изображение (скан), а где он уже «живой» (цифровой PDF). Часто встречаются гибриды: основная часть - текст, а приложения - сканы.

Языки тоже важны. В Казахстане типично, что в одном файле встречаются русский и казахский, а иногда оба алфавита есть в реквизитах и печатях. Это влияет на распознавание ФИО, адресов и названий организаций.

Дальше решите, какие поля должны появляться в выдаче. Обычно начинают с базового набора: ИИН/БИН, номер документа или договора, дата, сумма и валюта, контрагент (а ФИО и адрес - если действительно нужно).

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

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

Подготовка архива перед обработкой

Качество поиска почти всегда упирается не в «умность» модели, а в то, насколько аккуратно подготовлены файлы до OCR. Если на входе кривые сканы, разрозненные страницы и хаотичные названия, дальше будут ошибки в распознавании, реквизитах и выдаче.

Начните со сканирования. Для большинства договоров, счетов и писем обычно хватает 300 dpi. Если шрифт мелкий, много печатей и подписей, лучше 400-600 dpi. Цвет нужен, когда важны печати, штампы и маркеры. В остальных случаях черно-белый или оттенки серого дают меньше «шума» и меньший размер файлов. Следите за контрастом: слишком темные сканы «съедают» тонкие линии.

Дальше - базовая очистка изображения. Поворот на 90 градусов, перекос, большие поля и пыль от сканера ухудшают точность. Простое правило: если человеку неудобно читать страницу, OCR тоже будет ошибаться.

Отдельная тема - многостраничные документы и приложения. Важно заранее договориться, как храните «договор + приложения + акты»: одним файлом, набором файлов или гибридом. Это влияет и на подсветку фрагментов, и на то, как не терять контекст.

Чтобы потом не гадать, что откуда взялось, полезно ввести минимальный стандарт на входе: понятные имена файлов (дата, тип, номер), отметка источника (бумажный архив, e-mail, выгрузка из системы), идентификатор папки или дела, язык документа и признак «скан» или «цифровой PDF».

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

OCR: превращаем сканы в текст, пригодный для поиска

OCR (распознавание текста) берет изображение страницы и превращает его в текст. Это базовый шаг: пока документ остается картинкой, поиск работает только по имени файла и редким метаданным.

Ошибки OCR обычно типовые: путаются похожие символы (0/О, 1/І), теряются пробелы, склеиваются слова, неправильно читаются даты и номера. Чем хуже скан (косой лист, тень, размытость), тем больше ручной проверки понадобится.

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

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

Качество проверяйте на выборке, а не «по ощущениям». Возьмите 50-100 страниц разных типов и сравните ключевые поля (даты, суммы, номера) с оригиналом. Отдельно отметьте источники и шаблоны, где чаще всего случаются критические ошибки.

Для подсветки фрагментов важно хранить не только распознанный текст, но и координаты слов на странице (bounding boxes) и номер страницы. Тогда система покажет точный кусок документа, а не заставит пролистывать десятки PDF.

Классификация документов: чтобы не смешивать все в одну кучу

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

Классификация дает два понятных выигрыша. Во-первых, можно искать по типам: «найди счет» или «покажи доверенности за месяц». Во-вторых, для каждого типа можно применять свои правила: для счета важны суммы и НДС, для договора - сроки и стороны, для заявления - ФИО и дата.

На старте обычно хватает 5-10 самых частых типов (например: договор, счет, акт, доверенность, заявление) и класса «прочее».

Отдельная проблема - «смешанные пакеты», когда один PDF содержит разные документы или сканировали пачку одним файлом. Здесь помогает классификация по страницам: система помечает тип каждой страницы и собирает из них логические документы. Например, первые 2 страницы - счет, дальше 3 страницы - акт.

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

Извлечение реквизитов: ИИН/БИН, номера, даты, суммы

Реквизиты - короткие поля, по которым чаще всего ищут и сверяют, не читая документ целиком. Для бухгалтерии это номер счета и сумма, для юристов - дата договора и номер приложения, для кадров - ИИН, для закупок - БИН поставщика и номер накладной.

На практике реквизиты вытаскивают комбинацией подходов. Простые случаи берутся шаблонами (например, ИИН/БИН как 12 цифр). Там, где формат «гуляет», помогают ключевые слова рядом («ИИН», «БИН», «Сумма», «Итого», «№», «от»). Для сложных форм нужен контекст: по соседним словам модель определяет, что рядом с «к оплате» обычно сумма, а рядом с «от» - дата.

Чтобы вариативность не ломала процесс, полезно нормализовать текст заранее: склеивать переносы, чистить лишние пробелы, приводить похожие символы (O/0, I/1), приводить даты к единому формату. Отдельно учитывайте разные сокращения: «№», «N», «номер», «тенге», «тг», даты вида 01.02.24 и «1 февраля 2024».

Контроль качества лучше сделать обязательным. ИИН/БИН - ровно 12 цифр. Даты - допустимые форматы и разумный диапазон лет. Суммы - валюта, разделители и понятные диапазоны. Номера - допустимые символы и защита от обрезки из-за переноса.

Храните не только значение, но и источник: страницу и координаты или строку, откуда оно взято. Тогда можно не просто показать «сумма 1 250 000», а сразу подсветить место в документе и быстро проверить глазами.

Индексация: как сделать быстрый и удобный поиск

Индексация превращает обработанный архив в быстрый поиск: вы вводите запрос и сразу видите подходящие документы, а не ждете, пока система перечитает все PDF.

Практично делать два слоя. Первый - точный поиск по реквизитам (дата, номер, ИИН или БИН, сумма, контрагент). Второй - поиск по полному тексту после OCR, чтобы находить формулировки и редкие детали. Вместе это покрывает и строгие запросы, и «помню, что там было про гарантию/поставку/акт».

В индекс обычно кладут распознанный текст с привязкой к страницам, извлеченные поля и их варианты (например, номер без пробелов), тип документа, ключевые даты и суммы, а также контекст доступа (подразделение, проект, владелец).

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

Чтобы поиск не ломался от опечаток и разных написаний, используйте нормализацию: единый регистр, очистку пробелов, альтернативные формы имен (например, «ТОО Ромашка» и «Romashka LLP»), нечувствительность к раскладке и мягкое исправление опечаток.

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

Ответы с подсветкой фрагментов: меньше открытия PDF вручную

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

Обычно достаточно «сниппета» на 1-3 предложения вокруг найденной строки плюс подписи, откуда это взято (файл и страница). Контекст важен: сумма без валюты или дата без пояснения («дата оплаты» или «дата договора») легко вводят в ошибку.

Отдельный режим - вопросы, когда человек хочет не слово, а значение: «какая сумма», «какой срок», «кто подписант». Хороший ответ выглядит как «значение + подтверждение»: например, «Сумма: 1 250 000 KZT» и рядом цитата из документа, где это написано.

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

По UX решают мелочи: предпросмотр страницы с подсветкой, быстрый переход к месту совпадения и копирование реквизитов в один клик.

Пошаговый план внедрения пайплайна

Начинайте не с идеи «обработать весь архив», а с пилота, который дает измеримый результат за 2-4 недели. Выберите 1-2 понятных сценария: быстро найти договор по номеру и дате, или поднять все счета за период с нужной суммой.

План пилота

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

2. Настройте OCR и проверьте качество на выборке. Возьмите 200-500 файлов разного качества (сканы, фото, PDF) и проверяйте не «процент распознавания», а то, находятся ли ИИН/БИН, номера, даты, суммы, названия организаций.

3. Добавьте классификацию и извлечение реквизитов. Начните с 5-10 самых частых типов, чтобы применять правильные правила для каждого.

4. Соберите индекс и откройте поиск ограниченной группе. Лучше 10-20 пользователей, которые каждый день работают с архивом. Сразу дайте фильтры по реквизитам и поиск по тексту.

5. Включите подсветку и соберите обратную связь. Просите отмечать «верно/неверно», чего не хватило, где OCR ошибся. Это быстрее всего улучшает качество.

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

Частые ошибки и ловушки при запуске

Самая частая причина разочарования - попытка сделать все идеально с первого дня. Система обычно «сыпется» не из-за модели, а из-за качества входных данных и организационных мелочей.

Первая ловушка - брать сразу все типы документов. Для системы договоры, счета, приказы и акты - это разные шаблоны, поля и лексика. Начните с 1-2 самых важных классов, доведите точность до приемлемого уровня и только потом расширяйтесь.

Вторая ловушка - надеяться, что OCR вытянет плохие сканы. Перекос, штампы поверх текста, мелкий шрифт, копии копий резко бьют по качеству. Часто дешевле один раз наладить сканирование или пересканировать часть архива, чем долго лечить последствия.

Третья ловушка - хранить только извлеченные поля и терять связь с первоисточником. Пользователю нужно одним взглядом понять, откуда взята сумма или дата. Без привязки к странице и координатам доверия не будет.

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

Практический пример: бухгалтерия ищет «счет на оплату от 12.03» и получает почти верную дату из-за смазанной печати. Без проверок и без подсветки строка выглядит как факт и уходит дальше в отчет. С проверками и ссылкой на конкретный фрагмент такие ошибки ловятся быстро.

Быстрый чеклист перед стартом

Перед запуском полезно сделать короткую проверку. Это занимает час-два, но экономит недели на переделках.

Сначала договоритесь, что именно вы ищете и что считается «готовым ответом». Одним важнее быстро находить договор, другим - за минуту собрать суммы и даты по счетам.

Проверьте несколько пунктов: определены типы документов и 3-5 реквизитов, которые нужны первыми (номер, дата, сумма, ИИН/БИН, контрагент); понятны правила доступа и конфиденциальности; выбраны метрики успеха (время до результата, точность реквизитов, доля ручной проверки); подготовлен пилотный набор (200-500 файлов) и «эталонные ответы»; запланировано хранение OCR вместе с координатами на странице для подсветки.

Отдельно назначьте владельца процесса. Нужен человек или роль, кто принимает качество, решает спорные случаи (например, что считать «датой договора») и собирает обратную связь.

Простой тест перед пилотом: возьмите 20 документов разных типов и попросите двух сотрудников найти один и тот же реквизит. Если они делают это по-разному, правила стоит уточнить заранее.

Реалистичный пример и следующие шаги

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

Сценарий работы выглядит так: сотрудник вводит запрос «договор № 18/07 сумма 12 500 000» или «18/07 12,5 млн», затем сужает выдачу фильтрами по периоду, контрагенту и типу документа. В результатах он сразу видит подходящие файлы и подсвеченные фрагменты с номером, суммой и датой. Если нужно, реквизиты выгружаются в таблицу для сверки без ручного перепечатывания.

Чаще всего люди открывают десятки PDF из-за трех вопросов: где указан срок действия или срок оплаты, какая итоговая сумма и валюта, кто подписал и есть ли печать или подпись. Подсветка закрывает это быстрее всего.

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

Следующие шаги обычно такие: пилот на ограниченном архиве (1-2 вида документов за 3-6 месяцев), настройка извлечения полей, проверка качества и только потом масштабирование на весь архив. Если решение нужно развернуть на собственной инфраструктуре и увязать с корпоративными системами, здесь помогает опыт системного интегратора. Например, GSE.kz может подобрать и поставить серверную часть (включая отечественные серверы), собрать инфраструктуру под обработку документов и обеспечить поддержку 24/7 через свою сервисную сеть.