Настройка индексов HNSW и масштабирование поиска векторов для производственных систем RAG

Прототип генерации с усилением на основе поиска (RAG), использующий несколько тысяч векторов, обеспечивает мгновенный ответ практически на любом оборудовании. Однако по мере увеличения количества данных до миллионов возникают проблемы с задержками и потреблением ресурсов, а настройка индекса становится важной задачей для производственного использования. В этом руководстве рассматриваются два наиболее важных параметра HNSW, способ их настройки в Chroma, а также признаки того, когда настройки уже недостаточны и систему необходимо масштабировать.

Два параметра HNSW, контролирующих практически всё

Для настройки графов HNSW (Hierarchical Navigable Small World) не требуется полное знание теории. Индекс связывает каждый вектор с близлежащими векторами на нескольких уровнях, а запрос прокладывает путь по этому графу к своим ближайшим соседям. Два параметра определяют структуру этого графа и ход поиска. Чтобы узнать больше, ознакомьтесь с нашим обзором точного функционирования векторных баз данных, от эмбеддингов до гибридного поиска.

M: максимальное количество связей на узел

M задаёт максимальное количество связей с соседями, которые хранит каждый узел в графе.

• Низкое значение M: меньше связей, меньший размер индекса, меньше памяти и более быстрый поиск, но более низкая точность восстановления результатов из-за меньшего количества путей к подходящим кандидатам.

Высокое M: больше ссылок на узел, больше памяти, более крупный индекс и медленнее формирование. Запросы выполняются несколько медленнее, но точность улучшается, поскольку граф предоставляет больше путей к истинным ближайшим соседям.

M фиксируется при создании индекса, поэтому его изменение позже означает необходимость повторного создания индекса.

ef: степень усилий при каждом поиске

ef определяет, сколько кандидатов индекс учитывает в процессе поиска ближайших соседей запроса.

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

Многие движки разделяют этот параметр на значение, задаваемое во время построения графа и контролирующее степень тщательности его создания, и значение, задаваемое во время поиска, которое обычно можно изменить без пересоздания графа, что делает его самым доступным параметром для экспериментов.

Баланс между точностью, скоростью и памятью

Настройка HNSW предполагает трехсторонний компромисс между точностью, скоростью и памятью. Эти комбинации являются разумными отправной точками для типичных этапов проекта, причем ef обозначает значение, задаваемое во время поиска:

+----------------+----+-----+----------+
| Use Case       | M  | ef  | Priority |
+----------------+----+-----+----------+
| Prototype      | 16 | 40  | Speed    |
| Production     | 16 | 100 | Balanced |
| High accuracy  | 32 | 200 | Accuracy |
+----------------+----+-----+----------+

Рассматривайте их как базовые значения для сравнения: измеряйте степень воспроизведения результатов и время отклика для репрезентативных запросов до и после каждой изменения.

Настройка параметров HNSW в Chroma

Каждая база данных векторов реализует эти настройки по-разному. В Chroma их можно передать в качестве метаданных коллекции при её создании. В приведённом ниже примере значение M установлено в 16, значение ef при создании — в 100, а значение ef во время поиска — в 50:

#Chroma-HNSW Settings
collection=client.create_collection(
name='new_collection',
metadata={
'hnsw:M':16,
'hnsw:construction_ef': 100,
'hnsw:search_ef': 50
}
)

Формат ключей метаданных может отличаться в более новых версиях Chroma, где также предусмотрен специальный объект конфигурации; поэтому обязательно ознакомьтесь с документацией для вашей версии. Установите значения M и ef при создании коллекции до загрузки данных, поскольку они встраиваются в структуру графа.

Когда настройки уже недостаточны

Даже хорошо настроенный индекс в конечном итоге сталкивается с ограничениями. Когда время поиска регулярно превышает 100 мс, частой причиной является то, что индекс больше не помещается в память, и дальнейшая настройка параметров эту проблему не решит. Приблизительная оценка помогает: объем хранения векторов составляет количество векторов умноженное на их размеры, умноженное на 4 байта для 32-битных чисел с плавающей точкой, а граф HNSW добавляет дополнительные затраты памяти, которые растут с M. В таком случае решением является масштабирование, которое бывает двух видов.

Вертикальное масштабирование

Для наборов, содержащих примерно от 5 до 10 миллионов векторов, первым шагом обычно является увеличение объема оперативной памяти или производительности CPU на существующем устройстве. При достаточном объеме памяти весь индекс помещается в оперативную память, что восстанавливает быстрый поиск и повышает общую эффективность.

Вертикальное масштабирование не требует изменений в архитектуре или коде, но у одной машины есть ограничение по объему памяти, а более мощные версии быстро становятся дорогими.

Горизонтальное масштабирование

При объеме данных, превышающем примерно 10 миллионов векторов, горизонтальное масштабирование становится практичным решением. Коллекция делят на части, то есть данные распределяются между несколькими инстансами, причем каждая часть хранит и обрабатывает свою порцию данных.

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

Основные выводы

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

Начните с сбалансированной конфигурации, такой как M 16 с параметром поиска ef равным 100, затем протестируйте её на собственных запросах.

Большинство производственных систем RAG функционируют благодаря настройке индексов и вертикальному масштабированию; шардинг эффективен, но редко необходим, поэтому используйте его только для коллекций, которые действительно вырастают за пределы одной машины.