Сүзгіленген векторлық іздеу жалға алушыларда recall-ды қалай жоғалтады

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

Себеп әдетте эмбеддинг моделінде емес. ANN іздеуі жалпы кеңістікте шектеулі кандидаттар жиынын құрады, ал жалға алушы, құқық, аймақ немесе мәртебе бойынша сүзгі рұқсат етілген жиынды күрт тарылтады. Қажетті сегмент сирек болса, кандидаттар бюджеті көрші сегменттердегі бөтен нысандарға жұмсалады. Сүзгіден кейін нәтиже қысқа немесе қатысы жоқ болады. Мұны жүйенің жеке қасиеті ретінде жүктеме тестімен тексеру керек. Жақсы жаһандық recall барлық жағдайды қамтиды деп үміттенуге болмайды.

Recall-ды рұқсат етілген жиынның ішінде есептеу керек

tenant_id бар сұрау үшін эталондық нәтиже бүкіл жүйедегі ең жақын k векторды алып, кейін сүзу емес. Эталондық нәтиже tenant_id және барлық басқа міндетті шарттардан өтетін құжаттардың ішіндегі ең жақын k құжат болуы керек. Әйтпесе сіз басқа міндетті тексеріп жатырсыз.

q сұрауы t жалға алушысына тиесілі болсын, ал F(t, q) сүзгі рұқсат еткен құжаттарды білдірсін. Дәл эталон мынадай:

truth(q) = distance(q, d) бойынша top_k, мұнда d F(t, q) жиынына тиесілі

Жуық сұрау ann(q) нәтижесін қайтарады. Нақты сұрау үшін recall@k мәтіндердің ұқсастығы немесе адамның бағасы арқылы емес, идентификаторлардың қиылысуы арқылы есептеледі:

recall@k(q) = |truth(q) ∩ ann(q)| / k

Рұқсат етілген жиында k құжаттан аз болса, бөлімдегі сан эталондық нәтиже өлшеміне тең болуы керек. Қағазда бұл ұсақ-түйек көрінеді. Нақты көп жалға алушысы бар жүйеде шағын және жаңа жалға алушыларда сұралған k мәнінен аз құжат жиі болады. Қате формула бос нәтижені қалыпты нәтиже сияқты көрсетеді.

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

pgvector құжаттамасында бұл нақты айтылған: жуық индекс кезінде сүзгі индекс сканерленгеннен кейін қолданылады, сондықтан шектеулі hnsw.ef_search қажетті жол санын бермеуі мүмкін. Мысал ретінде құжаттама селективтілігі 10% болатын сүзгіні келтіреді: әдепкі ef_search = 40 кезінде орта есеппен төрт сәйкес жол ғана қалады. Бұл PostgreSQL қатесі де, ерекше жағдай да емес. Бұл шектеулі кандидаттар санының күтілетін нәтижесі.

Орташа жалға алушы ұзын құйрықты жасырады

Құжаттардың жалға алушылар арасында бөлінуі ешқашан біркелкі болмайды. Бір банк бірнеше жылдық өтініштер тарихын жүктейді, SaaS клиенті ондаған мың карточка қосады, ал шағын бөлім бірнеше жүз ереже әкеледі. Егер мың сұрауды трафикке пропорционалды алсаңыз, ірі сегменттер экспериментті басып кетеді. Сирек жалға алушылар жүйелі түрде ұтылып тұрса да, жалпы recall әдемі көрінеді.

Нәтижелерді кемінде екі тәуелсіз шкала бойынша бөліңіз:

• сүзгіден кейінгі рұқсат етілген сегмент өлшемі;
• сүзгінің бүкіл индекске қатысты селективтілігі.

Бұл бір нәрсе емес. 10 000 құжаты бар жалға алушы миллиард векторы бар индексте өте шағын болуы мүмкін. Керісінше, рөл бойынша сүзгі 500 құжат қалдыруы мүмкін, бірақ олар барлық жалға алушыларға таралған болады. ANN индексі үшін екі жағдай да маңызды: қолайлы нысандар қанша екені және құрылымды айналып өткенде олардың қаншалықты сирек кездесетіні.

Практикалық санаттар торы мынадай болуы мүмкін: рұқсат етілген векторлар саны 100-ден аз, 100-1 000, 1 000-10 000, 10 000-100 000 және 100 000-нан көп. Селективтілік үшін бөлек санаттар жасаңыз: 0,01%-дан аз, 0,01-0,1%, 0,1-1%, 1-10% және 10%-дан жоғары. Шекаралар міндетті емес. Олардың мақсаты графикте сирек жұмыс режимінің жоғалып кетпеуін қамтамасыз ету.

