Жақсырақ үзінділер үшін сұрауды түсінетін мәнмәтінді сығу

Кез келген жауап дәлелден басталады. Іздеу жүйесінде бұл дәлел әдетте құжаттардан келеді: бұл жауап моделіне немесе агентке мәнмәтін ретінде берілетін тақырыптар, түйіндемелер, үзінділер және фрагменттер.

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

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

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

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

Ұлғайту

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

Сондықтан жақсы үзінді үш нәрсені істеуі керек:

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

LLM шақыруы алдында маңызды емес мәнмәтінді алып тастау арқылы кідіріс пен құнды азайту.

Дәйөзексөз тұтастығын сақтау және бастапқы мәтінді өзгеріссіз қалдыру арқылы бақылау мүмкіндігін қамтамасыз ету.

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

Сұрауды түсінетін сығу ретіндегі үзінділер

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

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

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

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

Мысалы, мына сұрау мен алынған нәтижені қарастырайық:

Ұлғайту

Модельдің ықтимал шығысы жуан қаріппен жазылған сөйлемді таңдау болар еді: “In Comet, the assistant can ...”.

Біздің тәсіліміз өндірістік іздеу жүйесінде үзінділерді генерациялауға бейімделген FliCo, Provence және LooComp сияқты бұрынғы мәнмәтінді сығу жұмыстарымен бірдей жалпы идеяны ұстанады. Маңыздысы, модель біздің өңделмеген іздеу кезеңінен кейін дәлдік кезеңі ретінде жұмыс істейді. Бұрынғы Perplexity Research мақаламызда талқыланғандай, Introducing the Perplexity Search API, біз іздеу жүйелерімізді құжатша немесе үзінді деңгейінде жергілікті түрде жұмыс істейтіндей етіп құрастырамыз, бұл бізге дәлдік пен еске түсіруді жақсы теңгеруге мүмкіндік береді. Сұрауды түсінетін мәнмәтінді сығу моделін енгізу дәлдік пен еске түсірудің Парето шекарасын одан әрі сыртқа жылжытады.

Мәнмәтінді сығу моделін құру және оқыту

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

Модель архитектурасы

Біз негіз ретінде pplx-diffusion моделін қолданамыз. Бұл pplx-embed-v1 артындағы сол модель отбасы және біздің бұрынғы академиялық жұмысымыз да, Diffusion-Pretrained Dense and Contextual Embeddings, сондай-ақ өндірістік бенчмарктеріміз оның сұрау мен мәнмәтін жұптары үшін күшті екі бағытты кодтағыш екенін растайды. Бұл модель отбасының негізгі қасиеттерінің бірі — екі бағытты мәнмәтін: модель не сақталу керектігін шешпес бұрын коден әрбір токен көрсетілімі толық сұрау мен толық үміткер мәнмәтініне қатыса алады.

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

Бақылау құбыры

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

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

Содан кейін біз қайтарылған үзінділерді бастапқы мәтінмен қайта сәйкестендірдік. Күтілгендей, төрешінің көптеген шығыстары қазірдің өзінде нақты көшірмелер болды: қарапайым жолды сәйкестендіру үзінділердің 98%-ын қалпына келтірді. Тұрақты өрнекке негізделген қарапайым сәйкестендіру өтуін қосу үзіндіні қалпына келтіруді 100%-ға жеткізді. Бұл бізге токен деңгейіндегі сақтау/жою бақылауына айналдыруға болатын сенімді, түйіршіктелген үзінділерді берді.

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

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

Нақты уақыттағы кідірісті қамтамасыз ету

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

Практикалық сұрақ — сығымдау сапасы нашарлай бастамай тұрып, модель сыйымдылығын қаншалықты қауіпсіз азайтуға болатыны. Біз толық 28 қабатты pplx-diffusion backbone-ды қабаттарды қысқарту және іздеу жолына бағытталған 11 қабатты және 17 қабатты нұсқалармен салыстырамыз. Әрқайсысы үшін сығымдау шегін өзгертіп, екі шаманы өлшейміз: бір сұрау бойынша төменгі деңгейге жіберілетін контекст токендерінің орташа саны және сығымдаудан кейін сақталған пайдалы дәлелдердің үлесі.

