Slik legger du til AI-funksjoner i appen din

For å legge til AI-funksjoner i appen din kaller du et stort språkmodell-API (LLM) fra serveren din: send det tydelige instruksjoner pluss de relevante dataene, og bruk det som kommer tilbake. De fleste nyttige funksjoner er ett av fire mønstre (oppsummere, chatte, hente ut strukturerte data og klassifisere), og hver av dem er noen titalls linjer kode som et AI-verktøy kan skrive for deg. Arbeidet som avgjør om funksjonen er god, ligger rundt kallet: å holde API-nøkkelen på serveren, styre kostnaden per bruker, og kontrollere resultatet før du stoler på det.

De fire mønstrene bak de fleste AI-funksjoner

Uttrekking og klassifisering er ofte de mest verdifulle og de minst synlige. De sparer noen for noen minutter på hver post, og fordi resultatet har fast form, kan du kontrollere det automatisk. Chat er det mest synlige, men det vanskeligste å få til, og har sin egen guide: hvordan bygge en AI-chatbot-app.

Slik passer det inn i appen din

Alle mønstrene har samme form:

1. Brukeren handler: klikker «Oppsummer», laster opp en fil eller sender en melding.
2. Frontenden din kaller din egen server, ikke AI-leverandøren.
3. Serveren bygger forespørselen: systeminstruksjoner, brukerens input, og eventuelle data modellen trenger fra databasen din, bare data denne brukeren har lov til å se.
4. Serveren kaller LLM-API-et med en nøkkel lagret i en miljøvariabel.
5. Serveren kontrollerer svaret: gyldig JSON, en kjent etikett, en fornuftig lengde. Deretter lagrer eller returnerer den det.
6. Frontenden viser det, og strømmer tekst etter hvert som den kommer for lengre svar.

Nøkkelen ligger på serveren i steg 4 og når aldri nettleseren. Hvis ideen om et API er ny, er hva er et API en kort innføring, og hvordan bruke LLM-API-er dekker tokens, modeller og nøkler mer grundig.

Velge leverandør og modell

De store leverandørene (OpenAI, Anthropic, Google og andre) tilbyr tekst-API-er med ganske like former. Nyttige spørsmål når du velger:

• Kvalitet på din oppgave. Prøv noen ekte eksempler fra appen din på to eller tre modeller. Forskjeller er ofte tydeligere på dine data enn i generelle benchmarker.
• Størrelse mot kostnad. Leverandørene tilbyr større, mer kapable modeller og mindre, billigere og raskere. Klassifisering og enkel uttrekking fungerer ofte godt på en liten modell; lang resonnering eller nyansert skriving kan kreve en større.
• Strukturert output. For uttrekking og klassifisering bør du foretrekke et API-valg som får modellen til å returnere JSON som følger et skjema du oppgir, i stedet for å tolke fritekst.
• Databehandling. Les leverandørens vilkår om hvorvidt API-input lagres eller brukes til trening, og om det passer for dataene brukerne gir deg.
• Grenser. Nye kontoer har ofte lavere rate-grenser; sjekk dem før lansering.

Modellnavn og priser endrer seg ofte, så koden bør lese modellnavnet fra konfigurasjon i stedet for å hardkode det mange steder.

Legge til en funksjon, steg for steg

Ta et konkret eksempel: et lite CRM der hver kontakt har en lang historikk med notater.

1. Lagre nøkkelen. Lag en nøkkel i leverandørens dashbord og lagre den som en hemmelighet på serveren, for eksempel OPENAI_API_KEY eller ANTHROPIC_API_KEY.

2. Be om én smal funksjon:

Legg til en «Oppsummer»-knapp på kontaktsiden. Send kontaktens siste 20 notater til [LEVERANDØR] på serveren ved hjelp av hemmeligheten [ENV-NAVN], med instruksjoner om å skrive tre punkter: nåværende status, åpne spørsmål og neste steg. Ta bare med notater den innloggede brukeren kan se. Vis en lastetilstand, lagre oppsummeringen med tidspunkt, og vis «Kunne ikke oppsummere akkurat nå» hvis kallet feiler. Send aldri nøkkelen til nettleseren.

3. Legg til uttrekking der det sparer skriving:

Når en bruker limer inn en e-postsignatur i boksen «Hurtigtillegg», kall [LEVERANDØR] på serveren og returner JSON med navn, firma, stillingstittel, e-post og telefon, ved hjelp av leverandørens funksjon for strukturert output. Valider JSON-en på serveren, fyll ut skjemaet for ny kontakt med den, og la brukeren redigere før lagring. La felt stå tomme i stedet for å gjette.

«La brukeren redigere før lagring» er den viktige delen: modellen foreslår, og personen bestemmer.

4. Klassifiser i bakgrunnen:

Når en ny supportsak kommer inn, klassifiser den i nøyaktig én av: fakturering, feil, funksjonsønske, kontotilgang, annet. Bruk en liten modell med lav kostnad. Hvis svaret ikke er en av disse etikettene, lagre «annet». Vis etiketten som en redigerbar merkelapp.

