Почему обычная база данных с этим не справляется
Обычный индекс базы данных (например, B-дерево) построен вокруг упорядочивания сортируемых значений — отлично для «найти все строки, где цена < 100», бесполезно для «найти вектор из 10 000 измерений, ближайший к этому другому вектору из 10 000 измерений» — это вообще не задача сортировки.
Векторные базы данных используют специализированные структуры индекса (HNSW — самая распространённая в продакшене), построенные именно для приближённого поиска ближайших соседей — жертвуя небольшой точностью ради скорости поиска, которая остаётся быстрой даже когда коллекция вырастает до миллионов векторов.
Как это вписывается в пайплайн RAG
Когда пользователь задаёт вопрос, система превращает этот вопрос в вектор той же моделью эмбеддингов, что использовалась для индексации контента, отправляет этот вектор в векторную базу данных и получает обратно сохранённые фрагменты, чьи векторы ближе всего — кандидатов, наиболее вероятно реально релевантных.
Эти извлечённые фрагменты передаются LLM как контекст вместе с исходным вопросом, чтобы модель отвечала, используя реальный, актуальный, конкретный текст, а не то, что она случайно запомнила во время обучения — это и есть retrieval-половина retrieval-augmented generation.
Практические варианты — от простейшего до самого масштабируемого
Для небольшого прототипного проекта лёгкого библиотечного варианта (вроде Chroma или индекса FAISS в памяти) обычно достаточно, и не требует отдельного сервиса.
Для продакшен-масштаба выделенная управляемая или самостоятельно развёрнутая векторная база данных (Pinecone, Weaviate, Qdrant, или Postgres с расширением pgvector, если не хочется добавлять ещё один движок базы данных) справляется с миллионами векторов, фильтрацией по метаданным и горизонтальным масштабированием, для которого простая библиотека не была рассчитана.