AI-functies toevoegen aan uw app

Om AI-functies aan uw app toe te voegen, roept u een groot taalmodel (LLM) API aan vanaf uw server: u stuurt duidelijke instructies plus de relevante gegevens en gebruikt wat terugkomt. De meeste nuttige functies vallen in een van vier patronen — samenvatten, chatten, gestructureerde gegevens extraheren en classificeren — en elk daarvan is een paar tientallen regels code die een AI-builder voor u kan schrijven. Het werk dat bepaalt of de functie goed is, zit rond die aanroep: de API-sleutel op de server houden, de kosten per gebruiker beheersen en de output controleren voordat u erop vertrouwt.

De vier patronen achter de meeste AI-functies

Extraheren en classificeren zijn vaak het waardevolst en het minst zichtbaar. Ze besparen iemand bij elk record een paar minuten, en omdat de output een vaste vorm heeft, kunt u die automatisch controleren. Chat is het meest zichtbaar maar het moeilijkst goed te krijgen, en heeft een eigen gids: hoe u een AI-chatbotapp bouwt.

Hoe het in uw app past

Elk patroon heeft dezelfde vorm:

1. De gebruiker handelt — klikt op „Samenvatten“, uploadt een bestand, stuurt een bericht.
2. Uw frontend roept uw eigen server aan, niet de AI-aanbieder.
3. Uw server bouwt het verzoek: systeeminstructies, de invoer van de gebruiker en eventuele gegevens die het model nodig heeft uit uw database — alleen gegevens die deze gebruiker mag zien.
4. Uw server roept de LLM-API aan met een sleutel die in een omgevingsvariabele is opgeslagen.
5. Uw server controleert het antwoord — geldige JSON, een bekend label, een redelijke lengte — en slaat het op of stuurt het terug.
6. De frontend toont het, en streamt langere antwoorden terwijl ze binnenkomen.

De sleutel staat in stap 4 op de server en bereikt nooit de browser. Als het idee van een API nieuw is, is wat een API is een korte inleiding, en hoe u LLM-API's gebruikt behandelt tokens, modellen en sleutels dieper.

Een aanbieder en model kiezen

De grote aanbieders — OpenAI, Anthropic, Google en andere — bieden allemaal tekst-API's met grotendeels vergelijkbare opzet. Nuttige vragen bij de keuze:

• Kwaliteit voor uw taak. Probeer een paar echte voorbeelden uit uw app op twee of drie modellen. Verschillen zijn vaak duidelijker in uw eigen gegevens dan in algemene benchmarks.
• Omvang versus kosten. Aanbieders bieden grotere, capabelere modellen en kleinere, goedkopere en snellere. Classificeren en eenvoudig extraheren werken vaak goed op een klein model; lang redeneren of genuanceerd schrijven heeft misschien een groter model nodig.
• Gestructureerde output. Voor extraheren en classificeren geeft u de voorkeur aan een API-functie die het model JSON laat teruggeven volgens een schema dat u aanlevert, in plaats van vrije tekst te parsen.
• Gegevensverwerking. Lees de voorwaarden van de aanbieder over of API-invoer wordt opgeslagen of gebruikt voor training, en of dat past bij de gegevens die uw gebruikers u geven.
• Limieten. Nieuwe accounts hebben vaak lagere snelheidslimieten; controleer die vóór een lancering.

Modelnamen en prijzen veranderen vaak, dus de code moet de modelnaam uit de configuratie lezen in plaats van die op veel plekken hard te coderen.

Een functie toevoegen, stap voor stap

Neem een concreet voorbeeld: een kleine CRM waarin elk contact een lange geschiedenis van notities heeft.

1. Bewaar de sleutel. Maak een sleutel aan in het dashboard van uw aanbieder en sla die op als geheim op de server, bijvoorbeeld OPENAI_API_KEY of ANTHROPIC_API_KEY.

2. Vraag om één smalle functie:

Voeg een knop „Samenvatten“ toe aan de contactpagina. Stuur op de server de laatste 20 notities van het contact naar [AANBIEDER] met het geheim [OMGEVINGSNAAM], met de instructie om drie opsommingstekens te schrijven: huidige status, open vragen, volgende stap. Neem alleen notities mee die de ingelogde gebruiker mag zien. Toon een laadstatus, sla de samenvatting op met een tijdstempel, en toon „Samenvatten lukt nu niet“ als de aanroep mislukt. Stuur de sleutel nooit naar de browser.

3. Voeg extractie toe waar het typwerk bespaart:

Wanneer een gebruiker een e-mailhandtekening plakt in het vak „Snel toevoegen“, roep dan op de server [AANBIEDER] aan en geef JSON terug met naam, bedrijf, functietitel, e-mail en telefoonnummer, met de gestructureerde-outputfunctie van de aanbieder. Valideer de JSON op de server, vul het formulier voor nieuw contact ermee in en laat de gebruiker het bewerken voordat hij wordt opgeslagen. Laat velden leeg in plaats van te gokken.

„Laat de gebruiker bewerken voordat het wordt opgeslagen“ is het belangrijkste onderdeel: het model stelt voor, de persoon beslist.

4. Classificeer op de achtergrond:

Wanneer een nieuw supportticket binnenkomt, classificeer het in precies één van: facturatie, bug, functieverzoek, accounttoegang, overig. Gebruik een klein, goedkoop model. Als het antwoord geen van deze labels is, sla dan „overig“ op. Toon het label als bewerkbare tag.

