Векторные базы данных для RAG: сравнение скорости и точности поиска

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

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

Точность Recall@10 и скорость — не зависимые величины

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

На больших коллекциях точный перебор всех векторов обходится дорого. Поэтому применяют ANN — Approximate Nearest Neighbor, алгоритмы приближённого поиска ближайших соседей. Они сокращают время ответа, но могут пропустить часть наиболее релевантных результатов. Компромисс описывает, в частности, Recall@10: эта метрика показывает, какая доля объектов из набора истинных ближайших соседей обнаруживается среди десяти результатов поиска.

Иногда в качестве ориентира обсуждают целевые значения полноты вроде 0,95 или 0,99. Это не универсальные нормативы и не характеристики конкретной базы: подходящий уровень зависит от задачи и цены пропущенного документа. Более высокая полнота может потребовать дополнительных вычислений, но сама по себе не гарантирует более полезный ответ. В RAG важно, чтобы в контекст попадали фрагменты, действительно нужные для ответа, а не просто похожие по смыслу.

Сравнивать latency векторных баз данных корректно только при сопоставимом качестве выдачи и похожем профиле нагрузки. Если одна конфигурация возвращает результаты быстрее, но теряет больше релевантных документов, для RAG она не обязательно лучше. Ошибка на этапе retrieval — извлечения фрагментов — переносится в контекст языковой модели: генератор не сможет надёжно опереться на сведения, которые не были найдены.

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

Быстрый средний запрос не компенсирует медленный хвост, если пользователь регулярно ждёт ответ дольше ожидаемого.

Что показывают сравнительные данные

В доступном сравнении указан масштаб коллекции в 1 млн векторов размерностью 1536d. Однако методология не позволяет считать приведённые значения результатом контролируемого сопоставления: не раскрыты все параметры оборудования, индексации и нагрузки, а также не указан целевой Recall@10, при котором получены замеры. Поэтому нельзя утверждать, что базы сравнивались при одинаковой полноте выдачи. Таблица ниже — ориентир для первичного знакомства с цифрами, а не рейтинг с гарантированно равными условиями.

В этих данных у Qdrant наименьшие значения p50 и p95 среди перечисленных решений. Для self-hosted развертывания также приводится пропускная способность порядка 850 запросов в секунду при p95 около 8 мс на 1 млн векторов. Milvus находится рядом по задержкам. pgvector с HNSW в этом сравнении отстаёт от двух лидеров незначительно, а Weaviate и Pinecone Serverless показывают более высокие значения, особенно по p95.

Но это не означает, что Pinecone медленный, а Qdrant будет быстрее при любом запросе. Во-первых, неизвестно, при какой полноте поиска получены значения для каждой системы. Во-вторых, сравниваются разные модели эксплуатации: в одном случае команда отвечает за инфраструктуру и настройки, в другом часть операционной работы берёт на себя облачный сервис. Дополнительные сетевые переходы, режим обслуживания и условия теста могут влиять на задержку не меньше, чем сам алгоритм поиска.

Таблица задаёт направление для первого отбора, но не заменяет нагрузочную проверку. На практике важно воспроизвести собственные запросы, фильтры и структуру данных, а затем сопоставить задержку с качеством результатов. Если методика исходного сравнения неизвестна, относиться к разнице в несколько миллисекунд как к окончательному вердикту тем более не стоит.

Для RAG важен и путь целиком. После поиска сервису ещё предстоит собрать контекст и отправить его языковой модели. Если генерация занимает существенно больше времени, выигрыш нескольких миллисекунд на retrieval может почти не изменить общую задержку ответа. Но при высокой частоте запросов, низком latency-бюджете или нескольких последовательных операциях поиск становится заметной частью времени и затрат.

Qdrant и Milvus: два варианта для отдельного поискового слоя

