Мониторинг упоминаний бренда в ChatGPT: сравнение трёх способов сбора данных и разбор ошибок парсинга

Задачи мониторинга и параметры тестовых вопросов

Для одного из клиентских проектов я настраивал систему отслеживания видимости компании в ответах нейросетей (GEO / AEO). Основная цель заключалась в том, чтобы понять, насколько часто ChatGPT органически рекомендует бренд при коммерческих и информационных запросах, а также на какие домены он опирается при формировании ответов.

В качестве базы я взял 20 целевых вопросов из сферы продвижения бизнеса в нейросетях. Пул запросов варьировался от поисковых («где заказать», «сколько стоит») до стратегических («как сделать, чтобы нейросети рекомендовали мой бренд»). В 19 вопросах любое упоминание компании клиента полностью отсутствовало. Двадцатый вопрос был сформулирован как прямое сравнение: «Бренд X или конкурент Y — кто лучше».

Каждый полученный ответ я записывал в структурированный JSON-лог со следующими полями:

• полный текст ответа нейросети;
• признак использования веб-поиска;
• извлеченные из ответа домены-источники;
• отметки о наличии упоминания бренда клиента и шести ключевых конкурентов (список конкурентов сформирован на основе данных Perplexity и Алисы AI);
• технические дефекты записи и ошибки сбора.

Сбор данных производился с помощью написанного мною парсера на Python. Однако в процессе тестирования выяснилось: итоговые показатели видимости сильно искажались не из-за работы нейросети, а по причине подводных камней в алгоритмах сбора данных.

Три метода сбора ответов ChatGPT на одинаковом пуле запросов

В течение одной недели я снял ответы на выбранные 20 вопросов тремя кардинально разными способами. Результаты сбора существенно отличались по ключевым метрикам:

Ошибка 402 в третьем прогоне возникла из-за исчерпания лимита на балансе шлюза посредника. Пополнение баланса прервалось на третьей итерации, из-за чего весь третий повтор оказался полностью потерян.

Важным техническим нюансом стало различие в вызове веб-поиска через API. В модели gpt-4o поиск включался через web_search_options: алгоритм сам решал, выходить ли в сеть, но в итоговом объекте ответа отметки об этом не оставалось. Поэтому статус поиска оказался пустым, хотя ссылки в ответах присутствовали. У gpt-5.5 поиск вызывается как отдельный инструмент: вызовы и аннотации отдаются в структурированных полях API, что позволяет корректно отслеживать факты выхода в интернет.

В третьем съёме на трех вопросах («как заказать аудит видимости бренда в нейросетях», «как управлять репутацией компании в ответах ИИ» и «можно ли гарантировать попадание в ответы нейросети») ChatGPT не выходил в сеть ни в одной из итераций. Всего в лог попало 10 записей с пометой «поиск не отработал».

Реальная частота упоминания бренда без прямых подсказок

Анализ упоминаний целевого бренда показал следующие результаты в зависимости от метода съёма:

• 1-й съём (API gpt-4o): бренд прозвучал в 1 ответе из 57 на небрендовые вопросы (менее 2% ответов). В разрезе вопросов — на 1 из 19 вопросов. В брендовом вопросе — 3 из 3 раз.
• 2-й съём (Веб-интерфейс): 0 упоминаний из 19 на небрендовые вопросы. На брендовый вопрос — 1 из 1 (ответ содержал подробную сравнительную таблицу на 27 098 знаков).
• 3-й съём (API gpt-5.5): 0 упоминаний из 41 успешного ответа на небрендовые запросы. На брендовый вопрос — 2 из 2 раз.

Единственное органическое упоминание бренда произошло при вопросе об аудите видимости, где ChatGPT привел ссылку на статью клиента о ручной проверке позиций в ИИ.

Обратите внимание на разницу в метриках: при подсчете по ответам получается 1 из 57 (около 1.7%), а при подсчете по вопросам — 1 из 19 (около 5.2%). Данные одни и те же, но разница в подаче цифр трёхкратная.

Что касается шести отслеживаемых конкурентов, ChatGPT упомянул их лишь в 3 ответах из 43 в рамках третьего съёма. Другие сторонние компании в ответах появлялись, однако они не входили в заранее заданный список отслеживания.

Совпадение доменов-источников: интерфейс против API

Сравнение списка сайтов, на которые ссылается ChatGPT, выявило сильное расхождение между веб-чатом и API-доступом. На одном и том же наборе из 20 вопросов веб-интерфейс задействовал 49 доменов, а API (третий съём) — 68 доменов. Пересечение составило всего 17 общих сайтов. На 6 из 12 вопросов, где обе системы вывели ссылки, не совпало вообще ни одного домена!

Для объективной оценки я пересчитал пересечения по парам ответов на одинаковые вопросы (исключив технические домены google.com, openai.com, bing.com):

