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 responseObliczanie 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.00Automatyczna 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 NonePrzechowywanie 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
- Architektura rejestru promptów
- Kontrola wersji promptów
- Strategie wdrażania i wycofywania zmian
- Monitorowanie wydajności promptów na produkcji