Arize Phoenix, śledzenie i ocena aplikacji LLM

Arize Phoenix, śledzenie i ocena aplikacji LLM

Arize Phoenix zapisuje przebieg każdego wywołania w aplikacji opartej o model językowy: prompt, odpowiedź, wywołane narzędzia, pobrane fragmenty dokumentów, czas i zużyte tokeny. Do tego dokłada zestaw ewaluatorów, które oceniają jakość odpowiedzi bez udziału człowieka.

Problem, który rozwiązuje, pojawia się przy pierwszym zgłoszeniu od użytkownika. Ktoś pisze, że system podał złą informację, a Ty masz przed sobą jedno zdanie i żadnego sposobu, żeby odtworzyć, co się wydarzyło. Przy trzech krokach z narzędziami i wyszukiwaniem w dokumentach zgadywanie przestaje działać.

Licencja, czyli rzecz do sprawdzenia najpierw

Narzędzie bywa opisywane jako otwarte i to jest uproszczenie, które warto rozwinąć, zanim wpiszesz je do produktu.

Kod jest publiczny i da się go uruchomić u siebie bez opłat, natomiast licencja to Elastic License 2.0, a nie licencja zatwierdzona jako otwarta w rozumieniu przyjętych definicji. Praktyczna różnica sprowadza się do jednego zakazu: nie wolno udostępniać tego oprogramowania innym jako usługi zarządzanej.

Dla większości zespołów nie ma to żadnego znaczenia. Uruchamiasz to na własnym serwerze, obserwujesz własną aplikację, koniec sprawy. Znaczenie pojawia się wtedy, gdy budujesz platformę, w której Twoi klienci mieliby dostać panel obserwowalności jako element Twojej oferty. To jest dokładnie ten przypadek, który licencja wyklucza.

Warto to rozstrzygnąć na początku, bo wymiana warstwy obserwowalności po roku pracy jest kosztowna, a rozmowa z działem prawnym po podpisaniu umowy z klientem bywa jeszcze droższa.

Instalacja i pierwsze uruchomienie

pip install arize-phoenix
phoenix serve

Można też uruchomić bez instalowania czegokolwiek na stałe:

uvx arize-phoenix serve

Wydania wychodzą po kilka w tygodniu, więc numer wersji przesuwa się szybciej, niż zdąży zestarzeć się każdy tekst: w połowie sierpnia 2026 była to 19.21. Wymagany jest Python w wersji od 3.10 do 3.14. Interfejs podnosi się lokalnie i od razu przyjmuje dane, więc pierwsze ślady zobaczysz w kilka minut od instalacji.

Do wdrożenia trwałego są obrazy kontenerów i wykresy do uruchomienia w klastrze, a także gotowe przyciski wdrożeniowe dla kilku dostawców chmurowych. Wybór zależy od tego, czy dane mają zostać u Ciebie: uruchomienie lokalne albo we własnej infrastrukturze załatwia ten wymóg bez negocjacji.

Instrumentacja przez OpenTelemetry

Tu jest największa zaleta tego narzędzia i warto ją rozumieć, bo dotyczy decyzji na lata.

Zbieranie danych opiera się na OpenTelemetry, czyli standardzie używanym poza światem modeli językowych, z rozszerzeniem opisującym pojęcia typowe dla tej dziedziny: prompt, odpowiedź, wywołanie narzędzia, pobrany dokument.

Konsekwencja jest praktyczna. Instrumentujesz aplikację raz, a potem możesz zmienić narzędzie odbierające ślady bez dotykania kodu, bo mówią tym samym językiem. To odróżnia takie podejście od bibliotek z własnym, zamkniętym formatem, gdzie zmiana dostawcy oznacza przejście przez wszystkie miejsca w kodzie.

from phoenix.otel import register
from openinference.instrumentation.langchain import LangChainInstrumentor

register(project_name="asystent")
LangChainInstrumentor().instrument()

Gotowe instrumentacje obejmują popularne biblioteki, między innymi LangChain, LlamaIndex i Haystack, a także bezpośrednie wywołania modeli u głównych dostawców. Przy własnym kodzie dopisujesz zakresy ręcznie, co przy dobrze podzielonych funkcjach zajmuje kilkanaście linii.