• Третий съём (API gpt-5.5, повтор 1 vs повтор 2): 23% общих доменов (14 из 61), на 1 вопросе общих ссылок не было.
• Первый съём (API gpt-4o, повтор 1 vs повтор 2): 41% общих доменов (38 из 93), на 1 вопросе общих ссылок не было.
• Интерфейс vs API gpt-5.5 (только 1-й повтор): всего 11% общих доменов (8 из 70), на 3 вопросах полное отсутствие общих ссылок.

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

Интересно и сравнение с поисковой системой Алиса AI на 8 коммерческих запросах: Алиса сослалась на 39 доменов, интерфейс ChatGPT — на 30 (7 общих с Алисой), а API ChatGPT — на 40 (также 7 общих с Алисой). Таким образом, перекрытие с выдачей Алисы AI не превышает 25% независимо от способа съёма.

На вопросе «как сделать, чтобы нейросети рекомендовали мой бренд» интерфейс сослался на bing.com, blogs.bing.com и help.openai.com. API в том же вопросе ссылался на developers.google.com, help.openai.com и support.google.com, используя официальные гайды OpenAI, Google и рекомендации Bing для вебмастеров.

Технические ошибки парсинга, искажающие статистику ссылок

В ходе работы я столкнулся с тремя проблемами сбора данных, которые лечатся доработкой кода парсера, а не банальным занесением сайтов в чёрный список.

1. Проблема с иконками Google Favicons

В веб-интерфейсе ссылки на источники оформляются графическими иконками вида: https://www.google.com/s2/favicons?domain=https%3A%2F%2Fsite.ru&sz=128. Изначально мой парсер собирал все ссылки из круглых скобок в Markdown простым регулярным выражением:

import re

def source_urls(text: str) -> list[str]:
    # Изначальный вариант: захватывал и ссылки, и фавиконки
    return re.findall(r"\((https?://[^\s\)]+)\)", text)

Из-за этого 32 ссылки из 120 превратились в ошибочный источник google.com, исказив четверть всей статистики. Для решения проблемы я переписал функцию извлечения доменов:

import re
from urllib.parse import urlparse, parse_qs, unquote

def source_domains(answer: str) -> set[str]:
    """Извлечение реальных доменов-источников с раскодированием URL фавиконок."""
    domains = set()
    for url in re.findall(r"https?://[^\s)\]\"']+", answer):
        parts = urlparse(url)
        host = (parts.hostname or "").removeprefix("www.")
        if host == "google.com" and parts.path.startswith("/s2/favicons"):
            inner = unquote(parse_qs(parts.query).get("domain", [""])[0])
            host = (urlparse(inner).hostname or inner).removeprefix("www.")
        if host:
            domains.add(host)
    return domains

2. Расхождения в подсчёте ссылок внешним сервисом

Сторонний сервис, через который снимался интерфейс, зафиксировал 382 ссылки в 20 ответах, тогда как в чистом тексте ответов было ровно 120 ссылок. Чтобы не плодить фантомные данные, парсер игнорирует счётчики сторонних сервисов и анализирует только сырой текст ответа.

3. Попадание учебных доменов из кода в источники

При выгрузке ответов через API в список источников попадали технические домены вроде example.com, schema.org или ваш-домен.ru, фигурировавшие в примерах кода в самом тексте ответа. Фильтровать их чёрным списком бессмысленно — шаблоны могут быть любыми. Решение — проверка факта запуска веб-поиска по служебным метаданным API:

def search_performed(channel_type, sources, extra):
    if channel_type == "model_bare":
        return False
    if extra.get("search_calls") or extra.get("api_annotations"):
        return True
    if any(s.get("origin") == "api" for s in sources):
        return True
    if channel_type == "surface":
        return None
    return False

Практические выводы и правила построения корректного ИИ-мониторинга

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

1. Не смешивать веб-интерфейс и API в один показатель. У них разная механика поиска, разные домены в выдаче и разный уровень детализации метаданных.
2. Считать долю упоминаний по вопросам, а не по ответам. Повторные прогоны нужны для оценки стабильности ответа, но они не должны раздувать общий объем выборки в отчетах.
3. Использовать строго структурированные поля API для сбора источников. Текст ответа может содержать фантомные ссылки и примеры кода, поэтому для API-съёма нужно брать лишь те ссылки, которые переданы в аннотациях объекта ответа.
4. Делать несколько повторов на каждый вопрос. Из-за высокой вариативности выдачи LLM один прогон не дает объективной картины.
5. Корректно обрабатывать ошибки сбора. Сбои сети или ошибки оплаты (402) должны фиксироваться как дефекты сбора, а не трактоваться как «отсутствие упоминания бренда».

Источник: habr.com