У AI-агента, по сути, две работы: сначала собрать контекст, потом на его основе ответить или что-то сделать. Проблема в том, что именно первый этап все чаще ломает всю конструкцию. Для команд, которые внедряют агентные системы в разработку, поддержку или внутренние сервисы, качество поиска становится уже не побочной настройкой, а главным техническим ограничением.
Об этом пишет The New Stack, разбирая сдвиг в архитектуре AI-агентов: если раньше основное внимание уходило на выбор модели и качество генерации, то теперь все заметнее, что сбои происходят раньше, еще на этапе извлечения нужного контекста. Агент может быть подключен к хорошей LLM, иметь доступ к базе знаний, документации, тикетам и коду, но если он поднимает не те документы, не ту версию спецификации или просто шум вместо сути, дальше начинается предсказуемая история: уверенный тон, сомнательный результат и лишняя работа для людей.
Логика здесь довольно приземленная. Большинство агентных систем не живут в вакууме и не отвечают из головы. Им нужно собрать материал из внешних источников: корпоративных wiki, GitHub-репозиториев, CRM, логов, таск-трекеров, таблиц, переписок, внутренних регламентов. То есть агент почти всегда работает как связка из двух компонентов: механизма поиска и механизма рассуждения или выполнения действия. И если раньше индустрия была занята вопросом, насколько хорошо модель умеет писать текст, то теперь на передний план выходит вопрос, насколько хорошо система умеет найти именно тот фрагмент информации, который нужен в конкретный момент.
Это меняет сам подход к проектированию. Ошибка генерации обычно заметна на выходе: ответ странный, код не компилируется, письмо звучит криво. Ошибка на этапе retrieval опаснее тем, что она часто выглядит правдоподобно. Агент может аккуратно собрать ответ на базе неполного, устаревшего или нерелевантного контекста. Для пользователя разница неочевидна: внешне система ведет себя уверенно, но фактически принимает решение на плохом основании. Для инженерных команд это неприятный класс дефектов, потому что он плохо ловится обычными демо и быстро всплывает в проде, когда запросы становятся сложнее и грязнее, чем в красивой презентации.
Отсюда и сдвиг в критериях качества. Просто подключить модель к векторной базе уже недостаточно. Нужно понимать, как система индексирует данные, как ранжирует источники, умеет ли отличать свежую информацию от архивной, как работает с длинными документами, что делает при конфликтующих версиях, как ведет себя при нехватке контекста. На практике именно эти детали отделяют игрушечного агента от рабочего инструмента. Один и тот же LLM-стек может давать совершенно разный результат в зависимости от того, насколько аккуратно собран retrieval-слой. И это плохая новость для тех, кто рассчитывал решить задачу одним апгрейдом модели.
Для разработчиков здесь нет особой магии, зато есть много скучной, но важной инженерии. Нужно оценивать не только итоговый ответ, но и путь, которым агент к нему пришел: какие документы поднял, что отбросил, на каком основании выбрал именно этот контекст. Нужны метрики полноты и релевантности поиска, сценарии регрессионного тестирования, наборы запросов из реальной эксплуатации, а не только из happy path. Нужна работа с данными как с продуктом: чистка дублей, нормализация структуры, контроль версий, разметка доверенных источников. Иначе команда довольно быстро обнаружит, что модель у них умная, а память у системы хаотичная.
Для бизнеса вывод еще проще. Когда AI-агента пытаются встроить в поддержку, аналитику, продажи, HR или внутреннюю разработку, вопрос упирается не только в стоимость токенов и скорость ответа. Намного важнее, можно ли доверять тому, что агент нашел и на чем он основывает действие. Если retrieval работает плохо, агент не ускоряет процессы, а создает новый слой операционного шума: неправильные ответы, лишние проверки, повторные запросы, ручную перепроверку сотрудниками. В таком режиме обещанная автоматизация превращается в дорогой интерфейс к внутреннему бардаку. Поэтому качество поиска становится не академической темой из RAG-дискуссий, а прямым фактором окупаемости.
На этом фоне меняется и сама конкуренция между платформами для агентных систем. Выигрывать будут не только те, у кого сильнее базовая модель или эффектнее демо, а те, кто лучше решает довольно земные задачи: доступ к данным, актуальность индекса, объяснимость выбора источников, контроль над контекстом, воспроизводимость ответа. И здесь для русскоязычной IT-аудитории есть практический вывод: если команда строит AI-агента для реальной работы, обсуждение нужно начинать не с красивых промптов, а с карты данных и критериев релевантности. Похоже, следующий большой вопрос рынка звучит уже не «насколько умен агент», а «насколько надежно он умеет искать».