Forsiden / Blogg / Teknikk

Vi slettet utgiftsparseren vår

29. august 2026 · 8 min lesing · Dimesum Engineering

Dimesum slettet sin regelbaserte utgiftsparser etter at fire vanlige setninger ga pengefeil, og erstattet den med ett trinn som returnerer ett entydig tall eller ingenting.

Vi slettet en parser vi nettopp var ferdige med å skrive. Dimesums første forsøk på utgiftsføring med naturlig språk var en regelmotor, og fire vanlige setninger pensjonerte den: dinner 12-08 400 ble lest som 12 kr, ravioli 600 la et medlem ved navn Ravindra inn i delingen, kirana 500 belastet et medlem ved navn Kiran, og refund -483.50 ble en kostnad på 483,50 kr.

Å forstå en setning er modellens jobb og ingen andres. Det som erstattet regelmotoren er ett trinn kalt amount_only: ett enkelt tall, som bare returneres når teksten inneholder nøyaktig én entydig pengekandidat, og aldri en påstand om personer. To kandidater betyr ingen sum. Én regel erstattet en voksende haug med vakter.

Fire setninger gjorde slutt på regelparseren

Den slettede parseren dekket hele entitetssettet som AI-designdokumentet vårt spesifiserer: matching av medlemmer og kallenavn, et eksklusjonsleksikon, utleding av betaler, et kategorileksikon, og finjusterte konfidenser per felt. Hver av de fire feilene under hadde en åpenbar løsning. Hver løsning var en ny vakt med sitt eget blindpunkt.

To av de fire er én feil i forskjellige klær. Uskarp matching kan ikke skille en rett fra en person eller en butikk fra en person, for på tegnnivå ligner ravioli og Ravindra faktisk på hverandre. Krev en lengre prefiks-match, og du ødelegger ravi, som er tilfellet matcheren finnes for.

Hver vakt du legger til, får frem to nye formuleringer

En regelparser feiler på én bestemt måte: den svarer selvsikkert og feil. Et tomt felt koster brukeren ett trykk. En feil deling koster tillit til hovedboken, og i en app for deling av utgifter er hovedboken produktet. De fire radene over er ikke nestenbommer, de er pengefeil.

Tredemøllen er det egentlige argumentet, ikke noen enkelt defekt. Legg til en dato-vakt, og ordrenummer-tilfellet dukker opp. Legg til en ordrenummer-vakt, og rene tall dukker opp, så antall, så bordnumre. Vaktlisten vokser og konvergerer aldri, for naturlig språk har ikke noe endelig sett med formuleringer å telle opp.

Det som ble levert er ett tall og en avvisning

amount_only er det degraderte trinnet fra AI-designdokumentet vårt, implementert bokstavelig. Det trinnet lyder «det enkle skjemaet med forhåndsutfylling av beløp via regex på klientsiden», så nivået returnerer et beløp og ingenting annet: ingen beskrivelse, ingen kategori, ingen betalere, ingen deltakere, ingen eksklusjoner. Det koster ingenting og ringer ingen, og derfor kjører test og CI på det.

Tvetydighet er en avvisning, ikke en omkamp

Hele regelen bor i én funksjon, extract_amount_minor. Et tall kommer tilbake bare når teksten inneholder nøyaktig én kandidat til det, så order 90210 dinner 400 og flat 402 rent 15000 returnerer tomt i stedet for å kåre en vinner. Et tall merket med valuta regnes som entydig selv ved siden av rene tall, og derfor leser split 3 ways ₹1,200 fortsatt 1 200 kr.

Et negert tall er ikke noe beløp i det hele tatt, snarere enn sin absoluttverdi. -500, minus 200 og regnskapsførerens (500) kommer alle tilbake tomme, for feltet er en kostnad, og å beholde sifrene mens fortegnet droppes peker pengene motsatt vei av teksten. Parenteser teller bare når de lukker om selve tallet, så (500 each) forblir en parentes.

Valutaen bestemmer regnestykket

Minorenheter er den eneste formen penger tar i Dimesum, så nivået konverterer med en ISO 4217-eksponenttabell i stedet for en fastkodet multiplikasjon med 100. Den japanske yenen har ingen underenhet i det hele tatt, og ×100 blåser en kvittering på ¥1 200 opp hundre ganger. Et tall finere enn valutaens minste enhet avvises i stedet for å rundes av, for å runde av et beløp noen har tastet inn er å finne opp ett.

Indiske tallord er en del av å skrive et tall, ikke en del av å forstå en setning. 1.2k, 2 lakh og 500/- løses alle opp, som 1,200. Alt over hovedbokens maksimumsbeløp kommer tilbake tomt, så et feiltastet tall tømmer ett felt i stedet for å flyte over et heltall nedstrøms.

Trinnet i drift passerer aldri den brukbare 0.6-porten

Parse-kontrakten vår forlater en parse under 0.6 samlet konfidens og setter brukeren tilbake til det enkle skjemaet. amount_only rapporterer 0.3 på hvert svar, og konstanten er strukturell snarere enn finjustert. Et ensomt beløp er ikke en parse, så trinnet ligger på halvparten av porten uansett hva det fant. Én konstant for hvert svar er det som holder den der: en score per tilfelle er en score noen til slutt dytter oppover.

Nivået rapporterer også ingen prompt overhodet. Både prompt_id og prompt_version kommer tilbake null, for trinnet leste ingen prompt. Å navngi en ville tilskrive hvert eval-resultat en prompt-versjon nivået aldri så, og eval-riggen er det eneste instrumentet som har lov til å forfremme et trinn til ett-trykks forslag, ved 95 % presisjon på beløp og deltakere samlet.

To ytterligere nivåer er deklarert, og ingen av dem er i drift. cheap-fast-nivået har en Groq-adapter for openai/gpt-oss-120b og ingen nøkkel; mid-nivået har ingen adapter. Å velge ett av dem feiler ved oppstart snarere enn ved brukerens første forespørsel, for en LLM fakturerer per kall, og en fakturerbar avhengighet må feile lukket.

Ingenting bokføres automatisk, så et tomt felt koster ett trykk

Et tomt felt koster så lite bare fordi ingen registrering i Dimesum kan skrive penger. En registrering lager et forslag, en person bekrefter det, og bekreftelsen er det som skaper utgiften. Brief-beslutning D5 fastsetter regelen, og .go-arch-lint.yml håndhever den: registreringskonteksten nektes enhver avhengighet av expense eller ledger, så en registrering kan ikke bokføre en journal selv ved en feil. CI feiler importen, noe vi sjekket ved å legge til en.

Registreringen beholder råteksten uansett hva parseren gjør, og navngir hvilke felter som er uløste. Klienten fremhever de tomme feltene i stedet for å vise et oppdiktet utkast, som er forskjellen mellom en parser som ikke sier noe og en som gjetter. Bekreft utleder sin utgifts-id fra forslags-id-en, så et dobbelttrykk spiller av på nytt i stedet for å belaste to ganger.