Com afegir funcionalitats d'IA a la teva app

Per afegir funcionalitats d'IA a la teva app, crida una API de model de llenguatge (LLM) des del teu servidor: envia-li instruccions clares més les dades pertinents, i usa el que torni. La majoria de funcionalitats útils segueixen un de quatre patrons (resumir, xatejar, extreure dades estructurades i classificar), i cadascuna són unes quantes dotzenes de línies de codi que un constructor d'apps amb IA pot escriure per tu. La feina que decideix si la funcionalitat val la pena és la que envolta la crida: mantenir la clau d'API al servidor, controlar el cost per usuari i revisar la sortida abans de confiar-hi.

Els quatre patrons darrere de la majoria de funcionalitats d'IA

L'extracció i la classificació sovint són les més valuoses i les menys visibles. Estalvien discretament uns minuts a algú per cada registre i, com que la sortida té una forma fixa, es poden comprovar automàticament. El xat és el més visible però també el més difícil d'encertar, i té la seva pròpia guia: com construir una app de xatbot amb IA.

Com encaixa a la teva app

Tots els patrons tenen la mateixa forma:

1. L'usuari actua: fa clic a «Resumir», puja un fitxer o envia un missatge.
2. El teu front-end crida al teu propi servidor, no al proveïdor d'IA.
3. El teu servidor construeix la petició: instruccions del sistema, l'entrada de l'usuari i les dades de la teva base de dades que el model necessita; només les dades que aquest usuari pot veure.
4. El teu servidor crida l'API del LLM amb una clau guardada en una variable d'entorn.
5. El teu servidor comprova la resposta: JSON vàlid, una etiqueta coneguda, una longitud raonable; i la desa o la retorna.
6. El front-end la mostra, fent streaming del text a mesura que arriba per a respostes més llargues.

La clau es queda al servidor al pas 4 i mai arriba al navegador. Si la idea d'una API és nova, què és una API és una introducció breu, i com usar les APIs de LLM explica amb més profunditat els tokens, els models i les claus.

Triar proveïdor i model

Els principals proveïdors (OpenAI, Anthropic, Google i altres) ofereixen APIs de text amb formes força semblants. Preguntes útils en triar:

• Qualitat per a la teva tasca. Prova uns quants exemples reals de la teva app amb dos o tres models. Les diferències sovint són més clares amb les teves dades que amb els benchmarks generals.
• Mida contra cost. Els proveïdors ofereixen models més grans i capaços i models més petits, més barats i més ràpids. La classificació i l'extracció senzilla sovint funcionen bé amb un model petit; el raonament llarg o l'escriptura subtil poden necessitar un de més gran.
• Sortida estructurada. Per a l'extracció i la classificació, prefereix una funcionalitat de l'API que faci que el model retorni JSON segons un esquema que tu proporciones, en lloc d'analitzar text lliure.
• Tractament de dades. Llegeix les condicions del proveïdor sobre si les entrades de l'API s'emmagatzemen o s'usen per entrenar, i si això encaixa amb les dades que et donen els teus usuaris.
• Límits. Els comptes nous sovint tenen límits de tarifa més baixos; revisa'ls abans d'un llançament.

Els noms i els preus dels models canvien sovint, així que el codi hauria de llegir el nom del model de la configuració en lloc de codificar-lo en molts llocs.

Afegir una funcionalitat, pas a pas

Prenem un exemple concret: un petit CRM on cada contacte té un historial llarg de notes.

1. Guarda la clau. Crea una clau al tauler del proveïdor i desa-la com a secret del servidor, per exemple OPENAI_API_KEY o ANTHROPIC_API_KEY.

2. Demana una funcionalitat concreta:

Afegeix un botó «Resumir» a la pàgina del contacte. Al servidor, envia les últimes 20 notes del contacte a [PROVEÏDOR] usant el secret [NOM_VARIABLE], amb instruccions per escriure tres punts: estat actual, preguntes obertes i següent pas. Inclou només les notes que l'usuari connectat pot veure. Mostra un estat de càrrega, desa el resum amb una marca de temps i mostra «No s'ha pogut resumir ara» si la crida falla. Mai no enviïs la clau al navegador.

3. Afegeix extracció on estalvia escriure:

Quan un usuari enganxi una signatura de correu al quadre «Afegeix ràpid», crida [PROVEÏDOR] al servidor i retorna un JSON amb nom, empresa, càrrec, correu electrònic i telèfon, usant la funcionalitat de sortida estructurada del proveïdor. Valida el JSON al servidor, omple prèviament el formulari de nou contacte amb ell i deixa que l'usuari l'editi abans de desar. Deixa els camps buits en lloc d'endevinar.

La part important és «deixa que l'usuari l'editi abans de desar»: el model proposa, la persona decideix.

4. Classifica en segon pla:

Quan arribi un tiquet de suport nou, classifica'l en exactament una de les categories següents: facturació, error, sol·licitud de funcionalitat, accés al compte, altres. Usa un model petit i de cost baix. Si la resposta no és una d'aquestes etiquetes, desa «altres». Mostra l'etiqueta com a un marcador editable.

5. Prova-ho amb dades reals i desordenades: notes llargues, notes buides, altres idiomes, una signatura sense número de telèfon; i mira vint sortides una al costat de l'altra abans de publicar.

Escriure instruccions que funcionin

Les instruccions que envies amb cada petició (sovint anomenades prompt del sistema) són on rau la qualitat.

• Digues per a qui és i què és un bon resultat. «Els resums els llegeix un comercial en 10 segons abans d'una trucada» dona al model un objectiu.
• Fixa el format. Un nombre exacte de punts, un límit de longitud, els camps, les etiquetes.
• Digues què fer quan no està segur. «Si les notes no esmenten un següent pas, escriu "No hi ha cap següent pas registrat".» Així es redueixen les respostes inventades.
• Dona dos o tres exemples d'entrades i sortides bones per a l'extracció i la classificació.
• Mantén les instruccions separades del contingut de l'usuari, i etiqueta clarament el contingut de l'usuari perquè el model els distingeixi.

Guarda els prompts en fitxers dins del codi, perquè estiguin versionats i es puguin revisar com qualsevol altre codi.

Mantenir els costos sota control

Les APIs de LLM cobren per tokens (trossos petits de text), tant pel que envies com pel que tornen. El cost creix amb la quantitat de context per petició multiplicada per cada quan s'executa. Controls pràctics:

• Envia només el necessari. Les últimes 20 notes, no tot l'historial. Retalla els documents llargs o divideix-los.
• Usa el model més petit que faci la feina. Prova abans de posar el més gran per defecte.
• Limita la longitud de la sortida amb el paràmetre de tokens màxims de l'API.
• Guarda els resultats a la memòria cau. Desa un resum i només el regeneris quan canviï la font, en lloc de fer-ho a cada visita a la pàgina.
• Limita per usuari. Un límit diari per compte o per pla evita que un usuari intensiu, o un script, dispari la factura.
• Aplica límits de freqüència a l'endpoint, com a qualsevol altra ruta costosa.
• Fixa un pressupost o una alerta al tauler del proveïdor, i revisa l'ús cada setmana després del llançament.
• Registra l'ús de tokens per funcionalitat perquè sàpigues quina en costa quant.

Si les funcionalitats d'IA són el centre del teu producte, inclou el seu cost de funcionament als preus, en lloc d'assumir-lo.

Seguretat i confiança

La sortida de la IA és probabilística. Pot equivocar-se amb molta seguretat, i el text que llegeix pot dirigir-la. Construeix pensant en això:

• Tracta la sortida com a entrada no fiable. Valida l'estructura, escapa-la abans de mostrar-la com a HTML i mai no l'executis com a codi ni com a consulta de base de dades.
• Mantén una persona en el procés per a tot el que tingui conseqüències: enviar un correu, canviar un registre, reemborsar un pagament. El model redacta; una persona confirma.
• Protegeix-te de la injecció de prompts. Un document o un missatge pot contenir text com «ignora les teves instruccions». Limita el que el model pot veure al que l'usuari actual pot veure, i no li donis eines que puguin fer accions sensibles sense que el teu codi comprovi abans els permisos.
• Etiqueta el contingut d'IA perquè els usuaris sàpiguen que un resum o un suggeriment s'ha generat i el puguin revisar.
• Gestiona bé els fallades. Els proveïdors tenen interrupcions i límits de tarifa. Aplica temps d'espera, mostra un missatge clar i deixa que la resta de l'app continuï funcionant.
• Vigila el que envien els usuaris. Per a entrades de text obert, considera un pas de moderació i sigues clar a la política de privadesa que el contingut el processa un proveïdor d'IA extern.

La llista més àmplia de comprovacions es troba a la llista de seguretat per a apps creades amb IA.

Errors habituals

• Començar amb un xatbot general quan un sol botó «Resumir» o «Categoritzar» ajudaria més persones.
• Posar la clau al codi del front-end o en un repositori públic.
• Enviar tota la base de dades com a context, que és lent, car i pot exposar dades d'altres usuaris.
• Confiar en una sortida de text lliure quan un esquema o un conjunt fix d'etiquetes la faria comprovable.
• Sense límits per usuari, que es descobreixen quan arriba la primera factura.

Afegir funcionalitats d'IA amb Mythex

A Mythex afegeixes IA dins de la teva pròpia app demanant-ho al xat, amb la teva pròpia clau de proveïdor. Desa la clau com a secret del projecte: quan l'agent en necessiti una, Mythex mostra una targeta de secrets al xat perquè no hagis d'enganxar la clau a la conversa. Després l'agent escriu la ruta del servidor, els prompts i la interfície. L'ús d'IA de la teva app el factura el teu proveïdor, separat dels crèdits de Mythex que gastes construint. La documentació té un prompt inicial a afegir funcionalitats d'IA amb les teves pròpies claus d'API.

Preguntes