Настройка індэксаў 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, а пасля працавайце з тестамі на сопныя запыткі.