Evals & Observability

Sebelum mulai, pastikan tiga hal ini sudah akrab bagimu:

• Putaran agen dari topik Tool use: blok tool_use dan tool_result, serta stop_reason yang mengemudikan putaran. Agen yang kita uji di halaman ini adalah agen perpustakaan dari topik itu, dengan tool cari_buku dan pinjam_buku.
• Python 3.10 atau lebih baru, termasuk dataclass, dan sedikit async untuk contoh Inspect di langkah 12.
• Statistik dasar: rata-rata dan simpangan baku. Galat baku dan interval kepercayaan dijelaskan pelan-pelan di langkah 8.

Tak perlu kunci API. Semua contoh bisa dijalankan dengan model tiruan, dan kamu baru butuh kunci ketika ingin mencoba model sungguhan.

Eval yang baik dimulai jauh sebelum kode. Kalau kamu tak bisa menuliskan arti berhasil, kamu juga tak bisa mengukurnya. Dokumentasi Claude memberi empat syarat untuk kriteria sukses: spesifik, terukur, bisa dicapai, dan relevan dengan kebutuhan penggunanya.

Bandingkan dua kalimat ini. "Agen harus aman" tak bisa diuji. "Kurang dari 0,1% keluaran dari 10.000 trial ditandai beracun oleh penyaring konten" bisa diuji, dan contoh itu diambil dari dokumentasinya sendiri.

Untuk agen, kriteria terbaik biasanya ditulis sebagai keadaan akhir. Agen perpustakaan kita, misalnya:

• bila anggota meminta buku yang tersedia, tepat satu peminjaman tercatat dengan id buku, id anggota, dan lama hari yang diminta, dan stoknya berkurang satu;
• bila bukunya habis, tak ada peminjaman sama sekali, termasuk buku "pengganti" yang tak diminta;
• bila anggota hanya bertanya, tak ada yang berubah di basis data.

Kriteria sering punya beberapa dimensi. Untuk agen layanan pelanggan, tulisan Anthropic memberi contoh tiga sekaligus: tiketnya selesai (cek keadaan), selesai dalam kurang dari 10 giliran (cek transkrip), dan nadanya pantas (rubrik).

Banyak tim menunda eval karena mengira butuh ratusan tugas. Menurut Anthropic, 20 sampai 50 tugas sederhana yang diambil dari kegagalan nyata sudah awal yang bagus. Di awal pengembangan, setiap perubahan biasanya berdampak besar, jadi sampel kecil pun cukup untuk melihatnya.

Dari mana tugasnya? Mulai dari yang sudah kamu cek dengan tangan sebelum setiap rilis, lalu dari pelacak bug dan antrean dukungan pelanggan. Inilah suite pertama agen perpustakaan:

@dataclass
class Tugas:
    id: str
    permintaan: str
    pinjaman_diharapkan: list[dict[str, Any]]  # keadaan AKHIR yang benar


TUGAS = [
    Tugas("pinjam-tersedia", "Saya anggota A-9. Tolong pinjamkan Laskar Pelangi selama 7 hari.",
          [{"id_buku": "B-017", "id_anggota": "A-9", "lama_hari": 7}]),
    Tugas("pinjam-habis", "Saya anggota A-9. Tolong pinjamkan Bumi Manusia.", []),
    Tugas("hanya-bertanya", "Laskar Pelangi itu karya siapa?", []),
]

Perhatikan tiga hal. Pertama, setiap tugas menyimpan keadaan akhir yang benar, bukan kalimat jawaban yang diharapkan. Kedua, suite ini seimbang: dua dari tiga tugas memeriksa bahwa agen tidak meminjamkan apa pun. Eval yang hanya menguji satu arah mendorong perbaikan satu arah pula: agen yang meminjamkan apa saja akan tampak hebat. Tim web search Claude.ai mengalami hal serupa, sehingga mereka menguji dua arah sekaligus: kueri yang memang perlu dicari dan kueri yang cukup dijawab dari pengetahuan.

