Tre felter skal passe på én gang
En model, der skal have ret på tre felter samtidig, løser en helt anden opgave end en, der skal have ret på ét. 59 procent blev til 91 på et par dage, og halvdelen af det, der stadig var galt, var togbilletter uden ordet DSB på.
Jeg havde arbejdet længe på at automatisere bogføringen, og det virkede. Bare ikke godt nok.
Målet var, at systemet skulle læse et helt bilag rigtigt. Navn, dato og beløb, alle tre på én gang, på samme dokument. Den øvelse ramte 59 procent af gangene, og 59 procent er ubrugeligt, når det er andres regnskaber.
Så brugte jeg et par dage på det i juni. Bagefter ramte den 91.
Hvorfor 59 er lavere, end det lyder
Det tal overraskede mig, indtil jeg regnede efter på, hvad jeg egentlig havde bedt om.
Hvert af de tre felter blev læst rigtigt langt oftere end 59 procent af gangene. Datoen alene ramte 100. Det, jeg havde bedt om, var bare ét dokument, hvor alle tre felter var rigtige på samme tid, og den slags krav ganger sig selv sammen. Tre felter, der hver især kun tager fejl en gang imellem, giver et dokument, der tager fejl overraskende tit.
Det er den slags, jeg tror rigtig mange rammer ind i lige nu. Man tester et felt ad gangen, får pæne procenter, og bygger så en funktion, der kræver dem alle sammen på samme tid. Så falder tallet, uden at nogen af delene er blevet dårligere.
Den vane, det gav mig, er at måle på den enhed, brugeren faktisk får udleveret. Her er enheden et helt bilag, der kan bogføres, uden at nogen retter i det bagefter.
De 9 procent, der var tilbage
Det interessante lå i fejlene.
Omkring halvdelen af de bilag, den stadig tog fejl på, var DSB-regninger, hvor der ingen steder står DSB. Der står ikke noget, modellen kunne have læst. Oplysningen, jeg beder om, findes simpelthen ikke på papiret.
Den forskel afgør, hvad man gør bagefter. Læser modellen dårligt, skal man arbejde på modellen. Mangler oplysningen på dokumentet, skal man hente den et andet sted fra, eller også skal man holde op med at love, at den kan findes.
Datoen og frasorteringen af det, der slet ikke skal bogføres, ramte 100 procent i den samme test. Så systemet var allerede fuldstændig sikkert på to ting og gættede på en tredje, og det er en meget mere brugbar beskrivelse end ét gennemsnit.
Det andet, der skete samme uge
Konto- og momsmatchningen gik fra 53 til 100 procent i min test. Prisen per 1000 bilag faldt 83 procent i samme ombæring.
Bedre og billigere på én uge, og jeg vil gerne være ærlig om, hvorfor begge dele kunne ske samtidig. Det meste af forbedringen kom af at holde op med at spørge om alting på én gang og i stedet stille de spørgsmål hver for sig, hvor svaret er entydigt. Færre tokens per bilag og et mere præcist resultat er den samme ændring set fra to sider.
Hvor langt tallene rækker
Det her er en test fra juni, kørt af mig, på materiale, jeg selv havde valgt.
Jeg skriver det, fordi tallene er sande om det, de måler, og fordi springet fra 59 til 91 er den slags, man kan lave på et par dage, hvis man først finder ud af, hvad man har målt forkert. Men en test er en test. Den siger noget om, hvad systemet kan, når jeg holder i det, og ingenting om, hvad det gør, når det står alene på et kontor med rigtige bilag i en rigtig måned. De tal kom først meget senere, og de så anderledes ud.
At der ligger et par måneder mellem de to slags tal, er nok den mest brugbare ting, jeg kan sige om at bygge med AI. Selve springet tog et par dage. At vide, om det holdt, tog en sommer.