EMBERS и таксономия сбоев Deep Research: почему поисковые агенты ломаются в 65,6% случаев ещё до первого запроса в веб

Карта из 9 точек отказа (D1–D9) используется в двух режимах: как чек-лист защиты промпта при постановке задачи поисковому агенту (в 1 запросе) и как процедура стресс-тестирования агента (EMBERS) в серии прогонов:

ЭТАП 1: Формулировка подвопросов (65,6% всех сбоев)
  ├─ D1: Двусмысленная формулировка (18,8%) → агент путает сущности, время или ссылки («он/тот»)
  ├─ D3: Потеря контекста в подвопросах (18,5%) → при дроблении задачи агент выбрасывает ключевое ограничение
  ├─ D4: Перекос внимания (17,4%) → агент игнорирует важную зацепку, которая прямо написана в вопросе
  └─ D2: Непрямое/нишевое описание (10,9%) → агент не узнаёт объект по косвенным признакам и ищет не то

ЭТАП 2: Онлайн-поиск (24,2% всех сбоев)
  ├─ D8: Нечитаемый контент страниц (11,2%) → сайт закрыт, не парсится или обрезан
  ├─ D6: Чувствительность поискового запроса (5,7%) → разговорные слова уводят выдачу в сторону
  ├─ D5: Отвлечение на популярную соседнюю тему (4,7%) → громкий инфоповод забивает узкий факт
  └─ D7: Ошибки перевода между языками (2,6%) → искажение имён и терминов при кросс-языковом поиске

ЭТАП 3: Финальная сборка ответа (10,2% всех сбоев)
  └─ D9: Сложный ресёрч + простая операция (10,2%) → все факты найдены верно, но сбой на подсчёте, сортировке дат или вычитании

Задача: Продуктовый аналитик или инвестор запускает Deep Research агента (в ChatGPT, Perplexity, Claude или корпоративном ReAct-агенте), чтобы собрать и отсортировать в хронологическом порядке реальные сделки M&A российских IT-компаний за 2023–2025 годы с жёсткими фильтрами (только доли свыше 50%, без внутригрупповых реорганизаций), и хочет защитить запрос от 9 типовых сбоев декомпозиции и подсчёта.

Промпт:

Мне нужно провести глубокое веб-исследование (Deep Research):
Найди и выстрой в строгом хронологическом порядке (от самой ранней к самой поздней) 5 публично раскрытых сделок по покупке российскими IT-холдингами (Яндекс, VK, Т-Технологии, Ростелеком, Софтлайн) контрольных пакетов (строго более 50%) в других российских софтверных или медиа-компаниях, закрытых в период с 1 января 2023 по 31 декабря 2025 года (внутригрупповые реорганизации и покупка миноритарных долей не учитываются).

Чтобы избежать сбоев на этапе декомпозиции, поиска и финального расчёта, выполняй исследование строго по протоколу защиты от дефектов D1–D9:

1. ЗАЩИТА ЭТАПА ДЕКОМПОЗИЦИИ (против D1, D2, D3, D4):
- Сначала выпиши ВСЕ жёсткие ограничения задачи в отдельный блок [CONSTRAINTS]: (а) покупатель из списка 5 холдингов, (б) доля > 50%, (в) дата закрытия сделки (а не слухов/анонса!) внутри 2023–2025 гг., (г) не внутригрупповая передача.
- При формулировке КАЖДОГО подвопроса явно дублируй в нём эти ограничения (не сокращай подвопрос до «кого купил Софтлайн», пиши с годом и типом сделки, чтобы не потерять контекст — дефект D3).
- Убедись, что ни одна деталь из моего запроса не пропущена (дефект D4).

2. ЗАЩИТА ЭТАПА ОНЛАЙН-ПОИСКА (против D5, D6, D7, D8):
- Формулируй поисковые запросы сухими фактологическими терминами («закрыл сделку», «приобрёл контрольный пакет», «доля»), без разговорных фраз (дефект D6).
- Не подменяй малоизвестную сделку самой громкой новостью компании за тот же год, если в громкой новости доля меньше 50% или сделка не была закрыта (защита от популярного соседа — дефект D5).
- Если страница источника не открылась или обрезана (дефект D8), обязательно найди подтверждение даты закрытия и доли во втором независимом деловом СМИ (РБК, Коммерсантъ, Ведомости, Интерфакс).

3. ЗАЩИТА ФИНАЛЬНОЙ СБОРКИ (против D9):
- После сбора фактов НЕ сортируй сделки «в уме». Сначала выпиши таблицу: [Сделка | Точная дата закрытия в формате ГГГГ-ММ-ДД | Доля % | Источник].
- Отдельным шагом проверь неравенства дат: Дата_1 < Дата_2 < Дата_3 < Дата_4 < Дата_5 и пересчитай количество сделок.

Результат: Вместо того чтобы сразу кинуться в поиск с короткими запросами вроде «сделки VK 2024», нахвататься анонсов или миноритарных покупок и перепутать порядок дат в финальном абзаце, агент сначала зафиксирует матрицу ограничений, пронесёт фильтр «доля > 50%, дата закрытия» через каждый подвопрос, а перед выводом ответа явно нормализует даты в формат ГГГГ-ММ-ДД и проверит их порядок.

Главная слабость поисковых ReAct-агентов — каскадное размножение ранней ошибки. В отличие от обычного чата, где модель отвечает за один шаг, Deep Research агент сам себе ставит промежуточные задачи. Когда пользователь пишет сложный вопрос с косвенным описанием или несколькими условиями, агент на первом шаге разбивает его на простые подвопросы. При этом срабатывает потеря контекста (D3 — 18,5% всех ошибок) и перекос внимания (D4 — 17,4%): модель выкидывает из подвопросов «лишние» уточнения (например, год, географию или исключение), ищет в интернете широкую тему, попадает на популярный соседний сюжет (D5) и дальше уже уверенно строит весь отчёт вокруг неверно найденного объекта.

Вторая неочевидная слабость — провал простых операций в конце длинного контекста (D9 — 10,2% всех ошибок). Когда контекстное окно агента уже забито десятками спарсенных веб-страниц и черновиками поиска, модель теряет концентрацию на элементарной логике: она уже нашла все правильные даты и числа, но при сборке финального ответа ошибается в вычитании, сортировке хронологии или подсчёте элементов.

Явная фиксация ограничений внутри каждого подвопроса и вынесение финальной арифметики/сортировки в отдельный проверочный шаг перекрывают ровно 75,8% всех зафиксированных причин падения поисковых агентов (65,6% на этапе формулировки подвопросов + 10,2% на финальном рассуждении).

Рычаги управления: - Разрешение косвенных описаний до поиска (против D2) → если в задаче объект задан описательно («компания, чей основатель раньше руководил...»), заставьте агента отдельным первым шагом установить и перепроверить точное имя сущности, и только после этого генерировать остальные подвопросы. - Кросс-языковые якоря (против D7) → если агент ищет зарубежные источники по русскому запросу (или наоборот), требуйте выписывать оригинальное написание имени/термина на языке источника в скобках перед генерацией поисковых строк.

Ниже — универсальный шаблон два в одном: его можно вставить в системную инструкцию своего поискового агента (AGENTS.md / CLAUDE.md) для предотвращения сбоев либо использовать для стресс-тестирования (EMBERS-фаззинга) своего бота на устойчивость.

  {сложный_поисковый_запрос}

  
    Перед генерацией поисковых запросов выполни проверку по 4 правилам:
    1. [Anti-D1 Ambiguity]: Расшифруй все местоимения, временные привязки («в том же году», «после этого») и неоднозначные термины.
    2. [Anti-D2 Niche Entity]: Если объект задан косвенным описанием, выдели отдельный подвопрос №1 исключительно на идентификацию и верификацию точного названия объекта.
    3. [Anti-D3 Context Carryover]: Выпиши список всех ограничений задачи: {ключевые_ограничения}. Включай релевантные ограничения в текст КАЖДОГО подвопроса, чтобы они не потерялись при поиске.
    4. [Anti-D4 Clue Checklist]: Пронумеруй все зацепки и условия из  и проверь, что каждому условию соответствует хотя бы один подвопрос.
  

  
    При формировании запросов к поисковику и чтении страниц:
    5. [Anti-D5 Popular Distraction]: Проверяй, что найденный источник относится именно к целевой сущности, а не к более популярному тёзке или громкому смежному событию.
    6. [Anti-D6 Query Precision]: Используй строгие ключевые слова и термины предметной области вместо разговорных формулировок.
    7. [Anti-D7 Multilingual Anchor]: При поиске на другом языке дублируй точные оригинальные названия сущностей без вольного перевода.
    8. [Anti-D8 Unreadable Fallback]: Если страница недоступна или обрезана, не додумывай факт по сниппету — сделай резервный запрос к альтернативному источнику.
  

  
    9. [Anti-D9 Explicit Operation]: Прежде чем писать финальный ответ, выпиши все найденные факты и числа в сводную таблицу, приведи даты и единицы измерения к одному формату и выполни {финальная_операция_сортировка_или_расчёт} по шагам с явной проверкой.
  

Что подставлять в плейсхолдеры: - {сложный_поисковый_запрос} — ваш вопрос для Deep Research, требующий поиска и сопоставления фактов из нескольких источников. - {ключевые_ограничения} — период, география, пороговые числа, исключения, которые нельзя потерять по ходу поиска. - {финальная_операция_сортировка_или_расчёт} — что нужно сделать с найденными фактами в конце (отсортировать по дате, посчитать сумму/разницу, отобрать ровно N объектов).

🚀 Быстрый старт — вставь в чат:

Вот шаблон защиты поискового агента по таксономии EMBERS. Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит ваш поисковый запрос, какие жёсткие фильтры нельзя потерять при разбивке на подвопросы и какая расчётная или логическая операция нужна в финале — потому что именно на потере фильтров (D3/D4) и финальной сборке (D9) ломаются поисковые агенты.

⚠️ Нестабильность агентов от запуска к запуску: Даже без всякого изменения вопроса поисковые системы дают сильный разброс: например, агент WebSailor на бенчмарке FRAMES-ZH отвечает правильно с первой попытки в 18,34% случаев, но выдаёт правильный ответ три раза подряд (Consistent@3) лишь в 6% задач.

⚠️ Недоступность закрытых веб-страниц (D8) промптом не лечится: Около 11,2% всех сбоев поисковых агентов связано с тем, что нужная веб-страница не парсится, закрыта капчей или обрезана инструментом чтения. Промпт может лишь заставить агента искать дублирующий источник, но если факт есть только на одной закрытой странице, агент не справится.

⚠️ Полный цикл фаззинга EMBERS требует кодовой обвязки: Если вы хотите не просто защитить свои запросы по таксономии D1–D9, а автоматически гонять генератор мутаций EMBERS на сотнях траекторий своего агента, потребуется подключить фреймворк авторов к логам вашего агента.

Команда из Тяньцзиньского университета и компании Huawei собрала 1 932 полные траектории выполнения от трёх репрезентативных систем глубокого поиска — промышленной DeepDiver и открытых WebSailor и WebExplorer — на трёх сложных бенчмарках многошагового поиска (Bamboogle, FRAMES-ZH и BrowseComp-ZH). Из неверных траекторий исследователи по статистической выборке (доверительный интервал 95%) отобрали 384 провала и вручную, шаг за шагом, проследили, где именно зародилась первая неисправленная ошибка, которая в итоге обрушила финальный ответ.

Результат удивил: - 65,6% всех сбоев (252 из 384) произошли уже на этапе формулировки подвопросов (Subquestion Formulation): из-за двусмысленных фраз (D1 — 18,8%), потери обязательных условий при дроблении вопроса (D3 — 18,5%), игнорирования прямых подсказок в вопросе (D4 — 17,4%) и нераспознанных косвенных описаний (D2 — 10,9%). - 24,2% сбоев (93 из 384) возникли на этапе онлайн-поиска (Online Search): из-за нечитаемых веб-страниц (D8 — 11,2%), неудачных разговорных запросов (D6 — 5,7%), отвлечения на популярные соседние темы (D5 — 4,7%) и кривого перевода между языками (D7 — 2,6%). - 10,2% сбоев (39 из 384) случились на этапе финального рассуждения (Final Reasoning, D9): агент нашёл в вебе абсолютно все нужные факты, но ошибся в элементарном счёте, арифметике или сортировке дат!

Вооружившись этой таксономией из 9 дефектов, авторы построили фреймворк EMBERS: он берёт вопросы, на которые поисковый агент стабильно отвечает правильно, и вносит в них (или в промежуточные поисковые запросы) направленные мутации по правилам D1–D9, сверяя через веб-поиск, чтобы правильный ответ не изменился. На 16 конфигурациях «фреймворк — модель — датасет» за одинаковый 24-часовой бюджет тестирования EMBERS находил фатальные сбои агентов в 3,21 раза быстрее, чем лучший из существующих методов (DR-Arena и RobustAlpacaEval). А дообучение модели WebSailor-32B на найденных через EMBERS примерах подняло стабильность трёхкратного правильного ответа (Consistent@3) сразу на 9,13 процентного пункта.

🔧 Техника: Стресс-тест собственного поискового агента в чате по 4 главным мутациям EMBERS → быстрая проверка надёжности промпта

Перед тем как запускать корпоративного поискового бота в прод, возьмите 5 контрольных вопросов, на которые он отвечает правильно, и попросите любую LLM сгенерировать для каждого 4 «ядовитых близнеца» по главным дефектам из статьи:

Copy

Возьми мой контрольный вопрос: «{исходный_вопрос}» (правильный ответ: {ответ}).
Сгенерируй 4 тестовых варианта этого же вопроса, которые имеют ТОЧНО ТАКОЙ ЖЕ правильный ответ, но проверяют уязвимости поискового агента:
1. [Тест D2 — Косвенное описание]: Замени прямое название главной компании/человека на однозначное косвенное описание без изменения сути.
2. [Тест D3/D4 — Многосоставное ограничение]: Перенеси ключевое ограничение по дате или категории в придаточное предложение в начале вопроса, добавив рядом 2 нейтральные контекстные детали.
3. [Тест D5 — Популярный сосед]: Упомяни в вопросе сравнение или контраст с гораздо более известным объектом из той же сферы.
4. [Тест D9 — Финальная операция]: Попроси в конце не просто назвать факты, а отсортировать их в обратном хронологическом порядке и посчитать разницу в годах между первым и последним.

Исследование: EMBERS: Empirically Motivated Robustness Testing of Deep Research Systems via Defect-Guided Fuzzing (arXiv:2611.03723v1) Авторы: Shuochuan Li, Zan Wang, Dong Wang, Yuhang Jiang, Huajin Cui, Junjie Chen (Tianjin University), Chen Zhang, Gang Wang (Huawei Technologies Co., Ltd.)