Реранкер қашан ақталады: recall, кідіріс және баға

Неге іздеудегі артық қадам дауға себеп болады

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

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

Сондықтан командалар реранкер қосады. Ол 20 немесе 50 құжат сияқты қысқа кандидаттар тізімін алып, оны енді жай ұқсастыққа емес, сұрақпен нақтырақ сәйкестікке қарай қайта реттейді. Идеясы қарапайым: қайта іздеудің қажеті жоқ, бұрын табылған нәтижені дұрыс жерге шығару керек.

Әдетте дау идеяның өзіне емес, осы қадамның бағасына байланысты.

Егер реранкер керек жауапты 7-орыннан 2-орынға көтерсе, пайдаланушы оны бірден байқайды. Қолдау қызметінде, білім базасы бойынша ішкі іздеуде немесе операторға арналған RAG жүйесінде бұл айырмашылық тез көрінеді. Бірдей құжаттар жиыны тек реттілігі жақсарғандықтан ақылдырақ болып көріне бастайды.

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

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

Керісінше жағдай да болады. Базалық іздеу ұқсас құжаттарды табады, бірақ жақын тұжырымдарды, нұсқаулықтардың версияларын немесе бір-біріне өте ұқсас тауар карточкаларын шатастырады. Ондайда реранкер адам байқайтын қатені түзетеді: ең ұқсас мәтінді емес, нақтырақ үзіндіні жоғары шығарады.

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

Қайсысын пайда, қайсысын шығын деп санау керек

Реранкердің ақталатынын түсіну үшін оны тек әдемі есептегі метрикамен емес, нақты тапсырма деңгейінде өлшеу керек. Команда көбіне ұзын кандидаттар тізіміндегі сапа өсімін көріп, қате қорытынды жасайды. Пайдаланушы top-100 тізімді оқымайды. Ол алғашқы 3-5 нәтижені көреді немесе бірден дайын жауап алады.

Іске ең жақын метрика

Ең алдымен жұмыс топтағы recall-ға қараңыз. Егер реранкер керек құжатты 18-орыннан 4-орынға көтерсе, бұл нақты пайда. Егер ол құжаттарды тек top-50 ішінде орын алмастырып, top-5-те ештеңе өзгертпесе, пайдасы шамалы.

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

Мұндай көзқарас тез-ақ шындыққа жақындатады. Кандидаттардағы recall өсімі өздігінен артық қадамның ақысын жаппайды. Тек тапсырманың нәтижесін өзгертетін өсім ғана төлейді.

Жақсы тест өте қарапайым. Нақты сұраулар жиынтығын алып, реранкерсіз және реранкермен нәтижені салыстырасыз, содан кейін тек дұрыс құжаттың орнына ғана емес, адамның не боттың жұмысты аяқтай алған-алмағанына да қарайсыз. Қолдау қызметі үшін құжаттың 2-орында не 9-орында тұруы арасындағы айырмашылық өте үлкен. Ал бәрібір 20 карточканы ашып шығатын аналитик үшін ол нөлге жуық болуы мүмкін.

Құн мен кідірісті қабаттап есептеу

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

Кідіріс үшін де солай. Алғашқы іздеу қанша уақыт алғанын, реранкер қанша қосты, модельдің жауабы қанша уақытқа созылғанын бөлек өлшеңіз. Әйтпесе жағымсыз сценарийді өткізіп алуға болады: реранкер top-5-та recall-ды 4% көтерді, бірақ 350 мс қосты, сөйтіп боттың жауабы айтарлықтай баяулады.

Тек орташа мәнге емес, құйрықтарға да қараңыз. Егер сұраулардың 80% жылдам өтсе, ал күрделі сұраулар реранкермен кейде екі есе ұзақ күтсе, оператор дәл соны сезеді.

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

Реранкер нақты қашан көмектеседі

Реранкер іздеуді кеңейтпейді. Егер бірінші кезең кандидаттар тізіміне құжатты мүлде қоспаса, ол жаңа құжат таба алмайды. Оның пайдасы басқа нүктеде басталады: кандидаттар бойынша recall қалыпты, бірақ реті әлсіз болғанда. Керек үзінді top-50 не top-100 ішінде бар, бірақ тым төмен тұрады да, адам көретін немесе RAG алатын жұмыс топқа түспейді.