Жалға алушы өлшемін сүзгіге дейінгі корпус өлшемімен шатастырмаңыз. Жалға алушыда 50 000 құжат болуы мүмкін, бірақ document_type = policy, language = kk және active = true сұрауы 60 құжат қана қалдырады. Нақты іздеудің күрделілігін осы 60 құжат анықтайды. Тест кестесінде tenant өлшемін де, әр сұрау үшін толық сүзгіден өткен жолдар санын да сақтаңыз.

Тағы бір жағымсыз жайт бар. Шағын жалға алушылардың сұраулары жиі нашар тұжырымдалады, қайталама іздеуі аз, құжаттары әркелкі болады. Эталондық жақын мәтіндерді қолмен тексермей, нашар recall-ды сүзгіге жаба салуға болмайды. Кері қате де жиі кездеседі: команда промптты жақсартады немесе embedding моделін ауыстырады, ал шын мәнінде ANN іздеуі дұрыс кандидаттарға жетпеген.

Жүктеме тесті орташа мәнді емес, теңсіздікті қайталауы керек

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

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

Әр сұрау үшін өзгермейтін паспорт сақтаңыз:

{
  "query_id": "q-1842",
  "tenant_id": "tenant-small-17",
  "k": 10,
  "filter": {
    "tenant_id": "tenant-small-17",
    "document_type": "policy",
    "active": true
  },
  "eligible_count": 74,
  "tenant_count": 623,
  "global_count": 18000000
}

eligible_count мәнін ANN сұрауының нәтижесінен есептеуге болмайды. Оны бөлек дәл іске қосу немесе алдын ала жасалған эталон береді. Егер оған нақты қайтарылған құжаттар санын жазсаңыз, тест өз қатесін растай бастайды.

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

Тек жеке сұрауларды өлшемеңіз. Бәсекелес жүктеме индекстің және деректердің жадқа түсуін, CPU кезегін, кэш әрекетін және кідіріс құйрығын өзгертеді. Параллельдіктің бірнеше деңгейін, соның ішінде сервис жұмыс жүктемесіне жақындайтын деңгейді іске қосыңыз. Содан кейін дәл эталонды офлайн, қызған қызмет көрсету жолында емес, қайта іске қосыңыз. Эталонның мақсаты жылдамдық емес, дұрыстық.

Post-filter әдемі, бірақ толық емес нәтиже жиынын жиі береді

Ең көп тараған архитектуралық қате қарапайым: алдымен барлық вектор бойынша k = 10 параметрімен ANN іздеуін орындау, содан кейін табылған он нысанды tenant_id бойынша сүзу. Селективті сүзгі кезінде бұл схема он нәтижеге кепілдік бере алмайды. Егер сегіз кандидат басқа жалға алушыларға тиесілі болса, рұқсат етілген сегментте мыңдаған қолайлы құжат тұрса да, сіз екі нәтижені ғана көрсетесіз.

Инженерлер мұны сыртқы k мәнін, мысалы, 200 кандидат алып, сүзгіден кейін он нәтижені қалдыру арқылы түзетуге тырысады. Селективтілік орташа болса, бұл уақытша шешім ретінде жарауы мүмкін, бірақ оны сапа кепілдігі деп санауға болмайды. Үлесі 0,01% сегмент үшін 200 кандидаттың өзі бір де бір құжат бермеуі мүмкін. Ал k мәнін өсіргенде шығын желіге, жадқа, реранкерге және қолданбалық кодқа ауысады.

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

Бірақ «іздеу ішіндегі сүзгі» автоматты түрде мінсіз recall деген сөз емес. Іске асыру ANN құрылымын айналып өту мен сүзгіден өткен ішкі жиынды дәл өңдеу арасында таңдау жасауы, айналып өту бюджетін шектеуі немесе селективтілік бағасына қарай стратегияны ауыстыруы мүмкін. Сондықтан есепте нақты қозғалтқыштың семантикасы мен сұраудың нақты синтаксисін белгілеңіз. Бір сүзгіні векторлық шарттың ішіне немесе сыртына орналастыру кідірісті ғана емес, нәтиже жиынын да өзгертуі мүмкін.

Мұны қарапайым инвариантпен тексеріңіз: егер eligible_count >= k болса, барлық міндетті сүзгілерден кейін қайтарылған жолдар саны k болуы керек. Инварианттың бұзылуы әрдайым төмен recall дегенді білдірмейді, бірақ түсіндіруді талап етеді. Сіз іздеуге әдейі шектеу қойған болуыңыз мүмкін, қозғалтқыш сүзгіні тым қысқа кандидаттар іріктеуінен кейін қолданған болуы мүмкін немесе сұрауда қате болуы мүмкін.

