Задача сравнения векторных и реляционных СУБД

При запуске любого проекта с семантическим поиском возникает вопрос хранения векторов — в специализированной векторной СУБД или в расширении к привычной реляционной базе? Цена ошибочного выбора достаточно велика. Технически сложное решение увеличит операционные расходы, усложнит поддержку, но не даст заметного роста качества. Простое решение при росте объема данных быстро достигнет потолка производительности — масштабирование невозможно и в процессе эксплуатации придется менять СУБД, что чревато проблемами миграции и риском потери данных. Список кандидатов среди векторных СУБД постоянно растет, маркетинговые материалы различных вендоров обещают рекордную скорость и точность, однако корректно сравнить решения между собой по подобным источникам почти невозможно — у каждого свой бенчмарк, набор данных и условия. Существующие стандартизованные тесты производительности СУБД, прежде всего TPC-H — набор из 22 аналитических SQL-запросов к реляционной схеме типа «звезда» — измеряют пропускную способность при агрегациях над структурированными данными и неприменимы к задачам векторного поиска. У TPC-H нет ни метрик семантической близости, ни операций приближенного поиска ближайших соседей (Approximate Nearest Neighbors, ANN), ни средств учета специфики преобразования текстовых данных в набор чисел и векторы (эмбеддинг).

Решить проблему тестирования векторных СУБД можно путем практического тестирования на стендах, моделирующих условия конкретной задачи, например одна RAG-система (Retrieval-Augmented Generation, генерация с дополнением через поиск), один корпус документов, один интерфейс доступа к данным — и тестируемые СУБД, по очереди подключаемые к стенду.

Для конкретного сравнения отобраны системы, лидирующие в рейтинге DB-Engines по категории «векторные СУБД» [1] и охватывающие все основные сценарии развертывания: четыре специализированные векторные СУБД с самостоятельным развертыванием — Milvus, Weaviate, Chroma, Qdrant; облачный управляемый сервис — Pinecone; два расширения для PostgreSQL (pgvector и pgvectorscale); встраиваемое расширение для SQLite без отдельной инфраструктуры — sqlite_vec.

Система RAG представляет собой большую языковую модель, формирующую ответ на основе данных, найденных в базе знаний. Поиск релевантных фрагментов выполняет ретривер, а сборку контекста и обращение к модели координирует оркестратор. Главная цель RAG — снизить число галлюцинаций: модель отвечает строго по предоставленным документам. В качестве предметной области выбрана база организационно-правовых документов НИУ ВШЭ — корпус, на котором хорошо видно, чем «настоящие» данные отличаются от удобных учебных примеров.

Нормативные документы vs обычный текст

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

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

Отличается и этап формирования ответа. Система должна корректно обрабатывать точные обращения к источникам («согласно п. 1.2», «в соответствии с приказом № …») и, что особенно важно, учитывать актуальность документов: более поздний акт может «перекрывать» ранее утвержденный, а в ответ должен попасть именно актуальный, действующий. Кроме того, поверх векторного поиска необходима отдельная фильтрация по метаданным. Эти требования и стали отправной точкой при проектировании системы.

Подготовка данных для стенда

Подготовка данных включает несколько шагов: выгрузка документов, очистка от форматирования, разбиение на смысловые фрагменты, векторизация и запись в хранилище. Корпус организационно-правовых документов [2] на начало 2026 года насчитывал более двух тысяч документов в форматах PDF, DOCX и DOC. Для корректной работы выгружался не только текст каждого документа, но и его метаданные: вид документа, срок действия, дата принятия и т. д., которые затем используются для фильтрации и оценки актуальности.

Следующий этап — очистка от нежелательного форматирования. Весь извлеченный текст нормализуется по единому правилу: замена неразрывных пробелов и переносов, схлопывание множественных пробелов, приведение кодировки к нормальной форме Unicode NFC. Единообразие здесь критично — все тестируемые СУБД должны получить идентичный набор данных.

Далее — разбиение на смысловые фрагменты (чанкинг). Обычно выделяют несколько способов [3]: нарезка фиксированного размера; нарезка с перекрытием — каждый фрагмент захватывает часть соседнего; семантическое сегментирование — фрагмент содержит одну завершенную мысль; структурное разбиение по главам, разделам, спискам. Для нормативных документов применим гибридный способ.

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

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

Наконец, фрагменты векторизуются. Чтобы во все СУБД попадал идентичный набор данных, а расходы на API при переиндексации не росли, результаты векторизации кэшируются на диске; после первого запуска создается файл с параметрами разбиения и итоговым числом фрагментов. Так обеспечивается воспроизводимость: каждая база индексирует одни и те же векторы.

