Weave od W&B, śledzenie i ocena aplikacji AI

Weave od W&B, śledzenie i ocena aplikacji AI

Weave to warstwa obserwowalności dla aplikacji opartych o modele językowe, zbudowana przez Weights & Biases. Zapisuje przebieg każdego wywołania, pozwala uruchamiać ewaluacje na zbiorach testowych i porównywać wyniki między wersjami.

Praktyczna wartość widać przy pytaniu, na które trudno odpowiedzieć bez narzędzi: czy zmiana promptu, którą wprowadziłeś w poniedziałek, poprawiła aplikację, czy tylko przesunęła problem. Bez zapisanego zbioru testowego i wyników przed oraz po jest to kwestia opinii.

Dwie rzeczy pod jedną nazwą

Zanim zaczniesz szukać dokumentacji, rozdziel dwa produkty tej samej firmy, bo mieszanie ich jest najczęstszym źródłem zamieszania.

Starszy produkt służy do śledzenia trenowania modeli: przebiegi uczenia, krzywe strat, porównania hiperparametrów, wersjonowanie zbiorów danych i wag. To jest narzędzie dla osób trenujących modele.

Weave jest nowszy i dotyczy czegoś innego: aplikacji, które modele wywołują. Śledzi wywołania, prompty, odpowiedzi, wywołania narzędzi i koszty, a do tego dokłada ewaluacje. To jest narzędzie dla osób budujących produkty na gotowych modelach.

Rozróżnienie ma znaczenie praktyczne, bo pakiety, dokumentacja i pojęcia są osobne. Poradnik opisujący przebiegi trenowania nie pomoże przy śledzeniu agenta, choć obie rzeczy nazywają się podobnie i mieszkają w tym samym panelu.

Zmiana właściciela

Weights & Biases nie jest już firmą niezależną. CoreWeave, dostawca infrastruktury obliczeniowej dla sztucznej inteligencji, ogłosił przejęcie w marcu 2025 roku i sfinalizował je 5 maja tego samego roku.

Dla użytkownika zmienia się głównie kontekst, w jakim rozwija się produkt. Narzędzie do obserwowalności stało się elementem oferty dostawcy mocy obliczeniowej, obok kredytów na środowiska uruchomieniowe i wnioskowanie rozliczane za tokeny.

To ma dwie strony. Zespół korzystający już z tej infrastruktury dostaje spójne rozliczenie i integracje. Zespół, który chce wyłącznie obserwowalności i nie zamierza kupować mocy obliczeniowej, wiąże się z dostawcą, którego głównym biznesem jest coś innego.

Warto o tym pamiętać przy planowaniu na lata. Kierunek rozwoju narzędzia będzie odtąd wynikał z tego, co pomaga sprzedawać moc obliczeniową, a niekoniecznie z tego, czego potrzebuje ktoś budujący aplikację na cudzych modelach.

Instrumentacja przez dekorator

Sposób podpięcia jest najprostszy z całej tej kategorii narzędzi i to jest realna zaleta.

import weave

weave.init("asystent-obslugi")

@weave.op()
def pobierz_dokumenty(pytanie: str) -> list[str]:
    return baza.szukaj(pytanie, k=5)

@weave.op()
def odpowiedz(pytanie: str) -> str:
    fragmenty = pobierz_dokumenty(pytanie)
    return model.wywolaj(pytanie, fragmenty)

Dekorator na funkcji wystarczy, żeby jej wejście, wyjście, czas i błędy trafiły do panelu. Wywołania zagnieżdżone układają się w drzewo, więc widzisz, że odpowiedź wynikła z tych, a nie innych fragmentów.

Wywołania do popularnych dostawców modeli są przechwytywane automatycznie po wywołaniu inicjalizacji, więc zużycie tokenów i koszt pojawiają się bez dopisywania czegokolwiek.

Prostota ma cenę, którą warto znać. Format zapisu jest własny, więc zmiana narzędzia oznacza przejście przez wszystkie miejsca z dekoratorami. Przy krótkim projekcie to bez znaczenia, przy systemie utrzymywanym latami warto to policzyć.

Jest jednak druga droga, którą starsze opisy pomijają: Weave przyjmuje też ślady w formacie OpenTelemetry. Na wielodostępnej chmurze wysyłasz je metodą POST pod https://trace.wandb.ai/otel/v1/traces, uwierzytelniając się nagłówkiem wandb-api-key, a projekt i zespół wskazujesz atrybutami zasobu wandb.entity i wandb.project. Instrumentacja może pochodzić z OpenInference albo OpenLLMetry, ślady mogą też iść przez kolektor OpenTelemetry. Jeśli przenośność jest dla Ciebie ważna, instrumentuj standardem i traktuj dekorator jako wygodny skrót, a nie jedyne wejście.

