Kies een structuur die je kunt uitleggen
Maak een map met de naam van het project en dan een paar plekken met duidelijke rollen. De naam van een persoon of de datum van vandaag volstaat niet altijd om de inhoud zes weken later te begrijpen. Een notitie in de hoofdmap moet uitleggen waar de inputs, de lopende tests en de gekozen levering staan.
De Universiteit van Cambridge raadt aan om vroeg een ordening en consistente naamgevingsregels af te spreken. Het model hieronder is een BriefGPU-voorstel voor een kleine sessie. Pas het aan als je software al een projectstructuur oplegt; verplaats de gekoppelde bronnen niet zonder te controleren of het project ze terugvindt.
| Emplacement proposé | Ce qu’il contient | Règle de travail |
|---|---|---|
| 00_lire-moi.txt | Doel, mapindeling en gekozen test. | Werk de nuttige beslissingen bij. |
| 01_entrees | Ontvangen bronnen en geïdentificeerde versies. | Bewaar hier geen outputs van de verwerking. |
| 02_reglages | Parameters en toolversies per test. | Bewaar de instellingen die echt gebruikt zijn. |
| 03_sorties/essai-01 | Resultaten van een geïdentificeerde uitvoering. | Maak een andere map voor de volgende test. |
| 04_suivi | Inventaris, logboek en validatiefeedback. | Koppel elk resultaat aan zijn bron. |
| 05_livraison/v01 | Selectie klaar om aan te leveren. | Markeer elke nieuwe leveringsversie. |
Houd de ontvangen input herkenbaar
Maak vóór de eerste verwerking een lijst van de bronnen met hun oorspronkelijke naam en locatie. Bewaar een intacte versie van deze inputs, zoals Cornell aanraadt voor ruwe data. De simpele naam "originelen" beschermt de inhoud niet: geef de software een andere uitvoermap en controleer het gedrag op een testbestand.
Als je een input moet converteren of bijsnijden vóór de berekening, behandel die voorbereiding dan als een gemarkeerde stap. Houd de link met de ontvangen bron. Zo kun je een al aanwezig defect, een voorbereidingsprobleem en een effect van de GPU-verwerking van elkaar onderscheiden.
Wanneer een nieuwe bron de oude vervangt, noteer dan de versie en de outputs die herzien moeten worden. Overschrijf niet stil een bestand dat gebruikt wordt door een test die je wilt begrijpen. De regel is de nuttige herkomst bewaren, niet alle werkkopieën voor altijd houden.
Geef elke werkeenheid een stabiele identifier
Een korte identifier zoals image-001 helpt om dezelfde input door meerdere tests te volgen. Zijn rol verandert niet wanneer een output wordt goedgekeurd. Houd de validatiestatus in de inventaris in plaats van bestanden telkens te hernoemen naar "goed", "slecht" of "bijna-definitief".
Voor honderd inputs geven de nummers 001 tot 100 een vast houvast. Voeg een zakelijke referentie toe wanneer die nodig is voor de levering. Ga er niet van uit dat twee bestanden met de naam photo.png, ontvangen in twee verschillende submappen, hetzelfde voorstellen. Het volledige pad van de input moet aan de identifier gekoppeld blijven.
Kies namen die compatibel zijn met de tools van bestemming. Windows reserveert onder meer de tekens dubbele punt, vraagteken en asterisk; de gewone regels laten ook niet toe om twee namen alleen op basis van hoofdletters betrouwbaar te onderscheiden. Een naam zoals image-007_essai-02.png voorkomt die dubbelzinnigheid. Controleer de eigen beperkingen van je andere tools in plaats van universele compatibiliteit te beloven.
Voorbeeld: twee tests, één enkele verzameling bronnen
Stel dat er acht afbeeldingen in twee mappen binnenkomen. De inventaris kent image-001 tot en met image-008 toe en bewaart hun oorspronkelijke paden. De eerste passage gebruikt de instellingen essai-01; alle uitvoer gaat naar de bijbehorende map. Een fout op image-003 en image-006 leidt tot een tweede poging die beperkt blijft tot die twee invoeren.
De zes bevredigende resultaten van de eerste poging worden niet opnieuw berekend om de map uniformer te maken. De inventaris geeft aan welke uitvoer voor elke invoer is gekozen. De levering v01 bevat acht bestanden met de verwachte namen, ook al komt hun herkomst uit twee pogingen. Dit voorbeeld beschrijft een organisatie, zonder te veronderstellen dat de instellingen de resultaten noodzakelijk verbeteren.
| Entrée | Sortie retenue dans l’exemple | Réglages à retrouver | État |
|---|---|---|---|
| image-001 | 03_sorties/essai-01/image-001.png | 02_reglages/essai-01.txt | Geaccepteerd |
| image-003 | 03_sorties/essai-02/image-003.png | 02_reglages/essai-02.txt | Geaccepteerd na herneming |
| image-006 | 03_sorties/essai-02/image-006.png | 02_reglages/essai-02.txt | Geaccepteerd na herneming |
Bewaar de instellingen op het moment van de poging
Een bestand met de naam essai-02.txt kan een eenvoudige notitie zijn als de software de parameters niet kan exporteren. Noteer de versie van de tool, het eventuele model, de betrokken invoeren en de waarden die je hebt gekozen. Voeg de reden van de wijziging ten opzichte van de vorige poging toe. Een schermafbeelding kan de notitie aanvullen wanneer de parameters alleen in een venster zichtbaar zijn.
Vermijd één enkele notitie 'huidige instellingen' die na elke passage wordt vervangen. Die zou de laatste poging verklaren, maar niet meer de oudere uitvoer. Als meerdere pogingen dezelfde parameters gebruiken, verwijs dan naar dezelfde geïdentificeerde configuratie in plaats van die onnodig over te schrijven.
De versie van de software en de parameters vergemakkelijken de uitleg van een resultaat; ze garanderen op zichzelf geen identieke reproductie. Sommige toepassingen vragen andere informatie of bronnen. Volg hun documentatie voor een precieze herneming, vooral wanneer het om een trainingsstatus gaat.
Houd een logboek bij dat de beslissingen verklaart
Het logboek vult de inventaris aan. Die beantwoordt 'waar staat deze invoer?'; het logboek beantwoordt 'waarom hebben we gewijzigd?'. Een paar regels met datum volstaan: betrokken poging, observatie, beslissing en volgende controle. Vermijd elk bericht van de software over te schrijven als niemand er iets aan heeft.
Voor het voorbeeld zou een nuttige regel zijn: 'essai-01: onvolledige contouren op image-003 en image-006; deze twee invoeren opnieuw doen met instelling B; de andere uitvoer bewaren in afwachting van definitieve validatie.' Voeg na de beoordeling de effectieve beslissing toe. Herschrijf de oorspronkelijke observatie niet alsof de fout nooit heeft bestaan.
Lees technische logboeken na voordat je ze doorstuurt: ze kunnen privépaden of toegangsmiddelen bevatten. Houd geheimen gescheiden van de documentatiemap. De notitie voor een collega moet het werk uitleggen met de informatie die hij nodig heeft.
Onderscheid ordening, levering en back-up
De werkmap bewaart de pogingen die nuttig zijn voor je redenering. De leveringsmap verzamelt wat de ontvanger moet krijgen. De back-up bewaart de nodige onderdelen op een andere bestemming, met een kopiecontrole. Drie mappen naast elkaar op dezelfde ruimte vervullen deze drie functies niet op zichzelf.
Kopieer niet alle bronnen naar elke testmap. Verbind de uitvoer met de invoer via de inventaris. Voor de levering kan een geselecteerde kopie nuttig zijn om een zelfstandig geheel af te leveren; noteer dan de herkomst en de versie. Volg voor de back-up de aparte gids, die de inventaris en de controle na overdracht beschrijft.
Controleer voordat je de afgewezen varianten opruimt welke nog nodig zijn om een beslissing te verklaren of het werk opnieuw te doen. Deze organisatie legt geen bewaartermijn op. Ze laat toe te beslissen wat het bewaren waard is en daarna de kopie te vinden die als referentie dient.
Doe een controle op basis van een willekeurig gekozen uitvoer
Kies een leveringsbestand zonder eerst je software te openen. Vind op basis van de naam en de inventaris de invoer, de poging die het heeft geproduceerd, de instellingen en de acceptatiebeslissing terug. Herhaal dit met een uitvoer die een herneming nodig had. Als het traject afhangt van je geheugen, ontbreekt er een schakel in de opvolging.
Controleer daarna de hoeveelheden: aantal verwachte inputs, behouden resultaten, geblokkeerde items en uitgesloten varianten. Een netjes geordend dossier kan nog steeds onvolledig zijn. Deze kleine controle is klaar wanneer de afwijkingen een reden hebben en iemand anders kan begrijpen welke bestanden gebruikt moeten worden.