Дәл осы жерде екінші қадам жиі айқын әсер береді. Жылдам алғашқы іздеу ұқсас бөліктердің кең жиынын жинайды. Реранкер оларды мұқият оқып, жай ұқсастыққа емес, сұраудың мағынасына қарай қайта орналастырады. Метрика үшін бұл 24-орыннан 4-орынға жылжу болуы мүмкін. Пайдаланушы үшін айырмашылық одан да үлкен: жауап бірден шықты, артық ашулар да, нақтылаулар да қажет емес.

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

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

Мұндай базада бірінші кезең адал түрде жақын тұрған бірдеңені табады, бірақ бірінші орынға нені шығару керегін нашар шешеді. Реранкер дәл осы ранжирлеу қатесін түзетеді.

Көрініс көбіне мынадай: онсыз қажет бөлік кандидаттардың арасында бар, бірақ top-5 немесе top-10-ға сирек кіреді. Онымен бірдей кандидаттар жиыны жақсырақ реттеледі. Ал егер керек материал top-100-ге де сирек кірсе, екінші қадамның пайдасы шамалы. Онда іздеудің өзін түзету керек: chunk бөлу, фильтрлер, өрістер, эмбеддингтер және синонимдер сөздігі.

Ақталуын қалай есептеуге болады

Синтетикалық емес, 2-4 аптадағы тірі логтардан алынған сұрауларды қолданыңыз. Әр сұрау үшін эталон керек: қай құжат кемінде top-3 немесе top-5-ке кіруі тиіс. Егер команда эталонды алдын ала келіспесе, дау тез арада сезімге ауысады.

Келесі қадам - таза тест. Прогондар арасында индекс, chunk, эмбеддингтер мен фильтрлерді өзгертпеңіз. Әйтпесе дәл реранкер не бергенін ажырата алмайсыз.

1. Алдымен реранкерсіз базаны өлшеңіз. recall@k-ті, жұмыс топта дұрыс құжаты бар сұраулар үлесін, орташа кідірісті және p95-ті белгілеңіз. Бөлек 1000 сұрауға шаққандағы бағаны есептеңіз.
2. Сосын реранкерді қосып, басқа ештеңені өзгертпей, сол сұраулар жиынын қайта өткізіңіз. Тіпті промптты не chunk өлшемін сәл өзгерту салыстыруды бұзады.
3. Кандидаттар тізімінің бірнеше өлшемін тексеріңіз, әдетте 20, 50 және 100. 20-да реранкердің құтқаратындай ештеңесі болмауы мүмкін. 100-де recall өседі, бірақ баға мен кідіріс әлдеқайда тез ұлғаяды.
4. Сапа өсімін ақшаға аударыңыз. Егер жұмыс топ-3-тегі recall 4 пайыздық пунктке өссе, ал бұл 1000 сұрауда 30 қолмен тексеруді азайтса, оны бір тексерудің құнына көбейтіңіз. Оған қате іздеу салдарынан болатын қате жауаптың, қайта өтініштің немесе өтінім жоғалтудың бағасын да қосыңыз.
5. Осы ұтысты артық қадамның өз шығынымен салыстырыңыз. Шығынға реранкерді шақыру, CPU немесе GPU-ға түсетін қосымша жүк және кідірістің құны кіреді. Ішкі іздеу үшін қосымша 150 мс қалыпты болуы мүмкін, ал онлайн чатта дәл сол 150 мс SLA мен конверсияға соққы береді.

Тек recall өсімін емес, бір пункт өсімнің бағасын да есептеу пайдалы. Мысалы, 0,78-ден 0,82-ге өту тез ақталады, ал 0,82-ден 0,83-ке өту тым қымбат болуы мүмкін. Екі кезеңді іздеуде бұл кәдімгі жағдай.

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

Қолдау қызметіндегі мысал

Қолдау қызметінде реранкердің пайдасы даулы сұрауларда жақсы көрінеді. Клиент былай жазады: Мен тауарды бонус пен карта арқылы ішінара төледім. Қайтаруды қалай рәсімдеймін? Сұрақ қысқа, бірақ ішінде маңызды ерекшелік бар: төлемнің бір бөлігі басқа схема арқылы өткен болса, қайтарудың жалпы тәртібі жарамайды.

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

Дегенмен керек үзінді көбіне мүлде жоғалмайды. Ол top-50-дің бір жерінде жатады, бірақ тым төмен. Себебі қарапайым: онда жиі қолданылатын сөздер аз, ал сирек детальдар көп. Екі кезеңді іздеуде реранкер сұрақты толық оқып, сол үзіндіні top-3-ке көтереді. Оператор үшін айырмашылық өте нақты: бірнеше ұқсас құжатты шолудың қажеті жоқ, жауап бірден көрінеді.

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

