Ինչպես ավելացնել AI գործառույթներ ձեր հավելվածին

Հավելվածին AI գործառույթներ ավելացնելու համար կանչեք մեծ լեզվական մոդելի (LLM) API-ը ձեր սերվերից՝ ուղարկելով հստակ հրահանգներ և համապատասխան տվյալներ, և օգտագործեք ստացված արդյունքը։ Օգտակար գործառույթների մեծ մասը հետևյալ չորս օրինաչափություններից մեկն է՝ ամփոփում, չաթ, կառուցվածքային տվյալների արդյունահանում և դասակարգում։ Յուրաքանչյուրը մի քանի տասնյակ տողով կոդ է, որ AI կառուցիչը կարող է գրել ձեզ համար։ Այն, ինչ որոշում է գործառույթի որակը, գտնվում է կանչի շրջակայքում․ API բանալին սերվերի վրա պահելը, յուրաքանչյուր օգտատիրոջ ծախսերի վերահսկումը և արդյունքի ստուգումը նախքան վստահելը։

Չորս օրինաչափությունները, որոնց վրա հիմնված են AI գործառույթների մեծ մասը

Արդյունահանումը և դասակարգումը հաճախ ամենաթանկարժեքն են և ամենաքիչ նկատելին։ Դրանք անտեսանելիորեն խնայում են մարդու մի քանի րոպե յուրաքանչյուր գրառման վրա, և քանի որ արդյունքը ֆիքսված ձև ունի, այն կարելի է ավտոմատ ստուգել։ Չաթը ամենաերևացողն է, բայց ամենադժվարն է ճիշտ անելը, և դրա համար առանձին ուղեցույց կա՝ ինչպես կառուցել AI չաթբոտ հավելված։

Ինչպես է այն տեղավորվում ձեր հավելվածում

Բոլոր օրինաչափություններն ունեն նույն կառուցվածքը.

1. Օգտատերը գործում է՝ սեղմում է «Ամփոփել», վերբեռնում է ֆայլ, ուղարկում է հաղորդագրություն։
2. Ձեր frontend-ը կանչում է ձեր սերվերը, ոչ թե AI մատակարարին։
3. Ձեր սերվերը կազմում է հարցումը․ համակարգային հրահանգներ, օգտատիրոջ մուտքը և այն տվյալները, որոնք մոդելին պետք են ձեր տվյալների բազայից՝ միայն այն տվյալները, որ այս օգտատերը իրավունք ունի տեսնել։
4. Ձեր սերվերը կանչում է LLM API-ը միջավայրի փոփոխականում պահվող բանալիով։
5. Ձեր սերվերը ստուգում է պատասխանը՝ վավեր JSON, հայտնի պիտակ, ողջամիտ երկարություն, և այն պահում կամ վերադարձնում է։
6. Frontend-ը ցուցադրում է այն, երկար պատասխանների դեպքում տեքստը հոսքով՝ երբ այն ժամանում է։

4-րդ քայլում բանալին գտնվում է սերվերի վրա և երբեք չի հասնում բրաուզեր։ Եթե API հասկացությունը նոր է, ինչ է API-ն կարճ ներածություն է, իսկ ինչպես օգտագործել LLM API-ները-ը ավելի խորն է բացատրում թոքենները, մոդելները և բանալիները։

Մատակարարի և մոդելի ընտրություն

Մեծ մատակարարները՝ OpenAI, Anthropic, Google և այլք, բոլորն էլ առաջարկում են տեքստային API-ներ՝ մոտավորապես նման կառուցվածքով։ Ընտրելիս օգտակար հարցեր են.

• Որակը ձեր առաջադրանքի վրա։ Փորձեք ձեր հավելվածի մի քանի իրական օրինակ երկու-երեք մոդելի վրա։ Տարբերությունները հաճախ ավելի պարզ են ձեր տվյալների վրա, քան ընդհանուր չափանիշներում։
• Չափ կամ արժեք։ Մատակարարները առաջարկում են ավելի մեծ, ավելի ունակ մոդելներ և ավելի փոքր, էժան, արագ մոդելներ։ Դասակարգումը և պարզ արդյունահանումը հաճախ լավ են աշխատում փոքր մոդելով, մինչդեռ երկար տրամաբանությունը կամ նրբին գրությունը կարող է պահանջել մեծը։
• Կառուցվածքային արդյունք։ Արդյունահանման և դասակարգման համար նախընտրեք API-ի գործառույթը, որը ստիպում է մոդելին վերադարձնել JSON՝ ձեր տրամադրած սխեմային համապատասխան, այլ ոչ թե ազատ տեքստ վերլուծել։
• Տվյալների մշակում։ Կարդացեք մատակարարի պայմանները՝ արդյոք API մուտքերը պահվում են կամ օգտագործվում մոդելների ուսուցման համար, և արդյոք դա համապատասխանում է այն տվյալներին, որ օգտատերերը ձեզ են տալիս։
• Սահմանաչափեր։ Նոր հաշիվները հաճախ ունեն ցածր հարցումների սահմանաչափեր․ ստուգեք դրանք մինչև գործարկումը։

Մոդելների անուններն ու գները հաճախ են փոխվում, ուստի կոդը պետք է մոդելի անունը կարդա կոնֆիգուրացիայից, այլ ոչ թե կոշտ գրի այն շատ տեղերում։

Գործառույթի ավելացում, քայլ առ քայլ

Դիտարկենք կոնկրետ օրինակ՝ փոքր CRM, որտեղ յուրաքանչյուր կոնտակտ ունի երկար նշումների պատմություն։

1. Պահեք բանալին։ Ստեղծեք բանալի մատակարարի վահանակում և պահեք այն որպես սերվերային գաղտնիք, օրինակ՝ OPENAI_API_KEY կամ ANTHROPIC_API_KEY։

2. Խնդրեք մեկ նեղ գործառույթ։

Ավելացրու «Ամփոփել» կոճակ կոնտակտի էջին։ Սերվերի վրա ուղարկիր կոնտակտի վերջին 20 նշումները [PROVIDER]-ին՝ օգտագործելով [ENV_NAME] գաղտնիքը, հրահանգներով՝ գրել երեք կետ․ ընթացիկ կարգավիճակ, բաց հարցեր, հաջորդ քայլ։ Ներառիր միայն այն նշումները, որոնք մուտք գործած օգտատերը կարող է տեսնել։ Ցույց տուր բեռնման վիճակ, պահիր ամփոփումը ժամանակի նշումով և ցույց տուր «Չհաջողվեց ամփոփել հիմա», եթե կանչը ձախողվի։ Բանալին երբեք մի ուղարկիր բրաուզեր։

3. Ավելացրու արդյունահանում, որտեղ խնայում է մուտքագրումը։

Երբ օգտատերը տեքստային դաշտում տեղադրում է էլ․ փոստի ստորագրությունը «Արագ ավելացում» դաշտում, կանչիր [PROVIDER]-ին սերվերից և վերադարձրու JSON՝ name, company, job title, email և phone դաշտերով՝ մատակարարի կառուցվածքային արդյունքի գործառույթի միջոցով։ Ստուգիր JSON-ը սերվերի վրա, լրացրու նոր կոնտակտի ձևը դրանով և թույլ տուր օգտատիրոջը խմբագրել նախքան պահելը։ Դաշտերը թողեք դատարկ, այլ ոչ թե գուշակեք։

«Թույլ տուր օգտատիրոջը խմբագրել նախքան պահելը» ամենակարևոր մասն է․ մոդելը առաջարկում է, մարդը որոշում է։

4. Դասակարգեք ֆոնային ռեժիմում։

Երբ նոր աջակցության տոմս է մտնում, դասակարգիր այն ճիշտ մեկ կատեգորիայի մեջ՝ billing, bug, feature request, account access, other։ Օգտագործիր փոքր, էժան մոդել։ Եթե պատասխանը այս պիտակներից չէ, պահիր «other»։ Ցույց տուր պիտակը որպես խմբագրելի նշան։

