Metrics, alerts, र dashboards

चार मुख्य metrics

एक LLM service को लागि, चार dimensions ले तपाईंलाई थाहा पाउनुपर्ने अधिकांश कभर गर्दछन्:

1. Latency — हरेक request कति लामो लाग्दैछ, p50 र p95 मा?
2. Error rate — कति अंश requests असफल हुन्छन्?
3. Cost — हामी प्रति घण्टा, प्रति प्रयोगकर्ता, प्रति endpoint के खर्च गरिरहेका छौं?
4. Quality — जवाफहरू राम्रो छन्?

Latency र errors technical हुन्। Cost economic हो। Quality हो जुन प्रयोगकर्ताले वास्तवमा हेरचाह गर्दछ — र राम्रोसँग मापन गर्न सबैभन्दा गाह्रो।

Latency

हरेक endpoint को लागि, track गर्नुहोस्:

• p50 (median) — सामान्य अनुभव।
• p95 — slower 5% requests। जहाँ “app laggy लाग्छ” बस्दछ।
• p99 — पुच्छर। दुर्लभ, तर प्रयोगकर्ताले हिट गर्न सक्ने सबैभन्दा नराम्रो केस।

एक LLM Q&A service को लागि, स्वस्थ लक्ष्यहरू:

• p50: 1-2 s
• p95: 3-5 s
• p99: <10 s

यदि p95 5 s भन्दा माथि creeping सुरु हुन्छ भने, केही परिवर्तन भएको छ — retrieval slower भयो, model provider को खराब दिन छ, वा तपाईंको service load अन्तर्गत छ। जाँच गर्नुहोस्।

Latency, stage द्वारा तोडिएको, अझ उपयोगी छ। यदि कुल latency 4 s छ र retrieval 200 ms थियो र मोडेल 3.6 s थियो भने, मोडेल bottleneck हो। यदि retrieval 3 s थियो भने, तपाईंको vector store समस्या हो।

# collect stage-level latencies
log_event("latency", request_id=id, stage="retrieval", ms=210)
log_event("latency", request_id=id, stage="model", ms=1840)
log_event("latency", request_id=id, stage="post", ms=25)

यीलाई per-stage p50/p95 dashboards मा aggregate गर्नुहोस्।

Error rate

हरेक request या त सफल हुन्छ, error हुन्छ, वा अस्वीकार हुन्छ (quota, validation, rate limit)। fractions track गर्नुहोस्:

• Success rate — स्वस्थ services को लागि 95%+ हुनुपर्दछ।
• 5xx rate — server errors। <1% हुनुपर्दछ। कुनै पनि spike एक incident हो।
• 4xx rate — client errors (bad input, quota, auth)। तपाईंको traffic मा भर पर्दछ; sudden परिवर्तनहरूको लागि watch गर्नुहोस्।
• Refusal rate — मोडेलले जवाफ दिन इन्कार गर्यो, वा सहायकले “मलाई थाहा छैन” भन्यो। अलग रूपमा track गर्नुहोस्; एक spike को प्राय: retrieval टुट्यो भन्ने मतलब हो।

log_event("outcome", endpoint="/summarise", outcome="success")
log_event("outcome", endpoint="/summarise", outcome="5xx", error="APIError")
log_event("outcome", endpoint="/summarise", outcome="quota_exceeded")
log_event("outcome", endpoint="/summarise", outcome="refusal")

त्यसपछि aggregate गर्नुहोस्: outcome | count by outcome, endpoint, 5-minute-window। Chart गर्नुहोस्। 5xx rate > 1% for 5 minutes मा alert गर्नुहोस्।

Cost

Cost लाई तपाईंको per-request cost अनुमानहरू योग गरेर मापन गरिन्छ:

• प्रति घण्टा कुल cost — के यो जे तपाईंले अपेक्षा गर्नुभयो त्यो हो?
• प्रति प्रयोगकर्ता प्रति दिन cost — Rs 10 vs. Rs 100 पूरै फरक economic model हो।
• प्रति endpoint cost — पैसा कहाँ जाँदैछ?
• Cache hit rate — तपाईं caching बाट कति बचत गर्दै हुनुहुन्छ?

एक अप्रत्याशित cost spike प्राय: abuse, bug, वा viral क्षणको पहिलो चिन्ह हो। जुनसुकै घण्टामा alert गर्नुहोस् जहाँ cost recent baseline को 3× भन्दा बढी हुन्छ।

Quality — सबैभन्दा गाह्रो

तपाईं मात्र logs बाट “जवाफ राम्रो छ?” सजिलै मापन गर्न सक्नुहुन्न। Proxies:

• User thumbs up/down rate। यदि तपाईंसँग feedback button छ भने, thumbs-down rate प्रत्यक्ष quality signal हो।
• “मलाई थाहा छैन” rate। तपाईंको सहायकले refusal मा fall back गर्ने दर। बढ्दो दरले सामान्यतया retrieval टुटिरहेको छ वा user queries shift भएको छ भन्ने मतलब हुन्छ।
• Retrieval confidence। सबै queries भर top-score को distribution। तल drift ले तपाईंको semantic search degrade हुँदैछ भन्ने मतलब राख्दछ।
• Session-length। Chat उत्पादहरूको लागि, session length ले engagement signal गर्न सक्दछ। Q&A bot मा धेरै छोटो sessions को मतलब पहिलो जवाफ unhelpful थियो हुन सक्दछ।

Chapter 4 ले production मा evaluation लाई अझ राम्ररी कभर गर्दछ — यो dashboard को लागि proxies को shortcut सेट हो।

