TruLens, triada RAG i ocena odpowiedzi

TruLens, triada RAG i ocena odpowiedzi

TruLens to biblioteka Pythona do śledzenia i oceniania aplikacji opartych o modele językowe, ze szczególnym naciskiem na systemy odpowiadające na pytania z dokumentów. Jej najbardziej znanym wkładem jest triada RAG: trzy miary, które razem pokrywają praktycznie wszystkie sposoby, na jakie taka aplikacja potrafi zawieść.

Wersja z końca lipca 2026 nosi numer 2.10, licencja to MIT, a wymagany Python zaczyna się od 3.10. To rozróżnienie warto odnotować, bo część konkurencyjnych narzędzi z tej kategorii działa na licencjach ograniczających komercyjne udostępnianie, a tutaj takiego problemu nie ma.

Kto za tym stoi

Biblioteka powstała w firmie Truera, którą Snowflake przejął w maju 2024 roku. Rozwój trwa dalej, a integracja z ekosystemem tego dostawcy jest widoczna w dokumentacji i przykładach.

Dla użytkownika ma to jedną praktyczną konsekwencję: sporo materiałów pokazuje TruLens razem z usługami Snowflake, co bywa mylące. Sama biblioteka jest niezależna, instaluje się przez zwykły menedżer pakietów, działa lokalnie i nie wymaga konta u kogokolwiek. Modelem oceniającym może być dowolny dostawca albo model uruchomiony u Ciebie.

Triada RAG, czyli sedno tego narzędzia

To jest pomysł, dla którego warto poznać tę bibliotekę, nawet jeśli ostatecznie użyjesz innej.

Aplikacja odpowiadająca na pytania z dokumentów ma trzy połączenia: pytanie do pobranych fragmentów, pobrane fragmenty do odpowiedzi oraz pytanie do odpowiedzi. Każde z nich może się zerwać osobno i każde zrywa się inaczej.

Trafność kontekstu mierzy pierwsze połączenie: czy pobrane fragmenty w ogóle dotyczą pytania. Niska ocena znaczy, że problem leży w wyszukiwaniu, i żadna zmiana promptu tego nie naprawi.

Oparcie w źródłach mierzy drugie: czy każde twierdzenie w odpowiedzi da się wywieść z pobranych fragmentów. Niska ocena przy dobrym kontekście znaczy, że model dopowiada rzeczy, których nie było w dokumentach.

Trafność odpowiedzi mierzy trzecie: czy odpowiedź w ogóle odnosi się do zadanego pytania. Niska ocena przy dobrych dwóch poprzednich znaczy, że model odpowiedział na coś innego, zwykle na fragment pytania albo na temat pokrewny.

Siła tego układu polega na tym, że kombinacja trzech ocen wskazuje przyczynę, a nie tylko objaw. Zgłoszenie „system podał złą informację" bez tych miar prowadzi do zgadywania. Z nimi wiadomo, czy szukać w indeksie, w prompcie, czy w modelu.

Instalacja i pierwsze uruchomienie

pip install trulens trulens-providers-openai

from trulens.core import TruSession, Feedback
from trulens.providers.openai import OpenAI
import numpy as np

sesja = TruSession()
dostawca = OpenAI(model_engine="gpt-4o-mini")

trafnosc_kontekstu = (
    Feedback(dostawca.context_relevance_with_cot_reasons, name="trafnosc kontekstu")
    .on_input()
    .on(kontekst)
    .aggregate(np.mean)
)

oparcie = (
    Feedback(dostawca.groundedness_measure_with_cot_reasons, name="oparcie")
    .on(kontekst.collect())
    .on_output()
)

Sposób opisu jest tu inny niż w większości narzędzi i wymaga chwili przyzwyczajenia. Zamiast pisać funkcję oceniającą, składasz ją: wybierasz gotową miarę, wskazujesz, na czym ma działać, i określasz, jak zagregować wyniki, gdy fragmentów jest kilka.

