Proces AI: prowadź rejestr błędu i zmiany instrukcji

Oddziel błąd wyniku od zmiany narzędzia

Jeżeli model dopisuje termin albo pomija warunek, zachowaj scenariusz i odpowiedź. Nie poprawiaj tylko tekstu przeznaczonego dla klienta. Potrzebujesz informacji, która pomoże odtworzyć przyczynę.

Rejestr może korzystać z danych syntetycznych. Nie kopiuj prywatnej historii klienta do publicznego zestawu testów ani do promptu naprawczego.

Nazwij naruszoną zasadę

Zapisz konkretny warunek: odpowiedź miała używać tylko wskazanego dokumentu, nie mogła potwierdzać refundacji albo powinna była wskazać brak informacji. Ogólne model był słaby nie pozwala sprawdzić poprawki.

Oddziel faktyczny błąd od preferencji stylistycznej. Zmiana tonu i korekta fałszywego twierdzenia mają inne znaczenie dla ryzyka.

Karta zmiany

Po poprawce zachowaj wcześniejszą wersję scenariusza. Dzięki temu nie dopasujesz testu do nowej instrukcji.

Powtórz także poprawne przypadki

Nowa instrukcja może naprawić brak i jednocześnie pogorszyć inne odpowiedzi. Wybierz kilka wcześniej sprawdzonych scenariuszy oraz przypadek z nieznanym polem. Nie usuwaj niewygodnego wyniku z podsumowania.

Zapisz wersję modelu lub ustawienia dostępne w swoim narzędziu. Jeśli dostawca zmienił produkt, nie twierdź, że test dotyczy identycznej konfiguracji.

Ogranicz zakres wdrożenia

Po udanej próbie nazwij fragment procesu, który można wykorzystać, oraz kontrolę człowieka. Nie nadawaj całej automatyzacji etykiety bezbłędnej po jednej poprawce.

Ta karta nie prezentuje wykonanego benchmarku ani oszczędności czasu. Jest rejestrem do własnego użycia. Publiczny wynik wymaga rzeczywistych prób i jawnego zakresu.

Zacznij od stałego identyfikatora przypadku

Własna karta CHANGE-01 ma fikcyjny scenariusz E-01: źródło nie podaje terminu, a oczekiwany szkic powinien zachować brak. Nie wpisujemy żadnej wygenerowanej wypowiedzi. Pole wyniku modelu pozostaje niewykonane. Przykład definiuje warunek do sprawdzenia, a nie twierdzi, że konkretny dostawca popełnił błąd.

Zapisz osobno identyfikator przypadku, wersję materiału wejściowego, instrukcji i kryterium. Dla ćwiczenia wybieramy DATA-v1, PROMPT-v1 oraz regułę „nie dodawaj daty”. Te oznaczenia są umowne. W realnej próbie pozwolą odtworzyć, co otrzymało narzędzie. Zmiana opisu przypadku bez nowej wersji utrudnia ocenę, czy poprawiłeś proces, czy zastąpiłeś test łatwiejszym.

Przypisz zmianę do jednego warunku

W wariancie PROMPT-v2 dopisujemy obowiązek oznaczenia brakującego terminu jako nieznany. DATA-v1 i kryterium pozostają bez zmian. Oczekiwane porównanie dotyczy tej jednej reguły. Nie nazywamy poprawki skuteczną, dopóki nie mamy rzeczywistego szkicu po ponownej próbie. Sam tekst nowej instrukcji nie jest dowodem jej wykonania.

Jeżeli równocześnie zmienisz model, źródło i polecenie, zanotuj te trzy zmiany. Nie przypisuj różnicy jednej z nich bez odrębnego sprawdzenia. W naszym pliku status testu po zmianie wciąż brzmi niewykonany. Nie wpisujemy zaliczenia, liczby naprawionych błędów ani poprawy procentowej, której nie obserwowaliśmy.

