AI Prompt Engineering · Lekcja

Ocena decyzji

Pomiar jakości i kosztów

Lekcja 4 z 413 kroki

Ocena decyzji to bezpłatna lekcja AI Prompt Engineering na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej AI Prompt Engineering, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AI Prompt Engineering zawiera 4 lekcji w sumie.

Nie można decydować o tym, czego nie da się zmierzyć

Wybór między promptem, dostrajaniem i podejściem hybrydowym jest tak dobry, jak stojąca za nim ewaluacja. Bez zamrożonego zbioru ewaluacyjnego i modelu kosztów każde porównanie jest tylko anegdotą.

Jakość i koszt to dwie osie - nie należy przedwcześnie sprowadzać ich do jednej liczby
Zbiór ewaluacyjny musi być odłożony i stabilny we wszystkich porównywanych podejściach
Zwycięża podejście znajdujące się w najlepszym punkcie granicy jakości i kosztu dla danych ograniczeń

Najpierw należy zbudować zamrożony zbiór ewaluacyjny

Przed rozpoczęciem jakiegokolwiek porównania należy utworzyć wydzielony zbiór ewaluacyjny, na którym żadne podejście nie będzie trenowane. Musi on odzwierciedlać rzeczywisty rozkład danych: typowe przypadki, znane przypadki brzegowe oraz dane adversarialne w przybliżeniu w proporcjach produkcyjnych.

Należy go zamrozić. Każde podejście - wyłącznie promptowe, dostrojone i hybrydowe - musi być oceniane na identycznym zbiorze. Jeśli zbiór ewaluacyjny zmienia się między porównaniami, wyniki nie są porównywalne, a decyzja jest nieważna.

def split_eval(labeled, holdout_ratio=0.2, seed=42):
    import random
    rng = random.Random(seed)        # fixed seed = reproducible split
    data = labeled[:]
    rng.shuffle(data)
    cut = int(len(data) * (1 - holdout_ratio))
    train, frozen_eval = data[:cut], data[cut:]
    return train, frozen_eval        # eval never enters any training run

Należy wybrać metryki dopasowane do zadania

Ogólna dokładność ukrywa błędy charakterystyczne dla danego zadania. Należy wybrać metryki, które mierzą to, co rzeczywiście ma znaczenie:

Dokładne dopasowanie do wyniku/schematu w przypadku ustrukturyzowanych danych wyjściowych
LLM-as-judge oceniany według kryteriów w przypadku jakości odpowiedzi otwartych, z próbką zweryfikowaną przez człowieka
Metryki ogona - najgorszy przypadek i p95, a nie tylko średnia
Wskaźniki bezpieczeństwa i odmów jako twarde kryteria, oceniane niezależnie od jakości

Średni wynik, który ukrywa katastrofalne przypadki w ogonie rozkładu, prowadzi do niewłaściwej decyzji.

Każdego kandydata należy oceniać identycznie

Należy przepuścić podejścia wyłącznie promptowe, dostrojone i hybrydowe przez ten sam system oceny na tym samym zamrożonym zbiorze. Dla każdego z nich należy zapisać jakość oraz pełny wektor kosztów, aby porównanie było rzetelne.

def evaluate(candidate, frozen_eval, scorer):
    results = []
    for ex in frozen_eval:
        out = candidate.run(ex['input'])
        results.append(scorer(out, ex['label']))
    mean = sum(results) / len(results)
    p95 = sorted(results)[int(0.95 * len(results)) - 1]
    return {'mean': mean, 'p95_worst': p95}

# Identical frozen_eval + scorer for prompt / tuned / hybrid

Należy modelować pełny wektor kosztów

Koszt nie jest jedną liczbą. Należy uwzględnić każdy składnik, aby porównanie odzwierciedlało rzeczywistość przy zakładanej skali:

Koszt wnioskowania na wywołanie: tokeny wejściowe i wyjściowe pomnożone przez cenę (długie prompty kosztują więcej przy każdym wywołaniu)
Zamortyzowany koszt trenowania: koszt dostrajania rozłożony na przewidywaną liczbę żądań
Utrzymanie: potok danych, uruchomienia ewaluacji i ponowne dostrajanie przy zmianach bazowego modelu
Opóźnienie: wyceniane osobno, gdy wpływa na konwersję lub doświadczenie użytkownika

def monthly_cost(calls, in_tok, out_tok, price_in, price_out,
                 train_cost=0.0, months_amortized=12):
    inference = calls * ((in_tok/1000)*price_in + (out_tok/1000)*price_out)
    amortized_train = train_cost / months_amortized
    return inference + amortized_train

# Long prompt-only: high in_tok, train_cost=0
# Tuned: low in_tok, train_cost>0 amortized over volume

Należy wyznaczyć granicę jakości i kosztu

Mając jakość i miesięczny koszt każdego kandydata, należy umieścić je na granicy. Kandydat jest zdominowany, jeśli inny kandydat zapewnia jednocześnie wyższą jakość i niższy koszt; zdominowanych kandydatów należy odrzucić.

Wśród niezdominowanych kandydatów właściwy wybór zależy od ograniczenia: należy wybrać najtańszy wariant, który przekracza wymagany poziom jakości, albo wariant o najwyższej jakości mieszczący się w limicie kosztów. Decyzja staje się jawna i możliwa do uzasadnienia, a nie oparta na preferencjach.

def non_dominated(candidates):
    # candidate: {'name','quality','cost'} -- higher quality, lower cost better
    keep = []
    for c in candidates:
        dominated = any(o['quality'] >= c['quality'] and o['cost'] <= c['cost']
                        and o != c for o in candidates)
        if not dominated:
            keep.append(c)
    return keep

Istotność statystyczna, nie szum

Wzrost o dwa punkty w ewaluacji obejmującej 200 przykładów może być wynikiem szumu. Przed ogłoszeniem zwycięzcy należy sprawdzić, czy różnica jakości jest istotna statystycznie przy danym rozmiarze zbioru ewaluacyjnego.

Należy użyć porównania parami (te same przykłady przekazane obu kandydatom) oraz przedziału ufności dla różnicy. Jeśli przedział obejmuje zero, nie ma rzeczywistej poprawy, a dodatkowy koszt dostrajania jest nieuzasadniony.

def paired_diff_ci(scores_a, scores_b):
    import statistics
    diffs = [a - b for a, b in zip(scores_a, scores_b)]
    mean = statistics.mean(diffs)
    sd = statistics.pstdev(diffs)
    se = sd / (len(diffs) ** 0.5)
    return (mean - 1.96*se, mean + 1.96*se)  # if it spans 0 -> not significant

Należy chronić się przed wyciekiem danych do ewaluacji

Najszybszym sposobem na pozorne zawyżenie wyników dostrajania jest wyciek danych - przykłady treningowe, które pokrywają się ze zbiorem ewaluacyjnym. Zawierający wyciek zbiór ewaluacyjny nagradza zapamiętywanie i zawyża wynik dostrojonego kandydata.

Należy usunąć duplikaty na granicy zbiorów treningowego i ewaluacyjnego, sprawdzić prawie identyczne przykłady oraz preferować ewaluację rozdzieloną w czasie (odłożoną według daty), aby dostrojony model nie mógł wcześniej jej zobaczyć. Wyciek danych jest najczęstszą przyczyną decyzji o dostrojeniu, która kończy się niepowodzeniem na produkcji.

Należy monitorować system po wdrożeniu

Decyzja nie jest ostateczna w momencie uruchomienia systemu. Rozkład danych produkcyjnych zmienia się, a dostrojony model może po cichu tracić jakość, gdy dane wejściowe oddalają się od rozkładu treningowego.

