Panduan Arsitektur: Continuous Evaluation Harnesses for Production — Bagaimana Menerapkannya Secara Efisien?

Ringkasan: Mengandalkan pengujian pass/fail tradisional untuk agen AI di tahap produksi adalah resep menuju kegagalan sistemik. Untuk mencegah regresi, lonjakan latensi, dan pelanggaran keamanan, arsitektur Continuous Evaluation modern harus menggabungkan AST (Abstract Syntax Tree) Gates yang deterministik dengan Trajectory Evaluations—memvalidasi bukan hanya apakah agen memberikan jawaban yang benar, tetapi bagaimana agen tersebut mengambil keputusan dan mengeksekusi tool di setiap langkahnya.

Dalam arsitektur perangkat lunak tradisional, kita memiliki kontrak yang jelas antara kode dan ekspektasi. Jika kita menulis sebuah fungsi untuk menghitung pajak, kita dapat menulis unit test yang memberikan input spesifik dan mengharapkan output yang identik setiap saat. Paradigma ini telah menjadi fondasi dari praktik Continuous Integration/Continuous Deployment (CI/CD) selama beberapa dekade. Namun, ketika kita mulai mengintegrasikan agen AI otonom ke dalam critical path sistem produksi, kontrak deterministik ini hancur.

Kita sering melihat fenomena ini di lapangan: sebuah prototipe agen AI berfungsi dengan sempurna di lingkungan sandbox. Agen tersebut mampu merespons prompt pengguna, memanggil API internal, dan merangkum data dengan akurasi yang mengesankan. Namun, saat dideploy ke produksi dan dihadapkan pada variabilitas traffic dunia nyata, agen tersebut mulai menunjukkan perilaku anomali. Ia mungkin mengalami looping tanpa akhir saat memanggil tool, berhalusinasi parameter API yang tidak ada, atau mengambil rute eksekusi yang sangat tidak efisien yang menghancurkan unit economics dari sistem tersebut.

Akar masalahnya bukan pada model bahasanya itu sendiri, melainkan pada bagaimana kita mengevaluasi dan memberikan guardrails pada sistem yang pada dasarnya bersifat probabilistik.

Ilusi Pengujian Deterministik pada Sistem Probabilistik

Ketika tim engineering pertama kali memigrasikan agen AI dari tahap Proof of Concept (PoC) ke produksi, insting pertama mereka adalah menerapkan metodologi pengujian yang sudah mereka kenal. Mereka menulis assertions yang memeriksa apakah respons akhir dari agen mengandung kata kunci tertentu atau cocok dengan format JSON yang diharapkan.

Pendekatan ini sejalan dengan prinsip-prinsip dasar dalam Well-Architected Framework: Reliability pillar, di mana kita dituntut untuk mendefinisikan keandalan berdasarkan metrik pengalaman pengguna dan membangun sistem yang dapat pulih dari kegagalan. Namun, pengujian pass/fail tradisional memiliki titik buta yang masif ketika diterapkan pada agen AI.

Model Large Language Models (LLM) tidak mengeksekusi logika secara linear. Mereka memprediksi token berikutnya berdasarkan probabilitas. Ini berarti, untuk input yang sama, agen AI mungkin mengambil jalur penalaran yang berbeda pada dua eksekusi yang berbeda. Pengujian deterministik hanya melihat hasil akhir (output), mengabaikan proses kognitif dan operasional yang terjadi di baliknya.

Seperti yang dijelaskan dalam dokumentasi Agent Development Kit (ADK) tentang evaluasi agen, LLM memperkenalkan tingkat variabilitas yang membuat pendekatan pengujian tradisional menjadi tidak memadai. Kita tidak bisa lagi hanya bergantung pada sinyal "lulus/gagal" yang biner.

Dilema "Jawaban Benar, Metode Salah"

Keterbatasan pengujian berbasis output menjadi sangat berbahaya ketika agen AI diberikan akses ke tools eksternal (API, database, sistem internal). Mari kita bedah sebuah skenario arsitektural:

Sebuah agen customer support ditugaskan untuk membatalkan pesanan pengguna dan mengembalikan dana.

• Ekspektasi: Agen memanggil get_order_status, lalu memanggil cancel_order, dan terakhir memanggil issue_refund.
• Realitas di Produksi: Agen memanggil get_order_status tiga kali berturut-turut karena kebingungan dengan format timestamp, berhalusinasi memanggil check_inventory (yang tidak relevan), dan akhirnya memanggil cancel_order dan issue_refund.

