Zbudowałeś wewnętrzne narzędzie, które pozwala zespołowi przeprowadzić 28 testów jednostkowych funkcji opartej na LLM, nie wywołując przy tym API modelu. Zrobiłeś to, opakowując model w interfejs umożliwiający podmianę na mocka i dodając trzy warstwy ewaluacji: deterministyczną, heurystyczną oraz opartą na LLM.
Standardowe asercje zawodzą w momencie, gdy LLM generuje tekst ciągły. Ten sam prompt może dać inne zdanie przy każdym uruchomieniu, więc assertEqual(output, expected) zgłasza błąd nawet wtedy, gdy model zachował się poprawnie. Większość zespołów inżynieryjnych albo wypuszcza funkcję bez weryfikacji, albo próbuje testować sam model, traktując nieustannie zmieniający się cel tak, jakby był statyczną biblioteką.
Dlaczego ten problem jest istotny
LLM-y znajdują się obecnie wewnątrz procesów skierowanych do klienta — kampanii e-mailowych, odpowiedziach wsparcia czy generowaniu treści. Pojedynczy sfabrykowany fakt lub wyciek identyfikatora może zaszkodzić reputacji marki, ujawnić prywatne dane lub doprowadzić do naruszeń zgodności. Bez niezawodnej strategii testowania zespoły tracą czas na ściganie niestabilnych błędów lub wypuszczają bugi, które ujawniają się dopiero na produkcji.
Podejście: ograniczenie odpowiedzialności modelu
Pierwszym krokiem było ograniczenie tego, co faktycznie robi LLM. W systemie autora model zajmuje się jedynie tworzeniem szkiców wiadomości outreachowych. Cała logika routingu, zarządzanie stanem i sprawdzanie bezpieczeństwa pozostają w zwykłym kodzie. Poprzez ograniczenie modelu do pojedynczego, dobrze zdefiniowanego wyjścia, otaczający system pozostaje deterministyczny i możliwy do przetestowania.
Aby to umożliwić, LLM znajduje się za interfejsem dostawcy, co pozwala na użycie wersji typu fake w testach. W produkcji implementacja wywołuje zewnętrzne API; w zestawie testowym lekki mock zwraca gotową odpowiedź. Ponieważ reszta kodu wchodzi w interakcję tylko z interfejsem, cały przepływ pracy może być sprawdzany przez testy jednostkowe, które nigdy nie łączą się z siecią. Wynikiem jest przewidywalny rdzeń, który weryfikuje 28 testów.
Szczery mechanizm ewaluacji
Nawet przy zawężonym zakresie, wyjście modelu pozostaje niedeterministyczne. Autor zbudował zatem trójwarstwowy mechanizm ewaluacji, gdzie każda warstwa obsługuje inny rodzaj ryzyka.
Warstwa 1 – Sprawdzanie deterministyczne Proste reguły oparte na wyrażeniach regularnych wyłapują konkretne błędy, takie jak błędne ID budynku lub niedozwolone tokeny. Te sprawdzenia są szybkie i dają binarny wynik (sukces/porażka).
Warstwa 2 – Sprawdzanie heurystyczne Skrypty szukają sfabrykowanych liczb lub dat, flagując oczywiste kłamstwa faktyczne. Nie wyłapują one jednak fałszywych twierdzeń pozbawionych wskazówek numerycznych, co autor otwarcie przyznaje.
Warstwa 3 – Sędzia LLM Drugorzędny model ocenia ton i profesjonalizm. Ponieważ ten krok opiera się na innym systemie probabilistycznym, jest używany tylko do aspektów subiektywnych, gdzie stosowanie reguł deterministycznych byłoby niemożliwe.
Kluczem do mechanizmu jest zestaw danych użyty do ewaluacji. Autor zakodował znane wzorce błędów — konkretne pułapki i wiedzę domenową — dzięki czemu mechanizm testuje dokładnie te błędy, które pojawiły się w praktyce. Nie jest to magiczna metoda „na wszystko”, lecz celowana siatka bezpieczeństwa.
Co to oznacza dla zespołów
- Ogranicz zakres zadań LLM. Mniejsza liczba odpowiedzialności ułatwia izolację i testowanie.
- Przenieś routing, stan i bezpieczeństwo do kodu. Tradycyjna logika pozostaje deterministyczna i w pełni testowalna.
- Wystaw model poprzez interfejs umożliwiający podmianę na mocka. Testy jednostkowe działają bez zewnętrznych wywołań, dzięki czemu zestaw testów jest szybki i niezawodny.
- Stosuj warstwową ewaluację. Zacznij od reguł deterministycznych, dodaj heurystykę dla znanych halucynacji i zarezerwuj sędziów LLM dla subiektywnych kontroli jakości.
- Określ granice. Żadna warstwa nie gwarantuje perfekcji; mechanizm wyłapuje tylko to, co zostanie w nim jawnie zaprogramowane.
Kontrargument: nadal nie możesz przeprowadzić testów jednostkowych samego modelu
Autor przyznaje, że model to ruchomy cel. Nawet warstwa sędziego LLM dziedziczy ten sam niedeterminizm, który próbuje oceniać. W konsekwencji system nigdy nie zagwarantuje, że każda halucynacja lub naruszenie polityki zostanie wykryte przed wydaniem. Podejście to redukuje ryzyko, a nie eliminuje je, i opiera się na zdolności zespołu do aktualizowania danych ewaluacyjnych wraz z pojawianiem się nowych trybów błędów.
Podsumowanie
Nie można napisać klasycznego testu jednostkowego, który stwierdzi dokładne wyjście LLM, ale można zbudować system, w którym wpływ modelu jest ograniczony, jego interfejs jest wymienny, a jego wyjście jest filtrowane przez warstwowe, przejrzyste kontrole. Ta kombinacja zmienia komponent, który inaczej byłby niestabilny, w przewidywalną część większej, testowalnej aplikacji.