Что мешает ИИ нормально искать ответы в интернете

Когда поисковый ИИ начинает ходить по кругу

У ИИ-агентов для поиска в интернете сегодня одна и та же старая проблема: чем длиннее задача, тем быстрее они забывают, что уже нашли, что еще не нашли и куда вообще двигались. Сначала все выглядит впечатляюще: модель ищет, открывает страницы, выписывает факты, собирает ответ. А потом начинается знакомое. Те же запросы. Те же сайты. Те же тупики. Бюджет поиска сгорает, а ответ остается дырявым.

Авторы SearchOS предлагают не “еще одного умного агента”, а скорее операционную систему для поиска. Идея простая: перестать хранить ход поиска в переписке с моделью и вынести его в явное, общее, постоянное состояние, доступное всем агентам. Это и есть главная ставка работы.

Почему это важно? Потому что следующий шаг в развитии ИИ-поиска — не просто отвечать на один вопрос, а собирать большие, проверяемые, структурированные ответы: списки, таблицы, сравнения, сводки по десяткам источников. Для таких задач одной “умной головы” уже мало. Нужны координация, память и контроль.

Что именно предлагают авторы

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

Представьте задачу: собрать список компаний, их выручку, руководителей, дату основания и ссылки на подтверждающие источники. Вместо абстрактного “найди все это в сети” система строит таблицы с ячейками. Каждая ячейка — это конкретный факт, который нужно заполнить. И не просто заполнить, а прикрепить к нему URL и фрагмент текста, где этот факт виден.

Так открытый поиск превращается в задачу с понятным прогрессом: какие строки найдены, какие поля пусты, где есть конфликт данных, а где поиск уже заходил в тупик.

Архитектура SearchOS: оркестратор, общая память поиска, подагенты и слой управления инструментами.

Внутри SearchOS есть несколько ключевых частей.

Но самое важное не роли. Самое важное — общая память поиска, которую авторы называют управлением поисковым контекстом.

Память, которая не живет в голове модели

SearchOS хранит состояние поиска в четырех явных структурах. Это, пожалуй, центральная идея статьи.

Это кажется почти очевидным: если агент долго ищет, нужно где-то хранить его прогресс. Но многие современные системы до сих пор полагаются на историю диалога и локальную память модели. В коротких задачах это еще терпимо. В длинных — нет.

У SearchOS есть важное следствие: агенты перестают гадать по контексту и начинают работать по общей карте местности. Один агент не будет снова идти туда, где другой уже ничего не нашел. Оркестратор видит реальные пробелы, а не пытается восстановить их из длинной переписки.

Как слой управления вмешивается в цикл поискового агента: подает контекст, извлекает доказательства и останавливает зацикливание.

Почему тут нужен не просто мультиагентный подход, а “поисковая ОС”

Обычный мультиагентный подход обещает ускорение: давайте запустим несколько агентов параллельно. Но на практике это легко превращается в хаос. Два агента ищут одно и то же. Третий ждет. Четвертый упирается в медленный сайт, и вся партия задач тормозит.

Авторы берут идею из мира обучения больших моделей на GPU: конвейерный параллелизм. Вместо того чтобы запускать работу пакетами и ждать, пока завершатся все участники, SearchOS сразу подбрасывает новую подзадачу в освободившийся слот.

Это маленькое инженерное решение дает большой эффект. Меньше простоя. Больше полезной работы в единицу времени. И, что важно, новые задачи берутся не случайно, а из карты незаполненного покрытия.

То есть система не просто “занимает свободные руки”, а целится в реальные дыры ответа.

Авторы показывают, что такой непрерывный режим снижает среднее время работы примерно на четверть, уменьшает число вызовов LLM и одновременно повышает качество итоговой таблицы. Это редкий случай, когда эффективность и качество растут вместе, а не обмениваются друг на друга.

Самый интересный слой: перехват инструментов и контроль поведения