Jika kita hanya menguji hasil akhirnya—"Apakah pesanan dibatalkan dan dana dikembalikan?"—pengujian tradisional akan memberikan status PASS.

Namun, dari perspektif arsitektur sistem, eksekusi ini adalah sebuah bencana. Agen tersebut telah mengkonsumsi token ekstra untuk penalaran yang tidak perlu, meningkatkan latensi respons dari 2 detik menjadi 8 detik, dan membebani API internal dengan panggilan yang redundan. Dalam skala enterprise dengan jutaan requests, inefisiensi ini secara langsung melanggar prinsip-prinsip Well-Architected Framework: Cost optimization pillar, di mana optimalisasi penggunaan sumber daya secara berkelanjutan adalah mandat utama.

Ini adalah masalah Trajectory (lintasan). Kita tidak hanya peduli pada destinasi akhir; kita sangat peduli pada rute yang diambil agen untuk sampai ke sana.

Titik Buta dari LLM-as-a-Judge

Untuk mengatasi kelemahan pengujian biner, industri bergerak menuju pola LLM-as-a-Judge. Dalam pola ini, model LLM yang lebih besar dan lebih kuat (seperti Gemini 2.5 Pro atau Gemini 3.1 Pro-Preview) digunakan untuk mengevaluasi output dari agen produksi (yang mungkin berjalan di atas model yang lebih cepat seperti Gemini 2.5 Flash).

LLM-as-a-Judge diberikan rubrik evaluasi: "Apakah respons ini sopan? Apakah respons ini akurat berdasarkan konteks yang diberikan? Apakah tidak mengandung informasi sensitif?"

Meskipun pola ini secara signifikan meningkatkan kualitas evaluasi kualitatif, ia masih memiliki dua kelemahan fundamental jika digunakan sebagai satu-satunya mekanisme gatekeeping:

1. Biaya dan Latensi: Menjalankan evaluasi LLM penuh pada setiap commit kode atau setiap interaksi pengguna sangat mahal dan lambat. Ini menciptakan bottleneck dalam pipeline CI/CD.
2. Ketidakmampuan Menginspeksi Struktur: LLM-as-a-Judge sering kali hanya mengevaluasi teks akhir. Ia tidak secara inheren memahami struktur pemanggilan fungsi (AST) atau urutan tools yang dieksekusi di backend, kecuali jika seluruh trace log dimasukkan ke dalam prompt evaluasi (yang kembali meningkatkan biaya token secara eksponensial).

Kita membutuhkan mekanisme yang dapat memvalidasi struktur eksekusi secara deterministik sebelum kita melakukan evaluasi kualitatif yang mahal. Kita membutuhkan Continuous Evaluation Harnesses yang menggabungkan AST Gates dan Trajectory Evals.

Membangun Continuous Evaluation Harnesses: AST Gates & Trajectory Evals

Solusi arsitektural untuk masalah ini adalah dengan memisahkan evaluasi ke dalam beberapa lapisan (layer) yang berjenjang, dimulai dari yang paling deterministik dan murah, hingga yang paling probabilistik dan komprehensif. Inilah inti dari membangun agen produksi yang andal menggunakan framework modern seperti Agent Development Kit (ADK).

Seperti yang ditekankan dalam panduan persiapan evaluasi agen ADK, evaluasi agen harus dipecah menjadi dua komponen utama: mengevaluasi trajectory (penggunaan tool dan langkah-langkah penalaran) dan mengevaluasi respons akhir.

1. AST Gates (Abstract Syntax Tree Gates)

Sebelum agen AI benar-benar mengeksekusi sebuah tool atau API, model LLM akan menghasilkan representasi terstruktur dari niatnya (biasanya dalam bentuk JSON yang merepresentasikan pemanggilan fungsi).

AST Gates adalah lapisan validasi deterministik yang mem-parsing struktur JSON ini menjadi Abstract Syntax Tree dan memvalidasinya terhadap skema yang diizinkan (Pydantic models, OpenAPI specs) sebelum eksekusi terjadi.

Dalam pipeline CI/CD, AST Gates memastikan bahwa agen tidak pernah mencoba memanggil tool yang tidak ada, atau menggunakan parameter dengan tipe data yang salah. Ini adalah fail-fast mechanism. Jika agen mencoba memanggil issue_refund(amount="all") padahal skema mengharuskan amount berupa float, AST Gate akan langsung menggagalkan tes tersebut tanpa perlu memanggil LLM-as-a-Judge.

