Zyski:
- Możliwość ustanawiania warstw sprawdzania wyników opartych na schematach i regułach
- Możliwość znaczącego wymagania obecności człowieka w pętli przy podejmowaniu decyzji o dużym wpływie
- Możliwość projektowania routingu opartego na weryfikacji i progach zaufania w drugim modelu
Model językowy jest płynny, przekonujący i często dokładny, ale „przekonujący” to nie to samo, co „poprawny”. Model może po cichu dopasować kwotę, datę lub pole JSON; Nazywa się to halucynacją (model z pewnością wytwarza informacje, które nie istnieją w rzeczywistości). W systemie korporacyjnym, jeśli dane wyjściowe zostaną przekazane do następnego kroku — płatności, wysłania wiadomości e-mail, zapisu w bazie danych — błąd przeniesie się do świata rzeczywistego. W tej części nauczymy się filtrować dane wyjściowe za pomocą warstw weryfikacyjnych, zanim trafią one do systemu, oraz wymagać zaangażowania człowieka w pętlę przy podejmowaniu decyzji o dużym wpływie.
Dlaczego wymagana jest walidacja wyników?
Dane wyjściowe modelu mogą zostać uszkodzone na dwa podstawowe sposoby: format (nie jest zgodny z oczekiwanym schematem JSON, brakuje/nadmiar pola) i treść (format jest poprawny, ale wartość jest błędna — nieistniejący kod produktu, nielogiczna data). Istnieje trzeci wymiar bezpieczeństwa: złośliwe dane wyjściowe (złośliwe polecenie powstałe w wyniku wstrzyknięcia lub wycieku). Solidny system zatrzymuje całą trójkę u drzwi.
Uwaga: „Model ogólnie dokładny” nie jest kryterium produkcyjnym. W systemie bez weryfikacji nawet jeden błąd na tysiąc oznacza 100 błędnych transakcji dziennie na 100 000 żądań dziennie.
Warstwy uwierzytelniania: krok po kroku
- Walidacja schematu. Sprawdź na maszynie, czy wynik jest zgodny z oczekiwaną strukturą: czy pola są obecne, czy ich typy są prawidłowe, czy wymagane pola są wypełnione?
- Walidacja reguł/logiki biznesowej. Czy wartości odpowiadają regułom biznesowym? (Ilość > 0, data nie jest w przyszłości, kod produktu należy do katalogu.)
- Kontrola odniesienia/źródła. Jeśli model generuje twierdzenie, czy można je powiązać ze źródłem? (Czy cytat RAG faktycznie znajduje się w dokumencie?)
- Walidacja drugim modelem (LLM-as-sędzia). Niezależny model ocenia wyniki jako „poprawne/niekompletne/ryzykowne”.
- Próg zaufania i orientacja. Jeśli model lub walidator zgłosi niską pewność, dane wyjściowe nie zostaną automatycznie zaliczone; jest skierowany do ludzi.
- Kontrola człowieka. Wynik o dużej sile działania lub o niskim bezpieczeństwie zależy od zgody eksperta.
Cztery szablony do kopiowania
Schemat + „wymyśl, jeśli nie wiesz” razem:
Zwróć odpowiedź TYLKO w następującym schemacie JSON: wpisz „niski”. NIGDY nie pisz szacunków tak, jakby były dokładne.
Weryfikacja z drugim modelem (podpowiedź sędziego):
Jesteś niezależnym walidatorem. Poniżej znajduje się tekst <source> i <claim>. Sprawdź, czy KAŻDA liczba i data w roszczeniu występują dosłownie w źródle. Dla każdego powiedz: „zweryfikowane | nie w źródle | zaprzecza źródłu”. Jeśli chociaż jeden z nich jest „nieobecny/sprzeczny”, oznacz wynik jako „WYMAGANY PRZEGLĄDU LUDZKIEGO”.<source>{{ tekst }</source><claim>{{ model_output }</claim>
Reguła routingu progu zaufania:
Reguła routingu:- emin_misin = „wysoki” ORAZ kwota < 10 000 TL -> przetwarzanie automatyczne - emin_misin = „średni” LUB kwota 10 000–100 000 TL -> weryfikacja drugiego modelu – emin_misin = „niska” LUB kwota > 100 000 TL -> wymagana zgoda człowieka
Karta podsumowująca audyt ludzki (przyspiesza przegląd):
Przedstawiając danej osobie decyzję, pokaż następującą kartę: - Co proponujesz? (jedno zdanie) - Na jakim źródle jest to oparte? (odniesienie do artykułu/dokumentu) – Jakie są 2 najsłabsze założenia? – Czy można je odwrócić, jeśli zostaną zatwierdzone? (tak/nie)
Słaba podpowiedź/silna podpowiedź
słabe podejście
Mocne podejście
„Odejmij kwotę od faktury” (tekst dowolny)
Ścisły schemat JSON + wartość null + pole zaufania
Zapisanie wyniku bezpośrednio do systemu płatności
Schemat → reguła → zatwierdzenie przez człowieka (jeśli konieczne)
Po prostu mówię modelowi: „bądź pewien”
Walidacja numeru/daty w drugim modelu
Przetwarzanie każdego wyniku z równą pewnością
Routing oparty na wpływie i zaufaniu
Silne podejście nie daje nadziei, że model jest poprawny; Tworzy drzwi, które złapią Cię, gdy się mylisz.
Trzy mini etui
Przypadek 1 – Sam program nie wystarczył. Automatyzacja księgowości wyodrębniała kwotę z faktur w formacie JSON. Schemat był poprawny, ale model wypisał na fakturze „125 000” zamiast „1250,00” (przesunięcie dziesiętne). W schemacie nie udało się tego uchwycić; Wychwycono weryfikację reguły („kwota musi być zgodna z sumą pozycji faktury o ±1%”) i zapobiegnięto nieprawidłowemu zapisowi kwoty 112 500 TL.
Przypadek 2 — Drugi model uchwycił halucynację. „30-dniowy okres wypowiedzenia” – stwierdził asystent prawny w podsumowaniu umowy; Jednak w umowie było to 90 dni. Kiedy niezależny sędzia oznaczył model jako „sprzeczny ze źródłem”, wyniki zostały przekazane człowiekowi i poprawione. Gdyby było to automatyczne, klient powiadomiłby o anulowaniu w oparciu o niewłaściwą datę.
Przypadek 3 — Routing zmniejszył obciążenie o 70%. System roszczeń ubezpieczeniowych automatycznie akceptował roszczenia niskokwotowe i o wysokim zabezpieczeniu, a do eksperta wysyłał tylko te powyżej progowe/niskozabezpieczone. Z 3200 codziennych żądań tylko 950 przypadło ludziom; eksperci poświęcili swój czas naprawdę ryzykownym 30%, a średni czas transakcji spadł z 4 godzin do 40 minut.
Wskazówka: nie konfiguruj kontroli człowieka tak, aby „ludzie mogli wszystko widzieć” — to zmęczy ludzi, a akceptacja stanie się pieczątką. Zamiast tego kieruj do człowieka jedynie produkty o dużym wpływie i niskim stopniu zaufania; Dzięki temu uwaga skupiona jest na tym, co naprawdę ważne.
Nadanie znaczeniu kontroli człowieka
Human-in-the-loop nie polega na umieszczaniu pola wyboru na papierze. Recenzent musi mieć (1) kontekst umożliwiający zrozumienie decyzji, (2) dostęp do źródła oraz (3) władzę, aby powiedzieć „nie”. W przeciwnym razie kontrola pozostaje kosmetyczna. Karta recenzji (czwarty szablon powyżej) ma zapewnić właśnie taki kontekst.
Typowe błędy
- Po prostu sprawdzam poprawność schematu i pomijam błędy dotyczące treści/wartości.
- Myśląc, że mówiąc modelowi „upewnij się”, dokonujesz prawdziwej weryfikacji.
- Automatycznie wdrażaj decyzje o dużym wpływie i nieodwracalności.
- Nadanie ludzkiej kontroli każdemu produktowi i zamiana zgody na bezsensowną pieczątkę.
- Powiedzenie recenzentowi „zatwierdzam” bez podania źródła i kontekstu.
- Przetwarzanie wszystkich wyników z tym samym ryzykiem bez ustalania progu zaufania i routingu.
Podsumowując
- Dane wyjściowe są uszkodzone na trzy sposoby: forma, treść i złośliwe zamiary; solidny system zatrzymuje wszystkie trzy przy drzwiach.
- Warstwy: walidacja schematu, logika reguł/biznesowa, kontrola źródła, drugi model (LLM-jako sędzia) i routing progu zaufania.
- Sterowanie człowiekiem w pętli powinno być obowiązkowe w przypadku wyjść o dużym wpływie i niskim poziomie bezpieczeństwa.
- Recenzja manualna musi mieć znaczenie: recenzent musi mieć kontekst, dostęp do zasobów i władzę, aby powiedzieć „nie”.
- Zarówno bezpieczeństwo, jak i efektywność uzyskuje się poprzez kierowanie do ludzi tylko tych ryzykownych, a nie każdego produktu.
Zadanie aplikacji
Weź przykład z własnego wyniku AI. Najpierw zdefiniuj schemat JSON i wymuś do niego dane wyjściowe. Następnie napisz co najmniej dwie reguły biznesowe (na przykład „kwota odpowiada sumie pozycji”). Na koniec utwórz tabelę routingu: która kombinacja zaufania/wpływu przechodzi automatycznie, która trafia do drugiego modelu, a która do człowieka? Wygeneruj wadliwą próbkę i obserwuj, gdzie każda warstwa ją wychwytuje.
lista kontrolna
- [ ] Definiuję ścisły schemat wyjścia i weryfikuję go na maszynie.
- [ ] Dodałem co najmniej jedną walidację biznesową/reguł (logika wartości).
- [ ] Potrafię powiązać twierdzenia ze źródłem i je sprawdzić.
- [ ] Dostępny jest drugi model lub walidacja na ludziach w przypadku wyników o dużym wpływie/niskim bezpieczeństwie.
- [ ] Reguła routingu zdefiniowana w oparciu o zaufanie i wpływy.
- [ ] Recenzent otrzymuje kontekst, źródło i uprawnienia do odrzucenia.