ByteDance сжали миллиард векторов с 20 серверов до одного и ускорил поиск в 7 раз

Недавно я наткнулся на инженерный блог ByteDance, где они описали, как сократили потребление памяти с 10 терабайт до 500 гигабайт и при этом ускорили поиск в 7 раз.

Звучит как маркетинговый булшит, правда?

Я тоже так подумал. А потом разобрался в деталях и даже пообщался с одним из основных контибьюторов Apache Doris - Kang Xiao.

Последние 20 лет мы строили аналитику для людей. Человек открывает дашборд, смотрит на графики, думает, принимает решение. Если отчёт грузится 5 секунд? Ну, можно кофе налить.

Теперь представьте другую картину: тысячи AI-агентов одновременно долбят базу данных запросами. Каждый агент, ML-модель принимает решение: одобрить транзакцию, показать рекламу, порекомендовать товар. И у каждого есть жёсткий дедлайн: 50, 100, 200 миллисекунд.

А в это время каждый раз, когда вы прикладываете карту к терминалу, где-то на сервере банка просыпается ML-модель. Её работа за доли секунды решить: это вы покупаете кофе, или кто-то в Бразилии клонировал вашу карту.
У неё есть 100 миллисекунд, пока вы держите карту у терминала чтобы проверить вашу историю, сравнить паттерны, оценить риск.
Не секунды. Миллисекунды.
(с) GPT 5 pro за который я плачу $199 в месяц

Это и есть Agent-Facing Analytics аналитика для машин, а не для людей.

<i>Конкурентные запросы, реальное время и данные в разном формате </i>

Когда я впервые увидел эти требования, подумал: "Ну, придётся городить зоопарк".

Elasticsearch для текста, Pinecone, Quadrant, Milvus для векторов, ClickHouse для аналитики. Три системы, три точки отказа, три команды на поддержку. Для команд свыше 20 человек поддержка трех стеков это операционный ад.

Либо можно пойти по пути унификации в одной платформе и снизить когнитивную нагрузку и Time-to-Market, даже если мы теряем 5% функциональности специализированных инструментов, об этом в этой статье.

ByteDance (да, те самые, которые TikTok) столкнулись с задачей: искать похожих кандидатов в базе резюме.

ByteDance сжали миллиард векторов с 20 серверов до одного и ускорил поиск в 7 раз

Миллиард записей, 768-мерные векторы, тысячи запросов в секунду.

Первая попытка: классический векторный поиск с HNSW индексом. И тут начались проблемы.

Запрос: "Senior Python developers with 5+ years, NOT junior positions"

Что вернул векторный поиск:

❌ Кандидаты с 2 годами опыта (embeddings плохо различают числовые значения)

❌ Junior позиции (модели часто игнорируют отрицания вроде "NOT")

Релевантность: 58%

Векторные embeddings отлично ловят "похожее по смыслу", но не предназначены для точной фильтрации. "5 лет опыта" и "2 года опыта" — оба про experience, поэтому семантически близки. А отрицания вроде "NOT junior" модели часто просто игнорируют. Для таких условий нужны структурированные фильтры.
(с) GPT 5 pro за который я плачу $199 в месяц

BM25 scoring (то, что определяет порядок результатов) зависит от статистики сегмента данных. Один и тот же документ получает разные scores в разных сегментах. После compaction (когда база данных "уплотняет" данные) ранжирование меняется.

Пользователь ищет то же самое, получает другой порядок результатов. Доверие к поиску падает.

Давайте посчитаем.

1 миллиард векторов (резюме кандидатов)

Каждый вектор 768 измерений (стандартный размер для современных embedding-моделей).

Каждое измерение — float32 (4 байта).
Простая арифметика: 1,000,000,000 × 768 × 4 байта = 2.9 терабайта.

Только на сами векторы. Но это ещё не всё.

HNSW (Hierarchical Navigable Small World) — это граф, где каждый вектор связан с соседями. Чтобы поиск работал быстро, весь граф должен лежать в оперативной памяти. На миллиарде векторов структура графа занимает ещё ~7TB.

Итого - 10 терабайт оперативной памяти.
Это 20-30 серверов с 512GB RAM каждый. Просто чтобы держать индекс в памяти. Про стоимость такого кластера промолчу

Для оптимизации вычислительных мощностей и ускорения скорости обработки ByteDance перешли на гибридный поиск, который комбинирует три типа фильтрации в одном запросе:

```sql SELECT candidate_name, resume_text, bm25_score(resume_text) as keyword_score, cosine_distance(embedding, query_vec) as vector_score FROM resumes WHERE -- Step 1: Structured filter (B-tree, ~50ms) seniority = 'Senior' AND years_experience >= 5 -- 100M → 2M кандидатов -- Step 2: Keyword filter (inverted index, ~200ms) AND resume_text MATCH_ANY 'Python' -- 2M → 15K кандидатов -- Step 3: Vector similarity (~100ms) AND cosine_distance(embedding, query_vec) < 0.3 -- 15K → 100 кандидатов ORDER BY (keyword_score * 0.3 + vector_score * 0.7) DESC LIMIT 10; ```