5. Փորձարկեք իրական, անկանոն տվյալներով — երկար նշումներ, դատարկ նշումներ, այլ լեզուներ, ստորագրություն առանց հեռախոսահամարի — և նախքան թողարկելը համեմատեք քսան արդյունք կողք կողքի։

Հրահանգներ, որոնք աշխատում են

Հրահանգները, որ ուղարկում եք յուրաքանչյուր հարցման հետ (հաճախ կոչվում են system prompt), որակի աղբյուրն են։

• Ասեք, թե ում համար է և ինչն է լավ։ «Ամփոփումները վաճառողը կարդում է 10 վայրկյանում զանգից առաջ» մոդելին տալիս է թիրախ։
• Ֆիքսեք ձևաչափը։ Կետերի ճշգրիտ քանակ, երկարության սահման, դաշտեր, պիտակներ։
• Ասեք, թե ինչ անել, երբ անորոշ է։ «Եթե նշումները հաջորդ քայլի մասին չեն խոսում, գրիր՝ «Հաջորդ քայլը չի գրանցվել»։» Սա նվազեցնում է հորինված պատասխանները։
• Տվեք երկու-երեք օրինակ լավ մուտքի և արդյունքի համար արդյունահանման և դասակարգման դեպքում։
• Պահեք հրահանգները առանձին օգտատիրոջ բովանդակությունից և հստակ պիտակավորեք օգտատիրոջ բովանդակությունը, որպեսզի մոդելը կարողանա դրանք տարբերել։

Պահեք հուշումները կոդի բազայի ֆայլերում, որպեսզի դրանք տարբերակվեն և ստուգելի լինեն ինչպես ցանկացած այլ կոդ։

Ծախսերի վերահսկում

LLM API-ները վճարում են թոքենների համար՝ տեքստի փոքր կտորների, և՛ ուղարկվածի, և՛ վերադարձվածի համար։ Ծախսը աճում է՝ հարցումում եղած համատեքստի քանակը բազմապատկած այն հաճախականությամբ, որով այն աշխատում է։ Գործնական վերահսկումներ.

• Ուղարկեք միայն անհրաժեշտը։ Վերջին 20 նշումները, ոչ թե ամբողջ պատմությունը։ Կրճատեք երկար փաստաթղթերը կամ բաժանեք դրանք։
• Օգտագործեք այն ամենափոքր մոդելը, որը կատարում է աշխատանքը։ Նախ փորձարկեք, ապա միայն լռելյայն ընտրեք ամենամեծը։
• Սահմանափակեք արդյունքի երկարությունը API-ի առավելագույն թոքենների կարգավորումով։
• Քեշավորեք արդյունքները։ Պահեք ամփոփումը և նորից գեներացրեք միայն աղբյուրը փոխվելիս, այլ ոչ թե յուրաքանչյուր էջի դիտումից։
• Սահմանափակեք յուրաքանչյուր օգտատիրոջ համար։ Օրական սահման յուրաքանչյուր հաշվի կամ պլանի համար կանգնեցնում է մեկ ծանր օգտատիրոջը կամ մեկ սկրիպտը մեծ վճար կուտակելուց։
• Սահմանափակեք endpoint-ը ինչպես ցանկացած թանկ երթուղի։
• Սահմանեք բյուջե կամ ծանուցում մատակարարի վահանակում և ստուգեք օգտագործումը շաբաթական՝ գործարկումից հետո։
• Գրանցեք թոքենների օգտագործումը յուրաքանչյուր գործառույթի համար, որ իմանաք, թե որ մեկն ինչքան է արժում։

Եթե AI գործառույթները ձեր արտադրանքի կենտրոնում են, ներառեք դրանց աշխատանքային արժեքը ձեր գնագոյացման մեջ, այլ ոչ թե կլանեք այն։

Անվտանգությունն ու վստահությունը