2. Trajectory Evals (Evaluasi Lintasan)

Trajectory adalah daftar langkah atau tindakan yang diambil agen sebelum mengembalikan respons kepada pengguna. Mengevaluasi kinerja agen membutuhkan perbandingan antara trajectory aktual yang diambil agen dengan trajectory yang diharapkan (ideal).

Dalam Trajectory Evals, kita mendefinisikan Ground Truth Trajectory. Misalnya, untuk intent "Reset Password", trajectory yang diharapkan adalah: [ToolCall(verify_identity), ToolCall(generate_reset_link), ToolCall(send_email)]

Saat agen dievaluasi dalam harness pengujian, kita menangkap trace eksekusinya dan membandingkannya dengan Ground Truth. Kita dapat menggunakan algoritma deterministik (seperti Levenshtein distance untuk urutan array) untuk memastikan agen tidak mengambil langkah yang berlebihan atau melewatkan langkah kritis.

Jika agen mengambil trajectory: [ToolCall(verify_identity), ToolCall(search_knowledge_base), ToolCall(generate_reset_link), ToolCall(send_email)]

Sistem evaluasi dapat memberikan penalti karena adanya pemanggilan search_knowledge_base yang tidak efisien, meskipun hasil akhirnya benar. Pendekatan ini memaksa agen untuk tidak hanya menjadi "benar", tetapi juga "efisien" dan "aman".

Arsitektur Topologi: Continuous Evaluation Pipeline

Berikut adalah representasi arsitektur dari Continuous Evaluation Harness yang mengimplementasikan AST Gates dan Trajectory Evals dalam pipeline CI/CD.

flowchart LR
    subgraph Ci_Cd_Pipeline["CI/CD Continuous Evaluation Harness"]
        direction TB
        A[Code Commit / Agent Update] --> B{AST Gate Validation}
        
        B -- "Schema Invalid" --> C[Fail Fast: Reject Commit]
        B -- "Schema Valid" --> D[Execute Agent in Sandbox]
        
        D --> E[Capture Execution Trace]
        E --> F{Trajectory Eval}
        
        F -- "Diverges from Ground Truth" --> G[Fail: Inefficient/Unsafe Path]
        F -- "Matches Expected Trajectory" --> H{LLM-as-a-Judge Eval}
        
        H -- "Low Quality / Hallucination" --> I[Fail: Qualitative Rejection]
        H -- "High Quality" --> J[Pass: Ready for Production]
    end
    
    subgraph Ground_Truth["Evaluation Datasets"]
        K[(Expected Trajectories)] -.-> F
        L[(Evaluation Rubrics)] -.-> H
    end
    
    style A fill:#2d3436,stroke:#dfe6e9,color:#fff
    style C fill:#d63031,stroke:#ff7675,color:#fff
    style G fill:#d63031,stroke:#ff7675,color:#fff
    style I fill:#d63031,stroke:#ff7675,color:#fff
    style J fill:#00b894,stroke:#55efc4,color:#fff
    style B fill:#0984e3,stroke:#74b9ff,color:#fff
    style F fill:#0984e3,stroke:#74b9ff,color:#fff
    style H fill:#6c5ce7,stroke:#a29bfe,color:#fff

Implementasi Kode Produksi: Trajectory Assertions dengan ADK

Untuk mengimplementasikan konsep ini secara nyata, kita menggunakan Agent Development Kit (ADK) yang menyediakan primitif bawaan untuk menangkap dan mengevaluasi trace eksekusi agen.

Berikut adalah contoh implementasi Python yang menunjukkan bagaimana kita menulis test case yang memvalidasi trajectory agen secara deterministik, memastikan agen memanggil tools dalam urutan yang tepat sebelum mengevaluasi respons akhirnya.

import asyncio
from google.adk import Agent
from google.adk.tools import function_tool
from google.adk.evaluate import Evaluator, TrajectoryAssertion

# 1. Definisikan Tools (Mock untuk testing)
@function_tool
def verify_user_identity(user_id: str) -> bool:
    """Verifies if the user is authenticated."""
    return True

@function_tool
def fetch_account_balance(user_id: str) -> dict:
    """Fetches the current account balance."""
    return {"balance": 5000.00, "currency": "USD"}

