Налаштування індексів HNSW та масштабування пошуку векторів для продакшн-систем RAG
Дізнайтеся, як параметри M та ef у алгоритмі HNSW впливають на рівень відтворення даних, затримку та обсяг пам’яті, як налаштувати їх у Chroma, а також коли слід масштабувати векторну базу даних вертикально чи шляхом шардування.
Джерела: **15.**HNSW & Vector Database Tuning for Production RAG
Прототип генерації з підтримкою пошуку (RAG), який використовує кілька тисяч векторів, здатний негайно відповідати майже на будь-якому обладнанні. Коли кількість даних зростає до мільйонів, починають проявлятися проблеми з затримками та використанням ресурсів, а налаштування індексу стає важливою проблемою у продакшені. У цьому посібнику розглядаються два найважливіші параметри HNSW, способи їх налаштування в Chroma, а також ознаки того, коли налаштувань вже недостатньо та систему потрібно масштабувати.
Два параметри HNSW, які контролюють майже все
Вам не потрібна повна теорія графів HNSW (Hierarchical Navigable Small World), щоб налаштувати їх. Індекс пов’язує кожен вектор із сусідніми векторами у кількох шарах, а запит прокладає шлях по цьому графу до найближчих сусідів. Два параметри визначають структуру цього графу та шлях по ньому. Щоб дізнатися більше, перегляньте наш пояснювальний матеріал про як працюють бази даних векторів, від ембеддингів до гібридного пошуку.
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 мільйонів векторів, першим кроком зазвичай є додавання RAM або CPU до існуючої машини. З достатньою кількістю пам’яті весь індекс поміщається у RAM, що повертає швидкий пошук та покращує загальну ефективність.
Вертикальне масштабування не вимагає змін у архітектурі чи коді, проте одна машина має обмеження щодо кількості пам’яті, а більш потужні версії швидко стають дорогими.
Горизонтальне масштабування
Після приблизно 10 мільйонів векторів горизонтальне масштабування стає практичним рішенням. Колекція ділиться на частини, тобто дані розподіляються між кількома екземплярами, і кожна частина зберігає та шукає лише свою частину даних.
Це усуває обмеження, пов’язані з однією машиною. Однак це призводить до складності: кожен запит розсилається до всіх частин, а їхні часткові результати потрібно об’єднати в один впорядкований список, що збільшує затримку та обсяг роботи.
Основні висновки
Mвпливає на структуру графа: більші значення підвищують точність та використання пам’яті, а зміна цього параметра вимагає перебудови.efвпливає на процес пошуку: підвищення значення часу пошуку — це найдешевший спосіб пожертвувати частиною затримки заради підвищення точності.
M 16 із параметром пошуку ef 100, а потім протестуйте її на власних запитах.