Ta ostatnia rzecz bywa myląca. Trafność kontekstu liczona jest osobno dla każdego pobranego fragmentu, więc przy pięciu fragmentach dostajesz pięć ocen. Średnia mówi, czy wyszukiwanie działa ogólnie, a wartość najwyższa mówi, czy przynajmniej jeden trafny fragment się znalazł. To dwa różne pytania i warto wiedzieć, na które odpowiadasz.

Wersje z uzasadnieniem i po co one są

Miary występują w dwóch odmianach: zwracającej samą liczbę i zwracającej liczbę razem z wyjaśnieniem.

Wersja z uzasadnieniem kosztuje więcej tokenów i działa wolniej, a mimo to zwykle warto jej używać przy pracy rozwojowej. Powód jest prosty: ocena 0,4 bez wyjaśnienia nie mówi nic. Ocena 0,4 z uzasadnieniem, że dwa z pięciu fragmentów dotyczyły innego produktu, wskazuje wprost, co poprawić.

Bez uzasadnień trafiasz w typową pułapkę pracy z ewaluatorami: masz wykres, który spadł, i nie wiesz, czy pogorszyła się aplikacja, czy zmieniło się coś w sposobie oceniania. Uzasadnienie pozwala to rozstrzygnąć w minutę.

Przy uruchamianiu na dużej próbce warto to odwrócić: wersja bez uzasadnień na całym zbiorze do wyznaczenia trendu, wersja z uzasadnieniami na kilkudziesięciu najgorszych przypadkach do zrozumienia przyczyny.

Model oceniający i jego wiarygodność

Wszystkie te miary działają na tej samej zasadzie: prompt do modelu, który wystawia ocenę. Trzeba więc zadać pytanie, które przy każdym takim narzędziu jest właściwe.

Odpowiedź brzmi: sprawdź na własnych danych. Weź sto przypadków, oceń je ręcznie, porównaj z wynikiem miary i policz zgodność. Bez tej liczby wykres jakości pokazuje coś, czego nie znasz, a decyzje podejmowane na jego podstawie są losowe.

Dobór modelu oceniającego ma tu znaczenie większe, niż się zakłada. Model tańszy i szybszy wystarcza do oceniania oparcia w źródłach, bo to zadanie sprowadza się do porównania twierdzeń z tekstem. Ocena trafności odpowiedzi bywa trudniejsza i tam słabszy model myli się częściej, zwłaszcza przy pytaniach wieloczęściowych.

Trzecia rzecz to język. Miary są opisane promptami po angielsku i przy tekstach w innych językach potrafią działać gorzej, zwłaszcza przy ocenie oparcia, gdzie liczy się dokładne dopasowanie twierdzenia do zdania źródłowego. Prompty da się zmienić, i przy pracy na polskich dokumentach zwykle warto.

Poza triadą, czyli reszta zestawu miar

Trzy główne miary pokrywają najczęstsze awarie, natomiast biblioteka niesie ich znacznie więcej i część z nich rozwiązuje problemy, o których zespoły przypominają sobie za późno.

Wykrywanie treści szkodliwych i ocena wydźwięku przydają się tam, gdzie odpowiedzi trafiają wprost do klienta. To nie jest zabezpieczenie w sensie filtra działającego w czasie rzeczywistym, tylko miara pozwalająca stwierdzić, jak często coś takiego w ogóle powstaje.

Zgodność z podanym stylem albo zakresem tematycznym bywa najbardziej niedocenianą miarą przy asystentach firmowych. Odpowiedź poprawna merytorycznie i napisana niewłaściwym tonem jest problemem realnym, a triada jej nie wychwyci, bo pod względem faktów wszystko się zgadza.

Osobno warto policzyć miary niezwiązane z modelem. Czas odpowiedzi, liczba pobranych fragmentów, długość odpowiedzi i koszt w tokenach nie wymagają żadnego oceniającego, a często wyjaśniają więcej niż oceny jakości. Aplikacja, której odpowiedzi wydłużyły się dwukrotnie po zmianie promptu, zwykle pogorszyła się w odbiorze, nawet jeśli miary jakości tego nie pokazały.

