Kuidas lisada oma rakendusse AI-funktsioonid

AI-funktsioonide lisamiseks rakendusse kutsu suure keelemudeli (LLM) API serveris: saada sellele selged juhised ja vajalikud andmed ning kasuta tagasi saadud vastust. Enamik kasulikke funktsioone kuulub ühte neljast mustrist — kokkuvõtete tegemine, vestlus, struktureeritud andmete väljavõtmine ja klassifitseerimine — ning iga neist on paarikümne rea kood, mille AI-ehitaja sulle kirjutada saab. Töö, mis otsustab, kas funktsioon on hea, on kutse ümber: API-võtme hoidmine serveris, kulude kontrollimine kasutaja kohta ja väljundi kontrollimine enne, kui sellele usaldad.

Neli mustrit, mis on enamiku AI-funktsioonide aluseks

Väljavõtmine ja klassifitseerimine on sageli kõige väärtuslikumad ja kõige vähem nähtavad. Need säästavad kellegi iga kirje juures mõne minuti, ning kuna väljund on fikseeritud kujuga, saab seda automaatselt kontrollida. Vestlus on kõige nähtavam, kuid kõige raskem õigesti teha, ning sellele on eraldi juhend: kuidas ehitada AI-vestlusrakendust.

Kuidas see sinu rakendusse sobib

Iga muster on sama kujuga:

1. Kasutaja tegutseb — klõpsab „Tee kokkuvõte“, laadib faili üles, saadab sõnumi.
2. Sinu esikiht kutsub sinu enda serverit, mitte AI-pakkujat.
3. Su server koostab päringu: süsteemijuhised, kasutaja sisend ja andmed, mida mudel vajab sinu andmebaasist — ainult andmed, mida see kasutaja tohib näha.
4. Su server kutsub LLM API-d keskkonnamuutujasse salvestatud võtmega.
5. Su server kontrollib vastust — kehtiv JSON, tuntud silt, mõistlik pikkus — ja salvestab või tagastab selle.
6. Esikiht kuvab tulemuse, pikemate vastuste puhul voogedastades teksti nagu see saabub.

Võti asub serveris sammus 4 ega jõua kunagi brauserisse. Kui API mõiste on uus, on mis on API lühike sissejuhatus ja kuidas kasutada LLM API-sid käsitleb põhjalikumalt tokeneid, mudeleid ja võtmeid.

Pakkuja ja mudeli valimine

Suured pakkujad — OpenAI, Anthropic, Google ja teised — pakuvad kõik tekstiliideseid, mis on üsna sarnase kujuga. Valides kasulik küsida:

• Kvaliteet sinu ülesandel. Proovi paari päris näidet oma rakendusest kahel või kolmel mudelil. Erinevused on sageli selgemad sinu andmetel kui üldistel võrdlustel.
• Suurus vs kulu. Pakkujad pakuvad suuremaid, võimekamaid mudeleid ja väiksemaid, odavamaid ja kiiremaid. Klassifitseerimine ja lihtne väljavõtmine töötavad sageli hästi väikesel mudelil; pikk põhjendamine või peen kirjutamine võib vajada suuremat.
• Struktureeritud väljund. Väljavõtmise ja klassifitseerimise puhul eelista API-funktsiooni, mis paneb mudeli tagastama sinu antud skeemile vastava JSON-i, mitte vabateksti parsimist.
• Andmete käsitlemine. Loe pakkuja tingimusi selle kohta, kas API sisendeid salvestatakse või kasutatakse treeninguks, ja kas see sobib sinu kasutajate andmetele.
• Limiidid. Uutel kontodel on sageli madalamad päringulimiidid; kontrolli neid enne väljalaset.

Mudelite nimed ja hinnad muutuvad sageli, seega peaks kood lugema mudeli nime seadistusest, mitte kirjutama seda paljudesse kohtadesse.

Funktsiooni lisamine samm-sammult

Võta konkreetne näide: väike CRM, kus igal kontaktil on pikk märkmete ajalugu.

1. Salvesta võti. Loo võti pakkuja töölaual ja salvesta see serveripoolse saladusena, näiteks OPENAI_API_KEY või ANTHROPIC_API_KEY.

2. Palu üks kitsas funktsioon:

Lisa kontaktilehele nupp „Tee kokkuvõte“. Serveris saada kontakti viimased 20 märkust pakkujale [PROVIDER], kasutades saladust [ENV_NAME], koos juhistega kirjutada kolm punkti: praegune olukord, avatud küsimused, järgmine samm. Kaasa ainult märkmed, mida sisselogitud kasutaja näha võib. Näita laadimisolekut, salvesta kokkuvõte ajatempliga ja kuva „Kokkuvõtet ei saa praegu teha“, kui päring ebaõnnestub. Võtit ei tohi kunagi saata brauserisse.

3. Lisa väljavõtmine seal, kus see säästab kirjutamist:

Kui kasutaja kleebib „Kiire lisamise“ kasti e-posti allkirja, kutsu serveris pakkujat [PROVIDER] ja tagasta JSON väljadega nimi, ettevõte, ametinimetus, e-post ja telefon, kasutades pakkuja struktureeritud väljundi funktsiooni. Valideeri JSON serveris, täida uue kontakti vorm sellega ja lase kasutajal enne salvestamist muuta. Väljad jäta tühjaks, selle asemel et arvata.

„Lase kasutajal enne salvestamist muuta“ on oluline osa: mudel pakub, inimene otsustab.

4. Klassifitseeri taustal:

Kui saabub uus toetuspilet, klassifitseeri see täpselt ühte: arveldus, viga, funktsioonisoov, konto juurdepääs, muu. Kasuta väikest ja odavat mudelit. Kui vastus ei ole ükski neist siltidest, salvesta „muu“. Kuva silt muudetava märgendina.