Qdrant и Milvus — специализированные системы, которые можно развернуть самостоятельно. Такой выбор подходит, когда векторный поиск становится отдельной частью архитектуры и его нагрузку нужно масштабировать независимо от основной базы данных.

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

Из одних чисел нельзя вывести, какая система окажется выгоднее для конкретного проекта. Эксплуатационная стоимость зависит от оборудования, резервирования, объёма данных и инженерного времени. Универсальной оценки затрат для крупных коллекций эти замеры не дают.

Выбор между ними стоит связывать с характером системы. Если векторный индекс должен жить отдельно, а команда готова обслуживать самостоятельный компонент, специализированное хранилище позволяет изолировать retrieval-нагрузку от транзакционной базы. Но появляется ещё один сервис, который нужно мониторить, обновлять, резервировать и согласовывать с процессом загрузки документов.

Такая архитектура особенно уместна, если коллекция быстро растёт или запросы к поиску имеют собственный профиль нагрузки. В медицинских продуктах, например, RAG может быть одним из компонентов цифровой платформы, наряду с записью, аналитикой и рабочими процессами клиники. При этом готовность организации к подобным системам определяется не только выбором БД; полезен отдельный разбор того, как оценивают цифровую зрелость здравоохранения. Технически быстрая выдача сама по себе не создаёт качественный сервис, если данные фрагментированы или процесс их обновления не определён.

pgvector: когда достаточно расширить PostgreSQL

pgvector хранит векторы внутри PostgreSQL. Это не компромисс по умолчанию и не признак того, что проекту не нужна серьёзная инфраструктура. Для системы, где документы и прикладные данные уже находятся в Postgres, расширение позволяет избежать отдельного хранилища на раннем этапе и выполнять поиск рядом с остальными данными.

Ключевое изменение в сравнении — индекс HNSW, доступный в pgvector начиная с версии 0.5.0. HNSW — графовая структура, которая помогает приближённо находить ближайшие векторы, не перебирая коллекцию полностью. Переход от прежнего варианта индексации IVFFlat к HNSW существенно снизил задержку поиска. На объёмах порядка 2–5 млн векторов pgvector может конкурировать со специализированными базами по скорости, хотя итог зависит от конфигурации и нагрузки.

В приведённых данных pgvector с HNSW показывает близкие к лидерам значения p50 и p95. Но это не доказывает, что при одинаковой полноте выдачи и на любой инфраструктуре он будет столь же быстр. У результата есть и архитектурное измерение: если PostgreSQL уже является центром приложения, выигрыш может состоять не только в миллисекундах. Меньше отдельных компонентов — проще путь данных и меньше операций синхронизации.

С другой стороны, совместное размещение векторного поиска и транзакционной нагрузки требует внимательно распределять ресурсы. Интенсивные запросы к индексу могут конкурировать с другими задачами базы. А если рабочая нагрузка постоянно меняется — например, документы часто добавляются и обновляются, — проверять нужно не только поиск по готовому индексу, но и поведение всей системы при записи.

Выбор векторной БД для LLM поэтому не сводится к правилу «специализированная быстрее». Если проект уже использует Postgres, ожидаемая нагрузка умеренная, а операционная простота важна, pgvector — рациональная стартовая конфигурация. Когда поиск становится самостоятельной высоконагруженной подсистемой, отдельную базу можно сравнить на тех же запросах и при одинаковом требовании к качеству выдачи.

Pinecone и Weaviate: задержка в контексте модели эксплуатации

В приведённых данных Pinecone Serverless и Weaviate имеют более высокие задержки: около 12 и 8 мс по p50 и 48 и 22 мс по p95 соответственно. Но без полного описания методики эти числа не позволяют отделить влияние самой системы от сетевых условий, настроек и различий в эксплуатации.

Здесь особенно важно не смешивать результаты самоуправляемого и облачного развертывания. Self-hosted система и управляемый сервис решают не одну и ту же задачу для команды: первая предлагает больше контроля над инфраструктурой, вторая может снять часть работ по её обслуживанию. Сравнение Milvus и Pinecone для RAG поэтому не заканчивается сопоставлением двух значений в таблице. Миллисекунды описывают поисковый этап в конкретных условиях, а не полную стоимость владения.