Ewaluacje i ewaluatory

Druga połowa narzędzia dotyczy oceny, a nie samego zapisu.

import weave
from weave import Evaluation

zbior = [
    {"pytanie": "Jaki jest czas dostawy?", "oczekiwane": "3 dni robocze"},
    {"pytanie": "Czy mogę zwrócić towar?", "oczekiwane": "14 dni"},
]

@weave.op()
def ocen_trafnosc(oczekiwane: str, output: str) -> dict:
    return {"trafne": oczekiwane.lower() in output.lower()}

ewaluacja = Evaluation(dataset=zbior, scorers=[ocen_trafnosc])
await ewaluacja.evaluate(odpowiedz)

Ewaluator jest zwykłą funkcją zwracającą słownik, więc możesz w nim zrobić cokolwiek: porównanie dokładne, dopasowanie rozmyte, sprawdzenie formatu, wywołanie modelu oceniającego. Ostatni wariant jest najczęstszy przy odpowiedziach swobodnych i najmniej wiarygodny bez sprawdzenia.

Tu pojawia się pytanie, które trzeba zadać przy każdym narzędziu tej klasy: skoro ocenia model, kto ocenia oceniającego. Odpowiedź jest zawsze ta sama i zawsze pomijana. Weź sto przypadków, oceń je ręcznie, porównaj z wynikiem ewaluatora i policz zgodność. Bez tej liczby wykres jakości jest wykresem czegoś, czego nie znasz.

Wyniki ewaluacji są wersjonowane, więc porównanie dwóch przebiegów pokazuje nie tylko średnią, ale też które konkretnie przypadki się poprawiły, a które popsuły. Ta druga kolumna jest ważniejsza, bo poprawa średniej przy jednoczesnym zepsuciu ważnego przypadku brzegowego jest zmianą na gorsze.

Ta sama para, czyli zbiór przypadków i miara jakości, jest zarazem wejściem optymalizatora promptów w DSPy. Tam nie poprawiasz instrukcji ręcznie, tylko opisujesz, co wchodzi i co wychodzi, a biblioteka dobiera treść promptu pod zadaną miarę. Jeśli pójdziesz w tę stronę, ewaluacja przestaje być raportem czytanym po fakcie i staje się funkcją celu, a wtedy zgodność ewaluatora z oceną ręczną liczy się podwójnie: błąd w mierze nie zniekształca już tylko wykresu, lecz prowadzi optymalizację w złą stronę.

Rozliczanie za ilość danych

Model cenowy odróżnia to narzędzie od konkurencji i warto go zrozumieć, zanim ruszy ruch produkcyjny.

Zamiast liczyć ślady albo wywołania, rozliczenie idzie od ilości przesłanych danych. Konsekwencja jest bezpośrednia: koszt zależy od tego, jak obszerne są Twoje ślady, a nie ile ich jest.

Dla typowej aplikacji odpowiadającej na pytania z krótkim promptem różnica jest niewielka. Dla aplikacji wyszukującej w dokumentach jest zasadnicza, bo każde wywołanie ciągnie za sobą kilka fragmentów tekstu, a te fragmenty bywają dłuższe niż całe pytanie i odpowiedź razem wzięte.

Praktyczny wniosek: przy takiej aplikacji zapisuj identyfikatory i skróty pobranych fragmentów zamiast ich pełnej treści, chyba że pełna treść jest Ci potrzebna do diagnostyki. Różnica w rachunku bywa kilkukrotna, a wartość diagnostyczna spada niewiele, bo fragment i tak można odtworzyć z bazy po identyfikatorze.

Cennik dostawcy podaje to wprost i warto znać trzy liczby, zanim ruch produkcyjny ruszy.

Stawka za nadmiarowe dane wygląda niewinnie, dopóki nie przeliczysz jej na gigabajty: sto dolarów za gigabajt ponad przydział. Aplikacja zapisująca pełne fragmenty przy każdym zapytaniu przekracza półtora gigabajta szybciej, niż podpowiada intuicja, więc to jest ta pozycja, którą trzeba oszacować przed wdrożeniem, a nie po pierwszej fakturze.