Z tej trójki ostatnia daje ślad najbardziej czytelny, bo aplikacja jest tam grafem komponentów o jawnie zadeklarowanych wejściach i wyjściach, więc drzewo zakresów odpowiada rysunkowi potoku, a nie przypadkowemu zagnieżdżeniu funkcji. Przy własnym kodzie ten sam efekt trzeba wypracować samodzielnie, nazywając zakresy tak, żeby dało się je czytać za pół roku.

Warto od razu ustalić, co trafia do śladów. Domyślnie zapisywana jest pełna treść promptów i odpowiedzi, więc jeśli przechodzą przez nie dane osobowe, ślady stają się kolejnym miejscem, które trzeba objąć retencją i kontrolą dostępu.

Ewaluatory, czyli ocena bez człowieka

Śledzenie mówi, co się wydarzyło. Ocena mówi, czy było dobrze, i to jest druga połowa tego narzędzia.

Wbudowane ewaluatory obejmują sprawdzanie oparcia odpowiedzi w podanych źródłach, trafność pobranych fragmentów, wykrywanie treści zmyślonych, ocenę toksyczności oraz kryteria pisane samodzielnie. Każdy z nich to w praktyce prompt do modelu oceniającego, z określonym formatem odpowiedzi.

Trzy pierwsze pokrywają się z tym, co TruLens nazywa triadą RAG: trafność pobranych fragmentów, oparcie odpowiedzi w nich i trafność samej odpowiedzi. Po tamtą bibliotekę sięga się wtedy, gdy liczą się przede wszystkim miary dla wyszukiwania w dokumentach oraz licencja MIT bez zakazu odsprzedaży jako usługi, a ceną jest znacznie skromniejszy panel niż tutaj.

To rodzi pytanie, które pada zawsze i słusznie: skoro ocenia model, to kto ocenia oceniającego. Odpowiedź brzmi: Ty, na zbiorze przykładów ocenionych ręcznie. Sto przypadków z ręcznymi etykietami wystarczy, żeby sprawdzić, jak często ewaluator zgadza się z człowiekiem, i to jest jedyny sposób, żeby wiedzieć, ile warte są jego wyniki.

Prompty ewaluatorów są jawne i można je zmieniać, co odróżnia to podejście od zamkniętych ocen zwracających liczbę bez uzasadnienia. Przy dziedzinie odbiegającej od ogólnej, na przykład prawnej albo medycznej, ta możliwość jest rozstrzygająca, bo ewaluator ogólny będzie się mylił w sposób systematyczny.

Ocenę uruchamiasz na zbiorze zapisanych śladów, więc typowy przebieg wygląda tak: zbierasz ruch produkcyjny przez tydzień, wybierasz kilkaset przypadków, puszczasz ewaluatory, oglądasz najgorsze wyniki. Ten ostatni krok jest najważniejszy i najczęściej pomijany, bo to w nim widać, co naprawdę psuje się w aplikacji.

Eksperymenty i wersjonowanie promptów

Trzecia warstwa dotyczy zmian, które wprowadzasz świadomie.

Zbiory danych to zestawy wejść z oczekiwanym wynikiem, zapisane i wersjonowane. Eksperyment to uruchomienie aplikacji na takim zbiorze i porównanie wyników z poprzednim przebiegiem.

Wartość tego mechanizmu widać przy zmianie promptu systemowego. Bez zbioru testowego zmiana promptu jest ruchem w ciemno: poprawiasz jeden przypadek, psujesz trzy inne i dowiadujesz się o tym ze zgłoszeń. Ze zbiorem widzisz obie liczby przed wdrożeniem.

Prompty da się przechowywać w samym narzędziu, z historią wersji, co bywa wygodne, natomiast warto się zastanowić, czy tego chcesz. Prompt jest częścią zachowania aplikacji, więc trzymanie go w repozytorium razem z kodem daje przegląd zmian, powiązanie z wdrożeniem i możliwość cofnięcia jednym ruchem. Osobne miejsce z własną historią bywa wygodniejsze dla osób nietechnicznych i gorsze dla spójności wdrożeń.

