HNSW индексінің recall мәні неге төмендейді?

HNSW-тегі recall төмендегенде, оны көбіне дұрыс емес жақтан түзетуге тырысады. Команда нашар нәтижені көріп, ef_search мәнін арттырады, бірнеше миллисекунд жоғалтады да, инцидентті жабылды деп есептейді. Бір аптадан кейін recall қайта төмендейді, себебі шын себеп жаңа эмбеддер, аралас вектор нұсқалары, іздеуден кейін қолданылған сүзгі немесе коллекцияның толық жүктелмеуі болған.

HNSW құжаттың ескіргенін, мәтіннің басқа чанкермен бөлінгенін немесе жаңа сегменттегі жазбалардың жартысы L2-нормализациясыз вектор алғанын білмейді. Ол өзіне берілген сандар үшін графты аралайды. Сондықтан диагностика екі сұрақты қатаң ажыратудан басталады: қазіргі векторлар бойынша дәл іздеу әлі де күтілетін құжаттарды таба ма және HNSW осы дәл іздеуді қаншалықты жақсы қайталайды?

Malkov пен Yashuninнің түпнұсқа еңбегінде HNSW жуық іздеуге арналған иерархиялық граф ретінде сипатталған. Оның жылдамдығы графты шектеулі аралаудан келеді, ол әрқашан дәл top-k қайтарады деген уәде емес. Faiss құжаттамасы толық IndexFlat пен IndexHNSWFlat индекстерін тікелей ажыратады, ал OpenSearch құжаттамасы жоғары ef_search мәнін жақсырақ recall және жоғары кідіріспен байланыстырады. Бұл пайдалы бастама, бірақ диагноз емес.

Алдымен нашарлағаны дәл HNSW екенін дәлелдеңіз

HNSW recall төмендеуі бірдей деректердегі жуық top-k нәтижесінің дәл top-k нәтижесімен аз сәйкесетінін білдіреді. Бұл пайдаланушылардың азырақ пайдалы жауап алғанын білдірмейді.

Продакшенде әдетте үш түрлі көрсеткіш араласып кетеді. Біріншісі, өнімдік көрсеткіш, retrieval пайдаланушыға көмектесетін құжатты тапты ма деген сұраққа жауап береді. Екіншісі, векторлық көрсеткіш, эмбеддинг сапасын өлшейді: таңдалған метрика бойынша қажетті құжат дәл top-k ішіне кіре ме. Үшіншісі, ANN recall, дәл векторлық top-k элементтерінің қаншасы HNSW арқылы жеткенін көрсетеді.

Өнімдік метрика төмендеп, ANN recall тұрақты болса, граф параметрлеріне тимеңіз. Эмбеддинг моделін, құжаттарды бөлуді, сұрау тілдерін, қолжетімділік ережелерін және reranker-ді тексеріңіз. ANN recall төмендеп, ал вектор бойынша дәл іздеу мағыналы көрінсе, индексті және деректерді жаңарту жолын талдауға негіз бар.

Тағы бір жағымсыз жағдай бар: дәл top-k өзі нашарлап кеткен. Бұл эмбеддинг моделін ауыстырғаннан, нормализацияны өзгерткеннен, мәтіндерді түрлендіргеннен немесе терминологиясы бөлек құжаттардың үлкен доменін қосқаннан кейін болуы мүмкін. Мұндай жағдайда HNSW нашар эталонды recall 0.99 мәнімен адал қайталауы ықтимал.

Кез келген экспериментке дейін метрика анықтамасын бекітіңіз:

recall@k = |ANN_top_k ∩ exact_top_k| / k

Құжат немесе чанктердің ID мәндерін ғана салыстырыңыз. Recall-ды орташа similarity-мен алмастырмаңыз. HNSW ең жақын бір-екі элементті жүйелі түрде таппай жүрсе де, орташа similarity дерлік өзгермеуі мүмкін.

Эталон коллекцияның дәл сол снимогын қолдануы керек

Дәл және жуық іздеуді бір деректер снимогында іске қосу қажет, әйтпесе өлшемнің мағынасы болмайды.

Әр бақылау іске қосылымы үшін кемінде мыналарды сақтаңыз: коллекция нұсқасы, тірі нүктелер саны, эмбеддинг нұсқасы, вектор өлшемділігі, метрика, нормализация күйі, сүзгі параметрлері және query ID тізімі. Егер дәл іздеу түнгі жүктеуге дейін, ал HNSW тексерісі одан кейін орындалса, сіз индекс сапасымен бірге корпус өзгерісін де өлшеп отырсыз.