2-сурет сапа-тиімділік шекарасын көрсетеді. Модель жоғарғы сол жаққа жылжыған кезде жақсырақ болады: көбірек пайдалы дәлелдер сақталған төменгі ағын токендері азырақ. 28 қабатты модель сапа анықтамасын қамтамасыз етеді. 11 қабатты модель модельді тым агрессивті түрде сығудың қауіптерін көрсетеді. Қысқартылған 17 қабатты модель орташа орынды алады: ол қаныққан режимде 28 қабатты модельді мұқият қадағалайды, бірақ өндірістік трафиктің көп бөлігі жұмыс істейтін қисықтың тік бөлігінде кішкентай алшақтық пайда болады.

Бұл алшақтықты жою үшін біз токен деңгейіндегі білім дистилляциясын қолданамыз. Біздің тәсіліміз әдеттегідей: біз стандартты шығынды дистилляция коэффициентімен салмақталған мұғалім моделінің болжамдары бойынша жұмсақ кросс-энтропия терминімен толықтырамыз. Бұл студент моделін тең деңгейге жеткізуге жеткілікті, бұл өндірісте дистилляцияланған 17 қабатты модельге толығымен ауысуға мүмкіндік береді. Бұл жаңа өндірістік модель 28 қабатты мұғалімге қатысты сапаның төмендеуінсіз вывод кідірісінің 35-40% төмендеуін және жиынтық GPU есептеулерінің 40-45% төмендеуін береді. Өндірістік кідіріс 20 мс-тен (p99) аз уақытты алады: жауап моделіне жіберілетін жалпы токендерді айтарлықтай азайта отырып, қызмет көрсету жолына қосуға жеткілікті түрде кішірек.

Ұлғайту

Сапа және токен тиімділігі

Мәнмәтінді сығудың тиімділігін талдау үшін біз Perplexity жүйесінің Agent API сынақ алаңы ретінде пайдаланамыз. Біз Agent API үш пресетин бағалаймыз:

Әрбір нәтижелер жиынтығы үшін токен бюджетін 1000 токенмен шектейтін «төмен» мәнмәтін пресети.

Әрбір нәтижелер жиынтығы үшін токен бюджетін 4000 токенмен шектейтін «орташа» мәнмәтін пресети.

Әрбір нәтижелер жиынтығы үшін токен бюджетін 10000 токенмен шектейтін «жоғары» мәнмәтін пресети.

Стандартты, сығу жоқ және сығу параметрлері де осы токен бюджеттерін құрметтеу үшін конфигурацияланған.

Агенттік көп қадамды іздеу (BrowseComp)

Біз алдымен BrowseComp бенчмаркіндегі агенттік көп қадамды іздеу жұмыс процесстеріне сығудың әсерін зерттейміз. Біз бұл бағалауды ашық бастапқы кодты search_evals құралын пайдалана отырып орындаймыз. Бағалау OpenAI жүйесінің канондық BrowseComp LLM judge prompt қолдана отырып, барлық жұмыс кезінде бірдей болады.

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

Ұлғайту

Сығу барлық бағыттар бойынша жаңа Парето шекарасын жеткізеді. Әрбір параметр үшін сығуды енгізу сұрау деңгейіндегі токенді пайдалануды 10%-дан 70%-ға дейін азайтады, ал дәлдіктің өсуі 4 пен 4.81 пайыздық тармақ аралығында болады. Сығуды енгізу тіпті біздің «төмен» пресетімізге токенді пайдалануды үш еседен астам азайта отырып, сығу жоқ «жоғары» пресеттен асып түсуге мүмкіндік береді.

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

SimpleQA: бір қадамды фактілік іздеу

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

