AI-Агентам Векторный Поиск Необходим Больше, Чем RAG

Какова роль векторных баз данных в мире агентского ИИ? Этот вопрос активно обсуждается организациями в последние месяцы. Была распространена точка зрения, что по мере расширения контекстных окон больших языковых моделей до миллионов токенов специализированный векторный поиск станет лишь временным решением, а не полноценной инфраструктурой. Считалось, что агентская память сможет полностью решить проблему извлечения информации, а векторные базы данных останутся пережитком эпохи RAG (Retrieval-Augmented Generation). Однако практический опыт показывает обратное.

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

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

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

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

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

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

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

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

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

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

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

Три признака того, что пришло время изменить текущую настройку

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