Liquid AI LFM2.5-230M: lille model, stor

Det interessante ved LFM2.5-230M er ikke, at den er lille. Det er, at den er lille og alligevel vinder. Til dataekstraktion, altså opgaver hvor en model skal læse et dokument, en formular, en kvittering eller en e-mail og omsætte indholdet til struktureret data som JSON eller felter i et system, slår den modeller der er markant større. Det betyder, at antallet af parametre ikke længere er en pålidelig indikator for, hvor god en model er til en specifik opgave. En model bygget og trænet til ét formål kan slå en generalistmodel, selv når generalistmodellen er langt større.

Det er en vigtig pointe for virksomheder, der i dag antager, at de skal købe adgang til de største og dyreste modeller for at få god kvalitet. For opgaver som dataekstraktion er det ikke længere sandt.

Dataekstraktion er en af de mest almindelige, men mindst glamourøse AI-opgaver i virksomheder. Det er modellen, der læser en faktura og finder beløb, dato og leverandørnavn. Det er modellen, der scanner en kontrakt for nøgledatoer. Det er modellen bag ved formularudfyldning, dokumentklassificering og datavask forud for et system. Det er kedeligt arbejde, men det er også arbejde, der i dag ofte kræver en stor, dyr model i skyen, fordi opgaven kræver præcision.

LFM2.5-230M ændrer den ligning. Modellen er ifølge Liquid AI bygget til agentiske arbejdsgange, der kører direkte på enheden, og på benchmarks for dataekstraktion rammer den højere end modeller med flere parametre. Hvordan den er trænet, har jeg ikke tal eller detaljer på, som jeg kan stå inde for. Men resultatet peger samme vej som de øvrige små, afgrænsede modeller vi har set det seneste år: generel intelligens og opgavespecifik dygtighed er to forskellige ting, og for mange virksomhedsopgaver er det sidste, der tæller.

Det afgørende er, hvor modellen kan køre. En model på 230 millioner parametre fylder under 400 MB i hukommelsen og er lille nok til at eksekvere lokalt på enheder, der aldrig ville kunne håndtere en stor sprogmodel, fra smartphones til en Raspberry Pi. Det betyder, at dataekstraktion ikke længere kræver et kald til en cloud-API for hver eneste opgave.

Det har tre konkrete konsekvenser. For det første forsvinder latenstiden ved at sende data frem og tilbage til en ekstern server, hvilket gør det muligt at behandle dokumenter direkte der, hvor de opstår. For det andet forsvinder en stor del af den løbende cloud-regning, fordi inferens sker lokalt i stedet for at blive faktureret per kald. For det tredje, og måske vigtigst for mange danske virksomheder, kan følsomme data blive på enheden i stedet for at forlade den. Det er relevant for alt fra sundhedsdata til finansielle dokumenter, hvor GDPR og branchekrav ofte gør det svært at sende data til en ekstern model.

Jeg ser det som en del af en bredere bevægelse, hvor edge-modeller går fra at være et kompromis til at være det bedre valg til bestemte opgaver. Jeg satte selv dokumentudtræk i produktion hos en virksomhed med drift i flere lande. Vi startede på en stor cloud-model, fordi den lå lige for. Den var dyr per kald, og juristerne ville have et klart svar på, hvor dokumenterne blev behandlet. Så flyttede vi selve udtrækket ned på en lille model, der kørte lokalt, og beholdt den store model til de få sager, hvor udtrækket fejlede. Jeg har ikke et rent tal, jeg kan dele på besparelsen, men den tunge del af regningen forsvandt, og spørgsmålet om databehandling blev til et spørgsmål om, hvilken maskine der stod i rummet.

For virksomheder, der i dag betaler for store cloud-modeller til at løse afgrænsede opgaver som dokumentbehandling, formularudfyldning eller dataudtræk, er LFM2.5-230M et signal om, at der findes et billigere og hurtigere alternativ. Man behøver ikke betale for generel intelligens, når opgaven er specifik.

Det praktiske spørgsmål bliver derfor: hvilke af jeres nuværende AI-opgaver er reelt strukturerede udtræksopgaver, der kunne løses lokalt af en langt mindre og billigere model? For mange virksomheder ligger svaret i fakturabehandling, formularindlæsning, dokumentklassificering og lignende opgaver, der i dag sendes gennem en stor cloud-model, fordi det var den tilgængelige løsning, dengang systemet blev bygget. Den antagelse holder ikke længere. Når en model på 230 millioner parametre slår modeller fire gange dens størrelse på netop den opgavetype, er det værd at genoverveje arkitekturen bag jeres agentiske arbejdsgange, ikke kun hvilken model I bruger, men hvor den kører.