5. Test med rotete ekte data: lange notater, tomme notater, andre språk, en signatur uten telefonnummer. Se på tjue resultater side om side før du lanserer.

Skrive instruksjoner som fungerer

Instruksjonene du sender med hver forespørsel (ofte kalt systemprompten) er der kvaliteten kommer fra.

• Si hvem det er for og hva som er godt. «Oppsummeringer leses av en salgsmedarbeider på 10 sekunder før et møte» gir modellen et mål.
• Fast format. Eksakt antall punkter, lengdegrense, felt, etiketter.
• Si hva den skal gjøre når den er usikker. «Hvis notatene ikke nevner et neste steg, skriv "Ingen neste steg registrert"». Dette reduserer oppdiktede svar.
• Gi to eller tre eksempler på god input og output for uttrekking og klassifisering.
• Hold instruksjonene adskilt fra brukerinnhold, og merk brukerinnholdet tydelig, slik at modellen kan skille dem.

Ta vare på promptene i filer i kodebasen din, slik at de versjoneres og kan gjennomgås som all annen kode.

Holde kostnadene under kontroll

LLM-API-er tar betalt per tokens, små tekstbiter, for både det du sender og det som kommer tilbake. Kostnaden øker med mengden kontekst per forespørsel multiplisert med hvor ofte den kjøres. Praktiske kontroller:

• Send bare det som trengs. De siste 20 notatene, ikke hele historikken. Kutt eller del opp lange dokumenter.
• Bruk minste modell som klarer jobben. Test før du går til den største.
• Begrens lengden på svaret med API-ets innstilling for maks tokens.
• Cache resultater. Lagre en oppsummering og generer den på nytt bare når kilden endres, i stedet for ved hver sidevisning.
• Begrens per bruker. En daglig grense per konto eller abonnement stopper én tung bruker, eller ett skript, fra å drive opp regningen.
• Rate-begrens endepunktet som enhver annen dyr rute.
• Sett et budsjett eller en varsling i leverandørens dashbord, og sjekk bruken ukentlig etter lansering.
• Logg tokenbruk per funksjon, slik at du vet hva hver koster.

Hvis AI-funksjoner er sentrale for produktet ditt, regn med driftskostnaden i prisingen din i stedet for å absorbere den.

Sikkerhet og tillit

AI-output er sannsynlighetsbasert. Det kan være feil mens det høres sikkert ut, og det kan styres av teksten det leser. Bygg for det:

• Behandle output som utrygt input. Valider strukturen, escape den før den vises som HTML, og kjør den aldri som kode eller databasespørringer.
• Ha et menneske med i løkken for alt som har konsekvenser: sende en e-post, endre en post, refundere en betaling. Modellen lager utkast; en person bekrefter.
• Vern mot prompt injection. Et dokument eller en melding kan inneholde tekst som «ignorer instruksjonene dine». Begrens hva modellen kan se til det den nåværende brukeren har lov til å se, og gi den ikke verktøy som kan utføre sensitive handlinger uten at koden din først sjekker tillatelser.
• Merk AI-innhold, slik at brukere vet at en oppsummering eller et forslag er generert, og kan sjekke det.
• Håndter feil på en pen måte. Leverandører har driftsavbrudd og rate-grenser. Sett tidsavbrudd, vis en tydelig melding, og la resten av appen fungere.
• Følg med på hva brukerne sender. For åpne tekstfelt, vurder et moderasjonssteg, og vær tydelig i personvernerklæringen på at innholdet behandles av en tredjeparts AI-leverandør.

Den bredere listen over kontroller finnes i sikkerhetssjekklisten for AI-bygde apper.

Vanlige feil

• Å starte med en generell chatbot når en enkel «Oppsummer»- eller «Kategoriser»-knapp ville hjulpet flere.
• Å legge nøkkelen i frontend-koden eller i et offentlig repositorium.
• Å sende hele databasen som kontekst. Det er tregt, dyrt og risikerer å eksponere andre brukeres data.
• Å stole på fritekst-output der et skjema eller en fast etikettliste ville gjort den mulig å kontrollere.
• Ingen grenser per bruker, oppdaget når den første regningen kommer.

Legge til AI-funksjoner med Mythex

I Mythex legger du til AI i din egen app ved å be om det i chatten, med din egen leverandørnøkkel. Lagre nøkkelen som en prosjekthemmelighet. Når agenten trenger en, viser Mythex et hemmelighetskort i chatten, slik at du ikke limer nøkkelen inn i samtalen. Agenten skriver serverruten, promptene og grensesnittet. Appens AI-bruk faktureres av din leverandør, separat fra Mythex-kreditene du bruker på bygging. Dokumentasjonen har en startprompt i legg til AI-funksjoner med dine egne API-nøkler.

Spørsmål