हरेक interaction log गर्ने · AI प्रणाली शिप गर्ने

Live AI प्रणालीमा हरेक रहस्य — “यसले किन त्यो भन्यो?” “यो किन ढिलो छ?” “यो प्रयोगकर्ताले किन गलत जवाफ पायो?” — यदि तपाईंसँग logs छन् भने हल गर्न सकिन्छ र यदि तपाईंसँग छैनन् भने unsolvable छ। Logging glamorous छैन; यो हरेक अन्य operational discipline निर्माण भएको substrate हो। यो खण्ड एक सानो, unremarkable habit हो जुन समयको साथ सुधार हुने services लाई चुपचाप degrade हुने services बाट अलग गर्दछ।

न्यूनतम log

हरेक request जुन तपाईंको service मा हिट गर्दछ, कम्तिमा log गर्नुहोस्:

Timestamp (timezone सँग)।
Request ID — एक UUID जुन यो एक call बारे सबै कुरा जोड्दछ।
User ID — कसले सोध्दै छ।
Endpoint — कुन route।
Input — प्रयोगकर्ताको प्रश्न, साथै कुनै सम्बन्धित parameters।
Retrieval — कुन chunks retrieved थिए (IDs + scores)।
Model call — कुन model, tokens in, tokens out, cost अनुमान।
Output — तपाईंको service ले के फर्कायो।
Latency — कति लाग्यो, यदि सम्भव भए stages मा तोडिएको।
Status — success, error, refusal, quota hit।

यदि तपाईंसँग ती सबै छन् भने, तपाईंले पछि लगभग हरेक operational प्रश्नको जवाफ दिन सक्नुहुन्छ।

Structured logs, सधैँ

Production मा print() को lines कहिल्यै dump नगर्नुहोस्। JSON को रूपमा log गर्नुहोस्:

import logging
import json
import time
import uuid


logger = logging.getLogger("service")
handler = logging.StreamHandler()
handler.setFormatter(logging.Formatter("%(message)s"))
logger.addHandler(handler)
logger.setLevel(logging.INFO)


def log_event(event: str, **fields):
    payload = {
        "event": event,
        "ts": time.strftime("%Y-%m-%dT%H:%M:%S%z"),
        **fields,
    }
    logger.info(json.dumps(payload, ensure_ascii=False))

तपाईंको endpoint मा:

@app.post("/summarise")
def summarise(req: SummariseRequest, user_id: str = Depends(get_current_user)):
    request_id = str(uuid.uuid4())
    started = time.time()

    log_event("request_start",
              request_id=request_id,
              user_id=user_id,
              endpoint="/summarise",
              input_length=len(req.text))

    try:
        result = do_the_work(req)
    except Exception as e:
        log_event("request_error",
                  request_id=request_id,
                  error_type=type(e).__name__,
                  error_message=str(e))
        raise

    log_event("request_success",
              request_id=request_id,
              latency_ms=int((time.time() - started) * 1000),
              output_length=len(result.summary),
              tokens_input=result.tokens_input,
              tokens_output=result.tokens_output,
              cost_usd=result.cost_usd)

    return result

Structured JSON को मतलब तपाईंले पछि query गर्न सक्नुहुन्छ: log aggregator (Datadog, Grafana Loki, वा grep र jq पनि) मा logs | filter user_id=nishan | count।

के log नगर्ने

log गर्ने भन्दा उत्तिकै महत्त्वपूर्ण:

Plain text मा unhashed PII कहिल्यै log नगर्नुहोस्। यदि तपाईंको service ले phone numbers, national ID numbers, वा पूर्ण नामहरू प्राप्त गर्दछ भने, raw values log नगर्नुहोस्।

सट्टामा: sensitive fields लाई hash गर्नुहोस् (hashlib.sha256) ताकि तपाईं पहिचान expose नगरी प्रयोगकर्ताद्वारा समूह गर्न सक्नुहुन्छ।
वा: केवल truncated/masked संस्करण ("9841***456") log गर्नुहोस्।

पूर्ण API keys वा auth tokens कहिल्यै log नगर्नुहोस्। यदि एक auth token request मा देखिन्छ भने, truncated version ("tok_abcd...") log गर्नुहोस्।

Raw payment data कहिल्यै log नगर्नुहोस्। अधिकांश jurisdictions मा regulated; सबैमा risky।

प्रयोगकर्ताको पूर्ण प्रश्न सँग सावधान हुनुहोस् यदि यसमा व्यक्तिगत डाटा हुन सक्दछ। सामान्य chatbot को लागि, यसलाई log गर्नुहोस्। मानसिक स्वास्थ्य app को लागि, redacting वा hashing मा विचार गर्नुहोस्।

