«Уменьшение размерности не всегда снижает качество»: AWS сравнила три хранилища векторов для Bedrock Knowledge Bases

Три бэкенда с разной физикой

Amazon Bedrock Knowledge Bases даёт два пути: полностью управляемый вариант и вариант, где хранилище векторов выбирает сам клиент. Публикация разбирает именно второй путь и сравнивает три поддерживаемых бэкенда: Amazon OpenSearch Service, Amazon Aurora PostgreSQL с pgvector и Amazon S3 Vectors — возможность Amazon S3.

Amazon OpenSearch Service отдаёт быстрые результаты по данным в памяти, поддерживает многомерные эмбеддинги в вариантах управляемого кластера и serverless, умеет k-NN-поиск и гибридный поиск, совмещающий лексический подход с векторным; Bedrock Knowledge Bases работает и с управляемыми кластерами OpenSearch, и с serverless-коллекциями. Aurora PostgreSQL с pgvector соединяет производительность реляционной базы с векторным поиском по сходству, поддерживает несколько методов индексации (IVFFlat и HNSW), разные метрики расстояния (L2, косинус, скалярное произведение) и векторы размерностью до 2000 измерений в одинарной точности.

Amazon S3 Vectors — объектное хранилище AWS с нативной поддержкой векторов, рассчитанное на экономичное хранение и запросы эмбеддингов в масштабе: субсекундная производительность на поиске по сходству при снижении стоимости хранения векторов до 90 % по сравнению с традиционными векторными базами.

Базовая механика RAG описана отдельно: поиск по векторам находит результаты, близкие по смыслу к вопросу, и это лучше ловит семантическое сходство, чем совпадение ключевых слов. При запросе система обычно достаёт top n ближайших чанков (например, пять самых похожих) и передаёт их модели как дополнительный контекст, чтобы ответ был точнее.

Сценарий 1: каталог товаров — OpenSearch и цена сжатия

Для поиска по каталогу товаров AWS называет лучшим вариантом Amazon OpenSearch Serverless: он умеет совмещать семантическое понимание с традиционным совпадением по ключевым словам через гибридный поиск. На больших каталогах он держит задержку векторного поиска в диапазоне низких миллисекунд, а встроенные сложные фильтры и агрегации питают фасетную навигацию — фильтры по цене, бренду или цвету; метрику сходства тоже можно выбирать, например косинус или евклидово расстояние.

Важная оговорка: бенчмарки сняты на серверлесс-коллекциях Classic, тогда как коллекции NextGen (общая доступность в мае 2026 года) пока несовместимы с Retrieve API в Amazon Bedrock Knowledge Bases. Управляемые кластеры, в свою очередь, дают дополнительные возможности тюнинга — автооптимизацию, индексацию с ускорением на GPU и настраиваемый размер инстансов — и могут дать другие результаты.

Бенчмарк построен на датасете Shopping Queries Data Set (ESCI): 1 215 851 уникальный товар с медианной длиной описания около 1140 символов и 97 345 размеченных запросов с градациями Exact (3), Substitute (2), Complement (1) и Irrelevant (0). Из них выбраны 5 000 запросов — примерно 19 размеченных товаров на запрос, из которых около 17 релевантных, — а индексируются все 1,2 млн описаний товаров. Качество измерялось через NDCG@10, задержка — по p50/p95/p99 при конкурентности 1 и 10, размер — по памяти, которую занимает ANN-индекс.

Проверялись все комбинации размерности эмбеддингов (1024, 512, 256) и типа данных (float, binary) — шесть конфигураций плюс 1024-float в режиме on_disk со штатным сжатием 32x, — все на FAISS с HNSW при ef_construction=128 и m=24, с расстоянием l2 для float и hamming для binary. Ключевой вывод звучит контринтуитивно: уменьшение размерности не всегда снижает качество — на этом датасете 512-мерные float-эмбеддинги оказались статистически неотличимы от базовых 1024-мерных (NDCG 0.3628 против 0.3627, p = 0.87) при вдвое меньшем индексе (2.79 против 5.34 GiB) и меньшей задержке (25 против 31 мс по p50). Снижение до 256 измерений дало измеримую потерю 4,4 % качества, а где проходит граница между «сжатием без потерь» и «сжатием с потерями», зависит от модели эмбеддингов и датасета.

Бинаризация экономит объём, но платить приходится качеством, и размер платы зависит от размерности: при 1024 измерениях бинарные эмбеддинги уменьшили индекс в 13,4 раза (0.40 против 5.34 GiB) ценой 5,2 % NDCG при сопоставимой задержке (22 против 31 мс по p50). При 256 измерениях потеря качества выросла до 28,3 %, а дополнительная экономия оказалась куда скромнее — 5,0 раза, то есть штраф за бинаризацию растёт по мере уменьшения размерности.

Дисковый режим on_disk с 32-кратным сжатием сохраняет качество, но забирает задержку: при 1024 измерениях он дал NDCG 0.3610 — минус 0,5 % к базовой конфигурации — при том же размере индекса 0.40 GiB, что и у 1024-binary, но примерно втрое большей задержке (99 против 31 мс по p50). Соотношение по задержке держалось на p50, p95 и p99, а на малых корпусах штраф может не проявиться, потому что индекс помещается в page cache; он возникает на продакшен-масштабе.

