Meta FAIR præsenterer RPMs der vælger hvilke ML‑eksperimenter der må køre
Nyheden lander i en uge hvor automatiseret forskning igen er på dagsordenen. OpenAI meldte 6. september, at målet om en “automated research intern” er nået, med 3,1 agent‑arbejdsdage for hver menneskedag. Samtidigheden er ikke tilfældig. Branchen vil tempoet op, uden at brænde hele kreditkortet af på H200‑timer. RPMs er tænkt som et tyndt prioriteringslag før træning – ikke magi, men et håndtag der kan bruges i dag.
Hvad RPM egentlig gør
Kernen er bevidst jordnær: i stedet for at forudsige en absolut metrik for hver kandidat (som sprogmodeller viser sig upålidelige til), rangerer RPM de ueksekverede muligheder relativt og vælger kun én til faktisk kørsel. Ingen finetuning. Implementeringen bruger en frosset, fortrænet LLM som dommer. Det skærer både kompleksitet og risiko for læk fra træningsdata. Man kan miste noget domæneskarphed, ja, men gevinsten er plug‑and‑play.
AIRA‑dojo, den omgivende agent‑ramme, kører som en slags evolutionær søgning: vælg en forælder, anvend en operator (Draft, Improve, Debug), og vend tilbage med noden med højest validationscore. Forskellen med RPM er placeringen. I stedet for at køre ét barn, genereres 15 børn i parallel – alle ueksekverede – som så matches parvist i en knock‑out. Kun den endelige vinder får lov at bruge compute. Resten forbliver på papir. Eller rettere, i tokens.
En knockout‑turnering med kontekst
Turneringen er ikke ren mavefornemmelse. Hver sammenligning fodres med kontekst fra tidligere udforskede noder via en BFS‑gennemgang, inklusive deres faktiske validationscorer. Dommeren – sprogmodellen – gætter altså ikke i blinde. Den ser eksempler på, hvad der har virket og ikke har virket i samme træ. Den detalje gør forskellen: fra global forudsigelse til lokal beslutning med historik.
Er det så ikke bare en heuristik forklædt som en model? Jo – og det er pointen. I eksperimentstyring vinder simple, pålidelige beslutningsregler ofte over tunge metrik‑forudsigelser, især når sandheden kun afsløres ved faktisk træning. RPM lægger sig tættere på beslutningsteori end på klassisk regressionskunst.
To varianter, to budgetter
Holdet beskriver to varianter. En “inference‑only” RPM, hvor LLM’en er dommer over planer, kode og søgehistorik. Prompten blev optimeret med MIPROv2 fra DSPy og endte som en slags PI‑rubrik: tolerer fejl der kan fixes, beløn udvidbarhed, straf gentagelser. Offline‑nøjagtigheden lander ifølge rapporteringen omkring 57,7 til 59,0 procent. Ikke imponerende, men ofte nok hvis gevinsten er færre fejlkørsler – og uden ekstra pilotjobs på GPU’en.
Den anden er en “agentic” RPM. Samme dommer, men nu med en sandbox der kloner agentens miljø, inklusive en enkelt H200. Her kører korte pilotstudier med værktøjer som python, bash og submit_solution, og et feedback‑lag foreslår næste mest informative pilot – eller stopper. To designvalg er værd at bemærke: budgettet beskrives bevidst overestimeret (2.700 sekunder mod et reelt 300‑sekunders loft) for at undgå for tidlige stop, og der sættes kap på 30 piloter med 60 sekunders tærskel. Det er et ærligt trade‑off. Pilottid koster vægur.
Resultater på AIRS‑Bench
Benchmarken AIRS‑Bench beskrives som 20 offentlige tekst‑ og tabulære opgaver, 24 timer på en enkelt H200 per opgave, 10 seeds. Qwen3.6‑27B er backbone for både operatorer og RPM, så den målte gevinst kommer fra selektionslaget – ikke fra en klogere dommer på siden. Et rent designvalg, som gør tallene mere interessante.
Open source og backbone – hvad er faktisk udgivet
AIRA‑dojo og AIRS‑Bench beskrives som åbne. Det er afgørende, hvis andre skal reproducere eller udvide. Men her er der et hul i materialet: et direkte link til repo og licens mangler i de sekundære beskrivelser. Indtil et GitHub‑link, en tagget release og en licensfil kan inspiceres, bør man antage, at der kan være forskel mellem løfte og levering. Ikke usædvanligt i forskningsrelease‑uger.
Backbonen Qwen3.6‑27B omtales som open weights. Det ligger i tråd med Qwen‑familien, hvor flere 3.x‑modeller udgives med åbne vægte under licenser, der ofte tillader kommerciel brug med forbehold. Tjek modelkort, tokenizer, konfig og licens før ibrugtagning. Et tokenizer‑mismatch kan koste en weekend.
Hvorfor det betyder noget i MLOps
De fleste ML‑teams mangler ikke idéer – de mangler gennemløb. Et prioriteringslag før træning ændrer forløbet: i stedet for at affyre fem halvbagte kandidater, sender man én relativt bedømt vinder i maskinen. Det reducerer spild og kalibrerer forventninger. En menneskelig reviewer kan ikke læse sig igennem alle varianter, når agentløb multiplicerer dem.
Integration er det praktiske punkt. AIRA‑dojo er tænkt som et selektions‑hook ved child‑generering. I en eksisterende pipeline skal det bindes ind i jobkøen, ressourcestyring og checkpoints. Særligt hvis man vælger agentic‑varianten, der kører piloter. Her konkurrerer piloter direkte med resten af batchen om kvoter. Det øger vægurtiden og kræver cost‑rapportering – ellers forsvinder compute i det grå.
Hvad man skal bygge først
Tre lavpraktiske konsekvenser: For det første, en scheduler der kan prioritere pilotjobs side om side med træningsjobs uden at sulte nogen af dem. Preemption hjælper, men skærper fejlhåndtering. For det andet, governance. Et RPM‑lag kan skjule faktisk forbrug, hvis piloter ikke tælles som “rigtig træning”. Det er penge alt sammen. For det tredje, observabilitet. Sammenligningerne i knockout‑turneringen skal logges, ellers kan man ikke forklare valg i retrospekt. I regulerede domæner er “fordi modellen sagde det” for tyndt.
Der er også en menneskelig detalje. Når RPM favoriserer udvidbarhed og tolererer fixbare fejl, kan det skubbe kulturen mod hurtige prototyper frem for perfekte patches. Sundt – og farligt, hvis patch‑gælden aldrig indløses. Advarslen bør med.
Begrænsninger og åbne spørgsmål
Offline‑nøjagtigheden for inference‑only på knap 58–59 procent er ikke høj. Hvis prisen for en fejludvælgelse er stor – lange træningsløb, dyre data – kan det stadig være for dyrt at tage fejl. Agentic‑piloter kan give ekstra sikkerhed, men man betaler i vægur, kompleksitet og risiko for nondeterminisme i mikrokorte træningskørsler.
Rapporteringen nævner bevidst overestimeret budget i agentic‑varianten. Forståeligt for at få mere signal ind, men i produktion forvrænger det cost‑overblik. Desuden savnes ablations: hvordan ser kurverne ud ved strammere 300‑sekunders budgetter, flere samtidige opgaver eller ved andre operatorer end Draft og Improve? Debug triller tilbage til tilfældigt valg, hvilket antyder en grænse for, hvor langt RPM kan presses i fejlfinding.
Konflikten mellem teori og drift
Surrogatmodeller, Bayesian optimisation, multi‑fidelity evaluering – værktøjskassen til smartere eksperimentvalg er velkendt. RPM lægger sig i den familie, men med en LLM som dommer og en enkel turneringsmekanik. Fristelsen i praksis er klar: en generisk selektor, der kan ligge oven på kode, tekst og søgehistorik uden specialtræning. Ulempen er, at robustheden endnu ikke er dokumenteret bredt. Community‑reproduktioner efter release vil være bedre indikatorer end en enkelt benchmark.
Korrelerede fejl mellem kandidater spøger også. Hvis operatoren genererer 15 børn med samme blinde plet, hjælper rangering kun lidt. Stærkere diversitetskontrol i kandidatgenereringen kan være lige så vigtig som selve dommeren. Det omtales ikke i dybden og ligner et oplagt næste studie.
OpenAI’s automatiserede praktikant som bagtæppe
OpenAI’s melding om en “automated research intern” sætter en høj industrikrog at hænge ny forskning op på. Her er målet mere end prioritering; det handler om at øge den samlede arbejdskapacitet med agent‑arbejdsdage. RPM adresserer et smallere, men kritisk snit: hvem får lov at køre. Ambitionsforskellen er tydelig. Det ene er en organisationel produktivitetsmåling, det andet en selektionsmekanisme i en enkelt loop.
Man kan også sige, at RPM er den del af automatisering, der sandsynligvis gør mindst ondt at indføre. Den ændrer ikke slutproduktet – kun rækkefølge og prioritering. Kedeligt? Ofte der, gevinsten gemmer sig.
Sådan griber man adoption an
En kort huskeliste: Start i sandbox. Kør AIRS‑Bench eller en lille intern benchmark, der ligner jeres workloads, og mål vægurtid, GPU‑timer og fejlrate med og uden RPM. Tjek licenser på Qwen3.6‑27B og afhængigheder. Byg en cost‑meter som tæller piloter med samme vægt som træningsjobs. Log RPM’s parvise domme, så I kan forklare og revidere rubrikken, hvis den begynder at favorisere døde ender.
Overvej også, om inference‑only er nok. Hvis fejlkørsler er dyre, kan agentic‑piloter være et bedre kompromis trods ekstra drift. Er I bundet af stramme SLA’er, er ekstra vægur en reel risiko. Ingen magi her – kun prioriteringer.
Hvad der skal bekræftes
Robusthed over seeds og workloads skal bekræftes. Der nævnes 10 seeds – godt – men uden konfidensintervaller på tværs af opgaver og uden beskrevne failure‑modes er det svært at vurdere, hvor let metoden tipper. Og i drift dukker en detalje op: nondeterminisme i mikropiloter kan give spøgelseseffekter, hvor samme kandidat vinder én dag og taber næste. Hvordan dæmpes det? Ikke klart endnu.
Bundlinjen
RPMs føles som et praktisk greb. En LLM‑dommer, 15‑vejsturnering, én vinder til GPU’en. Det er egentlig alt. Hvis koder og benchmark virkelig er åbne, og hvis tallene på AIRS‑Bench kan reproduceres, kan det finde vej ind i mange agenter hurtigt. Hvis ikke, bliver det endnu et godt papir, der lever sit eget liv på Twitter og i konferencelobbyen.
Konklusionen er ikke pæn pakket ind. De fleste teams har brug for et selektionslag før træning. RPM er et bud med lovende, men stadig foreløbige beviser. Forskellen mærkes først, når man sidder med det i hænderne.
