Почему технология Production RAG выходит за рамки специализированных векторных баз данных

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

• Плотный поиск для выявления семантической схожести
• Редкий поиск для нахождения точных терминов
• BM25 для оценки лексической близости
• Гибридный поиск, увеличивающий количество найденных результатов
• Переупорядочивание результатов для повышения точности
• Переписывание запросов для сложных или неоднозначных вопросов
• Самопроверку и верификацию найденных результатов
• Поиск на основе графов для работы с взаимосвязанными знаниями
• Рабочие процессы с использованием агентов, выполняющих получение информации в несколько этапов

В данной статье рассматривается причина, по которой классический подход с использованием векторных баз данных для технологии Retrieval-Augmented Generation начинает оказываться недостаточным во многих реальных сценариях применения.

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

Уже довольно долгое время стандартная архитектура для Retrieval-Augmented Generation кажется практически обязательной:

LLM → Модель эмбеддингов → Векторная база данных → Полученный контекст → LLM

Если вы разрабатывали серьезный продукт на основе RAG, ожидалось, что вы выберете специализированный хранилище векторов — Pinecone, Weaviate, Qdrant, Milvus, Chroma или аналогичные.

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

Теперь речь уже не идет о:

«Какую векторную базу данных мне выбрать?»

Более актуальным стал следующий вопрос:

«Действительно ли мне нужна специализированная векторная база данных?»

Такая смена формулировки имеет огромное значение.

Недавние отчеты с места работы и сравнения по критериям производительности показывают, что все больше команд интегрируют поиск векторов в уже существующую инфраструктуру — PostgreSQL с расширением pgvector, Elasticsearch и различные объединенные платформы данных являются распространенными вариантами.

Это не означает, что векторные базы данных исчезнут за одну ночь.

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

И это давление проявляется именно там, где оно имеет наибольшее значение в инженерии искусственного интеллекта:

стоимость производства, операционные расходы, способность к фильтрации, согласованность данных и общее качество поиска.

1. База данных векторов решила настоящую проблему

Сначала стоит вспомнить, почему базы данных векторов вообще стали популярными.

Традиционные базы данных легко обрабатывают подобные запросы:

SELECT *
FROM documents
WHERE category = 'insurance'
AND effective_date > '2025-01-01';

Но семантический поиск ставит совершенно иной тип вопроса:

"Найти документы, значение которых близко к этому запросу."

Чтобы ответить на него, необходимо преобразовать текст в числовые векторы:

"How do I file a health insurance claim?"
                    ↓
          Embedding Model
                    ↓
[0.021, -0.183, 0.492, ...]

После этого база данных выполняет приблизительный поиск ближайшего соседа.

На концептуальном уровне это выглядит так:

Query Vector
     │
     ▼
 ┌─────────┐
 │ ANN     │
 │ Index   │
 └────┬────┘
      │
      ├── Document A  0.91
      ├── Document B  0.87
      ├── Document C  0.84
      └── Document D  0.81

Когда речь идет о миллионах или миллиардах векторов, специализированные методы индексации, такие как HNSW или IVF, могут значительно ускорить этот процесс по сравнению с прямым поиском всего массива.

Поэтому первоначальная идея казалась совершенно разумной:

Создать базу данных, специально разработанную для эффективного поиска векторов.

Для определенных типов нагрузок эта логика остается актуальной и сегодня.

Проблемы возникли из-за того, что произошло дальше.

2. Промышленные системы RAG включают гораздо больше, чем просто поиск векторов

Ранние прототипы систем RAG обычно следуют простой схеме:

Question
   ↓
Embedding
   ↓
Vector Search
   ↓
Top 5 chunks
   ↓
LLM

Реальные промышленные системы почти никогда не остаются настолько простыми.

В итоге у вас обычно получается нечто более сложное:

                         ┌── Metadata filters
                         │
                         ├── Tenant isolation
                         │
Query → Rewrite → Embed ─┼── Keyword search
                         │
                         ├── Vector search
                         │
                         ├── ACL filtering
                         │
                         ├── Recency
                         │
                         └── Reranking
                                  │
                                  ▼
                              LLM

На этом этапе база данных не может просто ответить:

«Какие векторы находятся ближе всего к этому?»

Необходимо ответить на гораздо более сложный вопрос:

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

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

3. Скрытые затраты на использование двух баз данных

Представьте, что ваша компания уже использует PostgreSQL.

Основные данные приложения хранятся там:

PostgreSQL

users
customers
policies
claims
documents
permissions
metadata

Затем в стек технологий добавляется база данных векторов:

