Как выбрать vector database для RAG без религиозных войн

Vector database — это слой хранения и поиска внутри RAG-системы, а не сама система. Он хранит vector representations и metadata, чтобы по query находить вероятные passages из источников. Он не делает documents актуальными, не решает, кому их можно показать, и не доказывает, что найденный текст поддерживает ответ.

Здесь разобран узкий вопрос: как выбрать слой vector storage для ограниченного RAG-workload. Материал дополняет широкий гайд по RAG-системам, где обсуждаются архитектура и scope работы. Решение должно следовать retrieval contract, lifecycle источников и operational ограничениям, а не рекламному тезису или чужому benchmark.

1. Начинайте с workload, а не со списка продуктов

До сравнения вариантов зафиксируйте, что retrieval layer обязан делать. Support assistant по versioned product documentation, multi-tenant внутренняя база знаний, recommendation feature и prototype с несколькими тысячами public pages предъявляют разные требования.

Минимальный workload brief содержит:

1. Corpus и изменение. Сколько passages есть сейчас, как они растут, какие documents заменяются или удаляются и нужно ли искать historical material.
2. Query pattern. Natural-language questions, точные identifiers, filters, multilingual queries, batch jobs или их сочетание. Точный номер заказа чаще требует system-of-record lookup, а не vector search.
3. Scope и permissions. Tenant, role, product, language и lifecycle conditions, которые обязаны сработать до того, как passage попадёт в context модели.
4. Service objective. Требуемая availability, latency budget, recovery expectation, evaluation gate и named owner.
5. Operating boundary. Кто отвечает за backups, updates, access policy, monitoring и incident response после пилота.

Если этих ответов нет, лучше выбрать небольшой обратимый prototype, а не фиксировать сложную платформу. Database не компенсирует неуправляемый corpus, отсутствующие metadata или невозможность проверить retrieval. Upstream gate разобран в статье о качестве источников для RAG, а метаданные и filters объясняют, почему eligibility должна быть определена до answer generation.

2. Сравнивайте по contract VECTOR-6

VECTOR-6 — vendor-neutral matrix. По каждому кандидату ответьте на одинаковые шесть вопросов и сохраните evidence и trade-offs вместо объявления универсального победителя.

Эта matrix отделяет «достаточно быстро в demo» от «подходит этой системе». Managed vector service может уменьшить infrastructure work, но добавить вопросы data location, access или cost. Self-hosted engine даёт больше control, но делает patching, capacity и recovery вашей обязанностью. Vector extension в существующей relational database иногда упрощает consistency и operations, а specialised engine может лучше подойти другому query pattern. Это conditional trade-offs, не рейтинг.

type VectorChoiceEvidence = {
  candidate: string;
  corpus: { passages: number; updatePattern: "batch" | "continuous" };
  requiredFilters: string[];
  querySet: string[];
  recoveryOwner: string;
  decision: "pilot" | "adopt" | "reject";
  unresolvedRisk: string[];
};

3. Сначала сравните архитектурные формы

Relational database с vector support может быть практичной, когда source metadata, application data и transactional updates уже живут рядом, а workload ограничен. Она уменьшает число компонентов, но всё равно требует index, query и maintenance tests.

Dedicated vector engine может подойти retrieval-heavy system, которой нужны purpose-built indexing, similarity operations или конкретное hybrid-search behavior. Новый component всё равно должен получать lifecycle events, permission filters и backups. «Dedicated» не означает, что retrieval policy появится автоматически.

Managed service может упростить provisioning и baseline operations. Но не отменяет проверку data residency, account boundaries, export path, deletion semantics, rate limits, observed cost и incident ownership. Сверяйте эти факты с актуальной documentation и contract кандидата, а не с launch announcement.

Search platform с vector capability разумна, когда lexical search, filtering и существующая operational practice уже важны. Это бывает полезно, если exact terms и semantic phrasing должны работать вместе. Нужность hybrid search подтверждается evaluation: test cases должны показать, что объединение signals улучшает нужное evidence, а не просто меняет ranking.

4. Три сценария, три разумных решения

Сценарий A: controlled first pilot. Corpus небольшой, sources public или строго owned, application ведёт одна команда, а задача — понять, помогает ли retrieval вообще. Выберите самый малый путь, который сохраняет source ID, metadata, versioning и deletion. Решение обратимо: сначала проверьте retrieval на маленьком test set, затем добавляйте scale или platform complexity.

Сценарий B: multi-tenant internal assistant. Главный риск — не только relevance, но и disclosure. Выбранный вариант обязан показать tenant и role filtering, versioned source removal, auditability и recovery owner. Откажитесь от кандидата, если application code просто «помнит» security filter, но нет test, доказывающего scope на каждом retrieval call. Database — лишь часть boundary; identity и policy остаются отдельными dependencies.

Сценарий C: document search product с меняющимся content. Новые documents, revisions, exact terms и natural-language questions сосуществуют. Выберите форму, которая связывает каждый answer candidate с source locator, предсказуемо удаляет superseded content и сравнивает lexical, vector и hybrid retrieval на named questions. Добавляйте reranking, только если evaluation показывает, что дополнительный этап меняет outcome достаточно, чтобы оправдать operating cost.

Один продукт может быть уместен в одном сценарии и лишней liability в другом. Поэтому decision record должен называть workload и exclusions, а не говорить «мы выбрали лучшую vector database».

5. Failure modes, которые скрывает обычное сравнение

Benchmark превращается в обещание. Benchmark зависит от dataset, language, hardware, index parameters, filters и measurement method. Это полезный input, но не прогноз quality или cost другого corpus. Проведите representative test и сохраните его условия.

Filtering включается после сборки context. Если result может попасть в prompt до tenant, role или lifecycle checks, boundary уже нарушена. Собирайте trusted filters из authenticated identity и применяйте их до того, как модель увидит text.

Deletion означает только удаление строки document. Source может остаться в chunks, index replicas, caches или queued jobs. Определите removal event, expected propagation, verification query и recovery route. Проверьте это на superseded или access-revoked document.

Similarity threshold взят из чужой статьи. Универсального безопасного score нет: он зависит от embedding model, language, chunking, query distribution и competing candidates. Проверяйте precision, unsupported-answer routes и failure cases в своей системе.

Operations отложены «на потом». Pilot становится production без backup, alert, access review и owner. Если service достаточно важен, чтобы отвечать сотрудникам или клиентам, recovery и accountability должны иметь named path до расширения.

6. Practical decision gate

Первое решение должно быть evidence-backed pilot, а не permanent declaration. Подготовьте representative sources и questions: normal retrieval, exact identifiers, source updates, denied access, mixed-language inputs при необходимости и вопросы, которые должны завершаться no-answer. Зафиксируйте expected evidence до tuning.

require(workload.owner && workload.failureCost && workload.changePattern);
require(scope.tenantId || workload.isPublic);
require(testSet.normal && testSet.changed && testSet.denied && testSet.noAnswer);
require(recovery.backupOwner && recovery.restorePath);

const adopt = evaluation.meetsAcceptance && operations.haveNamedOwner;
const route = adopt ? "bounded-rollout" : "revise-or-keep-pilot";

Полезный результат — retrieval layer с известными границами: какие sources он ищет, какие filters применяет, как меняется при изменении documents, как reviewer проверяет result и кто восстанавливает систему при сбое. Для architecture review полного пути начните с гайда по RAG-системам или engineering evidence в кейсах.