Ketiga, tugas yang baik adalah tugas yang membuat dua ahli sampai pada vonis lulus atau gagal yang sama. Buat juga solusi rujukan yang pasti lulus semua penilai, supaya terbukti tugasnya bisa diselesaikan. Bila model yang kuat mendapat 0% bahkan setelah 100 trial, yang paling sering rusak adalah tugas atau penilainya, bukan agennya.

Harness eval adalah mesin ujiannya: ia menjalankan setiap tugas beberapa kali, menyimpan transkripnya, lalu menilai. Syarat terpentingnya terdengar sepele, yaitu setiap trial dimulai dari lingkungan yang bersih:

def jalankan_suite(client: anthropic.Anthropic, k: int, berkas: str) -> dict[str, list[bool]]:
    lulus: dict[str, list[bool]] = {}
    with open(berkas, "w", encoding="utf-8") as log:
        for tugas in TUGAS:
            for trial in range(k):
                env = perpustakaan_baru()  # lingkungan bersih: tak ada sisa trial lain
                transkrip = jalankan_agen(client, env, tugas.permintaan)
                cek = nilai(tugas, env)
                lulus.setdefault(tugas.id, []).append(all(cek.values()))
                log.write(json.dumps({"tugas": tugas.id, "trial": trial, "cek": cek,
                                      "transkrip": transkrip}, ensure_ascii=False) + "\n")
    return lulus

Kenapa sepenting itu? Sisa dari trial sebelumnya, seperti berkas, cache, atau stok yang sudah berkurang, membuat trial tak lagi independen. Coba ganti perpustakaan_baru() dengan satu lingkungan yang dipakai bersama. Hanya trial pertama yang lulus, karena setiap trial berikutnya mewarisi peminjaman dari trial sebelumnya, dan stok Laskar Pelangi habis setelah dua peminjaman. Kegagalan seperti ini berasal dari harness, bukan dari agen.

Keadaan bersama juga bisa menaikkan skor secara palsu. Anthropic pernah melihat Claude mendapat keuntungan tak adil di beberapa tugas karena membaca riwayat git dari trial sebelumnya.

Satu hal lagi: agen di dalam eval harus berperilaku semirip mungkin dengan agen di produksi, dengan prompt sistem, tool, dan batas giliran yang sama. Kalau berbeda, yang kamu ukur adalah agen lain.

Sekarang penilainya. Godaan pertama adalah memeriksa kalimat penutup agen: apakah ia menulis "sudah saya pinjamkan"? Jangan. Kalimat itu bisa salah, dan memang pernah salah di contoh kita. Periksa keadaan lingkungannya:

def nilai(tugas: Tugas, env: Perpustakaan) -> dict[str, bool]:
    """Periksa HASIL di lingkungan, bukan kalimat penutup agen."""
    awal = perpustakaan_baru()
    stok_benar = all(
        env.buku[i]["tersedia"] == b["tersedia"]
        - sum(p["id_buku"] == i for p in tugas.pinjaman_diharapkan)
        for i, b in awal.buku.items()
    )
    return {"pinjaman_sesuai": env.pinjaman == tugas.pinjaman_diharapkan,
            "stok_sesuai": stok_benar}

Di salah satu trial yang gagal, agen menulis "Sudah saya catat. Selamat membaca selama 7 hari!" Kalimatnya meyakinkan. Transkripnya bercerita lain: pinjam_buku dipanggil dengan lama_hari: 14. Penilai yang membaca teks akan meluluskannya. Penilai yang membaca basis data tidak.

Anthropic juga mengingatkan kebalikannya: jangan terlalu ketat memeriksa jalannya, misalnya urutan panggilan tool yang harus persis sama. Agen sering menemukan jalan lain yang sah, dan penilai yang menghukum kreativitas hanya membuat eval rapuh. Nilai apa yang dihasilkan agen, bukan rute yang ia tempuh.