# 2. Inisialisasi Agen Produksi
financial_agent = Agent(
    name="FinOps_Assistant",
    model="gemini-2.5-flash", # Menggunakan model yang cepat dan efisien untuk routing
    instruction="You are a financial assistant. Always verify identity before fetching balance.",
    tools=[verify_user_identity, fetch_account_balance]
)

# 3. Definisikan Continuous Evaluation Test
async def run_trajectory_eval():
    evaluator = Evaluator(agent=financial_agent)
    
    # Definisikan input simulasi pengguna
    user_input = "What is the balance for user_id: 99812?"
    
    # Definisikan Ground Truth Trajectory (Urutan eksekusi yang diwajibkan)
    expected_trajectory = [
        TrajectoryAssertion(tool_name="verify_user_identity", expected_args={"user_id": "99812"}),
        TrajectoryAssertion(tool_name="fetch_account_balance", expected_args={"user_id": "99812"})
    ]
    
    # Eksekusi agen dalam mode evaluasi (menangkap trace)
    eval_result = await evaluator.run_test_case(
        input_text=user_input,
        expected_trajectory=expected_trajectory,
        enforce_exact_order=True # AST Gate: Urutan harus persis, tidak boleh ada tool ekstra
    )
    
    if eval_result.trajectory_passed:
        print("✅ Trajectory Eval Passed: Agent followed the exact secure execution path.")
        # Lanjutkan ke LLM-as-a-Judge untuk evaluasi kualitatif teks akhir
        # ...
    else:
        print(f"❌ Trajectory Eval Failed: {eval_result.trajectory_errors}")
        # Gagal di CI/CD pipeline, mencegah deployment agen yang tidak aman

if __name__ == "__main__":
    asyncio.run(run_trajectory_eval())

Kode di atas mendemonstrasikan pergeseran paradigma dari pengujian black-box menjadi pengujian white-box untuk agen AI. Dengan enforce_exact_order=True, kita menciptakan AST Gate yang ketat. Jika model LLM memutuskan untuk memanggil fetch_account_balance sebelum verify_user_identity (sebuah pelanggaran keamanan fatal), tes ini akan gagal secara deterministik dalam hitungan milidetik, tanpa perlu membuang token untuk LLM-as-a-Judge.

Use Case Nyata di Lapangan: Ide Implementasi Praktis

Bagaimana arsitektur Continuous Evaluation ini mengubah cara enterprise mengoperasikan agen AI di dunia nyata? Berikut adalah skenario implementasi di lapangan yang menunjukkan dampak langsung terhadap keandalan, keamanan, dan efisiensi biaya.

1. High-Throughput Enterprise Workloads: Mengisolasi P99 Tail-Latency

• Masalah Sehari-hari: Sebuah platform e-commerce mendeploy agen AI untuk menangani pertanyaan status pengiriman. Saat traffic memuncak (misalnya saat Harbolnas), latensi respons agen (P99) melonjak dari 2 detik menjadi 15 detik. Analisis menunjukkan bahwa agen sering terjebak dalam loop penalaran, memanggil API logistik berulang kali karena format respons API yang tidak konsisten, menghabiskan kuota rate-limit API internal.
• Cara Kerjanya di Praktik: Tim engineering mengimplementasikan Trajectory Evals di pipeline CI/CD. Mereka mendefinisikan aturan ketat: untuk intent "cek resi", agen diizinkan maksimal 2 pemanggilan tool. Jika agen mencoba memanggil tool logistik untuk ketiga kalinya, AST Gate di runtime akan memicu circuit breaker, menghentikan penalaran LLM, dan memaksa agen untuk mengembalikan respons fallback deterministik ("Sistem logistik sedang sibuk, mohon tunggu").
• Dampak Tangible: Penghapusan infinite loops secara deterministik. P99 tail-latency kembali stabil di bawah 3 detik bahkan saat burst traffic, dan penggunaan kuota API internal turun sebesar 40%, menjaga stabilitas sistem backend lainnya.

2. Zero-Trust Governance & Fault Isolation: Enforcing Least-Privilege

