Escolha uma estrutura que você consiga explicar
Crie uma pasta com o nome do projeto e alguns locais com papéis claros. O nome de uma pessoa ou a data de hoje nem sempre bastam para entender o conteúdo seis semanas depois. Uma nota colocada na raiz deve explicar onde estão as entradas, os testes em andamento e a entrega escolhida.
A Universidade de Cambridge recomenda definir cedo uma classificação e regras de nomenclatura consistentes. O modelo abaixo é uma proposta do BriefGPU para uma pequena sessão. Adapte-o se o seu software já impõe uma estrutura de projeto; não mova seus recursos vinculados sem verificar que o projeto os encontra.
| Emplacement proposé | Ce qu’il contient | Règle de travail |
|---|---|---|
| 00_lire-moi.txt | Objetivo, plano das pastas e teste escolhido. | Atualizar as decisões úteis. |
| 01_entrees | Fontes recebidas e versões identificadas. | Não salvar aí as saídas do processamento. |
| 02_reglages | Parâmetros e versões das ferramentas por teste. | Manter os ajustes realmente usados. |
| 03_sorties/essai-01 | Resultados de uma execução identificada. | Criar outra pasta para o próximo teste. |
| 04_suivi | Inventário, registro e retornos de validação. | Ligar cada resultado à sua origem. |
| 05_livraison/v01 | Seleção pronta para entregar. | Identificar toda nova versão de entrega. |
Mantenha a entrada recebida reconhecível
Antes do primeiro processamento, monte a lista das fontes com seu nome original e seu local. Mantenha uma versão intacta dessas entradas, como recomenda Cornell para os dados brutos. O simples nome "originais" não protege o conteúdo: indique ao software uma pasta de saída diferente e controle seu comportamento em um arquivo de teste.
Se você precisar converter ou recortar uma entrada antes do cálculo, trate essa preparação como uma etapa identificada. Mantenha o vínculo com a fonte recebida. Assim você poderá distinguir um defeito já presente, um problema de preparação e um efeito do processamento na GPU.
Quando uma nova fonte substituir a antiga, anote a versão e as saídas a revisar. Não sobrescreva silenciosamente um arquivo usado por um teste que você deseja entender. A regra é conservar a proveniência útil, não guardar indefinidamente todas as cópias de trabalho.
Dê um identificador estável a cada unidade de trabalho
Um identificador curto como image-001 serve para acompanhar a mesma entrada ao longo de vários testes. Seu papel não muda quando uma saída é aceita. Mantenha o estado de validação no inventário em vez de renomear os arquivos sem parar como "bom", "ruim" ou "quase-final".
Para cem entradas, os números 001 a 100 dão uma referência regular. Adicione uma referência de negócio quando ela for necessária para a entrega. Não presuma que dois arquivos chamados photo.png, recebidos em duas subpastas diferentes, representam a mesma coisa. O caminho completo da entrada deve permanecer associado ao identificador.
Escolha nomes compatíveis com as ferramentas de destino. O Windows reserva, entre outros, os caracteres dois-pontos, ponto de interrogação e asterisco; suas regras comuns também não permitem distinguir com segurança dois nomes apenas pela letra maiúscula. Um nome como image-007_essai-02.png evita essas ambiguidades. Verifique as restrições próprias das suas outras ferramentas em vez de prometer compatibilidade universal.
Exemplo: dois testes, uma única coleção de fontes
Suponhamos oito imagens recebidas em duas pastas. O inventário atribui image-001 a image-008 e mantém seus caminhos originais. A primeira passagem usa as configurações ensaio-01; todas as suas saídas vão para a pasta correspondente. Uma falha em image-003 e image-006 leva a um segundo ensaio limitado a essas duas entradas.
Os seis resultados satisfatórios do primeiro ensaio não são recalculados para deixar a pasta mais uniforme. O inventário indica qual saída foi escolhida para cada entrada. A entrega v01 contém oito arquivos com os nomes esperados, mesmo que sua origem se divida entre dois ensaios. Este exemplo descreve uma organização, sem supor que as configurações melhorem necessariamente os resultados.
| 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 | Aceito |
| image-003 | 03_sorties/essai-02/image-003.png | 02_reglages/essai-02.txt | Aceito após retrabalho |
| image-006 | 03_sorties/essai-02/image-006.png | 02_reglages/essai-02.txt | Aceito após retrabalho |
Guarde as configurações no momento do ensaio
Um arquivo chamado ensaio-02.txt pode ser uma simples anotação se o software não souber exportar seus parâmetros. Anote a versão da ferramenta, o modelo eventual, as entradas envolvidas e os valores que você escolheu. Acrescente o motivo da mudança em relação ao ensaio anterior. Uma captura de tela pode complementar a anotação quando os parâmetros só forem visíveis em uma janela.
Evite uma anotação única "configurações atuais" substituída após cada passagem. Ela explicaria a última tentativa, mas não as saídas antigas. Se vários ensaios usarem os mesmos parâmetros, referencie a mesma configuração identificada em vez de copiá-la desnecessariamente.
A versão do software e os parâmetros facilitam a explicação de um resultado; não garantem por si sós uma reprodução idêntica. Alguns aplicativos exigem outras informações ou recursos. Siga a documentação deles para uma necessidade de retomada precisa, sobretudo quando se trata de um estado de treinamento.
Mantenha um diário que explique as decisões
O diário complementa o inventário. Este responde a "onde está esta entrada?"; o diário responde a "por que mudamos?". Algumas linhas datadas bastam: ensaio envolvido, observação, decisão e próxima verificação. Evite copiar cada mensagem do software se ninguém poderá usá-la.
Para o exemplo, uma linha útil seria: "ensaio-01: contornos incompletos em image-003 e image-006; refazer essas duas entradas com a configuração B; manter as outras saídas aguardando validação final." Após a revisão, acrescente a decisão efetiva. Não reescreva a observação inicial como se o defeito nunca tivesse existido.
Releia os diários técnicos antes de transmiti-los: eles podem conter caminhos privados ou meios de acesso. Mantenha os segredos separados da pasta de documentação. A anotação destinada a um colega deve explicar o trabalho com as informações de que ele precisa.
Distinga organização, entrega e backup
A pasta de trabalho guarda os ensaios úteis para o seu raciocínio. A pasta de entrega reúne o que o destinatário deve receber. O backup guarda os itens necessários em outro destino, com uma verificação de cópia. Três pastas colocadas lado a lado no mesmo espaço não cumprem por si sós essas três funções.
Não copie todas as fontes em cada pasta de ensaio. Relacione as saídas às entradas por meio do inventário. Para a entrega, uma cópia selecionada pode ser útil para entregar um conjunto autônomo; anote então sua origem e sua versão. Para o backup, siga o guia dedicado, que detalha o inventário e a verificação após a transferência.
Antes de limpar as variantes descartadas, verifique quais continuam necessárias para explicar uma decisão ou refazer o trabalho. Essa organização não impõe nenhum prazo de retenção. Ela permite decidir o que vale a pena guardar, e depois encontrar a cópia que serve de referência.
Faça uma verificação a partir de uma saída escolhida ao acaso
Escolha um arquivo de entrega sem abrir primeiro o seu software. A partir do nome e do inventário, encontre sua entrada, o ensaio que o produziu, suas configurações e a decisão de aceitação. Repita com uma saída que exigiu retrabalho. Se o percurso depender da sua memória, falta um elo no acompanhamento.
Em seguida, verifique as quantidades: número de entradas previstas, resultados selecionados, itens bloqueados e variantes excluídas. Uma pasta bem organizada ainda pode estar incompleta. Essa pequena verificação termina quando as divergências têm um motivo e outra pessoa consegue entender quais arquivos usar.