Możliwość dopisania własnej miary jest tu prosta, bo funkcja zwrotna to zwykła funkcja Pythona zwracająca liczbę. Przy dziedzinie z twardymi regułami, na przykład wymogiem podania numeru podstawy prawnej, sprawdzenie wyrażeniem regularnym jest tańsze i pewniejsze niż jakikolwiek model oceniający.

Koszt oceniania i jak go ograniczyć

Ewaluacja bywa droższa od samej aplikacji i to zaskakuje zespoły, które policzyły tylko koszt odpowiadania użytkownikom.

Rachunek wynika z arytmetyki. Trzy miary triady to trzy dodatkowe wywołania modelu na jedną odpowiedź, a trafność kontekstu liczona per fragment przy pięciu fragmentach daje siedem wywołań zamiast trzech. Wersje z uzasadnieniem zużywają dodatkowo tokeny wyjściowe, których jest sporo, bo model pisze wyjaśnienie.

Trzy rzeczy obniżają ten koszt bez utraty wartości. Pierwsza to próbkowanie: ocenianie co dwudziestej rozmowy produkcyjnej daje ten sam trend co ocenianie wszystkich, przy dwudziestokrotnie niższym rachunku. Pełny zbiór testowy uruchamiaj przy zmianach, ruch produkcyjny próbkuj.

Druga to dobór modelu oceniającego do miary. Oparcie w źródłach da się mierzyć modelem tańszym, bo zadanie jest porównawcze. Trafność odpowiedzi przy pytaniach złożonych zasługuje na mocniejszy.

Trzecia to rezygnacja z uzasadnień poza pracą diagnostyczną. Trend policzysz na samych liczbach, a wyjaśnienia potrzebujesz tylko wtedy, gdy schodzisz do przypadków.

Przy dużym wolumenie sensowna bywa czwarta droga, zmieniająca jednostkę rachunku: model oceniający uruchomiony u siebie. Serwer w rodzaju vLLM wystawia interfejs zgodny z API OpenAI, więc dostawcę ocen wskazujesz na własny adres, a rachunek przestaje zależeć od liczby ocenionych rozmów i zaczyna zależeć od godzin pracy karty graficznej. Próg opłacalności leży tam, gdzie ocenianie chodzi stale, a nie raz na wydanie. Zastrzeżenie jest to samo co wyżej: zgodność mniejszego modelu z oceną ręczną trzeba policzyć osobno, bo wynik jednego oceniającego nie przenosi się na drugiego.

Warto też pamiętać o buforowaniu. Ten sam zbiór testowy uruchamiany kilka razy dziennie przy niezmienionej aplikacji nie musi być liczony od nowa, jeśli wejście i wyjście się nie zmieniły.

TruLens kontra alternatywy

Różnica między pierwszym a resztą jest kwestią proporcji. TruLens kładzie nacisk na miary i ich poprawność, a warstwa oglądania wyników jest skromniejsza. Pozostałe narzędzia mają bogatsze panele i słabiej dopracowany zestaw gotowych miar dla wyszukiwania w dokumentach.

Warto zauważyć, że to nie są wybory wykluczające. TruLens da się uruchomić jako bibliotekę liczącą oceny w potoku testowym, a wyniki wysyłać tam, gdzie zespół i tak patrzy. Przy licencji MIT nic temu nie stoi na przeszkodzie.

Jak to wpiąć w proces

Największą wartość to narzędzie daje uruchamiane automatycznie, a nie ręcznie przy okazji.

Zacznij od zbioru testowego. Trzydzieści pytań z oczekiwanymi odpowiedziami wystarcza na start i jest lepsze niż trzysta zebranych po roku, bo istnieje teraz. Najlepszym źródłem są pytania, które użytkownicy faktycznie zadali, a system odpowiedział źle.