Архитектура стенда

Ключевая задача — сравнить СУБД при работе в одинаковых условиях. Если каждый компонент системы обращается к каждой базе напрямую через ее собственный API, возникает восемь параллельных конвейеров: изменение любого параметра приходится синхронизировать в восьми местах и тогда сравнение становится ненадежным. Решение — паттерн «адаптер»: единый абстрактный класс задает правила взаимодействия и общий интерфейс, за которым скрыты различия конкретных реализаций. Это позволяет ретриверу и оркестратору не зависеть от того, с какой именно СУБД ведется работа, а хранилище может переключаться одной строкой конфигурации. Общая архитектура стенда показана на рис. 1.

Рис. 1. Архитектура системы для тестирования СУБД

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

Ретривер ищет наиболее релевантные запросу фрагменты. Для самого сравнения СУБД используется стандартный гибридный поиск: параллельно с векторным выполняем полнотекстовый поиск (BM25), после чего результаты совместно ранжируются. Такой режим позволяет измерять качество работы хранилища, не маскируя его эвристиками. Однако для реальной работы этого недостаточно — необходимо учитывать особенности предметной области, поэтому в штатном режиме на этапах векторизации и поиска добавляются дополнительные шаги (рис. 2).

Рис. 2. Дополнительные шаги ретривера при поиске релевантных фрагментов

• Расширение запроса. LLM генерирует три переформулировки исходного вопроса, поэтому поиск идет по всем вариантам, а результаты объединяются, что увеличивает охват выборки.
• Гипотетический ответ. Модель генерирует краткий предполагаемый ответ, который тоже векторизуется и добавляется к поиску: гипотетический ответ нередко семантически ближе к реальным данным, чем сам вопрос.
• Иерархический поиск. Сначала отбираются топ-k документов, затем поиск сужается до фрагментов внутри них — это повышает точность, когда несколько документов релевантны лишь частично.
• Точное совпадение. Принудительно добавляются фрагменты с точными цитатами в кавычках или номерами документов: пользователь нормативной базы часто ищет конкретный акт по номеру.
• Расширение контекста. К каждому найденному фрагменту добавляются соседние фрагменты того же документа, если их косинусное сходство с запросом выше порога. Так восстанавливается контекст, потерянный на границах смысловых блоков.
• MMR-дедупликация. Если два фрагмента слишком похожи (Maximal Marginal Relevance), оставляется только один — это устраняет избыточность контекста, передаваемого модели.
• LLM-реранкинг. Языковая модель оценивает релевантность фрагментов и отбирает минимально достаточный набор, компенсируя ограниченность алгоритмических метрик.

Если после всех шагов модель признает контекст недостаточным, формируется уточняющий запрос и поиск повторяется (не более трех итераций). Например, на вопрос «Каков размер суточных при командировании?» первый поиск возвращает общее положение о командировках, но не находит конкретных сумм — тогда система переформулирует: «приказ суточные командировочные расходы НИУ ВШЭ размер» и со второй попытки находит нужный акт. Это необходимо для сложных вопросов, ответ на которые собирается из нескольких документов.

Завершает конвейер оркестратор, координирующий обработку запроса: принимает вопрос, вызывает поисковый движок, собирает контекст для модели, обращается к API генерации и возвращает структурированный ответ со ссылками на источники. Для каждого найденного фрагмента оркестратор подставляет в промпт его метаданные — так модель учитывает актуальность и применимость документа.

Отдельное требование — корректное поведение при отсутствии ответа. Если в нормативных документах нет нужной информации, система обязана сообщить об этом, а не генерировать ответ из своих общих знаний. Реализована двойная защита: промпт предписывает вернуть маркер «нет в документах» при отсутствии данных в контексте, а постобработка проверяет наличие этого маркера и флага «found» независимо от того, что сгенерировала модель.

Тестирование

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

Программный метод

Для автоматической оценки использовалась генерация синтетических пар «вопрос — ответ» из документов корпуса с помощью фреймворка RAGAS [4], не требующего заранее размеченного датасета — пары «вопрос — ответ» генерируются из самого корпуса документов. Фреймворк предоставляет ключевые метрики, которые напрямую характеризуют работу ретривера — context precision (доля релевантных фрагментов среди найденных) и context recall (полнота: какая часть нужной информации найдена). При этом абсолютное значение метрики характеризует сочетание «СУБД + конкретный корпус документов» и на другом корпусе будут получены другие значения. Тестовый набор формируется однократно и используется для всех восьми СУБД. Чтобы снизить смещение языковой модели (систематическую погрешность, когда одна и та же модель и генерирует вопросы, и оценивает ответы), для генерации и оценки использовались разные модели — GPT-4o и GPT-4o-mini. Сводные результаты оформлены в таблицу.

