Qdrant привлекает $50 млн для переосмысления поисковых систем в сфере ИИ

Какова роль векторных баз данных в мире агентного ИИ? Этот вопрос организации активно осмысливают в последние месяцы.

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

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

Qdrant, базирующаяся в Берлине компания по разработке систем векторного поиска с открытым исходным кодом, в четверг объявила о привлечении 50 миллионов долларов в рамках раунда финансирования серии B (спустя два года после раунда серии A на 28 миллионов долларов). Это совпадение не случайно. Компания также выпускает платформу версии 1.17. Все это отражает вполне конкретный тезис: проблема извлечения данных никуда не исчезла с появлением агентов. Она масштабнее и сложнее.

«Люди делают несколько запросов каждые несколько минут, — рассказал VentureBeat Андрей Заярный, генеральный директор и соучредитель Qdrant. — Агенты совершают сотни или даже тысячи запросов в секунду, просто собирая информацию для принятия решений».

Такой сдвиг меняет требования к инфраструктуре таким образом, к которому развертывания времен RAG изначально не были готовы.

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

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

«Большинство существующих фреймворков памяти для ИИ используют ту или иную форму векторного хранилища», — отметил Заярный.

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

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

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

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

Практически каждая крупная база данных теперь поддерживает векторы в качестве типа данных — от гиперскейлеров до традиционных реляционных систем. Этот сдвиг изменил характер конкуренции. Сам тип данных стал базовым требованием. Специализированным остается качество извлечения в производственных масштабах.

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

«Мы создаем уровень извлечения информации для эпохи ИИ, — сказал он. — Базы данных нужны для хранения пользовательских данных. Если важна точность результатов поиска, вам необходима поисковая система».

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

«К нам каждый день приходят компании и говорят, что они начали с Postgres и думали, что этого достаточно — но это не так».

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

«Без этого мы бы вообще не оказались там, где находимся сейчас», — подчеркнул Заярный.

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

Компании, создающие производственные ИИ-системы на базе Qdrant, отстаивают ту же мысль с разных сторон: агентам нужен уровень извлечения данных, и разговорная или контекстная память не может его заменить.

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

Компания мигрировала с Elasticsearch по мере роста индекса до 10 миллионов документов. После перехода на Qdrant она сократила инфраструктурные расходы примерно на 40%, отказалась от примитивного уровня компенсации по ключевым словам, который поддерживался для сглаживания пробелов в релевантности Elasticsearch, и зафиксировала трехкратный рост вовлеченности пользователей.

«Мы измеряем успех полнотой результатов, — рассказал VentureBeat Камен Канев, руководитель отдела продуктов GlassDollar. — Если лучших компаний нет в результатах поиска, все остальное теряет значение. Пользователь теряет доверие».

Агентской памяти и расширенных контекстных окон также недостаточно для обработки рабочей нагрузки, необходимой GlassDollar.

«Это инфраструктурная проблема, а не задача управления состоянием диалога, — заявил Канев. — Ее нельзя решить просто за счет увеличения контекстного окна».

Еще одним пользователем Qdrant является компания &AI, которая создает инфраструктуру для патентных судебных разбирательств. Ее ИИ-агент Энди (Andy) выполняет семантический поиск по сотням миллионов документов, охватывающих десятилетия и множество юрисдикций. Патентные поверенные не будут опираться на сгенерированный ИИ юридический текст, а это значит, что каждый результат, выдаваемый агентом, должен быть подкреплен реальным документом.

«Вся наша архитектура спроектирована так, чтобы минимизировать риск галлюцинаций за счет того, что извлечение данных является главным примитивом, а не генерация», — рассказал VentureBeat Херби Тернер, основатель и технический директор &AI.

Для &AI агентный уровень и уровень извлечения данных разделены по замыслу.

«Энди, наш патентный агент, построен поверх Qdrant, — пояснил Тернер. — Агент — это интерфейс. Векторная база данных — это источник достоверных данных».

Три сигнала о том, что пора менять текущую конфигурацию

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

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

«Сейчас много шума по поводу того, что именно заменит уровень извлечения данных, — отметил Канев. — Но для любого, кто создает продукт, где качество извлечения и есть сам продукт, где пропуск результата имеет реальные бизнес-последствия, необходима выделенная поисковая инфраструктура».