Еще одна интересная часть статьи — так называемый слой управления инструментами. По сути, это прослойка между моделью и инструментами поиска.

Зачем она нужна? Потому что нельзя надеяться, что сама модель всегда будет дисциплинированной. Особенно на длинной дистанции. Она может забыть ограничение бюджета, пропустить важный факт, повторить бесполезный запрос или продолжать крутиться в цикле.

Этот слой делает три вещи.

Это важно. Контроль выносится из подсказки в инфраструктуру. И это, вероятно, один из самых полезных уроков статьи для всей индустрии ИИ-агентов. Надежность не надо целиком просить у модели словами. Ее нужно вшивать в систему.

Навыки: не учить поиск с нуля каждый раз

В SearchOS есть и библиотека навыков. Авторы делят ее на два уровня.

Это тоже практичная мысль. В реальном поиске мало уметь “рассуждать”. Нужно знать, как устроены конкретные места в сети. Где у сайта каталог. Где фильтры. Где удобнее брать структурированные данные. Такие процедуры можно переиспользовать между задачами, а не изобретать заново.

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

Траектории работы с вмешательством управления: после обнаружения застоя поиск снова начинает продвигать покрытие и находить сущности.

Что показали эксперименты

Авторы тестируют SearchOS на двух бенчмарках для открытого поиска: WideSearch и GISA. Оба заточены не под короткие ответы, а под длинные, структурированные, проверяемые результаты.

Главная метрика здесь — не просто “правильность ответа”, а полнота и точность по ячейкам и строкам таблиц. Это жестче и честнее: если в строке одна ошибка, строка может считаться неверной.

Результаты выглядят сильно. SearchOS обходит и одиночные системы, и другие мультиагентные подходы. Особенно заметен рост по полноте, то есть по способности не пропускать нужные факты.

Вот что бросается в глаза:

Почему особенно выросли задачи типа “множество”? Потому что там важно не просто найти пару верных ответов, а собрать полный набор. А карта покрытия и явный контроль пробелов как раз бьют в эту цель.

Авторы также делают любопытный разбор схем. Они сравнивают фиксированные структуры таблиц с динамическим планированием схемы во время поиска. Оказалось, универсальной структуры нет. Где-то лучше одна таблица, где-то несколько связанных. Поэтому решение “строить схему на лету” оказывается сильнее заранее заданных форматов.

Что здесь действительно новое

Если убрать детали реализации, главный вклад SearchOS можно свести к одной фразе: поиск стал задачей управления состоянием, а не только задачей генерации текста.

Это звучит просто, но меняет почти все:

На фоне гонки за “более умными агентами” это довольно приземленный, инженерный поворот. И именно поэтому он выглядит убедительно.

Ограничения и что может пойти не так

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

Кроме того, качество по-прежнему зависит от внешнего мира: доступности сайтов, структуры страниц, качества извлечения фактов, умения сопоставлять их со схемой. Если источник закрыт, сломан или двусмысленен, никакая красивая архитектура полностью это не отменит.

Есть и методологическая оговорка: авторы отчитываются по лучшему результату из трех запусков. Это полезно для оценки потенциала, но в реальной эксплуатации важна и средняя стабильность.

Выводы

Длинный веб-поиск для ИИ-агента упирается не столько в “интеллект”, сколько в организацию работы. Когда система явно хранит пробелы, доказательства, конфликты и неудачи, она начинает искать заметно надежнее.

Главная идея статьи — вынести состояние поиска из мозгов модели в общую инфраструктуру — выглядит очень жизнеспособной. Она помогает сразу по нескольким фронтам: повышает полноту, уменьшает повторения, делает параллельную работу осмысленной и добавляет проверяемость.

Для рынка ИИ-агентов это, возможно, один из самых полезных подходов прямо сейчас. Следующий скачок качества в сложных задачах может прийти не только от более сильных LLM, но и от систем, которые лучше помнят, координируют и контролируют сам процесс поиска. SearchOS — как раз про это.