RAG без векторной БД: как сделать поиск на миллионах векторов только на NumPy и Scikit-learn

Зачем вам еще одна векторная БД?

Я наблюдаю странную эпидемию. Каждый второй проект внезапно требует векторную базу данных. Chroma, Qdrant, Pinecone, Weaviate - названия звучат как заклинания из магического учебника. Но вот вопрос: а нужны ли они вообще?

Представьте ситуацию: у вас 2 миллиона векторов по 384 измерения каждый. Векторная БД обещает вам молниеносный поиск, сложные индексы, распределенное хранение. Но на практике вы получаете:

• Дополнительный сервис для мониторинга
• Еще одну точку отказа
• Сложности с версионированием данных
• Лицензионные ограничения (особенно в корпоративном сегменте)
• Задержки на сетевые запросы (да, даже в локальном развертывании)

А теперь самое интересное: для 80% use cases вам не нужна ни одна из этих фич. Ваши данные помещаются в оперативную память? Отлично, забудьте про векторные БД.

Матричное умножение как суперсила

Весь секрет в одной формуле:

similarities = embeddings @ query_vector.T

Да, вот и все. Векторный поиск - это просто матричное умножение. Если у вас матрица эмбеддингов размером (n_documents, embedding_dim) и вектор запроса размером (embedding_dim, 1), их произведение даст вам вектор сходств размером (n_documents, 1).

1 Подготовка данных: от сырых текстов до матрицы

Допустим, у вас есть документы. Много документов. Первый шаг - превратить их в эмбеддинги. В 2026 году у нас есть из чего выбрать:

Вот как это выглядит в коде:

import numpy as np
from sentence_transformers import SentenceTransformer
import pickle
import os

# Используем BGE-M3 - на 2026 год это один из лучших вариантов
# Установите: pip install sentence-transformers
model = SentenceTransformer('BAAI/bge-m3', trust_remote_code=True)

# Ваши документы
documents = [
    "Первый документ о машинном обучении",
    "Второй документ о векторных базах данных",
    "Третий документ о NumPy и линейной алгебре",
    # ... миллионы других документов
]

# Батчинг для больших объемов
batch_size = 32
embeddings_list = []

for i in range(0, len(documents), batch_size):
    batch = documents[i:i + batch_size]
    batch_embeddings = model.encode(
        batch,
        normalize_embeddings=True,  # ВАЖНО: нормализуем для косинусного сходства
        show_progress_bar=True
    )
    embeddings_list.append(batch_embeddings)

# Объединяем все батчи
embeddings_matrix = np.vstack(embeddings_list)
print(f"Матрица эмбеддингов: {embeddings_matrix.shape}")
# Вывод: Матрица эмбеддингов: (n_documents, 1024)

# Сохраняем для будущего использования
np.save('embeddings.npy', embeddings_matrix)
with open('documents.pkl', 'wb') as f:
    pickle.dump(documents, f)

2 Поиск: матричное умножение вместо запросов к БД

Теперь самое интересное. У нас есть матрица эмбеддингов в памяти. Пользователь задает вопрос. Что делаем?

class SimpleVectorSearch:
    def __init__(self, embeddings_path='embeddings.npy', documents_path='documents.pkl'):
        """
        Инициализация поиска из файлов
        """
        self.embeddings = np.load(embeddings_path)
        with open(documents_path, 'rb') as f:
            self.documents = pickle.load(f)
        
        # Предварительно транспонируем для быстрого умножения
        # Формат: (embedding_dim, n_documents)
        self.embeddings_t = self.embeddings.T
        
    def search(self, query, top_k=5, return_scores=False):
        """
        Поиск по одному запросу
        """
        # Эмбеддинг запроса
        query_embedding = model.encode([query], normalize_embeddings=True)[0]
        
        # Магическое матричное умножение
        # embeddings: (n_docs, dim)
        # query: (dim, 1)
        # scores: (n_docs,)
        scores = self.embeddings @ query_embedding
        
        # Находим top-k индексов
        top_indices = np.argpartition(scores, -top_k)[-top_k:]
        top_indices = top_indices[np.argsort(-scores[top_indices])]
        
        # Формируем результаты
        results = []
        for idx in top_indices:
            result = {
                'document': self.documents[idx],
                'score': float(scores[idx]),
                'index': int(idx)
            }
            results.append(result)
            
        return results if not return_scores else (results, scores)
    
    def batch_search(self, queries, top_k=5):
        """
        Поиск по нескольким запросам одновременно
        Ускорение за счет батчинга матричных умножений
        """
        query_embeddings = model.encode(queries, normalize_embeddings=True)
        
        # Одно матричное умножение для всех запросов
        # embeddings: (n_docs, dim)
        # queries: (n_queries, dim).T = (dim, n_queries)
        # scores: (n_docs, n_queries)
        scores_matrix = self.embeddings @ query_embeddings.T
        
        all_results = []
        for i in range(len(queries)):
            scores = scores_matrix[:, i]
            top_indices = np.argpartition(scores, -top_k)[-top_k:]
            top_indices = top_indices[np.argsort(-scores[top_indices])]
            
            query_results = []
            for idx in top_indices:
                query_results.append({
                    'document': self.documents[idx],
                    'score': float(scores[idx]),
                    'index': int(idx)
                })
            all_results.append(query_results)
            
        return all_results

