Eight months inside a GitHub Actions merge queue teaches you something that feature comparison matrices never will. A framework can ship fifty metrics, gorgeous dashboards, and citations from respected research labs. If it blocks your deploy because a "vibe check" score drifted from 0.72 to 0.68 against identical code, it is worse than useless. It becomes an active threat to your shipping velocity.

That is the filter most LLM evaluation roundups miss. They count capabilities. They rarely ask the only question that matters in a merge queue: does this check pass and fail the exact same way every single time it runs?

I learned this by doing the uncomfortable work. I wired six open-source LLM eval frameworks into a real CI pipeline. They ran against live production pull requests for eight months. Two earned the right to remain as gatekeepers. The rest were demoted to advisory dashboards, moved to nightly jobs, or removed entirely. The lesson was sharp and expensive: deterministic structure beats probabilistic quality when you are guarding the main branch.

The Real Job of a Merge Gate

A CI gate is not a research environment. It is a bouncer. Its entire purpose is to look at a specific change and answer yes or no. Yes, this PR can join the main branch. No, it cannot. That answer needs to arrive in seconds, cost pennies, and never flip retroactively. If you rerun the same pipeline against the same commit on a quiet Tuesday and a frantic Friday, the outcome must be identical.

This is where most LLM eval frameworks stumble. They are built by data scientists for data scientists. They optimize for insight, exploration, and nuanced scoring. A merge queue optimizes for binary decisions, speed, and zero flakiness. Those two goals only partially overlap.

Why LLM-as-Judge Breaks the Queue

The tools that failed in my test shared a single design sin: they relied too heavily on LLM-as-judge calls as the primary gate mechanism.

An LLM-as-judge prompt asks a model to score an output on a scale of one to ten, or to pick the better of two responses, or to rate factual correctness. The approach is powerful for understanding quality trends. It is poison for a blocking CI check. The same input can produce different scores on different days because temperature, model versioning, and prompt formatting all introduce noise. When that score is tied to a hard threshold and a hard exit code, your queue blocks on ghosts.

The failures cascade quickly. A nondeterministic check creates queue backups. Engineers learn to retry until the number lands favorably, which trains the team to ignore red builds. Token costs pile up because every retry burns more API credits. Worst of all, the signal becomes meaningless. A red build should mean "you introduced a bug." If it means "the judge model woke up picky today," trust erodes.

What the Survivors Do Differently

Promptfoo and DeepEval survived because they treat deterministic checks as first-class citizens and LLM judge scores as secondary, non-blocking signals. They understand that a gate needs an exit code, not a floating-point number with an opinion.

Promptfoo, released under the MIT license, is built for the command line. It runs assertions like regex matches, JSON schema validation, contains checks, and exact string comparisons. These are not fancy. They are glorified grep and jq commands. That is exactly why they work in CI. A regex either matches or it does not. A JSON schema either validates or it throws. Promptfoo returns standard Unix exit codes, so GitHub Actions natively understands when to stop a merge. It is language-agnostic because it operates as a CLI tool. You do not need to install a Python ecosystem inside a Node.js service repo just to validate outputs.

DeepEval, licensed under Apache 2.0, is the choice for Python teams. It integrates like pytest. You write tests in familiar syntax, and a failure blocks the suite naturally. DeepEval offers a huge catalog of metrics, but the critical detail is that you must use them carefully. Lean on deterministic or heuristic metrics for gates. If you pull in G-Eval or other judge-based scorers, wrap them in non-blocking report generators rather than hard asserts. When used this way, DeepEval gives you the ergonomics of a testing framework without the flakiness of a research notebook.

Where the Other Four Fit

The four frameworks that did not survive as gates still have value. They simply belong elsewhere in your toolchain.

Future AGI (Apache 2.0) menyertakan lebih dari lima puluh metrik dan menargetkan tim yang membangun SDK kustom. Metriknya sangat menyeluruh. Masalahnya adalah alat ini mengharuskan Anda menulis harness sendiri untuk menjalankannya dalam antrean CI. Dalam konteks penelitian, itu adalah pertukaran yang wajar. Dalam antrean merge, setiap lapisan pengabelan kustom adalah sumber instabilitas baru. Ini adalah mesin evaluasi yang mumpuni, tetapi bukan penjaga gerbang (gatekeeper) yang siap pakai.

