← Terug naar het overzicht

In de praktijk · 8 min lezen

Lokale AI in de praktijk: drie werkprocessen die je kunt verbeteren

De waarde van een klein taalmodel zit niet in een indrukwekkend chatgesprek, maar in werk dat beter of met minder moeite wordt afgehandeld. Documentverwerking, supportroutering en conceptsamenvattingen zijn drie afgebakende toepassingen om dat te onderzoeken.

Begin bij het werk dat nu blijft liggen

Welke informatie wordt steeds opnieuw overgetypt? Welke berichten gaan eerst naar de verkeerde collega? Welke notities leest iemand telkens helemaal door om drie actiepunten te vinden? Zulke vragen leveren een bruikbaarder vertrekpunt op dan “we moeten iets met lokale AI”.

Een klein taalmodel kan een voorstel doen; de toepassing eromheen bepaalt wat ermee gebeurt. Houd die rollen uit elkaar. Een model dat een bedrag uit een document haalt, hoeft geen betaling te kunnen uitvoeren. Een model dat een bericht indeelt, hoeft de klant niet zelfstandig te antwoorden.

De drie voorbeelden hieronder zijn fictieve werksituaties, geen behaalde klantresultaten. Ze laten zien hoe je een proef kunt inrichten en beoordelen. Dezelfde principes werken op kleine schaal thuis: bonnetjes ordenen, correspondentie sorteren of persoonlijke notities samenvatten.

1. Van documenten naar bruikbare velden

Stel dat een klein bedrijf orderbevestigingen ontvangt in verschillende vormen. Een medewerker neemt telkens ordernummer, leverancier, leverdatum en totaalbedrag over in een overzicht. Het meeste werk is niet rekenen, maar herkennen waar de juiste informatie staat.

Een mogelijke route is: document inlezen, tekst beschikbaar maken, velden laten voorstellen, controles uitvoeren en het resultaat naast de bron tonen. Bij een gescande pagina is eerst tekstherkenning nodig, ook wel OCR. Een fout in die stap kan doorwerken in de modeluitvoer. Bewaar daarom niet alleen de gelezen tekst, maar ook de oorspronkelijke pagina voor controle.

Voorbeeld: in de bron staat “Order 4817. Totaal € 242,00. Leverdatum volgt.” Het gewenste resultaat bevat het ordernummer en bedrag, maar geen verzonnen datum. Gebruik voor een ontbrekende waarde bijvoorbeeld null: expliciet geen bekende waarde. Een bestel- of documentdatum mag niet automatisch worden ingevuld als leverdatum.

Vraag een vast uitvoerformaat met precies de velden die je nodig hebt. Ollama ondersteunt hiervoor structured outputs met een JSON-schema: een beschrijving van de velden en toegestane gegevenstypen. Dat helpt om de uitvoervorm te begrenzen. Een passend schema bewijst echter niet dat het bedrag uit de juiste regel komt. [1]

Laat gewone software controleren of verplichte velden aanwezig zijn, getallen goed zijn ingelezen en bedragen aansluiten wanneer het document daarvoor voldoende informatie bevat. Vraag per veld een vindplaats of letterlijk bronfragment en controleer of dat fragment werkelijk bestaat. Laat onduidelijke documenten naar een beoordelingslijst gaan in plaats van ze stilzwijgend door te zetten.

Meet de opbrengst per veld én per volledig document. Een gemiddeld hoge veldscore kan verhullen dat op bijna ieder document nog één fout staat. Meet daarnaast hoeveel tijd controle en correctie kosten. Voor bonnetjes thuis kan een handmatige eindcontrole prima zijn; bij zakelijke verwerking moet duidelijk zijn wie afwijkingen beoordeelt.

Wanneer geen taalmodel? Als je bron al een betrouwbare gegevenskoppeling of een vaste machineleesbare export heeft, is die vaak logischer. Gebruik een taalmodel niet om vrije tekst te reconstrueren uit informatie die al gestructureerd beschikbaar is.

2. Supportvragen naar de juiste plek sturen