1. Latency P95 время отклика для 95% запросов. Если P95 = 400ms, это значит, что 95 из 100 запросов выполняются быстрее 400 миллисекунд. Инженеры смотрят на P95, а не на среднее, потому что среднее скрывает "тяжёлые хвосты" — те 5% запросов, которые могут висеть секундами.

2. Accuracy (nDCG@10) метрика качества ранжирования. Показывает, насколько хорошо система ставит релевантные результаты в топ-10. Значение 0.89 означает, что порядок результатов на 89% совпадает с "идеальным" ранжированием. Выше — лучше, максимум 1.0.

Идея простая: зачем гонять векторный поиск по 100 миллионам записей, если можно сначала отфильтровать по структурированным полям и ключевым словам?

Сначала самая дешевая операция, а потом дорогостоящая. На каждом шаге мы уменьшаем размер выборки.

<i>Progressive Filtering: Воронка данных</i>

Каждый этап отсекает данные, и к векторному поиску приходит уже маленький набор.

Отсюда и скорость — 7x ускорение.

Но подождите. Скорость объяснили, а откуда взялось сжатие памяти с 10TB до 500GB? Это же 20x разница.

Progressive filtering тут ни при чём — он про порядок обработки, а не про хранение.

Ответ — в другом алгоритме индексации.

Помните расчеты из Проблемы №3? HNSW-индекс для миллиарда векторов требовал ~10TB памяти.

ByteDance заменили его на IVPQ и уместились в 500GB. Вот как это работает.

Компромисс скорость/память:

HNSW граф с иерархическими уровнями: верхние слои sparse (быстрая навигация), нижние dense (точный поиск). Высокий recall, но граф целиком в памяти.
IVFPQ двухэтапное сжатие: сначала кластеризация (IVF сужает область поиска), потом квантизация (PQ сжимает векторы). Меньше памяти, но чуть ниже recall.

Технические детали:

Inverted File (IVF) кластеризация:

1 миллиард векторов разбивается на 10,000 кластеров (K-means)
При поиске ищем только в ближайших кластерах
Результат: 1000x сокращение пространства поиска

Product Quantization (PQ) сжатие:

768-мерный вектор (3,072 байта) разбивается на 8 субвекторов
Каждый субвектор заменяется на ID из кодовой книги
Результат: 384x сжатие (3KB → 8 байт)

Trade-off: IVF-PQ даёт 92% recall против 95% у HNSW.

3% потери приемлемая цена за 20x экономию ресурсов. Для рекомендательных систем (резюме, товары) 3% потери recall незаметны. Для mission-critical систем (антифрод) параметры квантизации нужно настраивать мягче, жертвуя сжатием ради точности.

Когда мы говорим, что ByteDance заменили 20 серверов на один, речь идет о вычислительной плотности.

Раньше для хранения HNSW-графа требовалось 10 ТБ распределенной памяти (20+ серверов по 512 ГБ).

После сжатия IVF-PQ индекс занимает всего 500 ГБ.
Это позволяет разместить весь миллиард векторов на одном Fat-Node сервере (например, машине с 768 ГБ RAM). Вместо администрирования целого кластера и борьбы с сетевыми задержками при шардинге, вы платите за одну мощную машину. TCO (Total Cost of Ownership) падает на 95%, а сетевой оверхед исчезает полностью.

Когда аналитикой пользуются люди — 5 секунд задержки норма. Когда аналитикой пользуются агенты — 100 миллисекунд это SLA. Разные требования — разные архитектуры.

Векторные базы данных решают одну задачу хорошо. Но в реальных системах нужны и структурированные фильтры, и полнотекстовый поиск, и векторы. Гибридный подход выигрывает и по скорости (progressive filtering), и по точности (нет semantic confusion).

Зоопарк из Elasticsearch + Pinecone + ClickHouse — это три точки отказа, три команды поддержки, три набора интеграций. Единая платформа сложнее внутри, но проще снаружи.

ByteDance обрабатывает миллиард векторов за 400ms на одном сервере. Это не маркетинг — это production-метрики. (Кейс retail-банка с 650 миллионами клиентов разберу в следующей статье.).
Кстати, а я же не просто так пишу про эти темы, помимо того что хочу, чтобы ChatGPT и ему подобные выдавал нашу компанию Datanomix.pro по целевым запросам и генерировал нам лиды на проекты по развертыванию систем Agent-Facing Analytics и datalakehouse, VeloDB, Apache Doris.

У меня также есть социальная цель - развивать наше локальное сообщество thecdo.kz для руководителей в области данных, AI.

Площадка, где CDO и директора по аналитике, платформам данных обмениваются опытом: оффлайн-встречи в Казахстане, Узбекистане, разборы кейсов управления, монетизации данных, подходы к управлению командами и кейсы внедрения платформ данных.

Например, у нас с докладом выступал co-founder VeloDB / Apache Doris, который как раз таки делился кейсом из этой статьи. Если вы в этой роли и хотите "сверить часы" заходите на сайт сообщества и оставляйте заявку

#ai #datalakehouse #agents #analytics

Источник: