Large Language Models-երի (LLM) արագ ներդրումը ձեռնարկատիրական տեխնոլոգիական համակարգերում ընթացել է «արագ գործիր և փոփոխություններ արա» մտածելակերպով: Հաճախորդների սպասարկման ավտոմատացումից մինչև ծրագրային կոդի բարդ գեներացում՝ այս մոդելները դարձել են ժամանակակից թվային վերափոխման հիմնասյունը: Այնուամենայնիվ, հետազոտողների և ձեռնարկատիրական ճարտարապետների շրջանում սթափեցնող իրականություն է սկսում ձևավորվել. հենց այն ճարտարապետությունը, որն այս մոդելներին հզոր է դարձնում՝ մարդկային լեզուն հավանականային օրինաչափությունների հիման վրա մշակելու, մեկնաբանելու և ստեղծելու կարողությունը, կարող է նաև լինել նրանց անվտանգության մշտական «աքիլեսյան գարշապարը»:

Մեքենայական ուսուցման միջազգային կոնֆերանսում (ICML) վերջին քննարկումները փոխել են օրակարգը՝ «ինչպե՞ս կարկատել» (patch) այս համակարգերը հարցից դեպի «ինչպե՞ս ընդունել» հիմնարար խոցելիությունը: Վեճն այլևս ոչ թե ուսուցման բավարար տվյալների բացակայության կամ պաշտպանիչ մեխանիզմների պակասի մասին է, այլ այն, որ LLM-ների հիմնական մեխանիզմը սկզբունքորեն անհամատեղելի է տեղեկատվական անվտանգության ավանդական սահմանման հետ:

Ճարտարապետական պարադոքսը. ինչո՞ւ կարկատանները բավարար չեն

Ավանդական ծրագրային ապահովման մշակման մեջ «անվտանգությունը նախագծման փուլից» (security by design) սկզբունքը ենթադրում է դետերմինիստական ուղի: Եթե դուք ստեղծում եք մուտքագրման վավերացման դաշտ CRM համակարգի համար, կարող եք սահմանել հստակ կանոններ, որոնք կմերժեն վնասակար հարցումները: Սակայն LLM-ները գործում են բոլորովին այլ պարադիգմով: Դրանք ոչ դետերմինիստական, հավանականային շարժիչներ են, որոնք նախապատվությունը տալիս են ճկունությանն ու նրբերանգներին, այլ ոչ թե երկուական սահմանափակումների կոշտ պահպանմանը:

Այս ճարտարապետական իրողությունը ստեղծում է մշտական խոցելիություն: Քանի որ LLM-ի «գիտելիքը» անքակտելիորեն կապված է իր ամբողջ ուսուցման պատմության հիման վրա հաջորդ տոկենը կանխատեսելու կարողության հետ, գրեթե անհնար է լիովին տարանջատել անվտանգ, նպատակային ելքերը հնարավոր վնասակար, հակառակորդի կողմից ուղղորդված հուշումներից: Երբ մենք փորձում ենք «ապահովել» մոդելը այնպիսի տեխնիկաներով, ինչպիսիք են մարդկային արձագանքների հիման վրա ամրապնդվող ուսուցումը (RLHF) կամ պրոմպտ-ինժեներիան, մենք, ըստ էության, կառուցում ենք սակավաթիվ հենարաններ մի կառուցվածքի շուրջ, որն իր էությամբ հեղուկ է:

Ձեռնարկության տեսանկյունից սա նշանակում է.

  • «Ջեյլբրեք»-ի (Jailbreak) «կատու-մկնիկ» խաղը. անկախ նրանից, թե քանի անվտանգության ֆիլտր է տեղադրված, հակառակորդ դերակատարները գտնում են մոդելի հավանականային բնույթը շահագործելու և հրահանգները շրջանցելու ուղիներ:
  • Համատեքստային ներարկման ռիսկերը. քանի որ ընկերությունները LLM-ները միացնում են իրենց ներքին տվյալների բազաներին՝ ավելի խելացի AI գործակալներին սնուցելու համար, պրոմպտ-ներարկման ռիսկը՝ երբ օգտատերը ստիպում է մոդելին անտեսել իր անվտանգության պարամետրերը և բացահայտել գաղտնի տվյալներ, դառնում է էկզիստենցիալ գործառնական ռիսկ:
  • Սպասարկման բեռը. անվտանգության թիմերը հասկանում են, որ մոդելի վրա կիրառված յուրաքանչյուր «կարկատանի» դեպքում ի հայտ են գալիս նոր, չնախատեսված դեպքեր, ինչը հանգեցնում է սպասարկման բարձր ծախսերի, որոնք կարող են նվազեցնել AI նախաձեռնության ակնկալվող ROI-ը (ներդրումների եկամտաբերությունը):

Թվային վերափոխման վրա ունեցած ազդեցությունը

Բիզնեսի ղեկավարների համար այս հետազոտությունը չպետք է դիտարկվի որպես AI-ի ընդունումը դադարեցնելու ազդանշան, այլ որպես կարևոր շրջադարձային կետ՝ այս համակարգերը գնահատելու և տեղակայելու հարցում: Երբ կազմակերպությունը LLM է ներդնում իր հիմնական աշխատանքային հոսքում, այն փաստացի անցնում է «փակ համակարգի» անվտանգության մոտեցումից դեպի «հավանականային ռիսկի» մոդել:

Ձեռնարկություններում ընդունման միտումները շարժվում են դեպի այնպիսի AI գործակալներ, որոնք ունեն գործողություններ կատարելու լիազորություններ՝ օրինակ՝ էլեկտրոնային նամակներ ուղարկել, Salesforce տիպի տվյալների բազայում գրառումներ թարմացնել կամ ֆինանսական գործարքներ նախաձեռնել: Գործառույթների այս թռիչքը մեծացնում է անվտանգության մարտահրավերը: Եթե գործակալը վտանգված է, ապա վնասի շառավիղը սոսկ արտահոսած փաստաթուղթը չէ, այլ համակարգի չարտոնված մուտքը:

Այն ընկերությունները, որոնք անտեսում են այս ճարտարապետական թերությունը, ռիսկի են դիմում ընկնել «անվտանգության պարտքի» թակարդը: Եթե դուք կառուցում եք սեփական հաճախորդների սպասարկման չաթ-բոտ կամ մատակարարման շղթայի ավտոմատացված օպտիմիզատոր, ձեր ռիսկերի շրջանակում պետք է հաշվի առնեք հետևյալը.

  • Մարդու մասնակցությամբ (HITL) վավերացում. բարձր ռիսկային որոշումների համար LLM-ը երբեք չպետք է լինի վերջնական որոշում կայացնողը: Համակարգը պետք է առաջարկի, իսկ որոշումը պետք է հաստատի դետերմինիստական, կանոնների վրա հիմնված համակարգը:
  • Գաղտնի տվյալների մեկուսացում. մի վերաբերվեք ձեր LLM-ին որպես միաձույլ ուղեղի: Օգտագործեք մասնագիտացված, սահմանափակված (sandboxed) մոդելներ կոնկրետ, ցածր ռիսկային առաջադրանքների համար և համոզվեք, որ բարձր գաղտնիության տվյալները մնում են ավանդական, դետերմինիստական API վերահսկողության ներքո:
  • Կարմիր թիմերի (Red-Teaming) աշխատանքը որպես ստանդարտ ընթացակարգ (SOP). քանի որ այս մոդելները փոխում են իրենց վարքագիծը, անվտան