Paano Magdagdag ng AI Features sa Iyong App

Para magdagdag ng AI features sa app mo, tumawag ng large language model (LLM) API mula sa server mo: magpadala ng malinaw na tagubilin kasama ang kaugnay na data, at gamitin ang ibabalik nito. Karamihan ng kapaki-pakinabang na features ay isa sa apat na pattern: pag-summarize, chat, pag-extract ng structured data, at classification. Bawat isa ay ilang dosenang linya lang ng code na kayang isulat ng AI builder para sa iyo. Ang bahaging nagpapasya kung maganda ang feature ay nasa paligid ng tawag: pag-iingat sa API key sa server, pagkontrol ng gastos bawat user, at pagsusuri ng output bago ito pagkatiwalaan.

Ang apat na pattern sa likod ng karamihan ng AI features

Kadalasan, ang extraction at classification ang pinakamahalaga pero pinakahindi napapansin. Tahimik nilang natitipid ang ilang minuto ng isang tao sa bawat record, at dahil nakapirmi ang hugis ng output, awtomatiko mo itong masusuri. Ang chat ang pinakanakikita pero pinakamahirap gawing tama, at may sarili itong guide: paano gumawa ng AI chatbot app.

Paano ito isinasama sa app mo

Pare-pareho ang hugis ng bawat pattern:

1. Kumikilos ang user: nag-click ng "Summarise", nag-upload ng file, nagpadala ng mensahe.
2. Tumatawag ang front end mo sa sarili mong server, hindi sa AI provider.
3. Binubuo ng server mo ang request: system instructions, input ng user, at anumang data na kailangan ng model mula sa database, data lang na pinapayagang makita ng user na ito.
4. Tinatawag ng server mo ang LLM API gamit ang key na nasa environment variable.
5. Sinusuri ng server mo ang response: valid JSON ba, kilalang label, makatwirang haba, at saka ito sine-save o ibinabalik.
6. Ipinapakita ng front end, na nag-i-stream ng text habang dumarating para sa mas mahabang sagot.

Nasa server ang key sa hakbang 4 at hindi ito kailanman umaabot sa browser. Kung bago pa sa iyo ang ideya ng API, ano ang API ay maikling paliwanag, at ang paano gamitin ang LLM APIs ay sumasaklaw sa tokens, models at keys nang mas malalim.

Pagpili ng provider at model

Lahat ng malalaking provider, gaya ng OpenAI, Anthropic, Google at iba pa, ay may text APIs na halos magkakatulad ang hugis. Mga kapaki-pakinabang na tanong sa pagpili:

• Kalidad sa iyong gawain. Subukan ang ilang totoong halimbawa mula sa app mo sa dalawa o tatlong model. Kadalasang mas malinaw ang pagkakaiba sa sarili mong data kaysa sa pangkalahatang benchmarks.
• Laki kumpara sa gastos. May mas malalaki at mas may kakayahang model ang mga provider, at mas maliliit, mas mura at mas mabilis na model. Madalas gumagana nang maayos sa maliit na model ang classification at simpleng extraction; ang mahabang pangangatwiran o maselang pagsusulat ay maaaring mangailangan ng mas malaki.
• Structured output. Para sa extraction at classification, mas mabuting gamitin ang feature ng API na nagpapabalik ng JSON ayon sa schema na ibibigay mo, kaysa mag-parse ng free text.
• Paghawak ng data. Basahin ang terms ng provider tungkol sa kung nise-save ang API inputs o ginagamit para sa training, at kung angkop ito sa data na ibinibigay ng users mo.
• Limits. Kadalasang mas mababa ang rate limits ng bagong account; tingnan ang mga ito bago mag-launch.

Mabilis magbago ang mga pangalan at presyo ng model, kaya dapat basahin ng code ang pangalan ng model mula sa configuration sa halip na i-hard-code ito sa maraming lugar.

Magdagdag ng feature, step by step

Halimbawa: maliit na CRM kung saan may mahabang kasaysayan ng notes ang bawat contact.

1. Itago ang key. Gumawa ng key sa dashboard ng provider at i-save bilang server-side secret, halimbawa OPENAI_API_KEY o ANTHROPIC_API_KEY.

2. Humingi ng isang maliit na feature:

Magdagdag ng "Summarise" button sa contact page. Sa server, ipadala ang huling 20 notes ng contact sa [PROVIDER] gamit ang secret na [ENV_NAME], na may tagubiling sumulat ng tatlong bullet points: kasalukuyang status, bukas na tanong, at susunod na hakbang. Isama lang ang mga notes na nakikita ng naka-log in na user. Magpakita ng loading state, i-save ang summary kasama ang timestamp, at magpakita ng "Hindi makapag-summarise sa ngayon" kapag pumalya ang tawag. Huwag kailanman ipadala ang key sa browser.

3. Magdagdag ng extraction kung saan nakakatipid ng pag-type:

Kapag nag-paste ang user ng email signature sa "Quick add" box, tawagin ang [PROVIDER] sa server at ibalik ang JSON na may name, company, job title, email at phone, gamit ang structured output feature ng provider. I-validate ang JSON sa server, punan muna ang bagong contact form nito, at hayaang i-edit ng user bago i-save. Iwanang blangko ang fields sa halip na manghula.

Ang "hayaang i-edit ng user bago i-save" ang mahalagang bahagi: nagmumungkahi ang model, nagpapasya ang tao.

4. Mag-classify sa background:

Kapag may dumating na bagong support ticket, i-classify ito sa eksaktong isa sa: billing, bug, feature request, account access, other. Gumamit ng maliit at murang model. Kung hindi isa sa mga label na iyon ang sagot, i-save ang "other". Ipakita ang label bilang tag na puwedeng i-edit.