Een gedeelde mailbox krijgt vragen over toegang, facturen, storingen en productgebruik. Een eerste proef hoeft niet meteen antwoorden te genereren. Alleen voorstellen welk team het bericht moet behandelen kan al een concrete taak zijn.

Begin met duidelijke categorieën, met voorbeelden en grensgevallen. “Factuur” en “klant ontevreden” sluiten elkaar bijvoorbeeld niet uit: het ene beschrijft het onderwerp, het andere de toon. Bepaal of je één bestemming wilt kiezen of meerdere kenmerken apart wilt vastleggen. Houd onderwerp en urgentie gescheiden.

Voorbeeld: “Ik kan sinds vanochtend niet inloggen en moet vandaag een factuur downloaden.” Een simpele trefwoordregel kan dit naar de financiële afdeling sturen. Een passend voorstel is eerst de toegangsblokkade behandelen, met factuur als bijkomend onderwerp. Dat voorstel moet nog worden getoetst aan de afspraken van jouw team.

Laat het systeem bij tegenstrijdige signalen, meerdere zelfstandige vragen of een onbekend onderwerp doorverwijzen naar een mens. Een door het taalmodel zelf geschreven “95% zeker” is op zichzelf geen betrouwbare foutkans. Baseer automatische verwerking op aangetoonde prestaties en concrete controles, niet alleen op hoe zeker het model klinkt.

Meet per categorie hoeveel berichten terecht worden toegewezen en hoeveel echte gevallen worden gemist. Dat zijn respectievelijk precision en recall. Een verwarringsmatrix maakt zichtbaar welke categorieën door elkaar worden gehaald. Deze maten zijn beschreven in de scikit-learn-documentatie en zijn niet specifiek voor taalmodellen. [2]

Tel ook doorverwijzingen naar mensen mee. Een systeem dat bijna alles laat beoordelen kan weinig automatische fouten maken, maar ook weinig werk besparen. Kijk daarom naar het aandeel zelfstandig afgehandelde berichten, de fouten binnen dat aandeel en het resterende werk voor het team.

Een veilige eerste proef laat het model alleen meelopen: het schrijft een voorstel weg zonder berichten te verplaatsen of te beantwoorden. Vergelijk dat voorstel met de beoordeling van medewerkers. Pas als die vergelijking bruikbaar is, kun je één laag-risicocategorie daadwerkelijk laten routeren.

Wanneer geen taalmodel? Bij stabiele categorieën en voldoende historische voorbeelden kan een klassiek tekstclassificatiemodel een sterke referentie zijn. Ook betere formulieren of duidelijke mailboxregels kunnen het probleem grotendeels oplossen.

3. Een eerste versie maken, zonder het oordeel over te nemen

Een overleg levert losse notities op. Iemand wil daar besluiten, openstaande vragen en actiepunten uit halen. Thuis kan hetzelfde nuttig zijn voor aantekeningen over een project of een vereniging. De taak is niet “schrijf een mooi verhaal”, maar “maak relevante informatie sneller terugvindbaar”.

Voorbeeld: de notitie luidt “Misschien vrijdag live, als de test lukt. Noor vraagt donderdag de status op.” Een slechte samenvatting maakt daarvan “Noor lanceert vrijdag.” Daarmee worden een voorwaarde, een onzeker besluit en een andere actie samengevoegd tot een onjuiste toezegging.

Vraag daarom aparte rubrieken voor besluiten, voorstellen, acties en onzekerheden. Laat bij een actie alleen een eigenaar of deadline invullen als die in de bron staat. Ontbreekt een gegeven, dan blijft het onbekend. Een korte samenvatting mag minder details bevatten, maar mag geen nieuwe afspraken creëren.

Onderzoek naar automatisch gegenereerde samenvattingen laat zien dat goed leesbare tekst informatie kan bevatten die niet door het brondocument wordt ondersteund. Het aangehaalde onderzoek uit 2020 is geen meting van huidige kleine modellen, maar onderbouwt waarom brongetrouwheid een aparte controle verdient. [3]