AI արդյունքը հավանականային է։ Այն կարող է սխալ լինել, բայց հնչել վստահ, և կարող է ուղղորդվել այն տեքստով, որը կարդում է։ Կառուցեք դրան համապատասխան.

• Արդյունքը համարեք անվստահելի մուտք։ Ստուգեք կառուցվածքը, փախչեցրեք HTML-ի մեջ ցուցադրելուց առաջ և երբեք մի գործարկեք որպես կոդ կամ տվյալների բազայի հարցում։
• Պահեք մարդուն գործընթացի մեջ այն ամենի համար, որը հետևանքներ ունի՝ էլ․ նամակ ուղարկել, գրառում փոխել, գումար վերադարձնել։ Մոդելը նախագիծ է գրում, մարդը հաստատում է։
• Պաշտպանվեք prompt injection-ից։ Փաստաթուղթը կամ հաղորդագրությունը կարող է պարունակել տեքստ, օրինակ՝ «անտեսիր քո հրահանգները»։ Սահմանափակեք այն, ինչ մոդելը կարող է տեսնել, դեպի այն, ինչ ընթացիկ օգտատերը կարող է տեսնել, և մի տվեք դրան գործիքներ, որոնք կարող են զգայուն գործողություններ կատարել առանց ձեր կոդի թույլտվության ստուգման։
• Նշեք AI բովանդակությունը, որ օգտատերերը իմանան, որ ամփոփումը կամ առաջարկը գեներացվել է, և կարողանան ստուգել այն։
• Մշակեք ձախողումները սահուն։ Մատակարարները ունենում են խափանումներ և սահմանաչափեր։ Սահմանեք ժամանակի սահման, ցույց տվեք հստակ հաղորդագրություն և թույլ տվեք, որ հավելվածի մնացած մասը շարունակի աշխատել։
• Հետևեք, թե ինչ են ուղարկում օգտատերերը։ Բաց տեքստային մուտքերի համար մտածեք մոդերացիայի քայլի մասին և գաղտնիության քաղաքականության մեջ հստակ նշեք, որ բովանդակությունը մշակվում է երրորդ կողմի AI մատակարարի կողմից։

Ավելի լայն ստուգումների ցանկը կա անվտանգության ստուգաթերթում AI-ով կառուցված հավելվածների համար։

Սովորական սխալներ

• Սկսել ընդհանուր չաթբոտից, երբ մեկ «Ամփոփել» կամ «Դասակարգել» կոճակը ավելի շատ մարդու կօգներ։
• Բանալին դնել frontend կոդում կամ հանրային repository-ում։
• Ամբողջ տվյալների բազան ուղարկել որպես համատեքստ, ինչը դանդաղ է, թանկ և վտանգ է ուրիշ օգտատերերի տվյալների արտահոսքի համար։
• Վստահել ազատ տեքստով արդյունքին, երբ սխեման կամ ֆիքսված պիտակների հավաքածուն այն կարող էր ստուգելի դարձնել։
• Առանց օգտատիրոջ սահմանաչափերի, որոնք պարզվում են առաջին հաշիվը ստանալուց հետո։

AI գործառույթների ավելացումը Mythex-ում

Mythex-ում AI-ը ձեր սեփական հավելվածի ներսում ավելացնում եք չաթում հարցնելով՝ օգտագործելով ձեր սեփական մատակարարի բանալին։ Պահեք բանալին որպես նախագծի գաղտնիք․ երբ գործակալին այն պետք է, Mythex-ը չաթում ցույց է տալիս գաղտնիքների քարտ, որ բանալին չտեղադրեք զրույցում։ Գործակալը գրում է սերվերային երթուղին, հուշումները և միջերեսը։ Ձեր հավելվածի AI օգտագործումը վճարվում է ձեր մատակարարի կողմից, առանձին այն Mythex կրեդիտներից, որոնք ծախսում եք կառուցելու համար։ Փաստաթղթերում կա սկզբնական հուշում AI գործառույթներ ավելացնել ձեր սեփական API բանալիներով բաժնում։

Հարցեր