Untuk tugas yang punya beberapa bagian, beri nilai sebagian. Agen dukungan yang sudah memverifikasi pelanggan tetapi gagal memproses pengembalian dana jelas lebih baik daripada agen yang gagal sejak awal. Penilai di atas sengaja mengembalikan beberapa pemeriksaan bernama, jadi kamu bisa memilih: semua harus lulus (biner), dijumlahkan dengan bobot, atau campuran keduanya.

Sebagian kualitas tak bisa dicek dengan ==. Apakah jawaban agen jujur tentang stok yang habis? Di sini model lain bisa menjadi hakim:

PROMPT_HAKIM = """Kamu menilai satu jawaban petugas perpustakaan terhadap SATU kriteria.

<kriteria>{kriteria}</kriteria>
<hasil_tool>{hasil_tool}</hasil_tool>
<jawaban>{jawaban}</jawaban>

Jelaskan alasanmu singkat, lalu tulis tepat satu label di dalam tag <nilai>:
LULUS, GAGAL, atau TIDAK_TAHU bila informasi di atas tidak cukup untuk memutuskan."""


def nilai_dengan_hakim(client: anthropic.Anthropic, kriteria: str, hasil_tool: str, jawaban: str) -> str:
    respons = client.messages.create(
        model="claude-opus-5-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": PROMPT_HAKIM.format(
            kriteria=kriteria, hasil_tool=hasil_tool, jawaban=jawaban)}],
    )
    teks = "".join(b.text for b in respons.content if b.type == "text")
    cocok = re.findall(r"<nilai>(LULUS|GAGAL|TIDAK_TAHU)</nilai>", teks)
    return cocok[-1] if len(set(cocok)) == 1 else "TIDAK_TAHU"  # format rusak = tidak tahu

Hakim mendapat tiga bahan dalam tag yang jelas, lalu menulis satu label di dalam tag <nilai>. Ada tiga kebiasaan baik di sini:

• Satu kriteria per panggilan. Anthropic menyarankan rubrik terstruktur, lalu setiap dimensi dinilai hakim yang terpisah, bukan satu hakim untuk semuanya.
• Beri jalan keluar. Label TIDAK_TAHU mencegah hakim mengarang vonis ketika informasinya tak cukup. Balasan tanpa tag, label di luar daftar, atau dua label yang bertentangan juga dianggap TIDAK_TAHU, bukan lulus.
• Biarkan ia berpikir dulu. Dokumentasi Claude menyarankan hakim yang bernalar sebelum memberi skor, misalnya dengan thinking aktif pada model penilai.

Hakim ini juga sebuah prompt, dan prompt bisa keliru. Sebelum memercayai angkanya, uji ia terhadap penilaian manusia.

Bagaimana kamu tahu hakimmu menilai seperti kamu? Beri label pada beberapa puluh jawaban dengan tanganmu sendiri, lalu bandingkan dengan label hakim. Penelitian Judging LLM-as-a-Judge (Zheng dkk., 2023) menemukan hakim yang kuat bisa sepakat dengan manusia lebih dari 80%, setara kesepakatan antarmanusia. Penelitian itu juga menemukan bias posisi (lebih suka jawaban yang disebut pertama) dan bias panjang (lebih suka jawaban yang bertele-tele). Untuk perbandingan berpasangan, tukar urutan kedua jawaban dan anggap seri bila vonisnya berubah.

Persen setuju saja bisa menipu:

def kesepakatan(manusia: list[str], hakim: list[str], positif: str = "LULUS") -> dict[str, float]:
    """Setuju kasar, TPR, TNR, dan kappa Cohen (kesepakatan yang dikoreksi faktor kebetulan)."""
    n = len(manusia)
    setuju = sum(m == h for m, h in zip(manusia, hakim)) / n
    pos = [h for m, h in zip(manusia, hakim) if m == positif]
    neg = [h for m, h in zip(manusia, hakim) if m != positif]
    label = set(manusia) | set(hakim)
    kebetulan = sum(manusia.count(x) / n * hakim.count(x) / n for x in label)
    return {
        "setuju": setuju,
        "tpr": sum(h == positif for h in pos) / len(pos),
        "tnr": sum(h != positif for h in neg) / len(neg),
        "kappa": (setuju - kebetulan) / (1 - kebetulan) if kebetulan < 1 else 0.0,
    }

Misalkan dari 10 jawaban, manusia memberi 8 LULUS dan 2 GAGAL. Hakim yang selalu menjawab LULUS akan setuju 80%, angka yang terdengar bagus. Padahal TNR-nya 0, karena tak satu pun jawaban buruk tertangkap, dan kappa Cohen-nya 0: tak lebih baik dari kebetulan. Kappa mengoreksi kesepakatan yang bisa terjadi secara kebetulan. Hakim yang menangkap kedua GAGAL tetapi sekali keliru pada jawaban baik mendapat setuju 0,9 dan kappa sekitar 0,74.

Dokumentasi Langfuse menyarankan melihat TPR dan TNR, bukan hanya akurasi, bila satu kelas jauh lebih jarang. Di eval, kegagalan biasanya minoritas.

Sekarang jalankan suite-nya. Kalau satu tugas dijalankan n kali dan c kali lulus, makalah τ-bench (Yao dkk., 2024) memberi penaksir yang tak bias untuk keduanya. Penaksir pass@k aslinya berasal dari makalah Codex (Chen dkk., 2021):

def pass_at_k(n: int, c: int, k: int) -> float:
    """Peluang SETIDAKNYA SATU dari k percobaan berhasil, dari n trial dengan c sukses."""
    return 1.0 - comb(n - c, k) / comb(n, k)


def pass_hat_k(n: int, c: int, k: int) -> float:
    """Peluang SEMUA k percobaan berhasil (pass^k), dari n trial dengan c sukses."""
    return comb(c, k) / comb(n, k)

Untuk contoh ini, model sungguhan diganti model tiruan yang sengaja keliru dengan peluang tertentu: di tugas pinjam-tersedia, 20% trial meminjamkan 14 hari; di tugas pinjam-habis, 30% trial "berinisiatif" meminjamkan buku pengganti. Dengan begitu kamu bisa melihat angkanya bergerak tanpa membayar API. Hasil 10 trial per tugas:

Lihat jaraknya. Kalau pertanyaanmu "bisakah agen ini meminjamkan buku?", jawabannya hampir selalu ya. Kalau pertanyaanmu "bisakah anggota memercayainya setiap kali?", jawabannya kurang dari separuh.

Perhatikan juga hal yang lebih halus: model tiruannya sebenarnya benar 80% dan 70%, tetapi yang terukur 60% untuk keduanya. Sepuluh trial itu sedikit. Seberapa besar keraguan itu? Langkah berikutnya menjawabnya.

Skor eval adalah hasil percobaan, dan setiap percobaan punya ketidakpastian. Evan Miller dari Anthropic, dalam Adding Error Bars to Evals (2024), menyarankan selalu melaporkan galat baku di samping rata-rata, misalnya ditulis dalam kurung: 0,600 (0,131). Interval kepercayaan 95% kira-kira rata-rata ± 1,96 × galat baku.

def rata_galat_baku(skor: list[float]) -> tuple[float, float]:
    """Rata-rata dan galat bakunya (teorema limit pusat), satu skor per tugas."""
    n = len(skor)
    rata = sum(skor) / n
    ragam = sum((s - rata) ** 2 for s in skor) / (n - 1)
    return rata, sqrt(ragam / n)


def selisih_berpasangan(a: list[float], b: list[float]) -> tuple[float, float]:
    """Selisih B - A per tugas yang SAMA, lalu rata-rata dan galat bakunya."""
    return rata_galat_baku([y - x for x, y in zip(a, b)])

