Observability & Evals untuk LLM di Produksi: Tutorial Praktis Tracing dan Scoring dengan Langfuse

Agent AI Anda jalan di production, tapi Anda tidak tahu apa yang dia lakukan, berapa biayanya, dan apakah output-nya masih bagus. Itu bukan observability — itu doa. Tutorial ini membangun fondasi LLMOps yang sebenarnya: tracing end-to-end dengan Langfuse, evaluasi otomatis dengan LLM-as-a-judge, dan eval gate di CI yang memblokir deploy kalau kualitas turun.

Masalah yang Tidak Ditemukan di Dashboard Biasa

Bayangkan Anda sudah mendeploy chatbot customer service berbasis LLM untuk klien. Seminggu berjalan, tiket komplain naik: bot menjawab ngawur, kadang mengarang kebijakan refund yang tidak pernah ada. Anda buka dashboard APM — CPU aman, latency aman, error rate nol. Semua hijau. Tapi bisnisnya berdarah.

Itulah jurang antara observabilitas tradisional dan observabilitas LLM. APM klasik menjawab pertanyaan "apakah sistemnya hidup?" Observabilitas LLM menjawab pertanyaan yang jauh lebih sulit: "apakah sistemnya benar, konsisten, dan masih sebanding dengan biayanya?"

Output LLM bersifat probabilistik. Prompt yang sama bisa menghasilkan jawaban bagus hari ini dan jawaban ngawur besok setelah provider mengupdate model di balik layar. Retrieval bisa diam-diam memburuk karena dokumen baru yang masuk ke knowledge base. Biaya token bisa meledak karena satu agent loop yang tidak sengaja memanggil model 40 kali per request. Tidak ada satu pun dari masalah ini yang muncul sebagai error 500.

Menurut analisis Confident AI yang diperbarui awal Oktober 2026, Gartner memprediksi bahwa pada 2028 investasi observabilitas LLM akan mencapai 50% dari seluruh deployment GenAI — naik dari 15% di awal 2026. Kategori ini terbelah menjadi dua: tool yang sekadar menghitung token, dan tool yang memperlakukan kualitas output sebagai sinyal utama. Tutorial ini membangun yang kedua.

Di akhir tutorial, Anda akan punya:

1. Tracing end-to-end untuk setiap request LLM: prompt, retrieval, tool call, latency, dan biaya per trace.
2. Evaluasi otomatis (LLM-as-a-judge) yang memberi skor setiap jawaban produksi.
3. Eval gate di CI yang menggagalkan merge request kalau kualitas model turun.
4. Flywheel produksi-ke-eval: kegagalan di produksi otomatis memperkaya dataset evaluasi Anda.

Prasyarat: Python 3.10+, Docker, dan pemahaman dasar tentang cara memanggil LLM API. Kita pakai Langfuse (open-source, MIT, bisa self-host) sebagai tulang punggung, karena ia menggabungkan tracing dan eval dalam satu platform dan menerima span OpenTelemetry.

Tiga Pilar Observabilitas LLM

Sebelum menyentuh kode, samakan dulu mental model-nya. Observabilitas LLM berdiri di atas tiga pilar:

1. Tracing: "Apa yang sebenarnya terjadi?"

Satu request user ke aplikasi AI modern bukan satu panggilan API. Ia adalah rantai: klasifikasi intent → retrieval dari vector DB → reranking → pemanggilan LLM pertama → tool call ke API internal → pemanggilan LLM kedua untuk merangkum. Kalau jawaban akhirnya salah, Anda harus bisa menelusuri rantai ini langkah demi langkah untuk tahu di mana letak kegagalannya: apakah retrieval-nya yang mengambil dokumen salah, atau modelnya yang mengabaikan konteks yang benar?

Tracing merekam setiap langkah sebagai span yang bersarang, lengkap dengan input, output, latency, dan jumlah token. Tanpa ini, debugging aplikasi LLM sama seperti debugging microservice tanpa distributed tracing: menebak-nebak.

2. Evals: "Apakah output-nya bagus?"