Метрика context recall показала малое среднеквадратичное отклонение от среднего: у семи СУБД из восьми оно не превышает 0,02, что говорит о воспроизводимости экспериментов и детерминированности индекса HNSW (Hierarchical Navigable Small World — алгоритм приблизительного поиска ближайших соседей, основанный на графовой структуре данных). Единственное исключение — pgvectorscale (отклонение > 0,02). В отличие от pgvector, который использует HNSW-индекс, pgvectorscale применяет StreamingDiskANN — алгоритм приближенного поиска на дисковых данных от Timescale на базе DiskANN (Microsoft Research), рассчитанный на датасеты, превышающие объем оперативной памяти. На сравнительно небольшом корпусе в 28 тыс. векторов это проявляется как повышенный разброс метрики, что может свидетельствовать о нестабильности индекса на малых объемах данных. По времени индексации локальные СУБД различаются менее чем на 5%, тогда как у Pinecone разброс достигает около 30% — сказывается сетевая нестабильность при загрузке векторов через API.

По качеству поиска семь систем оказались примерно одинаковы: context precision в диапазоне 0,685–0,704, context recall — 0,812–0,837. Заметно отстает лишь Weaviate, уступая остальным по обеим метрикам; вероятная причина — конфигурация по умолчанию, требующая дополнительной настройки. По скорости поиска лидирует Qdrant (наименьший разброс времени запроса), по скорости индексации — Milvus (примерно в пять раз быстрее Qdrant и Chroma). Pinecone показал лучший context recall (0,837), но с существенной сетевой задержкой (0,737 с на запрос).

Отдельно сопоставлены pgvector и его расширение pgvectorscale: последнее индексирует примерно на 12% быстрее (353 против 400 с), но работает медленнее и менее стабильно. Вывод однозначен — на малых объемах данных StreamingDiskANN не дает преимущества перед стандартным HNSW.

Пользовательские сценарии

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

1. Можно ли пересдать тест, если получил высокую оценку?
2. Что нужно сделать, если заболел перед экзаменом?
3. Соответствуют ли положения о майнорах общему положению об оценках
4. Можно ли перейти на бюджет при переводе в НИУ ВШЭ?
5. Какие документы нужны для перевода из другого университета?
6. Могут ли перезачесть предметы из другого университета?
7. Как восстановиться на бюджет после перевода на платное?

Ответ на каждый вопрос оценивался по 10-балльной шкале (максимум — 70 баллов). С переформулировкой результат составил от 43 до 46 баллов, а итоговая точность ответов — 0,61–0,66, что хорошо коррелирует с метрикой context precision из программного теста. Это главный методический результат: автоматическая оценка и живой пользовательский опыт согласуются.

Переформулировка вопроса заметно помогает — с ней система давала ответ на все семь вопросов против двух–трех без нее. Аномалию показал лишь вопрос № 2, где (без учета вклада Weaviate) поиск с переформулировкой сработал хуже, чем без нее. Для Weaviate переформулировка оказалась практически обязательной — эта СУБД находила ответ без переформулировки только в одном случае из шести, поэтому при проектировании системы на ее основе необходимо изначально закладывать расширение запроса.

Показателен и вопрос № 3: все рассматриваемые СУБД дали неудовлетворительный результат независимо от формулировки — релевантные документы нашли только Weaviate, pgvectorscale и sqlite_vec, но ответ так и не был сформирован. В целом при переформулировке разницы в качестве между реляционными и векторными решениями практически нет — реляционные СУБД держатся на одном уровне с векторными. Без переформулировки реляционные базы чаще находят ответ (3 против 1–2), причем эта разница особенно заметна на вопросе № 7. Подробные оценки по вопросам сведены в таблицу.

Результаты

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

Qdrant показал лучшую скорость поиска при тестировании через RAGAS, однако обладает нестабильным API: при обновлении библиотек версии клиента (локальный запуск) могут разойтись с версией сервера, что при внедрении создает дополнительные проблемы с совместимостью.

СУБД Milvus демонстрирует одни из лучших показателей по скорости индексации и полноте, но требует дополнительных инфраструктурных компонентов (MinIO, ETCD) и тонкой настройки параметров, что может быть неудобно для промышленной инфраструктуры.