Maak controle eenvoudig: toon de samenvatting naast de oorspronkelijke notities en koppel belangrijke uitspraken aan hun bronpassage. Beperk niet alleen de lengte, maar geef ook aan welke feiten behouden moeten blijven. Bij lange documenten kan een samenvatting per onderdeel helpen; controleer vervolgens of de uiteindelijke samenvoeging geen tegenstrijdigheden of voorwaarden weglaat.

Meet feitelijke fouten, belangrijke weglatingen en correctietijd. Laat de beoordelaar ook beoordelen of de samenvatting nuttig is voor de bedoelde lezer. Een correcte maar bijna even lange herhaling levert weinig op. Publiceer of verstuur de eerste proef niet automatisch namens iemand anders.

Wanneer geen taalmodel? Als je uitsluitend expliciete acties wilt verzamelen, kan een beter notitiesjabloon met vaste velden meer opleveren. Overweeg ook zinnen letterlijk te selecteren in plaats van ze opnieuw te laten formuleren.

Wat voegt lokaal draaien hier eigenlijk toe?

Geen van deze taken vereist per definitie lokale uitvoering. Het kan interessant zijn wanneer je de modelverwerking op een eigen apparaat of bedrijfsnetwerk wilt houden, zonder verbinding moet kunnen werken of een vaste modelversie wilt blijven gebruiken. Dat zijn redenen om de optie te testen, geen bewijs van betere inhoudelijke kwaliteit.

Controleer wel de volledige route. Een lokaal model met een externe OCR-dienst verwerkt niet alles lokaal. Hetzelfde geldt voor cloudopslag, zoekdiensten en logs waarin documentinhoud belandt. Beperk toegangsrechten en laat alleen noodzakelijke gegevens door de toepassing gaan.

Een klein model is vooral aantrekkelijk als de taak voldoende begrensd is om fouten zichtbaar te maken. Worden uitzonderingen steeds talrijker of blijft menselijke correctie nodig op vrijwel ieder resultaat, dan moet je de taak versmallen, een andere oplossing vergelijken of stoppen. Meer automatisering is niet vanzelf meer waarde.

Van idee naar een toetsbare proef

Een bruikbare proefomschrijving past in één alinea: “Voor deze soort invoer doet het systeem dit voorstel; deze fouten zijn onacceptabel; iemand controleert deze gevallen; we vergelijken de benodigde tijd met de huidige werkwijze.” Maak die afspraken voordat je een model kiest.

  1. Kies één terugkerende taak. Neem bijvoorbeeld alleen orderbevestigingen van een beperkt aantal leveranciers, niet direct de hele administratie.
  2. Bewaar representatieve voorbeelden. Neem normale gevallen, ontbrekende informatie en bekende uitzonderingen mee. Houd aparte voorbeelden achter voor de eindbeoordeling.
  3. Laat het systeem eerst voorstellen doen. Schrijf nog niet automatisch terug naar de administratie of klantomgeving. Leg afwijkingen en de beoordeling ervan vast.
  4. Beslis op kwaliteit én totale inspanning. Vergelijk voorbereiding, wachttijd, controle, correctie en beheer met de bestaande werkwijze. Een snelle modelaanroep die extra herstelwerk veroorzaakt is geen verbetering.

Begin niet met een belofte van een vast besparingspercentage. Leg eerst vast hoeveel werk er nu is en wat een fout kost in extra werk of gemiste service. Een geslaagde proef geeft je vervolgens een begrensd besluit: deze taak kan verder worden ontwikkeld, onder deze voorwaarden. Dat is meer waard dan een demo die op één mooi voorbeeld overtuigt.

Bronnen & verantwoording

De uitleg en afwegingen zijn van deze site. Productspecificaties komen uit de onderstaande primaire bronnen; mogelijkheden kunnen veranderen.

  1. Ollama — structured outputs en JSON-schema’s
  2. scikit-learn — precision, recall en F-measures
  3. Maynez e.a. (ACL 2020) — On Faithfulness and Factuality in Abstractive Summarization
VERDER VERKENNENEen eigen praktijktest opzetten: voorbij de benchmark