Inilah pilar yang tidak punya padanan di software tradisional. Di software biasa, benar/salah itu deterministik: unit test lolos atau gagal. Di LLM, "bagus" itu bergradasi. Evaluasi (evals) adalah cara sistematis memberi skor pada output model — bisa dengan aturan deterministik (apakah jawaban mengandung format JSON valid?), dengan model lain sebagai juri (LLM-as-a-judge: "beri skor 1-5 untuk relevansi jawaban ini"), atau dengan manusia sebagai penilai akhir.

Evals berjalan di dua tempat: offline (sebelum deploy, di CI, membandingkan prompt baru vs prompt lama pada dataset tetap) dan online (di produksi, memberi skor pada sampel trace nyata secara asinkron).

3. Cost & Latency Monitoring: "Apakah ini masih masuk akal?"

Setiap token adalah uang. Agent yang melakukan 30 langkah reasoning per request bisa 50x lebih mahal dari single-call. Tanpa monitoring biaya per fitur, per user, dan per model, tagihan API adalah kotak hitam sampai akhir bulan. Pilar ini biasanya diimplementasikan sebagai agregasi di atas data tracing: karena setiap span sudah mencatat token dan model, biaya tinggal dihitung dari tabel harga.

Lanskap Tooling 2026: Pilih Senjata Anda

Ekosistem tooling observabilitas LLM sudah matang di 2026. Berikut peta yang dirangkum dari beberapa indeks tooling terbaru (termasuk indeks DEV Community Agustus 2026 dan panduan Confident AI Oktober 2026):

Pola yang dipakai banyak tim produksi di 2026 — termasuk yang didokumentasikan Teamvoy untuk stack fintech mereka pada Oktober 2026 — adalah kombinasi: Promptfoo atau RAGAS untuk evals, Langfuse self-hosted atau LangSmith untuk tracing, dan Grafana/Prometheus untuk dashboard. Disiplinnya lebih penting dari tool-nya: eval set harus di-versioning, dimiliki seseorang, dan di-sign-off setiap rilis.

Satu pergeseran arsitektur terbesar sejak 2024 adalah konvergensi ke OpenTelemetry (OTel). Industri menyepakati konvensi semantik untuk span LLM — nama atribut standar untuk input, output, token, dan latency. Artinya Anda bisa instrumentasi sekali, lalu mengarahkan telemetri ke backend mana pun hanya dengan mengganti konfigurasi exporter. Langfuse kini punya endpoint ingesti OTel, dan Phoenix bersifat OTel-native sejak awal.

Tutorial ini memakai Langfuse karena tiga alasan praktis: open-source sehingga bisa jalan di laptop Anda hari ini juga, menggabungkan tracing dan eval dalam satu UI, dan dokumentasinya cukup matang untuk pola produksi.

Bagian 1: Menyalakan Langfuse dalam 5 Menit

Kita mulai dengan Langfuse self-hosted via Docker. Ini memberi Anda UI tracing lengkap tanpa mengirim satu byte pun data ke pihak ketiga — penting kalau Anda menangani data klien.

# Clone dan jalankan Langfuse
git clone https://github.com/langfuse/langfuse.git
cd langfuse
docker compose up -d

Buka `http://localhost:3000`, buat akun, lalu buat project dan ambil **Public Key** dan **Secret Key** dari Settings. Kita akan membutuhkannya sebagai environment variable:

```bash
export LANGFUSE_PUBLIC_KEY="pk-lf-..."
export LANGFUSE_SECRET_KEY="sk-lf-..."
export LANGFUSE_HOST="http://localhost:3000"

Install SDK Python:

pip install langfuse openai

SDK Langfuse v3 memakai dekorator dan context manager yang rapi. Mari kita bangun aplikasi contoh: asisten CS sederhana dengan retrieval, lalu instrumentasikan setiap langkahnya.

Bagian 2: Instrumentasi Aplikasi — Dari Kotak Hitam ke Kaca Transparan

Bayangkan aplikasi asisten CS berikut. Tanpa observabilitas, ia terlihat seperti ini:

from openai import OpenAI

client = OpenAI()

def jawab_pertanyaan(query: str, dokumen: list[str]) -> str:
    konteks = "\n".join(dokumen)
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "Kamu asisten CS. Jawab HANYA berdasarkan konteks."},
            {"role": "user", "content": f"Konteks:\n{konteks}\n\nPertanyaan: {query}"},
        ],
    )
    return resp.choices[0].message.content

Fungsi ini bekerja, tapi buta: kalau jawabannya salah, Anda tidak tahu apakah masalahnya di retrieval dokumen atau di modelnya. Sekarang versi terinstrumentasi dengan Langfuse:

import os
from langfuse import observe, get_client
from openai import OpenAI

client = OpenAI()
langfuse = get_client()  # membaca kredensial dari environment

@observe()
def retrieval(query: str) -> list[str]:
    # Simulasi retrieval dari vector DB (di produksi: pgvector/Weaviate + reranker)
    docs = cari_dokumen_relevan(query)
    # Catat skor retrieval sebagai metadata span
    langfuse.update_current_span(
        metadata={"num_docs": len(docs), "top_score": docs[0]["score"] if docs else 0}
    )
    return [d["text"] for d in docs]

@observe()
def generate_jawaban(query: str, konteks: str) -> str:
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "Kamu asisten CS. Jawab HANYA berdasarkan konteks."},
            {"role": "user", "content": f"Konteks:\n{konteks}\n\nPertanyaan: {query}"},
        ],
    )
    # Langfuse otomatis mencatat token usage dari response OpenAI
    return resp.choices[0].message.content

@observe(name="cs-assistant-request")
def jawab_pertanyaan(query: str, user_id: str) -> str:
    langfuse.update_current_trace(user_id=user_id, tags=["cs-assistant", "v1"])
    dokumen = retrieval(query)
    konteks = "\n".join(dokumen)
    jawaban = generate_jawaban(query, konteks)
    return jawaban

# Setiap panggilan kini menghasilkan satu trace lengkap di dashboard
print(jawab_pertanyaan("Bagaimana cara refund tiket?", user_id="user-123"))
langfuse.flush()

Buka dashboard Langfuse → Traces. Anda akan melihat satu trace cs-assistant-request berisi dua span bersarang: retrieval dan generate_jawaban. Klik span generate_jawaban: input prompt lengkap, output mentah, jumlah token input/output, latency, dan estimasi biaya — semuanya terekam otomatis.

Tiga praktik yang membedakan instrumentasi amatir dan profesional:

1. Beri nama trace yang bermakna dan sertakan user_id + session_id. Ini memungkinkan Anda menelusuri seluruh perjalanan satu user, bukan sekadar request anonim.
2. Versioning prompt. Jangan hardcode prompt di kode. Simpan prompt di Langfuse Prompt Management dengan label versi (v1, v2), lalu ambil saat runtime. Ketika kualitas turun, Anda bisa membandingkan performa antar versi prompt pada data yang sama.
3. Catat skor retrieval sebagai metadata. Banyak kegagalan RAG berasal dari retrieval yang buruk, bukan dari model. Kalau span retrieval mencatat top_score rendah dan jawaban akhirnya salah, diagnosisnya jelas dalam sekali lihat.

OTel-Native: Instrumentasi Sekali, Backend Bebas Ganti

Kalau tim Anda sudah standar pada OpenTelemetry, Anda tidak perlu mengunci diri ke SDK Langfuse. Kirim span OTel standar ke endpoint ingesti OTel Langfuse, dan telemetri yang sama bisa di-route ke Phoenix, Datadog, atau backend lain hanya dengan mengganti exporter. Ini adalah pola yang direkomendasikan untuk tim yang mengelola banyak layanan: satu instrumentasi, banyak tujuan.

Bagian 3: Evals — Memberi Nilai pada Output Model

Tracing memberi tahu Anda apa yang terjadi. Evals memberi tahu Anda apakah itu bagus. Ada tiga pendekatan eval, dari yang termurah ke yang termahal:

1. Eval deterministik (gratis, cepat). Aturan kode biasa: apakah output JSON valid? Apakah jawaban mengandung nomor tiket? Apakah panjang jawaban di bawah 500 karakter? Ini murah dan harus menjadi lapisan pertama.

2. LLM-as-a-judge (mahal sedikit, sangat fleksibel). Model lain menilai output model utama berdasarkan rubrik. Inilah workhorse eval modern: ia bisa menilai relevansi, nada, dan kepatuhan terhadap kebijakan — hal yang tidak bisa dijangkau regex.

3. Human review (mahal, paling akurat). Sampel kecil dari produksi dinilai manusia. Hasilnya menjadi golden dataset — kebenaran dasar untuk mengkalibrasi dua lapisan di atasnya.

Mari implementasikan lapisan 2: scoring otomatis setiap jawaban produksi dengan Langfuse. Polanya: trace selesai → worker asinkron memberi skor → skor tampil di dashboard dan bisa memicu alert.

from langfuse import get_client

langfuse = get_client()
judge = OpenAI()  # bisa juga model berbeda/lebih murah untuk judging

RUBRIK = """Kamu evaluator kualitas jawaban customer service.
Beri skor 1-5 untuk JAWABAN berikut berdasarkan PERTANYAAN dan KONTEKS.

Kriteria:
- 5: Akurat, sepenuhnya didukung konteks, nada sopan, langsung menjawab
- 4: Benar tapi bertele-tele atau kurang lengkap sedikit
- 3: Sebagian benar, ada informasi tidak didukung konteks
- 2: Mayoritas tidak didukung konteks (halusinasi ringan)
- 1: Halusinasi berat atau sama sekali tidak menjawab

Balas HANYA dengan format: SKOR: <angka> | ALASAN: <satu kalimat>
"""

def nilai_trace(trace_id: str, query: str, konteks: str, jawaban: str):
    penilaian = judge.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": f"{RUBRIK}\n\nPERTANYAAN: {query}\n\nKONTEKS: {konteks}\n\nJAWABAN: {jawaban}"}],
    ).choices[0].message.content

    skor = int(penilaian.split("SKOR:")[1].split("|")[0].strip())
    alasan = penilaian.split("ALASAN:")[1].strip()

    # Tempel skor ke trace yang sudah ada
    langfuse.create_score(
        trace_id=trace_id,
        name="kualitas-jawaban",
        value=skor,
        comment=alasan,
    )
    return skor

Di produksi, fungsi ini dipanggil oleh worker background (Celery, RQ, atau sekadar thread pool) untuk setiap trace baru — bukan di request path, agar tidak menambah latency ke user. Di dashboard Langfuse, tab Scores kini menampilkan distribusi skor dari waktu ke waktu. Ketika rata-rata skor `kualitas-jawaban` turun di bawah ambang (misalnya 3.5) dalam 1 jam terakhir, Anda pasang alert ke Slack. Inilah bedanya monitoring reaktif dan proaktif: Anda tahu kualitas turun *sebelum* komplain menumpuk.

**Tips kalibrasi yang sering dilewatkan:** LLM-as-a-judge punya bias — ia cenderung memberi skor tinggi pada jawaban panjang dan pada gaya bahasanya sendiri. Kalibrasikan dengan 50-100 sampel yang dinilai manusia terlebih dahulu, ukur korelasinya, dan sesuaikan rubrik sampai korelasinya memuaskan. Judge yang tidak dikalibrasi lebih berbahaya daripada tidak ada judge sama sekali, karena ia memberi rasa aman yang palsu.

## Bagian 4: Eval Gate di CI — Jangan Biarkan Kualitas Mundur Diam-Diam

Evals online menangkap masalah di produksi. Tapi masalah yang lebih murah dicegah adalah regresi yang *Anda* perkenalkan sendiri: mengganti model ke versi lebih murah, mengubah prompt, atau menambah dokumen baru ke knowledge base — lalu kualitas turun 10% tanpa ada yang sadar sampai berminggu-minggu.

Solusinya: **eval gate di CI**. Setiap perubahan prompt atau model harus melewati dataset evaluasi tetap sebelum boleh merge. Pola ini dipopulerkan tool seperti DeepEval (evals gaya pytest) dan Promptfoo, dan didukung penuh oleh Langfuse Datasets.

Langkahnya:

**1. Bangun golden dataset.** Kumpulkan 50-200 pasang pertanyaan-jawaban ideal dari tiga sumber: kasus nyata yang sering muncul, kegagalan produksi yang sudah diperbaiki manusia, dan edge case yang Anda takutkan. Simpan di Langfuse sebagai Dataset — setiap item punya input, expected output, dan metadata.

**2. Tulis eval sebagai test.** Contoh dengan pendekatan generik (bisa diadaptasi ke DeepEval/Promptfoo):

```python
# test_evals.py — dijalankan di CI setiap ada perubahan prompt/model
import pytest
from langfuse import get_client

