Предыстория этого кейса довольно типична для малых и средних производственных предприятий.

По одному из видов продукции за годы накопилось около 100 ГБ конструкторских данных, из них 17 ГБ - PDF-документация. Архив представлял собой множество папок без единой структуры хранения: по датам, номерам заказов и проектам, с вложенными каталогами. Всего в нем находилась документация примерно на 1500 щитовых затворов - включая дубли и разные версии изделий.

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

Проект начался с моей инициативы систематизировать архив.

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

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

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

Первая рабочая версия сохраняла найденные поля в JSON-карточках и собирала общий Excel-каталог с формой поиска. Затем я перенес систему в веб-приложение.

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

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

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

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

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

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