0Pricing
AI Prompt Engineering · Lekcja

Monitorowanie wydajności promptów na produkcji

Śledzenie opóźnień, kosztów, ocen jakości i wskaźników błędów dla każdej wersji promptu.

Monitorowanie wydajności promptów na produkcji 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.

Dlaczego monitorować wydajność promptów

Prompt wdrożony na produkcji nie jest „ukończony”. Zachowanie modelu zmienia się wraz z aktualizacjami, dane wejściowe użytkowników z czasem ulegają zmianie, a koszty mogą nieoczekiwanie wzrosnąć. Ciągłe monitorowanie wykrywa regresje, zanim zaszkodzą użytkownikom, i pomaga utrzymać przewidywalne wydatki.

Kluczowe metryki dla każdej wersji promptu

Dla każdej wersji promptu działającej na produkcji należy śledzić pięć metryk:

  • Średnie opóźnienie: czas od żądania do otrzymania pełnej odpowiedzi (P50, P95, P99)
  • Koszt wywołania: tokeny wejściowe × cena + tokeny wyjściowe × cena
  • Ocena jakości: automatyczna ewaluacja (LLM-as-judge lub metryka zadania)
  • Współczynnik błędów: błędy API + niepowodzenia parsowania niepoprawnie sformatowanych wyników
  • Satysfakcja użytkowników: oceny kciukiem, współczynnik ponowień, porzucanie sesji

Instrumentacja: rejestrowanie metryk

Każde wywołanie LLM należy opatrzyć instrumentacją rejestrującą wszystkie kluczowe metryki w bazie danych szeregów czasowych lub innej bazie danych, aby można je było później analizować i wykorzystywać do generowania alertów.

import time
import openai

client = openai.OpenAI(api_key='YOUR_API_KEY')

def instrumented_call(prompt_id, version, messages, model):
    start = time.time()
    error = False
    response = None
    try:
        response = client.chat.completions.create(
            model=model,
            messages=messages
        )
    except Exception as e:
        error = True
        raise
    finally:
        latency_ms = (time.time() - start) * 1000
        usage = response.usage if response else None
        record_metric({
            'prompt_id': prompt_id,
            'version': version,
            'latency_ms': latency_ms,
            'input_tokens': usage.prompt_tokens if usage else 0,
            'output_tokens': usage.completion_tokens if usage else 0,
            'error': error,
            'timestamp': time.time()
        })
    return response

Obliczanie kosztu wywołania

Koszt wywołania = tokeny wejściowe × cena tokenów wejściowych + tokeny wyjściowe × cena tokenów wyjściowych. Przechowywanie surowych liczników tokenów pozwala ponownie obliczyć koszt po każdej zmianie cennika.

# pricing.py — model pricing table (per 1M tokens)
PRICING = {
    'gpt-4o': {'input': 2.50, 'output': 10.00},
    'gpt-4o-mini': {'input': 0.15, 'output': 0.60},
    'claude-3-5-sonnet-20241022': {'input': 3.00, 'output': 15.00},
}

def cost_usd(model, input_tokens, output_tokens):
    p = PRICING.get(model)
    if not p:
        return None
    cost = (input_tokens / 1_000_000) * p['input'] \
         + (output_tokens / 1_000_000) * p['output']
    return round(cost, 6)

# Example
c = cost_usd('gpt-4o-mini', input_tokens=800, output_tokens=200)
print(f'Cost per call: ${c}')   # Cost per call: $0.000240

# Daily cost estimate
calls_per_day = 50_000
print(f'Daily cost: ${round(c * calls_per_day, 2)}')  # $12.00

Automatyczna ocena jakości

Do automatycznej oceny jakości wyników na produkcji należy użyć LLM jako sędziego. Aby utrzymać koszty na rozsądnym poziomie, oceniaj 5–10% wywołań.

import random

JUDGE_SAMPLE_RATE = 0.05  # score 5% of calls

JUDGE_PROMPT = '''Rate the quality of this AI response on a scale of 1-5.
1=Very poor, 3=Acceptable, 5=Excellent.
Return only the integer score.

User input: {input}
AI response: {output}'''

def maybe_score_quality(user_input, ai_output, model='gpt-4o-mini'):
    if random.random() > JUDGE_SAMPLE_RATE:
        return None  # not sampled

    judge_messages = [{'role': 'user', 'content':
        JUDGE_PROMPT.format(input=user_input, output=ai_output)}]
    response = client.chat.completions.create(
        model=model, messages=judge_messages, max_tokens=5
    )
    try:
        score = int(response.choices[0].message.content.strip())
        return max(1, min(5, score))  # clamp to 1-5
    except ValueError:
        return None

Przechowywanie metryk w bazie danych szeregów czasowych

