LLM-integration
LLM-integration i jeres produkt
Vi indbygger LLM'er — OpenAI, Anthropic, eller open source via Bedrock og Azure — i jeres eksisterende produkter. Med struktureret prompting, evaluering og guardrails der holder modellen på sporet i produktion.
Bygget til produktion
Det adskiller en demo fra et produkt
- Struktureret output via tool-use
- Schema
- Pipeline der måler kvaliteten over tid
- Eval
- PII-redaktion og prompt-injection-forsvar
- Guardrails
- Azure OpenAI eller Bedrock i Frankfurt
- EU
Sådan tænker vi LLM'er i produkt
Vi behandler LLM'er som software.
De fleste LLM-integrationer falder samme sted: en imponerende demo, en holdning om at "vi skal også have AI", og så et projekt der dør i overgangen til produktion fordi modellen hallucinerer, koster for meget eller ikke kan måles. Vi bygger LLM-features der overlever den overgang — fordi vi behandler dem som software, ikke som magi.
Vi starter altid med use-casen: hvad er det for et problem en sprogmodel faktisk løser bedre end en klassisk løsning? Nogle gange er svaret "ingenting", og så siger vi det. Når der er en god use-case (sammenfatning, klassifikation, struktureret udtrækning, samtale-grænseflade), bygger vi en arkitektur med struktureret output, retry- og fallback-logik, evaluering af kvaliteten over tid og styring af modeludgifter.
Vi tager også guardrails alvorligt: prompt injection-beskyttelse, PII-redaktion før modellen ser data, output-validering og audit-log af hvad modellen sagde til hvilken bruger. Det er den slags ting der adskiller en AI-feature der kan stilles op overfor jeres kunder fra én der bør forblive et internt eksperiment.
Hvad I får leveret
AI-features bygget til at overleve overgangen til produktion.
Struktureret prompting, evaluering, guardrails og forbrugs-styring — ikke kun en demo.
Use-case-vurdering og prototype
Vi starter med en uges discovery: hvad er problemet, hvilke modeller er kandidater, og hvad er en realistisk evalueringsmetric? Du får en kørende prototype og en ærlig vurdering af om det er værd at bygge videre.
Struktureret prompting og output
Vi designer prompts, system messages og few-shot-eksempler. Output valideres mod et JSON-schema (OpenAI structured outputs / tool use) så jeres backend kan stole på det vi får tilbage.
Retrieval (RAG) når det giver mening
Hvis modellen skal svare på baggrund af jeres egne data, bygger vi et RAG-lag med embeddings (Voyage, OpenAI, eller open source), vector-store (pgvector, Pinecone, Vectorize) og en retriever der kan måles og forbedres.
Guardrails og sikkerhed
Prompt-injection-detektion, PII-redaktion før modellen ser data, output-moderation (OpenAI Moderation eller Lakera), tool-use sandboxing og audit-log på hver eneste model-kald.
Evaluering og A/B-test
Vi sætter en evalueringspipeline op (LangSmith, Braintrust eller egen) der scorer output på de metrics der betyder noget for jeres use-case. Modeller, prompts og parametre kan A/B-testes i produktion uden at gå offline.
Cost- og latency-styring
Vi cacher hvor det giver mening, vælger den billigste model der løser opgaven godt nok, batcher requests og overvåger forbrug pr. feature og pr. kunde — så I ved præcis hvad AI-funktionerne koster jer.
Det her bør I vide
Vigtige afvejninger før I går i gang.
Modelvalg og leverandør-lock-in
Frontier-modeller (GPT-5, Claude Opus 4.5) leverer kvalitet for krævende opgaver, men de er dyre og ændrer sig oftere end I bryder jer om. Til produktionsfeatures vælger vi typisk en blanding: en frontier-model til den vanskelige logik, en mindre/billigere model til klassifikation og forbehandling. Vi designer abstraktionen så I kan skifte model uden at omskrive halvdelen af koden.
Datafortrolighed og hvor data lander
Bruger I OpenAI eller Anthropic via deres API'er, lover de ikke at træne på jeres data — men data passerer stadig deres infrastruktur. Hvis I har strikse data-residency-krav, kører vi via Azure OpenAI i EU, AWS Bedrock i Frankfurt, eller selv-hostede modeller. Vi gennemgår det grundigt i discovery.
Hallucinationer og evaluering
Sprogmodeller fabrikerer ting med fuld overbevisning. Det er ikke en bug — det er sådan de virker. Vi designer altid med antagelsen om at output kan være forkert: validering, citationskrav (RAG), bruger-feedback-loops, og en evalueringspipeline der måler kvaliteten over tid. Uden evaluering ved I aldrig om en prompt-ændring eller modeludskiftning gjorde tingene bedre eller værre.
Driftsomkostninger
AI-features har variable omkostninger der skalerer med brug. Det betyder at I skal kunne se forbrug pr. feature, pr. kunde og over tid — ellers står I om tre måneder med en regning der overrasker økonomi. Vi bygger forbrugs-monitoring ind fra start og diskuterer eventuelle pricing-justeringer hvis features koster mere end de bidrager.
FAQ
Det folk plejer at spørge om.
Hvilke modeller bruger I typisk?
Det afhænger af opgaven. Til klassifikation, struktureret udtrækning og lette samtale-flows bruger vi ofte mindre modeller (GPT-5 Mini, Claude Haiku, Llama på Bedrock) — de er billige, hurtige og rigeligt smarte. Til komplekst ræsonnement, kode-generering og krævende skrive-opgaver bruger vi frontier-modeller (GPT-5, Claude Opus). Vi designer abstraktionen så modelvalget er en konfiguration, ikke en omskrivning.
Kan vi bruge open source-modeller i stedet?
Ja, hvor det giver mening. Llama, Mistral og Qwen kan køre på Bedrock, Together, Groq eller jeres egen GPU-infrastruktur. For mange use-cases er kvaliteten god nok, og I får forudsigelig pris og fuld kontrol over data. For andre — særligt komplekst ræsonnement — er frontier-modellerne stadig mærkbart bedre. Vi måler det konkret for jeres use-case i stedet for at gætte.
Hvad med GDPR og persondata?
Vi behandler det som et krav fra dag ét. Vi redigerer PII ud før den passerer modellen hvor det kan undgås, vælger leverandører med EU-data-residency (Azure OpenAI EU, AWS Bedrock Frankfurt), laver databehandleraftaler og logger hvad modellen så på hvilken bruger. Hvis I har særligt følsomme data (sundhed, finans), kan vi køre selv-hostede modeller på jeres egen infrastruktur.
Hvor lang tid tager en LLM-integration?
En målrettet feature (smart søgning, sammenfatning, klassifikation) er typisk 4–8 uger fra discovery til produktion. En større integration med flere features, RAG over jeres egne data, evaluering og cost-styring er typisk 2–4 måneder. Vi går altid live tidligt med en afgrænset version og udvider derfra — det er den hurtigste måde at finde ud af hvad der faktisk virker for jeres brugere.
Hvordan måler vi om AI-featuren er værd at have?
Vi definerer succeskriterier i discovery — det kan være konverteringsrate, support-ticket-reduktion, gennemsnitlig opgaveløsningstid eller kvalitetsscore via menneskelig review. Vi sætter målingen op fra dag ét og rapporterer løbende. Hvis featuren ikke flytter de tal vi blev enige om, så fjerner vi den eller redesigner — det er bedre end at lade den blive hængende fordi "den koster jo ikke meget".
Klar til at starte?
Lad os tage en uforpligtende snak.
Vi vender tilbage indenfor en arbejdsdag med konkret input — ikke et standardtilbud.