AI հարցազրույցի հարց 2. Ինչպես ապահովել, որ մեծ լեզվական մոդելը (LLM) հուսալիորեն կանչի գործիքները

Ինչպես ապահովել, որ մեծ լեզվական մոդելը (LLM) գործիքների կանչի ժամանակ աշխատի հուսալի և վերահսկելի, այլ ոչ թե պարզապես ապավինի հուշող բառերին՝ մոդելին «համոզելու» համար: Անհրաժեշտ է համակարգված տրամադրել բազմամակարդակ սահմանափակումների շրջանակ:

Օրինակ՝ եղանակի հարցման դեպքում, մոդելի գործիքների կանչի ժամանակ հաճախ հանդիպող երեք «հորինելու» վարքագիծ.
1. Չկանչել գործիքը, ուղղակի հորինել պատասխանը:
2. Գործիքը կանչելիս սխալ ձևաչափի պարամետրեր փոխանցել (օրինակ՝ գործիքը չի աջակցում «վաղը», բայց փոխանցում է date="վաղը"):
3. Ինքնակամ փոխել պարամետրերի ձևաչափը (օրինակ՝ ինքնուրույն «վաղը»-ն վերածել կոնկրետ ամսաթվի), նույնիսկ եթե գործիքը դա չի պահանջում:

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

Այս խնդիրը լուծելու համար անհրաժեշտ է բազմամակարդակ ինժեներական լուծում.

1. Առաջին մակարդակ. օպտիմալացնել հուշող բառերը (փափուկ սահմանափակումներ)

   • Սա սահմանափակումների համակարգի մեկնարկային կետն է, բայց ոչ վերջնական կետը:
   • Հուշող բառերը պետք է դիտարկել որպես «գործառնական պայմանագիր», որը հստակ նկարագրում է գործիքի նպատակը, յուրաքանչյուր պարամետրի տեսակը, սահմանները և թվարկում է անվավեր արժեքների օրինակներ:
   • Պետք է ավելացնել Few-shot օրինակներ՝ ցուցադրելով «ճիշտ մուտք → ճիշտ կանչ» օրինակներ, որպեսզի համատեքստային ուսուցման միջոցով ամրացվի մոդելի վարքագծի ձևը:

2. Երկրորդ մակարդակ. ներդնել JSON Schema (կոշտ սահմանափակումներ)

   • Սա առանցքային քայլ է «համոզելուց» դեպի «արգելապատնեշներ դնելը»:
   • Բնական լեզվով պարամետրերի նկարագրությունը փոխարինել մեքենայական ընթեռնելի, ստուգելի կառուցվածքային սահմանմամբ (JSON Schema): Այն կարող է խստորեն սահմանել դաշտերի տեսակները, պարտադիր լինելը, թվարկված արժեքների շրջանակը, և additionalProperties: false սահմանելով՝ արգելել մոդելին արտածել որևէ չսահմանված դաշտ:
   • Հիմնական API հարթակները աջակցում են նման կառուցվածքային ելքի սահմանափակումներ մոդելի վերծանման փուլում՝ սկզբից խուսափելով ձևաչափի խախտումներից:

3. Երրորդ մակարդակ. ստեղծել ստուգման-ուղղման-կրկնափորձի ցիկլ (կատարման ապահովում)

   • Նույնիսկ Schema-ի առկայության դեպքում, մոդելի ելքը ստանալուց հետո անհրաժեշտ է կատարել շարահյուսական և Schema-ի ստուգում:
   • Ստուգման ձախողման դեպքում պետք է նախագծել ավտոմատ մաքրման և կրկնափորձի մեխանիզմ (սահմանափակ քանակով), սխալի հաղորդագրությունը հետ ուղարկելով մոդելին՝ ելքը ուղղելու համար: Կրկնափորձերի քանակը գերազանցելուց հետո անհրաժեշտ է ունենալ իջեցման կամ մարդկային միջամտության պլան:

4. Ճարտարապետական մակարդակ. պարտականությունների տարանջատում

   • Պետք է տարանջատել որոշումը կատարումից՝ ստեղծելով եռաշերտ ճարտարապետություն.
     • Մոդելի շերտ. միայն պատասխանատու է որոշման համար (որոշել, թե որ գործիքը կանչել, ինչ պարամետրեր ստեղծել):
     • Շրջանակի շերտ. պատասխանատու է կատարման շրջանակի համար, ներառյալ Schema-ի ստուգումը, գործիքի կանչը, կրկնափորձերի մշակումը և արդյունքների ինտեգրումը: Սա ապահովում է, որ մոդելի սխալներն ուղղակիորեն չեն ազդում գործիքի անվտանգության վրա, և գործիքի փոփոխությունները հաճախակի ճշգրտումներ չեն պահանջում հուշող բառերում:
     • Գործիքի շերտ. կոնկրետ բիզնես հնարավորությունների իրականացում:
   • LangChain-ը, LlamaIndex-ը և այլ շրջանակներ հենց այսպիսի աշխատանք են կատարում:

Ընթացիկ լուծման սահմանափակումները. լավ է աշխատում պարամետրերի ձևաչափի խնդիրների դեպքում, բայց պարամետրերի իմաստաբանության ստուգումը (օրինակ՝ «Շանհայ»-ի և «Հու»-ի համարժեքությունը) դեռևս անբավարար է: Սա կլինի ապագայի ինժեներական մարտահրավեր:

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