5. Test met rommelige echte gegevens — lange notities, lege notities, andere talen, een handtekening zonder telefoonnummer — en bekijk twintig outputs naast elkaar voordat u live gaat.

Instructies schrijven die werken

De instructies die u bij elk verzoek meestuurt (vaak de systeemprompt genoemd) zijn waar de kwaliteit vandaan komt.

• Zeg voor wie het is en wat goed is. „Samenvattingen worden door een verkoper in 10 seconden gelezen vóór een gesprek“ geeft het model een doel.
• Leg het formaat vast. Exact aantal opsommingstekens, lengtelimiet, velden, labels.
• Zeg wat te doen bij twijfel. „Als de notities geen volgende stap noemen, schrijf dan ‚Geen volgende stap vastgelegd‘.“ Dit vermindert verzonnen antwoorden.
• Geef twee of drie voorbeelden van goede invoer en uitvoer voor extraheren en classificeren.
• Houd instructies gescheiden van gebruikersinhoud, en label de gebruikersinhoud duidelijk, zodat het model ze kan onderscheiden.

Bewaar de prompts in bestanden in uw codebase, zodat ze versie-beheerd en controleerbaar zijn zoals alle andere code.

De kosten beheersen

LLM-API's rekenen per tokens — kleine stukjes tekst — voor zowel wat u verstuurt als wat terugkomt. De kosten stijgen met de hoeveelheid context per verzoek vermenigvuldigd met hoe vaak het draait. Praktische maatregelen:

• Stuur alleen wat nodig is. De laatste 20 notities, niet de volledige geschiedenis. Kort lange documenten in of splits ze.
• Gebruik het kleinste model dat de klus klaart. Test voordat u standaard het grootste kiest.
• Beperk de lengte van de output met de maximum-tokeninstelling van de API.
• Cache resultaten. Sla een samenvatting op en genereer die alleen opnieuw als de bron verandert, in plaats van bij elke paginaweergave.
• Beperk per gebruiker. Een dagelijkse limiet per account of abonnement voorkomt dat één zware gebruiker, of één script, de rekening doet oplopen.
• Beperk het aantal verzoeken aan het eindpunt, zoals bij elke dure route.
• Stel een budget of melding in in het dashboard van de aanbieder en controleer het gebruik wekelijks na de lancering.
• Houd het tokengebruik per functie bij zodat u weet welke functie wat kost.

Als AI-functies centraal staan in uw product, reken de doorlopende kosten dan door in uw prijs in plaats van ze zelf te dragen.

Veiligheid en vertrouwen

AI-output is probabilistisch. Ze kan fout zijn terwijl ze zelfverzekerd klinkt, en ze kan worden gestuurd door de tekst die ze leest. Bouw daar rekening mee:

• Behandel output als onbetrouwbare invoer. Valideer de structuur, escape die voordat u haar als HTML weergeeft, en voer ze nooit uit als code of databasequery.
• Houd een mens in de lus voor alles met gevolgen — een e-mail versturen, een record wijzigen, een betaling terugboeken. Het model maakt een concept; een persoon bevestigt.
• Bescherm tegen prompt injection. Een document of bericht kan tekst bevatten als „negeer je instructies“. Beperk wat het model kan zien tot wat de huidige gebruiker mag zien, en geef het geen tools die gevoelige acties kunnen uitvoeren zonder dat uw code eerst de rechten controleert.
• Label AI-inhoud zodat gebruikers weten dat een samenvatting of suggestie is gegenereerd en die kunnen controleren.
• Behandel storingen netjes. Aanbieders hebben storingen en snelheidslimieten. Gebruik time-outs, toon een duidelijke melding en laat de rest van de app gewoon werken.
• Let op wat gebruikers versturen. Overweeg bij vrije tekstvelden een moderatiestap, en maak in uw privacybeleid duidelijk dat inhoud door een externe AI-aanbieder wordt verwerkt.

De bredere lijst met controles staat in de beveiligingschecklist voor met AI gebouwde apps.

Veelgemaakte fouten

• Beginnen met een algemene chatbot terwijl één knop „Samenvatten“ of „Categoriseren“ meer mensen zou helpen.
• De sleutel in frontendcode zetten of in een openbare repository.
• De hele database als context meesturen, wat traag, duur is en gegevens van andere gebruikers kan blootgeven.
• Vertrouwen op vrije tekstoutput waar een schema of vaste labelset die controleerbaar zou maken.
• Geen limieten per gebruiker, en dat ontdekken bij de eerste factuur.

AI-functies toevoegen met Mythex

In Mythex voegt u AI toe aan uw eigen app door er in de chat om te vragen, met uw eigen aanbietersleutel. Bewaar de sleutel als projectgeheim — wanneer de agent er een nodig heeft, toont Mythex een geheimenkaart in de chat, zodat u de sleutel niet in het gesprek hoeft te plakken — en de agent schrijft de serverroute, de prompts en de interface. Het AI-gebruik van uw app wordt gefactureerd door uw aanbieder, los van de Mythex-credits die u bij het bouwen gebruikt. In de documentatie staat een startprompt in AI-functies toevoegen met uw eigen API-sleutels.

Veelgestelde vragen