Для начала сразу скажу, что 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-ретрива применительно к брендовым запросам, и брендовым сущностям/представлению глобально.
