Почему AI-агентам векторный поиск нужен больше, чем RAG

Вопрос о роли векторных баз данных в мире AI-агентов становится все более актуальным. Недавно бытовало мнение, что с увеличением контекстных окон больших языковых моделей до миллионов токенов, специализированный векторный поиск станет лишь временным решением, а не базовой инфраструктурой. Считалось, что память агентов сама решит проблему извлечения информации, а векторные базы данных уйдут в прошлое вместе с эрой RAG. Однако практика показывает обратное.

Компания Qdrant, разработчик открытого векторного поиска из Берлина, недавно объявила о привлечении $50 млн в рамках раунда B, спустя два года после раунда A в $28 млн. Это событие, совпадающее с выпуском версии 1.17 их платформы, подчеркивает важный момент: с появлением AI-агентов проблема извлечения данных не только не уменьшилась, но стала масштабнее и сложнее. Андрей Заярный, генеральный директор и сооснователь Qdrant, отметил: «Люди делают несколько запросов в минуту, а агенты — сотни или даже тысячи запросов в секунду, просто собирая информацию для принятия решений». Этот сдвиг кардинально меняет требования к инфраструктуре, к которым системы эпохи RAG не были готовы.

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

Агенты работают с информацией, на которой они не обучались: проприетарные корпоративные данные, актуальная информация, миллионы документов, постоянно меняющихся. Контекстные окна управляют состоянием сессии, но не могут обеспечить высокоточное извлечение данных из такого объема, поддерживать качество поиска при изменениях или справляться с огромным количеством запросов, генерируемых автономными решениями. Заярный подчеркивает, что большинство существующих фреймворков для управления памятью AI так или иначе используют векторное хранилище. Это прямое указание на то, что даже инструменты, позиционируемые как альтернативы памяти, в своей основе полагаются на инфраструктуру извлечения.

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

Версия Qdrant 1.17 напрямую решает эти проблемы. Функция обратной связи по релевантности улучшает полноту выдачи, корректируя оценку сходства на следующем проходе извлечения с помощью легковесных сигналов, генерируемых моделью, без переобучения основной модели встраивания (embedding). Функция отложенного веерного запроса (delayed fan-out) обращается ко второй реплике, если первая превышает настраиваемый порог задержки. Новый API телеметрии для всего кластера позволяет отслеживать состояние системы целиком, заменяя отладку по отдельным узлам.

Почему Qdrant больше не хочет называться просто «векторной базой данных»

Сегодня почти каждая крупная база данных, от гиперскейлеров до традиционных реляционных систем, поддерживает векторы как тип данных. Это изменило конкурентную среду: поддержка векторов стала стандартом. Что действительно остается специализированным, так это качество извлечения данных в промышленных масштабах. Именно поэтому Заярный предпочитает называть Qdrant иначе: «Мы создаем слой извлечения информации для эры AI». По его словам, базы данных предназначены для хранения пользовательских данных, но если важно качество результатов поиска, нужен поисковый движок. Его совет начинающим командам: используйте ту поддержку векторов, которая уже есть в вашем стеке. Команды переходят на специализированные решения для извлечения данных только тогда, когда масштаб проекта делает это необходимым.

«К нам ежедневно приходят компании, которые начинали с Postgres, думая, что этого достаточно, но это оказалось не так», — говорит Заярный. Архитектура Qdrant, написанная на Rust, обеспечивает высокую эффективность использования памяти и низкоуровневый контроль производительности, что недостижимо для языков более высокого уровня при той же стоимости. Открытый исходный код усиливает это преимущество: обратная связь от сообщества и широкое внедрение позволяют компании масштаба Qdrant конкурировать с вендорами, обладающими гораздо большими инженерными ресурсами. «Без этого мы бы не достигли того, что имеем сейчас», — добавил он.

Как две команды разработчиков обнаружили ограничения универсальных баз данных

Компании, создающие производственные AI-системы на базе Qdrant, приходят к одному и тому же выводу, но с разных сторон: агентам необходим слой извлечения данных, и разговорная или контекстная память не может его заменить. GlassDollar помогает таким предприятиям, как Siemens и Mahle, оценивать стартапы. Поиск является основным продуктом: пользователь описывает свою потребность на естественном языке и получает ранжированный список из миллионов компаний. Архитектура выполняет расширение запроса при каждом обращении — один запрос расходится на несколько параллельных, каждый из которых извлекает кандидатов с разных сторон, после чего результаты комбинируются и переранжируются. Это паттерн извлечения, характерный для агентов, а не для RAG, и он требует специализированной поисковой инфраструктуры для поддержания работы в больших объемах. Компания перешла с Elasticsearch по мере масштабирования до 10 миллионов проиндексированных документов. После перехода на Qdrant она сократила расходы на инфраструктуру примерно на 40%, отказалась от слоя компенсации на основе ключевых слов, который поддерживала для устранения пробелов в релевантности Elasticsearch, и увидела трехкратный рост вовлеченности пользователей. Камен Канев, руководитель отдела продуктов GlassDollar, заявил: «Мы измеряем успех по полноте выдачи. Если лучшие компании не попадают в результаты, все остальное не имеет значения. Пользователь теряет доверие». Память агентов и расширенные контекстные окна также недостаточны для обеспечения рабочей нагрузки, необходимой GlassDollar. «Это проблема инфраструктуры, а не задача управления состоянием диалога, — говорит Канев. — Это не то, что можно решить путем расширения контекстного окна».

Другой пользователь Qdrant — компания &AI, которая создает инфраструктуру для патентных споров. Ее AI-агент, Энди, выполняет семантический поиск по сотням миллионов документов, охватывающих десятилетия и множество юрисдикций. Патентные поверенные не будут использовать сгенерированный AI юридический текст, что означает, что каждый результат, выдаваемый агентом, должен быть основан на реальном документе. Херби Тернер, основатель и технический директор &AI, объясняет: «Вся наша архитектура спроектирована так, чтобы минимизировать риск галлюцинаций, делая извлечение данных основным примитивом, а не генерацию». Для &AI слой агентов и слой извлечения данных по замыслу разделены. «Энди, наш патентный агент, построен на Qdrant, — говорит Тернер. — Агент — это интерфейс. Векторная база данных — это источник истины».

Три признака, указывающие на необходимость перехода от текущей настройки

Практическая отправная точка: используйте любые векторные возможности, которые уже есть в вашем стеке. Вопрос не в том, стоит ли добавлять векторный поиск, а в том, когда ваша текущая настройка перестанет быть адекватной. Три признака указывают на этот момент: качество извлечения данных напрямую связано с бизнес-результатами; шаблоны запросов включают расширение, многоступенчатое переранжирование или параллельные вызовы инструментов; или объем данных достигает десятков миллионов документов. В этот момент оценка переходит к операционным вопросам: насколько хорошо ваша текущая настройка позволяет видеть, что происходит в распределенном кластере, и какой запас производительности она имеет при увеличении объемов запросов от агентов. Канев заключает: «Сейчас много разговоров о том, что заменит слой извлечения данных. Но для любого, кто создает продукт, где качество извлечения данных является самим продуктом, где пропущенный результат имеет реальные бизнес-последствия, необходима выделенная поисковая инфраструктура».