Si të shtoni veçori me AI në aplikacionin tuaj

Për të shtuar veçori me AI te aplikacioni juaj, thirrni një API të modelit të madh gjuhësor (LLM) nga serveri juaj: i dërgoni udhëzime të qarta plus të dhënat përkatëse, dhe përdorni atë që kthehet. Shumica e veçorive të dobishme bien në një nga katër modelet — përmbledhje, chat, nxjerrje të dhënash strukturuara dhe klasifikim — dhe secila është disa dhjetëra rreshta kodi që një ndërtues me AI mund ta shkruajë për ju. Puna që vendos nëse veçoria është e mirë është rreth thirrjes: mbajtja e çelësit API në server, kontrolli i kostos për përdorues dhe kontrolli i daljes përpara se t'i besoni.

Katër modelet pas shumicës së veçorive me AI

Nxjerrja dhe klasifikimi shpesh janë më të vlefshmet dhe më pak të dukshmet. Kursejnë pa zhurmë disa minuta për çdo regjistrim, dhe meqenëse dalja ka një formë fikse, mund ta kontrolloni automatikisht. Chat është më i dukshmi, por më i vështiri për ta bërë mirë, dhe ka udhëzuesin e vet: si të ndërtoni një aplikacion chatbot me AI.

Si përshtatet në aplikacionin tuaj

Çdo model ka të njëjtën formë:

1. Përdoruesi vepron — klikon "Përmblidh", ngarkon një skedar, dërgon një mesazh.
2. Frontend-i juaj thërret serverin tuaj, jo ofruesin e AI.
3. Serveri juaj ndërton kërkesën: udhëzimet e sistemit, hyrjen e përdoruesit dhe çdo të dhënë që modeli ka nevojë nga baza juaj — vetëm të dhëna që ky përdorues lejohet t'i shohë.
4. Serveri juaj thërret API-n LLM me një çelës të ruajtur në një variabël mjedisi.
5. Serveri juaj kontrollon përgjigjen — JSON i vlefshëm, një etiketë e njohur, një gjatësi e arsyeshme — dhe e ruan ose e kthen.
6. Frontend-i e shfaq, duke e transmetuar tekstin ndërsa mbërrin për përgjigje më të gjata.

Çelësi qëndron në server te hapi 4 dhe nuk arrin kurrë te shfletuesi. Nëse ideja e një API-je është e re, çfarë është një API është një hyrje e shkurtër, dhe si të përdorni API-t LLM shpjegon token-at, modelet dhe çelësat më thellë.

Zgjedhja e ofruesit dhe modelit

Ofruesit kryesorë — OpenAI, Anthropic, Google dhe të tjerë — ofrojnë API-t e tekstit me forma mjaft të ngjashme. Pyetje të dobishme gjatë zgjedhjes:

• Cilësia për detyrën tuaj. Provoni disa shembuj të vërtetë nga aplikacioni juaj në dy ose tre modele. Dallimet shpesh duken më qartë te të dhënat tuaja sesa te testet e përgjithshme.
• Madhësia kundrejt kostos. Ofruesit ofrojnë modele më të mëdha dhe më të aftë, dhe modele më të vogla, më të lira dhe më të shpejta. Klasifikimi dhe nxjerrja e thjeshtë shpesh funksionojnë mirë me një model të vogël; arsyetimi i gjatë ose shkrimi i nuancuar mund të kërkojë një të madh.
• Dalja e strukturuar. Për nxjerrjen dhe klasifikimin, preferoni një veçori API-je që e bën modelin të kthejë JSON që përputhet me një skemë që i jepni, në vend që të analizoni tekst të lirë.
• Trajtimi i të dhënave. Lexoni kushtet e ofruesit për atë nëse hyrjet e API-t ruhen ose përdoren për trajnim, dhe nëse kjo i përshtatet të dhënave që ju japin përdoruesit.
• Limitet. Llogaritë e reja shpesh kanë limite më të ulëta kërkesash; kontrolloni ato përpara lançimit.

Emrat e modeleve dhe çmimet ndryshojnë shpesh, prandaj kodi duhet ta lexojë emrin e modelit nga konfigurimi, në vend që ta fiksojë në shumë vende.

