Cross model Comparison

Cross-model Comparison в GEO означает сопоставление ответов и присутствия бренда в разных ИИ-системах. На практике пользователь взаимодействует не только с языковой моделью, но и с поиском, интерфейсом, настройками и историей диалога. Поэтому корректное сравнение обычно относится к конкретным продуктам и режимам на определённую дату.

Что именно сравнивается

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

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

Сопоставимость условий

Параметр	Почему он влияет на вывод
Поиск включён или выключен	Меняется доступ к актуальным источникам
Новая сессия или продолжение	История может подсказывать бренд
Язык и регион	Меняются подходящие компании и документы
Формулировка вопроса	Меняются ограничения выбора
Время запуска	Могут обновиться данные и продукт
Пользовательский интерфейс или API	Отличаются инструменты и настройки

Не все условия можно сделать одинаковыми. Если платформа сама определяет необходимость поиска, это часть её поведения. В отчёте полезно описать различие, а не пытаться представить продукты полностью идентичными.

Один пул и несколько срезов

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

Среднее по платформам требует выбранных весов. Равные веса означают равное значение систем в мониторинге, а не равные доли реальной аудитории. Если веса основаны на данных о клиентах, указывают источник и период этих данных. При их отсутствии лучше оставить отдельные результаты.

Содержание важнее одной общей оценки

Частоту упоминаний дополняют правильностью названия, адреса, услуг и рекомендаций. Система может чаще называть компанию, но приписывать ей чужие свойства. Другой продукт даёт меньше появлений, зато точнее передаёт ограничения. Свести всё к числу «лучше» без определения цели нельзя.

Видимые источники тоже различаются. Для их сопоставления подходит подход из статьи № 130 «Source Overlap». Однако сравнение ссылок ограничено тем, что интерфейс показывает пользователю, и не является исследованием полного внутреннего контекста.

Технические пропуски

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

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

Как применять результат

Различия между системами помогают выбрать направления проверки, но не доказывают конкретную причину. Если бренд исчез только в одном продукте, сначала проверяют режим, доступность источников и повторяемость ответа. Колебания между запусками раскрывает статья № 132 «Run-to-run Variability». Такой порядок защищает от поспешной переделки сайта после единичного результата.