PostgreSQL                  Vector DB
──────────                  ──────────
Documents       ───────►    Embeddings
Users                      Metadata
Permissions                 ANN index
Claims

С этого момента для обновления документа может потребоваться внесение изменений в две отдельные системы.

Типичный процесс обновления выглядит примерно так:

Document Updated
       │
       ├──────────────► PostgreSQL
       │
       └──────────────► Embedding Pipeline
                              │
                              ▼
                         Vector DB

Такая конфигурация создаёт проблемы с синхронизацией.

Рассмотрим, что необходимо сделать в следующих случаях:

• документ удаляется
• изменяются права доступа клиента
• у политики появляется новая версия
• обновляются метаданные
• арендатор удаляется из системы
• сама модель встраивания заменяется

В таком случае вы фактически внедряете проблемы согласованности данных в распределённой системе прямо в слой поиска.

В исследовательской статье 2026 года, посвящённой унифицированным слоям данных для технологии RAG, именно такое разделение — между реляционным и векторным хранилищем — указывается как коренная причина устаревших данных, сбоев в изоляции пользователей и чрезмерной сложности составления запросов. Их конфигурация на основе PostgreSQL и pgvector показала значительное улучшение при выполнении задач фильтрованного поиска в ходе тестирования, а также устранила проблемы синхронизации, возникающие при использовании двух отдельных систем.

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

4. «Достаточно хороший» векторный поиск начинает появляться в уже существующих базах данных

Именно здесь на сцену выходит PostgreSQL.

Благодаря pgvector таблица PostgreSQL может содержать одновременно обычные столбцы и эмбеддинги рядом друг с другом:

CREATE TABLE documents (
    id BIGSERIAL PRIMARY KEY,
    content TEXT,
    metadata JSONB,
    embedding VECTOR(1536)
);

И вы можете выполнять запросы на поиск сходства непосредственно в той же таблице:

SELECT
    id,
    content,
    embedding <=> query_embedding AS distance
FROM documents
WHERE tenant_id = 123
ORDER BY embedding <=> query_embedding
LIMIT 10;

Здесь важно не просто то, что PostgreSQL способен к векторному поиску.

Важно то, что этот векторный поиск выполняется одновременно с остальными данными вашего приложения.

Вы можете объединить всё в один запрос, в одной системе:

SQL filtering
       +
Vector similarity
       +
Transactions
       +
Access control
       +
Metadata

Для команд, управляющих производственными системами, это весьма привлекательное предложение.

Несколько исследований производственных сценариев, опубликованных в 2026 году, уже считают pgvector оптимальным решением для многих случаев использования RAG, когда PostgreSQL уже является частью стека — особенно при умеренном количестве векторов, а не огромном.

5. Фактор затрат имеет большее значение, чем кажется

Затраты, пожалуй, являются главной причиной, по которой команды снова рассматривают эту архитектуру.

Предположим, ваш стек уже включает что-то вроде:

PostgreSQL
$300/month

Добавление поддержки векторов к данной конфигурации может быть таким простым:

Existing PostgreSQL
        +
pgvector
        +
additional CPU/RAM

Сравните это с запуском отдельного управляемого сервиса векторов параллельно с PostgreSQL:

PostgreSQL
     +
Pinecone
     +
network traffic
     +
index management
     +
monitoring
     +
data synchronization

Для каждой нагрузки разница не будет значительной.

Но архитектурные затраты со временем накапливаются.

Ряд исследований затрат на 2026 год показывает реальную разницу в стоимости между управляемыми сервисами векторов и системами поиска векторов на базе PostgreSQL при умеренной нагрузке. Один тест показал, что стоимость одного запроса в Pinecone значительно выше, тогда как для достижения аналогичной производительности pgvector требовалась дополнительная настройка.

Вывод не в том, что:

"pgvector всегда является более дешевым вариантом."

Это утверждение не справедливо во всех случаях.

Настоящий вывод заключается в следующем:

Самая дешевая база данных векторов — это часто та, за которую вы уже платите.

6. Стоимость — не главная причина неудач этой модели

Вот менее приятная реальность.

Если бы единственной проблемой векторных баз данных была цена, решение было бы простым: сократить расходы.

Но команды, использующие эти системы в производстве, сталкиваются с другой, более глубокой проблемой.

Одного только поиска по сходству часто недостаточно для правильного поиска информации.

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

Такой вопрос на самом деле содержит несколько разных критериев поиска одновременно:

Semantic meaning
        +
Exact terms
        +
Customer segment
        +
Geography
        +
Effective date

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