Ал дерлік лезде жауап беретін чатта дәл сол қадам кедергі болады. Егер өнім 300-500 мс ішінде реакция беремін деп уәде етсе, жақсы реранкердің өзі уақыт бюджетінің тым үлкен бөлігін жеп қояды. Recall мен кідіріс бір-бірімен тартыса бастайды: бот дәлірек жауап береді, бірақ пайдаланушы паузаны сезіп, жауапты баяу деп қабылдайды.

Сондықтан тек ранжирлеу жақсарды ма, соған емес, сценарийге қараған дұрыс. Оператор интерфейсі үшін мұндай қадам көбіне ақталады. Жылдам чатта оны тек екіұшты немесе сирек сұрақтарда, базалық іздеу жиірек қателесетін кезде ғана қосқан дұрыс.

Қай кезде реранкер тек баға мен кідірісті өсіреді

Реранкер әдепкіде қажет емес. Егер бірінші іздеу онсыз да керек құжатты жиі алдыңғы орындарға шығарып жүрсе, екінші қадам көп нәрсені өзгертпейді. Ол тек тағы бір модель шақыруын, 100-400 мс кідірісті және әр сұрауға қосымша ақшаны қосады.

Мұны көбіне шағын әрі таза базаларда көруге болады. Құжаттар жинағы жинақы болса, дубльдер алынса, атаулар түсінікті болса және метадеректер толтырылған болса, жақсы іздеу жұмыстың басым бөлігін онсыз да атқарады. Мұндай базада реранкер көбіне top-ті жылтыратады, бірақ нәтижені құтқармайды.

Жаман белгі - кандидаттар тізімінің тым ұзақ болуы. Команда top-100 немесе top-200 алып, оны реранкерге береді де, сапа айтарлықтай өседі деп күтеді. Іс жүзінде керек құжат онсыз да top-5-та болған, ал қалған құйрық тек кідіріс пен шығынды үлкейтеді. Егер жұмыс top-3 немесе top-5-тегі өсім дерлік қозғалмаса, бұл қадам ақталмайды.

Продукт жағынан да бір нәрсе бар. Әр іздеуде құжаттардың мінсіз реті қажет емес. Кей сценарийлерде пайдаланушы сападан гөрі жылдамдықты жоғары қояды. Егер адам қысқа анықтама, ішкі регламент немесе форма нөмірін іздеп отырса, 0,7 секундтағы жауап 1,8 секундтағы сәл дәлірек жауаптан жақсырақ болуы мүмкін.

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

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

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

Командалар тестте қай жерде қателеседі

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

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

Тағы бір жиі қате - әртүрлі кандидаттар тізімімен реранкерлерді салыстыру. Мұны істеуге болмайды. Егер бірінші кезең бір тестте бір құжаттар жиынын, ал екіншісінде басқа жиынды тапса, сіз реранкердің өзінен бөлек нәрсені де салыстырып отырсыз. Әуелі бірдей кандидаттар тізімін бекітіңіз, содан кейін тек реттіліктің қалай өзгеретінін тексеріңіз. Кандидаттарды іздеу мен қайта ранжирлеуді бөлек эксперименттерде бағалаған дұрыс.

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

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

Сондықтан тексеруді екі қабатқа бөлген дұрыс. Әуелі іздеудің өзін өлшеңіз: recall@k, керек құжаттың орны және промах үлесі. Сосын сол сұраулар бойынша соңғы жауапты бөлек өлшеңіз. Екі қабат үшін де тек орташа мәнге емес, p95 кідірісіне қарау пайдалы, ал бағаны бір сәтті мысалға емес, 1000 сұрауға шақтап есептеу керек.

Соңғы тұзақ іске қосқаннан кейін көрінеді. Тестте команда кеш, batching және кезекті есептемейді, ал жұмыс жүйесінде басқа кідіріс алады. Бір реранкер тыныш сағатта 40 мс қосса, пик кезінде сұраулар өз кезегін күтіп 250 мс қоса алады. Егер сіз жалпы LLM-шлюз немесе shared GPU арқылы жұмыс істесеңіз, бұл әсіресе байқалады. Тек осындай сынақтан кейін ғана бұл қадам шынымен пайда әкеліп тұр ма, әлде іздеуді қымбат әрі баяу етіп тұр ма - соны түсінесіз.

Іске қоспас бұрынғы жылдам тексеріс

