Хорошо описать продукт, попасть в наблюдаемые источники и оказаться названным в ответе ИИ являются разными событиями. Препринт Aiso пытается связать их в диагностическую модель. Для бренда полезнее понять, какие данные поддерживают решение, чем принять формулу за обещание роста после правки страницы.
Что проверяет модель
В From Prompt to Recommendation Benjamin Tannenbaum анализирует 34 960 наблюдений «вопрос × система» по 75 анонимизированным проектам Aiso: 2854 разных вопроса и повторные запуски GPT и Gemini с июня по сентябрь 2026 года. Препринт опубликован 19 сентября. Автор руководит коммерческой платформой, чьи данные использованы в работе.
Модель сочетает историю предыдущих упоминаний с наблюдаемыми признаками текущего поиска и источников. На последних по времени 30% данных полная модель получила AUC 0,963 для GPT и 0,942 для Gemini. Автор прямо называет её диагностической и наблюдательной. Это не восстановленный алгоритм ранжирования провайдера.
Исходные клиентские записи не опубликованы; доступны агрегаты и код для них. Они позволяют воспроизвести итоговые иллюстрации и арифметику, но не независимо переобучить модель на исходных наблюдениях. Отсутствие ссылки на собственный сайт также не доказывает отсутствие внешнего поиска: бренд мог попасть в ответ через другие сведения.
Почему AUC не является обещанием GEO-роста
AUC характеризует различение классов по значениям модели на выбранных данных. Это не доля покупок, не величина прибавки упоминаний и не точность прогноза после будущей редакторской правки.
Особенно важно, когда доступны входные признаки. Если для диагностики используется источник из того же текущего запуска, его ещё нет у команды до выполнения этого запуска. Хорошее различение наблюдаемых ответов не превращается автоматически в инструмент, заранее обещающий результат изменения страницы.
Как принять решение по такому исследованию
Результат для руководителя GEO-проекта: карточка применимости модели к конкретному решению команды. Подготовьте описание предлагаемого изменения, реальный вопрос клиента, исходные полные ответы и список данных, доступных до изменения. Если поставщик предлагает численный прогноз, запросите определение результата и момент доступности каждого входа.
| Вопрос к модели | Что должно быть понятно |
|---|---|
| Какой исход различается | Упоминание, рекомендация, ссылка или иное событие |
| Когда известны входы | До ответа, после получения источников или после полного ответа |
| Где проверялась применимость | Проекты, системы, интерфейсы и период |
| Что доступно для повторной проверки | Исходные записи либо только агрегаты |
| Какое действие проверено | Наблюдаемая связь или изменение с отдельным дизайном проверки |
Заполните эти поля по документам, оставив неизвестное неизвестным. Затем укажите решение, которое модель действительно поддерживает. Например, разбор наблюдаемого ответа и предварительная оценка эффекта будущей правки требуют разных доказательств.
От диагностики к содержательной задаче
Выберите вопрос из обращения покупателя, в котором важное условие предложения можно проверить официальным источником. Сохраните полный ответ, показанные ссылки, дату, систему и режим. Отдельно отметьте, назван ли бренд и предлагается ли он под это условие.
Если на подходящей странице не хватает подтверждённого сведения, назначьте конкретное уточнение с владельцем факта. Если сведения уже доступны, но страница не показана, сохраните этот результат как проблему для дальнейшего наблюдения. Отсутствие ссылки само по себе не определяет, нужно ли переписывать страницу, менять распространение сведений или уточнять исходный набор вопросов.
После изменения повторите заранее сохранённый набор при сопоставимых условиях и прочитайте новые ответы. Отдельно проверяйте точность описания продукта, присутствие бренда и источники. Даже совместное улучшение показателей не устанавливает причинность без подходящего сравнения.
Полезный вывод работы Aiso состоит в разделении стадий диагностики. Для управленческого решения рядом с любой «формулой видимости» должны оставаться наблюдаемый исход, доступные входы и граница между объяснением данных и проверкой действия.