langfuse = get_client()
dataset = langfuse.get_dataset("cs-golden-v1")

@pytest.mark.parametrize("item", dataset.items)
def test_kualitas_jawaban(item):
    jawaban = jawab_pertanyaan(item.input["query"], user_id="eval-ci")
    skor = nilai_dengan_judge(item.input["query"], jawaban, item.expected_output)
    assert skor >= 4, f"Regresi kualitas pada '{item.input['query']}': skor {skor}"

3. Bandingkan antar versi, bukan sekadar lolos/gagal. Praktik terbaik 2026 bukan binary pass/fail, melainkan eksperimen: jalankan dataset yang sama terhadap prompt v1 dan v2, lalu bandingkan skor agregatnya di dashboard. Keputusan "apakah v2 lebih baik dari v1" menjadi berbasis data, bukan firasat.

4. Blokir merge kalau turun. Di GitHub Actions/GitLab CI, jadikan job eval sebagai required check. Prompt baru yang menurunkan skor rata-rata dari 4.3 ke 3.8 tidak boleh merge — sama seperti test yang gagal.

Biaya menjalankan eval suite ini? Untuk 100 item × judge call murah, biayanya recehan per run CI. Bandingkan dengan biaya satu insiden kualitas di produksi. Ini adalah asuransi termurah di stack AI Anda.

