Вы заливаете полмиллиарда документов в модную векторную базу, прикручиваете эмбеддинги от OpenAI или BGE, и уходите спать с чувством выполненного долга. Наивная архитектура готова. Утром p99 latency пробивает секунду, кластер сжирает терабайты памяти, а поиск по запросу «красный чехол iphone 15» выдает красные кроссовки. Классика. Почти все делают это неправильно, свято веря в магию плотных векторов. Но реальность бьет по голове. Векторный поиск на масштабе: гибрид с BM25 и потолок одного эмбеддинга — вот точка, где заканчивается хайп и начинается инженерия.
Почему один вектор не вытягивает сложные запросы? Индустрия продала нам иллюзию, что можно сжать пятистраничный юридический контракт или карточку товара со всеми характеристиками в массив из 768 или 1536 чисел с плавающей точкой. Математика против. Пространство высокой размерности ведет себя неинтуитивно. Эмбеддинги коллапсируют в узкий конус (проблема анизотропии), а модель неизбежно усредняет контекст. Слишком много смыслов в одном тексте — и вектор размывается, превращаясь в серое семантическое пятно.
Исследователи из DeepMind четко показали: у одновекторного подхода есть жесткий математический потолок релевантности. Это приговор. Одновекторный поиск блестяще работает на коротких абстрактных вопросах. Но он с треском проваливается, когда клиенту нужен точный мэтчинг длинного артикула, аббревиатуры или многосоставной технической сущности. Семантика найдет вам «похожий по смыслу» насос. Но вам не нужен похожий. Вам нужен тот, у которого диаметр фланца 150 мм.
ANN-индексы под нагрузкой: векторный поиск на масштабе ломается здесь
Как только мы уходим от десятков тысяч векторов к миллиардам, точный k-NN (brute-force) отпадает. Начинаются игры в ANN (Approximate Nearest Neighbors). И тут рынок предлагает прагматичный выбор из двух зол: HNSW или IVF. У каждого свой способ убить ваш продакшен.
HNSW (Hierarchical Navigable Small World) дает великолепную скорость и recall. Графовый подход идеален для поиска. Но платить придется оперативной памятью. Считаем: на один миллиард векторов размерности 768 вам понадобятся сотни гигабайт RAM только под структуру графа с указателями, не считая самих данных. Узел упал? Восстановление индекса займет мучительные часы. Когда мы в MoranaLabs катили RAG-систему для закрытого контура финтеха с потоком в три миллиона обновлений документов в сутки, попытка держать все в HNSW привела к тому, что сборка графа на лету начала съедать ресурсы инференса. Потребовалась композитная схема: буферные сегменты в памяти и фоновая мердж-компрессия на диск.
Вторая опция — IVF (Inverted File Index) и его вариации с квантованием (PQ). Они жрут кратно меньше памяти. Индекс бьет пространство на кластеры (ячейки Вороного) и при поиске смотрит только в ближайшие центроиды. Звучит отлично, пока ваши данные статичны. Данные динамические? Если распределение векторов изменилось из-за притока новых документов, старые центроиды перестают отражать реальность. Индекс деградирует. Реиндексация и переобучение центроидов — это часы процессорного или GPU-времени. Накладные расходы бьют по latency. Чудес не бывает.
Гибрид с BM25: почему старая школа бьет нейросети
Как починить релевантность и пробить потолок одного вектора? Отказаться от догмы, что трансформеры решают все. Алгоритм BM25 (модифицированный TF-IDF) жив и абсолютно незаменим.
Разреженные векторы (sparse vectors), которые лежат в основе лексического поиска, идеальны для точного попадания по ключевикам. Плотные (dense) векторы ловят семантику. Склеиваем их вместе — получаем гибридный поиск. Это архитектурный стандарт здорового человека.
Звучит элегантно на слайдах. На практике это два независимых пайплайна индексации, двойной расход стораджа и больная проблема нормализации. Как математически сложить скор 0.82 из косинусного расстояния с цифрой 14.5 из алгоритма BM25? Индустрия использует RRF (Reciprocal Rank Fusion). Метод просто берет позиции документа в двух выдачах и суммирует их обратные ранги. Работает? Да. Медленно? В два раза медленнее обычного поиска, потому что вы делаете два параллельных запроса, а потом аллоцируете память под сортировку результатов на координаторе.
Следующий уровень эскалации — мульти-векторный поиск. Подходы вроде ColBERT (Late Interaction). Вместо того чтобы жать весь документ в один вектор, мы храним эмбеддинги для каждого токена. При запросе считаем матрицу попарных расстояний. Точность взлетает в стратосферу. Но затраты на хранение растут в десятки раз, а вычислительная сложность инференса (MaxSim-операции) ставит крест на дешевом железе.
Прагматика диктует следующие правила выживания под нагрузкой:
- До миллиона статических документов: хватит одного плотного вектора и графа HNSW в памяти. Не плодите сущности.
- Десятки миллионов и высокая динамика: переходите на IVF-PQ, настраивайте фоновую переиндексацию, мониторьте recall-деградацию через контрольные выборки.
- Сложные e-commerce и legal запросы: внедряйте гибрид с BM25. Плотные векторы никогда не найдут точный номер судебного постановления среди тысяч похожих.
- Абсолютная релевантность важнее железа: используйте ColBERT или двухэтапный пайплайн с поздним реранкингом кросс-энкодером.
Одновекторный подход для всего подряд — это карго-культ. Инженерия высоких нагрузок начинается там, где вы считаете стоимость каждой миллисекунды задержки, байта в RAM и процента релевантности. Выбирайте архитектуру под профиль нагрузки, а не по заголовкам из бенчмарков.