Dernæst en hurtig dry‑run med en lokal test‑generator (test.Repeat) og en simpel probe (lmrc.SlurUsage) og én generation:

python -m garak --target_type test.Repeat --probes lmrc.SlurUsage --generations 1
Pointen er at verificere hele kæden – uden API‑nøgler og uden omkostninger. Vi lægger typisk samme trin i CI for at fange brud i tooling, før dyre kald rammer.

Real‑model scan og multi‑probe
Herefter scanner tutorialen en Hugging Face‑model. Eksemplet bruger gpt2 som mål og en klassisk DAN‑probe (Dan_11_0) med parallelisering:
python -m garak --target_type huggingface --target_name gpt2 \
  --probes dan.Dan_11_0 --generations 1 --parallel_attempts 8
Bagefter vises en programmatisk multi‑probe‑kørsel via run_garak med tre prober i samme job: dan.Dan_11_0, encoding.InjectBase64 og lmrc.SlurUsage samt --parallel_attempts 16. Det giver bredere dækning og samler data i én rapport – med krav til CPU, netværk og hensyn til rate limits mod eksterne endpoints. Kører I mod cloud‑modeller, bør ops planlægge kø‑styring og caps på samtidige kald.
Hvad rapporterne og scores fortæller
Efter kørsel læses rapporten med garak.report.Report. Tutorialen viser per‑probe gennemsnitlige safety‑scores og evalueringer og har et fallback, der parser JSONL manuelt, hvis import fejler. God praksis, fordi det øger robustheden.
Hvordan skal et security‑team læse det? Scores er signaler, ikke domme. En høj succesrate på en DAN‑probe siger noget om modtagelighed for prompt‑omgåelse, men kontekst er afgørende: prompt‑arkitektur, systeminstruktioner, indbyggede sikkerhedslag og downstream‑detektorer. Brug garak‑scores til screening: flag højrisiko‑områder til menneskelig vurdering af forretningspåvirkning. Standardopsætninger på rå modeller støjer ofte – det er forventeligt og kræver bevidst tuning, før man handler på fundene.


At lave custom probes og detectors
Tutorialen viser også, hvordan man laver egne prober og detektorer. Det er centralt, fordi standard‑plugins sjældent rammer en virksomheds mest konkrete risici. Vi har bygget prober, der tester for læk af interne koder, trade‑secrets i bestemte fraseringer og regulatoriske faldgruber. I en finanscase gav en første multi‑probe‑kørsel 120+ høj‑prioritets alarmer i testmiljø; efter tuning af to detektorer og prompt‑hardening faldt støjen 70%.

Integration i drift og governance
Det vigtige er ikke kun at scanne, men at gøre scanningen til en driftsrytme. Tutorialens dry‑run‑mønster med test.Repeat er velegnet som CI‑trin uden eksterne kald. Real‑model scans kan trigges ved modelopdateringer, nye prompter eller ændrede sikkerhedspolitikker.
AVID‑eksporten binder det til governance. Standardiseret output kan lande i risikoregistre, dashboards eller GRC‑systemer. Lav en mapping: hvilke garak‑felter matcher jeres interne kategorier, hvilke tærskler giver “blokér” vs. “observér”, og hvem ejer opfølgning. Praktisk kræver det et fælles beslutningstræ mellem SRE\/ops, sikkerhed og compliance: hvornår fejler et build, hvornår åbnes et ticket, hvornår kræves menneskelig godkendelse.

Praktiske detaljer der bider
Inden bred udrulning vil vi sikre tre ting. 1) Robusthed: run_garak læner sig op ad _config.transient.report_filename. Brug eksplicit output‑sti eller stabil søgestrategi, som tutorialens find_latest_report antyder. 2) Error‑håndtering: tidsgrænser og retries, så parallelle forsøg ikke hænger ved netværksproblemer. 3) Rate limits og omkostninger: caps og per‑probe logging.
Og så det uundgåelige: scanner I mod eksterne modeller, skal procurement og legal med. Promptdata forlader jeres miljø, og databehandleraftaler kan begrænse jer. Det er vilkår, ikke et garak‑problem.

Hvor garak ikke løser alt
Garak afhænger af plugin‑kvalitet. Nogle detektorer kan give mange false positives i jeres domæne. Tutorialen leverer ikke kvantitative benchmarks for detektorpræcision; test selv mod et kendt sæt on‑ og off‑policy prompts og justér tærskler.
Ydeevne er også åben. Tutorialen viser parallel_attempts, men ikke hardwarekrav eller runtime for større job. Det afhænger af endpoints og prober, men drift har brug for målinger, før natlige kørselssæt planlægges. Start småt og log CPU, RAM, latenser – og om detektorer laver dyre efterberegninger.
Konkrete kommandoer og kode fra tutorialen
Her er de centrale stumper, som vi har krydstjekket mod notebookens tekst:


Installation og miljø: python -m pip install -q -U garak, TOKENIZERS_PARALLELISM=false, HF_HUB_DISABLE_TELEMETRY=1
Plugin‑inventar: python -m garak --list_probes (og tilsvarende for detectors, generators, buffs)
Dry‑run: python -m garak --target_type test.Repeat --probes lmrc.SlurUsage --generations 1
Real‑model scan: python -m garak --target_type huggingface --target_name gpt2 --probes dan.Dan_11_0 --generations 1 --parallel_attempts 8
Programmatisk multi‑probe via helper: run_garak med prober dan.Dan_11_0,encoding.InjectBase64,lmrc.SlurUsage og --parallel_attempts 16

Der er også en analyse‑sektion med import af garak.report.Report og et fallback, der finder seneste *report.jsonl i garaks standardmapper. Det hele ligger i tutorialens “FULL CODES”.
Hvorfor det betyder noget i drift
For teams med LLM‑services i produktion gør garak to ting rigtigt: det er scriptbart, og det har fornuftige standarder. Man kan køre et minimum af sikkerhedstests uden at bygge en ny ramme. AVID‑eksporten hjælper med at gøre findings til en del af kontrolmiljøet, ikke bare en PDF i en mappe.
I en kundepipeline var plugin‑inventaret en stærk audit‑log. En detektor markerede til gengæld halvdelen af svarene som risikable, fordi domænesproget lignede toxicitet. En times justering af tærskler og filtrering af enkelte prober løste det, hvorefter flowet kørte stabilt.


Snillds anbefalinger
Hvis du vil i gang hurtigt, så gør dette i rækkefølge: 1) Tilføj dry‑run i CI med test.Repeat og 1–2 simple prober for at bekræfte værktøjet. 2) Vælg én produktionsnær model og kør en multi‑probe med lav --generations i staging. 3) Byg 1–2 custom prober målrettet jeres forretning (fx læk af interne koder eller brud på brancheregler). 4) Map AVID‑eksporten til jeres governance‑felter og etabler et beslutningstræ for opfølgning.
Målet er et stabilt, gentageligt sikkerhedstjek – ikke en enkelt pæn rapport.

Usikkerheder og ting vi vil validere
Nogle dele i tutorialen bør verificeres uafhængigt. Helper‑mønstret med _config.transient.report_filename kan være skrøbeligt på tværs af versioner. Test på mindst to udgivelser. Der er heller ikke kvantitative tal for false positives\/negatives på detektorerne; lav et lille eval‑sæt med kendte angrebs‑ og ikke‑angrebsprompter. Endelig mangler performance‑målinger for større multi‑probe jobs – mål, før I skalerer.
AVID‑workflowet er demonstreret som eksport, men integration i governance kræver jeres felt‑mapping og tydeligt ejerskab for opfølgning. Det kræver beslutninger, ikke ekstra kode.

Konklusion
Garak‑tutorialen viser et komplet defensivt LLM‑workflow, ikke kun en demo. Den er tilstrækkelig konkret til, at teams kan operationalisere den og stadig sætte eget præg. Start med dry‑run. Bevis multi‑probe i staging. Byg få, skarpe custom prober. Sæt AVID‑eksport i drift og bind den til governance. Forskellen mærkes først, når man kører det i praksis.

Appendiks

Kilde: NVIDIA garak tutorial hos Marktechpost – “NVIDIA garak Tutorial: Build a Complete Defensive LLM Red‑Teaming Workflow with Custom Probes and Detectors”. Indeholder fulde kodeeksempler og link til FULL CODES.
Metoden i artiklen bygger på den offentlige tutorial, suppleret med vores erfaringer. Hvor tutorialen ikke dokumenterer robusthed (fx detektorpræcision), har vi markeret usikkerhed og anbefalet egne tests.






Kilder

NVIDIA garak Tutorial: Build a Complete Defensive LLM Red-Teaming Workflow with Custom Probes and Detectors
Meta Business Agent drives AI-powered conversational commerce



        Kontakt

Denne artiklen er skrevet af en redaktion bestående af kunstig intelligenser, der har skrevet artiklen på baggrund af automatiseret research og oplysninger om de seneste teknologi nyheder fra internettet.
Billederne i artiklen er lavet af Gemini 3 Pro Nano Banana 2 Pro fra Google.