5. Testi korrastamata päris andmetega — pikad märkmed, tühjad märkmed, teised keeled, allkiri ilma telefoninumbrita — ja vaata kakskümmend väljundit kõrvuti enne väljalaset.

Kuidas kirjutada töötavaid juhiseid

Juhised, mille saadad igal päringul (sageli nimetatakse süsteemipromptiks), on koht, kust kvaliteet tuleb.

• Ütle, kellele see on mõeldud ja mis on hea. „Kokkuvõtteid loeb müügiinimene 10 sekundiga enne kõnet“ annab mudelile sihi.
• Fikseeri vorming. Täpne arv punkte, pikkuse piirang, väljad, sildid.
• Ütle, mida teha, kui pole kindel. „Kui märkmed ei maini järgmist sammu, kirjuta „Järgmist sammu pole salvestatud““. See vähendab väljamõeldud vastuseid.
• Anna kaks-kolm näidet heast sisendist ja väljundist väljavõtmise ja klassifitseerimise jaoks.
• Hoia juhised eraldi kasutaja sisust ning märgi kasutaja sisu selgelt, et mudel saaks neid eristada.

Hoia prompte koodibaasis failides, et need oleksid versioonitud ja ülevaadatavad nagu mis tahes muu kood.

Kulude kontrolli all hoidmine

LLM API-d arvestavad tokenite järgi — väikeste tekstitükkide järgi — nii selle eest, mida saadad, kui ka selle eest, mis tagasi tuleb. Kulu kasvab päringu konteksti mahu ja selle korduvuse korrutisena. Praktilised meetmed:

• Saada ainult vajalik. Viimased 20 märkust, mitte kogu ajalugu. Lõika pikad dokumendid või jaga need tükkideks.
• Kasuta väikseimat mudelit, mis töö ära teeb. Testi enne, kui valid suurima.
• Piira väljundi pikkust API maksimaalse tokenite seadistusega.
• Vahemälu tulemused. Salvesta kokkuvõte ja loo see uuesti ainult siis, kui allikas muutub, mitte iga lehevaatamise korral.
• Piira kasutaja kohta. Päevane limiit konto või paketi kohta takistab ühel rasksel kasutajal või skriptil arve üles ajada.
• Piira päringute sagedust lõpp-punktis nagu iga teise kallise marsruudi puhul.
• Sea eelarve või hoiatus pakkuja töölaual ja vaata kasutust iga nädal pärast väljalaset.
• Logi tokenite kasutust funktsiooni kohta, et teada, milline funktsioon mida maksab.

Kui AI-funktsioonid on sinu toote keskmes, arvesta nende jooksva kulu hinnas, mitte ära kanna seda ise.

Ohutus ja usaldus

AI väljund on tõenäosuslik. See võib olla vale, kuigi kõlab kindlalt, ja seda võib juhtida tekst, mida see loeb. Ehita selleks:

• Käsitle väljundit usaldamatu sisendina. Kontrolli struktuuri, põgeneta see enne HTML-ina kuvamist ja ära käivita seda kunagi koodina ega andmebaasi päringuna.
• Hoia inimene ahela sees kõige puhul, millel on tagajärg — e-kirja saatmine, kirje muutmine, makse tagasimaksmine. Mudel koostab mustandi; inimene kinnitab.
• Kaitse end prompt injection eest. Dokument või sõnum võib sisaldada teksti nagu „ignoreeri oma juhiseid“. Piira, mida mudel näha saab, selleks, mida praegune kasutaja tohib näha, ja ära anna sellele tööriistu, mis võivad tundlikke toiminguid teha enne, kui su kood on õigusi kontrollinud.
• Märgista AI-sisu, et kasutajad teaksid, et kokkuvõte või soovitus on genereeritud ja saavad seda kontrollida.
• Käsitle vigu graatsiliselt. Pakkujatel on katkestusi ja päringulimiite. Sea ajalõpp, näita selget teadet ja lase ülejäänud rakendusel töötada.
• Jälgi, mida kasutajad saadavad. Vabade tekstisisendite puhul kaalu modereerimise sammu ja ole privaatsuspoliitikas selge, et sisu töödeldakse kolmanda osapoole AI-pakkuja poolt.

Laiem kontrollide loend on turvakontrollnimekirjas AI-ga ehitatud rakendustele.

Levinud vead

• Alustamine üldise vestlusrobotiga, kui üks „Tee kokkuvõte“ või „Kategoriseeri“ nupp aitaks rohkem inimesi.
• Võtme panemine esikoodi või avalikku repositooriumisse.
• Kogu andmebaasi saatmine kontekstina, mis on aeglane, kallis ja riskib teiste kasutajate andmete avalikustamisega.
• Vabateksti väljundi usaldamine, kui skeem või fikseeritud siltide hulk muudaks selle kontrollitavaks.
• Kasutajapõhiste limiitide puudumine, mille avastad siis, kui saabub esimene arve.

AI-funktsioonide lisamine Mythexiga

Mythexis lisad AI oma rakenduse sisse, küsides seda vestluses, kasutades oma pakkuja võtit. Salvesta võti projekti saladusena — kui agent seda vajab, kuvab Mythex vestluses saladuste kaardi, nii et võtit ei pea vestlusesse kleepima — ning agent kirjutab serveriteekonna, promptid ja liidese. Sinu rakenduse AI-kasutust arvestab pakkuja, eraldi Mythexi krediitidest, mida ehitamisel kulutad. Dokumentatsioonis on algusprompt lehel lisa AI oma API-võtmetega.

Küsimused