Belajar AI Engineer - Observability & Monitoring AI

#Pendahuluan

Sistem yang kalian bangun semakin kompleks: agent multi-langkah, RAG, memory, tool calls. Dan di episode 11, kita katakan debugging agent butuh tracing. Episode ini memenuhi janji itu — observability & monitoring AI, lapisan yang menentukan apakah tim bisa tidur nyenyak setelah deploy.

Mengapa penting? Karena produk AI punya masalah yang tidak dimiliki aplikasi biasa: perilaku nondeterministik. Error bukan hanya "500" — bisa berupa jawaban salah, biaya melonjak, atau agent berputar tanpa selesai. Tanpa observability yang tepat, kalian buta: tidak tahu mengapa biaya membengkak, request mana yang lambat, atau jawaban mana yang mulai menurun kualitasnya.

#Apa yang Harus Diukur

Observability produk AI terbagi tiga dimensi:

Tiga pertanyaan yang harus bisa kalian jawab kapan saja: kenapa lambat?, kenapa mahal?, dan kualitasnya turun di mana?

#Tracing: Melihat Tiap Langkah

Trace adalah catatan perjalanan satu request: berapa langkah, tool apa yang dipanggil, berapa lama tiap langkah, berapa token. Standar industri adalah OpenTelemetry (OTel) dengan instrumentasi eksplisit:

Tracing dengan OpenTelemetry

from opentelemetry import trace
from opentelemetry.trace import Status, StatusCode
 
tracer = trace.get_tracer("ai-app")
 
def run_agent(task: str) -> str:
    with tracer.start_as_current_span("agent.run") as span:
        span.set_attribute("task", task)
        try:
            langkah1 = retrieve(task)       # RAG
            jawaban = generate(langkah1)    # LLM
            span.set_attribute("docs_used", len(langkah1))
            return jawaban
        except Exception as e:
            span.set_status(Status(StatusCode.ERROR, str(e)))
            raise

Setiap span menyimpan konteks: nama operasi, durasi, token, dan attribute khusus. Di dashboard (Jaeger/Tempo/Cloud), kalian bisa melihat request yang lambat dan langkah mana penyebabnya.

#Cost Tracking: Token Adalah Uang

Setiap panggilan LLM harus tercatat biayanya. Pola dasarnya: baca usage dari response (episode 3), hitung biaya dengan harga model, simpan ke time-series:

Catat cost setiap panggilan LLM

PRICES = {"gpt-4o-mini": (0.00015, 0.0006)}  # input, output per 1K token
 
def log_cost(model: str, usage, user_id: str, feat: str) -> None:
    pi, po = PRICES[model]
    cost = (usage.prompt_tokens / 1000) * pi + \
           (usage.completion_tokens / 1000) * po
    emit_metric("llm.cost", cost,
                {"model": model, "user": user_id, "feature": feat})
    emit_metric("llm.tokens_in", usage.prompt_tokens, {"model": model})
    emit_metric("llm.tokens_out", usage.completion_tokens, {"model": model})

Data cost per feature memungkinkan pertanyaan penting: "fitur mana yang menyumbang 70% biaya?" — jawaban yang memandu optimasi di episode 22. Data cost per user memicu abuse detection: satu pengguna tiba-tiba memakai 100x rata-rata.

#LangSmith: Observability Khusus AI

Framework AI (LangChain/LangGraph, yang kita pakai mulai episode 23) punya tool observability khusus: LangSmith. Ia otomatis mencatat setiap panggilan LLM, prompt, tool call, dan metadata — tanpa instrumentasi manual:

export LANGSMITH_TRACING=true
export LANGSMITH_API_KEY=lsv2_...
export LANGSMITH_PROJECT=ai-engineer-lab

Trace otomatis via LangSmith

from langsmith import traceable
 
@traceable
def jawab_dokumen(question: str) -> str:
    docs = retrieve(question)      # otomatis tercatat
    return generate(docs, question)  # otomatis tercatat

LangSmith juga punya evaluator bawaan: feedback loop, banding jawaban antar versi, dan dataset management yang nyambung dengan eval suite episode 9. Untuk tim yang memakai LangGraph (episode 23), ini pilihan paling cepat.

#Monitoring Kualitas: Feedback dan Drift

Observability tidak berhenti di metrik teknis. Kualitas jawaban harus dipantau:

• Feedback pengguna: tombol 👍/👎 di UI → jadi data evaluasi (konversi ke metrik approval rate per fitur).
• Sampling eval otomatis: 5-10% request dijalankan lewat LLM-as-judge (episode 9) secara asinkron — tidak menambah latensi request utama.
• Drift detection: jika skor faithfulness turun drastis, bisa jadi sumber dokumen berubah, model penyedia berubah diam-diam, atau prompt berubah.

Sampling eval di produksi

import random
 
def after_answer(question, konteks, jawaban):
    if random.random() < 0.05:  # sampel 5%
        skor = llm_judge(question, konteks, jawaban)  # episode 9
        emit_metric("qa.faithfulness", skor["faithfulness"], {})

#Common Pitfalls

• Observability ditambahkan belakangan: integrasi OTel/LangSmith di akhir proyek itu sulit dan menyakitkan. Pasang sejak prototipe.
• Hanya metrik teknik: token dan latensi tanpa kualitas = produk yang "berjalan" tapi mungkin buruk.
• Log tanpa konteks: log "call failed" tanpa prompt/model/user tidak berguna untuk debug.
• Tanpa alert: metrik tanpa alert berarti tidak ada yang tahu saat terjadi masalah. Alert dasar: cost spike, error rate naik, latensi p99 memburuk.

#Penutup

Inti yang harus dibawa pulang:

• Ukur tiga dimensi: performance, cost, quality.
• Tracing (OTel) mencatat span per langkah agent — llm.call, retrieval, tool.call.
• Cost tracking per user dan per fitur memandu optimasi dan mendeteksi abuse.
• LangSmith memberi observability + evaluasi bawaan untuk stack LangChain/LangGraph.

Di episode 18 selanjutnya kita mengamankan semuanya: AI security & safety — prompt injection, jailbreaks, data leakage, dan OWASP LLM Top 10 untuk produk AI. Sampai jumpa di episode 18!