Для начала сразу скажу, что MEO (Multiple Engine Optimization) – пока что не отраслевой стандарт, не спецификация, не метрика. А заодно и не «техника», которую можно было бы при желании «внедрить по методичке». Это рабочая модель, которую я предлагаю для описания одной технической проблемы. Суть такая – у современного бренда (или продукта, или даже отдельной страницы) отсутствует единый алгоритм-судья, который решает, покажут этот бренд/продукт/страницу пользователю или нет. Таких алгоритмов могу с ходу назвать минимум 8. Лучше даже сказать – это принципиально разные классы, и у каждого своя механика извелечения, ранжирования и репрезентации сущностей.
Предлагаю разобрать подробно, что технически происходит внутри каждого из этих классов.
С чего все началось
Классический поисковый движок – инвертированный индекс плюс ранжирующая модель поверх сигналов. Сюда можно отнести ссылочную массу сайта, поведенческие факторы и релевантность запросу. Это достаточно понятная и хорошо задокументированная механика.
Генеративные ответные системы работают по другим принципам. Часть моделей отвечает на вопросы пользователей, использую сведения из параметрических знаний. Это те данные, которые были вбиты в веса на этапе претрейна. Другая часть систем используют RAG, то есть извлечение релевантных документов через векторный или гибридный поиск. Затем они генерируют «наиболее вероятный» ответ поверх найденного контекста. Это 2 принципиально разных механизма получения значимости бренда в ответе, и они требуют разных технических действий для влияния на результат:
-
На параметрические знания модели можно повлиять только через присутствие в обучающих корпусах (текст, проиндексированный до или во время очередного претрейна).
-
На RAG-подобные системы можно повлиять через классическую индексируемость и структурированность контента здесь и сейчас, аналогично SEO, но с другими требованиями к чанкингу и семантической целостности блоков текста.
А теперь те самые 8 классов (не школьных, но и не академических… пока что)
Ниже – классификация (не претендую на то, чтобы стать истиной в посоедней инстанции, но по опыту вижу именно такую классификацию). Акцент на то, какая механика ранжирования/ретрива (ивлечения) стоит за каждым классом:
-
Поиск – инвертированный индекс + ранжирующая модель (BM25-подобные сигналы + ML).
-
Ответы – расширенные сниппеты и голосовые ответы. Они часто (почти всегда) основаны на разметке (schema.org, вопросно-ответные форматы) и структуре заголовков, которые позволяют движку выделить условно самодостаточный, «полноценный» фрагмент.
-
Генерёжка – LLM с параметрическими знаниями и/или RAG-контуром поверх собственного или стороннего поискового индекса.
-
Рекомендация – тут, как правило, коллаборативная фильтрация и/или векторные представления пользователей и объектов в одном пространстве.
-
Коммерческие сигналы – ранжирование по структурированным фидам (то есть характеристики товара, атрибуты, доступность), часто с собственной моделью релевантности вида «вот запрос, вот товар по нему».
-
Карты/графы – геопривязанные базы данных POI (point of interest) + сигналы локальной релевантности (сюда отнёс бы расстояние, рейтинг, актуальность карточки).
-
Социальная привязка – это ранжирование внутри графа социальных связей плюс поисковый слой поверх контента, созданного самими пользователями (UGC).
-
Агентная работа – а это уже вызов функций (у кого-то формулируется как tool use, а где-то function calling). Суть: агент не показывает список вариантов, а выполняет действие, опираясь на структурированные данные (API, машиночитаемые фиды), которые он может безопасно вызвать.
Почему согласованность сущностей обязательно нужна
Проблема, с которой сталкивается почти любой бренд с неуникальным именем: при неоднозначном запросе система разрешения сущностей (или лучше сказать связывания) не может однозначно связать упоминания в разных источниках с 1 объектом. И в итоге модель неизбежно путает вас с вамшими с однофамильцами, потому что в обучающих данных или в индексе нет достаточно сильных дизамбигуирующих сигналов. Аналогично и с брендами.
Что технически МОЖЕТ снизить эту неоднозначность:
-
Структурированная разметка schema.org (типов Organization или Product с полем sameAs, связывающим все профили сущности).
-
Согласованность фактов (имён, категорий, доменов) во всех независимых источниках, а не только на основном сайте.
-
Наличие сущности в источниках, которые сами по себе используются как “якоря” для связности сущностей (открытые энциклопедические базы, отраслевые справочники). Можно сказать короче – консистентность.
Но это всё не гарантирует «автоматического веса» бренду, но вероятность ошибочной атрибуции снижает.
Оценочный лист MEO
Предлагаемая (опять же пока что не общепринятая) четырёхуровневая модель метрик:
-
«Находибельность» (возможность нахождения, но звучит громоздко) – бинарно/по шкале: показывает ли вас движок вообще по релевантному запросу.
-
Представленность – частота корректного цитирования, точность фактов, согласованность категории.
-
Конкурентная позиция – рабочая метрика Share of Model (уже устоявшаяся): доля упоминаний/рекомендаций бренда среди конкурентов по фиксированному набору запросов в разных генеративных системах. По факту, это аналогия старого понятия Share of Voice для генеративных систем – метод сбора данных пока не стандартизирован, и сравнивать её между разными исследователями напрямую нельзя.
-
Итог / выхлоп – измеримые в цифрах визиты, лиды, продажи, CAC, ROMI. Одним словом, всё то, ради чего остальное и было нужно.
Мифы
Здесь надо отдельно проговорить набор тезисов, которые я сознательно не использую в этой модели, потому что они не подтверждаются данными. Опять же, не подтверждаются они пока что:
-
Классический поиск «умирает» – нет, каналы сосуществуют (SEO «умирает» уже лет 20, всё никак не умрёт).
-
Все генеративные системы используют RAG – нет, не все. Часть работает только на параметрических знаниях. Есть и «комбинации».
-
Векторное представление обязательно для любого современного ИИ-поиска — это распространённый, но не универсальный паттерн.
-
Наличие оформленной сущности автоматически повышает вес бренда в ранжировании – здесь нет прямой причинно-следственной связи, подтверждённой публично, скорее это основа основ, без которой работать нельзя. Но точно не «залог успеха».
-
Существует официальный стандарт MEO – ничего подобного. На данный момент это открытая рабочая модель, а не спецификация.
Зачем вся эта маркетинговая подноготная нужна разработчикам?
Если вы делаете продукт со своим API, каталогом или базой данных — вы, по сути, уже являетесь потенциальным “движком” агентного класса для ИИ-агентов. Вопрос о том, насколько легко внешнему агенту безопасно и предсказуемо вызвать функцию вашего сервиса – чистой воды инженерная задача (стабильность API, машиночитаемая документация, структурированные ответы), а не задача маркетингового отдела.
Буду рад техническому обсуждению в комментариях, особенно если у кого-то есть опыт измерения связывания записей или RAG-ретрива применительно к брендовым запросам, и брендовым сущностям/представлению глобально.
Автор: IvanDiskin
