Векторные базы в агентной архитектуре и как изменятся вопросы на собеседованиях в 2026 году Дьячков Георгий Сергеевич бэкэнд-разработчик, Альфа-Банк, к.э.н. 

1. Какую базу данных выбрать? 2. Как оптимизировать запись/чтение 3. Как масштабировать? 4. Как оценить ресурсы? Системный дизайн 2 

microservice1 microservice2 microservice3 database 1 2 3 4 5 6 Как было раньше? 3 

microservice1(agent) microservice2 (rag) microservice3(tool) database ? ? n (random) Эпоха агентов 4 

Векторизация справочников, корпоративных документов, AI-техподдержка Разработка больших поисковых систем на основе семантического сходства— векторизация Confluence, поиск, юридические и медицинские документы Векторизация рабочих чатов — транскрибация и векторизация созвонов для последующего поиска Модерация пользовательского контента (UGC) в социальных сетях или играх Персонализированные рекомендации в E-commerce или стриминге Какие бывают задачи? 5 

Client Embedder Vector DB Reranker Final LLM LLM Последовательность этапов RAG 6 

Вектор весит много — 6 килобайт Векторные индексы весят еще больше Векторные базы данных это не источник точной информации, ACID не нужен Нужна масштабируемость Всегда балансируем между точностью и скоростью Базовые условия 7 

Что есть на рынке? 8 

Использование Langchain 9 

База данных Поддерживаемые индексы Pgvector FLAT (полный перебор), IVF, HNSW Redis FLAT (полный перебор), HNSW OpenSearch FLAT (полный перебор), IVF, HNSW (через nmslib и faiss) Qdrant FLAT (полный перебор), HNSW Milvus FLAT, IVF_FLAT, IVF_SQ8, IVF_PQ, IVF_RABITQ, HNSW, HNSW_SQ, HNSW_PQ, HNSW_PRQ, DISKANN, SCANN, AISAQ, GPU_CAGRA, GPU_IVF_FLAT, GPU_IVF_PQ, GPU_BRUTE_FORCE Индексы 10 

O(log^2 n) O(log^k n) search insert HNSW 11 

HNSW индекс создан с параметрами m=16, ef_construction=64 Время создания 570.1918048858643 {'total_mb': 6783.90625, 'table_mb': 229.78125, 'indexes_mb': 3916.9921875, 'toast_mb': 2637.1328125} HNSW CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS PIDS 7dd8127d7180 postgres- pgvector 302.21% 1.213GiB / 8.722GiB 13.90% 63.5kB / 25.9kB 4.52GB / 13.9GB 13 12 1 млн. записей 

Вектор запроса Кластер 1 Кластер 2 Кластер 3 Ранжирование кластеров в порядке близости на основе их центроидов Nprobe = 2 Search - O(k + (n × nprobe / nlist)) Insert - O(k + d) IVF 13 

IVF индекс создан с параметром lists=100 Время создания 57.20296812057495 {'total_mb': 6784.6875, 'table_mb': 229.78125, 'indexes_mb': 3917.7734375, 'toast_mb': 2637.1328125} IVF CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS 7dd8127d7180 postgres- pgvector 99.28% 1.321GiB / 8.722GiB 15.14% 56.1kB / 17.9kB 4.17GB / 13GB 6 14 1 млн. записей 

reader->read(frontier_read_reqs, ctx) std::vector frontier_read_reqs; // собираем все запросы луча frontier_read_reqs.reserve(2 * beam_width); // ... заполняем reader->read(frontier_read_reqs, ctx); // отправляем одним пакетом 2. Параллелизм I/O (Concurrency) В плоском графе Vamana все соседи узла хранятся компактно, часто в одном секторе (4 КБ) 1. Предсказуемость доступа (Locality) VAMANA + PQ Milvus DiskANN 15 

Скалярная (SQ — Scalar Quantization): Как работает: Уменьшает точность чисел. Превращает 32-битные float в 8-битные (или даже 1-битные) целые числа. Результат: Вектор становится в 4 раза меньше, поиск ускоряется, но падает точность ранжирования. Векторная (VQ — Vector Quantization): Как работает: Делит вектор на части и заменяет каждую часть ссылкой на ближайший "типовой" шаблон (центроид) из заранее составленного словаря-книги кодов (кодовая книга). Результат: Огромное сжатие (до 100 раз), позволяющее строить индексы типа IVF (Inverted File Index) и искать только в похожих кластерах, а не во всей базе. Квантизация 16 

pgvector opensearch qdrant prefilter postfilter prefilter ANN search Qdrant filter Проблема фильтров 17 

Shard 1 Merge shards Shard 3 Shard 2 query Qdrant архитектура масштабируемости 18 

1.Поддержка мультитенантности 2.Умный фильтр 3.Оптимизатор коллекций 4.Настройка memmap 5.Индексация только по hnsw 6.Поддержка гибридного поиска 7.Поддержка product quantization Qdrant другие особенности 19 

Лучше меньше чанков и больше текста внутри чанка — быстрее чтение и меньше памяти на диске Использовать фильтры Настроить оптимально параметры efSearch и efConstruction Настроить optimization threshold Настроить memmap Применить продуктовую квантизацию Как можем оптимизировать на примере Qdrant? 20 

