Я сделал проверочный слой для PDF-каталогов и Excel: как находить расхождения в товарных данных до того, как они попадут в карточки

В e-commerce и B2B-дистрибуции есть не самая заметная, но очень дорогая проблема: товарные данные живут сразу в нескольких источниках.

Есть PDF-каталог производителя. Есть Excel или выгрузка товарной базы. Есть карточки на сайте. Есть фильтры, подборщики, дилерские кабинеты, прайсы и внутренние справочники.

И всё это должно совпадать.

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

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

Я решил собрать проверочный слой, который помогает находить такие расхождения автоматически, но не делает вид, что может “магически всё исправить”.

Задача была такой: взять технический PDF-каталог производителя и Excel или товарную выгрузку, сопоставить модели и характеристики, нормализовать значения и получить отчёт по расхождениям.

Не как финальное автоисправление, а как безопасный процесс:

PDF + Excel → проверочный слой → размеченный Excel → отчёт → ручная проверка спорных мест.

Для демо я взял публичную выборку по климатическому оборудованию Ballu/BHC. В инженерном оборудовании ошибки в характеристиках могут стоить дорого: неверная мощность, габариты, расход воздуха, напряжение или комплектация могут влиять на фильтры, подбор модели, работу менеджера и доверие дилера.

Сначала кажется: “ну что там, распарсил PDF, сравнил с Excel”.

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

Поэтому проект быстро превратился не в один парсер, а в цепочку обработки:

— извлечение данных из PDF; — построение индекса моделей и характеристик; — классификация таблиц; — сопоставление с Excel или товарными строками; — нормализация единиц измерения; — набор детерминированных правил; — ручная проверка спорных случаев; — генерация размеченного Excel и отчётов.

Главный принцип: лучше честно отправить спорный случай на ручную проверку, чем автоматически “починить” данные неправильно.

На небольшой демо-выборке по Ballu/BHC получилось:

— 110 строк Ballu; — 84 группы связанных BHC-моделей; — 10 групп с конкретными расхождениями характеристик; — 45 отличий по парам поле/значение.

Я специально называю это не “доказанными ошибками”, а кандидатами на ручную проверку.

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

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

Результат — это не только логи для разработчика, а рабочий файл для человека.

На выходе можно получить:

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

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

То есть система не заменяет эксперта по товарным данным, а снимает с него часть рутины и помогает быстрее найти проблемные места.

Сначала мне казалось, что если код стоит рядом с моделью, его можно использовать для маппинга.

После ручной проверки стало понятно: нет.

Иногда это код внутреннего блока или компонента. Иногда — код соседнего товара в визуальном блоке. Иногда — код аксессуара, цвета или варианта исполнения.

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

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

Сейчас модно обещать: загрузите файл, ИИ всё поймёт, всё исправит, всё сделает.

В товарных данных такой подход опасен.

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

Поэтому архитектура проекта такая: сначала правила и ручная проверка, а обучаемый слой — потом.

ML и LLM могут быть полезны как помощники:

— подсказать похожие случаи; — сгруппировать паттерны; — предложить правило; — объяснить, почему строка спорная; — помочь приоритизировать ручную проверку.

Но финальные решения не должны применяться автоматически без валидации.

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

Так появился отдельный режим, который берёт папку с PDF-каталогами и делает разведку в режиме report-only.

Он показывает:

— какие PDF удалось прочитать; — сколько таблиц найдено; — есть ли товарные сигналы; — какие таблицы похожи на уже поддержанные профили; — где нужны новые профили; — какие каталоги можно считать quick win; — какие каталоги лучше пока не обещать автоматизировать.

Важный момент: этот режим ничего не меняет в основной проверке. Он не переписывает данные, не добавляет правила автоматически и не делает вид, что новый каталог уже поддержан.

Он помогает ответить на более практичный вопрос: стоит ли этот каталог брать в следующий этап подключения?

Я не считаю, что такой инструмент нужно сразу продавать как большую платформу “для всех PDF мира”.

Более реалистичный первый шаг — коммерческий пилот на ограниченном наборе данных.

Как это может выглядеть:

— взять небольшой набор PDF-каталогов и Excel-выгрузок; — согласовать объём проверки; — запустить проверочный слой; — получить размеченный Excel и отчёт; — вручную проверить спорные случаи; — понять, какие категории и бренды стоит подключать дальше.

То есть первый продукт — это мини-аудит товарных данных, а не внедрение платформы на весь ассортимент.

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

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

Проект не обещает:

— универсальную автоматическую обработку всех брендов; — автоматическое исправление клиентских данных; — мгновенный SKU-mapping без ручной проверки; — полное покрытие всех категорий без подключения профилей; — автоматическое применение ML-решений; — замену специалиста по товарным данным.

Это проверочный слой, а не автопилот без руля.

В будущем такой проект можно развивать как managed SaaS.

Но не в формате “загрузите любой PDF и получите идеальную правду”.

Более честная модель:

— для поддержанных брендов и категорий проверка работает быстро; — новые каталоги проходят разведку; — под новые категории подключаются профили; — спорные случаи идут в ручную проверку; — клиент получает историю проверок, отчёты и размеченные Excel-файлы.

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

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

Сейчас я ищу 2–3 компании, которым актуальна проблема качества товарных данных.

Если у вас есть PDF-каталоги производителей, Excel-выгрузки, карточки товаров и ощущение, что данные периодически расходятся, можно начать с маленького пилота.

Он может дать:

— размеченный Excel; — отчёт по расхождениям; — список спорных случаев; — оценку непокрытых мест; — понимание, где автоматизация окупится.

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

Для меня этот проект стал хорошим напоминанием: в B2B часто ценность лежит не в самом “умном ИИ”, а в скучной, но важной проверке данных.

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

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

Если вам близка эта боль — напишите мне. Могу показать демо-файл и обсудить небольшой пилот.