Именно поэтому современные системы RAG все чаще создаются с учетом необходимости сочетания различных подходов к поиску:

BM25
  +
Dense Retrieval
  +
Metadata Filtering
  +
Reranking

вместо полной зависимости от семантического сходства.

Недавнее исследование, посвящённое качеству поиска при изменении размера корпуса — сравнение лексических, плотных, графовых и агентных подходов — показало, что BM25 показал удивительно хорошие результаты, оставаясь на низкозатратной границе Парето во всём диапазоне тестированных размеров корпуса.

Уже один этот результат должен заставить инженеров RAG задуматься.

Многие годы усилий были вложены в совершенствование семантического поиска.

Однако поиск на основе ключевых слов никогда по-настоящему не устарел.

7. Elasticsearch стал подходящим фоновым решением для RAG

Эта тенденция ещё больше ослабляет аргументы в пользу отдельных векторных баз данных.

Поисковые системы уже давно справляются со следующими задачами:

• обратные индексы
• оценка качества с помощью BM25
• фильтрация
• агрегация данных
• поиск с фасетами
• ранжирование релевантности текста

распределенный поиск

Теперь они также обрабатывают векторный поиск.

Поэтому вместо архитектур, построенных на:

PostgreSQL
      +
Vector DB
      +
Search Engine

команды могут сосредоточиться на чем-то вроде:

Search Engine
        ┌───────────────┐
        │ BM25          │
        │ Vector Search │
        │ Filters       │
        │ Ranking       │
        └───────────────┘

В 2026 году был проведен общественный тестирование, в котором pgvector сравнивался с Elasticsearch, Qdrant, Pinecone и Weaviate; в нем оценивалась не только базовая задержка работы алгоритмов типа ANN, но и фильтрованный поиск, гибридный поиск, поведение при записи/обновлении данных и одновременный доступ в реалистичных условиях производства.

Именно такие тесты имеют реальное значение на практике.

Никто не получает срочное уведомление из-за того, что показатели косинусного сходства у него на 12% хуже, чем у конкурентов.

Уведомления поступают из-за того, что:

клиенту показали неверный документ.

8. Именно в области фильтрованного поиска происходит настоящая конкуренция

Это, возможно, самое важное архитектурное замечание в современном дизайне RAG.

Представьте себе набор данных из 100 миллионов векторов.

Конкретному пользователю разрешено видеть только те результаты, которые соответствуют:

tenant = ACME
region = US
department = legal
document_status = active

Примитивная обработка может выполнять что-то вроде:

Vector Search
     ↓
Top 100
     ↓
Metadata Filtering
     ↓
Top 10

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

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

Другими словами, запрос, который вы на самом деле хотите использовать, выглядит скорее так:

Semantic Similarity
        +
Structured Filtering
        +
Authorization
        +
Keyword Matching
        +
Ranking

В сущности, это задача оптимизации запросов к базе данных.

Это не просто задача поиска по векторам.

9. Векторные базы данных сталкиваются со своим собственным давлением в плане создания «единого слоя данных»

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

Архитектура, которая формируется, выглядит примерно так:

                  Unified Data Layer
                           │
       ┌───────────────────┼───────────────────┐
       │                   │                   │
   Relational           Vector              Search
       │                   │                   │
   SQL / joins          ANN/HNSW             BM25
       │                   │                   │
       └───────────────────┼───────────────────┘
                           │
                         Graph
                           │
                     Relationships

И потенциально может расширяться до чего-то вроде:

                    RAG Query
                       │
                       ▼
              Query Planning Layer
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Vector         BM25        SQL
       Search        Search      Filters
          │            │            │
          └────────────┼────────────┘
                       ▼
                    Reranker
                       │
                       ▼
                       LLM

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

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

10. Завершились ли разработки Pinecone, Qdrant и Milvus?

Совсем нет.

Именно в этом аспекте аргументации требуется более тонкое рассмотрение.

Специально созданные векторные базы данных по-прежнему остаются оптимальным выбором в ряде ситуаций.

Когда ваша коллекция векторов огромна. Если вы работаете с объемами данных:

500M+
1B+
10B+ vectors

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

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

Millions of queries
per second

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

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

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

11. Что на самом деле исчезает

Это не сам поиск векторов. Это не эмбеддинги, индексация с использованием нейронных сетей или подход RAG как таковой.

Утрачивает актуальность определенное предположение:

"Каждая производственная система RAG требует собственной специализированной векторной базы данных."

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

PostgreSQL
   │
   ├── Relational Data
   ├── Metadata
   ├── Permissions
   ├── Full-text Search
   └── pgvector
            │
            ▼
           RAG

