LangSmith: jak oceniać i śledzić aplikacje AI

Demonstracja asystenta wygląda dobrze, lecz po zmianie instrukcji część odpowiedzi stała się gorsza. Jak ustalić, co się zmieniło? LangSmith pomaga obserwować i oceniać aplikację AI, ale kryterium poprawności musi pochodzić z zadania biznesowego. Ładny ślad wykonania nie jest jeszcze dowodem, że klient otrzymał właściwy wynik.

Zakres opisanych funkcji sprawdzono 15 września 2026 r. Poniższy plan służy ocenie narzędzia i przygotowaniu kontroli jakości, nie obiecuje czasu wdrożenia ani automatycznej poprawy modelu.

Co pokazuje LangSmith

Platforma umożliwia zbieranie śladów wykonania, obserwację działania aplikacji oraz analizowanie wyników. Obsługuje różne frameworki i dostawców modeli; nie ogranicza się do aplikacji napisanych wyłącznie w LangChain. Źródło: LangSmith Observability.

Ślad pomaga odtworzyć przebieg konkretnego żądania. Można sprawdzić etapy, wywołania i miejsca wystąpienia problemu, w zakresie danych, które aplikacja rejestruje. Brak instrumentacji danego kroku nadal pozostawia lukę.

Oddziel obserwację od wykonania procesu. To aplikacja pobiera dokument, wywołuje narzędzie i zwraca odpowiedź. LangSmith pomaga ten przebieg analizować oraz porównywać jego wyniki.

Najpierw zapisz, co znaczy poprawna odpowiedź

Dla asystenta zamówień poprawność może oznaczać zgodność ze statusem w systemie, brak ujawnienia cudzych danych i czytelną informację o braku dostępu. Sam naturalny język nie wystarcza.

Kryterium	Jak je sprawdzić
Zgodność faktów	Porównać odpowiedź ze znanym źródłem
Kompletność	Sprawdzić wymagane elementy wyniku
Granice dostępu	Ocenić odmowę w niedozwolonym przypadku
Obsługa braku danych	Oczekiwać jawnej informacji zamiast zgadywania
Użyteczność	Sprawdzić, czy odbiorca wie, co zrobić dalej

Nie sprowadzaj wszystkich cech do jednej oceny liczbowej. Wysoka średnia może ukryć błąd krytyczny. Ujawnienie danych nie staje się akceptowalne dlatego, że pozostałe odpowiedzi były stylistycznie dobre.

Uzgodnij kryteria z osobą znającą proces. Programista może sprawdzić format, a właściciel usługi znaczenie wyniku. Obie perspektywy są potrzebne.

Przygotuj zbiór przypadków

LangSmith rozróżnia ocenę offline na przygotowanych danych od oceny online dotyczącej działania produkcyjnego. Dokumentacja opisuje zbiory przykładów, eksperymenty i sposoby oceny wyników. Źródło: LangSmith Evaluation.

Na początek dobierz przypadki zwykłe i trudne. Nie buduj zestawu wyłącznie z pytań używanych podczas demonstracji. Inaczej poprawisz wynik prezentacji, a nie odporność aplikacji.

Własny zestaw może zawierać poniższe grupy. Ich proporcje są propozycją ćwiczenia, nie normą branżową.

Grupa	Liczba przykładów	Oczekiwany wynik
Zwykłe pytania	10	Poprawna odpowiedź ze źródła
Brak informacji	4	Pytanie uzupełniające lub jawny brak
Niedozwolony dostęp	3	Odmowa ujawnienia danych
Błąd narzędzia	3	Kontrolowany komunikat
Razem	20	Osobna ocena każdej grupy

Zapisz oczekiwaną odpowiedź lub warunki jej akceptacji. Niektóre zadania dopuszczają wiele poprawnych sformułowań. Wtedy dokładne porównanie tekstu nie będzie właściwym miernikiem.

Przykład małego zestawu ewaluacyjnego

Asystent odpowiada na pytania pracowników o status zamówienia. Przygotuj cztery sztuczne sprawy z zatwierdzonymi danymi: poprawny numer, numer nieznany, zamówienie należące do innego klienta i sprzeczne daty w dwóch źródłach. Każda sprawa ma oczekiwany typ zachowania, nie jedną wzorcową frazę: odpowiedź ze źródłem, prośbę o doprecyzowanie, odmowę dostępu albo wskazanie konfliktu do wyjaśnienia.

Przypadek	Warunek zaliczenia	Niedopuszczalny wynik
Poprawny numer	Status i data pochodzą z właściwego rekordu	Dopisanie nieistniejącego terminu
Numer nieznany	Prośba o identyfikator lub informacja o braku danych	Wymyślony status
Cudze zamówienie	Odmowa bez ujawnienia szczegółów	Pokazanie danych innego klienta
Sprzeczne źródła	Wskazanie niepewności i eskalacja	Wybór jednej daty bez uzasadnienia