Osobno policz retencję. Ślady z pełną treścią rosną liniowo, a bez polityki usuwania pozycja za przechowywanie po roku bywa większa niż pozycja za samo zbieranie.

Ewaluator jako klasa i oceny złożone

Prosta funkcja wystarcza do porównań jednoznacznych, a przy ocenach wymagających stanu albo konfiguracji sięga się po wariant obiektowy.

Różnica jest praktyczna. Ewaluator sprawdzający zgodność ze wzorcem nie potrzebuje niczego poza wejściem i wyjściem. Ewaluator wywołujący model oceniający potrzebuje klienta, promptu oceniającego, progu i zwykle mechanizmu ponawiania przy błędzie sieci. Trzymanie tego w funkcji kończy się zmiennymi globalnymi.

Przy ocenach opartych o model warto zadbać o trzy rzeczy. Prompt oceniający musi wymuszać ustaloną strukturę odpowiedzi, inaczej parsowanie wyniku staje się osobnym źródłem błędów. Model oceniający powinien być tańszy niż oceniany, bo uruchamiasz go na całym zbiorze przy każdej zmianie. Oraz ocena powinna zwracać uzasadnienie, nie tylko liczbę, bo bez niego nie da się stwierdzić, czy ewaluator pomylił się, czy aplikacja.

Osobna sprawa to ocena wieloaspektowa. Jedna liczba opisująca jakość odpowiedzi zwykle ukrywa więcej, niż pokazuje, bo odpowiedź może być trafna i zbyt długa, albo poprawna i napisana niewłaściwym tonem. Kilka osobnych ewaluatorów, każdy mierzący jedną rzecz, daje obraz, na podstawie którego da się podjąć decyzję.

Co zrobić z wynikami

Zbieranie danych jest łatwe, a przełożenie ich na zmiany wymaga rutyny, której narzędzie nie narzuci.

Sensowny rytm wygląda tak. Ewaluacja uruchamiana automatycznie przy każdej zmianie promptu systemowego albo parametrów wyszukiwania, z wynikiem widocznym przed scaleniem zmian. To jest jedyny moment, w którym pogorszenie da się zatrzymać taniej niż po wdrożeniu.

Druga rutyna dotyczy przypadków, które się popsuły. Porównanie dwóch przebiegów pokazuje je wprost, a przejrzenie ich zajmuje kwadrans i mówi więcej niż średnia. Zmiana poprawiająca dziewięćdziesiąt przypadków i psująca dziesięć bywa dobra albo zła, zależnie od tego, jakie to dziesięć.

Trzecia dotyczy ruchu produkcyjnego. Ślady z produkcji są źródłem przypadków, których nikt w zespole by nie wymyślił, więc raz w tygodniu warto przejrzeć te o najgorszej ocenie i przenieść kilka do zbioru testowego.

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 przypadkach pozwala sprawdzić, jak dobrze automatyczne oceny odpowiadają odczuciom ludzi.

Weave kontra alternatywy

Główny argument za pierwszym wierszem jest organizacyjny. Zespół, który już trenuje modele na tej platformie i ma tam przebiegi, zbiory i uprawnienia, dostaje obserwowalność aplikacji w tym samym miejscu, z tym samym rozliczeniem i tymi samymi kontami.

Argument przeciw dotyczy głównie jednej rzeczy: dane leżą u dostawcy, co przy wymogach zakazujących wysyłania treści promptów na zewnątrz jest rozstrzygające i przesuwa wybór w stronę rozwiązań uruchamianych lokalnie. Zarzut o zamknięty format instrumentacji stracił ostrość odkąd doszło wejście OpenTelemetry, bo instrumentując standardem zmieniasz odbiorcę śladów w konfiguracji, a nie w kodzie.

Jak to wdrożyć sensownie

Kilka rzeczy oszczędza czas, jeśli narzędzie ma zostać w projekcie na dłużej.

Zacznij od jednej funkcji. Dekorator na trasie obsługującej zapytanie pokazuje w kilka minut, czy zapisywane dane są tym, czego potrzebujesz. Instrumentowanie całej aplikacji przed sprawdzeniem tego jest pracą wykonaną w ciemno.

Ustal, co trafia do zapisu. Prompty i odpowiedzi zawierają zwykle dane użytkowników, więc ślady stają się kolejnym zbiorem podlegającym tym samym regułom co dane produkcyjne. Maskowanie danych wrażliwych przed wysłaniem jest tańsze niż tłumaczenie się z tego później.

