Poetiq sætter ifølge MarkTechPost en ny topplacering på LiveCodeBench Pro ved ikke at ændre modellen, men ved at lægge en automatisk, model‑agnostisk inferens‑harness omkring den. Ingen fin‑tuning. Ingen særlige adgangsforhold. GPT 5.5 High går fra 89,6 til 93,9 procent, og Gemini 3.1 Pro springer fra 78,6 til 90,9. Store hop for en klogere måde at køre modellen på. Men én ting først: uden run‑seeds, gentagelser/varians og konkrete cost‑ samt latency‑målinger kan andre ikke vurdere robusthed og TCO ordentligt.
Retningen er svær at misforstå. Vi har igen og igen set, at god styring rundt om modellen henter mere ud af samme motor. Her er løftet bare større end normalt. Og målbart i en streng benchmark.
Hvorfor LiveCodeBench Pro bider fra sig
LCB Pro er et kodningsbench med opgaver fra rigtige konkurrencer. Der er ingen offentlige facit; løsninger køres mod en test‑ramme med både memory‑ og runtime‑krav. Fokus er C++ og effektiv, proceduretung logik. Opgaver er grupperet efter menneskers løsningsrater og opdateres løbende for at undgå stagnering.
Det gør smarte genveje svære. Vi har haft C++‑cases, der så fine ud i enhedstests, men væltede på p95‑latency eller ramte memory‑limit, når input ikke var pænt. LCB Pro finder de svagheder hurtigt.
Hvad Poetiq faktisk gør
En inferens‑harness er lagene omkring selve modelkaldet: struktureret prompt, opdeling i trin, flere runder, samling af svar, tests undervejs og post‑processing. Ofte også en sandbox til at kompilere og teste. Poetiq hævder, at deres Meta‑System automatisk konstruerer og optimerer denne opsætning og kan bruges på tværs af modeller via API. Uden at røre ved modellerne.
Det gør løsningen relevant for teams, der arbejder med hyldevarer og vil løfte performance uden træningsbudgetter og lange retrain‑forløb.
Resultaterne i kildeartiklen
Ifølge MarkTechPost rammer GPT 5.5 High 93,9 procent på LCB Pro (25Q2) mod 89,6 i baseline. Gemini 3.1 Pro går fra 78,6 til 90,9, og det score slår den rapporterede 88,8 for Gemini 3 Deep Think. Deep Think er ikke API‑tilgængelig, så den del kan ikke valideres udefra. Poetiq optimerede opsætningen på Gemini 3.1 Pro og genbrugte den på andre modeller.
Kan andre genskabe det i dag? Delvist. Adgang til LCB Pro og de konkrete modelvarianter er en praktisk barriere. Og uden seeds, antal runs og varians bliver robusthed en vurdering, ikke en måling.
Hvorfor en god opsætning virker
Fem greb flytter typisk mest: 1) stram styring af delmål, 2) flere kald med specialiserede roller, 3) test‑drevet iteration hvor forslag kompilieres og fejl bruges i næste skridt, 4) samling og voting på tværs af kandidater, 5) hård input‑ og output‑sanitizing. Ikke magi. Disciplin.
Vi har selv set cirka 6 procentpoint løft med et ekstra kompilations‑loop og to retries. Prisen var cirka 30 procent højere p95‑latency. Til at leve med, hvis man har fallback og budgetloft.
Konsekvenser for implementering
Lad være med at generalisere blindt. Tunge C++‑opgaver med runtime/memory‑krav ligner LCB Pro og har større potentiale end små scripts. Vi ville starte her: byg en målbar opsætning før I shopper modeller.
Tre prioriteringer vi anbefaler: 1) versionsstyr prompts og komponenter, og kør pipelines som kan testes end‑to‑end, 2) udskyd fin‑tuning, hvis målet er kortsigtet løft — høst først det, en klog køreplan kan give, 3) sæt hårde grænser for cost og ventetid fra dag ét med p95/p99‑mål og guardrails.
Sådan kan en minimal pipeline se ud
Normaliser input, del problemet i moduler, generer løsningsforslag i parallelle grene, kompiler og test hver gren, saml fejl, og forfin den bedste kandidat. En controller beslutter ekstra runder og holder øje med et lille budget, så svære sager ikke æder hele maskinen.
Hvis Poetiqs Meta‑System faktisk kan bygge dette automatisk, flytter fokus til måling og afgrænsning. Ejerskab, drift, governance og hurtig rollback er stadig jeres ansvar.
Begrænsninger og åben anmodning til Poetiq
For at gøre resultaterne fuldt reproducerbare har branchen brug for en pakke med: 1) run‑logs, 2) seeds, 3) antal optimeringsiterationer og variansintervaller, 4) fuld konfiguration af opsætningen, inkl. prompts og validatorer, 5) den anvendte objektivfunktion.
Og for en produktionsvurdering mangler vi: gennemsnitlig cost pr. opgave, antal API‑kald pr. opgave (gennemsnit og p95), samt pct.‑stigning i p95/p99‑latency mod baseline. Vi opfordrer Poetiq til at offentliggøre disse artefakter.
Test generalisering i praksis
Undgå over‑tuning til én benchmark: 1) kør på andre sprog end C++ med tilsvarende runtime/memory‑krav, 2) brug hold‑out benchmarks, der ikke indgik i optimeringen, 3) lad en uafhængig part auditere seeds, prompts og konfigurationer blindt. Praktisk kan det ske ved at lade en tredjepart afvikle containeriserede jobs på en lukket LCB Pro‑konto og publicere checksums og scorefordelinger.
Noget af gevinsten vil være LCB Pro‑specifik. Men hvis hovedparten kommer fra model‑uafhængige principper som struktur, retries og stram test, vil meget bære over. Det skal måles, ikke antages.
Drift: metrikker, budgetter og grænser
SLA handler nu om hele kæden. Start med få, skarpe nøgletal: 1) p95‑latency pr. opgavetype, 2) cost per 1.000 inferences, 3) andel opgaver der kræver ekstra runde, 4) validator‑fejlrate. Sæt konkrete guardrails: maksimalt 3 runder, hårdt timeout pr. opgave (fx 60 sek.), og et cost‑loft pr. opgave (fx 0,20).
Vi har set, hvordan en lille ændring i en validator kan vælte natkørsler. Læringen: behandl opsætningen som software. CI på prompts, enhedstests for post‑processing, versionsnumre på alt og en hurtig rollback‑vej. Kedeligt. Uundværligt.
Tre skridt vi ville tage i morgen
1) Pilot på en snæver kodeopgave — gerne C++, hvis det matcher jeres domæne. Mål baseline uden avanceret køreplan: accuracy, p95/p99‑latency, cost per 1.000 inferences, engineering‑timer. 2) Indfør en enkel opsætning med problemopdeling, kompilations‑loop og 1‑2 retries. Sammenlign. Tal, ikke mavefornemmelser. 3) Test model‑uafhængigt: kør samme opsætning mod to modeller via en fælles adapter og se, hvor værdien faktisk opstår. Log seeds og versioner til audit.
I to nyere projekter hos os gav bedre prompt‑flow og styring omkring modellen cirka 5‑8 procentpoint i task‑accuracy. Prisen var 20‑40 procent længere svartid i enkelte trin og lidt mere skrøbelighed, når en validator fejllarmede. Det var okay, fordi vi havde fallback til enkeltkald, cache af delresultater og alarmer, når et loop trak ud.
Skepsis, omkostninger og realiteter
Benchmark‑optimering kan ske, og cost kan løbe. Begge dele er reelle risici. Vi ser samtidig, at 5‑10 procentpoint højere accuracy i kodegenerering ofte fjerner manuelle rettelser og reducerer fejl nedstrøms. Det rammer TCO direkte. Men uden cost‑ og latency‑tal fra Poetiq er billedet ikke komplet. De bør offentliggøre dem.
Gennemsigtighed er den anden kritik. Hvis det her skal flytte branchen, skal vi have reproducibility‑pakken beskrevet ovenfor.
Konkurrencebilledet
Flere flytter fokus fra større modeller til klogere runtime‑strategier og værktøjskæder. The Algorithmic Bridge noterer, at benchmarks nu kæmper med, at selve kæden bliver konkurrenceparameter. Poetiq lægger sig midt i den bevægelse og viser, hvad man kan hente ved at designe køreplanen lige så omhyggeligt som motoren.
Det gør også leverandørvalg mindre låst. Hvis en stærk opsætning giver store løft på tværs af modeller, bliver interoperabilitet vigtigere end små forskelle på leaderboardet.
Metodeboks
Påstande om resultater, benchmarkbeskrivelse og Poetiqs framing er verificeret mod MarkTechPost, som linker til Poetiqs indlæg. Centrale tal: GPT 5.5 High 93,9 procent med opsætningen mod 89,6 baseline; Gemini 3.1 Pro 90,9 mod 78,6 baseline; reference til Gemini 3 Deep Think 88,8. Vi markerer, at Gemini 3 Deep Think ikke er API‑tilgængelig, og ekstern verifikation derfor er begrænset. Perspektiv på benchmarking‑trends er hentet fra The Algorithmic Bridge som baggrund, ikke som kilde for tal.
Ved publicering mangler vi fuld konfiguration, run‑seeds, antal kørselspunkter og variansmål samt cost‑ og latency‑tal for Poetiqs kørsel. Vurderinger her bygger på tilgængelige kilder og egne driftserfaringer.
Det større billede
Det her er ikke et løfte om 12 procentpoint i morgen. Det er et signal om, at styringen omkring modellen kan være den hurtigste vej til bedre performance i kodningstunge miljøer. Før I opgraderer modellen igen, så kig på jeres pipeline. Vi forventer, at flere lægger en større del af budgettet her det næste år.
En lille ting fra vores hverdag: vi lagde et simpelt voting‑lag oven på to modelkald til en besværlig parser. Én del blev fantastisk, én ramte ved siden af — samlet set en gevinst. Man opdager først forskellen, når man sidder med det i hænderne.
