Каталог — это не просто текстовая задача

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

Языковая модель полезна здесь не как автономный редактор, которому можно отдать весь каталог и кнопку «опубликовать», а как помощник по разбору неоднородного входа. Она может предложить каноническое название, выделить признаки из описания и разложить их по заранее заданным полям. Но предложение модели ещё не является достоверным фактом и тем более не должно автоматически переписывать мастер-запись.

Сначала зафиксируйте экономическую единицу

Считайте не «сколько карточек обработала модель», а одну утверждённую карточку, прошедшую ваши правила и готовую к публикации. В расчёт включите:

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

Простая модель для пилота:

стоимость утверждённой карточки = (инференс + проверка + исправления + доля инфраструктуры и интеграции) / число принятых карточек.

Для сравнения с ручной работой замерьте текущие минуты на карточку и полную стоимость часа сотрудника. Снижение времени генерации не означает экономию, если проверка стала длиннее. И наоборот: даже умеренная автоматизация может быть полезна, если высвобождает время специалиста для исключений, переговоров с поставщиками и контроля качества.

Условный пример — только для проверки метода, не рыночный тариф. Пусть ручная подготовка занимает 6 минут, а нагруженная стоимость часа сотрудника для расчёта равна 600 ₽. Тогда ручной труд — около 60 ₽ на карточку без учёта накладных расходов. В ИИ-процессе предположим 1 минуту проверки, 20 секунд на исправления в среднем и 8 ₽ на обработку и инфраструктуру. Получается примерно 20 ₽ прямых затрат на карточку. Если проверка занимает уже 4 минуты, итог станет около 50 ₽. Эта разница показывает, почему время человека нужно измерять отдельно, а не прятать за ценой токенов.

Архитектура: модель предлагает, правила проверяют, человек утверждает

Пилот можно построить вокруг выгрузки CSV или копии каталога, не подключая сразу боевую учётную систему:

1. Сохраните исходный идентификатор, название, описание, артикул и имеющиеся атрибуты. Не позволяйте модели менять ключи или создавать записи.
2. Подготовьте справочник допустимых категорий, единиц измерения, вариантов значения и правил заполнения. Там, где данных нет, задайте явное значение «неизвестно», а не требование угадать.
3. Передайте модели одну карточку или небольшой пакет карточек с инструкцией извлекать только подтверждаемые сведения. Просите вернуть структурированные поля и короткий фрагмент исходного текста, на котором основано каждое спорное значение.
4. Примите ответ только после программной проверки схемы и бизнес-правил. JSON Schema умеет описывать обязательные поля, типы и ограничения значений; это помогает отсечь некорректную форму, но само по себе не доказывает истинность содержимого.
5. Покажите оператору сравнение «было / предложено / основание / предупреждение». Сотрудник утверждает или исправляет результат. До явного согласования исходная карточка остаётся неизменной.
6. Запишите принятую версию, автора решения, модель, версию промпта и причину отклонения. Сохраняйте исходный файл и возможность отката.

В локальном контуре Ollama поддерживает форматирование вывода по JSON Schema через API и библиотеки Python/JavaScript. Это пример доступного механизма, а не гарантия качества конкретной модели: проверьте версию сервера и библиотеки, совместимость выбранной модели и фактическое соблюдение вашей схемы. Затем запускайте независимый валидатор приложения и бизнес-правила. Для облачного API применяется тот же принцип «структура плюс проверки», но место обработки данных и договорные условия будут другими.

Что именно проверять

Не начинайте с попытки нормализовать весь ассортимент. Возьмите 300–500 SKU одного типа с похожей структурой, но сохраните сложные и неполные строки. Отдельно выделите 50–100 карточек, на которых сотрудники заранее отметили правильные значения: это контрольная выборка, а не учебный набор для промпта.

Измеряйте не один общий процент, а несколько показателей:

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

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

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

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

Если в каталоге много сканов, таблиц и изображений, добавится OCR или обработка изображений; это отдельная стадия со своей проверкой и стоимостью. Если исходные данные систематически неверны, модель не исправит причину — она может только быстрее размножить несогласованность. Сначала исправьте справочники и правила, затем расширяйте охват.

Ограничения и защита

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

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

Практический следующий шаг

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