Pobierać próbki rzeczywistego ruchu i oceniać je według tych samych kryteriów
Ustawiać alerty na spadki jakości i wzrost kosztu na wywołanie
Ponownie uruchamiać zamrożoną ewaluację przy każdej zmianie wersji bazowego modelu

Wybrane podejście należy traktować jako hipotezę podlegającą ciągłym testom, a nie jako zamkniętą decyzję.

Rejestr decyzji

Porównanie należy zapisać jako pisemny rejestr decyzji: zamrożony zbiór ewaluacyjny, wektor jakości i kosztów każdego kandydata, wynik analizy istotności, założoną liczbę żądań oraz wybrany punkt na granicy wraz z uzasadnieniem.

Dzięki temu wybór można kontrolować i ponownie oceniać. Gdy zmieni się liczba żądań lub bazowy model, należy ponownie otworzyć rejestr i uruchomić analizę, zamiast odtwarzać dyskusję z pamięci.

Funkcja decyzyjna od początku do końca

Należy połączyć wszystkie elementy: ocenić każdego kandydata na zamrożonym zbiorze ewaluacyjnym, dołączyć jego koszt, odrzucić zdominowane warianty, wymagać istotnej poprawy względem najtańszego punktu odniesienia, a następnie dokonać wyboru zgodnie z wiążącym ograniczeniem.

def decide(candidates, quality_bar, cost_ceiling):
    frontier = non_dominated(candidates)
    feasible = [c for c in frontier
                if c['quality'] >= quality_bar and c['cost'] <= cost_ceiling]
    if not feasible:
        return 'NO_CANDIDATE_MEETS_CONSTRAINTS'
    # cheapest option that clears the quality bar
    return min(feasible, key=lambda c: c['cost'])['name']

# Prefer prompt-only on ties: lower maintenance TCO

Szybkie sprawdzenie

Dostrojony model uzyskuje wynik o 2 punkty wyższy niż podejście promptowe w ewaluacji obejmującej 150 przykładów, ale przedział ufności dla różnicy w porównaniu parami obejmuje zero. Ponadto kosztuje więcej miesięcznie. Jaka decyzja jest właściwa?

Odpowiedz w interaktywnej lekcji

Podsumowanie

Należy decydować na podstawie zamrożonej ewaluacji i rzetelnego wektora kosztów, a nie intuicji. Jakość i koszt to dwie osie; odpowiedzią jest punkt na granicy jakości i kosztu wybrany zgodnie z wiążącym ograniczeniem.

Zamrozić jeden zbiór ewaluacyjny i oceniać na nim każdego kandydata identycznie
Wybrać metryki dopasowane do zadania i obserwować ogon rozkładu, a nie tylko średnią
Modelować pełny wektor kosztów i amortyzować koszt trenowania na podstawie rzeczywistej liczby żądań
Wymagać istotności statystycznej; przedział ufności obejmujący zero oznacza brak poprawy
Chronić się przed wyciekiem danych do ewaluacji - to główna przyczyna pozornych sukcesów dostrajania
Monitorować system po wdrożeniu i zapisywać decyzje, aby można było ponownie je zweryfikować

Bezpłatny start

Ucz się AI Prompt Engineering dzięki korepetycjom AI — za darmo

Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.

Kursy: 53
Lekcje: 199

Zacznij naukę bezpłatnie Wyświetl pełny kurs

Często zadawane pytania

Czy lekcja „Ocena decyzji” jest bezpłatna?

Tak — pełny tekst „Ocena decyzji” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu AI Prompt Engineering, przejdź na CoddyKit PRO. Kurs AI Prompt Engineering zawiera 4 lekcji w sumie.

Co nauczysz się w „Ocena decyzji”?

Pomiar jakości i kosztów Ćwiczysz AI Prompt Engineering z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć AI Prompt Engineering?

Nie wymagamy żadnego doświadczenia. AI Prompt Engineering w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Ocena decyzji”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji AI Prompt Engineering?

Tak. Każda lekcja AI Prompt Engineering zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

← Powrót do AI Prompt Engineering