Одна из самых легких ловушек в RAG — это посмотреть на панель метрик поиска, увидеть здоровые показатели и заключить, что система работает хорошо. Вы можете увидеть:
- высокий Success@K,
- сильный recall,
- хорошую метрику ранжирования,
- и больший K, кажущийся улучшающим охват.
На бумаге все может выглядеть лучше, но в действительности агент может вести себя хуже. Ваш агент может иметь целый ряд проблем, таких как размытые ответы на запросы, ненадежное использование инструментов или просто рост задержки и стоимости токенов без реальной пользы для пользователя.
Это рассогласование происходит потому, что большинство панелей поиска по-прежнему отражают мировоззрение поиска для человека. Они предполагают, что потребитель полученного набора может просматривать, фильтровать и игнорировать мусор. Люди удивительно хорошо в этом справляются. LLM последовательно хорошо в этом не справляются.
LLM не «замечает» десять полученных элементов и небрежно сосредотачивается на двух лучших так, как это сделал бы сильный аналитик. Он обрабатывает весь пакет как контекст подсказки. Это означает, что уровень поиска выводит доказательства, которые активно формируют рабочую память модели.
Именно поэтому я думаю, что команды агентов должны перестать относиться к поиску как к проблеме ранжирования в обслуживании и начать относиться к нему как к проблеме выделения бюджета рассуждений. При разработке производительных агентских систем ключевой вопрос заключается в следующем:
- Мы извлекли что-то релевантное?
- Сколько шума мы заставили модель обработать, чтобы получить эту релевантность?
Это линза, к которой подталкивает вас BoR, и я считаю это очень полезным подходом.
Проектирование контекста становится дисциплиной первого класса
Одна из причин, по которой эта статья нашла отклик у меня, заключается в том, что она соответствует более широкому сдвигу, уже происходящему на практике. Инженеры программного обеспечения и практики машинного обучения, работающие над системами LLM, постепенно становятся чем-то близким к инженерам контекста.
Это означает проектирование систем, которые решают:
- что должно попасть в подсказку,
- когда оно должно попасть,
- в какой форме,
- с какой степенью детализации,
- и что должно быть исключено полностью.
В традиционном программном обеспечении мы беспокоимся о памяти, вычислениях и границах API. В системах LLM нам также необходимо беспокоиться о чистоте контекста. Окно контекста — это оспариваемая когнитивная недвижимость.
Каждый неуместный отрывок, дублированный фрагмент, слабо связанный пример, многословное определение инструмента и плохо рассчитанный по времени результат поиска конкурирует с тем, на чем модель должна сосредоточиться больше всего. Именно поэтому мне нравится метафора загрязнения. Неуместный контекст загрязняет рабочее пространство модели.
Статья BoR придает этой интуиции более строгую форму, говоря нам, что мы должны перестать оценивать поиск только по тому, успешен ли он. Мы также должны спросить, насколько лучше поиск по сравнению со случайностью на глубине (топ K полученных элементов), которую мы фактически используем. Это очень практический вопрос.
Почему перегрузка инструментами нарушает агентов
Именно здесь я думаю, что работа BoR становится особенно важной для реальных систем агентов.
В классическом RAG корпус часто велик. Вы можете извлекать из десятков тысяч или миллионов фрагментов. В этом режиме случайный шанс остается слабым дольше. Выбор инструмента совсем другой.
В агенте модель может выбирать между 20, 50 или 100 инструментами. Это звучит управляемо, пока вы не поймете, что несколько инструментов часто расплывчато правдоподобны для одной и той же задачи. Как только это происходит, помещение всех инструментов в контекст — это не тщательность. Это замешательство, выданное за полноту.
Я много раз видел этот паттерн в проектировании агентов:
- команда добавляет больше инструментов,
- описания становятся длиннее,
- перекрытие между инструментами увеличивается,
- агент начинает делать хрупкие или непоследовательные выборы,
- и первый инстинкт — еще сильнее настраивать подсказку.
Но часто реальная проблема архитектурная, а не на уровне подсказки. От модели требуется выбирать из перегруженного контекста, где различия слишком слабы и слишком многочисленны.
Что BoR здесь добавляет — это полезный способ формализовать что-то, что люди часто чувствуют только интуитивно: есть момент, когда задача выбора становится настолько переполненной, что модель больше не демонстрирует значимую избирательность.
Именно поэтому я настоятельно предпочитаю проекты агентов с:
- Поэтапный поиск инструментов: сужение поиска в шагах, сначала поиск небольшого набора правдоподобных инструментов, затем окончательный выбор из этого короткого списка, а не из полной библиотеки сразу.
- Маршрутизация по доменам: перед окончательным выбором инструмента означает сначала решить, к какой широкой области относится задача, например, поиск, CRM, финансы или кодирование, и только затем выбрать конкретный инструмент в этом домене.
- Сжатые сводки возможностей: представление каждого инструмента с кратким, высокосигнальным описанием того, для чего он предназначен, когда его следует использовать и чем он отличается от близлежащих инструментов, вместо того чтобы в подсказку попадали длинные многословные спецификации.
- Явное исключение неуместных инструментов: целенаправленное удаление инструментов, которые не подходят для текущей задачи, чтобы модель не отвлекалась на правдоподобные, но ненужные опции.
По моему опыту выбор инструмента следует рассматривать более как поиск, чем как статическое украшение подсказки.
Понимание BoR через выбор инструмента
Одна из самых полезных особенностей BoR заключается в том, что это уточняет, что действительно означает top-K в агентах, использующих инструменты.
При поиске по документам увеличение top-K часто