RAGAS (Apache 2.0) unggul dalam mengukur kualitas retrieval-augmented generation. Metrik faithfulness dan answer relevance-nya sangat berguna untuk memahami performa basis pengetahuan dari waktu ke waktu. Sayangnya, metrik-metrik tersebut sangat bergantung pada juri LLM. Metrik ini sangat bagus untuk tugas kualitas harian yang mengirimkan tren ke Slack. Namun, metrik ini bukan "penjaga pintu" (bouncer) yang baik untuk pull request. Pindahkan RAGAS ke alur analisis terjadwal Anda, bukan ke penghambat merge Anda.

Arize Phoenix menggunakan Elastic License 2.0 dan berada di persimpangan yang sepenuhnya berbeda. Alat ini menghubungkan distributed tracing dengan evaluasi, memberi Anda observabilitas tentang mengapa sebuah model berperilaku dengan cara tertentu. Anda membutuhkan ini saat sedang melakukan debugging insiden produksi atau melacak halusinasi kembali ke potongan retrieval yang buruk. Anda tidak ingin alat tracing memutuskan apakah feature branch seorang pengembang junior dapat dirilis. Arsitekturnya dibangun untuk wawasan (insight), bukan untuk gerbang biner (binary gates).

MLflow Evaluate (Apache 2.0) mewarisi reputasinya dari pelacakan eksperimen (experiment tracking). Alat ini berat. Memasukkannya ke dalam image CI yang ramping akan menambah waktu startup dan dependensi yang memperlambat setiap pekerjaan. Jika Anda benar-benar harus menggunakannya di dalam pipeline, gunakan saja metrik heuristiknya untuk pemeriksaan struktural. Bahkan dalam kondisi itu, Anda sedang melawan desain fundamental kerangka kerja tersebut. MLflow ingin mencatat run dan membandingkan eksperimen selama berminggu-minggu. Antrean merge menginginkan keputusan dalam waktu kurang dari satu menit.

Aturan Praktis untuk Gating

Jika Anda tidak mengambil hal lain dari eksperimen ini, ambillah tiga aturan ini.

Pertama, batasi struktur, bukan "vibe". Anda dapat memastikan bahwa sebuah output adalah JSON yang valid. Anda dapat memastikan bahwa ia berisi kunci (keys) yang diperlukan. Anda dapat memastikan bahwa label klasifikasi termasuk dalam enum yang diizinkan. Pemeriksaan ini cepat, murah, dan deterministik. Anda tidak dapat memastikan secara andal bahwa sebuah ringkasan itu "ramah" atau sebuah penulisan ulang itu "kreatif". Kualitas-kualitas tersebut adalah bagian dari tinjauan manusia atau evaluasi batch berkala, bukan dalam gerbang otomatis.

Kedua, jika sebuah skor berubah pada input yang tidak berubah, turunkan statusnya segera. Jalankan rangkaian evaluasi Anda dua kali terhadap artefak yang sama persis. Jika ada metrik yang berubah dari pass ke fail, metrik tersebut telah kehilangan haknya untuk menghambat merge. Pindahkan ke dasbor penasihat di mana variansi dianggap wajar dan dapat ditoleransi.

Ketiga, hormati exit code. Laporan HTML yang cantik dengan spanduk merah tidak menghentikan merge. Exit code yang bukan nol lah yang menghentikannya. Alat evaluasi Anda harus menggunakan bahasa asli platform CI Anda. Standard out adalah untuk manusia. Exit code adalah untuk mesin.

Kesimpulan

Kita masih berada di tahap awal dalam mencari tahu cara menguji aplikasi berbasis LLM. Godaan yang ada adalah memperlakukan evaluasi seperti rubrik penilaian manusia: bernuansa, kontekstual, dan sedikit subjektif. Hal itu berhasil dalam makalah penelitian. Namun, hal itu gagal dalam antrean merge.

Setelah delapan bulan lalu lintas produksi, pipeline saya sekarang menjalankan Promptfoo untuk asersi struktural dan skema di berbagai layanan, dan DeepEval untuk pemeriksaan perilaku di sisi Python yang memetakan secara bersih ke kondisi pass-fail. Semuanya yang lain dilaporkan ke dasbor harian. Antreannya stabil. Sinyalnya bersih. Tim kembali mempercayai build yang berwarna merah.

Anda tidak membutuhkan lebih banyak metrik di gerbang Anda. Anda membutuhkan lebih sedikit metrik yang mengatakan kebenaran setiap saat.

Berdasarkan pengujian dan tulisan asli yang dibagikan di Dev.to. Untuk diskusi lebih lanjut tentang membangun sistem AI yang andal, bergabunglah dengan komunitas GyaanSetu di Telegram.