Dashboards

हरेक AI service सँग एउटा dashboard हुनुपर्दछ, एउटा screen मा, जुन टिमले दैनिक हेर्न सक्दछ। सुझाव गरिएको layout:

┌──────────────────────────────────────────┐
│ nepse-mitra — production dashboard       │
├──────────────────────────────────────────┤
│ Latency (p50 / p95, per endpoint)         │
│ Error rate (%, past hour / past 24h)     │
│ Cost (Rs, this hour / this day / month)  │
│ Refusal rate (%, past 24h)               │
│ Cache hit rate (%, past 24h)             │
│ Thumbs down rate (%, past 24h)           │
│ Active users (past hour / 24h)           │
└──────────────────────────────────────────┘

सात संख्याहरू। सबै एकैचोटि दृश्यमान। टिममा कसैले पनि हेर्न सक्दछ, 30 सेकेन्ड मा, र “हामी स्वस्थ देखिन्छौं” वा “केही off छ” भन्न सक्दछ।

Tooling विकल्पहरू:

• Managed: Datadog, Grafana Cloud, Better Stack। तिनीहरूलाई तपाईंको log stream मा point गर्नुहोस्; तिनीहरूको dashboard builder प्रयोग गर्नुहोस्।
• Self-hosted: Grafana + Loki (logs) + Prometheus (metrics)। थप setup, थप नियन्त्रण।
• Minimal: एक सानो Python script जुन कल S3 बाट hijos logs पढ्दछ, aggregate गर्दछ, र हरेक बिहान टिमलाई email गर्दछ। शून्य infrastructure। एक सानो परियोजनाको लागि अचम्मको प्रभावकारी।

Minimal बाट सुरु गर्नुहोस्। जब तपाईंले current tool को pain महसुस गर्नुहुन्छ मात्र upgrade गर्नुहोस्।

Alerts

एक alert एक नियम हो जुन metric ले threshold पार गर्दा notification fire गर्दछ। राम्रो alert को नियम:

• Actionable। कसैले यस बारे केही गर्न सक्दछ। “Latency high छ” कुनै recovery path बिना noise हो।
• Specific। “5xx rate > 2% for 5 minutes on /summarise” specific छ। “केही गलत छ” छैन।
• Rate-limited। प्रति incident एक notification, प्रति मिनेट एक होइन।
• Sensibly routed। कार्य घण्टामा: Slack। रातभर: genuine emergencies (service down, wallet fire) को लागि मात्र page।

Starter alert set:

• 5xx rate > 1% for 5 min → Slack मा चेतावनी।
• 5xx rate > 5% for 5 min → on-call page।
• Cost rate > 3× baseline for 30 min → on-call page (potential wallet fire)।
• p95 latency > 10 s for 15 min → Slack मा चेतावनी।
• Thumbs-down rate > 15% for 24h → Slack मा चेतावनी (quality regression)।

पाँच alerts। सबै actionable। noise को लागि noise छैन।

Nepal-विशिष्ट dashboard

Nepal-facing उत्पादको लागि, केही local signals थप्नुहोस्:

• Devanagari vs. Latin input ratio। नेपाली vs. अंग्रेजीमा कति queries छन्? यहाँ ट्रेन्डहरूले language-audience shifts संकेत गर्दछन्।
• क्षेत्रीय प्रयोगकर्ता वितरण (यदि geo data उपलब्ध छ)। काठमाडौँ vs. पोखरा vs. ग्रामीण। Quality प्राय: क्षेत्रीय रूपमा फरक हुन्छ किनकि training data गर्दछ।
• NPT मा time-of-day usage। तपाईंका प्रयोगकर्ताहरू कहिले सक्रिय छन्? Global averages होइन, वास्तविक उपयोग windows को capacity र cost caps लाई match गर्नुहोस्।

यी universally applicable छैनन्, तर उत्पादहरूको लागि जहाँ language / region / time-of-day matter गर्दछ, तिनीहरूले नेपाली audiences को लागि specific समस्याहरू surface गर्दछन् जुन generic metrics ले छुटाउँछन्।

दैनिक habit

हरेक बिहान, एक व्यक्ति dashboard मा 5 मिनेट खर्च गर्दछ:

1. के संख्याहरू हुनुपर्ने ठाउँमा छन्?
2. के कुनै spikes वा dips छन्?
3. कुनै alerts overnight जसलाई follow-up चाहिन्छ?

व्यक्ति साप्ताहिक परिवर्तन हुन्छ। सबैले “normal” कस्तो देखिन्छ को intuition निर्माण गर्दछन्। जब केही shifts हुन्छ, प्रयोगकर्ताहरू भन्दा पहिले टिमले नोटिस गर्दछ।

यो एक बानी — प्रत्येक दिन 5 मिनेट dashboard-reading — शान्तपूर्वक rot गर्ने service र वर्षौंसम्म स्वस्थ रहने service बीचको फरक हो।

अब के आउँछ

तपाईं आफ्नो प्रणाली देख्न सक्नुहुन्छ, र यो टुट्दा तपाईं alarm गर्न सक्नुहुन्छ। अर्को: जब चीजहरू टुट्दछन् तपाईंको कोड भित्र के गर्ने। Timeouts, retries, fallbacks — patterns जुन एक नाजुक service लाई graceful बनाउँदछन्, ताकि प्रयोगकर्ताहरूले भ्रमित stack traces को सट्टा मैत्रीपूर्ण errors देख्दछन्।