СУБД Pinecone как облачное решение оправдана там, где важна точность, а не скорость (необходимо закладывать сетевую задержку), либо при жестких ограничениях на собственные серверные ресурсы.

СУБД Chroma — золотая середина для быстрого запуска: лучшие показатели precision на RAGAS, третье место по времени индексации в обмен на минимальную конфигурацию и легкое развертывание. Подходит для локальной разработки, быстрой проверки гипотез, но плохо масштабируется и не рекомендуется для коммерческой эксплуатации.

СУБД Weaviate сильна по скорости (второе место и по индексации, и по времени запроса), но уступает по точности поиска и релевантности — что, по-видимому, связано с использованием в тестах конфигурации по умолчанию. При оптимизации параметров результаты должны вырасти.

Реляционные СУБД (pgvector, pgvectorscale, sqlite_vec) на данном корпусе показали себя достойно, однако для баз большего объема предпочтительнее специализированные решения: они выигрывают в скорости индексации и лучше подходят для систем с частым обновлением данных. При этом на корпусе в 28 тыс. фрагментов разницы между pgvector и pgvectorscale практически нет — индекс StreamingDiskANN на малых датасетах не дает выигрыша.

Сводные рекомендации по областям применимости приведены в таблице, а на рис. 3 представлен наглядный алгоритм выбора.

Рис. 3. Граф выбора СУБД

Итоги и перспективы

На корпусе среднего размера выбор конкретной векторной или реляционной СУБД влияет на качество поиска меньше, чем обычно принято считать, — и это само по себе значимый результат, который невозможно получить из маркетинговых бенчмарков вендоров. Семь из восьми систем показали близкие метрики — куда важнее оказались инженерные факторы: простота развертывания, стабильность API и требования к инфраструктуре. Реляционные базы с векторными расширениями на небольших объемах данных оказались полноценной альтернативой специализированным решениям. Это частично снимает проблему выбора платформы для тех команд, где уже развернуты реляционные СУБД.

Предложенная методика сравнения: единый стенд, один корпус документов, единый интерфейс доступа к данным позволят выполнить корректное сравнение СУБД. Методика воспроизводима и переносима — любая команда может применить ее к конкретной прикладной области: медицинская документация, юридические договоры, техническая документация и пр. для получения объективной картины, не полагаясь на данные из внешних источников.

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

***

Рейтинг «лучшей векторной базы», безусловно, может отличаться в других контекстах сравнения — именно поэтому имеет ценность воспроизводимая методика. Разбор типичных трудностей при работе с нормативными документами и равные условия для всех участников теста применимы к любой аналогичной задаче. На основе решений, прошедших проверку на стенде, сегодня работает сервис семантического поиска по нормативным документам (hse–docs.ru). Но сложная вложенность документов не решается простым обходом всех фрагментов в глубину — необходима отдельная древовидная структура, корректно отражающая ссылки между документами. Кроме того, модель эмбеддингов (text–embedding–3–small) обучена преимущественно на английском тексте, что могло занижать context precision. У точности на данном корпусе имеется очевидная перспектива роста — за счет перехода на модели, лучше работающие с русскоязычной юридической лексикой.

Литература

1. DB-Engines. Ranking of Vector DBMS [Электронный ресурс]. — 2026. — URL: https://db-engines.com/en/ranking/vector+dbms (дата обращения: 30.06.2026).

2. Национальный исследовательский университет «Высшая школа экономики». Организационно-правовые документы и локальные акты [Электронный ресурс]. — [Б. г.]. — URL: https://www.hse.ru/docs/index.html (дата обращения: 16.03.2026).

3. Душкин Р. В. RAG-системы: от теории к практике. — М.: ДМК Пресс, 2025. — 286 с.

4. Es S., James J., Espinosa Anke L., Schockaert S. RAGAs: Automated Evaluation of Retrieval Augmented Generation [Электронный ресурс] // Proceedings of the 18th Conference of the European Chapter of the Association for Computational Linguistics: System Demonstrations. — St. Julians, Malta, 2024. — P. 150–158. — URL: https://aclanthology.org/2024.eacl-demo.16/ (дата обращения: 28.04.2026).

Анастасия Милованова (nastya.milowanowa2016@yandex.ru) — студентка, МИЭМ НИУ ВШЭ; Егор Денисов (edenisov@hse.ru) — преподаватель, ФСН НИУ ВШЭ (Москва).

DOI: 10.51793/OS.2026.63.60.003