Het bewijs achter elk resultaat terugvinden.

Onderscheid campagne, configuratie en uitvoering

Een campagne draagt een vraag, bijvoorbeeld het vergelijken van een referentie met een aanpassing. Een configuratie beschrijft de technische keuzes. Een run is een poging om die configuratie uit te voeren, met een seed, een begin, een einde en een status. Twee identieke pogingen behouden dus twee identificaties, zelfs als de tweede een onderbroken poging vervangt.

Voeg een evaluatie-identificatie toe wanneer hetzelfde artefact op meerdere datasets of met een nieuwe metriek wordt geëvalueerd. Dat voorkomt dat je een nieuw model verwart met een nieuwe lezing van het bestaande model. Koppel de hervattingpoging aan de poging die eraan voorafging en aan de geladen checkpoint.

MLflow organiseert de opvolging eveneens rond runs, parameters, metrieken en artefacten. Dat onderscheid is nuttig, zelfs in een eenvoudige map met bestanden. Je kunt het toepassen met je gebruikelijke tool; er is geen specifiek trackingplatform nodig om te beginnen.

Technische bronnen: MLflow — runs, parameters, metrieken en artefacten

Schrijf het manifest dat daadwerkelijk is uitgevoerd

Bewaar de parameters die zijn vastgesteld na toepassing van de standaardwaarden en de opstartargumenten. Het oorspronkelijke configuratiebestand kan een standaard batchgrootte of een tijdens de uitvoering gewijzigde optie weglaten. Registreer wat daadwerkelijk is gebruikt, met een kopie van de code of een onveranderlijke revisie en de status van niet-opgeslagen wijzigingen.

Het manifest verbindt ook de versies van het model en de tokenizer, de softwareomgeving, de daadwerkelijk gebruikte GPU, de precisie, de data, de seeds en de definitie van de metrieken. Het beschrijft de poging, zonder een installatiehandleiding te worden. Vermeld de eenheden: seconden, bytes, tokens, punten of een verhouding van 0 tot 1, afhankelijk van de meting.

Bij het starten is de status lopend; aan het einde wordt deze voltooid, mislukt of onderbroken, afhankelijk van wat je hebt vastgesteld. Vul een vergeten versie niet achteraf aan met de momenteel geïnstalleerde versie. Markeer de informatie als onbekend en beperk de conclusie die ervan afhangt.

Identificeer data verder dan een mapnaam

Een pad zoals data/final duidt geen stabiele versie aan. Bewaar de inventaris van de bestanden of voorbeelden, de splits en de transformatieprocedure. Als je labels corrigeert of rijen filtert, maak dan een nieuwe versie en behoud de relatie met de vorige. De oude score moet blijven verwijzen naar de oude data.

Hugging Face Datasets koppelt fingerprints aan de staat van een dataset en aan de transformaties ervan om de cache te beheren. Dat mechanisme is nuttig, maar je moet ook de herkomst van de data en de voorbewerking bewaren. Een transformatie die niet te hashen is, kan bijvoorbeeld tot een willekeurige fingerprint leiden: de cache-identificatie vervangt op zichzelf niet je herkomstdossier.

Voeg voor vastgelegde artefacten de grootte en de bestandsvingerafdruk toe. Een SHA-256-digest die vóór en na een kopie wordt berekend, maakt het mogelijk om te verifiëren dat de bytes overeenkomen met de bewaarde referentie. Het bewijst noch de kwaliteit van de labels, noch de gebruiksrechten, noch de afwezigheid van lekken tussen de splits.

Technische bronnen: Hugging Face Datasets — fingerprints en transformaties · Python 3.14 — bestandsvingerafdrukken met hashlib

Metrieken, voorspellingen en artefacten met elkaar verbinden

Een metricregel zou de run, het geëvalueerde artefact, de evaluatieset, de versie van de metric en de scope moeten identificeren. Geef aan of de waarde betrekking heeft op een tussenliggende checkpoint, het eindmodel of een subgroep. Een curve volstaat niet als je niet meer weet welk bestand bij het gekozen punt hoort.