Shtimi i një veçorie, hap pas hapi

Merrni një shembull konkret: një CRM i vogël ku çdo kontakt ka një histori të gjatë shënimesh.

1. Ruajeni çelësin. Krijoni një çelës në panelin e ofruesit dhe ruajeni si sekret të anës së serverit, për shembull OPENAI_API_KEY ose ANTHROPIC_API_KEY.

2. Kërkoni një veçori të ngushtë:

Shto një buton "Përmblidh" te faqja e kontaktit. Në server, dërgo 20 shënimet e fundit të kontaktit te [PROVIDER], duke përdorur sekretin [ENV_NAME], me udhëzime për të shkruar tre pika: statusi aktual, pyetjet e hapura, hapi tjetër. Përfshi vetëm shënimet që përdoruesi i kyçur mund t'i shohë. Shfaq një gjendje ngarkimi, ruaje përmbledhjen me një kohë, dhe shfaq "Nuk u arrit të përmblidhet tani" nëse thirrja dështon. Kurrë mos e dërgo çelësin te shfletuesi.

3. Shto nxjerrje aty ku kursen shkrim:

Kur një përdorues ngjit një nënshkrim emaili te kutia "Shtim i shpejtë", thirr [PROVIDER] në server dhe kthe JSON me emrin, kompaninë, titullin e punës, email-in dhe telefonin, duke përdorur veçorinë e daljes së strukturuar të ofruesit. Valido JSON-in në server, plotëso formularin e ri të kontaktit me të dhënat dhe lëre përdoruesin t'i ndryshojë para ruajtjes. Lër fushat bosh në vend që të supozosh.

"Lëre përdoruesin t'i ndryshojë para ruajtjes" është pjesa e rëndësishme: modeli propozon, personi vendos.

4. Klasifiko në sfond:

Kur të arrijë një kërkesë e re mbështetjeje, klasifikoje në saktësisht një nga: faturim, gabim, kërkesë veçorie, qasje në llogari, tjetër. Përdor një model të vogël me kosto të ulët. Nëse përgjigjja nuk është një nga këto etiketa, ruaj "tjetër". Shfaq etiketën si një tag që mund të redaktohet.

5. Testoni me të dhëna reale e të rrëmujshme — shënime të gjata, shënime bosh, gjuhë të tjera, një nënshkrim pa numër telefoni — dhe shikoni njëzet dalje njëra pranë tjetrës para se të publikoni.

Shkrimi i udhëzimeve që funksionojnë

Udhëzimet që dërgoni me çdo kërkesë (shpesh të quajtura system prompt) janë aty ku vjen cilësia.

• Thoni për kë është dhe si duket e mirë. "Përmbledhjet i lexon një shitës në 10 sekonda para një thirrjeje" i jep modelit një objektiv.
• Fiksoni formatin. Numri i saktë i pikave, limiti i gjatësisë, fushat, etiketat.
• Thoni çfarë të bëjë kur nuk është i sigurt. "Nëse shënimet nuk përmendin një hap tjetër, shkruaj 'Nuk u regjistrua hap tjetër'." Kjo zvogëlon përgjigjet e shpikura.
• Jepni dy ose tre shembuj të hyrjes dhe daljes së mirë për nxjerrjen dhe klasifikimin.
• Mbajini udhëzimet të ndara nga përmbajtja e përdoruesit, dhe etiketoni qartë përmbajtjen e përdoruesit, që modeli t'i dallojë.

Mbajini kërkesat në skedarë në bazën e kodit, që të jenë të versionuara dhe të rishikueshme si çdo kod tjetër.

Mbajtja e kostove nën kontroll

API-t LLM paguajnë sipas token-ave — copëza të vogla teksti — si për atë që dërgoni ashtu edhe për atë që kthehet. Kosto rritet me sasinë e kontekstit për kërkesë shumëzuar me sa shpesh ekzekutohet. Kontrolle praktike:

• Dërgoni vetëm atë që duhet. 20 shënimet e fundit, jo gjithë historinë. Prisni dokumentet e gjata ose ndajini ato.
• Përdorni modelin më të vogël që e bën punën. Testoni përpara se të shkoni te më i madhi.
• Kufizoni gjatësinë e daljes me cilësimin e API-t për numrin maksimal të token-ave.
• Ruani rezultatet në cache. Ruani një përmbledhje dhe rigjenerojeni vetëm kur ndryshon burimi, në vend që ta bëni në çdo shikim faqeje.
• Kufizoni për përdorues. Një tavan ditor për llogari ose plan ndalon një përdorues të rëndë, ose një skript, të ngrejë faturën.
• Kufizoni shpejtësinë e endpoint-it si çdo rrugë tjetër e shtrenjtë.
• Vendosni një buxhet ose alarm në panelin e ofruesit, dhe kontrolloni përdorimin çdo javë pas lançimit.
• Regjistroni përdorimin e token-ave për veçori, që të dini cila kushton sa.

Nëse veçoritë me AI janë qendrore për produktin tuaj, përfshijeni kostonë e tyre të funksionimit në çmimin tuaj, në vend që ta absorboni.

Siguria dhe besueshmëria

Dalja e AI është probabilistike. Mund të jetë e gabuar ndërsa tingëllon e sigurt, dhe mund të drejtohet nga teksti që lexon. Ndërtoni duke e pranuar këtë:

• Trajtoni daljen si hyrje të pabesuar. Valido strukturën, bëj escape përpara se ta shfaqësh si HTML, dhe mos e ekzekuto kurrë si kod ose pyetje në bazë të dhënash.
• Mbani një njeri në qarkullim për çdo gjë me pasoja — dërgimin e një emaili, ndryshimin e një regjistrimi, rimbursimin e një pagese. Modeli përgatit draftin; një person konfirmon.
• Mbrojuni nga prompt injection. Një dokument ose mesazh mund të përmbajë tekst si "injoro udhëzimet e tua". Kufizoni çfarë mund të shohë modeli në atë që përdoruesi aktual mund ta shohë, dhe mos i jepni mjete që mund të nisin veprime të ndjeshme pa që kodi juaj të kontrollojë së pari lejet.
• Etiketoni përmbajtjen e AI që përdoruesit ta dinë se një përmbledhje ose sugjerim u krijua dhe mund ta kontrollojnë.
• Trajtoni dështimet me kujdes. Ofruesit kanë ndërprerje dhe limite kërkesash. Caktoni afat kohe, shfaqni një mesazh të qartë dhe lejoni pjesën tjetër të aplikacionit të vazhdojë.
• Kini kujdes çfarë dërgojnë përdoruesit. Për fusha të hapura teksti, konsideroni një hap moderimi dhe jini të qartë në politikën e privatësisë që përmbajtja përpunohet nga një ofrues i jashtëm AI.

Lista më e gjerë e kontrolleve është te lista e sigurisë për aplikacionet e ndërtuara me AI.

Gabimet më të shpeshta

• Fillimi me një chatbot të përgjithshëm kur një buton i thjeshtë "Përmblidh" ose "Kategorizo" do t'i ndihmonte më shumë njerëz.
• Vendosja e çelësit në kodin e frontend-it ose në një repozitor publik.
• Dërgimi i gjithë bazës së të dhënave si kontekst, që është i ngadaltë, i shtrenjtë dhe rrezikon të ekspozojë të dhënat e përdoruesve të tjerë.
• Besimi te dalja me tekst të lirë aty ku një skemë ose një grup etiketash i fiksuar do ta bënte të kontrollueshme.
• Pa kufizime për përdorues, të zbuluara kur vjen fatura e parë.

Shtimi i veçorive me AI me Mythex

Në Mythex e shtoni AI brenda aplikacionit tuaj duke e kërkuar në chat, duke përdorur çelësin tuaj të ofruesit. Ruajeni çelësin si sekret projekti — kur agjenti ka nevojë për të, Mythex shfaq një kartelë sekretesh në chat, që të mos e ngjitni çelësin në bisedë — dhe agjenti shkruan rrugën e serverit, kërkesat dhe ndërfaqen. Përdorimi i AI të aplikacionit tuaj faturohet nga ofruesi juaj, veçmas nga kreditet Mythex që shpenzoni për ndërtim. Dokumentacioni ka një kërkesë fillestare te shtoni veçori AI me çelësat tuaj API.

Pyetje