Семь AI-поверхностей: что можно проверить по открытым данным

Мы спрашиваем, что может подтвердить внешний наблюдатель без доступа к индексам, ranking signals и контексту модели. Это desk research по официальным документам, а не эксперимент с одинаковыми запросами. Поэтому выводы относятся к публично описанным возможностям и ограничениям, а не к долям видимости.

Семь поверхностей выглядят для пользователя как один вопрос к AI, но для исследования это разные среды с разными документами и сигналами. Мы не сравниваем их как рейтинг: карта показывает, что оператор описывает, что можно наблюдать и что неизвестно.

Для читателя итоговая карта полезна как decision aid: сначала определить, какой вопрос задаётся — доступ, поиск, атрибуция или переход — и только затем выбрать измерение. Это предотвращает перенос правил одного оператора на другого.

Отдельно проверяйте качество атрибуции: ссылка может вести на главную, пересказ или точный фрагмент. Для исследования это три разных исхода. Записывайте URL и поддерживаемое утверждение рядом, чтобы не считать любое появление домена citation.

Сравнение платформ имеет смысл только при одинаковой единице анализа. Мы используем поверхность и конкретный наблюдаемый artefact, а не бренд целиком. Поэтому YandexBot, OAI-SearchBot и поисковый интерфейс нельзя складывать в одну метрику без явного определения.

Редакционная польза карты — в выборе следующего действия. Плохой HTTP-статус ведёт к технической проверке; отсутствие URL в индексе — к проверке indexability; релевантный ответ без ссылки — к отдельному эксперименту с атрибуцией. Один универсальный совет здесь был бы менее точным.

Статус desk research нужно показывать рядом с датой: это синтез документов, а не измерение ответов. Читатель сразу понимает, почему таблица описывает границы знания, а не доли трафика или ranking.

Источники раздела:[1] Google Search Central

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

Таблицу следует читать по строкам и колонкам: выбрать поверхность, отделить описание оператора от наблюдения, затем проверить последнюю колонку. URL в ответе можно проверить; полный candidate set до выбора публично недоступен.

Если документ говорит о crawler, мы не добавляем к нему утверждение об answer engine. Если интерфейс показывает источник, мы не объявляем доказанным весь retrieval. Такая дисциплина делает сравнительный материал менее эффектным, но пригодным для аудита.

Для сравнения полезно выделить тип артефакта: серверная строка, запись панели, полный ответ или переход. Артефакты разной природы нельзя считать взаимозаменяемыми доказательствами.

Источники раздела:[2] OpenAI Developers[1] Google Search Central[3] Perplexity Docs[4] Microsoft Learn[5] Google Gemini Help[6] Anthropic Support[7] Yandex Webmaster

Для каждой поверхности фиксируем официальный URL, издателя, дату проверки и формулировку. Затем кодируем четыре поля: discovery, fetch, attribution и unknown. Индустриальные советы, не подтверждённые источником, не попадают в observed claims.

Синтез не означает, что семь документов описывают один pipeline. Сохраняйте canonical URL, дату проверки и точную формулировку claim, затем маркируйте observed, inference или unknown. Редакционная рекомендация не становится фактом оператора.

Пример рабочей записи: «11 сентября, RU, Google AI Search, вопрос X, показан URL Y, источник подтверждает тезис Z частично». Это сильнее, чем «страница видна в AI», потому что указывает поверхность, дату, ссылку и степень соответствия.

Каждый источник проверяйте на дату и область действия. Устаревшая политика доступа может объяснить расхождение с логом; это повод создать новую версию claim, а не исправлять старую задним числом.

Источники раздела:[3] Perplexity Docs

Переносимая рекомендация — не специальный файл для AI, а доступный HTML, устойчивые URL, ясные сущности, первичные источники и раздельное измерение результатов. Это снижает препятствия проверке, но не гарантирует показ или цитирование.

На практике сначала исправляется доставка: HTML, стабильные URL, sitemap и коды ответа. Затем создаётся доказательный материал с датой, источником и ограничениями. Только потом измеряется ответ поверхности. Отсутствие citation нельзя объяснить одной причиной.

Следующий этап исследования должен сравнивать одинаковые вопросы, а не собирать случайные скриншоты. Нужны заранее заданные критерии citation, сохранённые ответы и журнал изменений документов. Только такой срез позволит обсуждать повторяемость.

Редакционное действие после карты — выбрать один проверяемый вопрос и один URL. Большой список советов создаёт иллюзию охвата, тогда как узкий повторяемый тест даёт более сильное наблюдение.

Источники раздела:[4] Microsoft Learn

Документы могут описывать только часть продукта и меняться со временем. Мы не запускали matched prompts, не измеряли ranking и не проверяли причинность между обходом и ответом. Любой количественный вывод требует отдельного протокола и сохранённых ответов.

Публичное описание функции не равно наблюдению во всех языках, регионах и режимах. Поэтому цифры без знаменателя, периода и состава выборки не публикуются. Это задаёт стандарт для будущего эксперимента.

Внедрение на сайте простое: для каждой публикации хранить sourceIds, дату data-through, тип утверждения и correction history. Тогда публичная страница показывает не только вывод, но и путь его проверки.

Публикуйте абсолютное число запусков вместе с долей и перечисляйте исключённые ответы. Без знаменателя читатель не может оценить устойчивость результата.

Источники раздела:[1] Google Search Central

Повторите проверку через 30 дней, сохраните снимки документов и хэши. Затем задайте десять одинаковых вопросов в каждой поверхности, сделайте три повтора, зафиксируйте режим, регион, ответ и ссылки. Считайте fetch, mention, citation и referral отдельно; отсутствие артефакта обозначайте unknown.

Готовый протокол: зарегистрировать вопросы, выбрать одинаковые locale и регион, сохранить полный ответ, открыть URL, проверить смысловое соответствие и выгрузить серверные события. Отдельно считать fetch, index signal, mention, citation и referral.

Мы намеренно не называем неизвестность провалом платформы. Отсутствие публичного candidate set — свойство доступных данных, а не измеренная ошибка. Исследование помогает корректно сформулировать вопрос для следующего эксперимента.

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

Источники раздела:[1] Google Search Central