Geen eval-loop
De POC werkte 'wel ergens'. Maar nooit was gemeten op hoeveel testcases het correct werkte, waar het brak, of hoe vaak. Zonder eval is verbetering gokken.
Veel AI-POCs stranden. Niet altijd omdat het idee fout was, maar omdat de eval ontbrak, de scope te breed werd, of de stack niet meeschaalde naar productie. In één dag kijken we waar het breekt en bouwen we de versie die wel werkt.
Drie patronen die we keer op keer terugzien. Niet als verwijt, wel als check.
De POC werkte 'wel ergens'. Maar nooit was gemeten op hoeveel testcases het correct werkte, waar het brak, of hoe vaak. Zonder eval is verbetering gokken.
Begonnen met 'beantwoord factuur-vragen', geëindigd met 'doe alles wat onze klantenservice doet'. De model-kwaliteit wordt slecht naarmate de scope onhanteerbaar wordt.
Een POC met een notebook en hard-coded keys werkt in demo. In productie strandt het op latency, kosten, security of integratie met legacy-systemen die nooit getest waren.
We diagnostiseren en bouwen. We maken geen marketing-rapport van waarom het mislukte.
Eerst begrijpen wat er nu niet werkt, dan bouwen wat wel werkt.
We doorlopen de huidige POC, zien wat hij wel en niet doet, en lijsten de gaten op.
Eval-set maken, testcases draaien, kijken waar het breekt: model, prompt, tool, data of stack.
Versie 2-richting bepalen. Soms is het een prompt-fix, soms een ander model, soms herbouwen op een andere stack.
Implementeren van de geïdentificeerde fix. Direct testen tegen de eval-set.
Draai de eval-set opnieuw. Vergelijk met de oorspronkelijke POC. Documenteer het verschil.
Eerlijke conclusie: het werkt nu, of we hebben geleerd dat deze aanpak niet werkt. In beide gevallen heb je een rapport en eval om mee verder te gaan.
Vier deliverables die je intern overdraagbaar maken.
Ja. We hebben geen voorkeur voor onze eigen code. Vraag wel om de bestaande codebase en eventuele documentatie vooraf, zodat we niet de eerste twee uur van de dag aan het reverse-engineeren zijn.
Dan zeggen we dat eerlijk en leg je in het rapport uit waarom. Soms ligt het aan de use case (AI is niet de juiste oplossing voor het probleem), soms aan data-kwaliteit, soms aan ambitie. Beter na één dag weten dan na nog drie maanden investering.
Beide. We kennen de standaard valkuilen van agent-flows (planning loopt vast, tools werken niet zoals verwacht, mens-in-de-lus ontbreekt) en van klassieke RAG/prompt-setups. De diagnose-fase laat zien waar de bottleneck zit.
Bij voorkeur werken we met geanonimiseerde of synthetische data op de dag. Bij gevoelige data kiezen we self-hosted modellen of een lokale eval-loop. Bespreken we in de intake.
Als versie 2 werkt en je naar productie wil: we rollen door naar een Appfront-traject voor de productie-build met monitoring, security en SSO. Als het project beter gestopt kan worden, helpt het rapport om dat intern uit te leggen.
Stuur ons een korte beschrijving van wat de POC moest doen en wat hij niet doet. We bekijken in de intake of de rescue-dag past.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.