Potem wpinasz obliczanie triady do potoku uruchamianego przy każdej zmianie promptu, parametrów wyszukiwania albo modelu. Wynik przed i po zmianie widoczny w przeglądzie kodu zmienia sposób pracy bardziej niż jakikolwiek panel.

Progi ustal osobno dla każdej miary. Oparcie w źródłach powinno być wysokie i tu warto być surowym, bo to jest miara wykrywająca zmyślenia. Trafność kontekstu bywa niższa i to normalne, bo wyszukiwanie zwraca też fragmenty częściowo pasujące.

Ostatnia rzecz to obserwowanie ruchu produkcyjnego. Miary policzone na próbce prawdziwych rozmów raz w tygodniu pokazują, czy zbiór testowy nadal odzwierciedla to, o co pytają ludzie. Zwykle nie odzwierciedla, i to jest właśnie sygnał do jego rozszerzenia.

Typowe błędy

Pierwszy to liczenie jednej miary zamiast trzech. Sama ocena odpowiedzi nie mówi, czy problem leży w wyszukiwaniu, czy w modelu, więc poprawianie odbywa się po omacku.

Drugi to ufanie ocenom bez sprawdzenia zgodności z ludźmi. Miara oparta o model może mylić się systematycznie, a bez porównania na ręcznie ocenionych przypadkach nie wiesz, jak często.

Trzeci to używanie tego samego modelu do generowania i oceniania. Model łagodniej ocenia własne wytwory, więc wyniki wychodzą wyższe, niż powinny.

Czwarty to zła agregacja przy trafności kontekstu. Średnia z pięciu fragmentów odpowiada na inne pytanie niż wartość najwyższa i mieszanie tego prowadzi do błędnych wniosków.

Piąty to zostawienie promptów oceniających w wersji angielskiej przy pracy na dokumentach w innym języku. Ocena oparcia wymaga dokładnego dopasowania twierdzeń i tam różnica jest największa.

Szósty to uruchamianie ewaluacji raz na kwartał. Miara, która nie jest liczona przy każdej zmianie, nie chroni przed regresem, tylko go dokumentuje po fakcie.

Siódmy to ocenianie każdej rozmowy produkcyjnej zamiast próbki. Trend widać na co dwudziestej, a rachunek za ocenianie potrafi przewyższyć koszt samego odpowiadania użytkownikom.

FAQ

Czym jest triada RAG?

Trzema miarami pokrywającymi trzy połączenia w aplikacji odpowiadającej z dokumentów: trafność pobranych fragmentów wobec pytania, oparcie odpowiedzi w tych fragmentach oraz trafność odpowiedzi wobec pytania. Kombinacja ich ocen wskazuje, czy poprawiać wyszukiwanie, prompt czy model.

Czy TruLens jest darmowy?

Tak, biblioteka jest na licencji MIT, więc bez opłat i bez ograniczeń komercyjnych. Kosztem są wywołania modelu oceniającego, bo każda miara to prompt, który trzeba opłacić u dostawcy albo policzyć na własnym sprzęcie.

Czy potrzebuję konta w Snowflake?

Nie. Biblioteka powstała w firmie przejętej przez tego dostawcę i integruje się z jego usługami, natomiast instaluje się przez zwykły menedżer pakietów, działa lokalnie i przyjmuje dowolnego dostawcę modelu oceniającego.

Czym różni się od Phoenix i Langfuse?

Naciskiem i licencją. TruLens skupia się na miarach jakości, zwłaszcza dla wyszukiwania w dokumentach, i jest na licencji MIT. Arize Phoenix daje mocniejsze śledzenie przy licencji Elastic, a Langfuse stawia na wybór między hostingiem własnym a chmurą.

Czy mogę oceniać aplikacje spoza LangChaina?

Tak. Gotowe integracje obejmują popularne biblioteki, w tym LangChain, ale miary da się policzyć na dowolnym wejściu i wyjściu, więc własny kod wywołujący model też się nadaje.

Dokumentacja stoi na stronie projektu, a kod i wydania w repozytorium na GitHubie.