Төменде cosine similarity үшін ең қарапайым бақылау есебі берілген. Ол бақылау жиынын NumPy-ге экспорттауға жарайды және нақты векторлық базаға әдейі тәуелді емес.

import numpy as np

# db: float32 [n_vectors, dim], q: float32 [n_queries, dim]
# ids: int64 [n_vectors], ann_ids: int64 [n_queries, k]

def normalize(x):
    norms = np.linalg.norm(x, axis=1, keepdims=True)
    return x / np.clip(norms, 1e-12, None)

def exact_topk_cosine(db, ids, q, k):
    db = normalize(db.astype(np.float32))
    q = normalize(q.astype(np.float32))
    scores = q @ db.T
    pos = np.argpartition(-scores, kth=k - 1, axis=1)[:, :k]
    row = np.arange(q.shape[0])[:, None]
    pos = pos[row, np.argsort(-scores[row, pos], axis=1)]
    return ids[pos], scores[row, pos]

def recall_at_k(exact_ids, ann_ids):
    hits = []
    for truth, found in zip(exact_ids, ann_ids):
        hits.append(len(set(truth.tolist()) & set(found.tolist())) / len(truth))
    return float(np.mean(hits))

exact_ids, exact_scores = exact_topk_cosine(db, ids, q, k=20)
print({
    "recall_at_20": recall_at_k(exact_ids, ann_ids),
    "queries": len(q),
    "exact_first_score_median": float(np.median(exact_scores[:, 0]))
})

Шығыс форматы қызықсыз әрі тұрақты болуы керек:

{'recall_at_20': 0.9475, 'queries': 400, 'exact_first_score_median': 0.7812}

Эталон үшін векторларды байқатпай дөңгелектейтін, басқа қашықтық операторын қолданатын немесе post-filter қосатын бөлек SDK пайдаланбаңыз. Дәл есеп индекс алатын массивтердің өзін алуы керек. Әсіресе cosine-ды скалярлық көбейту арқылы есептеу база мен сұрауларды бірдей нормализациялаған жағдайда ғана дұрыс.

Деректер дрейфі модель өзгермесе де геометрияны өзгертеді

Деректер дрейфі векторлардың, сұраулардың немесе олардың бір-біріне сәйкестігінің таралуы өзгергенін білдіреді. Бұл графтың бұзылуымен бір нәрсе емес.

Банк өнімдері туралы нұсқаулықтар базасын елестетіңіз. Құжаттар жылдар бойы тақырыптық кластерлерде бірқалыпты жатты. Кейін базаға қысқа операция журналдары, шаблонды хабарламалар және регламенттердің қайталанатын үзінділері жаппай қосылды. Эмбеддинг моделі өзгерген жоқ. Бірақ бір-біріне ұқсас векторлардың тығыз топтары көбейді, ал бұрынғы сұраулар енді қашықтықтары өте жақын ондаған кандидат алады.

Мұндай базада екі оқиға қатар жүруі мүмкін. Пайдаланушы сапасы төмендейді, себебі дәл top-k дерлік дубликаттарға толады. ANN recall ID бойынша да төмендеуі мүмкін, өйткені дәл top-k ішінде бір-біріне өте ұқсас көршілер көп болады, ал HNSW тығыз топтан басқа элементті таңдайды. Екінші әсер индекс мәселесіне ұқсайды, бірақ алдымен эталонның өз тұрақтылығын тексеру керек.

Бірінші көршінің орташа қашықтығына ғана қарамаңыз. Әр сұрау үшін мыналарды сақтаңыз:

• бірінші дәл көршінің қашықтығы немесе similarity мәні;
• бірінші және k-шы көрші арасындағы алшақтық;
• k-шы және k+1-ші көрші арасындағы алшақтық;
• әр деректер кесіндісінен шыққан нәтижелердің үлесі;
• top-k ішіндегі дерлік дубликат чанктердің үлесі.

Cosine similarity үшін score[k] - score[k+1] мәнінің кішкентай болуы top-k шекарасының осал екенін білдіреді. Аз ғана сандық айырмашылықтың өзінде бір құжат дәл тізімнен түсіп қалып, оның орнына екіншісі келуі мүмкін. Мұндай режимде пайдаланушының k=10 мәні үшін recall@50-ді де есептеген немесе кеңірек кандидаттар пулына кіруді бағалаған пайдалы. Бұл нашар HNSW-ті ақтау емес. Бұл тұрақсыз шекараға қарап қате қорытынды жасамаудың жолы.