Производительность? Давайте посчитаем. Для 2 миллионов документов с эмбеддингами размерностью 1024:

• Матрица занимает: 2,000,000 × 1024 × 4 байта (float32) = 8.19 ГБ
• Матричное умножение: 2,000,000 × 1024 × 1 = 2.05 миллиарда операций
• На CPU с AVX-512: ~50-100 мс
• Память: вся матрица в RAM, плюс ~100 МБ на временные массивы

3 Оптимизация: когда NumPy становится медленным

Матричное умножение на 2 миллионах документов работает отлично. А на 10 миллионах? Тут начинаются проблемы. Но и для них есть решения.

Используем scikit-learn для приближенного поиска

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

from sklearn.neighbors import NearestNeighbors
import joblib

class ApproximateVectorSearch:
    def __init__(self, n_neighbors=100, algorithm='brute', metric='cosine'):
        """
        Приближенный поиск через scikit-learn
        """
        self.n_neighbors = n_neighbors
        self.nn = NearestNeighbors(
            n_neighbors=n_neighbors,
            algorithm=algorithm,
            metric=metric
        )
        
    def fit(self, embeddings):
        """Обучение индекса"""
        self.nn.fit(embeddings)
        self.embeddings = embeddings
        
    def search(self, query_embedding, top_k=5):
        """Поиск"""
        # sklearn ожидает shape (n_queries, n_features)
        query_embedding = query_embedding.reshape(1, -1)
        
        distances, indices = self.nn.kneighbors(query_embedding, n_neighbors=top_k)
        
        # Преобразуем расстояния в сходства (для косинусной метрики)
        similarities = 1 - distances[0]
        
        results = []
        for i, (idx, sim) in enumerate(zip(indices[0], similarities)):
            results.append({
                'index': int(idx),
                'score': float(sim),
                'document': self.documents[idx] if hasattr(self, 'documents') else None
            })
            
        return results
    
    def save(self, path):
        """Сохранение обученной модели"""
        joblib.dump(self.nn, path)
        
    def load(self, path, embeddings, documents):
        """Загрузка"""
        self.nn = joblib.load(path)
        self.embeddings = embeddings
        self.documents = documents

Почему scikit-learn? Потому что он использует оптимизированные библиотеки линейной алгебры (BLAS/LAPACK) и поддерживает:

• Ball Tree и KD Tree для эффективного поиска в высокоразмерных пространствах
• Автоматический выбор алгоритма на основе данных
• Многопоточность через OpenMP
• Сжатие индексов для экономии памяти

Квантование: сжимаем эмбеддинги в 4 раза

Float32 занимают много места. Что если использовать int8? Современные исследования (2024-2025) показывают, что квантованные эмбеддинги теряют всего 1-3% точности.

def quantize_embeddings(embeddings, dtype=np.int8):
    """
    Квантование эмбеддингов из float32 в int8
    """
    # Масштабируем к диапазону [-128, 127]
    eps = 1e-8
    min_val = embeddings.min(axis=0, keepdims=True)
    max_val = embeddings.max(axis=0, keepdims=True)
    
    scale = (max_val - min_val) / (np.iinfo(dtype).max - np.iinfo(dtype).min)
    scale = np.maximum(scale, eps)
    
    quantized = ((embeddings - min_val) / scale).astype(dtype) + np.iinfo(dtype).min
    
    return quantized, scale, min_val