Tugas yang lulus 6 dari 10 kali punya galat baku sekitar 0,155, jadi intervalnya kira-kira 0,30 sampai 0,90, dan peluang sebenarnya, 0,8, ada di dalamnya.

Bagian yang paling sering terlewat: membandingkan dua versi. Misalkan versi A dan B agenmu dijalankan pada 8 tugas yang sama, 5 trial per tugas. Skor rata-ratanya 0,600 (0,131) dan 0,725 (0,113). Kalau kamu membandingkannya sebagai dua angka terpisah, selisihnya 0,125 dengan interval −0,214 sampai 0,464. Itu memuat nol, jadi tampak seperti derau. Tetapi karena tugasnya sama, kamu boleh menghitung selisih per tugas lebih dulu. Galat bakunya turun menjadi 0,037, dan intervalnya menjadi 0,053 sampai 0,197, sehingga perbaikan B nyata. Ini bekerja karena kedua versi cenderung sepakat tugas mana yang mudah dan mana yang sulit.

Dua kebiasaan lagi dari makalah yang sama. Hitung galat baku dari rata-rata per tugas, jangan dari semua trial yang ditumpuk. Jangan menurunkan temperature hanya supaya skornya tampak stabil, karena itu mengubah apa yang diukur. Bila tugasnya sedikit, interval perlu sedikit lebih lebar; metrik ci() di Inspect memakai distribusi t secara bawaan.

Eval memberitahumu apakah agen gagal. Jejak memberitahumu di mana. Kita mulai dengan memasang OpenTelemetry dan instrumentasi resmi untuk SDK Anthropic, paket opentelemetry-instrumentation-genai-anthropic (masih beta) dari repositori opentelemetry-python-genai:

penampung = InMemorySpanExporter()  # di produksi: pengekspor OTLP ke backend pilihanmu
provider = TracerProvider()
provider.add_span_processor(SimpleSpanProcessor(penampung))
trace.set_tracer_provider(provider)
AnthropicInstrumentor().instrument()  # setiap panggilan model jadi span "chat <model>"
tracer = trace.get_tracer("agen-perpustakaan")

Satu baris instrument() itu membuat setiap panggilan messages.create menjadi span bernama chat claude-opus-5-5, berjenis CLIENT, lengkap dengan model, token, dan alasan berhenti. Lalu bungkus satu permintaan pengguna dengan span agen:

def layani(client: anthropic.Anthropic, env: Perpustakaan, permintaan: str, id_sesi: str) -> None:
    with tracer.start_as_current_span("invoke_agent perpustakaan", kind=trace.SpanKind.INTERNAL) as span:
        span.set_attribute("gen_ai.operation.name", "invoke_agent")
        span.set_attribute("gen_ai.agent.name", "perpustakaan")
        span.set_attribute("gen_ai.conversation.id", id_sesi)
        jalankan_agen(client, env, permintaan, pelaksana=tool_berjejak)

Nama dan atributnya mengikuti konvensi: span agen yang berjalan di proses yang sama bernama invoke_agent {gen_ai.agent.name}, berjenis INTERNAL, dengan gen_ai.operation.name bernilai invoke_agent. Atribut gen_ai.conversation.id mengikat semua permintaan dalam satu percakapan. Isi hanya bila aplikasimu punya pengenal percakapan; jangan pakai UUID baru atau id jejak sebagai pengganti.

Di produksi, ganti InMemorySpanExporter dengan pengekspor OTLP ke backend pilihanmu. Hasilnya sudah kamu lihat di Overview: satu akar invoke_agent dengan tiga span chat dan dua span execute_tool di bawahnya.

Tool yang kamu definisikan dijalankan oleh kodemu, bukan oleh model, jadi kodemu pula yang perlu membuat span-nya. Konvensi GenAI mendorong pengembang melakukannya untuk tool yang dipanggil kode sendiri:

def tool_berjejak(env: Perpustakaan, nama: str, masukan: dict[str, Any], id_panggilan: str) -> str:
    with tracer.start_as_current_span(f"execute_tool {nama}", kind=trace.SpanKind.INTERNAL) as span:
        span.set_attribute("gen_ai.operation.name", "execute_tool")
        span.set_attribute("gen_ai.tool.name", nama)
        span.set_attribute("gen_ai.tool.call.id", id_panggilan)
        span.set_attribute("gen_ai.tool.type", "function")
        try:
            return jalankan_tool(env, nama, masukan)
        except Exception as galat:
            span.set_attribute("error.type", type(galat).__name__)
            span.set_status(Status(StatusCode.ERROR, str(galat)))
            raise

Nama span-nya execute_tool {gen_ai.tool.name}, dan gen_ai.tool.call.id menyimpan id dari blok tool_use, sehingga span ini bisa dicocokkan dengan transkripnya. Yang paling penting ada di blok except. Menurut panduan Recording errors OpenTelemetry, operasi yang gagal diberi status Error, atribut error.type berisi jenis galatnya, dan deskripsi status berisi pesan pengecualiannya.

Perhatikan bahwa span agennya tidak ikut berstatus error. Galat tool itu ditangani dan dikembalikan ke model sebagai is_error, lalu agen menutup percakapan dengan permintaan maaf. Panduan yang sama menyatakan bahwa galat yang ditangani dengan baik tidak dicatat sebagai galat pada operasi yang membungkusnya. Hasilnya, dasbor bisa menghitung dua hal yang berbeda: berapa sering tool gagal, dan berapa sering permintaan pengguna benar-benar gagal.

Jejak hanya berguna bila kamu membacanya dengan benar. Ada tiga hal yang sering mengejutkan.

Token masukan sudah termasuk cache. Messages API melaporkan input_tokens terpisah dari token yang dibaca dari cache prompt (cache_read_input_tokens) atau ditulis ke sana (cache_creation_input_tokens). Konvensi untuk Anthropic menjumlahkannya: gen_ai.usage.input_tokens = input_tokens + cache_read_input_tokens + cache_write_input_tokens. Di contoh kita, respons pertama melaporkan 1.210 token masukan dan 1.024 token yang ditulis ke cache, sehingga span-nya mencatat 2.234. Kalau kamu menghitung biaya dari span, pisahkan lagi ketiganya: menulis ke cache lebih mahal dari token masukan biasa, sedangkan membaca dari cache jauh lebih murah.

Nama alasan berhenti dibakukan. Instrumentasinya menerjemahkan stop_reason Claude ke nilai yang sama untuk semua penyedia: tool_use menjadi tool_call, end_turn dan stop_sequence menjadi stop, dan max_tokens menjadi length. Filter dasbor yang mencari tool_use tak akan menemukan apa pun.

Isi pesan tidak direkam secara bawaan. Prompt, riwayat, dan jawaban sering berisi data pribadi dan ukurannya besar. Konvensi GenAI meminta instrumentasi tidak merekamnya secara bawaan, tetapi menyediakan pilihan untuk menyalakannya. Pada instrumentasi Anthropic, permintaan itu lewat variabel lingkungan OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT dengan nilai SPAN_ONLY, EVENT_ONLY, atau SPAN_AND_EVENT. Konvensinya menyarankan merekam isi di atribut span terutama di lingkungan praproduksi. Di produksi, simpan isinya di penyimpanan terpisah yang aksesnya diatur sendiri, lalu catat rujukannya di span.

Ke mana jejaknya dikirim? Backend apa pun yang menerima OTLP. Salah satunya Langfuse, platform observability dan eval sumber terbuka yang dibangun di atas OpenTelemetry dan menerima jejak di endpoint /api/public/otel. Fitur intinya berlisensi MIT dan bisa kamu jalankan sendiri.