Таралуларды ескі және жаңа корпус үшін, сондай-ақ ескі және жаңа сұраулар үшін бөлек салыстырыңыз. Егер exact-first similarity, алшақтықтар және top құрамы өзгерсе, деректер дрейфке ұшыраған. Дәл іздеу таралулары бұрынғыдай болып, ANN анық көрінетін дәл көршілерді жиі өткізіп жібере бастаса, күдік индекске ауысады.

ef_search өсуі обход тапшылығын басқа себептерден ажыратады

Егер recall ef_search мәнімен бірге едәуір өссе, HNSW қолданыстағы обход бюджетімен графтың қажетті бөлігін зерттеп үлгермейді.

ef_search HNSW обходы кезінде іздеу қарастыратын векторлар санын белгілейді. OpenSearch бұл айырбасты тікелей сипаттайды: жоғары мән recall-ды жақсартады, бірақ кідірісті арттырады. Faiss-та осы параметр зерттеу тереңдігі деп аталады. Оны бір рет бөтен мысалға қарап таңдамай, өлшенген қисық бойынша баптау керек.

Бекітілген бір снимокта бір эксперимент жасаңыз. Модельді, репликаларды, сығуды, сүзгіні және сұраулар құрамын қатар өзгертпеңіз.

1. Қалыпты, сирек және проблемалы сұраулар бар frozen сұраулар жиынын алыңыз.
2. Дәл іздеуді орындап, top-20 нәтижесін сақтаңыз.
3. HNSW-ті ef_search мәндерінің бірнеше өспелі нұсқасымен іске қосыңыз.
4. Әр мән үшін recall@10, recall@20, кідірістің p50 және p95 мәндерін, сондай-ақ кесінділер бойынша нәтижелерді жазып алыңыз.
5. Жылыту әсері мен кездейсоқ басқа сұрау маршрутын жоққа шығару үшін клиентті қайта іске қосқаннан кейін тесті қайталаңыз.

Түсіндіру әдетте қарапайым. Кідіріс қолайлы шамада өсіп, recall күрт артса, іздеу бюджеті жеткіліксіз. Қисық дерлік жазық болса, басқа мәселе бар: қате метрика, бүлінген векторлар, сүзгі қатесі, квантизация немесе exact іздеу экспорты мен нақты коллекция арасындағы сәйкессіздік.

Орташа мәнге қарап қорытынды жасамаңыз. Бір тығыз тілдік сегмент немесе құжаттың бір түрі көршілерінің жартысын жоғалтып жатқанда, жалпы recall әлі де қалыпты көрінуі мүмкін. Бұл RAG жүйелерінде сирек кездесетін заңи тұжырымдарда, тариф атауларында, қате кодтарында және бірнеше шектеуі бар сұрауларда анық байқалады.

Құру параметрлерін бір сұраумен түзетуге болмайды

Жоғары ef_search әлсіз графтың бір бөлігін өтейді, бірақ индекс құрылып жатқанда жасалмаған байланыстарды қайтармайды.

HNSW құрылымына ең көп әсер ететін параметрлер, қозғалтқышқа қарай, M және ef_construction немесе ef_construct. M байланыстар санын шектейді, ал ef_construction вектор қосылған кезде кандидаттарды іздеу көлемін анықтайды. OpenSearch құжаттамасы жоғары ef_construction индекстеуді баяулату есебінен дәлірек граф құратынын көрсетеді, ал Qdrant m, ef_construct және іздеуге арналған ef параметрлерін бөлек баптау тетіктері ретінде сипаттайды.

Бұл айырмашылықты жиі шатастырады. ef_search бар графтың қаншалықты терең зерттелетінін таңдайды. ef_construction сол графтың қандай болып шыққанына әсер етеді. Біріншісін жаппай жүктеуден кейін көтеру, екіншісі төмен болған жағдайда, кейде орынды, бірақ бұл бұрын қабылданған граф сапасы шешімін кідіріспен өтеу деген сөз.

Тексеру қарапайым: бір экспортталған снимоктан қазіргі параметрлері бар уақытша индекс және құру параметрлері өзгертілген екінші индекс жасаңыз. Екеуінде де бірдей сұраулар жиынын және бірдей ef_search мәндерін қолданыңыз. Егер жаңа граф бірдей іздеу бюджетінде жақсы нәтиже берсе, қайта құру орынды. Айырмашылық болмаса, бақылау сезімі үшін қымбат rebuild іске қоспаңыз.