Bazy danych szeregów czasowych (InfluxDB, TimescaleDB lub nawet prosta tabela PostgreSQL z indeksem opartym na znaczniku czasu) wydajnie przechowują metryki poszczególnych wywołań i obsługują zapytania agregujące na potrzeby dashboardów.

-- TimescaleDB / PostgreSQL schema for prompt metrics
CREATE TABLE prompt_metrics (
  ts              TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  prompt_id       VARCHAR(100),
  version         VARCHAR(20),
  model           VARCHAR(50),
  latency_ms      FLOAT,
  input_tokens    INT,
  output_tokens   INT,
  cost_usd        FLOAT,
  quality_score   FLOAT,   -- NULL if not sampled
  error           BOOLEAN DEFAULT FALSE
);

-- Convert to hypertable (TimescaleDB)
SELECT create_hypertable('prompt_metrics', 'ts');

-- Query: hourly P95 latency by version
SELECT
  date_trunc('hour', ts) AS hour,
  version,
  PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY latency_ms) AS p95_latency
FROM prompt_metrics
WHERE prompt_id = 'summarize-article'
  AND ts > NOW() - INTERVAL '24 hours'
GROUP BY 1, 2
ORDER BY 1;

Tworzenie dashboardu metryk

Dashboardy prezentują pięć kluczowych metryk w czasie rzeczywistym. Można użyć Grafana (ze źródłem danych TimescaleDB) lub niestandardowego dashboardu webowego. Kluczowe panele:

  • Opóźnienie P50/P95/P99 w czasie, według wersji
  • Trend kosztu wywołania (dzienny/tygodniowy)
  • Procentowy współczynnik błędów
  • Średnia krocząca oceny jakości
  • Ocena satysfakcji użytkowników
# Simple dashboard query aggregation in Python
def get_dashboard_stats(conn, prompt_id, hours=24):
    with conn.cursor() as cur:
        cur.execute('''
            SELECT
              version,
              COUNT(*) AS calls,
              AVG(latency_ms) AS avg_latency,
              PERCENTILE_CONT(0.95)
                WITHIN GROUP (ORDER BY latency_ms) AS p95_latency,
              AVG(cost_usd) AS avg_cost,
              AVG(quality_score) FILTER (WHERE quality_score IS NOT NULL) AS avg_quality,
              SUM(error::int)::float / COUNT(*) AS error_rate
            FROM prompt_metrics
            WHERE prompt_id = %s
              AND ts > NOW() - INTERVAL %s
            GROUP BY version
            ORDER BY MAX(ts) DESC
        ''', (prompt_id, f'{hours} hours'))
        return cur.fetchall()

Wykrywanie anomalii wskazujących na regresję promptu

Ręczne przeglądanie dashboardu nie wykrywa powolnych regresji. Automatyczne wykrywanie anomalii porównuje okno kroczące z historycznym poziomem bazowym i generuje alert, gdy odchylenie przekroczy określony próg.

import statistics

def detect_anomaly(recent_values, baseline_values, threshold_std=2.0):
    if len(baseline_values) < 10:
        return False  # not enough data
    baseline_mean = statistics.mean(baseline_values)
    baseline_std = statistics.stdev(baseline_values)
    recent_mean = statistics.mean(recent_values)

    if baseline_std == 0:
        return False
    z_score = abs(recent_mean - baseline_mean) / baseline_std
    return z_score > threshold_std

# Example: detect quality regression
baseline_quality = [4.1, 4.0, 4.2, 4.1, 4.0, 3.9, 4.1, 4.2, 4.0, 4.1]
recent_quality   = [3.2, 3.1, 3.4, 3.0]

if detect_anomaly(recent_quality, baseline_quality):
    print('ALERT: Quality score anomaly detected!')
    # fire_pagerduty_alert(...)
else:
    print('Quality within normal range')

Reguły alertów i progi

Reguły alertów należy definiować jako kod, aby można było je kontrolować za pomocą systemu kontroli wersji i poddawać przeglądom. Typowe alerty monitorowania promptów:

  • Współczynnik błędów > 5% przez 5 kolejnych minut
  • Opóźnienie P95 > 10 s przez 3 minuty
  • Koszt dzienny > 2× średnia tygodniowa (nagły wzrost kosztów)
  • Ocena jakości spada o > 20% względem poziomu bazowego
# alerts.yaml (Grafana alerting or custom)
alerts:
  - name: HighErrorRate
    condition: error_rate > 0.05
    for: 5m
    severity: critical
    message: 'Prompt {prompt_id} error rate {error_rate:.1%} exceeds 5%'

  - name: HighLatencyP95
    condition: p95_latency_ms > 10000
    for: 3m
    severity: warning
    message: 'P95 latency {p95_latency_ms}ms exceeds 10s for {prompt_id}'

  - name: CostSpike
    condition: daily_cost_usd > weekly_avg_daily_cost * 2
    for: 1h
    severity: warning
    message: 'Daily cost ${daily_cost_usd:.2f} is 2x the weekly average'

  - name: QualityRegression
    condition: rolling_quality_avg < baseline_quality_avg * 0.80
    for: 15m
    severity: critical
    message: 'Quality dropped {pct_drop:.0%} for prompt {prompt_id}'

