Ինչպես կառուցել AI չաթբոտի հավելված. բանալիներ, prompt-ներ, ծախսեր և անվտանգություն
AI չաթբոտի հավելված կառուցելու համար հարկավոր են չորս բան՝ չաթի ինտերֆեյս, փոքր սերվեր, որը պահում է մոդելի մատակարարի API բանալին և փոխանցում հաղորդագրությունները, համակարգային հրահանգ, որը մոդելին ասում է, թե ով է և ինչ կարող է անել, և սահմաններ, որոնք պահում են ծախսերն ու չարաշահումը վերահսկելի։ AI հավելվածների կառուցող գործիքը կարող է ամբողջը գրել նկարագրությունից։ Ձեր մասը մատակարարի ընտրությունն է, հրահանգների գրելը և այն, ինչ բոտը երբեք չպետք է անի։
Ինչից է բաղկացած AI չաթբոտի հավելվածը
Չաթբոտների մեծ մասը՝ լինի դա աջակցության օգնական, դասախոս, թե ներքին «հարցրու մեր փաստաթղթերից» գործիքը, ունի նույն մասերը.
| Մաս | Ինչ է անում | Կարելի՞ է բաց թողնել |
|---|---|---|
| Չաթի UI | Հաղորդագրությունների ցուցակ, մուտքի դաշտ, «մտածում է» վիճակ, հոսքային պատասխաններ | Ոչ |
| Սերվերային երթուղի | Ընդունում է օգտատիրոջ հաղորդագրությունը, ավելացնում համակարգային հրահանգը և կանչում մատակարարին ձեր գաղտնի բանալիով | Ոչ, բանալին երբեք չպետք է հասնի բրաուզեր |
| Համակարգային հրահանգ | Մշտական կանոններ՝ դեր, տոն, շրջանակ, ինչից հրաժարվել | Ոչ |
| Գիտելիք | Ձեր սեփական բովանդակությունը, որից բոտը պատասխանում է (FAQ, քաղաքականություններ, արտադրանքի փաստաթղթեր) | Այո, ընդհանուր օգնականի համար |
| Զրույցների պահպանում | Պահում է թելերը տվյալների բազայում, որպեսզի օգտատերերը կարողանան վերադառնալ | Այո, առաջին տարբերակի համար |
| Հաշիվներ | Թույլ է տալիս յուրաքանչյուր օգտատիրոջը տեսնել միայն իր պատմությունը և սահմանափակել օգտագործումը անձի համար | Այո, սահմանափակումներով հանրային ցուցադրության համար |
| Սահմաններ և գրանցում | Հաղորդագրության երկարության սահմաններ, արագության սահմանափակումներ, ծախսերի սահման, սխալների գրանցում | Ոչ |
Սերվերային երթուղին այն մասն է, որը մարդիկ ամենից հաճախ սխալ են անում։ Եթե չաթի էջը մատակարարին կանչում է անմիջապես բրաուզերից, ցանկացած մարդ կարող է բացել զարգացողի գործիքները, պատճենել ձեր բանալին և սպառել ձեր բյուջեն։
Որոշումներ, որոնք պետք է կայացնել կառուցելուց առաջ
Որ մատակարարը և մոդելը
Հիմնական մատակարարները (OpenAI, Anthropic, Google և ուրիշներ) բոլորն էլ առաջարկում են չաթի տիպի API, որը նույն կերպ է աշխատում․ ուղարկում եք հաղորդագրությունների ցուցակ և ստանում եք պատասխան։ Գործնական ընտրությունը ավելի շատ կախված է մոդելի չափից, քան ապրանքանիշից.
- Ավելի փոքր, արագ մոդելները ավելի էժան են և արագ են պատասխանում։ Դրանք լավ են կարճ պատասխանների, դասակարգման և պարզ FAQ բոտերի համար։
- Ավելի մեծ մոդելները ավելի լավ են մտածում, ավելի հուսալիորեն հետևում են երկար հրահանգներին և բարդ հարցերին, բայց մեկ հաղորդագրության համար ավելի թանկ են և ավելի դանդաղ են պատասխանում։
Սկսեք միջին չափի մոդելից, փորձեք այն ձեր իրական հարցերի վրա և հետո բարձրացրեք կամ իջեցրեք։ Եթե նոր եք այս API-ների գնագոյացման և կանչման հետ, նախ կարդացեք ինչպես օգտագործել LLM API-ները։
Որտեղից է գալիս բոտի գիտելիքը
| Ձեր բովանդակությունը | Մոտեցում |
|---|---|
| Մեկ-երկու էջ (աշխատանքային ժամեր, վերադարձի քաղաքականություն, գներ) | Դրեք ուղղակիորեն համակարգային հրահանգի մեջ |
| Տասնյակ էջեր, որոնք հազվադեպ են փոխվում | Դրեք դրա կրճատ տարբերակը հրահանգի մեջ կամ բաժանեք ըստ թեմայի և ներառեք համապատասխան բաժինը |
| Հարյուրավոր փաստաթղթեր կամ ամեն օր փոփոխվող բովանդակություն | Պահեք, որոնեք յուրաքանչյուր հարցին համապատասխան հատվածները և ուղարկեք միայն դրանք (RAG) |
Սկսեք ամենապարզ տարբերակից, որը ծածկում է ձեր բովանդակությունը։ Retrieval-ը ավելացնում է որոնման ինդեքս, դրա թարմացման եղանակ և ավելի շատ տեղեր, որտեղ պատասխանները կարող են սխալվել։ Շատ օգտակար բոտերի երբեք դրա կարիքը չի լինում։
Հանրային, թե մուտքով
Հանրային չաթբոտը, որը գտնվում է ձեր կայքում, հասանելի է, բայց նաև հեշտ է չարաշահել․ ինչ-որ մեկը սցենարով հազարավոր հաղորդագրություններ կարող է ուղարկել։ Մուտքով չաթբոտը թույլ է տալիս պահել պատմությունը յուրաքանչյուր օգտատիրոջ համար և սահմանել օրական քվոտա յուրաքանչյուր հաշվի համար։ Եթե այն հանրային է, սահմանափակեք հաղորդագրության երկարությունը, սահմանեք, թե մեկ այցելուն որքան հաղորդագրություն կարող է ուղարկել որոշ ժամանակահատվածում, և դրեք ամսական կոշտ սահման մատակարարի վահանակում։ Ինչպես ավելացնել մուտք ձեր հավելվածին-ը ընդգրկում է հաշիվների մասը։
Պահե՞լ զրույցները
Պահված թելերը օգտակար են․ օգտատերերը կարող են շարունակել այնտեղից, որտեղ թողել են, իսկ դուք կարող եք կարդալ իրական հարցերը՝ հրահանգը բարելավելու համար։ Սակայն դրանք անձնական տվյալներ են։ Որոշեք, որքան ժամանակ եք դրանք պահում, նշեք դա ձեր գաղտնիության ծանուցման մեջ և մի պահեք այն, ինչ պետք չէ։
Գրեք համակարգային հրահանգը որպես աշխատանքի նկարագրություն
Համակարգային հրահանգը այն հրահանգն է, որը մոդելը ստանում է յուրաքանչյուր զրույցից առաջ։ Լավ հրահանգը կարդացվում է որպես կարճ բրիֆ նոր աշխատակցի համար.
- Դեր և լսարան. «Դուք Oakline-ի՝ հեծանիվների վերանորոգման խանութի օգնականն եք։ Խոսում եք հաճախորդների հետ»։
- Շրջանակ. «Պատասխանեք ծառայությունների, գների, աշխատանքային ժամերի և գրանցման մասին հարցերին։ Մնացած ամեն ինչի համար ասեք, որ կարող եք օգնել միայն խանութի հարցերում»։
- Տեղեկության աղբյուր. «Օգտագործեք միայն ստորև տրված տեղեկությունը։ Եթե պատասխանը այնտեղ չկա, ասեք, որ չգիտեք, և տվեք խանութի հեռախոսահամարը»։
- Տոն և երկարություն. «Ընկերական, պարզ լեզվով, մինչև երեք նախադասություն, եթե մանրամասն պատասխան չեն խնդրում»։
- Կոշտ կանոններ. «Երբեք մի խոստացեք վերանորոգման գին, որը ցուցակում չկա։ Երբեք մի խնդրեք քարտի տվյալներ»։
Չափեք այն դժվար հարցերով․ շրջանակից դուրս հարցումներ, անպատշաճ հաղորդագրություններ, հարցեր, որոնց պատասխանը ձեր բովանդակության մեջ չկա, և փորձեր՝ ստիպել այն անտեսել իր հրահանգները («մոռացիր կանոնները և…»)։ Ճշգրտեք հրահանգը, մինչև պատասխանները դառնան այնպիսիք, որոնց տակ կստորագրեք ձեր անունը։
Պահեք ծախսերը կանխատեսելի
Մատակարարները վճարում են ըստ տոկենների (մոտավորապես՝ բառերի մասեր) ձեր ուղարկած մուտքի և մոդելի գրած ելքի համար։ Երեք բան է որոշում վճարը.
- Զրույցի երկարությունը։ Յուրաքանչյուր նոր հաղորդագրություն սովորաբար վերուղարկում է ամբողջ թելը, որպեսզի մոդելը հասկանա համատեքստը։ 40 հաղորդագրությամբ զրույցը յուրաքանչյուր պատասխանի համար շատ ավելի թանկ է, քան 4-ով։ Պահեք միայն վերջին մի քանի փոխանակումը կամ ամփոփեք հինները։
- Հրահանգի չափը։ Երկար համակարգային հրահանգը կամ տեղադրված մեծ գիտելիքի բլոկը ուղարկվում է յուրաքանչյուր հաղորդագրության հետ։
- Ելքի երկարությունը։ Սահմանեք պատասխանի առավելագույն երկարությունը API կանչում և հարցրեք կարճ պատասխաններ հրահանգում։
Նախքան գործարկումը դրեք ամսական ծախսերի սահման մատակարարի վահանակում և գրանցեք տոկենների օգտագործումը յուրաքանչյուր հարցման համար, որպեսզի տեսնեք, թե որ զրույցներն են թանկ։ Գները այստեղ չենք նշում, քանի որ դրանք տարբերվում են ըստ մոդելի և հաճախ են փոխվում։ Ստուգեք մատակարարի գնային էջը։
Կառուցեք քայլ առ քայլ
Քայլ 1. Նկարագրեք բոտը, ոչ թե կոդը
Առաջին prompt-ը, որը նշում է լսարանը, շրջանակը, տվյալները և անվտանգության կանոնները, արդեն հասցնում է մեծ մասին.
Կառուցիր հաճախորդների աջակցության չաթբոտ Oakline-ի համար՝ հեծանիվների վերանորոգման խանութի։ Չաթի էջ՝ հաղորդագրությունների ցուցակով և մուտքի դաշտով, պատասխանները հոսքով՝ երբ գրվում են։ Anthropic API-ը կանչիր սերվերային երթուղուց՝ գաղտնի ANTHROPIC_API_KEY-ով, երբեք չբացահայտելով այն բրաուզերին։ Համակարգային հրահանգ, որը պատասխանում է միայն ծառայությունների, գների և ժամերի մասին shop-info.md ֆայլից, իսկ հակառակ դեպքում ասում է «Վստահ չեմ, զանգահարեք ստորև նշված համարով»։ Սահմանափակիր հաղորդագրությունները 500 նիշով և յուրաքանչյուր այցելուի համար՝ 20 հաղորդագրություն ժամում։ Մաքուր, ընկերական դիզայն, որը աշխատում է հեռախոսներում։
Քայլ 2. Ավելացրեք բանալին որպես գաղտնիք
Ստեղծեք բանալին մատակարարի կոնսոլում, ապա պահեք այն նախագծի միջավայրի փոփոխականներում կամ գաղտնիքներում, ոչ թե չաթում և ոչ կոդում։ Եթե բանալին երբևէ հայտնվի որևէ հանրային տեղում, չեղարկեք այն մատակարարի մոտ և ստեղծեք նորը։ Ինչ են միջավայրի փոփոխականներն ու գաղտնիքները-ը բացատրում է, թե ինչու է սա կարևոր։
Քայլ 3. Փորձարկեք պատասխանները, ոչ միայն ինտերֆեյսը
Երբ չաթը աշխատի, ամենաշատ ժամանակը ծախսեք պատասխանների որակի վրա։ Պահեք մոտ 20 իրական հարցի ցուցակ, ներառյալ մի քանիսը, որոնք պետք է մերժվեն, և յուրաքանչյուր prompt-ի փոփոխությունից հետո անցեք դրանց միջով։ Ստուգեք.
- Մնո՞ւմ է արդյոք շրջանակում։
- Խոստովանո՞ւմ է արդյոք, երբ չգիտի, այլ ոչ թե հորինում է պատասխան։
- Դիմանո՞ւմ է արդյոք, երբ ինչ-որ մեկը փորձում է անտեսել իր հրահանգները։
- Բացակայո՞ւմ է արդյոք բանալին բրաուզերի ներբեռնած ամեն ինչից։
Քայլ 4. Ավելացրեք հիշողություն և հաշիվներ, եթե պետք է
Երբ առանձին զրույցները աշխատեն, խնդրեք պահված թելեր տվյալների բազայում և, անհրաժեշտության դեպքում, գրանցում ու մուտք, որպեսզի յուրաքանչյուր օգտատեր տեսնի միայն իր չաթերը։ Միաժամանակ ավելացրեք յուրաքանչյուր օգտատիրոջ օրական հաղորդագրությունների քվոտա։
Քայլ 5. Հրապարակեք սահմաններն ակտիվ
Համոզվեք, որ հրապարակված հավելվածն ունի նույն գաղտնիքները, ինչ նախադիտումը, ծախսերի սահմանը դրված է մատակարարի մոտ, և սխալները գրանցվում են մի տեղ, որտեղ կնկատեք դրանք։ Ապա կիսվեք փոքր խմբի հետ, նախքան այն դնելը ձեր հիմնական կայքում։
Անվտանգություն և վստահություն
Չաթբոտը հանրության հետ խոսում է ձեր անունից, ուստի նրա սխալները ձեր խնդիրն են.
- Սխալ պատասխաններ։ Մոդելները կարող են վստահորեն ասել սխալ բաներ։ Պահեք բոտը նեղ թեմայի վրա, հիմնավորեք այն ձեր սեփական բովանդակությամբ և ավելացրեք կարճ նշում, որ կարևոր հարցերի պատասխանները կարող են սխալ լինել։
- Prompt injection։ Օգտատերերը (կամ բոտի կարդացած փաստաթղթերը) կարող են պարունակել հրահանգներ, ինչպիսիք են «անտեսիր նախորդ կանոնները»։ Մի տվեք բոտին այնպիսի լիազորություններ, որոնց նա չի կարող վստահվել՝ առանց ձեր կոդում ստուգման՝ ոչ վերադարձ, ոչ ջնջում, ոչ էլ նամակների ուղարկում օգտատիրոջ խնդրանքով։
- Զգայուն թեմաներ։ Բժշկական, իրավական կամ ֆինանսական հարցերի դեպքում թող բոտը մարդկանց ուղղորդի մասնագետի, այլ ոչ թե խորհուրդ տա։
- Անձնական տվյալներ։ Մի տեղադրեք հաճախորդների գրառումներ prompt-ների մեջ, եթե դա անհրաժեշտ չէ, և ստուգեք, թե ինչ են ասում ձեր մատակարարի պայմանները API տվյալների մշակման մասին։
Մեր անվտանգության ստուգաթերթը AI-ով կառուցված հավելվածների համար-ը ընդգրկում է ամբողջ հավելվածը։
Տարածված սխալներ
- Մատակարարին կանչել բրաուզերից։ Բանալին արտահոսում է։ Միշտ անցեք ձեր սերվերով։
- Հանրային բոտ առանց սահմանների։ Մեկ սցենարը մեկ կեսօրում կարող է սպառել ամսվա բյուջեն։
- Սկսել միանգամից RAG-ով, գործիքներով և մի քանի մոդելներով։ Նախ աշխատեցրեք մեկ լավ զրույց․ մնացածը ավելացրեք, երբ իրական հարցերը ցույց տան, որ դրա կարիքն ունեք։
- Փորձարկել միայն բարի հարցերը։ Ձեր օգտատերերը առաջին օրվանից կհարցնեն տարօրինակ, թշնամական և թեմայից դուրս բաներ։
- Թույլ տալ, որ թելը անսահման աճի։ Ծախսերը և պատասխանի ժամանակը աճում են յուրաքանչյուր հաղորդագրության հետ։
Երբ պատրաստի արտադրանքը ավելի լավ ընտրություն է
Սեփական կառուցումն իմաստ ունի, երբ չաթբոտը ձեր արտադրանքի մաս է, պետք է աշխատի ձեր սեփական տվյալների կամ աշխատանքային հոսքի հետ, կամ պետք է հատուկ տեսք և վարք։ Հաճախ սխալ ընտրություն է, երբ.
- Ձեզ միայն կայքի վրա աջակցության վիջեթ է պետք։ Շատ օգնության սպասարկման կամ կենդանի չաթի արտադրանքներ արդեն ներառում են AI պատասխանող բոտ, որը կարդում է ձեր օգնության կենտրոնը, և ունեն մարդու միջամտության, մուտքի արկղի և հաշվետվությունների հնարավորություն։
- Միայն դուք կամ ձեր թիմը կօգտագործեք այն։ Ընդհանուր օգնականի բաժանորդագրությունը, օրինակ՝ ChatGPT կամ Claude, ձեր փաստաթղթերը վերբեռնած, կարող է բավարար լինել։
- Ձեզ անհրաժեշտ են խիստ համապատասխանության երաշխիքներ (օրինակ՝ կարգավորվող առողջական կամ ֆինանսական տվյալներ)։ Մատակարարը, որն արդեն ունի անհրաժեշտ հավաստագրերը, կարող է ավելի անվտանգ լինել, քան հատուկ կառուցումը։
Կառուցել Mythex-ով
Mythex-ը AI հավելվածների կառուցող գործիք է․ դուք նկարագրում եք չաթբոտը զրույցում, և այն գրում է ինտերֆեյսը և սերվերային կանչը, աշխատեցնում է կենդանի նախադիտման մեջ և հրապարակում հանրային URL-ով։ Ձեր հավելվածի ներսի AI-ն օգտագործում է ձեր սեփական մատակարարի բանալին։ Այն ավելացնում եք նախագծի գաղտնիքներում կամ Mythex-ի զրույցում երևացող գաղտնիքների քարտի միջոցով, երբ այն պահանջվում է, և մատակարարի օգտագործումը վճարվում է ձեր մատակարարի հաշվին, ոչ թե Mythex-ի կառուցման կրեդիտներով։ Mythex-ը չի ներառում տոկեններ ձեր հավելվածի օգտատերերի համար, գիտելիքի բազայի արտադրանք կամ պատրաստի արագության սահմաններ․ դրանք այն մասերն են, որոնք դուք խնդրում և փորձարկում եք։ Ձեր հավելվածում AI ավելացնելու ձեռնարկը քայլ առ քայլ անցնում է դրա միջով, իսկ ավելացրեք AI ձեր սեփական API բանալիներով-ում կա սկզբնական prompt։
Եթե բոտին պետք են պահված թելեր, Mythex-ը նախագծին կցում է Postgres տվյալների բազա, երբ խնդրում եք։ Հավելվածների ներսում մոդելներ օգտագործելու ավելի շատ եղանակների համար՝ ամփոփումներից մինչև դասակարգում, տե՛ս ինչպես ավելացնել AI հնարավորություններ ձեր հավելվածին, կամ նայեք հավելվածների կաղապարները՝ սկզբնակետ ստանալու համար։
Հարցեր
Պետք է ինձ սեփական API բանալի՝ AI չաթբոտի հավելված կառուցելու համար:
Գրեթե միշտ՝ այո։ Չաթբոտը յուրաքանչյուր հաղորդագրություն ուղարկում է մոդելի մատակարարին, օրինակ՝ OpenAI, Anthropic կամ Google, իսկ մատակարարը վճարում է այն հաշվին, որին պատկանում է API բանալին։ Բանալին պետք է գտնվի ձեր սերվերում, երբեք՝ վեբ էջում։
Որքա՞ն է AI չաթբոտի աշխատեցման արժեքը:
Մատակարարները վճարում են ըստ տոկենների՝ և՛ ուղարկված, և՛ մոդելի վերադարձրած տեքստի համար, իսկ գները մոդելների միջև զգալիորեն տարբերվում են։ Քանի որ յուրաքանչյուր նոր հաղորդագրության ժամանակ սովորաբար ուղարկվում է ամբողջ զրույցը, երկար զրույցները մեկ հաղորդագրության համար ավելի թանկ են, քան կարճերը։ Ստուգեք մատակարարի գնային էջը և դրեք ծախսերի սահման նրա վահանակում։
Կարո՞ղ եմ չաթբոտը վերապատրաստել իմ սեփական փաստաթղթերով:
Սովորաբար մոդելն ինքը չեք վերապատրաստում։ Փոքր քանակությամբ բովանդակության համար այն տեղադրում եք համակարգային հրահանգի մեջ․ մեծ գրադարանի համար այն պահում եք, յուրաքանչյուր հարցի համար որոնում եք համապատասխան հատվածները և մոդելին ուղարկում միայն դրանք։ Այս երկրորդ մոտեցումը կոչվում է retrieval-augmented generation, կամ RAG։
Կարո՞ղ եմ AI չաթբոտ կառուցել առանց ծրագրավորման:
Այո։ AI հավելվածների կառուցող գործիքը պարզ նկարագրությունից կարող է գրել չաթի ինտերֆեյսը, սերվերային երթուղին, որը կանչում է մոդելը, և զրույցների պահպանման տվյալների բազան։ Մատակարարի հաշիվը և API բանալին դուք պետք է ստեղծեք ինքներդ։