Co właściwie widać w śladzie

Warto wiedzieć, czego szukać, bo pierwsze spojrzenie na drzewo wywołań bywa przytłaczające, a większość odpowiedzi siedzi w trzech miejscach.

Pierwsze to podział czasu. Ślad pokazuje, ile trwał każdy krok osobno, i to zwykle obala założenie zespołu o tym, co jest wolne. W aplikacjach wyszukujących w dokumentach model bywa najszybszym elementem, a czas idzie na zapytanie do bazy wektorowej, przeliczenie osadzeń zapytania i sekwencyjne wywołania narzędzi, które dałoby się wykonać równolegle.

Drugie to pobrane fragmenty. Przy odpowiedzi niezgodnej z prawdą pierwsze pytanie brzmi, czy właściwy fragment w ogóle trafił do kontekstu. Jeśli nie, problem leży w wyszukiwaniu i żadna zmiana promptu go nie naprawi. Jeśli tak, a model i tak odpowiedział inaczej, problem leży w prompcie albo w modelu. To rozróżnienie zmienia kierunek pracy o sto osiemdziesiąt stopni, a bez śladu nie da się go zrobić.

Trzecie to argumenty wywołań narzędzi. Agent, który wywołał właściwą funkcję z niewłaściwymi argumentami, zwraca odpowiedź wyglądającą sensownie i całkowicie błędną. Widać to wyłącznie w zapisie wywołania, bo w samej odpowiedzi nie ma śladu po tym, co poszło do narzędzia.

Czwarte, rzadziej używane, to zużycie tokenów w podziale na kroki. Przy agencie wykonującym kilka tur suma bywa wielokrotnie wyższa od tego, co sugeruje długość rozmowy, bo każda tura niesie cały dotychczasowy kontekst. To jest miejsce, w którym najłatwiej znaleźć oszczędność.

Od śladów do poprawek

Zbieranie danych jest łatwe, a wyciąganie z nich wniosków wymaga rutyny, której nikt nie narzuci za Ciebie.

Sensowny cykl wygląda tak. Raz w tygodniu bierzesz dwadzieścia rozmów o najniższej ocenie, czytasz je i przypisujesz przyczynę: złe wyszukiwanie, zły prompt, brakujące narzędzie, błąd w danych. Po czterech tygodniach masz rozkład przyczyn i wiesz, gdzie pracować, zamiast poprawiać to, co akurat rzuciło się w oczy.

Druga rutyna dotyczy zmian. Każda modyfikacja promptu systemowego albo parametrów wyszukiwania powinna przechodzić przez ten sam zbiór testowy, a wynik przed i po zapisany. Bez tego zespół po pół roku nie wie, czy jest lepiej niż na starcie, bo każdy pamięta wyłącznie ostatnią zmianę.

Trzecia dotyczy przypadków brzegowych. Rozmowa, która zakończyła się źle i została naprawiona, powinna trafić do zbioru testowego jako przypadek. To najtańszy sposób budowania zestawu odzwierciedlającego rzeczywistość, bo przykłady pochodzą od użytkowników, a nie z wyobraźni zespołu.

Warto też zapisywać ocenę wystawianą przez użytkownika, jeśli interfejs ją zbiera. Kciuk w dół powiązany ze śladem daje etykietę, której żaden ewaluator nie zastąpi, i po kilkuset takich przypadkach masz materiał do sprawdzenia, jak dobrze automatyczne oceny odpowiadają odczuciom ludzi.

Phoenix kontra alternatywy

Ostatni wiersz warto rozważyć uczciwie, bo bywa pomijany. Jeśli zespół ma działający system zbierania śladów i tablic, dołożenie do niego kilku atrybutów opisujących wywołania modelu jest tańsze niż wprowadzenie kolejnego narzędzia z osobnym interfejsem i osobnym utrzymaniem. Traci się gotowe ewaluatory, zyskuje jedno miejsce zamiast dwóch.

Różnica między pierwszymi trzema wierszami sprowadza się głównie do tego, gdzie leżą dane i jaka licencja Cię wiąże. Możliwości śledzenia są w nich zbliżone, a przewaga jednego nad drugim w konkretnym zestawieniu funkcji zmienia się z kwartału na kwartał.