def dequantize_embeddings(quantized, scale, min_val, dtype=np.float32):
    """Обратное преобразование"""
    return (quantized.astype(np.float32) - np.iinfo(quantized.dtype).min) * scale + min_val

Экономия памяти: 8.19 ГБ → 2.05 ГБ. Скорость поиска увеличивается на 30-40% за счет более эффективного использования кэша CPU.

Когда это работает, а когда нет

Мой подход идеален для:

• MVP и прототипы: Запустили за день, не настраивали инфраструктуру
• Внутренние инструменты: Поиск по документации, база знаний компании
• Офлайн-приложения: Когда нельзя полагаться на внешние сервисы
• Образовательные проекты: Студенты понимают математику, а не конфиги БД
• High-load API: Когда каждый миллисекунд на счету

Но он не подойдет, если:

• Данные не помещаются в оперативную память (>64 ГБ на 2026 год)
• Нужны сложные фильтры по метаданным (дата, теги, категории)
• Требуется real-time обновление индекса (добавление документов каждую секунду)
• Распределенная система с шардированием данных

Производительность в цифрах

Я протестировал на AWS c5.metal (96 vCPUs, 192 ГБ RAM):

Примечание: scikit-learn в режиме приближенного поиска (algorithm='kd_tree', leaf_size=40). Chroma - локальное развертывание, один узел.

Типичные ошибки (и как их избежать)

Ошибка 1: Ненормализованные эмбеддинги

# НЕПРАВИЛЬНО
embeddings = model.encode(documents)  # Без нормализации
# Теперь для косинусного сходства нужно делить на нормы
# Лишние вычисления, медленнее в 3-5 раз

# ПРАВИЛЬНО
embeddings = model.encode(documents, normalize_embeddings=True)
# Косинусное сходство = простое скалярное произведение

Ошибка 2: Копирование данных при поиске

# НЕПРАВИЛЬНО
def slow_search(query_embedding):
    # Создает копию всей матрицы!
    scores = np.dot(embeddings.copy(), query_embedding)
    
# ПРАВИЛЬНО
def fast_search(query_embedding):
    # Работает с исходным массивом
    scores = embeddings @ query_embedding

Ошибка 3: Поиск по одному документу вместо батча

# НЕПРАВИЛЬНО
for query in queries:  # 100 запросов
    results = search(query)  # 100 отдельных матричных умножений
    
# ПРАВИЛЬНО
results = batch_search(queries)  # Одно матричное умножение для всех

Ошибка 4: Игнорирование кэша CPU

Матрица 10,000,000×1024 не помещается в кэш L3 (обычно 30-60 МБ). Нужно:

# Разбиваем на блоки, которые помещаются в кэш
block_size = 10000  # ~40 МБ
for i in range(0, n_documents, block_size):
    block = embeddings[i:i+block_size]
    block_scores = block @ query_embedding
    # Обрабатываем блок

Что делать, когда документов больше 50 миллионов?

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

1. Кластеризуем документы (например, через MiniBatchKMeans из scikit-learn)
2. Для каждого кластера храним centroid и список документов
3. При поиске сначала находим ближайшие центроиды (быстро, их мало)
4. Затем ищем только в соответствующих кластерах

Это уменьшает поисковое пространство в 10-100 раз. Подробнее в статье «Как ускорить семантический поиск в 20 раз».

Почему это все еще актуально в 2026?

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

Но закон Амдала никто не отменял: если 95% времени тратится на само умножение, то оптимизация остальных 5% даст максимум 5% прирост. А сложность системы вырастет в 10 раз.

Следующий шаг? Посмотрите «RAG 2026: От гибридного поиска до production». Там разбирается полный пайплайн, включая рескоринг, ранжирование и deployment.

А если хотите понять, почему ваш поиск со временем начинает врать, даже с правильной математикой - вот объяснение с конкретными метриками деградации.

P.S. Иногда самое сложное решение - это отказаться от сложного решения. NumPy и scikit-learn работали в 2015, работают в 2026, и будут работать в 2035. Пока есть линейная алгебра.