Сирек жалға алушыға іздеудің бөлек стратегиясы қажет

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

Стратегияны бүкіл кестедегі құжаттар санына қарап таңдамаңыз. Оны сүзгіден кейінгі күтілетін жиын өлшемі мен мақсатты кідіріске қарап таңдаңыз. Шартты саясат мынадай болуы мүмкін:

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

Бұл режимдер арасындағы шекті басқа бенчмарктен ала алмайсыз. Ол эмбеддинг өлшеміне, метрикаға, CPU санына, жадқа, диск жүйесіне, сүзгілер құрамына және сұраулар кезегіне байланысты. Шекті eligible_count X осінде, ал p95 пен recall@k Y осінде тұрған график арқылы табыңыз. Ауысу нүктесі дәл жол кідіріс бюджетіне сыймай бастаған немесе ANN белгіленген толықтықты сенімді бере бастаған жерден тұруы керек.

Нәтижелер бойынша пагинация бұл мәселені емдемейді. Бірінші ANN іздеуі қажетті нысандарды таппаса, екінші бет оларды жақындатпайды. Сол сияқты reranking кандидатта болмаған құжатты қайтармайды. Реранкер кандидаттардың ретін жақсартады, ал сүзгіленген ANN кандидаттардың оған мүлде жеткізілген-жеткізілмегенін анықтайды.

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

Индекс баптауларын ең нашар санатқа қарап таңдаңыз

HNSW-ті жаһандық recall бойынша баптау сирек сүзгілер үшін тым шағын іздеу бюджетін таңдауға әкеледі. pgvector ішінде hnsw.ef_search динамикалық кандидаттар тізімінің өлшемін шектейді. Құжаттама сүзгілеу кезінде оны өсіруді ұсынады, ал 0.8.0 нұсқасынан бастап iterative index scans мүмкіндігін береді: қозғалтқыш жеткілікті жол жинағанша немесе қаралған кортеждер саны не жад бойынша белгіленген шекке жеткенше сканерлеуді жалғастырады.

Итерациялық сканерлеу пайдалы, бірақ бюджетті жоймайды. hnsw.max_scan_tuples тым аз болса, сирек жалға алушы нәтижесіз қалады. Лимитті қорғаныссыз тым жоғары қойсаңыз, бір тар сүзгі CPU-ды алып, басқалар үшін p99 көрсеткішін нашарлатуы мүмкін. Сондықтан бір ғана ef_search емес, параметрлер жиынтығын тестілеңіз: бастапқы бюджет, ең жоғары кеңейту, жад лимиті және рұқсат етілген кідіріс құйрығы.

IVFFlat үшін осы логика тексерілетін тізімдер санына қатысты. probes аз болса, іздеу жылдам, бірақ толық емес болады. probes көп болса, толықтық артады, бірақ сұрау қымбат сканерлеуге жақындайды. IVFFlat-та тағы бір қауіп бар: тізімдер саны деректердің кластерлерге қаншалықты біркелкі бөлінетініне әсер етеді. Шағын көлемде және тізімдер саны тым агрессивті болып жасалған индекс сүзгіге дейін-ақ толықтықты нашар беруі мүмкін.

Конфигурацияларды бір сұрауда қолмен таңдаудың орнына матрицамен тексеріңіз. Әр параметр жұбы үшін мынаны жазыңыз:

Соңғы баған қаралған векторлар саны, барған түйіндер, ef_search, probes саны немесе қозғалтқыш беретін басқа метрика болуы мүмкін. Онсыз сәтті баптаудың сапаны қолайсыз шығынмен сатып алған баптаудан айырмасын түсіну қиын.

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

Дәл эталон жуық тесттің жанында болуы керек

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

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

BEGIN;

SET LOCAL enable_indexscan = off;
SET LOCAL enable_bitmapscan = off;

SELECT id
FROM chunks
WHERE tenant_id = :tenant_id
  AND document_type = :document_type
  AND active = true
ORDER BY embedding <=> :query_embedding
LIMIT 10;

COMMIT;

Содан кейін индекспен жұмыс істейтін нұсқаны бөлек іске қосып, идентификаторлардың реттелген екі тізімін сақтаңыз. pgvector recall-ды жуық іздеуді дәл іздеумен салыстыру арқылы бақылауды ұсынады және мұндай бақылау үшін index scan мүмкіндігін өшіруді көрсетеді.

