Wersjonowanie danych i modeli w systemach AI

Gdy odpowiedź systemu AI nagle się zmienia, sama nazwa modelu językowego zwykle nie wystarcza, by wyjaśnić przyczynę. Mogły zmienić się dokumenty źródłowe, sposób ich podziału na fragmenty, model embeddingowy, indeks albo konfiguracja wyszukiwania. W systemie predykcyjnym analogiczny wpływ mają definicje cech, okno czasowe i sposób obsługi braków. Wersjonowanie tych elementów pozwala ustalić, jaki dokładnie zestaw danych i ustawień doprowadził do wyniku.

Praktyczny punkt wyjścia to identyfikator wydania obejmujący wersję kodu, konfiguracji, zbioru wejściowego i artefaktów modelowych. Nie musi to być jeden rozbudowany system: wystarczy spójny rejestr, który łączy wdrożenie z manifestem artefaktów. Błędem jest zapisywanie wyłącznie numeru obrazu kontenera, bo obraz nie opisuje zmian danych ani indeksu. Warto też odróżniać wersję produktu od wersji eksperymentu: ta pierwsza musi być stabilna i audytowalna, druga może służyć do porównań.

Manifest powinien pozwalać odtworzyć ścieżkę od surowego źródła do odpowiedzi. Dla potoku RAG uwzględnij identyfikatory źródeł, datę ekstrakcji, reguły czyszczenia, strategię podziału tekstu, wersję modelu embeddingowego i parametry indeksu. Zapisz również konfigurację wyszukiwania, filtrowania metadanych, szablonu promptu i modelu generującego. W predykcji dodaj schemat danych, definicje cech, wersję modelu oraz progi decyzyjne.

Wybieraj pola, które rzeczywiście wpływają na wynik; nie kopiuj bezrefleksyjnie całych logów z danymi osobowymi lub sekretami. Manifest może zawierać skróty kryptograficzne plików, referencje do kontrolowanego magazynu i jawne numery wersji. Sam skrót potwierdza zgodność bajtów, ale nie zapewnia dostępności pliku ani prawa do jego ponownego użycia. Typowa pułapka to aktualizowanie dokumentu w miejscu bez zachowania poprzedniej rewizji. Przed publikacją wydania sprawdź, czy każda referencja wskazuje na niezmienny artefakt i czy osoba z zespołu potrafi odtworzyć konfigurację.

belmont-rental.pl

Embeddingi zależą od modelu, wersji jego dostawcy, normalizacji tekstu i parametrów generowania. Zmiana któregokolwiek z tych elementów może sprawić, że wektory przestaną być porównywalne z dotychczasowymi. Dlatego przypisz indeksowi wersję obejmującą co najmniej źródłowy zbiór dokumentów, model embeddingowy, transformacje wejścia i ustawienia indeksowania. Zachowuj też informację, które rekordy zostały pominięte i dlaczego.

Przy zmianie modelu nie nadpisuj od razu aktywnego indeksu. Zbuduj równoległy indeks, policz dokumenty, sprawdź wymiary wektorów i przetestuj reprezentatywne zapytania. Porównaj trafność wyników oraz opóźnienie na własnym zestawie testowym, a następnie przełącz ruch kontrolowanie. Jeśli system nie pozwala na łatwe utrzymanie dwóch indeksów, przygotuj plan odtworzenia poprzedniego stanu i zmierzone okno niedostępności. Częsty błąd to założenie, że zgodna liczba wymiarów oznacza zgodność semantyczną. Nie oznacza: modele mogą tworzyć przestrzenie o odmiennych właściwościach.

Prompt traktuj jak wersjonowany komponent oprogramowania. Zapisuj jego treść, format wejścia i wyjścia, reguły walidacji oraz wersje narzędzi, z których może korzystać model. Zmiana promptu, kolejności kontekstu albo limitu tokenów może wpłynąć na zachowanie nawet wtedy, gdy model pozostaje ten sam. Dla każdej wersji przygotuj zestaw przypadków obejmujący typowe pytania, błędne dane, brak źródeł i próby wymuszenia odpowiedzi spoza dostępnego kontekstu.

Wdrożenie rozpocznij od testów offline, potem użyj ruchu cieniowanego lub niewielkiego udziału rzeczywistych zapytań, jeśli pozwalają na to zasady prywatności i architektura. Ustal wcześniej mierniki akceptacji, na przykład poprawność cytowania źródeł ocenianą na ręcznie sprawdzonym zestawie, odsetek błędów walidacji i czas odpowiedzi. Nie przedstawiaj automatycznej oceny modelu jako dowodu prawdziwości. Wersjonuj także schemat odpowiedzi i politykę ponawiania prób; inaczej porównanie dwóch wydań może mieszać zmianę generowania ze zmianą obsługi błędów.

W modelach predykcyjnych szczególnie ważne jest odnotowanie, kiedy i jak powstała każda cecha. Zapisz źródło, definicję, okno agregacji, obsługę wartości brakujących oraz moment dostępności danych. Dzięki temu można wykryć wyciek informacji z przyszłości, na przykład użycie pola aktualizowanego dopiero po zdarzeniu, które model ma przewidywać. Wersja modelu powinna wskazywać również zbiór uczący, walidacyjny i testowy oraz definicję etykiety.

Przykładowo, model prognozujący ryzyko opóźnienia zamówienia nie powinien korzystać z informacji o faktycznej dacie dostawy, jeśli ta data nie jest znana w chwili prognozy. Dla każdej wersji zachowaj kod transformacji cech i parametry uczenia, a także uzasadnienie podziału danych. Sam zapis parametrów modelu może nie wystarczyć, jeśli zależności bibliotek lub źródłowe dane uległy zmianie. Przed wdrożeniem sprawdź zachowanie na danych z późniejszego okresu i określ, jak często będzie oceniana jakość. Konkretne progi alarmowe trzeba ustalić na podstawie ryzyka danego zastosowania, nie kopiować z innego projektu.

Każda zmiana powinna mieć plan wejścia i wyjścia. Przed wdrożeniem określ właściciela wydania, zakres zmian, oczekiwane różnice, testy blokujące publikację oraz warunek wycofania. W systemie wyszukiwania przygotuj poprzedni indeks lub procedurę jego szybkiego odtworzenia; w usłudze predykcyjnej zachowaj poprzedni artefakt i konfigurację progów. Zapisz też, jak kierowany jest ruch, aby można było przełączyć wersję bez niekontrolowanej edycji ręcznej.

Po wdrożeniu obserwuj błędy, opóźnienia, rozkłady wejść i mierniki właściwe dla zadania. Zmiana rozkładu danych jest sygnałem do zbadania, a nie automatycznym dowodem pogorszenia jakości. Zanim podejmiesz decyzję o ponownym trenowaniu, sprawdź jakość etykiet, świeżość źródeł oraz ewentualne zmiany procesu biznesowego. Częsty błąd organizacyjny polega na traktowaniu wycofania jako porażki. W praktyce to zaplanowany mechanizm ograniczania ryzyka. Procedury należy regularnie ćwiczyć, bo niezweryfikowany rollback może okazać się niekompletny właśnie wtedy, gdy jest najbardziej potrzebny.