Bewaar de voorspellingen met hun invoer-ID, hun status en de informatie die nodig is voor de evaluatie. De verwachte referenties kunnen in een apart, geversioneerd bestand blijven staan. Onderscheid bij gestructureerde uitvoer het ruwe resultaat, het geparseerde resultaat en het oordeel: het corrigeren van de parsing mag de oorspronkelijke uitvoer niet overschrijven.

Met MLflow kun je metrics koppelen aan modellen en aan data. Pas met bestanden hetzelfde principe toe via expliciete identifiers. Houd een leesbare inventaris bij van de artefacten: gewichten of adapter, generatieparameters, uitvoer, evaluatierapport en beslissingsnotitie. Ga er niet van uit dat een schermafbeelding deze bestanden vervangt.

Technische bronnen: MLflow — metrics, modellen en datasets met elkaar verbinden

Voorbeeld: zes runs en een duplicaat dat een tekort verbergt

Laten we een classificatievoorbeeld nemen met twee configuraties en drie seeds. Dat levert zes geplande runs op. Elk moet dezelfde 300 evaluatie-ID's voorspellen: de volledige map verwacht dus 6 × 300 = 1.800 unieke paren (run_id, input_id). Deze berekening beschrijft een verwachte inventaris, geen werkelijk uitgevoerd experiment.

Stel dat een bestand 300 regels bevat, maar dat de identifier doc-042 twee keer voorkomt en doc-117 ontbreekt. Het totaal aantal regels lijkt correct; toch zijn er maar 299 unieke ID's. Deze run faalt voor de dekkingscontrole totdat de afwijking is verklaard en gecorrigeerd.

Als elke run vervolgens wordt geëvalueerd op het volledige corpus en op zijn subgroep van lange teksten, krijg je twaalf metricregels voor een gegeven metric. Dat blijven zes runs, geen twaalf onafhankelijke trainingen. De evaluatiesleutel moet de scope bevatten om dit onderscheid te bewaren.

Het dossier sluiten met een leesbare beslissing

Controleer voordat je een run als voltooid verklaart de aanwezigheid en openbaarheid van de bestanden, de overeenkomst van de identifiers, de herberekenbaarheid van de metrics en de status van elke fout. Een technisch voltooide poging kan toch worden afgewezen wegens onvoldoende kwaliteit. Houd deze twee statussen gescheiden.

De beslissingsnotitie bundelt de vraag, de vergeleken varianten, het vooraf aangekondigde criterium, de weerhouden resultaten en de redenen voor uitsluiting. Vermeld de run_id's en de artefactpaden in plaats van 'het laatste model'. Voeg de beperkingen toe: weinig herhalingen, onvoldoende subgroep, versie niet teruggevonden of vergelijking die onmogelijk is geworden.

Een latere correctie moet een spoor achterlaten: nieuwe evaluatie, nieuw rapport en reden voor de wijziging. Bewaar de oude conclusie als een geïdentificeerde historische versie, zonder dat die als huidige beslissing verschijnt. Controleer ten slotte of de geëxporteerde kopie opent vanuit de bestemmingsmap.

Onnodige verzameling en beloftes over reproduceerbaarheid vermijden

Verzamel de velden die nodig zijn voor het bewijs, niet alle omgevingsvariabelen of de terminalgeschiedenis. Een configuratie of een URL kan een token bevatten; maak een deelbare versie zonder secrets en bewaar gegevens die privé moeten blijven op hun toegestane locatie. Technische test-ID's hoeven geen persoonsnaam te bevatten.

Een volledig dossier vergroot de mogelijkheid om een experiment te herhalen en te begrijpen. Het garandeert geen numerieke gelijkheid tussen platforms of versies: PyTorch documenteert deze beperkingen van reproduceerbaarheid. Onderscheid het protocol terugvinden, het artefact opnieuw laden en de getallen exact reproduceren.

Het IteraGPU-carnet kan je doelstellingen, parameters en beslissingen bewaren, met de nuttige referenties. Het start geen runs en verzamelt niet automatisch bestanden of telemetrie. Gebruik het als index van je redenering en bewaar het artefactdossier in je eigen back-ups.

Technische bronnen: PyTorch 2.14 — grenzen aan reproduceerbaarheid tussen omgevingen

Praktische vragen