Bagian 5: Flywheel — Produksi yang Membuat Eval Anda Makin Pintar

Pola paling matang yang muncul di 2026 adalah production-to-eval flywheel: sistem evaluasi yang memperbaiki dirinya sendiri dari data produksi.

Alurnya:

1. Setiap trace produksi diberi skor asinkron oleh LLM-as-a-judge.
2. Trace dengan skor rendah otomatis masuk antrean review manusia.
3. Reviewer manusia mengoreksi: mana jawaban yang benar, di mana letak kesalahannya (retrieval? prompt? model?).
4. Kasus yang terkonfirmasi menjadi item baru di golden dataset.
5. CI eval gate kini melindungi dari regresi pada kasus nyata tersebut — selamanya.

Dataset evaluasi Anda tidak lagi statis sejak hari peluncuran. Ia tumbuh mengikuti pola kegagalan nyata. Tim yang menjalankan flywheel ini melaporkan efek kompon: setiap bulan, kategori kegagalan yang sama semakin jarang muncul karena eval gate menangkapnya sebelum deploy.

Implementasi minimalnya sederhana: query Langfuse API untuk trace dengan skor di bawah ambang dalam 7 hari terakhir, tampilkan di internal tool sederhana untuk review, dan satu klik untuk "promosikan ke dataset". Tidak perlu platform mahal — yang dibutuhkan adalah disiplin menjalankannya tiap sprint.

Bagian 6: Checklist Produksi — Dari Tutorial ke Operasional

Sebelum menutup, berikut checklist yang bisa langsung ditempel di Notion tim Anda:

Instrumentasi

• Setiap request LLM menghasilkan satu trace dengan nama bermakna
• user_id dan session_id selalu terisi untuk penelusuran lintas request
• Prompt di-versioning (bukan hardcode), bisa di-rollback dalam 1 menit
• Metadata retrieval (skor, jumlah dokumen) tercatat di span
• Token usage dan estimasi biaya tercatat per trace

Evaluasi

• Golden dataset 50+ item, di-versioning, dimiliki seseorang
• Eval deterministik untuk format dan aturan keras
• LLM-as-a-judge terkalibrasi dengan sampel human review
• Scoring online berjalan asinkron di produksi dengan alert ambang batas
• Eval gate di CI memblokir merge saat kualitas turun

Operasional

• Dashboard biaya per fitur/model/user, direview tiap sprint
• Flywheel review mingguan: skor rendah → review manusia → dataset bertambah
• Runbook untuk "skor turun tiba-tiba": cek urutan prompt → model → retrieval → data
• Data residency jelas: self-host kalau menangani data sensitif (Langfuse/Phoenix bisa on-prem)

Studi Kasus Mini: Ketika Provider Mengganti Model Diam-Diam

Maret 2026 — sebuah tim SaaS di Jakarta bangun pagi dengan inbox penuh komplain: chatbot mereka tiba-tiba menjawab dengan nada kaku dan sering menolak pertanyaan yang kemarin dijawab dengan baik. Tidak ada deploy semalam. Tidak ada perubahan kode. Dashboard APM hijau semua.

