Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Товарные карточки научились превращать в сопоставимые наборы характеристик без ручной разметки схемы для каждой категории. В препринте Amazon, который не прошёл рецензирование и содержит замеры самих авторов, правильными оказались 85% извлечений, а расходы на обработку сократились на 92%. Это делает специализированную модель и собственный контур вывода практичной альтернативой постоянным обращениям к крупной LLM.
Схему строят отдельно от извлечения
Конвейер разделяет две задачи с разной стоимостью. Сначала Claude Sonnet 4 изучает репрезентативные товары категории и выбирает характеристики, по которым покупатель различает предложения: например, мощность блендера, объём накопителя или шумоподавление наушников.
Для каждого атрибута модель задаёт описание, тип данных и допустимые значения. Все товары внутри категории получают одну схему, поэтому поиск, фильтры и сравнение работают с одинаковыми полями, а не с набором близких формулировок от разных продавцов.
Схемы разных категорий затем сводят между собой. Названия атрибутов переводят в векторные представления с помощью Qwen3-8B, группируют по смысловой близости и заменяют каноническими вариантами. Так «Water Resistance», «Waterproof rating» и «IP Water Rating» не превращаются в три независимых поля во внутренней базе.
Гранулярность категорий здесь влияет на результат сильнее, чем выбор формата ответа. Слишком широкая категория оставит только общие характеристики, а слишком узкая породит множество почти одинаковых схем. Конвейер не устраняет эту архитектурную развилку, но снимает ручную работу по составлению и согласованию полей.
На втором этапе Qwen3-4B получает текст карточки и готовую схему, после чего возвращает структурированные значения. Обучающие ответы для неё подготовила крупная модель: компактная модель переняла задачу, которую затем должна выполнять многократно и дешевле.
Значения генерируются одновременно
Обычная генеративная модель последовательно записывает весь объект JSON. Она сначала создаёт значение одного атрибута, затем переходит к следующему, хотя цвет товара обычно не нужен для определения его мощности.
Hyper-Parallel Decoding использует эту независимость. Система заранее создаёт каркас ответа с пустыми полями и на каждом шаге генерирует очередной токен сразу для всех значений. Специальная маска внимания не позволяет одному атрибуту случайно опираться на ещё не завершённый соседний атрибут.
Такой режим нельзя подключить одним параметром API. Он требует специального дообучения, дополнительных служебных токенов, изменённых идентификаторов позиций и собственной маски внимания. Команде также нужен контролируемый контур вывода модели, а не только доступ к облачному чат-интерфейсу.
На каталоге более чем из 30 млн товаров одна вычислительная машина обрабатывала около 159 тыс. карточек в час. Несколько параллельных машин завершили проход за 36 часов; вычисления стоили примерно $5 тыс. против $63 тыс. у крупной модели через пакетный облачный API.
Проверка охватывала частный англоязычный каталог с тысячами категорий, текстами заголовков и описаний. Качество оценивали модель-оценщик и люди, а вариантами сравнения служили последовательная генерация той же компактной моделью и крупная модель-учитель. Изображения в контекст не входили, поэтому сведения только на упаковке или фотографии извлечь нельзя.
Планы меняются только при пакетной обработке
Работа предлагает не новую универсальную модель, а способ разложить массовую обработку каталога. Редкую и семантически сложную задачу — определить полезные атрибуты — выполняет крупная LLM. Частую задачу с фиксированным форматом переносит компактная модель, оптимизированная под конкретную схему ответа.
Такое разделение стоит учитывать, если один и тот же набор полей нужно извлекать из миллионов однотипных документов. Экономия возникает из повторяемости: контекст меняется, но структура результата остаётся стабильной, а значения можно вычислять независимо.
Для прототипа или небольшого каталога собственное дообучение и нестандартный механизм вывода могут оказаться сложнее прямого вызова API. В крупной системе придётся поддерживать версии схем, повторно обрабатывать изменившиеся карточки, проверять JSON и возвращать в очередь записи с нарушенным типом данных.
Подход хуже переносится на задачи, где поля зависят друг от друга. Если одно значение нужно вывести из другого, параллельная генерация разрушает полезную последовательность рассуждения. Та же граница действует для многоязычных каталогов и данных из изображений: работа проверяет только английский текст и модели семейства Qwen3.
Практический вывод состоит в выборе уровня специализации. Если извлечение атрибутов уже стало заметной статьёй расходов, команде имеет смысл отделить проектирование схемы от её заполнения и считать экономику собственного вывода. Если схема часто меняется или каждый документ требует нового набора вопросов, преимущество параллельного конвейера уменьшается.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