Реранкерді сезімге қарап емес, өз деректеріңіздегі қысқа тексерістен кейін қосқан дұрыс. Егер сізде дұрыс жауабы белгілі нақты сұраулар жиыны болмаса, кез келген қорытынды кездейсоқ болуы мүмкін. Алғашқы прогонға 100-300 сұрау жетеді, егер олар жарты сағатта қолдан құрастырылған емес, тірі трафиктен алынған болса.

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

Іске қоспас бұрын бес нәрсені тексеру жеткілікті:

1. Нақты құжаттары немесе дұрыс жауаптары бар сұраулар жиынын жинаңыз. Онда қысқа, ұзын, көмескі және шынымен қиын сұраулар болғаны жақсы.
2. Бір сұрауға арналған кідіріс шегін бекітіңіз. Ішкі іздеу үшін бір сан, қолдау чаты немесе кассалық сценарий үшін мүлде басқа сан болады.
3. Тек реранкердің бағасын емес, бүкіл тізбектің толық құнын есептеңіз. Есепке іздеу, реранкер, генерация және қайталама шақырулар, егер олар болса, кіреді.
4. Кандидаттар тізімінің кемінде 2-3 өлшемін өткізіңіз. Мысалы, top-20, top-50 және top-100.
5. Нәтижені сұрау түрлері бойынша бөліңіз. Реранкер көбіне контексті бар ұзын сұрақтарда жақсы, ал қарапайым навигациялық сұрауларда дерлік пайдасыз жұмыс істейді.

Кішкентай мысал. Команда қолдау базасы бойынша іздеуді тесттеп, орташа recall@10-дағы 4% өсімді көреді. Жаман емес сияқты. Бірақ бөлек қарағанда, ұтыстың басым бөлігі сирек әрі көпсөзді сұрақтарға тиесілі екені анықталады, ал парольді қалпына келтіру сияқты жиі сұрауларда реранкер ештеңені өзгертпейді. Мұндайда оны бәріне бірдей емес, қарапайым маршрутизация ережесімен ғана қосқан дұрыс.

Егер бірнеше реранкер мен модельді AI Router сияқты бір OpenAI-үйлесімді шлюз арқылы airouter.kz ішінде салыстырсаңыз, мұндай тестті таза ұстау оңайырақ. Маршрутты не модельді SDK-ны, кодты және промпттарды қайта жазбай-ақ ауыстыруға болады, әрі ұтыс дәл реранкерден келді ме, әлде пайплайнның басқа бөлігінен бе - соны оңайырақ көресіз.

Осыдан кейін шешімдер әдетте тынышталады. Не қадам нақты сценарийлерде ақталады, не сіз оны адал түрде алып тастап, артық миллисекундтар үшін төлемейсіз.

Әрі қарай не істеу керек

Реранкерді әдепкіде бірінші қадам ретінде қоспаңыз. Алдымен базаны тексеріңіз: құжаттарды chunk-тарға қалай бөлесіз, әр фрагментке қандай метадерек бересіз және алғашқы іздеуде қандай top-k аласыз. Көбіне осы кезеңнің өзінде-ақ recall өседі, ал кідіріс дерлік өзгермейді.

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

Жақсы тәжірибе - трафикті екі сценарийге бөлу. Қарапайым сұрауларға кәдімгі іздеуді қалдыру. Күрделі сұрауларға қысқа ереже арқылы екі кезеңді іздеуді қосу: ұзын сұрау, дәл сәйкестік аз, ұқсас бөліктер көп, жауап қатесінің қаупі жоғары.

Толық іске қоспас бұрын тірі ағынға тест қажет. Қолайлысы - shadow run, яғни жаңа схема нәтижені қатар есептейді, бірақ пайдаланушыға әсер етпейді. Трафик жеткілікті болса, A/B-тест жасаңыз және тек орташа метрикаға емес, кідіріс құйрығына, 1000 сұрауға шаққандағы бағаға және реранкердің жұмыс топты шын өзгертетін жағдайлар үлесіне қараңыз.

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

Мұндай кесте тез-ақ шындыққа жақындатады. Егер реранкер күрделі кейстерде recall-ды 6-8% көтеріп, трафиктің бір бөлігіне ғана 150 мс қосса, оны қалдыру керек. Егер ол метриканы біршама ғана өсіріп, іздеуді айтарлықтай баяулатып әрі қымбаттатса, ол қадамды алып тастап, chunk, фильтрлер және top-k-ке ақша салған дұрыс.