Karena mereka sudah punya tracing + scoring online seperti di tutorial ini, diagnosisnya memakan waktu 20 menit, bukan 2 hari. Grafik skor kualitas-jawaban di Langfuse menunjukkan penurunan tajam mulai pukul 02:00 WIB. Filter trace pada rentang itu memperlihatkan satu pola: semua trace buruk memakai model version yang berbeda — provider telah melakukan rolling update pada model yang mereka pakai, mengubah perilakunya tanpa pengumuman.

Solusinya: pin versi model secara eksplisit di setiap panggilan (bukan memakai alias latest), dan tambahkan eval canary — subset kecil golden dataset yang dijalankan otomatis setiap jam terhadap model produksi. Kalau skor canary turun >10% dalam 2 jam, pager berbunyi sebelum user sempat komplain. Sejak itu, mereka tidak pernah lagi "dibohongi" update diam-diam.

Pelajaran umumnya: di era LLM, dependensi Anda bisa berubah tanpa Anda mengganti apa pun. Observabilitas adalah satu-satunya cara untuk tahu.

Kesalahan Umum yang Sering Ditemui Tim Indonesia

1. Mencatat prompt tapi tidak mencatat versi model. Trace yang menyimpan prompt lengkap tapi tidak menyimpan model="gpt-4o-mini-2026-03-01" (dengan tanggal versi) tidak bisa direproduksi. Selalu catat model + versinya di setiap span generasi.

2. Judge menilai tanpa konteks retrieval. Memberi skor jawaban tanpa menunjukkan dokumen yang diambil saat retrieval adalah kesalahan fatal untuk RAG: Anda tidak bisa membedakan "model mengarang" dari "retrieval mengambil dokumen salah". Judge harus selalu menerima triple: query, konteks yang diambil, jawaban.

3. Eval dataset hanya berisi kasus bahagia. Kalau golden dataset Anda semuanya pertanyaan mudah yang sudah pasti benar, eval gate tidak akan pernah menangkap apa pun. Aturan praktis: minimal 30% dataset harus berisi kasus yang pernah gagal di produksi.

4. Alert tanpa runbook. Skor turun, Slack berbunyi, lalu tidak ada yang tahu harus ngapain. Setiap alert harus ditempeli runbook 5 langkah: cek versi prompt → cek versi model → cek distribusi skor retrieval → cek perubahan data/knowledge base → rollback bila perlu.

5. Mengukur biaya di akhir bulan. Tagihan API yang baru dilihat 30 hari kemudian sudah terlambat untuk dioptimasi. Agregasi biaya per trace memungkinkan Anda melihat hari ini juga bahwa fitur X menghabiskan 70% budget token — dan memutuskan apakah agent 30-langkah itu benar-benar sepadan.

Penutup: Observabilitas Adalah Fitur, Bukan Aksesori

Ada godaan untuk menganggap observabilitas sebagai "nanti saja, setelah fiturnya jadi". Di software tradisional, itu masih bisa dimaklumi. Di sistem LLM, itu adalah cara tercepat menuju insiden yang tidak bisa Anda jelaskan — ke user, ke klien, apalagi ke regulator.

Kabar baiknya: fondasinya tidak mahal. Satu container Docker Langfuse, beberapa dekorator @observe(), satu rubrik judge yang terkalibrasi, dan satu job CI. Total waktu implementasi untuk pola di tutorial ini: sekitar satu hari kerja untuk tim kecil. Bandingkan dengan waktu yang Anda habiskan menebak-nebak kenapa bot "tiba-tiba jadi bodoh" minggu lalu.

Mulailah dari tracing — karena Anda tidak bisa memperbaiki apa yang tidak bisa Anda lihat. Tambahkan evals begitu trace mengalir. Tutup loop-nya dengan flywheel. Tiga bulan dari sekarang, Anda akan punya sesuatu yang langka di 2026: sistem AI yang kualitasnya terukur, bukan sekadar diharapkan.

Artikel ini bagian dari seri engineering AI praktis di Vechcode. Di artikel sebelumnya, kita membangun RAG end-to-end dengan pgvector — tracing dan evals di artikel ini adalah lapisan berikutnya yang membuat RAG tersebut layak produksi.