HNSW экспериментіндегі жұмыс сұрауы мынадай болуы мүмкін:

BEGIN;

SET LOCAL hnsw.ef_search = 80;
SET LOCAL hnsw.iterative_scan = strict_order;
SET LOCAL hnsw.max_scan_tuples = 20000;

SELECT id
FROM chunks
WHERE tenant_id = :tenant_id
  AND document_type = :document_type
  AND active = true
ORDER BY embedding <=> :query_embedding
LIMIT 10;

COMMIT;

Бұл сандарды рецепт ретінде production жүйесіне көшірмеңіз. Олар эксперименттің құрылымын көрсету үшін берілген. Әр нәтиже жолында query_id, іздеу параметрлері, exact IDs тізімі, ANN IDs тізімі, ұзақтығы, қайтарылған жолдар саны және сегмент санаттары сақталсын. Сонда бүкіл тесті қайта іске қоспай-ақ recall@10, бірінші орын hit rate, толық емес нәтиже үлесі мен кідірістерді есептеуге болады.

Дәл сұраудың шынымен дәл екеніне көз жеткізіңіз. Жоспарлаушы күтпеген жолды таңдауы, ал сүзгі сіз ойлағаннан басқаша қолданылуы мүмкін. Әр санаттағы бірнеше сұрау үшін EXPLAIN (ANALYZE, BUFFERS) нәтижесін қараңыз. Әсіресе join, ішкі сұрау немесе қолжетімділікті тексеру функциясының ішінде жасырылған сүзгілерге назар аударыңыз. Сұрау семантикасы индекстің әдемі атауынан маңызды.

Деректер схемасындағы қателер ANN мәселесі болып көрінуі мүмкін

Көп жалға алушысы бар іздеу көбіне векторлар кестесін негізгі құжаттар кестесімен, рұқсаттар кестесімен және ұйымдар кестесімен біріктіреді. Егер tenant_id тек негізгі кестеде тұрса, сүзгі векторлық сканерлеу мен join-нан кейін қолданылуы мүмкін. Бұл әрдайым қате емес, бірақ жоспардан көріп, салдарын өлшеуіңіз керек. Оқшаулау ережесі маңызды болғанда, іздеуге қажет өзгермейтін сүзгілерді вектордың жанында сақтау талдау үшін әдетте оңайырақ әрі сенімдірек.

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

Тағы бір тұзақ - soft delete. Құжат өнімнен жасырылғанымен, оның векторы фондық тазалауға дейін индексте қалуы мүмкін. Іздеу кандидаттарды өлі жолдарға жұмсайды, ал тар сүзгі оларды соңында алып тастайды. Есепте ANN тірі құжаттарды таппаған жағдайларды жойылған немесе қолжетімсіз құжаттарды тапқан жағдайлардан бөліңіз. Әйтпесе команда алдымен деректердің өмірлік циклін түзету керек кезде ef_search мәнін көтереді.

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

SLO шағын сегменттердің үнсіз құлауына тыйым салуы керек

Сүзгіленген іздеу үшін «recall@10 кемінде 0,95» деген жалғыз мақсат жеткіліксіз. Ол нәтиженің қандай сұрауларда және қандай кідіріс құнымен алынғанын көрсетпейді. Санаттар бойынша талап қойып, толық емес нәтиже үшін бөлек шектеу белгілеңіз.

Командамен талқылауға болатын мысал: рұқсат етілген құжат саны оннан кем емес сұрауларда сервис он құжат қайтарады; қолдау көрсетілетін селективтілік санаттарының әрқайсысында recall@10 келісілген шектен төмен түспейді; жұмыс кезіндегі параллельділікте p99 белгіленген лимиттен аспайды. Өте шағын сегменттер дәл жолмен қызмет алса, оны метрикаларда атап, ANN нәтижелерімен араластырмау керек.

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

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

Ең пайдалы алғашқы іске қосу күрделі стендті қажет етпейді. Ірі, орта және шағын жалға алушылардан бірнеше ондаған нақты сұрау алыңыз. Олар үшін толық сүзгі ішіндегі дәл top-k нәтижесін құрыңыз. Содан кейін оны қазіргі ANN жолымен салыстырып, қателерді eligible_count пен селективтілік бойынша бөліңіз. Егер график сирек сегменттерде күрт құлдыраса, орташа recall туралы дауласпаңыз. Пайдаланушы нашар жауап алып тұрған жердегі іздеу жолын, деректер құрылымын немесе индекс бюджетін өзгертіңіз.