5. Subukan gamit ang magulong totoong data: mahabang notes, walang laman na notes, ibang wika, signature na walang phone number, at tingnan ang dalawampung output nang magkatabi bago i-ship.

Pagsulat ng tagubiling gumagana

Ang mga tagubiling ipinapadala mo kasama ng bawat request (madalas tawaging system prompt) ang pinanggagalingan ng kalidad.

• Sabihin kung para kanino ito at ano ang magandang resulta. Ang "Binabasa ng salesperson ang mga summary sa loob ng 10 segundo bago ang tawag" ay nagbibigay sa model ng target.
• Ayusin ang format. Eksaktong bilang ng bullets, limitasyon sa haba, fields, labels.
• Sabihin kung ano ang gagawin kapag hindi sigurado. "Kung walang nabanggit na susunod na hakbang sa notes, isulat ang 'Walang naitalang susunod na hakbang'." Nababawasan nito ang mga sagot na inimbento.
• Magbigay ng dalawa o tatlong halimbawa ng magandang input at output para sa extraction at classification.
• Paghiwalayin ang tagubilin sa content ng user, at lagyan ng malinaw na label ang content ng user para maiba ito ng model.

Itago ang mga prompt sa mga file sa codebase para ma-version at masuri ang mga ito gaya ng anumang code.

Pagkontrol ng gastos

Sinisingil ng LLM APIs ang mga token, maliliit na piraso ng text, para sa ipinapadala mo at sa ibinabalik nito. Tumataas ang gastos habang tumataas ang context bawat request na pinarami ng dalas ng pagtakbo nito. Mga praktikal na kontrol:

• Ipadala lang ang kailangan. Ang huling 20 notes, hindi ang buong kasaysayan. I-trim o hatiin ang mahahabang dokumento.
• Gamitin ang pinakamaliit na model na kaya ang trabaho. Subukan muna bago gawing default ang pinakamalaki.
• Limitahan ang haba ng output gamit ang maximum-tokens setting ng API.
• I-cache ang resulta. I-save ang summary at i-regenerate lang kapag nagbago ang pinagmulan, sa halip na sa bawat pagbisita sa page.
• Limitahan bawat user. Ang daily cap bawat account o plan ay pumipigil sa isang mabigat na user, o isang script, na pataasin ang bill.
• I-rate-limit ang endpoint tulad ng ibang mahal na route.
• Magtakda ng budget o alert sa dashboard ng provider, at suriin ang paggamit linggo-linggo pagkatapos mag-launch.
• I-log ang paggamit ng token bawat feature para malaman mo kung alin ang magastos.

Kung sentro ng produkto mo ang AI features, isama ang running cost nila sa pricing mo sa halip na sagutin ito nang mag-isa.

Kaligtasan at tiwala

Ang output ng AI ay probabilistic. Maaari itong mali habang kumpiyansa ang tono, at maaari itong maimpluwensyahan ng text na binabasa nito. Gumawa para doon:

• Ituring na untrusted input ang output. I-validate ang istruktura, i-escape bago i-render bilang HTML, at huwag kailanman patakbuhin ito bilang code o database query.
• Panatilihin ang tao sa loop para sa anumang may kahihinatnan, tulad ng pagpapadala ng email, pagbabago ng record, o pag-refund ng bayad. Gumagawa ng draft ang model; kinukumpirma ng tao.
• Mag-ingat sa prompt injection. Maaaring may text ang dokumento o mensahe tulad ng "ignore your instructions". Limitahan ang nakikita ng model sa kung ano lang ang puwedeng makita ng kasalukuyang user, at huwag bigyan ito ng tools na makakagawa ng sensitibong aksyon nang hindi muna sinusuri ng code mo ang permissions.
• Lagyan ng label ang AI content para malaman ng users na ginawa ng AI ang summary o mungkahi at puwede nila itong suriin.
• Hawakan nang maayos ang pagkabigo. Nagkakaroon ng outage at rate limits ang mga provider. Maglagay ng timeout, magpakita ng malinaw na mensahe, at hayaang gumana pa rin ang iba pang bahagi ng app.
• Bantayan ang ipinapadala ng users. Para sa bukas na text inputs, isaalang-alang ang moderation step, at malinaw sa privacy policy mo na ang content ay pinoproseso ng third-party AI provider.

Nasa security checklist para sa AI-built apps ang mas malawak na listahan ng mga pagsusuri.

Mga karaniwang pagkakamali

• Pagsisimula sa pangkalahatang chatbot kung kailan mas makakatulong sa mas maraming tao ang iisang "Summarise" o "Categorise" na button.
• Paglalagay ng key sa front-end code o sa public repository.
• Pagpapadala ng buong database bilang context, na mabagal, mahal at maaaring maglantad ng data ng ibang user.
• Pagtitiwala sa free-text na output kung saan magiging madaling suriin ang schema o nakapirming set ng labels.
• Walang limitasyon bawat user, at matutuklasan lang kapag dumating ang unang invoice.

Pagdaragdag ng AI features sa Mythex

Sa Mythex, nagdadagdag ka ng AI sa sarili mong app sa pamamagitan ng paghingi nito sa chat, gamit ang sarili mong provider key. Itago ang key bilang project secret. Kapag kailangan ito ng agent, magpapakita ang Mythex ng secrets card sa chat para hindi mo na kailangang i-paste ang key sa usapan. Ang agent ang susulat ng server route, mga prompt at interface. Ang AI usage ng app mo ay sisingilin ng provider mo, hiwalay sa Mythex credits na ginagastos mo sa pag-build. Nasa docs ang starter prompt sa add AI features with your own API keys.

Mga tanong