Задайте эталон до загрузки каталога
Проверка карточек работает лучше, когда у команды есть компактная схема: название, артикул, материал, размер, совместимость, комплектация и обязательные предупреждения. Список зависит от категории и не должен быть одинаковым для всех товаров. Сначала согласуйте требования с владельцем каталога и специалистом, который отвечает за точность характеристик. Модель не должна выбирать правила после того, как увидит данные: иначе она подгонит проверку под привычный формат и пропустит системную ошибку. Для каждого обязательного поля укажите допустимые единицы и источник, например спецификацию поставщика или утверждённую базу. Если два источника расходятся, статус карточки должен стать «нужно решение», а не «готово».
Разделите факт, формат и стиль
В одном проходе не просите и проверить цифры, и сделать текст продающим, и придумать недостающие особенности. Разбейте задачу. Сначала модель сверяет наличие и формат атрибутов; затем отдельно предлагает редакторскую правку, сохраняя исходные значения. Для каждого предложенного изменения показывайте «было — стало — причина». Так контент-менеджер может принять удачную формулировку, не соглашаясь автоматически с сомнительным фактом. Запретите модели добавлять влагозащиту, совместимость или гарантию, если этого нет в подтверждённом источнике. Отсутствие данных — отдельная пометка для владельца каталога, а не приглашение к генерации.
Соберите таблицу контроля
Один ряд — одна карточка, один столбец — одно проверяемое свойство. Результат удобно хранить в колонках «атрибут», «значение в карточке», «эталон», «статус», «фрагмент-основание» и «решение человека». Пусть модель возвращает фиксированную структуру, а не свободный абзац: тогда строки можно фильтровать и передавать на ручную проверку. Для каждого замечания сохраните источник, который использован для сравнения, и отметьте, если его нет. Не включайте в таблицу лишние данные покупателей или внутренние договорённости, не нужные для проверки товара.
Пилотируйте на неоднозначных позициях
Возьмите 40–60 карточек: простые, неполные, с разными единицами, комплектами, вариациями цвета и похожими артикулами. До запуска попросите двух сотрудников независимо отметить ожидаемые ошибки. Затем сравните предложения модели с их разметкой. Важно измерить не только найденные пробелы, но и ложные тревоги: если почти каждую карточку приходится заново перепроверять, очередь лишь переносит ручную работу. Отдельно проверьте случаи, где названия похожи, а товар разный. Система должна объяснить сопоставление через артикул или подтверждённое правило, а не один общий термин.
Ограничьте права на изменение
Для первого запуска интеграция должна работать в режиме чтения. Результат — список замечаний, а не автоматическое обновление сайта. После нескольких циклов команда может разрешить сохранение черновика с версионированием, но публикацию всё равно оставьте за редактором. У каждого поля должно быть действие «принять», «отклонить» или «передать специалисту». Записывайте, кто подтвердил атрибут и из какого источника. Если вы используете API, уточните срок хранения каталога, повторное использование данных и возможность удалить их после теста.
Считайте эффект по исправленным ошибкам
До пилота зафиксируйте время проверки одной карточки, долю карточек с пропусками и число возвратов после публикации. После теста сравните те же показатели на сопоставимой категории. Не считайте количество комментариев модели мерой пользы: длинный отчёт может увеличить нагрузку. Полезная система находит проверяемые проблемы, указывает причину и сокращает время до решения. Через две недели пересмотрите правила на реальных ложных срабатываниях, но не подменяйте ими исходные данные без согласования с владельцем каталога.
Разберите спорные значения отдельно
Если карточка содержит сразу несколько вариантов — например, один товар в разных размерах или комплектациях, — сначала проверьте, к чему относится каждое поле. Модель может склеить данные родительской позиции и отдельного варианта. Для пилота попросите вывести идентификатор SKU и источник каждого атрибута. Затем сравните результат на карточках, где размер меняет совместимость, а цвет — только отображение. Если система не уверена, она должна оставить поле в очереди, а не копировать значение из соседней строки. Установите минимальный порог качества по каждому критичному атрибуту отдельно: правильная категория не компенсирует ошибочную мощность или объём. Для незначимых описательных полей допустим другой уровень ручной проверки, но это решение принимает редактор каталога. Запишите правила принятия так, чтобы следующий сотрудник понял, почему один флаг остановил публикацию, а другой стал обычной редакторской задачей.
Организуйте исправление по приоритету
Не все замечания требуют одинаковой срочности. Разделите их на блокирующие публикацию факты, важные для поиска и описательные улучшения. Ошибка в напряжении устройства или составе набора может привести к возврату; повтор слова в абзаце обычно решается редакторской правкой. Попросите модель объяснять серьёзность через последствие и поле, но итоговую категорию подтвердит владелец каталога. Назначайте каждой задаче ответственного и срок, а после правки повторно проверяйте только изменённые атрибуты и связанные варианты. Сохраняйте исправления в журнале, чтобы видеть, какие источники чаще всего приводят к расхождениям. Если замечание оказалось ложной тревогой, зафиксируйте причину и обновите правило проверки только после согласования. Не обучайте команду игнорировать все предупреждения из-за слишком шумного пилота: лучше сузить критерии, чем отключить контроль целиком.
FAQ: можно ли сразу исправлять карточки автоматически?
Для первого пилота лучше нет: начните с режима предложений, сравните результат с утверждёнными спецификациями и сохраните историю. Что делать, если у товара нет официального паспорта? Отметить отсутствие источника и передать вопрос ответственному, не поручая модели выводить характеристику из похожего товара. Нужно ли проверять каждую категорию одной инструкцией? Нет, требования к обуви, электронике и продуктам различаются. Как понять, что пилот сработал? Сравнить ручное время, долю подтверждённых замечаний и число ошибок, дошедших до публикации.