Бұрынғыдай, біз канондық төреші шақыруын пайдалана отырып, тапсырма бойынша орташа жалпы токендерге қарсы дәлдікті сызамыз. 4-сурет осы бір қадамды параметрдегі ұпай-токен шекарасын көрсетеді. Әсер өлшемдері бір қадамды параметрде көбірек сығылғанымен, біз сығудың барлық пресеттер бойынша бір уақытта дәлдік пен тиімділікті жақсартатынын, осылайша жаңа Парето шекарасын енгізетінін қайтадан байқаймыз. Сығу қосылған кезде, орташа пресет әр құжат үшін орташа есеппен тек 200 токенмен 95% дәлдікке қол жеткізеді. 10 000-нан астам токен болатын орташа құжат ұзындығын ескерсек, бұл 50-ден астам сығу коэффициентіндегі шекаралық деңгейдегі өнімділікті білдіреді.

Ұлғайту

Үзінділерге не кіреді?

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

Маңызды: пайдаланушының сұрауына жауап беру үшін маңызды дәлел.

Тақырыптан тыс: қандай da басқа мақсат үшін пайдалы болуы мүмкін, бірақ қолдағы сұраққа қатысы жоқ ақпарат.

Жарнамалар: пайдаланушының сұрауына жауап беруден алаңдататын маңызды емес жарнама.

Метадеректер: құжаттың мазмұны туралы метадеректер.

UI & navigation: фронтендті көрсету және навигация элементтері.

Дубликат: бұрын қосылған ақпараттың қайталануы.

Біздің бағалауымыз өндірістік стек пен сығу өшірілген басқаша ұқсас базалық көрсеткішті салыстыра отырып, валидация жиынтығымыздағы 1000 аралас домендік сұраулар бойынша жұмыс істейді. 5-суретте көрсетілгендей, сығу сығу жоқ базалық көрсеткішке қарағанда әр үзінді үшін маңызды токендердің үлесін орташа есеппен 63%-ға арттырады. Біз UI/navigation (-58%), metadata (-46%) және ads (-43%) салаларындағы әсіресе тік төмендеулермен маңызды емес токендердің 29%-ға сәйкес төмендегенін байқаймыз. Бұл нәтижелер жоғарыда талқыланған сапа-тиімділік жақсартуларының механизмін растайды: сығу әрбір жеке үзіндінің сигнал-шу қатынасын күрт арттыру арқылы екі өлшем бойынша да өнімділікті жақсартады.

Ұлғайту

6-сурет бұл өзгерісті жеке сұрау үшін көрсетеді. «6 day old newborn milk intake per feeding» сұрауы үшін біз сығылмаған базалық және сығылған үзінділерді көрсетеміз. Сығу маңызды емес мазмұн санаттарын жояды және тек жаңа туылған нәрестеге қатысты тамақтандыру туралы ақпаратты сақтайды. Маңыздысы, сығу парақ үшін жалпы тақырыпқа сай болуы мүмкін, бірақ осы нақты нәрестеге бағытталған сұрау үшін тақырыптан тыс болатын мазмұнды сәтті жояды.

Ұлғайту

Қорытынды

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

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

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

Әдебиеттер тізімі

N. Chirkova, T. Formal, V. Nikoulina, and S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Accepted to ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, and D. Kim. LooComp: Leverage Leave-One-Out Strategy to Encoder-only Transformer for Efficient Query-Aware Context Compression, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang, and D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez, and G. Neubig. Learning to Filter Context for Retrieval-Augmented Generation, 2023. arXiv:2311.08377.

Дәйексөз

@online{perplexity2026QueryAwareContextCompressionForBetterSnippets,
  author = {{Perplexity} and Bo Wang and Hao Zhang and Ismail Gadzhiev and Kirill Priemko and Markus Krimmel and Nandor Licker and Vitalii Polshkov and Sarah Eslami and Louis Milliken and Maksim Gaiduk and Nikita Kireev and Jerry Ma},
  title = {{Query-aware context compression for better snippets}},
  date = {2026-05-14},
  url = {https://perplexity.coolkeypoint.com/hub/blog/query-aware-context-compression-for-better-snippets}
}