7.4 Zarządzanie assetami i wersjonowanie

Przy stu assetach folder wystarcza. Przy dziesięciu tysiącach to on decyduje, czy odpowiesz na pytanie w minutę, czy w dzień — a pytania, które przychodzą, nie są opcjonalne. Który model to zrobił? Co opublikowaliśmy w wersji trzeciej? Czy da się to odtworzyć? Czy to ta sama grafika, którą opublikowaliśmy w marcu?

Ten rozdział to najmniejszy system, który na nie odpowiada.

Struktura biblioteki

Pięć osi, a struktura wynika z pytań, nie z estetyki:

assets/
  <persona>/                     one folder per persona
    00-bible/                    canon, timeline register (2.3, 2.4)
    10-references/               face, body, outfits, locations, props (5.3)
    20-datasets/                 training inputs (4.4)
    30-models/                   adapters, hashes, base version (4.5)
    40-prompt-lists/             variant files (5.2)
    50-output/                   raw generations, by run
      <run-id>/                  one folder per batch
        manifest.json            prompts, seeds, model, references
    60-approved/                 passed QA, not yet published (5.6)
    70-published/                what went out, when, where
    80-queue/                    fix queue and bank
    99-archive/                  retired versions, never overwritten

Trzy decyzje strukturalne, których warto bronić.

Folder na run. Outputy grupujemy według batcha, który je wyprodukował, bo to jest jednostka, którą trzeba będzie unieważnić. Jeśli run użył złego adaptera, chcesz zidentyfikować wszystko, co powstało — a to operacja na folderze, nie zapytanie do bazy.

Zatwierdzone i opublikowane to osobne stany. Bank z 5.6 to materiały zatwierdzone, ale jeszcze nieopublikowane, i to inny stan niż opublikowane. Scalenie ich oznacza, że nie odróżnisz, co widziała publiczność.

Archiwum, nigdy usuwanie. Wycofane reference'y i adaptery przenosisz do archiwum razem z ich datami. Procedura wycofywania z rozdziału 4.7 i rejestry ujawnienia z 11.3 potrzebują tego, żeby stare wersje istniały.

Status assetu

Sześć stanów, a każdy asset jest dokładnie w jednym:

Dlaczego statusy, a nie same foldery. Status to zapytanie. „Ile mam zatwierdzonych assetów?" i „co jest zatwierdzone dłużej niż trzydzieści dni bez publikacji?" to pytania, które zmieniają decyzje, a odpowiesz na nie tylko wtedy, gdy stan jest zapisany wprost.

Jeden status wymaga dyscypliny: rejected wymaga kodu defektu z dwunastowierszowej tabeli w 5.6, nie samej flagi. To właśnie kody zamieniają historię odrzuceń w diagnozę twojego pipeline'u — różnica między wiedzą, że rejection rate wynosi 30%, a wiedzą, że wynosi 30% z powodu dłoni.

Metadane: pola, które zasługują na swoje miejsce

Na każdy asset, z powodem dla każdego pola:

Sześć z szesnastu istnieje dla zgodności. prompt, model, adapter, created, published_url i disclosure_label to pola, które pozwalają odpowiedzieć regulatorowi albo platformie na pytanie, co opublikowałeś i jak to powstało. Obowiązki oznaczenia odczytywalnego maszynowo z rozdziału 11.5 i rejestry ujawnienia z 11.3 zależą od tego, czy te dane istnieją, a odtworzyć ich później nie da się.

Praktyczny test: jeśli brand poprosi cię o dowód, jak powstał frame w reklamie, odpowiesz z systemu w minutę? Jeśli nie — brakuje jakiegoś pola.

Automatyzacja metadanych

Ręczne wpisywanie metadanych nie przeżyje zderzenia z wolumenem. Pisać je musi system.

W momencie generacji: orchestrator (7.3) zapisuje prompt, wariant, seed, wersję modelu, wersję adaptera i ścieżki reference'ów do manifestu runu. Pipeline już to wszystko zna — to krok odczytu i zapisu, nie nowa praca.

Na etapie QA: człowiek dopisuje wynik i status — dwa pola, które naprawdę wymagają oceny. Wszystko inne jest już zapisane.

W momencie publikacji: scheduler zapisuje URL, datę, platformę i etykietę ujawnienia. Znowu mechanicznie.

Konsekwencja: jedyne pola, których dotyka człowiek, to qa_score, defect_code i status. Trzy pola — dlatego ten system jest wykonalny.

Gdzie to trzymać. Ustrukturyzowany plik na asset (JSON obok obrazu) albo baza danych. Pojedynczy JSON na asset przeżyje zmiany narzędzi, da się przeszukać grepem i nie wymaga infrastruktury; baza jest szybsza w skali, a gorsza w przenoszeniu. Zacznij od plików i przenieś się wtedy, gdy trafisz na zapytanie, na które nie umiesz odpowiedzieć.