а не вот так:

PostgreSQL
     │
     ├──── Vector DB
     │
     ├──── Search Engine
     │
     └──── Cache

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

12. Более полезный способ принятия решения

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

Менее 1 миллиона векторов: держитесь простоты. Если PostgreSQL уже является частью вашей стек-технологий, pgvector заслуживает первоочередного рассмотрения. Нет необходимости внедрять ещё одну базу данных только потому, что это советуют в учебниках.

От 1 миллиона до 50 миллионов векторов: именно здесь важны реальные тесты производительности. Сравнивайте такие варианты, как:

pgvector
vs
Qdrant
vs
Weaviate
vs
Pinecone
vs
Elasticsearch

Но необходимо оценить задержку p95/p99, качество фильтрации результатов, производительность гибридных методов поиска, пропускную способность ввода данных, поведение при обновлении и удалении записей, объем используемой памяти, операционные затраты и возможности восстановления после сбоев — а не только чистую скорость работы моделей типа ANN.

От 50 миллионов до более чем 500 миллионов векторов: здесь уже имеет смысл использовать специализированные системы, включая:

Qdrant
Milvus
Pinecone
Weaviate
Elasticsearch
specialized vector infrastructure

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

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

13. Как выглядит стек RAG сегодня

Типичная структура RAG в 2023 году выглядела так:

LLM
 │
Embedding Model
 │
Vector Database
 │
Retriever
 │
LLM

Структура, которая появится в производстве к 2026 году, существенно отличается:

                    User Query
                        │
                        ▼
                  Query Planner
                        │
          ┌─────────────┼─────────────┐
          │             │             │
          ▼             ▼             ▼
       BM25          Vector          SQL
       Search        Search        Filters
          │             │             │
          └─────────────┼─────────────┘
                        ▼
                    Reranker
                        │
                        ▼
                 Context Selection
                        │
                        ▼
                       LLM

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

14. Более общие выводы для инженеров ИИ

Эта схема говорит о структуре инфраструктуры ИИ в целом.

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

LLM → New database
Embeddings → New database
Vector search → New database
Agents → New orchestration layer
RAG → New retrieval layer

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

"Можем ли мы объединить часть из этого?"

Каждый дополнительный сервис, который вы запускаете, добавляет:

More cost
More monitoring
More networking
More credentials
More failure modes
More backups
More synchronization
More operational knowledge

Специализированные инструменты, как правило, побеждают в тестах производительности.

Консолидированные системы, как правило, побеждают в реальных условиях эксплуатации.

Именно по этой причине PostgreSQL сейчас стал настолько привлекательным вариантом в стеке технологий ИИ.

Ему не обязательно быть самым быстрым векторным движком на рынке.

Достаточно лишь того, чтобы он был:

достаточно быстрым, достаточно дешевым, достаточно надежным и хорошо интегрированным.

Для большинства реальных приложений такое сочетание действительно трудно превзойти.

15. Векторные базы данных не исчезают — их переопределяют

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

Ожидайте, что экосистема разделится на три основные категории.

Категория 1 — векторный поиск, встроенный в базу данных

PostgreSQL + pgvector
Elasticsearch
OpenSearch
other unified databases

Этот уровень подходит для команд, которые хотят сократить количество работающих систем.

Уровень 2 — специально разработанные векторные базы данных

Pinecone
Qdrant
Weaviate
Milvus

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

Уровень 3 — специализированные движки поиска

Для нагрузок, которые являются чрезмерно большими или требовательными:

GPU indexes
quantized indexes
distributed ANN
custom retrieval engines
hybrid vector/graph systems

Эта категория не исчезает.

Она разделяется на уровни.

Заключение

Настоящее изменение заключается не просто в том, что PostgreSQL теперь может хранить векторы.

Это в том, что инженеры начинают настраивать весь процесс поиска, а не только отдельные его компоненты.

Промышленная система RAG не обращает внимания на то, указывают ли отчеты ANN:

8 ms
vs
12 ms

какова фактическая стоимость обработки вашего запроса:

40 ms → query processing
30 ms → network
80 ms → reranking
500 ms → LLM

База данных векторов никогда не была конечной целью.

Качество поиска и было главной целью.

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

Поэтому честный вывод таков:

Базы данных векторов не исчезают.

Происходит что-то более интересное.

Поиск векторов превращается в функцию базы данных.

Как только технология переходит из категории самостоятельного продукта в категорию функции, всё в окружающей архитектуре меняется навсегда.