Гибридный поиск даёт устойчивый прирост: на этом датасете он улучшил NDCG на 6,0 % относительно чисто семантического поиска и для float (0.3633 → 0.3850), и для binary (0.3451 → 0.3658). Показательнее всего, что 1024-binary с гибридом (0.3658) обошёл 1024-float только с семантикой (0.3633), имея в 13 раз меньше памяти — 0.40 против 5.34 GiB, — то есть гибрид способен отыграть качество, потерянное на бинаризации. Плата — задержка: шаг слияния примерно удваивает последовательную задержку (30 → 38 мс для float и 17 → 35 мс для binary), а под конкурентностью разрыв растёт. При этом выборка товаров благоволит ключевому поиску: один BM25 достиг NDCG 0.314 — всего на 13 % хуже семантики, — а вес слияния 0.7 на 0.3 задан для демонстрации и не подбирался.

Сценарий 2: глубокое исследование — S3 Vectors

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

Для этого сценария AWS использует подмножество английской Википедии более чем из 6 млн статей и строит индексы нескольких масштабов — от 5 000 до 1 000 000 векторов, нарезая статьи на сегменты примерно по 300 токенов и получая 1024-мерные float32-эмбеддинги моделью Amazon Titan Text Embedding v2 с косинусным расстоянием. Замер проводился на 100 исследовательских вопросах, каждый забирал top 50 ближайших векторов, а время генерации эмбеддингов исключалось, чтобы изолировать производительность S3 Vectors.

Результаты показывают сублинейное масштабирование: рост с 5 тыс. до 1 млн векторов, то есть в 200 раз, поднял p50-задержку лишь примерно в 3,5 раза — с 82 до 294 мс. Хвост задержки тоже ведёт себя предсказуемо: разрыв между p50 и p95 расширяется примерно со 100 мс на 5 тыс. векторов до примерно 210 мс на 250 тыс., а затем сужается и держится на уровне примерно 100–120 мс на отрезке от 500 тыс. до 1 млн, то есть добавление векторов не увеличивает хвост пропорционально. Даже на 1 млн векторов p99 остаётся ниже 510 мс — для агента, который секундами рассуждает над извлечённым контекстом, это приемлемая плата.

Дополнительно S3 Vectors поддерживает десятки миллионов векторов на индекс и тысячи индексов на бакет, оптимизирован под пакетную загрузку и извлечение, интегрируется с Bedrock Knowledge Bases и OpenSearch, а платить нужно по факту потребления — что подходит исследовательским нагрузкам с переменным профилем.

Сценарий 3: клиентский чатбот — Aurora и pgvector

Для клиентских RAG-чатботов с большими базами знаний Aurora PostgreSQL с pgvector балансирует между ёмкостью и производительностью S3 и OpenSearch и даёт возможность менять метод индексации под конкретный датасет. Тестовое окружение — 500 000 чанков в векторной базе, 5 000 случайных запросов с 1024-мерными эмбеддингами, Amazon Aurora v15.15, запросы через интерфейс RDS API, причём инстансы работали минимум 15 минут, чтобы исключить задержку старта.

Сравнивались два типа индексов на одинаковых 1024-мерных эмбеддингах с расширением pgvector: HNSW показал 31,91 мс по p50, 38,20 мс по p95 и 89,00 мс по p99, а IVFFlat — 35,94, 42,38 и 94,08 мс соответственно. Оба варианта держат медианный ответ ниже 50 мс, а p95 — ниже 60 мс, то есть подходят для ответов в реальном времени, при этом HNSW оказался на 4 мс быстрее.

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

Как выбирать и почему это не сравнение «в лоб»

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

Дальше профиль сопоставляется с базой: при требовании гибридного поиска с задержкой ниже 50 мс стартовать стоит с Amazon OpenSearch Service, потому что он даёт задержку в единицы миллисекунд на HNSW в памяти и нативно совмещает лексический поиск с векторным. Для сбалансированной задержки около 100 мс вместе с реляционными данными — Aurora PostgreSQL с pgvector: он отдаёт запросы быстрее 50 мс, позволяет A/B-тестировать типы индексов и естественно ложится на существующие процессы PostgreSQL. Для экономичного хранения в огромном масштабе или минимума операционных усилий — S3 Vectors, который снижает стоимость хранения векторов до 90 % и масштабируется без управления инфраструктурой.

Выбор не обязан быть окончательным: если начать с S3 Vectors на прототипе или экономичном исследовательском сценарии, позже можно выгрузить векторы в OpenSearch или Aurora без повторного эмбеддинга. Aurora стоит выбирать там, где нужно соединять векторные результаты с реляционными данными одним запросом — это единственный из трёх вариантов с такой возможностью. OpenSearch нужен, если задержка ниже 20 мс или гибридный поиск требуются с первого дня, а полный корпус при этом можно держать в S3 Vectors. Наиболее мощной авторы называют ярусную схему хранения: полный корпус в S3 Vectors, а производительно-критичные подмножества — в OpenSearch Service или Aurora.

Авторы прямо оговаривают границы своих цифр: примеры и показатели взяты из отдельных рабочих нагрузок, подобранных под каждую базу, а не из прямого сравнения на общем датасете, поэтому числа иллюстрируют форму компромиссов, а не результат «яблоко к яблоку». Итог формулируется так: правильное хранилище — то, которое лучше всего подходит под требования конкретной нагрузки по задержке, стоимости и качеству извлечения.