Logs अन्य कुनै पनि data store जस्तै privacy र compliance नियमहरूको अधीनमा हुन्छन्। Nepal को Data Protection Act (एकपटक लागू भएपछि) र अवस्थित उपभोक्ता संरक्षण मापदण्ड दुबैले व्यक्तिगत डाटाको ईमानदार उपचार आवश्यक पर्दछ — तपाईंले logs मा राख्नुहुने कुरा सहित। हरेक log line एक सानो privacy निर्णय हो। तपाईंलाई operational insight को लागि आवश्यक न्यूनतम log गर्नुहोस्, र अरू केही होइन।

Retention र storage

दुई axes: तपाईं logs कति समय राख्नुहुन्छ, र कहाँ।

Retention।

Real-time logs (debugging को लागि): 24 घण्टा देखि 7 दिन, in-memory वा hot storage मा।
Structured event logs (analytics, evaluation को लागि): cheap storage मा 30-90 दिन।
Regulated logs (वित्तीय, स्वास्थ्य): जे स्थानीय नियमहरूले आवश्यक पर्दछ। NEPSE/BFI-facing उत्पादहरूको लागि, compliance सल्लाहकारसँग परामर्श गर्नुहोस्।

Storage।

Small scale: stdout को log aggregator मा pipe गरिएको (Fly.io, Railway, Render सबैले एक समावेश गर्दछन्)।
Medium scale: Datadog, Better Stack, Grafana Cloud जस्तै managed service।
Large scale: self-hosted Grafana + Loki, वा Elasticsearch।

Nepal-scale मा (हजारौंदेखि दसौं हजार interactions प्रति दिन), managed platform को built-in logging सामान्यतया महिनौंको लागि पर्याप्त हुन्छ। over-engineer नगर्नुहोस्।

Request भर tracing

धेरै चरण भएको AI systems (retrieval → model → post-processing) को लागि, एक trace ले तिनीहरूलाई जोड्दछ। हरेक चरणले उही request_id log गर्दछ, ताकि तपाईंले एक call को पूर्ण life cycle पुनर्निर्माण गर्न सक्नुहुन्छ।

def do_the_work(req, request_id):
    t0 = time.time()

    log_event("retrieval_start", request_id=request_id)
    hits = search_index(req.text, top_k=3)
    log_event("retrieval_done",
              request_id=request_id,
              latency_ms=int((time.time() - t0) * 1000),
              top_score=hits[0]["score"],
              doc_ids=[h["doc_id"] for h in hits])

    t1 = time.time()
    log_event("model_call_start", request_id=request_id)
    response = client.messages.create(...)
    log_event("model_call_done",
              request_id=request_id,
              latency_ms=int((time.time() - t1) * 1000),
              model="claude-3-5-sonnet-latest",
              tokens_input=response.usage.input_tokens,
              tokens_output=response.usage.output_tokens)

    ...

अब, कुनै पनि request_id को लागि, तपाईंले देख्न सक्नुहुन्छ: retrieval कति लामो लाग्यो, कुन कागजातहरू यसले फर्कायो, मोडेल कति लामो लाग्यो, मोडेलले के उत्पादन गर्यो। एक slow request debugging गर्नु त्यो stage पत्ता लगाउनु बन्दछ जुन लामो लाग्यो।

Audit log

AI systems को लागि जसले प्रयोगकर्ताको तर्फबाट निर्णयहरू गर्दछ (एक policy Q&A bot, एक वित्तीय सहायक, एक चिकित्सा triage tool), एक स्थायी audit log राख्नुहोस् — हरेक interaction को separate append-only store, operational logs भन्दा लामो समयसम्म retained।

Fields:

request_id, user_id, timestamp
पूर्ण input
Retrieved documents (IDs + scores)
पूर्ण output
Model version, prompt version

Purpose: जब प्रयोगकर्ताले “bot ले मलाई गलत जानकारी दियो” भन्दछ, तपाईं ठ्याक्कै के भयो हेर्न सक्नुहुन्छ। यसले प्रयोगकर्तालाई सुरक्षित गर्दछ, र यसले तपाईंलाई सुरक्षित गर्दछ।

Audit log ephemeral 30-day retention window बाहिर बस्दछ। यसलाई cheap, append-only storage (S3, GCS, वा local WORM store) मा राख्नुहोस्। तपाईंको उत्पादको risk profile मा भर पर्दछ, छ महिना देखि केही वर्ष।

Logs ले दिने पाँच कुराहरू

