Semantic cache-ը կրճատում է հարցումները, բայց նման իմաստը նույն պատասխանը չէ

Semantic cache-ը կարող է կրճատել LLM-ին ուղղվող կանչերն ու պատասխանի սպասման ժամանակը՝ իմաստով մոտ հարցման համար պահված պատասխանը վերադարձնելով։ GPT Semantic Cache-ի փորձերում պատվերի և առաքման հարցումների խմբում API կանչերը կրճատվել են 68.8%-ով, իսկ խմբերի positive hit rate-ը կազմել է 92.5–97.3%. աշխատանքի ամփոփագիրը նշում է 97%-ից բարձր ցուցանիշ, բայց մանրամասն աղյուսակում որոշ խմբեր այդ սահմանից ցածր են։ Այդ արդյունքները նկարագրում են փորձի հարցումներն ու գնահատման եղանակը, ոչ թե ցանկացած ծառայության համար պատրաստի խնայողության չափ։

Քեշից պատասխանը վերադարձնելու պայմանը միայն հարցումների նմանությունը չէ։ Նոր հարցման օգտատերը, պահանջվող տվյալների տարբերակը և պատասխանի թարմությունը նույնպես պետք է համապատասխանեն պահված գրառմանը։ Նմանության շեմն ընտրելիս պետք է համեմատել նոր LLM կանչի արժեքը սխալ համընկնման հավանականության ու հետևանքի հետ, իսկ որոշ հարցումների համար քեշն ընդհանրապես շրջանցել։

Ինչ են ցույց տալիս hit rate-ը և positive hit rate-ը

Hit rate-ը հարցումների այն բաժինն է, որի համար համակարգը քեշում համընկնում է գտել և նոր պատասխան չի գեներացրել։ Այն ցույց է տալիս, թե որքան հաճախ է հնարավոր խուսափել LLM կանչից։ Positive hit rate-ը այդ վերադարձների մեջ պիտանի համարված պատասխանների բաժինն է։ Առաջին ցուցանիշը կարող է բարձրանալ, երբ շեմն իջեցվում է, մինչդեռ երկրորդը կարող է վատանալ, եթե քեշն սկսի ընդունել իմաստով մոտ, բայց տարբեր պատասխան պահանջող հարցումներ։

Երկու չափումների հայտարարը տարբեր է. քեշի հիթերի բաժինը հաշվվում է բոլոր հարցումներից, իսկ դրական հիթերի բաժինը՝ միայն քեշից պատասխան ստացածներից։ Դրա համար հիթերի բարձր բաժինը չի հավասարվում նույնքան մեծ ճշտության, ինչպես նաև API կանչերի կրճատումը ինքնաբերաբար նույն չափով չի կրճատում ամբողջ ծախսը։ Հարցման վեկտորային ներկայացումը ստեղծելը, քեշում որոնելը և հնարավոր լրացուցիչ ստուգումն էլ ունեն արժեք ու տևողություն։

Հրապարակված փորձի պիտանիության գնահատականը ստացվել է մոդելային դատավորից, որն ուսումնասիրել է նոր ու պահված հարցումների համարժեքությունը և վերադարձված պատասխանի ճշտությունը։ Դա օգտակար փորձնական չափում է, սակայն արտադրական միջավայրում հարկավոր է առանձին հաշվել իրական սխալ վերադարձները՝ հատկապես այն խմբերում, որտեղ պատասխանը կախված է անձից կամ գործող տվյալներից։ Օրինակ՝ նույն «Որտե՞ղ է իմ պատվերը» հարցումը կարող է տալ բարձր տեքստային նմանություն և միաժամանակ վերաբերել տարբեր պատվերների։

Ինչպես ընտրել նմանության շեմը

