MarkTechPost udgav 18. juni en tutorial, der går længere end et hurtigt demo‑prompt. Der er sat en sammenhængende arbejdsgang op fra prompt til testet resultat. Modellen hentes fra Hugging Face, output udtrækkes som Python‑funktioner og ryger gennem en række checks, før noget belønnes. Man kan følge det uden at gætte sig frem hele vejen.
Tørt? Ikke helt. Byggeklodserne samles i ét script, og det gør en forskel i hverdagen: færre manuelle hop, mere struktur. Man kan se, hvornår en kandidat falder fra – og hvorfor.
Hvad tutorialen gør
Workflowet samler generering og evaluering i én kæde. Trinene, i kort form:
- Indlæs en Salesforce CodeGen‑model fra Hugging Face og klargør tokenizer og model.
- Generér Python‑funktioner ud fra naturligt sprog.
- Udtræk selve funktionen af tekstoutputtet.
- Kør syntakstjek og statiske sikkerhedstjek før eksekvering.
- Valider med unit‑tests og brug testresultater i scoringen.
- Generér flere kandidater per prompt og foretag best‑of‑N‑reranking.
- Understøt multi‑step syntese og eksperimentér med prompt‑stile.
- Visualisér benchmarks og gem artefakter for sporbarhed.
Det er en evaluator‑pipeline, ikke bare inferens. Svagheder sorteres tidligt, så det bedste forslag står tilbage.
Teknisk præcision i koden
Tutorialen angiver sine afhængigheder tydeligt. Installationslinjen står eksplicit i materialet:
{sys.executable} -m pip install -q -U transformers accelerate safetensors einops datasets evaluate pandas matplotlib tqdm rich radon tiktokenModelindlæsningen sker via AutoTokenizer og AutoModelForCausalLM. Default model vælges direkte i koden:
MODEL_ID = os.environ.get("CODEGEN_MODEL_ID", "Salesforce/codegen-350M-mono")Der er en MODEL_OPTIONS‑struktur med større varianter, så man kan skifte model uden at pille ved resten. trust_remote_code slås til for udvalgte modelserier (fx codegen2/codegen25). Enheder og taltyper håndteres pragmatisk: device bliver cuda, hvis tilgængelig, ellers cpu. Dtype vælges tilsvarende (float16 på GPU, float32 på CPU). På GPU sættes device_map=”auto” og torch_dtype i load_kwargs, på CPU holdes det i float32. Ingen pynt, bare en opsætning der kan køre lokalt og i Colab, reproducerbart.
Fra demo til noget der ligner produktion
Tutorialen rammer de rigtige engineering‑trin: funktionsekstraktion, syntaksvalidering, statiske sikkerhedstjek, unit‑tests og reranking. God base. Men den dækker ikke drift: CI/CD‑kobling, løbende kvalitetsmonitorering, cost‑kontrol og skaleringsmålinger er uden for scope. Fair afgrænsning, men værd at være eksplicit om.
Næste skridt i et team er lige til: pak pipelinen i CI‑jobs, gør tests deterministiske, log alle scoringssignaler, og læg guardrails i staging før produktion. Best‑of‑N er stærkt, men øger compute og tid pr. funktion. Mål det – gæt ikke.
Praktiske konsekvenser for udviklingsworkflow
En faseopdelt tilgang skaber ro: start med en lille POC, hvor I måler tre ting på et sæt interne opgaver: syntaksfejl‑rate, unit‑test‑passrate og tid per generation. Byg det derefter ind i testmiljøet, og først til sidst i en begrænset produktionskanal. Roller flytter sig: QA får mere at sige om prompts og testdækning, mens DevOps planlægger batch‑kørsler, cache og kvoter.
Reranking og best‑of‑N reducerer støjen, især når unit‑tests vægter kandidater. Men drop ikke code review. Kanttilfælde og sideeffekter kræver stadig menneskeøjne.
Sikkerhed og governance
Sikkerhedstjek udføres statisk, før noget kører. Det er fornuftigt. Men der er ikke dokumenteret en runtime‑sandbox. Hvis noget lækker igennem, er der ingen beskrevet isolation. trust_remote_code er også et risikopunkt: når det er slået til, accepteres repo‑defineret kode ved load fra Hugging Face. Det kalder på enterprise‑vetting eller intern mirroring af model‑repos, afhængigt af compliance‑krav.
Minimum, før man sover lidt bedre: sandbox‑eksekvering af kandidatkode, secrets‑scanning i både prompts og output, runtime‑policy‑checks, samt auditlogning af alle scoringsbeslutninger. Tutorialens lag er placeret rigtigt, men regelsættet skal defineres lokalt.
Hvad evalueringen konkret fanger
Funktionsekstraktion isolerer det, der faktisk skal testes. Syntakstjek med Python AST fanger de oplagte fejl uden at spilde compute. Unit‑tests fungerer både som filter og score – man gætter ikke på kvalitet. Og med flere kandidater per prompt kan man lade modellen prøve sig frem, mens pipelinen vælger vinderen. Det er hele idéen i best‑of‑N‑trinnet.
Multi‑step syntese og varierende prompt‑stile er to reelle håndtag i materialet. Små, systematiske forsøg her kan løfte passraten mere end endnu en tilfældig temperaturændring.
Hvor langt er der til produktion
Der mangler tal for latenstid, throughput og omkostning pr. genereret funktion. Også for hvor meget passraten faktisk løfter sig med best‑of‑N på tværs af opgaver. Skeptikeren vil sige, at meget her handler om værktøjseksekvering fremfor produktintegration. Det er ikke helt forkert. Samtidig er det netop de her byggeklodser, integrationen hviler på.
Reglerne for sikkerhedstjekket omtales, men listes ikke. Det gør trinnet mindre overbevisende for enterprise, indtil man selv udfylder rammerne.
Konkrete next steps
Vil du genbruge opskriften, så start småt og mål konkret:
- POC: brug “Salesforce/codegen-350M-mono” og genbrug installationslinjen fra tutorialen for hurtig replikering.
- Målepunkter: syntaksfejl‑rate, unit‑test‑passrate, tid/compute pr. funktion, andel kandidater filtreret af sikkerhedslag, samt simpel latenstid og throughput pr. batch.
- Benchmark: sammenlign best‑of‑N mod modelstørrelse. Hæv N fra fx 1→4 og/eller skift til en større variant; log marginal gevinst i passrate og marginal omkostning i tid/compute.
- Sikkerhed først: kør i sandbox, aktivér secrets‑scanning, og kræv auditlogning af alle beslutninger i pipelinen, før kandidater går i test.
Når kurverne flader ud, binder man det op i CI, tilføjer alerts på kvalitetsfald og indfører en godkendelsesport, så ændringer i prompts eller modelversioner er sporbare.
Konklusion
Tutorialen viser en produktionsnær måde at bruge CodeGen på: generér funktioner, udtræk, tjek, test og vælg bedste kandidat. To konkrete holdepunkter – installationslinjen og default MODEL_ID – gør replikeringen let. De ekstra lag med statiske checks, unit‑tests, reranking, multi‑step og visualisering giver et ordentligt stillads. For at gå fra demo til drift kræves dog klar sandboxing, et dokumenteret sikkerhedsregelsæt, CI/CD, monitorering og målinger af cost vs. kvalitet. Når de er på plads, er der et solidt fundament at bygge videre på.