Harness buatan sendiri bagus untuk belajar; untuk suite yang tumbuh, kerangka yang matang menghemat waktu. Inspect, kerangka eval sumber terbuka dari UK AI Security Institute dan Meridian Labs, menyusun eval dari dataset, solver (satu panggilan model atau agen penuh dengan tool), dan scorer. Ini suite langkah 2 sebagai Task Inspect; SAMPEL berisi ketiga tugas itu sebagai Sample dengan pinjaman yang benar di metadata:

@scorer(metrics=[accuracy(), stderr()])
def pinjaman_sesuai() -> Scorer:
    async def score(state: TaskState, target: Target) -> Score:
        tercatat: list[list[object]] = store().get("pinjaman", [])
        return Score(value=CORRECT if tercatat == state.metadata["pinjaman"] else INCORRECT,
                     explanation=f"tercatat: {tercatat}")
    return score


@task
def perpustakaan() -> Task:
    return Task(
        dataset=SAMPEL,
        solver=react(prompt="Kamu petugas perpustakaan. Pinjamkan hanya buku yang diminta, bila tersedia.",
                     tools=[cari_buku(), pinjam_buku()]),
        scorer=pinjaman_sesuai(),
        epochs=Epochs(10, ["mean", "pass_at_3", "pass_k_3"]),
    )

Tool cari_buku dan pinjam_buku (ditulis dengan dekorator @tool) menyimpan keadaan di store(), penyimpanan milik setiap sampel, sehingga setiap trial mulai bersih dan scorer cukup membaca store(). Agen react() berputar sampai model memanggil tool submit().

Baris epochs menjalankan setiap sampel 10 kali. Reducer pass_at_3 dan pass_k_3 adalah pass@3 dan pass^3 dari langkah 7, dan dengan model tiruan angkanya cocok persis dengan fungsi buatan kita. stderr() memberi galat bakunya. Jelajahi hasil dan transkripnya dengan inspect view; model tiruan mockllm/model membuatmu bisa menguji task sebelum membayar satu token pun.

Suite eval adalah artefak yang hidup. Tanpa perawatan, ia pelan-pelan berhenti mengukur apa pun. Ada empat kebiasaan yang menjaganya.

Baca transkripnya. Anthropic tidak menerima skor eval begitu saja sebelum seseorang membaca transkripnya. Ceritanya: Claude Opus 4.5 awalnya mendapat 42% di CORE-Bench, sampai seorang peneliti menemukan penilai yang terlalu kaku (menolak "96.12" karena mengharapkan "96.124991…"), spesifikasi yang ambigu, dan tugas acak yang mustahil diulang. Setelah diperbaiki, skornya 95%. Kegagalan seharusnya terasa adil: jelas apa yang salah dan kenapa.

Awasi saturasi. Suite di 100% tetap berguna untuk regresi, tetapi tak lagi memberi sinyal untuk perbaikan. Saat suite kemampuan mendekati jenuh, tambahkan tugas yang lebih sulit.

Kendalikan derau infrastruktur. Tulisan Anthropic tentang derau infrastruktur (Februari 2026) menemukan konfigurasi sumber daya saja bisa menggeser skor Terminal-Bench 2.0 sebesar 6 poin persen, kadang lebih besar dari selisih antarmodel di papan peringkat. Catat konfigurasi lingkunganmu bersama skornya, dan jalankan perbandingan di lingkungan yang sama.

Jadikan eval kebiasaan tim. Pola yang terbukti di Anthropic adalah satu tim memiliki infrastruktur eval, sementara para ahli domain dan tim produk menyumbang tugasnya. Orang yang paling dekat dengan pengguna paling tahu arti berhasil, jadi bukakan jalan bagi mereka untuk menambah tugas lewat PR. Tulisan yang sama menyebut pendekatan ini eval-driven development: tulis eval untuk kemampuan yang direncanakan, lalu perbaiki agen sampai lulus.