Ժամանակակից բիզնեսը «կորցրել է գլուխը» «անվերջ կոնտեքստային պատուհանի» (infinite context window) պատճառով։ Այժմ, երբ մոդելներն ունակ են յուրացնելու իրավաբանական պայմանագրերի ամբողջական գրադարաններ, էլեկտրոնային նամակների ամիսների նամակագրություն կամ հսկայական կոդային բազաներ, ամենագետ AI գործակալի գաղափարը վերջապես թվում է իրատեսական։ Մեզ ասում են, որ այլևս կարիք չկա անհանգստանալու տեղեկատվության կրճատման կամ կորստի մասին։ Սակայն, ինչպես կհաստատի ցանկացած ինժեներ, որն աշխատում է արտադրական մասշտաբի AI-ի հետ, «անսահմանափակ» հնարավորությունների խոստումը ծնել է մի լուռ, թանկարժեք և արտադրողականությունը նվազեցնող ճգնաժամ։
Գործնականում LLM-ները ոչ միայն պայքարում են մոռացկոտության դեմ, այլև տառապում են այն ամենի «ճանաչողական ծանրաբեռնվածությունից», որը ստիպված են հիշել։ Զրույցների շարունակման և կոնտեքստային պատուհանների ընդլայնման հետ մեկտեղ՝ հուշումները (prompts) ծանրաբեռնվում են ավելորդ երկխոսություններով, ձևական ողջույններով և ցածր արժեք ունեցող մետատվյալներով։ Բիզնեսի ղեկավարի համար սա պարզապես տեխնիկական նրբություն չէ, այլ գործառնական արդյունավետության և բյուջեի ուղղակի կորուստ։
Թոքենների ծանրաբեռնվածության թաքնված հարկը
CRM (Հաճախորդների հետ հարաբերությունների կառավարում) համակարգերի և ավտոմատացված աջակցության բոտերի համար ներկայիս ճարտարապետական ստանդարտը ենթադրում է հուշումը հաճախորդի հետ շփման ողջ պատմությամբ «լցնելը»։ Թեև սա ապահովում է շարունակականություն, այն առաջացնում է երկու հիմնական խնդիր՝ «Միջնամասում կորած» (Lost in the Middle) համախտանիշը, երբ մոդելները նախապատվությունը տալիս են հուշման սկզբին և վերջին՝ անտեսելով մեջտեղում թաղված հիմնական տեղեկատվությունը, և անկառավարելի լատենտությունը (հապաղումը)։
ROI-ի (ներդրումների վերադարձելիության) տեսանկյունից սա ոչ արդյունավետ ծախս է։ API-ին ուղարկված յուրաքանչյուր ավելորդ թոքեն ձեր բյուջեի վրա կատարված ծախս է։ Ավելին, դա ստիպում է մոդելին հաշվարկային ռեսուրսներ ծախսել «աղմուկը» ֆիլտրելու համար, ինչը վերջնական օգտագործողի համար արտահայտվում է արձագանքման դանդաղ ժամանակով։ Երբ մենք ստեղծում ենք AI գործակալներ, որոնք պետք է աշխատեն իրական ժամանակում, լատենտության յուրաքանչյուր միլիվայրկյանը հանգեցնում է օգտագործողի փորձի վատթարացմանը։
Այս խնդիրը մեղմելու համար առաջադեմ ինժեներական թիմերը անցնում են դետերմինիստական «հուշումների էտման» (prompt-pruning) ճարտարապետության։ LLM-ի ներքին ուշադրության մեխանիզմի վրա հույս դնելու փոխարեն՝ մենք պետք է ներդնենք նախնական մշակման շերտ, որը գործում է որպես խելացի կուրատոր։
Այս էտման շերտը գործում է՝ վերլուծելով մուտքային հոսքի կառուցվածքը նախքան այն կհասնի մոդելի ինֆերենցիոն շարժիչին։ Բացահայտելով «բարձր արժեք» ունեցող իմաստային հենակետերը, ինչպիսիք են օգտագործողի հատուկ պահանջները, հիմնական նույնականացման տվյալները և վերջին գործողությունները, և հեռացնելով կրկնվող զրուցակցային «ջուրը», մենք կարող ենք հասնել մի քանի չափելի օգուտների.
- Ծախսերի օպտիմալացում. յուրաքանչյուր հարցման համար թոքենների սպառման կրճատում 30%-ից 50%-ով, ինչը ուղղակիորեն նվազեցնում է ամսական API ծախսերը։
- Լատենտության սեղմում. հուշումների ավելի կարճ երկարությունը նշանակում է առաջին թոքենի ստացման ավելի արագ ժամանակ (TTFT), ինչը ստեղծում է ավելի արագ և արձագանքող ինտերֆեյսներ։
- Ճշգրտության բարձրացում. «շեղող» տեքստը հեռացնելով՝ մենք մոդելին թույլ ենք տալիս իր ուշադրությունը կենտրոնացնել իրապես կարևոր տվյալների վրա՝ նվազեցնելով հալյուցինացիաների կամ սխալ մեկնաբանված հրահանգների հավանականությունը։
- Դետերմինիստական հուսալիություն. ի տարբերություն ստոխաստիկ ամփոփման՝ կառուցվածքային էտման շերտը երաշխավորում է, որ կարևոր տվյալները, ինչպիսիք են հաշվի ID-ները կամ անվտանգության թոքենները, երբեք պատահաբար չեն հեռացվի։
Արդյունավետ ճարտարապետություն մասշտաբայնության դարաշրջանում
Քանի որ մենք պարզ չաթ-բոտերից անցնում ենք դեպի ինքնավար գործակալներ, որոնք իրականացնում են Թվային փոխակերպման (Digital Transformation) բարդ աշխատանքային գործընթացներ, հուշումների ճարտարագիտության կարևորությունը մասշտաբով չի կարելի գերագնահատել։ Եթե ձեր AI գործակալին հանձնարարված է ամփոփել B2B վաճառքի ընթացիկ ցիկլը, նրան պետք չեն վերջին 50 «բարև» և «շնորհակալություն» փոխանակումները։ Նրան անհրաժեշտ է ընթացիկ կարգավիճակը, բարձրացված վերջին առարկությունը և սահմանված ժամանակացույցը։
Էտման շերտի որդեգրումը պահանջում է մոտեցման փոփոխություն տվյալների կառավարման հարցում։ Խոսքը տվյալների կորստի մասին չէ, այլ տվյալների հիգիենայի։ Ավանդական ծրագրային ապահովման մշակման մեջ մենք զգալի ժամանակ ենք ծախսում տվյալների բազայի հարցումներն օպտիմալացնելու համար՝ համոզվելու, որ հավելվածները մնում են արդյունավետ, երբ տվյալների ծավալը մեծանում է։ Մենք այժմ պետք է նույն խստությունը կիրառենք մեր LLM փոխազդեցությունների նկատմամբ։
Այն ընկերությունների համար, որոնք ներկայումս ներդնում են լեզվական մեծ մոդելներ մասշտաբով, որդեգրման միտումը հստակորեն շարժվում է դեպի «Lean LLM» (նիհար LLM) ռազմավարություններ։ Սա ներառում է միջին շերտի (middleware) ստեղծում, որը գտնվում է ձեր ինտերֆեյսի և ինֆերենցիոն պրովայդերի միջև։ Այս շերտն իրականացնում է երեք հիմնական գործառույթ.
- Իմաստային առաջնահերթություն. զրույցի պատմության հատվածների գնահատում՝ ըստ ընթացիկ նպատակի հետ դրանց առնչության։
- **Կառուցված