• Masalah Sehari-hari: Di sektor perbankan (FinTech), agen AI internal digunakan oleh staf Customer Service untuk merangkum profil risiko nasabah. Ketakutan terbesar CTO adalah agen tersebut dimanipulasi (prompt injection) untuk memanggil API transfer dana atau mengubah data nasabah, melampaui batas otorisasi yang seharusnya hanya untuk "membaca" data.
• Cara Kerjanya di Praktik: Arsitektur dirombak menggunakan Graph Workflows dari ADK. AST Gates diterapkan tidak hanya di CI/CD, tetapi juga sebagai middleware di produksi. Setiap kali agen menghasilkan JSON untuk memanggil tool, AST Gate memvalidasi nama tool terhadap kebijakan IAM (Identity and Access Management) yang diikat ke sesi pengguna saat itu. Trajectory Evals di CI/CD secara terus-menerus menguji agen dengan adversarial prompts untuk memastikan agen tidak pernah mencoba menghasilkan trajectory yang melanggar batas read-only.
• Dampak Tangible: Isolasi kesalahan (fault isolation) yang terjamin secara matematis. Bahkan jika model LLM berhalusinasi atau dimanipulasi untuk memanggil update_account_balance, AST Gate akan memblokir eksekusi di tingkat infrastruktur, memastikan kepatuhan penuh terhadap regulasi keamanan Zero-Trust.

3. Production FinOps & Unit Economics: Optimasi Biaya Evaluasi

• Masalah Sehari-hari: Tim AI menjalankan ribuan automated tests setiap malam untuk memastikan agen mereka tidak mengalami regresi. Mereka menggunakan model flagship (seperti Gemini 2.5 Pro) sebagai LLM-as-a-Judge untuk mengevaluasi setiap interaksi. Tagihan cloud bulanan untuk testing environment membengkak melebihi biaya produksi itu sendiri, merusak unit economics proyek AI.
• Cara Kerjanya di Praktik: Tim mengadopsi pendekatan evaluasi berjenjang (tiered evaluation). Lapisan pertama adalah AST Gates dan Trajectory Evals yang berjalan secara lokal atau di Cloud Run dengan biaya komputasi minimal. Lapisan ini memfilter 80% kegagalan (seperti salah panggil tool atau format JSON rusak) secara instan. Hanya test cases yang lulus Trajectory Eval yang diteruskan ke lapisan kedua: LLM-as-a-Judge menggunakan model yang lebih ringan (Gemini 2.5 Flash) untuk evaluasi kualitatif dasar, dan hanya menggunakan Gemini 2.5 Pro untuk kasus edge-case yang kompleks.
• Dampak Tangible: Penurunan drastis dalam biaya operasional CI/CD tanpa mengorbankan cakupan pengujian, memungkinkan tim untuk menjalankan evaluasi lebih sering (setiap commit, bukan hanya setiap malam).

📊 Simulasi FinOps & TCO Produksi: CI/CD Pipeline Evaluation Costs (100k Runs/Month) (Perhitungan SKU Terverifikasi)

Asumsi Beban Kerja Produksi (us-central1 / asia-southeast1):

• 100,000 evaluation runs per month in CI/CD pipeline.
• Option A uses Gemini 2.5 Pro for full LLM-as-a-Judge evaluation on every run (10K input, 1K output tokens per run).
• Option B uses deterministic AST/Trajectory gates first, falling back to Gemini 2.5 Flash for qualitative checks (10K input, 500 output tokens per run), reducing compute time.
• Cloud Run execution time drops from 5 seconds per eval (Option A) to 2 seconds per eval (Option B) due to fast-failing deterministic trajectory assertions.

Sumber Harga Resmi Google Cloud (2026.09): cloud.google.com, cloud.google.com

Menuju Rekayasa Agen yang Presisi

Membangun agen AI untuk produksi bukan lagi tentang merangkai prompt yang cerdas. Ini adalah disiplin rekayasa sistem terdistribusi. Ketika kita membiarkan agen AI beroperasi tanpa Continuous Evaluation Harnesses yang memvalidasi trajectory mereka, kita pada dasarnya mendeploy sistem black-box yang memiliki akses ke infrastruktur kritis kita.

Dengan mengadopsi AST Gates dan Trajectory Evals melalui framework seperti ADK, kita mengembalikan determinisme ke dalam sistem yang probabilistik. Kita memaksa agen untuk tidak hanya memberikan jawaban yang benar, tetapi juga membuktikan bahwa mereka mengambil jalur yang aman, efisien, dan dapat diprediksi untuk mencapai jawaban tersebut.

Inilah garis demarkasi yang memisahkan antara eksperimen AI yang menarik di lingkungan sandbox, dengan sistem AI enterprise-grade yang siap menangani beban produksi dunia nyata. Keandalan tidak datang dari model yang lebih besar; keandalan datang dari arsitektur evaluasi yang tidak kenal kompromi.