Две нейросети могут предлагать разных поставщиков и одновременно не рекомендовать вашу компанию. Полезнее спросить не «какая модель хуже», а какие данные позволяют определить следующий шаг для бренда. Исследование рекомендаций показывает, почему внешне похожий провал требует осторожной диагностики.
Что обнаружили авторы
В препринте Divergent Recommendations, Convergent Diagnoses авторы из Unusual сравнили два пула API-моделей на 215 коммерчески сформулированных вопросах в четырёх сериях. Среднее пересечение рекомендованных брендов по Жаккару составляло около 0,35: системы заметно различались по выбору.
Для 7 763 сочетаний, где обе стороны не рекомендовали бренд, авторы получили 95,1% совпадений в классификации наблюдаемого этапа неуспеха. Преобладал этап отсутствия обнаружения. Это важно: большое совпадение при сильном перекосе классов нельзя читать как универсальную точность диагноза.
Работа использует журналы поиска и автоматическую согласованную разметку. Её результат не означает, что одна модель может достоверно объяснить причины поведения другой по тексту ответа. Авторы отдельно подчёркивают: этап описывает наблюдаемый след, а не установленную причину.
Три уровня, которые видны по-разному
| Уровень | Что требуется проверить | Что доступно в обычном ответе |
|---|---|---|
| Обнаружение | Попадал ли бренд в поисковые запросы, найденные страницы и фрагменты | Обычно полного журнала нет |
| Упоминание | Назван ли бренд в тексте | Можно проверить непосредственно |
| Рекомендация | Предложен ли бренд как подходящий вариант | Нужно прочитать контекст и условия |
Не названный бренд мог отсутствовать в найденных материалах, не соответствовать ограничениям или не попасть в короткий список. Один публичный ответ не различает эти объяснения.
С другой стороны, упоминание в фразе «не подходит для вашей задачи» не является положительной рекомендацией. Автоматическая сумма всех названий способна скрыть именно тот результат, который важен коммерческой команде.
Как провести собственный разбор
Возьмите реальные задачи выбора поставщика с одинаковыми обязательными условиями. Для каждой системы сохраните точный вопрос, дату, режим и серию ответов. Разметьте в них компанию: отсутствует, упоминается без рекомендации, предлагается как вариант, исключается с объяснением.
Если система показала ссылку, откройте конкретную страницу. Проверьте, есть ли там сведения, которые помогают решить поставленную задачу. Отсутствие бренда в показанных ссылках отмечайте именно так; не переименовывайте это в доказанный сбой обнаружения.
Затем составьте карту действий:
- Факт о продукте искажён: сохранить цитату, URL и официальное подтверждение.
- Бренд исключён по ограничению: проверить актуальность ограничения и географию.
- Бренд не назван, источники неполны: поставить гипотезу, собрать дополнительные наблюдения.
- Разные системы дают разные обоснования: проверить каждое основание отдельно.
Что добавляет brandfound
В разделе источников можно сузить данные по компании, продукту, кластеру и периоду, затем раскрыть домен до URL. Используйте полный ответ, чтобы связать ссылку с конкретным объяснением рекомендации.
Ссылочная таблица не является полным журналом внутренних поисковых действий. Не обещайте на её основании установить невидимый этап воронки. Её полезный результат здесь: проверяемый перечень утверждений и страниц, по которым команда может действовать.
Какое решение защищает от лишней работы
Если две системы повторяют один устаревший факт и показывают один источник, разумно начать с него. Если одна ссылается на цену, другая на недоступность услуги, общее переписывание страницы без проверки обоих фактов будет слабой задачей.
После исправления повторите прежние сценарии. Изменения рекомендаций считайте отдельно по системам, сохраняя число ответов и условия. Исследование поддерживает внимание к этапам, но не разрешает назначать скрытую причину без соответствующих данных.