Wdrożenie w praktyce

Kilka rzeczy oszczędza czas, jeśli narzędzie ma zostać na dłużej niż na tydzień eksploracji.

Zacznij lokalnie. Uruchomienie na własnej maszynie i podpięcie do środowiska deweloperskiego zajmuje kwadrans i od razu pokazuje, czy ślady zawierają to, czego potrzebujesz. Dopiero potem ma sens rozmowa o wdrożeniu trwałym.

Ustal retencję wcześnie. Ślady z pełną treścią promptów rosną szybciej, niż się zakłada, zwłaszcza przy aplikacjach wyszukujących w dokumentach, gdzie każde zapytanie ciągnie za sobą kilka fragmentów tekstu. Bez polityki usuwania baza rośnie liniowo do końca świata.

Rozdziel projekty według środowiska. Ślady z pracy deweloperskiej wymieszane z produkcyjnymi psują każdą statystykę, bo eksperymenty wyglądają jak błędy użytkowników.

Ostatnia rzecz to zwyczaj. Narzędzie obserwowalności, do którego nikt nie zagląda, jest kosztem bez zwrotu. Jeden przegląd tygodniowo, na którym ktoś ogląda dziesięć najgorzej ocenionych rozmów, daje więcej niż najbogatszy zestaw wykresów.

Typowe błędy

Pierwszy to traktowanie licencji jak otwartej. Elastic License 2.0 zabrania udostępniania tego oprogramowania innym jako usługi zarządzanej, więc plan wbudowania panelu w ofertę dla klientów wymaga sprawdzenia przed rozpoczęciem pracy.

Drugi to ufanie ewaluatorom bez sprawdzenia. Ocena wystawiana przez model może się mylić systematycznie, a bez zbioru z ręcznymi etykietami nie wiesz, jak często.

Trzeci to zapisywanie pełnych treści bez polityki retencji. Ślady stają się wtedy kopią danych produkcyjnych, z tymi samymi wymogami i bez tej samej ochrony.

Czwarty to instrumentowanie wyłącznie wywołania modelu. Największe opóźnienia i najczęstsze błędy siedzą zwykle w wyszukiwaniu dokumentów i w wywołaniach narzędzi, a nie w samym modelu.

Piąty to mieszanie środowisk w jednym projekcie. Statystyki przestają cokolwiek znaczyć, gdy połowa śladów pochodzi z testów.

Szósty to zbieranie danych bez cyklicznego przeglądu. Bez kogoś, kto regularnie ogląda najgorsze przypadki, całe wdrożenie zostaje archiwum.

FAQ

Czy Arize Phoenix jest darmowy?

Do uruchomienia u siebie tak, bez opłat i bez ograniczeń funkcji. Licencja to jednak Elastic License 2.0, a nie licencja otwarta w przyjętym rozumieniu, i zabrania udostępniania tego oprogramowania innym jako usługi zarządzanej.

Czy dane opuszczają moją infrastrukturę?

Przy uruchomieniu lokalnym albo we własnym kontenerze nie, i to jest główny powód wyboru tego narzędzia. Istnieje też wariant hostowany przez dostawcę, gdzie ślady trafiają na jego serwery.

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

Głównie licencją i miejscem przechowywania danych. Langfuse daje wybór między uruchomieniem u siebie a chmurą dostawcy, LangSmith jest usługą zamkniętą związaną z ekosystemem LangChaina, a Phoenix stawia na uruchomienie własne z instrumentacją opartą o OpenTelemetry.

Czy muszę używać LangChaina, żeby to działało?

Nie. Gotowe instrumentacje obejmują popularne biblioteki, ale zbieranie danych opiera się na OpenTelemetry, więc własny kod wywołujący model bezpośrednio też da się opisać, dopisując zakresy ręcznie.

Czy ewaluatorom można ufać?

Tylko po sprawdzeniu na własnych danych. Ewaluator to prompt do modelu oceniającego, więc jego wyniki trzeba porównać z ręcznymi etykietami na kilkuset przypadkach, zanim ktokolwiek podejmie decyzję na podstawie wykresu.

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