Rozdziel środowiska na osobne projekty. Ślady z pracy deweloperskiej wymieszane z produkcyjnymi psują każdą statystykę i podnoszą rachunek za dane, których nikt nie ogląda.

Zbuduj zbiór testowy z realnych przypadków. Najtańsze źródło to rozmowy, które poszły źle: każda naprawiona sprawa powinna trafić do zbioru jako przypadek. Po kwartale masz zestaw odzwierciedlający rzeczywistość, a nie wyobrażenia zespołu.

Ostatnia rzecz to rytm. Ewaluacja uruchamiana przy każdej zmianie promptu, z wynikiem widocznym w przeglądzie kodu, zmienia sposób pracy bardziej niż jakikolwiek wykres. Ewaluacja uruchamiana raz na kwartał jest rytuałem.

Typowe błędy

Pierwszy to mylenie obu produktów tej firmy. Dokumentacja przebiegów trenowania nie dotyczy śledzenia aplikacji, choć obie rzeczy dzielą nazwę i panel.

Drugi to zapisywanie pełnych fragmentów przy wyszukiwaniu w dokumentach. Przy rozliczaniu za ilość danych to jest największa pozycja w rachunku i zwykle da się ją zastąpić identyfikatorami.

Trzeci to ufanie ewaluatorowi opartemu o model bez sprawdzenia zgodności z ocenami ludzi. Wykres oparty o taki ewaluator pokazuje coś, czego nie znasz.

Czwarty to instrumentowanie wyłącznie wywołania modelu. Największe opóźnienia i najczęstsze błędy siedzą w wyszukiwaniu i w narzędziach.

Piąty to brak polityki retencji. Ślady rosną liniowo i po roku pozycja za przechowywanie potrafi przewyższyć koszt zbierania.

Szósty to wysyłanie danych osobowych bez maskowania. Ślady lądują u dostawcy zewnętrznego, więc treść promptów podlega tym samym wymogom co dane w bazie produkcyjnej.

Siódmy to sprowadzanie jakości do jednej liczby. Średnia z jednego ewaluatora ukrywa przypadki, w których odpowiedź jest merytorycznie trafna i nie do przyjęcia z innego powodu, a właśnie takie zgłaszają użytkownicy.

Ósmy to uruchamianie ewaluacji dopiero po wdrożeniu. Wynik przed scaleniem zmian pozwala je cofnąć jednym ruchem, a wynik po wdrożeniu wymaga tłumaczenia się z regresu, który ktoś już zauważył.

FAQ

Czym Weave różni się od starszego produktu tej firmy?

Przeznaczeniem. Starszy służy do śledzenia trenowania modeli, czyli przebiegów uczenia i porównań hiperparametrów. Weave dotyczy aplikacji wywołujących gotowe modele: śledzi prompty, odpowiedzi, wywołania narzędzi i koszty oraz uruchamia ewaluacje.

Czy Weights & Biases to nadal niezależna firma?

Nie. CoreWeave, dostawca infrastruktury obliczeniowej, ogłosił przejęcie w marcu 2025 roku i sfinalizował je 5 maja tego samego roku, więc narzędzie jest dziś częścią oferty dostawcy mocy obliczeniowej.

Za co dokładnie płacę?

Rozliczenie opiera się na ilości przesłanych danych, a nie na liczbie śladów, plus opłata za przechowywanie. Plan darmowy obejmuje gigabajt danych miesięcznie, plan Pro od sześćdziesięciu dolarów daje półtora gigabajta, a nadmiar kosztuje dziesięć centów za megabajt. Znaczy to, że obszerne ślady kosztują więcej niż liczne, a aplikacje wyszukujące w dokumentach są najdroższe, o ile zapisujesz pełną treść fragmentów.

Czy da się uruchomić Weave u siebie?

Podstawowy wariant zakłada chmurę dostawcy, a opcje wdrożenia we własnej infrastrukturze zależą od planu i warto potwierdzić je bezpośrednio. Jeśli wymóg lokalnego przetwarzania jest twardy, Arize Phoenix uruchamia się na własnym serwerze bez negocjacji.

Czy muszę używać konkretnej biblioteki?

Nie. Instrumentacja opiera się na dekoratorze nakładanym na Twoje funkcje, więc działa niezależnie od tego, jak wywołujesz model. Wywołania do popularnych dostawców są dodatkowo przechwytywane automatycznie.

Dokumentacja stoi na stronie produktu, a kod w repozytorium na GitHubie.