AI Engineer interviewvragen en antwoorden voor jouw gesprek

Voorbeeldantwoord

Ik begin met duidelijke succescriteria en een evalset, zodat ik kwaliteit objectief kan meten. Daarna voeg ik monitoring, fallbacks, guardrails en een budget voor latency en kosten toe. Ik version prompts, retrieval en modelkeuzes alsof het code is, en ik test edge cases expliciet. De stap van demo naar productie zit vooral in betrouwbaarheid, observability en beheer.

Voorbeeldantwoord

Ik stel een representatieve evalset samen met gewenste uitkomsten en lastige randgevallen. Daarna combineer ik automatische metrics, zorgvuldig gebruik van LLM-as-judge en menselijke review op een steekproef. Ik kijk niet alleen naar accuracy, maar ook naar hallucination rate, consistentie en taak-specifieke criteria. Elke wijziging aan prompt, retrieval of model moet door dezelfde regressie-evaluatie heen.

Voorbeeldantwoord

Ik meet eerst waar de tijd en kosten echt vandaan komen. Vaak helpt het om caching toe te passen, kleinere modellen te gebruiken voor eenvoudige cases en alleen op te schalen naar een groter model wanneer dat nodig is. Ook retrieval optimaliseren is vaak winstgevend, omdat je dan minder context naar het model stuurt. Ik check altijd of de kwaliteit gelijk blijft met een vaste evalset.

Voorbeeldantwoord

Ik ground het model in betrouwbare, retrieved context en laat het alleen antwoorden binnen de scope die je hebt afgesproken. Ik gebruik citations waar het kan, dwing gestructureerde output af en bouw ruimte in voor 'ik weet het niet'. Voor risicovolle use cases zet ik human-in-the-loop in en log ik input en output voor controle. Betrouwbaarheid komt uit systeemontwerp, niet alleen uit een betere prompt.

Voorbeeldantwoord

Ik begin met de goedkoopste en snelste optie die het probleem kan oplossen, meestal prompting plus retrieval. Als het gaat om consistente output, stijl of een niche gedragspatroon dat je niet stabiel uit prompting krijgt, dan kan fine-tuning zinvol zijn. Zit je tegen capability- of kostenlimieten aan, dan kijk ik naar een ander model of model routing. Ik kies de techniek op basis van het probleem, de data en de totale kosten.

RAG haalt relevante documenten op uit een kennisbron, meestal via vector search op embeddings, en stopt die context in de prompt zodat het model antwoordt op basis van actuele en autoritaire informatie. Je gebruikt het wanneer antwoorden privé, groot of snel veranderend zijn en niet betrouwbaar in het model zelf zitten. Het helpt hallucinations verminderen en is vaak goedkoper en flexibeler dan fine-tuning voor kennisvragen.

Embeddings zijn dichte numerieke vectoren die de semantische betekenis van tekst, afbeeldingen of andere data vastleggen, zodat vergelijkbare items dicht bij elkaar liggen in vector space. Je gebruikt ze voor semantic search, clustering, recommendation en de retrieval-stap in RAG. De keuze van embedding model en chunking-strategie heeft direct invloed op retrieval quality.

Temperature bepaalt hoeveel randomness je toelaat bij token sampling: laag geeft voorspelbare, consistente output en past bij feitelijke of gestructureerde taken, hoog geeft meer variatie en creativiteit maar minder consistentie. Voor production features houd ik temperature meestal laag. Voor brainstormen of variabele generatie kan een hogere temperature nuttig zijn, maar het maakt het systeem niet volledig deterministic.

De context window bepaalt hoeveel tokens het model tegelijk kan verwerken, dus lange documenten of lange gesprekken moet je bewust beheren. Ik werk eromheen met retrieval om alleen relevante chunks op te halen, summarization van eerdere turns en chunking met overlap. Ook reserveer ik tokens voor instructies en output, zodat belangrijke context niet wordt afgekapt.

Prompt injection is wanneer onbetrouwbare input het model probeert te manipuleren om instructies te negeren, bijvoorbeeld een kwaadaardige passage in een document die data probeert te lekken of een actie probeert af te dwingen. Je verdedigt je met strikte scheiding tussen trusted instructions en untrusted content, door tool outputs en documenten als data te behandelen, permissions te beperken, outputs te valideren en bij gevoelige acties een mens in de loop te houden. Defense in depth is essentieel, omdat geen enkele maatregel genoeg is.

Situatie: een support assistant gaf ineens zelfverzekerd foutieve policy-antwoorden na een data-update. Taak: ik moest het vertrouwen snel herstellen. Actie: ik traceerde het naar verouderde en conflicterende documenten in de knowledge base, herstelde de retrieval-bron, voegde citation requirements toe en breidde de evalset uit met policy-vragen. Resultaat: de accuracy herstelde en de nieuwe evals vingen later automatisch een vergelijkbaar probleem.

Situatie: leadership verwachtte perfecte accuracy op een genuanceerde juridische taak. Taak: ik moest realistische verwachtingen neerzetten zonder het project te killen. Actie: ik liet de error rate zien op een echte evalset, legde de beperkingen van huidige modellen uit en stelde een human-in-the-loop ontwerp voor op de risicovolle onderdelen. Resultaat: we shipten een nuttige assistive tool met passende oversight in plaats van een te ambitieus autonoom systeem.

Situatie: een classificatietaak leek te vragen om een dure fine-tuned modeloplossing. Taak: ik moest waarde leveren op een kostenefficiënte manier. Actie: ik bouwde eerst een goed geprompt kleiner model met few-shot voorbeelden en vergeleek dat met de eis. Resultaat: het haalde de gewenste accuracy tegen een fractie van de kosten en doorlooptijd, waardoor we fine-tuning konden bewaren voor een echt moeilijk vervolgprobleem.

Situatie: users klaagden dat de assistant te langdradig was en hun intentie miste. Taak: ik moest de tevredenheid verhogen. Actie: ik analyseerde failure transcripts, verscherpte de prompt voor kortere en beter onderbouwde antwoorden, voegde intent clarification toe en bouwde een eval die aansloot op de echte klachten. Resultaat: de satisfaction scores gingen merkbaar omhoog en het aantal escalaties naar humans daalde.