Перейти к содержимому
Бизнес-анализ

Сверка двери по фото с корпоративными справочниками

Ручная оценка, можно ли реализовать дверь по референсу, занимала 5-10 минут и зависела от опыта сотрудника. Построил пайплайн: загрузка фото референса, распознавание типа товара и элементов двери, сверка с внутренними справочниками отделок и фурнитуры, формирование протокола сверки с расхождениями, заменами и недостающими позициями.

10–15×

ускорение обработки

5-10 мин -> 20-30 с

3 класса

признаков в сверке

ручка, отделка, фурнитура

0

дополнительных людей

при росте потока

100%

аудируемый след

протокол по каждому референсу

Проблема

5-10 мин10 мин

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

Решение

Пятиэтапный пайплайн: загрузка фото референса двери → vision-анализ и выделение признаков → сопоставление признаков с внутренними справочниками (типы товара, ручки, отделки, фурнитура) → проверка совместимости и комплектности → формирование протокола сверки с совпадениями, расхождениями, заменами и недостающими позициями.

Результат

~20–30 с5-10 мин30 с10 мин

На демо-наборе: ~20–30 с на референс вместо 5-10 минут вручную + единый протокол сверки для принятия решения.

Контекст и проблема

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

Даже при 20-30 референсах в день процесс занимал значимое время: сотрудник сверял фото с несколькими справочниками, делал вывод "реализуемо / не реализуемо" и оформлял комментарии вручную в свободной форме. Из-за этого решения были неоднородными и плохо воспроизводимыми.

Вовлечённые роли: менеджер по продажам, технолог, владелец.

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

Решение: пятиэтапный пайплайн

Идея: автоматизировать первичную техническую сверку и оставить эксперту только подтверждение спорных пунктов.

  1. Приём референса — фото двери (одно или несколько), комментарий клиента и контекст заказа из CRM/формы.

  2. Vision-распознавание двери (AI) — модель выделяет конструктивные и визуальные признаки: тип товара/двери, вероятный тип ручки, вид отделки, элементы фурнитуры, дополнительные узлы.

  3. Нормализация признаков — признаки приводятся к формату внутренних справочников (синонимы, варианты написания, визуально похожие элементы).

  4. Сверка со справочниками (код + AI) — система сопоставляет найденные признаки с эталонами: Справочник типов товара, Справочник ручек, Справочник отделок, Справочник фурнитуры, проверяет правила совместимости, наличие аналогов и комплектность.

  5. Протокол сверки (код) — на выходе структурированный документ: что распознано, что найдено в справочниках, какие расхождения есть, чего не хватает в текущей номенклатуре, какие замены допустимы, итоговый статус: Реализуемо, Реализуемо с заменами, Не реализуемо.

Ключевые архитектурные решения

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

Почему выделен слой сопоставления со справочниками? Справочники в компании живут отдельно и регулярно обновляются. Выделенный слой позволяет менять структуру и версии справочников без переписывания vision-части.

Почему n8n для оркестрации? Альтернативы рассматривались: Airflow (избыточен для небольших потоков), custom Python (сложно поддерживать бизнесу). n8n даёт визуальный граф процесса: от фото до протокола сверки, понятный как техкоманде, так и бизнесу.

До и после

ПараметрДоПосле
Время на референс5-10 минут (ручная экспертная оценка)~20-30 секунд (автоматическая сверка)
Основа решенияОпыт конкретного сотрудникаФормальные правила + справочники
АртефактСвободный комментарийСтандартизованный протокол сверки
Роль сотрудникаПолная ручная проверкаПодтверждение спорных случаев
АудируемостьЧастичнаяПолная трассировка по полям и справочникам
AI-провайдерЛокальный контур (on-premise), без внешнего API

Стек

  • AI (on-premise): Ollama + Qwen2.5-VL (или Llama 3.2 Vision) — локальное распознавание двери по фото, выделение признаков и вероятных классификаций.
  • Детерминированная логика: сопоставление со справочниками, проверка совместимости, расчет статуса реализуемости, формирование протокола — Python + Pydantic.
  • Оркестрация: n8n — визуальный граф, который можно передать команде.
  • Инфраструктура: Python 3.11, FastAPI, Pillow / OpenCV (предобработка изображений), Docker.

Результат

Скорость: ~20-30 с на референс вместо 5-10 минут вручную — ускорение первичной сверки на демо-наборе.

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

Цель процесса закрыта: можно быстро и формально ответить на ключевой вопрос бизнеса — возможно ли реализовать подобную дверь по референсу в текущей номенклатуре.

Формат результата: итог выдается в виде протокола сверки, пригодного для согласования с клиентом, технологом и отделом продаж.

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