
RAG թե fine-tuning․ փաստերի համար վերապատրաստումը հաճախ սխալ ընտրություն է

Եթե ԱԲ համակարգը պետք է պատասխանի փոփոխվող ներքին փաստաթղթերի հիման վրա և ցույց տա փաստի աղբյուրը, սովորաբար սկսեք RAG-ից։ AWS-ի համեմատական ուղեցույցը փաստաթղթերին հղվող հարցուպատասխանի համար խորհուրդ է տալիս հենց այս մեկնակետը․ fine-tuning-ը պատասխանին աղբյուրի հղում չի տալիս, իսկ հաճախ փոխվող փաստաթղթերի դեպքում մոդելը թարմացնելը դժվարանում է։
Եթե փաստերն արդեն հասանելի են, բայց համակարգը պետք է հետևողականորեն պահպանի որոշակի ձևաչափ, ոճ կամ կատարի կրկնվող առաջադրանք, դիտարկեք fine-tuning-ը։ Երկուսի համադրությունը իմաստ ունի, երբ նույն պատասխանից պահանջվում են և՛ փաստաթղթից վերցված տեղեկություն, և՛ առանձին սովորեցված վարք։ Ընտրությունը փոխվում է նաև այն դեպքում, երբ պետք է ամփոփել ամբողջ փաստաթուղթը, կամ երբ որոնումն ու երկար համատեքստը չափազանց դանդաղ են տվյալ արտադրանքի համար։
Փաստերի տեղը՝ որոնելի հավաքածու, թե մոդելի պարամետրեր
RAG-ի դեպքում հարցման պահին որոնվում են համապատասխան հատվածները, որոնք փոխանցվում են մոդելին պատասխանը կազմելու համար։ Microsoft Foundry-ի բացատրությունը այս եղանակը կապում է մասնավոր կամ հաճախ փոխվող տվյալների հետ և նշում է աղբյուրին հղվելու հնարավորությունը։ Գիտելիքը պահվում է որոնելի փաստաթղթերում, ուստի մոդելի վերապատրաստումը պարտադիր չէ յուրաքանչյուր բովանդակային փոփոխության համար։
Սակայն «փաստաթուղթը փոխվեց» և «պատասխանը թարմացավ» նույն պահը չեն։ Նոր տարբերակը պետք է ներմուծվի ու ինդեքսավորվի, իսկ հինը՝ հեռացվի որոնման արդյունքներից կամ հստակ նշվի որպես հնացած։ Եթե նույն կանոնի տարբեր խմբագրությունները մնում են հասանելի, համակարգը կարող է ընտրել սխալը նույնիսկ այն ժամանակ, երբ յուրաքանչյուր հատված առանձին ճիշտ է արտագրված։ Աղբյուրի հղումը օգնում է գտնել պատասխանի հիմքը, բայց ինքնուրույն չի երաշխավորում դրա ճիշտ մեկնաբանությունը։
Fine-tuning-ը փոխում է մոդելի պարամետրերը ուսուցման օրինակների միջոցով։ Այն օգտակար է, երբ խնդիրը կայուն գործողություն սովորեցնելն է, օրինակ՝ մուտքը դասակարգել կամ պատասխանը սահմանված կառուցվածքով ներկայացնել։ Փոփոխվող ներքին պայմանը պարզապես հին օրինակների մեջ ներառելը այլ խնդիր է. նոր կանոնի ուժի մեջ մտնելուց հետո նախկինում սովորած պատասխանը կարող է պահպանվել, իսկ օգտատերը չի տեսնի, թե որ խմբագրությունից է վերցվել պնդումը։
Որոշման ծառ՝ ներքին փաստաթղթերով համակարգի համար
- Փաստերը փոխվո՞ւմ են։ Եթե կանոնները, ապրանքի պայմանները կամ ներքին հրահանգները պարբերաբար թարմացվում են, ընտրեք որոնելի հավաքածու և սահմանեք դրա թարմացման կարգը։ Ստուգեք, թե որքան ժամանակ է անցնում փաստաթուղթը փոխելուց մինչև նոր տարբերակով պատասխան ստանալը։ Կայուն փաստաթղթերն ինքնին fine-tuning-ի պատճառ չեն. որոշիչը նաև այն է, թե ինչ պետք է անի մոդելը դրանցով։
- Պե՞տք է ցույց տալ աղբյուրը։ Եթե օգտատերը պետք է բացի պատասխանի հիմքում ընկած հատվածը, պահպանեք փաստաթղթի նույնացուցիչը, բաժինը և տարբերակը։ Որոնումը պետք է պահպանի հասանելիության իրավունքները. համակարգը չպետք է պատասխանով բացահայտի այնպիսի հատված, որը տվյալ օգտատերը չի կարող կարդալ սկզբնական փաստաթղթում։
- Խնդիրը վարքի՞ կրկնությունն է։ Երբ ճիշտ փաստերը տրամադրված են, բայց մոդելը շարունակ խախտում է պահանջվող կառուցվածքը կամ սխալ է կատարում նույն տեսակի առաջադրանքը, նախ փորձեք հստակ հրահանգ և օրինակներ։ Fine-tuning-ը դիտարկեք, եթե այդ միջոցները բավարար չեն, իսկ թիմն ունի որակյալ մուտք–ելք օրինակներ և դրանցից առանձնացված ստուգման հավաքածու։
- Ամբողջ փաստաթո՞ւղթն է պետք։ Պայմանագրի կամ հաշվետվության ամբողջական ամփոփման համար հարցին նման մի քանի հատված վերադարձնող RAG-ը կարող է բաց թողնել բացառությունները։ Եթե ծավալը թույլ է տալիս, ամբողջ տեքստի փոխանցումը կարող է ավելի համապատասխան լինել։ Մեծ փաստաթղթի դեպքում մասերով ամփոփումը գնահատեք նաև այն հարցերով, որոնք պահանջում են տեղեկություն տարբեր բաժիններից։
- Որքա՞ն ուշացում և ենթակառուցվածք է ընդունելի։ Պատասխանի ժամանակի մեջ հաշվեք հարցման մշակումը, որոնումը և մոդելին փոխանցվող համատեքստը։ Առանձին հաշվի առեք ինդեքսի պահպանումը, փաստաթղթերի ներմուծումը և թույլտվությունների կառավարումը։ Եթե ուշացումը գերազանցում է արտադրանքի պահանջը, կրճատեք կամ վերադասավորեք փոխանցվող հատվածները և նորից չափեք որակը. արագացումը օգտակար չէ, եթե կորչում է անհրաժեշտ բացառությունը։
Երբ որոնումն է փչացնում պատասխանը
RAG-ի որակը կախված է նրանից, թե ճիշտ հատվածը հասնո՞ւմ է մոդելին։ Մասնատման անհաջող սահմանը կարող է կանոնը բաժանել դրա բացառությունից, իսկ որոնումը՝ վերադարձնել հնացած կամ միայն բառերով նման հատված։ Եթե անհրաժեշտ տեղեկությունն ընդհանրապես չկա փոխանցված համատեքստում, գեներատորի fine-tuning-ը չի վերականգնի բացակայող աղբյուրը։ Նախ պարզեք՝ ճիշտ փաստաթուղթը գտնվել է, հետո գնահատեք, թե ինչպես է մոդելը օգտագործել այն։
Սա հատկապես զգալի է աղյուսակների, հավելվածների և իրար հղվող բաժինների դեպքում։ Միայն մոտակա հատվածից կազմված պատասխանը կարող է բաց թողնել պայմանը, որը գրված է փաստաթղթի այլ մասում։ Ամբողջ փաստաթղթի ամփոփման դժվարությունն էլ այստեղ է. առանձին հարցի համար կարևոր թվացող հատվածները պարտադիր չէ, որ ընդգրկեն ընդհանուր պատկերի բոլոր էական տարրերը։ Երբ թույլատրված, արդիական աղբյուրում պատասխան չկա, համակարգը պետք է կարողանա դա նշել։
Ինչ են չափել հրապարակված համեմատությունները
Օվադիայի և գործընկերների գիտելիքի ներմուծման ուսումնասիրությունում RAG-ը գիտելիք պահանջող առաջադրանքներում գերազանցել է չվերահսկվող fine-tuning-ին թե՛ մոդելին ծանոթ, թե՛ նոր փաստերի դեպքում։ Հեղինակները նաև նկատել են, որ նոր փաստը բազմաթիվ տարբեր ձևակերպումներով ուսուցման մեջ ներկայացնելը կարող է մեղմել յուրացման դժվարությունը։ Այդ փորձը վերաբերում էր չվերահսկվող վերապատրաստմանը. այն չի չափում, թե վերահսկվող fine-tuning-ը որքան լավ է սովորեցնում պատասխանի ձևաչափ կամ այլ կրկնվող գործողություն։ Օգտագործված գիտելիքի աղբյուրները Վիքիպեդիայից էին, ուստի արդյունքը չի փոխարինում ներքին փաստաթղթերով գնահատմանը։
Լակատոսի և գործընկերների համեմատությունում պարզ RAG կառուցվածքը fine-tuned մոդելներից միջինը բարձր արդյունք է ունեցել ROUGE չափմամբ՝ 16%, BLEU-ով՝ 15%, և կոսինուսային նմանությամբ՝ 53%, մինչդեռ վերապատրաստված մոդելների METEOR արդյունքը միջինը 8% բարձր էր։ Փորձում RAG-ի համար կիրառվել է Llama-2-7B, իսկ fine-tuning-ի կողմում՝ նաև այլ մոդելներ. համեմատվել են կոնկրետ համակարգեր, ոչ թե նույն մոդելի բոլոր հնարավոր կարգավորումները։ Տվյալաշարերը ներառել են եգիպտացորենի մշակության, քաղաքային դիտարկման և COVID-19-ի գիտական նյութեր։ Հեղինակները նշել են նաև, որ RAG-ի ու fine-tuning-ի միացումը կարող է նվազեցնել արդյունքը. համադրությունը ինքնաբերաբար շահավետ չէ։
Ինչը չափել ընտրությունից առաջ
Համեմատության համար օգտագործեք նույն հարցերի հավաքածուն՝ ներառելով նորացված կանոն, հնացած տարբերակ, բացակայող պատասխան, աղբյուրների միջև հակասություն, ամբողջական ամփոփում և պահանջվող ձևաչափ։ Արդյունքը բաժանեք փուլերի։ Եթե ճիշտ հատվածը չի գտնվել, չափեք որոնման որակը։ Եթե գտնվել է, բայց պատասխանը սխալ է կամ բաց է թողնում պայմանը, չափեք վերջնական պատասխանի հիմնավորվածությունն ու ամբողջականությունը։ Microsoft Foundry-ի գնահատման բաժինը նույնպես առանձին է դիտարկում փաստաթղթի որոնումը և պատասխանի հիմնավորվածությունը։
Նույն հավաքածուով գնահատեք fine-tuning-ի տարբերակը՝ հարցնելով՝ արդյոք այն կայուն է պահում պահանջվող վարքը, ինչպես է արձագանքում փոփոխված փաստին և կարողանո՞ւմ է զերծ մնալ չհիմնավորված պնդումից։ Որակի կողքին գրանցեք պատասխանի ուշացումը, կանչերի ու որոնման ծախսը, ինդեքսի թարմացման ժամանակը և թույլտվությունների պահպանումը։ Եթե համադրությունն ավելի լավ արդյունք տա, առանձին չափեք՝ բարելավումը որոնո՞ւմն է բերել, թե՞ սովորեցված վարքը։ Այդ տարբերությունը ցույց է տալիս, թե որ բաղադրիչի վրա է արժե ծախսել հաջորդ աշխատանքը։
Առնչվող հոդվածներ


n8n թե Zapier․ պարզությունը վճարովի է, վերահսկողությունը՝ աշխատատար

ԱԲ գործակալը գործիքներ է ստանում․ ինչպես սահմանափակել վնասի շառավիղը

LangGraph թե CrewAI․ գրաֆային վերահսկո՞ւմ, թե դերային թիմ

ChatGPT Plus, Claude Pro, Google AI Pro․ ո՞ր $20 փաթեթն է շահավետ

Claude Code թե Codex․ մեկ հաղթող չկա՝ առաջադրանքն է որոշում
Բաժանորդագրվեք մեր տեղեկագրին
Ստացեք Web3-ի, ԱԲ-ի և կրիպտոյի վերջին լուրերն անմիջապես ձեր էլ. փոստին։