Deduplikacja i wykrywanie near-duplikatów

Publikacja tego samego frame'a dwa razy to konkretna awaria z konkretną przyczyną: listy wariantów promptów bywają używane ponownie, a operator tego nie pamięta.

Dwa sprawdzenia, oba tanie:

Dokładne duplikaty po hashu. Banalne i łapie kopię.

Near-duplikaty przez porównanie percepcyjne nowego assetu z ostatnimi N opublikowanymi. Hash obrazu albo porównanie embeddingów łapie przypadek „ta sama scena, wygenerowana ponownie z drobną zmianą" — ten, który naprawdę dociera do publiczności.

I jedno sprawdzenie przez człowieka, którego żaden system nie zastąpi: czy to wygląda jak coś, co opublikowaliśmy niedawno? Krocząca reguła wykluczania z 5.3 to wersja ręczna i warto ją zostawić nawet przy automatyzacji, bo near-duplikat to osąd o pamięci publiczności, nie porównanie pikseli.

Wersjonowanie samych assetów

Trzy osobne przestrzenie wersji, które ludzie mieszają:

Wersje tożsamości. LoRA v1, v2, v3, każda ze swoim base hashem. Zmiana tutaj zmienia twarz persony i jest zdarzeniem dużej wagi (4.5, 4.7).

Wersje reference'ów. Sheet v1 dla LoRA v1. Nowy sheet dla tego samego adaptera to zdarzenie mniejszej wagi (5.1).

Wersje produkcyjne. Lista promptów 2026-Q3, wersja graphu, wersja presetu. Ich zmiana zmienia to, jak renderowana jest ta sama tożsamość.

Reguła: każdy asset zapisuje wszystkie trzy, bo odpowiedź na pytanie „dlaczego to wygląda inaczej" zależy od tego, która przestrzeń się zmieniła. Magazyn assetów, który zapisuje tylko jedną, nie odpowie na to pytanie.

Backupy

Niegustowne i obowiązkowe, bo biblioteka to cały biznes. Utrata reference library oznacza utratę możliwości odtworzenia persony.

Trzy kopie, dwa nośniki, jedna poza siedzibą. Klasyczne sformułowanie i tutaj też się trzyma. Dysk lokalny, druga kopia lokalna na innym sprzęcie i kopia w chmurze albo zdalnie.

Najpierw kopiuj reference'y, adaptery, listy promptów i metadane. Są małe i nie do odtworzenia. Wygenerowane outputy są duże i regenerowalne, więc mają najniższy priorytet w backupie.

Raz przetestuj odtworzenie. Nieprzetestowany backup to plik — tak mówi reguła higieny z 3.6. Odtworzenie jednego folderu z backupu to piętnastominutowe ćwiczenie, które dowodzi całego systemu.

Gdzie to się psuje

Jeden płaski folder. Pytania bez odpowiedzi w ciągu miesięcy.

Scalenie zatwierdzonych z opublikowanymi. Tracisz rozeznanie, co widziała publiczność.

Usuwanie wycofanych wersji. Tracisz możliwość wyjaśnienia własnej historii.

Ręczne metadane. Nikt ich nie będzie utrzymywał.

Zapis modelu bez base hasha. Pułapka niezgodności, nie do zdiagnozowania.

Brak sprawdzania near-duplikatów. Powtórka dociera do publiczności.

Mieszanie trzech przestrzeni wersji. „Dlaczego to wygląda inaczej" staje się pytaniem bez odpowiedzi.

Brak przetestowanego backupu. Biblioteka to cały biznes.

Bramka

1. Czy biblioteka ma jeden folder na personę, z osobnymi obszarami na runy, zatwierdzone, opublikowane i archiwum?
2. Czy każdy asset jest dokładnie w jednym z sześciu stanów?
3. Czy zapisujesz szesnaście pól, w tym sześć, które istnieją dla zgodności?
4. Czy pola metadanych są zapisywane automatycznie w momencie generacji i publikacji, a człowiek dotyka tylko trzech pól?
5. Czy masz sprawdzanie zarówno dokładnych duplikatów, jak i near-duplikatów?
6. Czy odróżniasz wersje tożsamości, reference'ów i produkcyjne?
7. Czy masz trzy kopie i czy przetestowałeś odtworzenie?

Co z tego zostaje

Pięcioosiowa struktura biblioteki z folderem na run i osobnymi stanami zatwierdzonych i opublikowanych, sześć statusów assetu z dyscypliną, że odrzucenia noszą kod defektu, szesnaście pól metadanych z sześcioma istniejącymi dla zgodności, plan automatyzacji, który sprowadza ręczne wpisywanie do trzech pól, wykrywanie dokładnych duplikatów i near-duplikatów, trzy przestrzenie wersji, które trzeba zapisywać osobno, oraz reguła backupu z jednym testem.