Өлшемсіз параметрлерді коллекциялар арасында көшірмеңіз. Қысқа әрі біртекті хабарландырулар корпусы, көптілді өтініштер мұрағаты және техникалық құжаттама базасы кластер тығыздығын әртүрлі қалыптастырады. Бірінде жақсы жұмыс істеген параметр екіншісінде жад жұмсап, айтарлықтай пайда бермеуі мүмкін.

Коллекция жаңартулары өлшемді графқа қарағанда жиірек бұзады

Коллекция жаңартылғаннан кейін алдымен деректердің сәйкессіздігін іздеңіз, HNSW-тің түсініксіз деградациясын емес.

Ең жиі кездесетін қате күнделікті көрінеді. Пайплайн алдымен жаңа payload жазып, кейін векторды жазуға жетпей тоқтады. Басқа воркер тапсырманы қайталап, жаңа чанкер қолданды. Үшінші процесс ескі ID мәндерін бір шардта ғана жойды. Құжаттар саны көрсеткіште дұрысқа жуық, бірақ шын мәнінде exact экспорты мен жұмыс істеп тұрған коллекцияда әртүрлі объектілер бар.

Индексті баптамас бұрын бес инвариантты тексеріңіз:

• әрбір тірі ID дәл қажетті өлшемділіктегі бір векторға ие;
• өлшеніп отырған коллекция ішінде эмбеддинг нұсқасы бірдей;
• векторлар бірдей нормализациядан өткен;
• себепсіз қайталап іске қосқанда құжаттар мен чанктердің ID мәндері өзгермейді;
• сүзгіленетін өрістер мен қолжетімділік құқықтары дәл эталонда және ANN сұрауында бірдей бар.

Upsert операциясына ерекше назар аударыңыз. Ескі ID астындағы мәтінді ауыстыру жаңа payload пен жаңа вектордың бір логикалық нұсқаға бірге түскеніне кепілдік болғанда ғана рұқсат етіледі. Процесс құжатты оқып, векторды есептеп, оны нұсқасыз бөлек операциялармен жазса, қатар орындалған жаңарту бір редакцияның мәтінін және екіншісінің эмбеддингін қалдыруы оңай.

Жоюлар мен сегментацияны да тексеру керек. Кейбір қозғалтқыштар шағын сегменттерде толық перебор қолдануы мүмкін, басқалары графты кейін құрады, ал үшіншілері сегменттерді асинхронды оңтайландырады. Мысалы, Qdrant жоспарлаушы HNSW орнына full scan қолданатын шекті және сегменттерді қайта индекстеу шарттарын бөлек құжаттайды. Сондықтан «жүктегеннен кейін нашарлады» деген сөз сұраулардың басқа орындау режиміне түскенін білдіруі мүмкін.

Жаңартуға дейін және одан кейін бақылау есебін жинаңыз: нүктелер саны, бірегей ID саны, нұсқалар бойынша векторлар саны, өлшемділік, нөлдік векторлар үлесі, нормалар таралуы және әр сегменттегі құжаттар үлесі. Бұл есеп recall графигі пікірталас тақырыбы болғанға дейін себепті тауып беруі мүмкін.

Сүзгілер мен квантизация жоғалтудың бөлек түрлерін тудырады

Filtered ANN мен сығылған векторлар бойынша іздеуді бөлек бағалау керек, өйткені олар іздеу тапсырмасының өзін өзгертеді.

Сүзгі top-k нәтижесінен кейін қосылатын косметикалық шарт емес. Алдымен бүкіл база бойынша ең жақын жиырма кандидатты алып, кейін тыйым салынғандарын алып тастасаңыз, k нәтижеден аз қайтаруыңыз және сәл тереңірек тұрған рұқсат етілген көршілерді өткізіп алуыңыз мүмкін. OpenSearch құжаттамасы қатаң предикат кезіндегі post-filter k мәнінен едәуір аз нәтиже қайтаруы мүмкін екенін тікелей ескертеді, ал k-NN іздеуі кезінде сүзгілеу басқаша жұмыс істейді.

Сүзгіленген сұраудың эталоны былай есептелуі керек:

exact_top_k = top_k(metric(query, vector)) among documents that pass the same filter