Zapisz wersję danych, promptu, modelu i aplikacji. W śladzie wykonania wystarczą identyfikatory testowych spraw, wywołane narzędzia i wynik oceny; nie kopiuj pełnych danych klientów, jeśli nie są potrzebne do diagnozy. Dokumentacja LangSmith o zbiorach danych opisuje zarządzanie przykładami, ale kryterium poprawności musi wynikać z firmowego procesu.

Porównuj wersje przy stałych warunkach

Przed zmianą instrukcji zachowaj wynik bazowy. Następnie uruchom nową wersję na tym samym zbiorze i sprawdź, które przypadki poprawiły się lub pogorszyły.

Zapisz identyfikator modelu, wersję instrukcji, dane i ustawienia istotne dla zadania. Zmiana kilku elementów jednocześnie utrudnia przypisanie przyczyny. W kontrolowanym porównaniu warto ograniczyć liczbę zmiennych.

Nie oczekuj pełnej identyczności odpowiedzi, jeśli generowanie jest zmienne. Dla istotnych przypadków rozważ powtórzenia i sprawdzaj stabilność spełniania kryterium, nie jedynie jednorazowy korzystny rezultat.

Wniosek powinien wskazywać zakres: nowa wersja poprawiła określoną grupę zadań, ale pogorszyła inną. To podstawa do decyzji o dalszym teście, a nie powód do ukrywania niepasujących przykładów.

Automatyczny oceniający także może się mylić

Format JSON lub obecność pola można sprawdzić regułą. Ocenę złożonej odpowiedzi można wspomóc modelem, lecz wynik takiej oceny wymaga kontroli.

Przygotuj przykłady, w których oceniający powinien wykryć błąd. Porównaj jego decyzję z oceną osoby znającej zadanie. Jeśli oceniający nagradza pewny ton mimo błędnych faktów, poprawa wyniku testu może prowadzić w niewłaściwą stronę.

Nie oddawaj automatycznej ocenie prawa do zatwierdzania nieograniczonego zakresu działań. Narzędzie ma wspierać odbiór zgodny z ryzykiem, a nie usuwać odpowiedzialność właściciela procesu.

Kontroluj dane trafiające do śladów

Ślad może zawierać treść pytania, fragmenty dokumentów, odpowiedzi narzędzi i wynik modelu. To może być większy zakres niż ten, który użytkownik widzi na ekranie.

Przed uruchomieniem rejestrowania ustal, czego potrzebujesz do diagnozy. Usuń lub ogranicz niepotrzebne informacje przed wysłaniem, sprawdź dostęp, retencję i sposób eksportu. Nie zakładaj, że środowisko testowe automatycznie oznacza bezpieczny zakres danych.

Dokumentacja opisuje różne warianty platformy, w tym chmurę, model hybrydowy i własne utrzymanie. Dostępność i warunki trzeba sprawdzić dla konkretnej oferty. Sam wybór wariantu nie zastępuje oceny przepływu danych.

Oszacuj koszt obserwacji i testów

Do kosztu aplikacji dodaj rejestrowanie, przechowywanie, eksperymenty i ewentualne wywołania modelu oceniającego. Rachunek zależy od zakresu, liczby prób i wybranej usługi.

Nie zbieraj wszystkiego bez celu. Najpierw określ pytania diagnostyczne i wymagany czas przechowywania. Zbyt ubogi ślad uniemożliwi analizę, a nadmierny zwiększy koszt i zakres danych wymagających kontroli.

W Inteligentnym Systemie Operacyjnym Firmy wynik AI powinien dać się powiązać z zadaniem i odpowiedzialnością. Obserwacja jest użyteczna, gdy prowadzi do poprawy konkretnego działania.

Sprawdź także wybór modelu

Jeśli warunkiem jest samodzielne utrzymanie otwartego narzędzia do śladów i ewaluacji, porównaj Langfuse z zakresem wybranego wariantu LangSmith. Ta decyzja dotyczy lokalizacji śladów, licencji i kosztu operacyjnego; oba narzędzia nadal wymagają własnych przypadków testowych i polityki danych.

Jeśli problem powraca mimo poprawy instrukcji, potrzebne może być porównanie modeli albo danych wejściowych. Poradnik Hugging Face pokazuje, jak ocenić model razem z jego dokumentacją i sposobem uruchomienia.

W poniedziałek wybierz jedną odpowiedź, która była błędna. Odtwórz źródło, wywołania i wynik, a następnie dodaj przypadek do zestawu kontrolnego. Możesz dalej oceniać aplikację po udanej prezentacji. Możesz też sprawdzić, czy ten sam błąd wróci po kolejnej zmianie.