Sådan tilføjer du AI-funktioner til din app

For at tilføje AI-funktioner til din app kalder du en stor sprogmodel (LLM) API fra din server: send den klare instruktioner plus de relevante data, og brug det, der kommer tilbage. De fleste nyttige funktioner falder i et af fire mønstre — opsummering, chat, udtræk af struktureret data og klassificering — og hver af dem er nogle få dusin linjer kode, som et AI-værktøj til apps kan skrive for dig. Det, der afgør, om funktionen er god, er arbejdet omkring kaldet: at holde API-nøglen på serveren, styre omkostningerne pr. bruger og kontrollere outputtet, før du stoler på det.

De fire mønstre bag de fleste AI-funktioner

Udtræk og klassificering er ofte de mest værdifulde og de mindst synlige. De sparer stille og roligt nogen for nogle minutter på hver post, og fordi outputtet har en fast form, kan du kontrollere det automatisk. Chat er det mest synlige, men det er ssværest at få rigtigt, og det har sin egen guide: sådan bygger du en AI-chatbot-app.

Sådan passer det ind i din app

Hvert mønster har den samme form:

1. Brugeren handler — klikker på „Opsummer“, uploader en fil, sender en besked.
2. Din frontend kalder din egen server, ikke AI-udbyderen.
3. Din server bygger anmodningen: systeminstruktioner, brugerens input og de data modellen har brug for fra din database — kun data denne bruger må se.
4. Din server kalder LLM-API'et med en nøgle gemt i en miljøvariabel.
5. Din server kontrollerer svaret — gyldig JSON, en kendt etiket, en fornuftig længde — og gemmer eller returnerer det.
6. Frontenden viser det, og streamer tekst efterhånden som den kommer, ved længere svar.

Nøglen sidder på serveren i trin 4 og når aldrig browseren. Hvis idéen om en API er ny, er hvad er en API en kort introduktion, og sådan bruger du LLM-API'er dækker tokens, modeller og nøgler mere grundigt.

Valg af udbyder og model

De store udbydere — OpenAI, Anthropic, Google og andre — tilbyder alle tekst-API'er med nogenlunde samme form. Nyttige spørgsmål ved valget:

• Kvalitet på din opgave. Prøv et par rigtige eksempler fra din app på to eller tre modeller. Forskellene er ofte tydeligere på dine data end i generelle benchmarks.
• Størrelse vs. omkostning. Udbyderne tilbyder større, mere kapable modeller og mindre, billigere, hurtigere. Klassificering og simpelt udtræk fungerer ofte godt på en lille model; lang ræsonnering eller nuanceret skrivning kan kræve en større.
• Struktureret output. Til udtræk og klassificering skal du foretrække en API-funktion, der får modellen til at returnere JSON, der matcher et skema du leverer, frem for at parse fri tekst.
• Databehandling. Læs udbyderens vilkår for, om API-input gemmes eller bruges til træning, og om det passer til de data, dine brugere giver dig.
• Grænser. Nye konti har ofte lavere hastighedsgrænser; tjek dem før en lancering.

Modelnavne og priser ændrer sig ofte, så koden bør læse modelnavnet fra konfigurationen i stedet for at hardkode det mange steder.

Tilføj en funktion, trin for trin

Tag et konkret eksempel: et lille CRM, hvor hver kontakt har en lang historik af noter.

1. Gem nøglen. Opret en nøgle i din udbyders dashboard og gem den som en hemmelighed på serveren, for eksempel OPENAI_API_KEY eller ANTHROPIC_API_KEY.

2. Bed om én snæver funktion:

Tilføj en knap „Opsummer“ på kontaktsiden. Send på serveren kontaktens sidste 20 noter til [PROVIDER] med hemmeligheden [ENV_NAME], med instruktion om at skrive tre punkter: nuværende status, åbne spørgsmål og næste skridt. Medtag kun noter, den indloggede bruger må se. Vis en indlæsningstilstand, gem resuméet med et tidsstempel, og vis „Kunne ikke opsummere lige nu“, hvis kaldet fejler. Send aldrig nøglen til browseren.

3. Tilføj udtræk, hvor det sparer indtastning:

Når en bruger indsætter en e-mailsignatur i feltet „Hurtig tilføjelse“, kald [PROVIDER] på serveren og returnér JSON med navn, firma, jobtitel, e-mail og telefon, ved brug af udbyderens funktion for struktureret output. Valider JSON'en på serveren, udfyld formularen for ny kontakt med den, og lad brugeren redigere før lagring. Lad felter stå tomme frem for at gætte.

„Lad brugeren redigere før lagring“ er den vigtige del: modellen foreslår, personen beslutter.

4. Klassificer i baggrunden:

Når en ny supportsag kommer ind, klassificér den i præcis én af: fakturering, fejl, funktionsønske, kontoadgang, andet. Brug en lille, billig model. Hvis svaret ikke er en af disse etiketter, gem „andet“. Vis etiketten som et redigerbart mærke.

