Каталог на 3-5 тысяч товаров, выгруженный из старой 1С или собранный парсингом с нескольких поставщиков — почти всегда грязный: разные форматы названий, потерянные атрибуты, дубли под разными артикулами. Раньше это разбирали руками неделями. Языковая модель не заменяет эту работу целиком, но снимает большую часть рутины — если процесс построен с проверкой, а не на слепом доверии к выводу модели.
В этой статье — где AI в очистке данных даёт реальный эффект, а где превращается в источник новых ошибок.
Где полезны модели
Языковые модели хорошо справляются с задачами, где входные данные написаны на естественном языке и правило нельзя свести к regexp: разнобой в названиях товаров, свободный текст описаний, нестандартные сокращения поставщиков. Там, где данные уже структурированы и правило однозначное (привести телефон к формату +7, убрать пробелы в артикуле) — модель не нужна, обычный скрипт справится быстрее и без риска придумать лишнее.
Практический критерий: если задачу можно описать десятком regex-правил — пишем скрипт. Если правил становится полсотни и они противоречат друг другу на живых данных — здесь модель эффективнее, потому что обобщает контекст, а не перебирает паттерны.
Нормализация названий
Типичная ситуация после парсинга нескольких поставщиков: одна и та же позиция называется «Кабель ВВГнг-LS 3х2.5», «ВВГ-нг(А)-LS 3*2,5 (кабель)», «Кабель силовой 3×2.5 ВВГнг LS». Формально это разные строки, для каталога — один товар с одними и теми же атрибутами.
Модель хорошо разбирает такие варианты на составляющие: тип изделия, характеристики, стандарт — и приводит к единому шаблону названия. Но результат обязательно прогоняем через проверку по справочнику терминов (если он есть) и выборочный ревью человеком перед заливкой в WooCommerce или 1С-Битрикс — иначе модель может незаметно «поправить» технический параметр, которого на самом деле не меняла.
Категоризация
Разложить полторы тысячи позиций по дереву категорий вручную — это дни монотонной работы. Модели дают на входе название и краткое описание, на выходе — категорию из уже готового дерева (важно: именно из готового списка, а не свободным текстом, иначе получишь двадцать вариантов написания одной категории).
Работает точнее, если модели передают не просто «придумай категорию», а закрытый список с ограничением — выбрать один из существующих пунктов дерева, а при неуверенности — вернуть отметку «на ручную проверку». Процент таких отметок и есть честный показатель качества модели на конкретном каталоге, а не абстрактная «точность 95%», которую никто не считал на твоих данных.
Поиск дублей
Классическая проблема каталогов, собранных из нескольких источников: одна и та же позиция попадает под разными артикулами, потому что у каждого поставщика свой SKU. Точное совпадение строк дублей не найдёт — нужен нечёткий поиск: похожесть текста плюс сверка ключевых атрибутов (бренд, модель, характеристики).
Здесь модель полезна на этапе группировки кандидатов в дубли — она видит, что «Термос Stanley Classic 1L зелёный» и «Stanley Classic Vacuum 1.0L Hammertone Green» — вероятно один товар. Но окончательное решение «слить или оставить» — за человеком: модель не видит контракты с поставщиками, разницу в комплектации или региональные различия в характеристиках, которые в тексте не указаны.
Извлечение атрибутов
Из неструктурированного описания нужно вытащить цвет, размер, материал, вес — то, что должно лечь в отдельные поля товарной карточки, а не остаться внутри текстового блока. Это ровно то, что называют structured extraction: модели дают текст и схему полей, требуют ответ в фиксированном формате (JSON со строгими ключами), а не свободное перечисление.
Важная деталь: для полей, где допустима только конечная выборка значений (например, единица измерения или статус товара), схему стоит ограничивать перечислением, а не открытым текстом — так модель не сможет подставить формулировку, которой нет в справочнике. Для WooCommerce это в итоге ложится в атрибуты товара при импорте через CSV — формат полей и обязательные колонки лучше свериться в актуальной документации импортёра.
Проверка качества и human review
Ни один из перечисленных этапов не запускаем «в одну кнопку» на боевой каталог без промежуточного контроля. Практическая схема, которая работает: модель обрабатывает партию, результат попадает не сразу в базу, а в промежуточную таблицу с полем уверенности и причиной решения. Всё, что ниже порога уверенности или помечено как спорное, уходит в очередь ручной проверки. Только подтверждённые записи попадают в боевой каталог.
Отдельно стоит держать логи: какая версия модели и промпта обработала конкретную партию. Если через месяц найдётся системная ошибка — по логам можно быстро понять, сколько записей она затронула, а не пересматривать весь каталог заново.
Риски галлюцинаций и конфиденциальности
Языковая модель может уверенно выдать неверный факт — придумать модель товара, которой не существует, или домыслить характеристику, которой не было в исходных данных. Это системное свойство генеративных моделей, а не баг конкретного промпта, поэтому единственная рабочая защита — не доверять выводу без сверки с исходником: либо автоматической (совпадение с исходным текстом, справочником, диапазоном значений), либо ручной на выборке.
Второй риск — куда уходят данные. Если в каталоге или базе клиентов есть персональные данные, номера телефонов, адреса — отправка такого текста во внешний API модели требует проверки: какая юрисдикция у провайдера, что написано в его политике обработки данных, не противоречит ли это условиям хранения персональных данных, под которые подпадает бизнес. Для чувствительных данных это отдельный разговор до начала работ, а не деталь, которую решают постфактум.
Пример рабочего конвейера
Не абстрактная схема, а последовательность, которую применяем на практике для каталога, собранного парсингом с нескольких источников:
- Сырые данные попадают в промежуточную таблицу (результат работы вроде услуги «Парсинг сайтов») — без прямой записи в боевой каталог.
- Нормализация названий и извлечение атрибутов моделью — с фиксированной схемой полей и обязательным полем уверенности.
- Автоматическая сверка: атрибуты в допустимом диапазоне, обязательные поля не пустые, категория есть в дереве.
- Поиск дублей по группе кандидатов — нечёткое совпадение плюс сверка атрибутов.
- Всё, что не прошло автосверку или ниже порога уверенности — в очередь human review с оригиналом рядом для сравнения.
- Импорт подтверждённых записей в боевой каталог (WooCommerce CSV-импорт или инфоблоки 1С-Битрикс) — пакетами, с возможностью откатить конкретную партию.
Чек-лист перед запуском AI-очистки данных
- Задача действительно требует модель, а не решается набором regex-правил.
- Для категоризации и атрибутов используется закрытая схема/справочник, а не свободный текст модели.
- Результат модели проходит через промежуточную таблицу, а не пишется в боевую базу напрямую.
- Есть порог уверенности и очередь ручной проверки для спорных случаев.
- Логи хранят версию модели/промпта для каждой обработанной партии.
- Проверена юрисдикция и политика обработки данных провайдера модели, если в данных есть персональные сведения.
- Импорт в CRM/каталог идёт партиями с возможностью отката.
Если каталог собирается из нескольких источников или регулярно обновляется — предварительно оцениваем объём и структуру данных, и только после этого предлагаем конкретную схему очистки под твой случай, а не универсальный шаблон. Опиши каталог и источники данных через форму на сайте — посмотрим, что реально автоматизируется, а что дешевле оставить на ручной проверке.
Частые вопросы
Можно ли доверять модели персональные данные клиентов при очистке каталога?
Не по умолчанию: сначала смотрим, какая юрисдикция у провайдера модели и что написано в его политике обработки данных. Если в каталоге есть телефоны, адреса или другие персональные данные — это отдельный разговор до начала работ, а не то, что решаем постфактум.
Как понять, что модель не начала выдумывать характеристики товаров?
По логам и порогу уверенности: каждая партия проходит через промежуточную таблицу с отметкой, насколько модель уверена в своём ответе, а не сразу попадает в боевой каталог. Всё, что ниже порога или помечено как спорное, уходит в очередь на ручную проверку человеком.
Сколько стоит очистка каталога в несколько тысяч товаров?
Зависит от того, насколько грязные данные и сколько атрибутов нужно вытащить — точную оценку даём после тестовой партии в 50-100 позиций, а не по объёму каталога на глаз. Тестовая партия заодно показывает, какой процент случаев модель решает уверенно, а какой уходит на ручную проверку.