Zachowaj mały zestaw różnych oczekiwań

Ćwiczenie ma trzy identyfikatory. E-01 wymaga zachowania braku terminu, E-02 wskazania konfliktu dwóch źródeł, E-03 zachowania ograniczenia uprawnień do szkicu. To różne warunki, choć wszystkie mogą dotyczyć obsługi. Nie usuwaj E-02 i E-03 po zmianie instrukcji tylko dlatego, że chcesz naprawić pierwszy przypadek.

W izolowanej kontroli rejestru sprawdzamy obecność tych trzech identyfikatorów i wspólną wersję kryteriów. Ta kontrola wykrywa pominięty przypadek lub zmianę zakresu. Nie ocenia odpowiedzi AI i nie dowodzi bezpieczeństwa integracji. NIST opisuje zarządzanie ryzykiem; karta jest naszym praktycznym sposobem zapisywania tego, co zostało sprawdzone oraz co pozostaje nieznane.

Przygotuj decyzję i drogę wycofania

Po rzeczywistej próbie wpisz zaobserwowane zachowanie, sprawdzony warunek i ograniczenie. Zanim użyjesz szkicu, człowiek zatwierdza fakty oraz uprawnienia. Dla własnej procedury zachowaj poprzednią wersję, osobę odpowiedzialną i sposób powrotu do ręcznej obsługi. W ćwiczeniu nie wyznaczamy pracownika ani nie przeprowadzamy wdrożenia.

CSV służy do odtworzenia wariantów v1/v2 i oczekiwań E-01–E-03. Nie zawiera prawdziwego zgłoszenia, prywatnej wiadomości ani sfałszowanego benchmarku. Jeśli wyniku nie masz, pozostaw stan niewykonany. Rejestr jest użyteczny właśnie wtedy, gdy nie myli planowanej poprawki z potwierdzoną zmianą zachowania narzędzia.

Zauważ brak przypadku i zmienione kryterium

Przy izolowanym sprawdzeniu usuń z rejestru E-02. Zestaw zawiera wtedy dwa wymagane identyfikatory zamiast trzech, więc kontrola zakresu zatrzymuje podsumowanie. Nie opisujemy tego jako wyniku modelu. To wykryty brak w naszym demonstracyjnym spisie, który można sprawdzić bez generowania tekstu i bez danych klientów.

W drugim wariancie pozostaw trzy identyfikatory, lecz zmień kryterium E-03 między v1 i v2. Przypadek dotyczący braku uprawnienia do wysyłki nie jest porównywalny z nową oceną uprzejmości. Oznacz zmianę kryterium, zanim uznasz wynik za poprawę. Sam komplet trzech wierszy nie potwierdza jednakowego zakresu ani wykonania wszystkich prób.

Pobierz dane do własnego ćwiczenia

CSV zawiera wyłącznie przypadek syntetyczny opisany powyżej. To karta do samodzielnego sprawdzenia, nie wynik sklepu ani plik do importu w platformie.

Otwórz ćwiczenie CSV

Źródła i metoda

Autorska karta zadania z jawnymi założeniami i ograniczeniami. Nie przedstawia wykonanych prób, wyników sklepu ani opinii klientów. Aktualne ustawienia i obowiązki sprawdź w źródłach przed wdrożeniem. Rozwinięcie z 9.10.2026: własne ćwiczenie syntetyczne, karta danych i warunki interpretacji. Nie użyto rzeczywistych danych klientów, wyników kampanii ani wykonanych zamówień.

• UODO: informacje o ochronie danych — sprawdzono: 2026-10-08
• NIST: generative AI risk management profile — sprawdzono: 2026-10-09
• NIST: profil ryzyka generatywnej AI — sprawdzono: 2026-10-09

Daty sprawdzenia podano przy źródłach. Przykłady liczbowe są ilustracją obliczeń, a nie danymi konkretnego sklepu.