Well-structured logs ले सबै downstream सक्षम गर्दछन्:

Debugging। “यो प्रयोगकर्ताले गलत जवाफ पायो” तथ्य बन्दछ जुन तपाईंले जाँच गर्न सक्नुहुन्छ, अनुमान गर्नुपर्ने दावी होइन।
Performance। “Requests 2 PM मा slow थिए” query बन्दछ, रहस्य होइन।
Evaluation। Logs निरन्तर मूल्यांकन loop (Chapter 4) को लागि कच्चा सामग्री हुन्।
Cost विश्लेषण। “कुन endpoint सबैभन्दा धेरै cost लाग्दछ?” log-level cost fields बाट जवाफ योग्य छ।
Product सुधार। “प्रयोगकर्ताहरू वास्तवमा के सोध्दैछन्?” input logs बाट जवाफ योग्य छ।

यीमध्ये हरेक logs बिना असम्भव छ। यीमध्ये हरेक महिनौं जम्मा भएको डाटामा compound हुन्छ।

Log discipline

तीन बानीहरू निर्माण गर्न लायक:

हरेक महत्त्वपूर्ण सीमामा log गर्नुहोस्। हरेक request start, हरेक stage संक्रमण, हरेक असफलता। हरेक function call मा एउटा होइन — तर हरेक अर्थपूर्ण घटना।
आयामहरू log गर्नुहोस्, narratives होइन। {"latency_ms": 1240, "endpoint": "/summarise"} queryable छ। "summarise गर्न लामो समय लाग्यो" छैन।
हप्तामा आफ्नो logs हेर्नुहोस्। 20 भर्खरका requests को scan मा पनि patterns प्रकट हुन्छन्। प्रयोगकर्ताहरू के सोध्दैछन्? के slow छ? के असफल हुँदैछ? logs पढ्ने बानी जहाँ operational insight बस्दछ।

आफ्नो बुझाइ जाँच्नुहोस्

Quick check

—

एक प्रयोगकर्ताले report गर्दछन् कि तिनीहरूको chatbot ले एक घण्टा अघि विशिष्ट नीति बारे पूर्णतया गलत जानकारी दियो। यीमध्ये कुन तपाईंलाई वास्तवमा जाँच गर्न सक्षम बनाउँछ?

प्रयोगकर्तालाई विश्वास गर्नुहोस् र FAQ update गर्नुहोस्।
Structured logs जुन request ID, user ID, timestamp, पूर्ण input, retrieved documents (IDs र similarity scores सँग), पूर्ण output, र model version समावेश गर्दछन्। ती दिइएमा, तपाईंले ठ्याक्कै के भयो पुनर्निर्माण गर्न सक्नुहुन्छ: कुन chunks retrieved थिए, मोडेल किन तिनीहरूमा latched भयो, र pipeline मा असफलता कहाँ बस्यो। ती बिना, तपाईं अनुमान गर्दै हुनुहुन्छ। हरेक interaction लाई structured fields सँग logging ले 'कसैले bot गलत भन्यो' लाई रहस्यबाट हल गर्न सकिने जाँच बनाउँछ।
प्रयोगकर्तालाई screenshot माग्नुहोस्।
उही query चलाउनुहोस् र यो फेरि असफल हुन्छ कि हेर्नुहोस्।

Quick check

—

नेपाली chatbot को लागि यीमध्ये कुन तपाईंले plaintext मा log गर्नुहुँदैन?

Request timestamps।
प्रयोगकर्ताको raw national ID number, phone number, वा auth token। यी PII (personally identifiable information) वा credentials हुन्, र तिनीहरूलाई plaintext मा logging ले compliance जोखिम र leak surface सिर्जना गर्दछ। सही pattern हो: sensitive fields लाई समूह गर्नको लागि hash गर्नुहोस् (sha256), वा तिनीहरूलाई mask गर्नुहोस् ('9841***456'), वा तिनीहरूलाई logs बाट पूर्ण रूपमा छोड्नुहोस्। हरेक log line एक सानो privacy निर्णय हो; PII encrypted data store मा हुनुपर्दछ, operational log stream मा होइन।
Endpoint नामहरू।
Model version।

अब के आउँछ

तपाईंसँग logs छन्। ठिक छ। तर logs एक haystack हुन् — needles तिनीहरूमा लुक्दछन्। अर्को खण्ड metrics र dashboards हो: aggregated signals को सानो संख्या जुन तपाईंलाई एक नजरमा आफ्नो प्रणालीको स्वास्थ्य देख्न दिन्छ, र जब केही गलत हुन्छ alarm सेट गर्न दिन्छ।