ANN нәтижесін сүзгіден кейін толық коллекция бойынша есептелген exact top-k нәтижесімен салыстырмаңыз. Бұл эксперимент қатесі қатаң қолжетімділік құқықтарында, күндерде, тілдерде және tenant ID мәндерінде «recall төмендеді» деген сөзсіз қорытынды көрсетеді.

Квантизация үшін тағы бір бөлік қажет. Сізде бастапқы float-векторлар, сығылған көрініс және сығылған көріністің үстіндегі HNSW болуы мүмкін. Жоғалтудың көзін түсіну үшін үш деңгейді өлшеңіз:

1. бастапқы векторлар бойынша exact;
2. іздеу үшін нақты сақталатын көрініс бойынша exact;
3. сол көрініс бойынша ANN.

Бірінші және екінші деңгей арасындағы айырмашылық сығуға тиесілі. Екінші және үшінші деңгей арасындағы айырмашылық жуық іздеуге тиесілі. Квантизация жоғалуын ef_search мәнін арттырумен өтеу мағынасыз: HNSW бұрмаланған геометриядағы көршілерді дәлірек іздегенімен ғана шектеледі.

Қайта құру күнтізбе бойынша емес, дәлелденгеннен кейін қажет

Векторлардың сол бір жиыны жаңа графта жақсырақ ANN recall алатынын өлшем көрсетсе немесе жаңарту жолы қолданыстағы құрылымның тұтастығына кепілдік бере алмаса, HNSW-ті қайта құрыңыз.

Қалыпты rebuild процедурасы боевой коллекцияны жоюдан басталмайды. Ескі нұсқаның жанында жаңа нұсқа жасаңыз, оған тексерілген бір экспортты жүктеңіз, инварианттарды тексеріңіз, индексті құрыңыз, frozen жиынын орындап, exact, ANN және кідірістерді салыстырыңыз. Содан кейін оқуды жаңа нұсқаға ауыстырыңыз. Белгілі query ID бойынша айырмашылықтарды зерттеу үшін ескі нұсқаны жеткілікті уақыт сақтаңыз.

Кезеңдік қайта құруды сапаны бақылаудың жалғыз саясатына айналдырмаңыз. Ол аралас эмбеддингтерді, қате сүзгілерді немесе корпус дрейфін уақытша жасыруы мүмкін, бірақ бұл қателер келесі жаңартуда қайта оралады. Жақсы жүйе оларды кіріс кезінде ұстайды: эмбеддинг нұсқасы жазбаның метадеректеріне кіреді, бақылау сұраулары жүктеуден кейін орындалады, ал exact эталон онлайн жолдан бөлек сақталады.

Бірыңғай OpenAI-үйлесімді қабатты қолданатын командалар үшін AI Router эмбеддингтер нұсқасы мен модель маршрутын бақылауды жеңілдетуі мүмкін, бірақ бұл тәртіпті жоймайды. Векторлық коллекция бәрібір сіздің жауапкершілігіңізде: әр вектордың қай модельмен және қандай түрлендірумен алынғанын сақтаңыз.

Бір жалпы recall емес, екі тексеру жиынын ұстаңыз

Бір агрегатталған recall индекс деградациясын да, деректер деградациясын да жасырады. Әртүрлі міндеттері бар екі сұрау жиынын ұстаңыз.

Бірінші жиын ANN инженериясына қажет. Ол бекітілген, күрделі геометриялық жағдайларды қамтиды және әрқашан бір снимок бойынша дәл іздеумен салыстырылады. Оның мақсаты ef_search, құру параметрлері, сегменттер, сүзгілер және сығудың әсерін көру.

Екінші жиын өнімге қажет. Оның құрамында нақты сұраулар мен тексерілген релевантты құжаттар бар, ол доменмен бірге жаңарып отырады және retrieval сапасын reranker-ге дейін де, одан кейін де өлшейді. Оның мақсаты модель, чанкер немесе корпус пайдаланушы сұрағына жауап беруді тоқтатқан сәтті көру.

Бұл жиындар бір-бірінен алшақтаса, бұл жақсы жаңалық: қайдан іздеу керегін білесіз. Тек біріншісі төмендесе, HNSW пен сақтауды талдаңыз. Тек екіншісі төмендесе, деректер мен семантиканы талдаңыз. Екеуі де төмендесе, алдымен коллекцияның жаңа нұсқасын бекітіп, exact эталонды қайта есептеңіз. Оған дейін ef_search мәнін көтеру жауап сатып алу емес, кідіріс сатып алу болады.