Индекс эмбеддингов (Embedding Index)

Индекс эмбеддингов — это внутренняя структура данных, которую векторная база данных или поисковый движок строит над коллекцией эмбеддингов, чтобы поиск ближайших соседей вектора запроса не требовал сравнения его с каждым сохранённым вектором по отдельности. Без индекса поиск по сходству является «полным перебором» (технически называемым плоским или исчерпывающим поиском) — точным, но его стоимость растёт линейно с числом векторов, что становится неработоспособно медленным, когда коллекция достигает миллионов записей. Почему это важно для AI/SaaS-разработчиков: тип индекса и его конфигурация обычно являются самым большим рычагом влияния на задержку, recall (насколько часто действительно возвращаются истинно лучшие совпадения) и стоимость инфраструктуры функции RAG или семантического поиска — и это решение, которое явно должна принять каждая команда, строящая систему на «сыром» pgvector, Qdrant или Weaviate (управляемые сервисы вроде Pinecone скрывают это за разумными настройками по умолчанию). Как это работает: доминирующее семейство индексов в продакшене сегодня — HNSW (Hierarchical Navigable Small World, иерархические навигируемые графы малого мира) — графовая структура, где каждый вектор является узлом, связанным со своими приближёнными ближайшими соседями на нескольких уровнях, что позволяет поиску «перепрыгивать» к вектору запроса за примерно логарифмическое время вместо сканирования всего подряд. HNSW предлагает отличный компромисс между recall и скоростью, но прожорлив по памяти (весь граф обычно должен оставаться в RAM), а построение индекса вычислительно затратно для инкрементального обновления при очень высоком объёме записи. IVFFlat (Inverted File with Flat compression) — более дешёвая альтернатива, используемая pgvector и другими: она кластеризует векторы в «корзины» (через k-means) на этапе построения индекса и ищет только в корзинах, ближайших к запросу, жертвуя частью recall ради меньшей памяти и более быстрого построения — хорошо подходит для наборов данных, которые не меняются постоянно. Параметры настройки вроде `ef_construction`/`ef_search` (HNSW) или числа `lists`/`probes` (IVFFlat) напрямую обменивают recall на задержку: поиск в большей части графа или в большем числе кластеров находит лучшие совпадения, но занимает больше времени. Разбор примера: SaaS для поиска по коду индексирует 2 миллиона эмбеддингов функций. При плоском (без индекса) поиске один запрос занимает ~800 мс — неприемлемо для плагина IDE. Переход на HNSW-индекс с `m=16, ef_construction=200` снижает задержку запроса до ~8 мс с recall выше 95% относительно эталона полного перебора, ценой того, что индексу требуется ~6 ГБ RAM против ~4 ГБ на диске для сырых векторов. Позже команда поднимает `ef_search` с 50 до 100, заметив падение recall на неоднозначных запросах, обменивая пару дополнительных миллисекунд задержки на измеримо лучшее качество ответов в последующей LLM — компромисс настройки, невидимый для продуктовой поверхности, но напрямую определяющий, действительно ли «поиск похожих функций» ощущается надёжным для разработчиков, использующих плагин.