TL;DR
SearchAuditor — метод диагностики длинных «расследований» ИИ-агента (когда он много шагов ищет информацию в интернете и в конце выдаёт неверный ответ). Суть: вместо одного прохода по всей истории рассуждений для поиска ошибки, запускают три параллельные проверки с разными углами зрения, затем отдельный шаг-«судья» сравнивает их выводы и смотрит конкретные доказательства вокруг спорных моментов, чтобы вынести окончательный вердикт.
Главная находка: когда ИИ-агент долго ищет информацию и ошибается, ошибка почти никогда не в самом конце — она закладывается раньше и тихо тянется через десятки последующих шагов, а финальный ответ всё равно выглядит уверенным и гладким. Причём почти половина критических ошибок обнаруживается в последней третьи всей истории рассуждений — искать её эффективнее с конца, а не с начала. Самая частая причина сбоев — агент путает или теряет правильный вариант ответа среди множества найденных кандидатов (27% всех ошибок).
Метод решает это в три этапа: (1) три отдельные проверки — общий обзор, проверка по требованиям задачи, хронологический проход по шагам — ищут ошибку каждая своим способом; (2) судья сравнивает несогласия между отчётами и смотрит текст вокруг спорных шагов, а не просто голосует за большинство; (3) на основе финального диагноза формулируются конкретные инструкции, что исправить.
Схема метода
ШАГ 1 (параллельно, 3 отдельных запроса с разными промптами):
1а. Общий обзор → где, по мнению модели, впервые случилась ошибка
1б. Проверка по требованиям задачи → разбить вопрос на условия, найти
какое условие не подтверждено доказательствами, откатиться к моменту решения
1в. Хронологический проход → построить план по вопросу, пройти шаги
по порядку, найти ПЕРВЫЙ шаг, закладывающий ошибку (а не тот, что её повторяет позже)
ШАГ 2 (отдельный запрос-судья):
Сравнить 3 отчёта → выделить совпадения и разногласия → посмотреть
текст вокруг спорных шагов → финальный вердикт: точный шаг + причина ошибки
ШАГ 3 (отдельный запрос):
На основе диагноза → конкретные пошаговые инструкции по исправлению
(что изменить в процессе, а не «какой должен быть ответ»)
Пример применения
Задача: Вы попросили ChatGPT в режиме Deep Research (или Perplexity) собрать досье на потенциального бизнес-партнёра перед сделкой. Агент долго искал, прочитал десятки страниц — и в финале перепутал двух людей с похожим именем, выдав неверные данные о финансах и репутации.
Промпт:
Вот полная история переписки с AI-агентом (все рассуждения и поисковые
запросы), который дал неверный ответ на вопрос: {вопрос про партнёра}.
Известно, что ответ неверен: {в чём именно ошибка, если знаете}.
Проведи аудит в три этапа, каждый — с отдельного угла:
1) ОБЩИЙ ОБЗОР: прочитай всю историю целиком. Укажи шаг, на котором
впервые появилась ошибка, приведшая к неверному финалу. Объясни, что произошло.
2) ПРОВЕРКА ПО ТРЕБОВАНИЯМ: разбей исходный вопрос на отдельные условия.
Для каждого — подтверждено ли оно доказательствами из истории? Найди
самое раннее решение, где агент выбрал направление или кандидата без проверки.
3) ХРОНОЛОГИЧЕСКИЙ ПРОХОД: составь минимальный план того, что нужно
было сделать. Пройди шаги истории по порядку. Найди первый шаг, который
заложил путь к ошибке — а не тот, что просто её повторил позже.
Сравни три результата: где совпадают, где расходятся? Посмотри на
конкретные сообщения вокруг спорных шагов и вынеси финальный вердикт:
какой шаг и какая причина на самом деле. Причины выбирай из списка:
путаница между кандидатами-ответами, недостаточный охват поиска,
игнорирование условия задачи, доверие непроверенному источнику,
путаница между похожими сущностями, необоснованный вывод.
В конце — конкретные инструкции: что изменить в процессе поиска
начиная с найденного шага, чтобы получить верный ответ.
Результат: модель проведёт три отдельных мини-анализа (можно попросить показать каждый), затем сведёт их в единый вердикт с указанием конкретного сообщения/шага, категорией ошибки (скорее всего — путаница кандидатов, это самая частая причина) и пошаговыми инструкциями, что изменить, если запускать поиск снова.
Почему это работает
При одном сплошном проходе по длинной истории модель цепляется за последний заметный симптом, а не за первопричину — потому что финальные шаги на виду, а корень ошибки похоронен в шуме из десятков предыдущих сообщений. Это слабость: модель плохо держит в голове несколько разных критериев поиска одновременно на большом объёме текста.
Сильная сторона LLM — она хорошо выполняет узкую сфокусированную инструкцию. Если дать ей один конкретный угол зрения (только требования, только хронологию), она справляется точнее, чем пытаясь удержать всё сразу.
Метод разбивает работу на три узких прохода с разным фокусом, а затем добавляет отдельный шаг проверки доказательств вокруг спорных точек — это не даёт модели просто «согласиться» с большинством отчётов, а заставляет её реально свериться с текстом.
Рычаги управления: - Число ракурсов аудита → можно добавить четвёртый со своим фокусом (например, «проверка источников на надёжность») - Список причин ошибок → замените на свою таксономию под задачу (код-ревью, редактура текста, анализ переговоров) - Что считается «критическим шагом» → адаптируйте под свой контекст: не поиск в интернете, а этап рассуждения, этап написания текста, этап принятия решения
Шаблон промпта
Вот полная история рассуждений AI (или моя переписка с ним), которая
привела к неверному результату по вопросу: {вопрос}.
Ошибка в финале: {в чём заключается}.
Проведи аудит в три этапа с разных углов:
1) ОБЩИЙ ОБЗОР: найди шаг, где впервые возникла ошибка.
2) ПРОВЕРКА ПО ТРЕБОВАНИЯМ: разбей задачу на условия, найди какое
не подтверждено, найди момент решения без проверки.
3) ХРОНОЛОГИЯ: пройди шаги по порядку, найди ПЕРВЫЙ шаг, заложивший
ошибку, не последующие повторения.
Сравни три версии, разреши разногласия через текст вокруг спорных шагов.
Вынеси финальный вердикт: шаг + причина ошибки (выбери из: {список причин}).
Дай конкретные инструкции по исправлению процесса с этого шага.
Подставьте: {вопрос} — что вы просили сделать, {в чём заключается} — в чём неверность (если знаете), {список причин} — свои категории ошибок под задачу.
🚀 Быстрый старт — вставь в чат:
Вот шаблон трёхракурсного аудита ошибок. Адаптируй под мою задачу: {опиши свою длинную историю с AI, где получился неверный результат}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какая именно история переписки у вас есть и в чём заключается ошибка — потому что без конкретного лога рассуждений метод не сработает: ему нужен текст, по которому можно свериться с доказательствами.
Ограничения
⚠️ Точность ограничена: даже с этим методом лучшие модели угадывают точный шаг ошибки только в половине случаев. Это инструмент сужения поиска, а не оракул истины.
⚠️ Нужна подробная история: метод работает только если есть видимые промежуточные шаги рассуждений и поиска, а не просто финальный ответ без объяснений.
⚠️ Дороже одного запроса: три параллельных прохода плюс сведение результатов — это несколько отдельных обращений к модели, что медленнее и затратнее по токенам, чем один прямой вопрос «где ошибка?».
Ресурсы
SearchAuditBench и SearchAuditor — Zhixiang Liang, Yifei Liu и др., University of Illinois Urbana-Champaign и Joy Future Academy (JD). Код и данные: github.com/lzzzx666/SearchAuditor