Sygnały satysfakcji użytkowników

Automatyczne metryki nie uwzględniają wszystkiego. Należy zbierać jawne i niejawne sygnały od użytkowników, aby uzupełnić oceny jakości:

  • Ocena kciukiem: jawna ocena 👍/👎 odpowiedzi AI
  • Współczynnik ponowień: użytkownik natychmiast ponownie wysyła to samo zapytanie (niejawny sygnał niezadowolenia)
  • Współczynnik kopiowania/wykorzystania: użytkownik kopiuje wynik AI (niejawny sygnał zadowolenia)
  • Współczynnik korekt: użytkownik edytuje wynik AI przed jego wykorzystaniem
# feedback_collector.py
def record_feedback(prompt_id, version, call_id, signal_type, value):
    '''
    signal_type: 'thumbs' | 'retry' | 'copy' | 'edit'
    value: for thumbs: 1 (up) or -1 (down); others: 1 (occurred)
    '''
    db.execute(
        'INSERT INTO prompt_feedback '
        '(prompt_id, version, call_id, signal_type, value, ts) '
        'VALUES (%s, %s, %s, %s, %s, NOW())',
        (prompt_id, version, call_id, signal_type, value)
    )

# Aggregate satisfaction score
def satisfaction_score(prompt_id, version):
    rows = db.fetch(
        'SELECT signal_type, AVG(value) as avg_val FROM prompt_feedback '
        'WHERE prompt_id=%s AND version=%s GROUP BY signal_type',
        (prompt_id, version)
    )
    return {r['signal_type']: round(r['avg_val'], 3) for r in rows}

Raporty porównania wersji

Przy ocenie, czy promować canary, czy wykonać rollback, należy wygenerować porównanie wszystkich metryk nowej wersji i poziomu bazowego obok siebie. Raport ten stanowi podstawę decyzji o promocji.

def version_comparison_report(prompt_id, version_a, version_b, hours=48):
    stats_a = get_dashboard_stats_for_version(prompt_id, version_a, hours)
    stats_b = get_dashboard_stats_for_version(prompt_id, version_b, hours)

    print(f'=== Comparison: {version_a} vs {version_b} ===')
    metrics = ['avg_latency', 'p95_latency', 'avg_cost', 'avg_quality', 'error_rate']
    for m in metrics:
        va = stats_a.get(m, 0)
        vb = stats_b.get(m, 0)
        delta = vb - va
        pct = (delta / va * 100) if va else 0
        direction = '+' if delta > 0 else ''
        print(f'{m:20s}: {va:.4f} -> {vb:.4f}  ({direction}{pct:.1f}%)')

# Example output:
# avg_latency         : 1234.5000 -> 1189.2000  (-3.7%)
# p95_latency         : 3210.0000 -> 3050.0000  (-5.0%)
# avg_cost            : 0.000240 -> 0.000255  (+6.2%)
# avg_quality         : 4.1000 -> 4.3000  (+4.9%)
# error_rate          : 0.0120 -> 0.0080  (-33.3%)

Szybkie sprawdzenie

Chcą Państwo automatycznie wykrywać regresje jakości bez ręcznego sprawdzania dashboardów. Które podejście najlepiej to umożliwia?

Podsumowanie monitorowania

Monitorowanie promptów na produkcji wymaga śledzenia pięciu wymiarów dla każdej wersji:

  • Opóźnienie (P50/P95/P99) — doświadczenie użytkownika
  • Koszt wywołania — kondycja finansowa
  • Ocena jakości — automatyczne próbkowanie z użyciem LLM jako sędziego
  • Współczynnik błędów — niezawodność
  • Satysfakcja użytkowników — oceny kciukiem, ponowienia i sygnały kopiowania

Metryki należy przechowywać w bazie danych szeregów czasowych, wizualizować na dashboardach i generować alerty po przekroczeniu progów. Raporty porównania wersji pomagają podejmować decyzje o promocji i rollbacku.

Często zadawane pytania

Czy lekcja „Monitorowanie wydajności promptów na produkcji” jest bezpłatna?

Tak — pełny tekst „Monitorowanie wydajności promptów na produkcji” 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 „Monitorowanie wydajności promptów na produkcji”?

Śledzenie opóźnień, kosztów, ocen jakości i wskaźników błędów dla każdej wersji promptu. Ć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 „Monitorowanie wydajności promptów na produkcji”?

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

  1. Architektura rejestru promptów
  2. Kontrola wersji promptów
  3. Strategie wdrażania i wycofywania zmian
  4. Monitorowanie wydajności promptów na produkcji
← Powrót do AI Prompt Engineering