В современном мире основным источником информации о товарах для дома для покупателя является Интернет, с помощью которого можно легко и быстро найти, сравнить, выбрать и даже купить модель того или иного вида товара.
Однако мало кто из покупателей задумывается о том, что стоит за формированием контента, на основе которого они делают этот выбор.
Однако и владелец магазина, и его отдел маркетинга прекрасно понимают необходимость предоставления качественных, полных и в то же время достаточно простых для понимания описаний товаров.
Контент о продукте можно разделить на несколько типов:
- Общая информация (фото, видео, редакционный текст).
- SEO (комплект для продвижения, поиск, сниппеты, микроразметка).
- Техническое описание (характеристики).
- Файлы документации.
- Сопутствующие товары (родственные, зависимые, обязательные, альтернативные и т.п.
).
Информационная модель
В этой статье мы рассмотрим третий тип контента — техническое описание (на самом деле из этого контента можно извлечь почти всё остальное).Такое содержимое обычно представляет собой таблицу, состоящую из пар «Атрибут: Значение».
В этом случае под признаком следует понимать некоторое обособленное свойство группы товаров сходного назначения, отражающее их функциональные, физические и/или потребительские качества.
Значение атрибута — это реализация такого свойства в данном конкретном товаре (алгебраически говоря, значение — это влияние атрибута на товар).
Атрибуты могут быть числовыми, категориальными или текстовыми.
Числовой Атрибут — это линейная шкала, по которой продукты можно сравнивать друг с другом, как если бы они были обычными действительными числами.
Как правило, это физическая величина (вес, объем, частота, мощность и т.п.
) с единицей измерения (масштабом) или количественным признаком (без масштаба).
Числовой атрибут в каждом продукте реализован как определенное числовое значение с определенной единицей измерения.
Иногда два числовых атрибута объединяются в один для реализации значения интервала (от и до).
Категорический Атрибут представляет собой конечный список токенов (слов, фраз, названий, обозначений и т.п.
) и в каждом конкретном товаре реализуется некоторым (возможно, пустым) подмножеством этого списка.
Окончательно, текст атрибут может принимать в качестве значений любой текст из данного алфавита, т.е.
является аналогом категориального атрибута, но с бесконечным набором возможных значений (звезда Клини в данном алфавите).
При желании все три типа атрибутов можно свести к последнему – текстовому.
Для покупателя, читающего описание товара, разницы между ними нет. Однако стоит отметить, что чем более структурирован атрибут и чем лучше он оцифрован (даже если это конечный список векторов или матриц, а не просто число), тем проще его использовать в алгоритмах сравнения произведений и при вычислении их «функции полезности», а также в фильтрах и тегах.
Следовательно, чем выше качество технического описания, тем больше в нем числовых признаков и меньше (в идеале вообще нет) текстовых.
Для каждого конкретного продукта каждый атрибут в отдельности мало что значит, однако определенный набор атрибутов, реализованный в продукте, уже представляет собой определенный «генетический код» этого продукта, и поэтому правильный выбор атрибутов определяет, как этот продукт будет соотноситься с другими сопутствующими товарами.
те.
продукции, насколько она будет релевантна в поиске, насколько ее можно найти среди множества аналогичных товаров.
Возникает дилемма: какой набор атрибутов, с одной стороны, достаточен для исчерпывающего (делающего его уникальным) описания одного товара, а с другой стороны, сколько атрибутов необходимо для того, чтобы адекватно описать, сравнить и сопоставить товары в интернет-магазине или на рынке? -место.
Как обычно, истина где-то посередине.
Все товары необходимо разделить на группы таким образом, чтобы внутри каждой группы было как можно меньше малоиспользуемых атрибутов (крайний вариант: каждый товар имеет свой набор атрибутов) и при этом количество этих групп должно быть как можно меньшими, а их объем не должен быть очень большим.
различаются от группы к группе (крайний вариант: единый набор атрибутов для всех товаров, т.е.
одна группа товаров).
Обычно (и, как правило, такая логика оправдана) принято разделять товары на группы в соответствии с их функциями и потребительскими свойствами.
Например, не стоит искать одинаковые наборы атрибутов для микроволновой печи и бензиновой газонокосилки.
При этом чайники и термопоты легко объединяются в одну группу товаров с одинаковым набором атрибутов.
Пара (Группа продуктов: Набор атрибутов) называется информационная модель (информационная модель, модель).
Таким образом, информационная модель представляет собой многомерное пространство (гиперкуб), в котором измерения являются атрибутами, а точки — конкретными физическими благами, точнее, их представлением в этой модели.
Информационная модель со временем развивается, поскольку пополняются списки значений категориальных атрибутов, добавляются новые атрибуты и единицы измерения.
Вариативность информационных моделей
Давайте теперь вспомним, что товары с очень похожими свойствами (одним назначением) производятся разными компаниями, число которых может достигать нескольких сотен.У каждого производителя есть свое описание товара, а значит свое разделение товаров на группы и своя информационная модель для каждой группы.
Получается, что производители хотя и говорят практически об одном и том же, но используют разные формальные языки.
Это означает, что даже для одной группы товаров существует множество информационных моделей, а универсальной общепринятой модели вообще не существует. Создавая собственный информационный каталог для интернет-магазина, мы вынуждены каким-то образом импортировать технические описания товаров извне.
Это может быть сделано вручную вашей собственной командой по контенту, его можно импортировать через API провайдеров и поставщиков контента, вы можете настроить другие методы импорта контента из надежных источников, а также можете комбинировать одни методы импорта с другими.
Так или иначе, возникает задача определения операторов, отображающих внешние информационные модели во внутренние.
Кроме того, дальнейшей трансформации подлежит и внутренняя модель для предоставления данных сайту интернет-магазина и различным фидам для продвижения товаров на онлайн-платформах.
А если мы говорим о внутренней модели контент-провайдера, то эта модель отображается в многочисленных информационных моделях клиентов, приобретающих этот контент. Таким образом, в общем случае мы имеем проблему двойной трансформации технического контента: 
И на каждом из трех звеньев этой цепи мы имеем дело с разными информационными моделями и разным разделением многих продуктов на группы, так что при каждом преобразовании моделей мы вынуждены переводить с одного модельного языка на другой.
К сожалению, информационные модели не являются линейными пространствами, и преобразование, переводящее одну информационную модель в другую, не является линейным оператором.
Поэтому для создания транзитных преобразований (минуя внутренний каталог) обойтись умножением матриц линейных операторов не получится.
И это не единственная проблема.
Утрачено при переводе
Перечислим некоторые трудности преобразования информационных моделей:- Разбивка товаров по группам из проверенных источников может отличаться.
- Набор атрибутов в информационных моделях различен для всех доверенных источников (от названий атрибутов и значений списков до используемых физических величин).
- (Человеческий) язык моделей также может быть разным.
- Единицы измерения в числовом атрибуте могут быть указаны в системе, отличной от СИ, и/или включены в имя атрибута или его значение.
- Товары могут быть описаны недостаточно полно.
- Значения могут быть ошибочными (даже из проверенных источников).
- Клиентские каналы и каталоги сильно различаются по своим требованиям.
- Как организовать свою внутреннюю информационную модель, чтобы максимально точно разместить описания доверенных источников и максимально полно и адекватно формировать данные для клиентских каталогов?
- Как очистить входные данные от «шума»?
- Как формализовать операторы преобразования информационных моделей на этапах импорта и экспорта?
Атомизированная модель
Если проблема различий разговорных языков решается относительно просто (нужно договориться, что и внутренняя модель, и внешние доверенные источники будут использовать только английский язык и метрическую систему мер), то различие в группах и наборах признаков требует построение такой принимающей модели, в которой бы все внешние атрибуты были максимально разделены и декомпозированы.Другими словами, операторы, преобразующие внешнюю информационную модель во внутреннюю (операторы импорта), не должны склеивать отдельные атрибуты в один, а вполне могут разделить один сложный атрибут на несколько более простых (т. е.
увеличить размерность информационной модели).
С другой стороны, чтобы максимально упростить синтез новых информационных моделей для клиентской стороны (экспорта), внутренняя модель также должна быть максимально структурирована и разбита на элементарные атрибуты, чтобы операторы экспорта могли их объединить.
в максимальное разнообразие внешних моделей (при уменьшении размерности информационной модели).
Такая атомизированная модель имеет ряд преимуществ по чисто комбинаторным причинам.
Действительно, имея в своем арсенале всего три характеристики A, B, C, мы можем составить из них не менее 5 (число Белла для n=3) непустых моделей ({A,B,C}, {A+B, С}, { А+С,В}, {А,В+С}, {А+В+С}).
Эти комбинированные модели могут соответствовать разным внешним моделям, но в то же время вписываться в одну внутреннюю модель.
Второе преимущество заключается в том, что такую модель легче модерировать.
Если характеристика А указана только один раз, то ее переименование, добавление к набору значений или единиц измерения и исправление ошибок также выполняются во внутренней системе только один раз.
Если мы сделаем внутреннюю модель такой, чтобы она представляла все возможные комбинации внешних моделей, то дальнейшее управление станет экспоненциально более сложным по сравнению с атомизированной моделью.
Очистка данных
Помимо проблемы сравнения атрибутов различных внешних информационных моделей с внутренней моделью, существует еще проблема «шума» в исходных данных.Во-первых, данные могут быть неполными.
Для импорта это не проблема, но это означает, что доверенный источник должен быть дополнен каким-то другим источником.
Полнота данных о продукте означает, что в рамках одной информационной модели не существует двух продуктов с одинаковым набором значений атрибутов.
Полнота, очевидно, зависит от источника данных.
Если в одном доверенном источнике относительно мало продуктов, то модель их описания может быть плохой, поскольку небольшого набора атрибутов достаточно, чтобы отличить их в рамках данной модели.
При объединении данных из многих доверенных источников может быть потеряна полнота, а значит, во внутренней модели описание товаров должно быть максимально подробным.
Таким образом, возникает необходимость получения данных по одному и тому же товару как минимум из двух-трех источников.
Это же требование делает возможным процесс проверки данных.
Дело в том, что ошибки совершают все, в том числе и сайты производителей.
Для выявления ошибок нужно уметь сравнивать импортированные данные между собой и с описаниями товаров из заданной группы.
И для корректного сравнения нам снова нужна единая атомизированная модель.
Только когда мы сможем сравнить данные из разных источников в рамках одной информационной модели, мы сможем также выявить некоторые ошибки и тем самым очистить данные (например, не допускать в систему противоречивые значения или передавать только наиболее вероятные альтернативы).
Почему информационная модель не может быть всеобъемлющей?
Ранее мы уже отмечали, что при создании информационной модели необходимо сохранять некоторый баланс между полнотой модели и глубиной разделения товаров на группы.Давайте обсудим этот момент более подробно.
Очевидно, что делать одну модель для одного или 10 изделий неразумно хотя бы из-за сравнения затрат на создание модели и эффекта от ее использования.
Из всего вышесказанного уже должно быть очевидно, что создание информационной модели – задача хлопотная и затратная как по времени, так и по интеллектуальным ресурсам.
Если при наличии в каталоге 1000 товаров создать группы по 10 товаров, то нам потребуется 100 моделей, каждую из которых необходимо создать и поддерживать.
Конечно, здесь есть свои спасительные хитрости.
Например, во многих моделях присутствуют многие атрибуты (например, частота или вес).
Поэтому их проще создать и настроить в отдельном атрибутивном каталоге, и собрать из них модель, как «Лего».
Но помимо создания модели вам также потребуется создать операторы импорта/экспорта, которые будут принимать и отправлять контент во внешние модели.
И в этих внешних моделях, как правило, категоризация (деление на группы) происходит по своим принципам.
Ради одной-двух внешних моделей придется создать несколько сотен операторов.
Это опять же дорого и очень избыточно.
Наконец, если мы хотим использовать такие вещи, как машинное обучение, для выявления ошибок, отклонений и автоматизации импорта/экспорта данных, нам понадобится достаточно большая группа однородных описаний продуктов, имеющих единую информационную модель.
В противном случае машинное обучение будет неверным.
Хорошо, тогда почему бы не создать модель, включающую все продукты из каталога? Одна модель требует одного акта создания и, казалось бы, существенно экономит на поддержке.
Однако эта крайность имеет и свои недостатки.
Во-первых, эта модель будет крайне редкой.
Напомним, что товар в информационной модели — это вектор значений атрибутов.
Если модель очень широкая, то может случиться так, что каждый продукт использует 1–2% атрибутов, хотя все продукты вместе используют 100% атрибутов.
В итоге мы получаем очень разреженную модель данных, а такие модели обычно очень требовательны к вычислительным ресурсам, поскольку сильно разреженные векторы требуют постоянной упаковки и распаковки для экономии памяти, а это значит, что выполнение массовых операций над каталогом становится трудоемкой задачей.
С точки зрения Data Science, к такому информационному пространству следует применять алгоритмы уменьшения размерности, отбрасывая все несущественные атрибуты и разрезая это единое пространство на несколько независимых подпространств, размерность которых будет в несколько раз меньше исходного.
Но это не что иное, как переход к группам товаров со схожей информационной моделью (категоризацией).
Во-вторых, глобальную информационную модель тоже необходимо поддерживать — пополнять атрибутами, расширять списки значений, модифицировать операторы импорта/экспорта при возникновении таких изменений.
Здесь мы снова сталкиваемся с проблемой, когда необходимость внесения небольших изменений затрагивает весь каталог.
Кроме того, возрастает риск дублирования или перекрытия атрибутов, поскольку отслеживание корректности модели становится для человека невыполнимой задачей.
В-третьих, если внутренняя модель используется для заполнения описаний «вручную», то контент-менеджер будет вынужден тратить длительное время на просмотр информационной модели в поисках нужного ему атрибута для присвоения значения.
Это огромная трата времени и ресурсов компании.
Против глобальной информационной модели можно привести ряд других аргументов, связанных с процессами управления каталогами, разделением прав доступа, отслеживанием изменений модели, автоматизацией проверок качества вводимых значений и т. д. Таким образом, чаще всего информационные модели строятся на группах очень похожих продуктов, сохраняя паритет между полнотой и тривиальностью модели.
Когда мы имеем дело с товарной группой, где разница в полноте товарной модели составляет 5-10%, мы не только облегчаем себе жизнь в плане управления моделью и привязки к ней операторов импорта/экспорта, но и получаем ряд бонусов.
Чрезмерная атомизация модели
В попытках построить простейшую информационную модель можно прийти к типу модели, называемому моделью «Да/Нет».В такой модели существует ровно два типа атрибутов – числовые (с единицами измерения) и категориальные с одинаковым списком значений {'Да', 'Нет'}.
Очевидно, что любой категориальный атрибут сводится к набору атрибутов «Да/Нет».
Для этого достаточно взять список значений заданного категориального атрибута и превратить его в список одноименных атрибутов.
Тогда, если это значение исходного атрибута присутствует в товаре, одноименный атрибут «Да/Нет» принимает значение «Да», в противном случае – «Нет».
Такая сверхатомизированная модель имеет право на существование и даже часто используется на практике.
Однако легко понять, что это также очень сложно для целей сравнения внешних моделей с внутренними.
Достаточно отметить, что добавление нового значения категориального атрибута практически не влияет на формулы операторов импорта/экспорта, тогда как соответствующее добавление атрибута «Да/Нет» может потребовать изменения многих сопутствующих алгоритмов преобразования информационных моделей.
Кроме того, такая модель будет очень разреженной и будет в сотни раз больше исходной модели со списком атрибутов, в результате чего мы получим все проблемы, которые были описаны для случая комплексной модели.
Использование модели «Да/Нет» может быть оправдано только в каталогах с очень простым, слабо меняющимся описанием (как каталоги предвыборных листовок «Да-да-нет-да») или если эта модель скрыта «под «капюшон» системы искусственного интеллекта, которая самостоятельно создает группы товаров и информационные модели для них, самостоятельно создает операторов импорта/экспорта, самостоятельно проверяет и пополняет данные на основе внешних стимулов (обратной связи от внешних систем и алгоритмов управления).
Другое использование модели «Да/Нет» — сопоставление с некоторым внешним каталогом, модель которого имеет тот же тип.
В этом случае импорт контента станет немного сложнее: сначала оператор импорта заполнит внутреннюю модель «Да/Нет», затем другой оператор сравнит данные с нативной внутренней моделью, содержащей список категориальных атрибутов.
Распределенные модельные бонусы
Для начала отметим, что если информационная модель соответствует группе товаров, имеющих примерно одинаковые атрибуты, то такие товары можно легко сравнивать друг с другом.И это очень важный аспект выбора товара покупателем.
Далее, если модель максимально декомпозирована, то и сравнение товаров в ней, и любая аналитика по имеющемуся контенту (статистический расчет группы товаров) будут максимально подробными.
С помощью атомизированной модели можно микроскопически выявлять различия в описаниях товаров, локализовать ошибочные значения, устранять неоднозначные интерпретации атрибутов, искать зависимые атрибуты и рассчитывать недостающие знания о продукте.
Выше уже отмечалось, что атомизированная модель позволяет генерировать большое количество комбинаций атрибутов, что упрощает создание операторов экспорта во внешние модели.
Чем меньше элементарный квант модели, тем точнее мы можем построить правила экспорта данных, отвечающие требованиям заказчика или рынка.
Ряд бонусов атомизированной модели появляется, когда мы говорим о системе управления контентом и ее интерфейсах.
Прежде всего, мы можем наложить ограничения на разрешенные значения атрибутов, поскольку они вводятся как оператором-человеком, так и оператором импорта.
Например, для числового атрибута можно установить ограничивающий диапазон либо заранее, исходя из его физического значения, либо на основе статистического анализа значений для ранее описанных товаров.
Вы также можете запретить ввод дробных значений для количественных атрибутов или ограничить количество десятичных знаков для значений частоты процессора.
В случае категориальных атрибутов часто существует ограничение на количество значений, которые можно ввести одновременно.
Таким образом, атрибуты подтипа «выбрать» позволяют выбрать только одно значение.
Наконец, можно выполнить перекрестную проверку значений и/или пополнение знаний о продукте.
А именно, из физических соображений мы можем связать атрибуты формулами так, что если некоторые из введенных значений позволяют однозначно вычислить остальные, то мы можем либо автоматически заполнить недостающие атрибуты, либо проверить правильность их заполнения.
Категориальные атрибуты с фиксированными списками значений и синонимов, указанными для этих значений, а также иерархия значений позволяют контролировать возникновение повторяющихся атрибутов и значений.
Отсутствие повторяющихся фрагментов информационной модели означает более эффективное ее использование при импорте/экспорте данных, а также лучший поиск и сравнение товаров.
Еще одним важным бонусом атомизированной модели является то, что с помощью операторов экспорта можно сформировать из нее не только таблицу технических характеристик, более ориентированную на читабельность, но и отдельный список фильтров для сайта, который будет включать более структурированные атрибуты, а также отдельный список атрибутов для таблицы сравнения продуктов.
Кроме того, вы можете экспортировать SEO-тексты и метатеги, автоматически генерировать названия продуктов и краткие описания.
Ранее мы отмечали, что при создании модели и выборе источников лучше использовать один язык – английский.
Однако для внешних клиентских каталогов может потребоваться содержимое на разных языках.
Наличие атомизированной модели позволяет создавать словари токенов для перевода атрибутов, значений и единиц измерения на другие языки.
Здесь важно, чтобы как названия атрибутов, так и их значения были максимально полными с лингвистической точки зрения, что позволит исключить неоднозначность перевода.
В заключение отметим, что, имея качественное и хорошо структурированное техническое описание продукта, мы можем использовать алгоритмы машинного поиска для других типов контента – изображений, документации, видеороликов, маркетинговых текстов и т. д. Подводя итог, подведем основные выводы:
- У каждого своя информационная модель, поэтому для адекватного взаимодействия между информационными моделями необходимо создать внутреннюю принимающую модель.
- Внутренняя модель должна быть атомизированной и аналитической.
- Больше числовых атрибутов, меньше текста!
- Модель должна соответствовать группе схожих товаров так, чтобы разница между товарами группы по количеству используемых признаков составляла не более 5-10%.
- Группы товаров не должны быть маленькими.
- (Человеческим) языком внутренней модели и подключенных доверенных источников должен быть английский, а системой мер — СИ.
- Используйте модель «Да/Нет» с осторожностью, а лучше не используйте ее вообще.
-
Как Я Проверял Программу На Вирусы
19 Oct, 24 -
Всем Мужчинам-Айтишникам С 8 Марта :)
19 Oct, 24 -
На Лифте В Космос - 2009. Итоги
19 Oct, 24
