Home / Blog / Techniek

We hebben onze onkostenparser verwijderd

29 augustus 2026 · 8 min leestijd · Dimesum Engineering

Onze regelparser hield het een week vol, waarna vier gewone zinnen geld op de verkeerde persoon zetten en één weigeringsregel de hele stapel bewakers verving.

We hebben een parser verwijderd die we net af hadden. Dimesums eerste poging tot het parsen van onkosten in natuurlijke taal was een engine op basis van regels, en vier gewone zinnen stuurden hem met pensioen: dinner 12-08 400 werd gelezen als €12, ravioli 600 zette een lid met de naam Ravindra in de verdeling, kirana 500 belastte een lid met de naam Kiran, en refund -483.50 werd een last van €483,50.

Een zin begrijpen is het werk van het model en van niets anders. Wat de engine op basis van regels verving is één trede genaamd amount_only: één enkel getal, alleen teruggegeven wanneer de tekst precies één ondubbelzinnige geldkandidaat bevat, en nooit een bewering over personen. Twee kandidaten betekent geen bedrag. Eén regel verving een groeiende stapel bewakers.

Vier zinnen beëindigden de regelparser

De verwijderde parser dekte de volledige set entiteiten die ons AI-ontwerpdocument voorschrijft: het matchen van leden en bijnamen, een uitsluitingslexicon, het afleiden van de betaler, een categorielexicon, en per veld afgestemde betrouwbaarheden. Elk van de vier storingen hieronder had een voor de hand liggende oplossing. Elke oplossing was een nieuwe bewaker met zijn eigen blinde vlek.

Twee van de vier zijn één bug in andere kleren. Fuzzy matching kan een gerecht niet van een persoon onderscheiden, of een winkel van een persoon, want op tekenniveau lijken ravioli en Ravindra echt op elkaar. Eis een langere prefix-match en je breekt ravi, precies het geval waarvoor de matcher bestaat.

Elke bewaker die je toevoegt brengt twee nieuwe formuleringen naar boven

Een regelparser faalt in één specifieke vorm: hij antwoordt zelfverzekerd en fout. Een leeg veld kost een gebruiker één tik. Een verkeerde verdeling kost vertrouwen in het grootboek, en in een app die het delen van geld bijhoudt is het grootboek het product. De vier rijen hierboven zijn geen bijna-missers, het zijn geldbugs.

De tredmolen is het echte argument, niet één enkel defect. Voeg een datumbewaker toe en het geval van het bestelnummer arriveert. Voeg een bewaker voor bestelnummers toe en platte getallen arriveren, dan hoeveelheden, dan tafelnummers. De lijst met bewakers groeit en convergeert nooit, want natuurlijke taal heeft geen eindige set formuleringen om op te sommen.

Wat live ging is één getal en een weigering

amount_only is de gedegradeerde trede uit ons AI-ontwerpdocument, letterlijk geïmplementeerd. Die trede luidt "het gewone formulier met client-side vooraf ingevulde bedrag-regex", dus de trede geeft een bedrag terug en niets anders: geen omschrijving, geen categorie, geen betalers, geen deelnemers, geen uitsluitingen. Het kost niets en belt niemand, en daarom draaien test en CI erop.

Ambiguïteit is een weigering, geen tiebreak

De hele regel leeft in één functie, extract_amount_minor. Een bedrag komt alleen terug wanneer de tekst er precies één kandidaat voor bevat, dus order 90210 dinner 400 en flat 402 rent 15000 geven leeg terug in plaats van een winnaar te kiezen. Een van een valutateken voorzien bedrag telt als ondubbelzinnig, zelfs naast kale getallen, en daarom leest split 3 ways ₹1,200 nog steeds ₹1,200.

Een bedrag met een minteken is helemaal geen bedrag in plaats van de absolute waarde ervan. -500, minus 200 en de (500) van de boekhouder komen allemaal leeg terug, want het veld is een last en de cijfers houden terwijl je het teken laat vallen wijst het geld de andere kant op dan de tekst. Haakjes tellen alleen wanneer ze op het bedrag zelf sluiten, dus (500 each) blijft een tussenzin.

De valuta bepaalt de rekenkunde

Minor units zijn de enige vorm die geld in Dimesum aanneemt, dus de trede converteert met een ISO 4217-exponententabel in plaats van een hardgecodeerde vermenigvuldiging met 100. De Japanse yen heeft helemaal geen subeenheid, en ×100 blaast een bon van ¥1,200 honderd keer op. Een bedrag fijner dan de kleinste eenheid van de valuta wordt geweigerd in plaats van afgerond, want het afronden van een bedrag dat iemand heeft getypt is er een verzinnen.

Indiase getalwoorden horen bij het schrijven van een bedrag, niet bij het begrijpen van een zin. 1.2k, 2 lakh en 500/- lossen allemaal op, net als 1,200. Alles boven het maximumbedrag van het grootboek komt leeg terug, dus een verkeerd getypt bedrag maakt één veld leeg in plaats van verderop een integer te laten overlopen.

De live trede haalt de 0.6-drempel voor bruikbaarheid nooit

Ons parse-contract laat een parse onder 0.6 algehele betrouwbaarheid vallen en stuurt de gebruiker naar het gewone formulier. amount_only rapporteert 0.3 op elk antwoord, en de constante is structureel in plaats van afgestemd. Een op zichzelf staand bedrag is geen parse, dus de trede zit op de helft van de drempel, wat ze ook vond. Eén constante voor elk antwoord houdt ze daar: een score per geval is een score die iemand uiteindelijk omhoog duwt.

De trede rapporteert ook helemaal geen prompt. Zowel prompt_id als prompt_version komen null terug, want de trede las geen prompt. Er een noemen zou elk evaluatieresultaat toeschrijven aan een promptversie die de trede nooit zag, en het evaluatieharnas is het enige instrument dat een trede mag promoveren tot suggestie met één tik, bij 95% precisie op bedrag en deelnemers samen.

Nog twee treden zijn gedeclareerd en geen van beide is live. De cheap-fast-trede heeft een Groq-adapter voor openai/gpt-oss-120b en geen sleutel; de midtrede heeft geen adapter. Een van beide selecteren faalt bij het opstarten in plaats van bij het eerste verzoek van een gebruiker, want een LLM rekent per aanroep en een factureerbare afhankelijkheid moet gesloten falen.

Niets boekt automatisch, dus een leeg veld kost één tik

Een leeg veld kost zo weinig alleen omdat geen enkele vastlegging in Dimesum geld kan wegschrijven. Een vastlegging maakt een suggestie, een persoon bevestigt die, en de bevestiging is wat de onkost aanmaakt. Briefbeslissing D5 stelt de regel, en .go-arch-lint.yml handhaaft die: de ingestiecontext krijgt geen enkele afhankelijkheid van expense of ledger, dus een vastlegging kan zelfs per ongeluk geen journaalpost boeken. CI laat de import falen, wat we controleerden door er één toe te voegen.

De vastlegging bewaart de ruwe tekst wat de parser ook doet, en noemt welke velden onopgelost zijn. De client markeert die lege velden in plaats van een verzonnen concept te tonen, en dat is het verschil tussen een parser die niets zegt en een die raadt. Bevestigen leidt zijn onkost-id af uit de suggestie-id, dus een dubbele tik speelt opnieuw af in plaats van twee keer te belasten.