Graph + vector db Архитектура: Две отдельные БД. Векторный индекс (Qdrant) для быстрого поиска кандидатов, граф (Neo4j) для обогащения контекста. Чтение (Запрос): O(log n) + O(k). Быстро: нашли векторы (log n), вытащили связанные данные по индексам за константу (k). Вставка (Ingest): Высокая. Самое дорогое здесь это LLM распарсить связи (медленно и дорого), потом записать сам граф. Потом нужно писать атомарно в оба стора. Транзакции 2-phase commit или компенсационные транзакции (snapshot-based rollback). В лучшем случае O(log n) + O(k) Graph + vector db 21 

Гибридные многоуровневые индексы Динамическая регулировка степени параллелизма в зависимости от сложности запроса VeloANN RaBitQ Vast database — иерархическая структура вместо шардинга Ключевые направления исследований оптимизаций векторных баз данных в 2026 году 22 

Shared storage VeloANN Worker 1 Worker 2 Worker n Vast Database Глобальное индексирование (Universal Index): У них нет понятия "шарда" или "партиции" в классическом понимании. Есть единый глобальный индекс, который охватывает все данные. Рекурсивный поиск (Recursive Search): Как только приходит запрос, они используют механизм рекурсивного поиска по кластерам. Но вместо жесткого дерева (как в примере выше) они строят более гибкий граф или дерево, которое хранится распределенно. Data-Placement (Размещение данных): Физически данные (векторы и центроиды) лежат на разных SSD-дисках в кластере. Но благодаря иерархии, система точно знает, на каком именно диске лежит кластер. Zero-Copy Aggregation: Поскольку мы сразу идем в правильный "лист", нам не нужно собирать данные с 10 шардов. Агрегация результатов происходит на лету и требует минимум ресурсов. query 23 

Для каждого вектора мы храним: ID центроида, к которому он принадлежит (например, 0, 1 или 2) Битовый код сдвига (например, 11, 01, 10) Корректирующие факторы: Реальная длина сдвига (до нормировки) — у нас все длины = 1, но в реальности они разные Скалярное произведение между исходным сдвигом и его квантованной версией Шаг 1 найти ближайшие центроиды Центроид C1 [5,5]: расстояние 0.36 Центроид C2 [-5,5]: расстояние 9.8 Центроид C3 [0,-5]: расстояние 11.4 Шаг 2: Преобразовать Q относительно C1 и получить код Q=01 Вектор Код сдвига Корректир ующие факторы A1 11 длина=1.0 , dot=0.95 A2 01 длина=1.0 , dot=0.97 A3 10 длина=1.0 , dot=0.94 A4 11 длина=1.0 , dot=0.96 Шаг 3: Быстрое сравнение кодов через XOR Результаты сравнения: A2(01) vs Q(01): XOR = 00 → разница 0 бит A1(11) vs Q(01): XOR = 10 → разница 1 бит A4(11) vs Q(01): XOR = 10 → разница 1 бит A3(10) vs Q(01): XOR = 11 → разница 2 бита Шаг 4: Применить корректирующие факторы Оценки расстояний с поправкой: A2: ~0.15 A1: ~1.6 A4: ~1.6 A3: ~2.1 Шаг 5: Уточнить топ-k Достать полный вектор по id из памяти и сделать полное сравнение для оставшихся топ k A2: точное расстояние = 0.67 RaBitQ 24 

База данных Чтение (сек) Запись (сек) Qdrant (до оптимизации) 0.0243 0.0009 Qdrant (после оптимизации) 0.0047 0.0009 Pgvector (HNSW) 0.004 0.0032 Pgvector (IVF) 0.009 0.0017 20к записей Какую базу данных выбрать? 25 

Нагрузочное тестирование 26 1 млн. записей 

При расчете ресурсов важно смотреть на память, индекс 200 мб векторов может занимать 4 гб Рассмотрели основные трейд-оффы между скоростью и точностью: квантизация, параметры efSearch, efConstruction, nprobe Рассмотрели основные нюансы нагрузки на чтение и на запись разных индексов Рассмотрели разные подходы к архитектурам масштабируемости векторных баз данных Выводы 27 

1. https://github.com/pgvector/pgvector/blob/master/src/hnswscan.c 2. https://github.com/zilliztech/knowhere/blob/main/thirdparty/DiskANN/src/pq_flash_index.cpp#L1087 3. https://www.researchgate.net/publication/389248375_Strategies_for_Improving_Vector_Database_Performance _through_Algorithm_Optimization 4. https://arxiv.org/pdf/1603.09320 5. https://qdrant.tech 6. https://milvus.io 7. https://www.kaggle.com/code/anotherbadcode/skip-list-meets-graph-understanding-hnsw-indexing 8. https://medium.com/engineering-playbook/vector-database-seemed-essential-postgresql-pgvector-was-enough- c164b0f20c6e 9. https://www.cybertec-postgresql.com/en/indexing-vectors-in-postgresql/ 10. https://lancedb.com/blog/feature-rabitq-quantization/ 11. https://arxiv.org/html/2602.22805v1 Полезные ссылки 28 

Спасибо за внимание! Контакты: @George14adv [email protected] 29