Շեմը կարգավորում է խնայված կանչերի և սխալ համընկնումների փոխզիջումը։ Բարձր շեմով համակարգը ավելի քիչ պահված պատասխան է ընդունում, ուստի ավելի հաճախ է դիմում LLM-ին։ Ցածր շեմը կարող է մեծացնել հիթերի բաժինը, բայց նաև ընդունել հարցումներ, որոնց տարբերությունը գտնվում է գործողության, ժխտման կամ ժամանակի մեջ։ Համընդհանուր թիվ վերցնելու փոխարեն շեմը պետք է որոշել տվյալ ծառայության հարցումներով։

Microsoft Research-ի համահեղինակությամբ աշխատանքը քեշից վերադարձը դիտարկում է թարմ LLM պատասխանի արժեքի և անհամապատասխան պահված պատասխանի սպասվող վնասի համեմատությամբ։ Գործնական շեմի համար սա նշանակում է չափել ոչ միայն նմանության միավորը, այլև սխալվելու գինը հարցումների յուրաքանչյուր խմբում։ Ընդհանուր տերմինի ոչ լիովին հարմար բացատրությունը կարելի է ուղղել հաջորդ հարցմամբ, մինչդեռ ուրիշ մարդու պատվերի կարգավիճակը վերադարձնելը խախտում է պատասխանի հասցեականությունը։

Գնահատման հավաքածուում պետք են և՛ նույն պատասխանն ընդունող տարբեր ձևակերպումներ, և՛ մոլորեցնող զույգեր, որոնց բառերը նման են, բայց ճիշտ պատասխանները՝ տարբեր։ Առանձին ընդգրկեք «կարո՞ղ եմ» ու «ինչպե՞ս», ներկա ու նախկին վիճակը, տարբեր երկրները, լեզուները և իրավասության սահմանները։ Յուրաքանչյուր փորձվող շեմի համար հաշվեք հիթերի բաժինը, սխալ վերադարձների բաժինը, ընդհանուր արժեքն ու սպասման ժամանակը։ Եթե սխալի հետևանքը ծանր է, տվյալ խմբի համար նույնիսկ շատ բարձր նմանության միավորը կարող է անբավարար լինել։

Որ հարցումն ընդունել, որը՝ շրջանցել

Հետևյալները պայմանական օրինակներ են։ Որոշումը կախված է ոչ միայն հարցման ձևակերպումից, այլև նրանից, թե ինչ տեղեկության հիման վրա է կազմվել պահված պատասխանը։

• Ընդունել՝ կայուն բացատրություն։ «Ի՞նչ է semantic cache-ը» և «Ինչպե՞ս է աշխատում իմաստային քեշավորումը» հարցերը կարող են ստանալ նույն պատասխանը, եթե պահանջվող լեզուն, մանրամասնության աստիճանն ու համատեքստը համընկնում են։ Այդ դեպքում ձևակերպման տարբերությունը պատասխանի բովանդակությունը չի փոխում։
• Ընդունել պայմանով՝ ընդհանուր ընթացակարգ։ Ապրանքի վերադարձի կանոնների մասին երկու հարց կարող են կիսել պատասխանը, եթե վերաբերում են նույն երկրի, վաճառողի և կանոնների տարբերակի։ Նույն թեման բավարար չէ, երբ այդ պայմաններից մեկը փոխվել է։
• Մեկուսացնել՝ անձնական տվյալ։ «Որտե՞ղ է իմ պատվերը» նույն նախադասությունն է տարբեր գնորդների համար, բայց պատասխանն առանձնահատուկ է յուրաքանչյուր պատվերի համար։ Ընդհանուր քեշում հարցման նմանությամբ որոնումը չպետք է հատի օգտատերերի մուտքի սահմանը։
• Նոր պատասխան ստանալ՝ փոխվող վիճակ։ «Հասանելի՞ է ապրանքը» կամ «Կարո՞ղ եմ չեղարկել վճարումը» հարցերի պատասխանը կարող է կախված լինել տվյալ պահի մնացորդից կամ գործարքի վիճակից։ Նախորդ պատասխանի լեզվական համապատասխանությունը այդ տեղեկությունը չի թարմացնում։
• Տարբերակել մտադրությունը։ «Կարո՞ղ եմ չեղարկել վճարումը» հարցը կարող է պահանջել կոնկրետ գործարքի ստուգում, իսկ «Ինչպե՞ս չեղարկել վճարումը»՝ ընդհանուր ընթացակարգ։ Միայն ընդհանուր թեման համընկնում է. անհրաժեշտ գործողությունը՝ ոչ։