Управляемая модель может быть привлекательна, если команда не хочет поддерживать отдельный кластер. Однако конкретные расходы нельзя вывести из задержек, а производительность на коллекциях существенно большего масштаба требует отдельной проверки. Облачный сервис имеет смысл оценивать вместе с сетевым расположением приложения, режимом масштабирования и тем, какие операции команда передаёт провайдеру.

Weaviate также не следует отвергать только по более высокому p95 в одном сравнительном наборе. Если сервис удовлетворяет latency-бюджету продукта, подходит по модели развертывания и хорошо сочетается с остальной архитектурой, разница может быть приемлемой. Но когда задача чувствительна к длинному хвосту задержек, p95 нужно измерять на целевой нагрузке, а не заменять медианой.

Настройки индекса и реальная нагрузка

На производительность влияет не только название базы. Для HNSW существенны параметры построения графа и поиска, в том числе ef_construction и M. В общем виде они задают компромиссы между затратами на создание индекса, его размером, полнотой поиска и скоростью. При этом оптимальные значения зависят от модели данных и требований приложения; переносить настройки из чужого теста без проверки рискованно.

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

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

• Целевая полнота выдачи. Зафиксируйте требование к Recall@10 и сравнивайте системы при этом требовании. Значения вроде 0,95 или 0,99 могут быть полезны как тестовые ориентиры, но их нельзя приписывать уже опубликованным замерам без подтверждения.
• Размерность и состав коллекции. Результаты для векторов 1536d не следует напрямую переносить на 768d или на документы с другим распределением embeddings.
• Фильтрация по метаданным. Поиск только по векторной близости и поиск с ограничениями по атрибутам — разные сценарии; фильтры способны заметно изменить профиль нагрузки.
• Доля чтения и обновления. Индекс, который хорошо работает на статичной коллекции, может вести себя иначе, когда документы постоянно добавляются или обновляются.
• Распределение задержек. Измеряйте и p50, и p95: первая метрика показывает типичный ответ, вторая — устойчивость сервиса для большей части запросов.
• Полный путь RAG. Отделяйте задержку retrieval от времени построения контекста и генерации ответа, чтобы не оптимизировать компонент, который не является узким местом.

Проверка должна включать не только скорость, но и то, насколько хорошо найдены фрагменты отвечают задаче. Для этого полезно собрать набор типовых запросов и заранее определить, какие документы должны находиться. Затем можно сравнивать Recall@10 и задержку в одинаковых условиях. Такой подход не обещает универсального результата для любой нагрузки, зато показывает, как конкретная конфигурация ведёт себя именно на данных продукта.

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

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

Практический выбор для RAG-стека

Если нужна отдельная self-hosted система с низкими задержками в сравнительных данных, первыми кандидатами остаются Qdrant и Milvus. Но порядок в таблице не заменяет теста на собственной нагрузке, тем более что целевой Recall@10 для приведённых цифр не указан. Если данные уже находятся в PostgreSQL, pgvector с HNSW заслуживает полноценной проверки до добавления ещё одного компонента: в сравнении его показатели близки к специализированным решениям, а единый контур данных может упростить архитектуру. Pinecone Serverless и Weaviate стоит оценивать вместе с преимуществами выбранной модели эксплуатации, а не только по p95.

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

Надёжное сравнение начинается с одинакового набора запросов, сопоставимой полноты выдачи и замера хвостов задержки. Опубликованные цифры помогают выбрать кандидатов для такой проверки, но без полной методики не дают основания объявить одну базу победителем. Для продукта важнее найти хранилище, которое при нужном качестве retrieval обеспечивает приемлемый отклик и остаётся управляемым в собственной инфраструктуре.