Сначала определите, чей результат вы хотите наблюдать
Если задача бизнеса — узнать, что получает потенциальный клиент в пользовательском поиске, исследуйте доступный клиенту сценарий. Если команда тестирует собственную программную интеграцию, объектом проверки будет её запрос и ответ. Оба наблюдения полезны, но они отвечают на разные вопросы.
Не называйте ответ программного инструмента «позицией сайта в ChatGPT» без определения такого показателя. Упоминание компании, место в перечислении и цитирование URL могут изменяться от запроса к запросу. В отчёте должно быть понятно, каким способом получен каждый результат и что именно автор считал.
Запишите настройки, которые реально доступны наблюдателю
Для программного запроса сохраните используемый сервис, идентификатор модели, переданные сообщения, инструменты и настройки, существенные для теста. Секреты и закрытые сведения исключают из публичного отчёта. Для пользовательского интерфейса запишите показанный режим, доступный поиск и известный контекст диалога. Не восстанавливайте скрытую конфигурацию по догадке.
Отметка «неизвестно» лучше ложной точности. Пользователь может не видеть внутреннюю версию модели или выбор поискового механизма. Это ограничивает сравнение, но не делает наблюдение бесполезным. Оно остаётся свидетельством конкретного ответа при описанных доступных условиях.
Проверьте, был ли поиск, а не только возможность его включить
Наличие инструмента поиска в программной интеграции ещё не доказывает его использование в конкретном ответе. Сохраняйте доступные события вызова и фактические ссылки. В интерфейсе учитывайте видимые признаки и источники, не называя любой ответ результатом свежего веб-поиска.
В документации OpenAI веб-поиск описан как отдельный инструмент API с собственным результатом и ссылками. Это не описание всех деталей пользовательского ChatGPT. Аналогично, данные Яндекс Вебмастера о видимости в Алисе AI имеют собственную область измерения; их нельзя превращать в ответ произвольного программного запроса к другой системе.
Источники: OpenAI: Web search в API; Яндекс: видимость сайта в Алисе AI
Заполните протокол до оценки ответа
В таблице вымышленные записи учебного теста выбора мастерской. Они показывают качество описания метода; реальные запросы к сервисам по этому упражнению не выполнялись. Временные метки, сервис и условия в собственном журнале заполняйте по факту, не копируя значения учебной строки.
| Поле | Запись А: программная интеграция | Запись Б: пользовательский сервис |
|---|---|---|
| Вопрос | Одинаковая сохранённая формулировка о выборе мастерской | Та же формулировка без дописанного бренда |
| Модель | Идентификатор из конфигурации теста сохранён | Видимая метка сохранена; внутренняя версия неизвестна |
| Поиск | Включён инструмент; событие использования не сохранено | Источники видны в ответе и открыты проверяющим |
| Контекст | Список переданных сообщений известен | Новый диалог; доступные настройки записаны, скрытое неизвестно |
| Время | Время запуска и часовой пояс сохраняются отдельными полями | То же правило, без округления до названия месяца |
| Упоминание | В учебном ответе назван бренд А | В учебном ответе бренд А не назван |
| Вывод | Есть упоминание в этой интеграции; использование поиска не доказано | Есть отдельное наблюдение интерфейса, не опровергающее запись А |
Два последних результата не образуют падение видимости с одного появления до нуля. Между строками изменился способ получения ответа. Сначала нужно сохранить две серии наблюдений, а не соединять их в один график.
Разберите расхождение, не назначая одну причину
Проверьте вопрос, историю сообщений, доступный поиск и ссылки. Затем посмотрите, одинаковое ли решение требуется от сервиса. Запрос «какую компанию выбрать» и просьба «расскажи о компании А» дают разные основания появления названия. Нельзя исправить методику одним уточнением даты.
Если причины различия не установлены, так и запишите. Формулировка «результаты различаются при разных условиях» точнее утверждения, что модель не знает бренд или сайт потерял позиции. Для отдельной проверки меняйте один известный параметр и сохраняйте ограничения: полностью контролировать внутреннее устройство чужого сервиса наблюдатель обычно не может.
Продолжить: Как исследовать различия доступного контекста диалога
Продолжайте ряд только при известной совместимости метода
При смене модели, интерфейса или способа поиска отметьте границу в журнале. Можно сохранить старую серию как историю и начать новую; если доступен параллельный период, он поможет увидеть расхождения методов, но не гарантирует возможность простого пересчёта одной метрики в другую.
Не смешивайте отчёт поисковой панели, ручные ответы и данные программного монитора в один процент. В каждом наборе свои единица, знаменатель и область наблюдения. В сводном отчёте объясните, что показала каждая серия и какие изменения невозможно уверенно сопоставить.
Продолжить: Как сравнить периоды и сохранить несопоставимые строки отдельно
Передайте владельцу данные вместе с правилом чтения
К итоговому наблюдению приложите точный вопрос, сохранённый ответ, источники и паспорт метода. Обозначьте, является ли это тестом интеграции, наблюдением пользовательского сервиса или выгрузкой официального отчёта. Читатель должен понять результат без восстановления конфигурации из переписки с исполнителем.
Такой пакет позволяет выбрать следующий шаг: исправить пробел журнала, отдельно проверить источник или подготовить доработку сайта. Само расхождение API и интерфейса не является достаточным основанием переписать все статьи. Сначала установите, какая проблема подтверждается доступными данными.