Program-Aided Language (PAL)

PAL flytter selve udregningen ud af sprogmodellen. Modellen bruges til at oversætte opgaven til kode, typisk Python, og koden køres derefter i et separat miljø. Svaret kommer fra eksekveringen, ikke fra modellens egen forudsigelse af næste token.

Forskellen til chain-of-thought er arbejdsdelingen. Chain-of-thought lader modellen både opstille og udføre mellemregningerne i tekst, hvor hvert tal genereres statistisk. PAL beholder opstillingen som modellens opgave, men overlader udførelsen til en deterministisk fortolker.

Forskellen til least-to-most er, hvad der nedbrydes. Least-to-most deler et problem i delspørgsmål, som modellen besvarer i rækkefølge, stadig i naturligt sprog. PAL nedbryder til variabler og operationer og kan sagtens kombineres med least-to-most, hvor hvert delproblem bliver en kodeblok.

ReAct er en tredje nabo, men bredere. Der veksler modellen mellem ræsonnement og vilkårlige værktøjskald, hvor PAL har præcis ét værktøj: en fortolker.

Aritmetik er dårligt egnet til token-forudsigelse. Et tal som 34,499 og et tal som 34,999 ligner hinanden stærkt i repræsentationen, men er forskellige svar. Modellen har ingen mekanisme til at bære mente eller holde et mellemresultat præcist over mange trin, så fejlraten stiger med antallet af cifre og operationer.

Kode har en anden egenskab. Syntaksen tvinger opgaven ind i en fast struktur, hvor hver størrelse skal navngives og hver operation skrives eksplicit. Det reducerer antallet af plausible fortsættelser og gør det sværere at springe et led over uden at koden bliver ufuldstændig.

Desuden er trænings­materialet for kode tættere på formel notation end almindelig tekst. Mønstret "procent af et tal" har en meget snæver kodemæssig realisering, mens det i prosa kan udtrykkes på hundrede måder med hver sin risiko for skred i betydningen.

Eksekveringen fjerner så den sidste fejlkilde. Når koden først er korrekt opstillet, er resultatet uafhængigt af modellens usikkerhed.

PAL beskytter mod regnefejl, ikke mod forståelsesfejl. Hvis modellen misforstår, om 40 % gælder tilbudsprodukterne eller hele sortimentet, producerer koden et forkert svar med fuld præcision og pæn formatering. Det er farligere end et tydeligt forkert overslag, fordi resultatet ser autoritativt ud.

Teknikken er også spild på opgaver uden numerisk kerne. Vurderinger, tekstanalyse og klassifikation vinder intet ved at blive presset ind i kode, og du får en ekstra fejlkilde og en ekstra infrastrukturafhængighed uden gevinst.

Nyere reasoning-modeller har rykket grænsen. Claude Opus 5, GPT-5.6 Sol og Gemini 3.1 Pro klarer flercifret aritmetik og flertrinsopgaver markant bedre end tidligere generationer, og mange af dem har allerede kodeeksekvering indbygget i deres værktøjslag. Her er den eksplicitte PAL-instruktion ofte overflødig.

Billedet er anderledes for mindre modeller. GPT-5 nano, Claude Haiku 4.5 og Gemini 3.7 Flash fejler stadig på kæder af udregninger, og der giver PAL en reel forbedring, hvis du har eksekveringsmiljøet.

Præcisionen i outputtet siger intet om, hvorvidt modellen har opstillet det rigtige regnestykke. Den eneste reelle kontrol er at læse koden, og det forudsætter, at variabelnavne og struktur afspejler opgavens begreber frem for anonyme mellemresultater.

En praktisk kontrolmekanisme er at bede om både kode og et groft overslag i tekst. Hvis de to afviger væsentligt, ligger fejlen i opstillingen. Metoden fanger ikke alt, men den afslører de misforståelser, som eksekveringen ellers ville skjule bag et præcist tal.