5. Test med rodede rigtige data — lange noter, tomme noter, andre sprog, en signatur uden telefonnummer — og kig på tyve outputs side om side, før du lancerer.

Skriv instruktioner, der virker

De instruktioner du sender med hver anmodning (ofte kaldet systemprompten) er der, kvaliteten kommer fra.

• Sig hvem det er til, og hvad godt er. „Resuméer læses af en sælger på 10 sekunder før et opkald“ giver modellen et mål.
• Fastlæg formatet. Præcist antal punkter, længdegrænse, felter, etiketter.
• Sig, hvad der skal ske, når den er i tvivl. „Hvis noterne ikke nævner et næste skridt, skriv „Intet næste skridt registreret““. Det reducerer opfundne svar.
• Giv to eller tre eksempler på godt input og output til udtræk og klassificering.
• Hold instruktioner adskilt fra brugerindhold, og mærk brugerindholdet tydeligt, så modellen kan skelne dem.

Gem prompterne i filer i din kodebase, så de er versionerede og kan gennemgås ligesom anden kode.

Hold omkostningerne under kontrol

LLM-API'er tager betaling pr. tokens — små stykker tekst — både for det du sender, og det der kommer tilbage. Omkostningen vokser med mængden af kontekst pr. anmodning ganget med, hvor ofte den køres. Praktiske kontroller:

• Send kun det nødvendige. De sidste 20 noter, ikke hele historikken. Beskær lange dokumenter eller del dem op.
• Brug den mindste model, der klarer opgaven. Test, før du går til den største som standard.
• Begræns outputlængden med API'ets indstilling for maksimale tokens.
• Cache resultater. Gem et resumé, og generér det kun igen, når kilden ændres, i stedet for ved hver sidevisning.
• Begræns pr. bruger. Et dagligt loft pr. konto eller pr. abonnement stopper én tung bruger, eller ét script, fra at køre regningen op.
• Sæt hastighedsgrænser på endpointet ligesom på enhver anden dyr rute.
• Sæt et budget eller en advarsel i udbyderens dashboard, og tjek forbruget ugentligt efter lancering.
• Log tokenforbrug pr. funktion, så du ved, hvilken der koster hvad.

Hvis AI-funktioner er centrale for dit produkt, så regn deres løbende omkostninger ind i din prissætning frem for at absorbere dem.

Sikkerhed og tillid

AI-output er probabilistisk. Det kan være forkert, selv når det lyder sikkert, og det kan styres af den tekst, det læser. Byg med det in mente:

• Behandl output som upålideligt input. Valider strukturen, escape det før visning som HTML, og kør det aldrig som kode eller databaseforespørgsler.
• Hold et menneske med i loopet ved alt, der har konsekvenser — at sende en e-mail, ændre en post, refundere en betaling. Modellen udkaster; en person bekræfter.
• Værn mod prompt injection. Et dokument eller en besked kan indeholde tekst som „ignorer dine instruktioner“. Begræns, hvad modellen kan se, til det den aktuelle bruger må se, og giv den ikke værktøjer, der kan udføre følsomme handlinger, før din kode har kontrolleret rettighederne.
• Mærk AI-indhold, så brugerne ved, at et resumé eller forslag er genereret, og kan kontrollere det.
• Håndtér fejl elegant. Udbydere har nedbrud og hastighedsgrænser. Sæt timeouts, vis en klar besked, og lad resten af appen fortsætte med at virke.
• Hold øje med, hvad brugerne sender. Overvej et modereringstrin ved åbne tekstfelter, og vær klar i din privatlivspolitik om, at indhold behandles af en tredjeparts AI-udbyder.

Den bredere liste over kontroller findes i sikkerhedstjeklisten for AI-byggede apps.

Almindelige fejl

• At starte med en generel chatbot, når en enkelt knap „Opsummer“ eller „Kategorisér“ ville hjælpe flere mennesker.
• At lægge nøglen i frontend-koden eller i et offentligt repository.
• At sende hele databasen som kontekst, hvilket er langsomt, dyrt og risikerer at eksponere andre brugeres data.
• At stole på fri tekst-output, hvor et skema eller et fast sæt etiketter ville gøre det kontrollerbart.
• Ingen grænser pr. bruger, som opdages, når den første faktura kommer.

Tilføj AI-funktioner med Mythex

På Mythex tilføjer du AI i din egen app ved at bede om det i chatten og bruge din egen udbydernøgle. Gem nøglen som en projekthemmelighed — når agenten har brug for den, viser Mythex et hemmelighedskort i chatten, så du ikke skal indsætte nøglen i samtalen — og agenten skriver serverruten, prompterne og brugerfladen. Din apps AI-forbrug faktureres af din udbyder, adskilt fra de Mythex-kreditter du bruger på at bygge. Dokumentationen har en startprompt i tilføj AI-funktioner med dine egne API-nøgler.

Spørgsmål