Թարմությունը և օգտատիրոջ սահմանը

TTL-ը՝ քեշի գրառման պահպանման ժամկետը, պետք է բխի պատասխանի հիմքում ընկած տվյալների փոփոխության արագությունից։ Կայուն սահմանման համար կարելի է ընտրել ավելի երկար ժամկետ, իսկ հաճախ փոփոխվող պայմանների համար՝ կարճ։ Երբ քաղաքականությունը, փաստաթուղթը կամ ապրանքի տվյալը փոխվում է մինչև ժամկետի ավարտը, համապատասխան գրառումը պետք է անվավեր դարձնել այդ փոփոխության պահին։ TTL-ի լրանալուն սպասելը հին պատասխանը հասանելի է թողնում։

Մինչև նմանության հաշվարկը նպատակահարմար է սահմանափակել որոնման տիրույթը։ Օգտատիրոջ կամ կազմակերպության ինքնությունը, մուտքի իրավունքը, լեզուն, աղբյուրի տարբերակը և պահանջվող ձևաչափը կարող են որոշել՝ արդյոք պահված պատասխանը վերօգտագործելի է։ Դրանք կարելի է ներառել քեշի բանալում կամ պարտադիր զտիչներում։ Վեկտորային նմանությունը չի կարող փոխարինել իրավասության ստուգմանը, իսկ անհայտ համատեքստի դեպքում անվտանգ ընտրությունը նոր, թույլատրված աղբյուրներով պատասխան ստանալն է։

Շեմի և հնացման կարճ ստուգաթերթ

Շեմի նախնական ընտրությունը պետք է ստուգել պատմական կամ ընտրված հարցումներով, ապա հետևել սխալ վերադարձներին իրական աշխատանքի ընթացքում։ LangSmith-ի գնահատման ուղեցույցը տարբերակում է նախնական գնահատումը ընտրված օրինակներով և ընթացիկ գնահատումը արտադրական հարցումների վրա։ Այդ բաժանումը հատկապես օգտակար է, երբ իրական օգտատերերի ձևակերպումները տարբերվում են փորձնական հավաքածուից։

1. Յուրաքանչյուր հարցումների խմբի համար սահմանեք, թե երբ են երկու հարցեր պահանջում նույն պատասխանը և ում կարելի է այդ պատասխանը վերադարձնել։
2. Փորձարկեք մի քանի շեմ իրական համարժեք ու մոլորեցնող զույգերով։ Ընտրությունը կատարեք սխալ վերադարձների ընդունելի սահմանի, ընդհանուր արժեքի և սպասման ժամանակի համադրությամբ։
3. Սահմանեք TTL՝ ըստ տվյալների փոփոխության արագության, և առանձին ազդակ՝ աղբյուրի նոր տարբերակից հետո հին գրառումները անվավեր դարձնելու համար։
4. Անձնական կամ արագ փոփոխվող տվյալների համար ամրագրեք քեշը շրջանցելու կանոն։ Գործարկումից հետո սխալ վերադարձները ավելացրեք գնահատման հավաքածուին և դրանց հիման վրա վերանայեք շեմը կամ զտիչները։

Կարդացեք նաև:

• C2PA պիտակը ցույց է տալիս ծագումը, բայց չի ապացուցում բովանդակության ճշմարտությունը
• Prompt cache-ը խնայում է մինչև 80%, եթե գործիքները չեն կոտրում prefix-ը
• GitHub Actions թե GitLab CI․ մեկ րոպեն երկու հարթակում նույն արժեքը չունի