Онтология-справочник дверей: от прайсов к PIM
Производитель и дистрибьютор дверей работал с разрозненными прайсами и справочниками. Построил единую онтологию через AI-нормализацию и реляционную модель, закрыв совместимость и масштабирование каталога без ручной синхронизации.
2–3 дня
→ 1–2 часа
добавление новой линейки
100%
совместимости
валидация без ручной проверки
0
некорректных заявок
из-за несовместимых комплектаций
5×
скорость обновления
ассортимента
Проблема
Каталог собирался из разрозненных прайсов производителя и дистрибьютора. Проверка совместимости — замки, петли, отделка, спецификации дверей — была полностью ручной, создавала ошибки в заявках клиентов и замораживала обновление ассортимента на дни.
Решение
Пятиэтапный конвейер: сбор неструктурированных данных из PDF, XLS, каталогов → AI-нормализация сущностей и извлечение атрибутов → проектирование реляционной онтологии (дверь → фурнитура → отделка → ограничения) → описание матрицы совместимости и бизнес-правил → интеграция в фронтенд-каталог с автоматической валидацией заказов.
Результат
Добавление новой линейки сократилось с 2–3 дней ручной работы до 1–2 часов ввода SKU + автоматизация. Ошибки несовместимости в заявках исчезли. Справочник стал масштабируемой базой для B2B интеграций. На базе этой модели запущены фильтры на сайте и API для партнёров.
Контекст и проблема
Клиент — производитель и дистрибьютор высокоёмких дверей (входные, межкомнатные, спецдвери). В каталоге — сотни SKU, каждая дверь комплектуется с десятков позиций: замки, петли, доводчики, отделка, спецификации. Данные по моделям и фурнитуре приходили из разных источников: PDF прайсы от производителя, Excel-таблицы от дистрибьютора, техническая документация в неструктурированном виде.
Процесс добавления новой линейки:
- Менеджер контента получает прайс от производителя.
- Вручную создаёт в CMS позиции двери и комплектующих.
- Вручную проверяет совместимость: подходит ли замок к этой двери, правильная ли отделка, не конфликтуют ли спецификации.
- При ошибке выясняется при переговоре с клиентом, заявка отправляется в доработку.
- Если в каталоге жёсткая комплектация без предупреждений — ошибка попадает в заказ.
Масштаб проблемы: 2–3 дня на одну новую линейку. При росте поставщиков добавляется ручная синхронизация и перепроверка. Ошибки совместимости — это возвраты, переписка и репутационный риск.
Вовлечённые роли: менеджер контента (исполнитель), операции (дедлайн на интеграцию), продажи (некорректные комплектации на сайте), техподдержка (переговоры с недовольными клиентами).
Ключевая проблема — не скорость сбора, а отсутствие единого источника истины: нельзя автоматизировать валидацию без явного описания правил совместимости.
Решение: пятиэтапная конвейеризация
Идея: раз и навсегда описать онтологию (что может комплектоваться с чем), чтобы новые данные валидировались автоматически, а каталог был единым источником истины.
PIM-онтология в интерфейсе
Текущая рабочая версия онтологии оформлена как ZERRUS PIM v3.0 FINAL: в ней зафиксированы 17 канонических словарей, 25 бизнес-правил и табличная матрица совместимости по категориям. Это не просто документация, а оперативный интерфейс для операций и контент-команды.
Этап 1: сбор и нормализация неструктурированных данных
Исходный материал: PDF-прайсы, Excel-таблицы, техническая документация. Используется Yandex AI для извлечения структурированной информации:
- Модель двери, артикул, размеры, вес
- Фурнитура (замки, петли, доводчики)
- Отделка (краска, ламинат, натуральный шпон)
- Спецификации (противопожарные, противовзломные, акустические, климатические границы)
Результат: JSON-схема с явным игнорированием шума из источников (опечатки, форматирование).
Этап 2: проектирование онтологии
На основе нормализованных данных выстраивается реляционная модель:
дверь (SKU, размер, материал базовый, вес, спецификации)
↓
фурнитура (замок, петли, доводчик, ручка)
↓
отделка (тип, цвет, текстура)
↓
ограничения совместимости (правила)
Правила задаются явно в SQL / Python:
- Замок X подходит к двери типа A и B, но не C
- Отделка Y поддерживает только замки Z1, Z2 (по эстетике и функциональности)
- Спецификация «противопожарная» несовместима с определёнными материалами отделки
- Вес комплектации не должен превышать Y кг (ограничения на монтаж)
Этап 3: автоматическая валидация при добавлении новой двери или фурнитуры
При загрузке нового SKU система:
- Классифицирует тип двери и фурнитуры.
- Применяет матрицу совместимости.
- Выделяет конфликты: несовместимая комбинация, недопустимые спецификации и т. д.
- Блокирует добавление без разрешения администратора (с полным отчётом о конфликте).
Это требует разово затратить время на описание правил, но потом система работает сама.
Этап 4: интеграция в фронтенд-каталог (zerrus.ru)
Справочник данных синхронизируется с фронтенд-каталогом:
- Фильтры строятся на основе совместимости (если выбрана дверь типа A, доступны только совместимые замки).
- Подсказки при конфигурации: «На эту дверь рекомендована отделка X».
- Защита от ошибок: при выборе несовместимой комбинации — явное предупреждение перед добавлением в корзину.
Этап 5: API для B2B-интеграций
На основе эталонного справочника выстраивается REST API для партнёров:
- Получить совместимые комплектации для дверь SKU
- Валидировать комплектацию перед заказом
- Синхронизировать свежие данные из каталога
Партнёры могут интегрировать эту валидацию в свои системы — улучшает их качество данных и снижает возвраты.
Ключевые архитектурные решения
Почему AI используется только на входе (нормализация), а не для валидации? Совместимость — это детерминированная бизнес-логика, а не семантическое решение. AI помогает распарсить прайс и извлечь атрибуты, но валидация конфигурации — это SQL-запросы и явные правила. Это дешевле, надёжнее и аудируемо. Нет риска, что LLM выдаст случайный результат на одну и ту же комплектацию.
Почему хранить правила в коде / SQL, а не в UI-инструменте? Альтернатива: BPM-система или но-код платформа для управления правилами. Минус: при масштабировании сложно отслеживать, какие правила действуют, тяжело версионировать. Решение: правила в коде (версионируются в Git), фронтенд для аналитиков (читает из БД), разработчики обновляют логику PR-ом.
Почему стартовать с zerrus.ru, а не с B2B-системы? B2C даёт немедленный feedback: ошибки совместимости видны в заказах и возвратах. B2B интеграции можно добавить позже, когда модель уже стабилизирована. Так снижается риск — вначале убедиться, что сама модель корректна.
До и после
| Параметр | До | После |
|---|---|---|
| Время на новую линейку | 2–3 дня (ручная работа) | 1–2 часа (ввод SKU + валидация) |
| Ошибки совместимости | Выявляются при переговоре клиента | Исключены системой |
| Источник истины | Разрозненные таблицы | Единая онтология в БД |
| Фильтры в каталоге | Жёсткие, вручную | Динамические на основе совместимости |
| B2B интеграция | Нет | REST API с валидацией |
| Масштабирование | Лимитировано людьми | Линейно с объёмом данных |
Стек
- Нормализация данных: локальный пайплайн Python (spaCy, pandas, regex-правила) без облачных LLM
- Бизнес-логика: Python (Pydantic, SQLAlchemy), PostgreSQL
- Оркестрация: локальный
n8n(self-hosted) — загрузка данных, запуск валидаций, синхронизация с каталогом - Инструменты: Cursor (IDE), локальные скрипты ETL и миграции БД
- Фронтенд интеграция: REST API, webhook для уведомлений о конфликтах
Результат
Масштабируемость: новая линейка добавляется за 1–2 часа вместо 2–3 дней. Это было узким местом; сейчас операции могут добавить поставщика в один спринт, а не ждать недели.
Качество данных: ошибок совместимости нет. Клиент не получает заказ с несовместимой конфигурацией.
Автоматизация: менеджер контента работает с интерфейсом, не с SQL. Он вводит SKU, система сама проверяет правила и докладывает о проблемах.
Позиция для роста: на этой модели можно строить B2B API, рекомендации (к этой двери подходит вот эта отделка и замок), прогнозирование спроса. Единая онтология — фундамент для будущих фич.