
Arize Phoenix repo'sundaki LICENSE dosyasının 1. satırı "Elastic License 2.0 (ELv2)" yazıyor. Apache değil. MIT değil. Sıkça önerilen açık kaynak LLM değerlendirme framework'lerinden biri, OSI'nin tanımına göre açık kaynak değil, buna rağmen bu sorgu için sıralanan neredeyse her sayfa aynı iddiayı tekrarlıyor. Bugüne kadar bizim sayfamız da öyle yapıyordu. 2026-08-04'te sekiz framework'ün lisans dosyasını ve ana daldaki commit geçmişini elle okuduk, üst sıralardaki sayfaların hâlâ önerdiği üç tanesini daha ekledik, sonra altısını kurup her birinden aynı 10 vakayı geçirdik. Bir eval framework'ü satmıyoruz, o yüzden aşağıdaki hiçbir karar bir ürünü korumuyor.
Öne Çıkanlar
- Arize Phoenix, OSI'nin açık kaynak olarak onaylamadığı Elastic License 2.0 altında dağıtılıyor.
- UpTrain'in
maindalına son commit'i 2024-07-29 tarihli. Yeni bir projeye bunun üzerine başlamayın. pip install promptfoosize üçüncü taraf bir sarmalayıcı veriyor. Gerçek proje npm üzerinde dağıtılıyor.- Ragas'ın 2026-02-24'ten bu yana commit'i yok ve GitHub organizasyonunu
vibrantlabsai'ye taşıdı.
2026'da Hangi Açık Kaynak LLM Değerlendirme Framework'ünü Kurmalısınız?
Sıralamaya değil, kısıtlarınıza göre seçin. Mevcut bir test paketinin içine pytest biçimli assertion'lar istiyorsanız DeepEval kurun. Herhangi bir dil yığınına uyan bir YAML config ve CLI istiyorsanız promptfoo kurun. Ölçtüğümüz en temiz iyi-kötü ayrımını istiyorsanız Opik kurun. Üçü de Apache-2.0 veya MIT.
İşte denetim. Kapsamda sekiz framework var, artı bu sorgu için üst sıralarda yer alan sayfaların hâlâ önerdiği üç tanesi daha.
| Framework | Lisans (2026-08-04 itibarıyla doğrulandı) | Son sürüm | main'e son commit | Kurulum | Arayüz biçimi | En iyi olduğu iş | Geçiş maliyeti |
|---|---|---|---|---|---|---|---|
| DeepEval | Apache-2.0 | v4.1.5 (2026-07-29) | 2026-08-03 | pip install deepeval | pytest tarzı assertion'lar | Python test paketine kapı koymak | düşük, metrikler düz nesneler |
| Promptfoo | MIT | 0.121.20 (2026-07-31) | 2026-08-04 | npm install promptfoo | YAML config artı CLI | dilden bağımsız prompt testi | orta, config formatı promptfoo'ya özel |
| Opik | Apache-2.0 | 2.2.17 (2026-08-04) | 2026-08-04 | pip install opik | bağımsız .score() çağrıları | en az satırda kullanılabilir bir skor | düşük, metrikler platform olmadan çalışıyor |
| Arize Phoenix | Elastic License 2.0, OSI-onaylı değil | v19.15.0 (2026-08-03) | 2026-08-04 | pip install arize-phoenix-evals | dataframe üzerinde hazır evaluator'lar | ikili geçti/kaldı etiketleri | eval için düşük, satarsanız lisansa bağlı |
| Ragas | Apache-2.0 | v0.4.3 (2026-01-13) | 2026-02-24 | pip install ragas | dataset üzerinde asenkron evaluate() | RAG retrieval metrikleri | düşük, satırlar düz dict |
| Evidently | Apache-2.0 | v0.7.21 (2026-03-10) | 2026-05-02 | pip install evidently | descriptor'lar artı bir HTML raporu | çok satır üzerinde toplu raporlama | yüksek, skor ölçeği ters |
| Inspect AI | MIT | 0.3.252 (2026-08-04) | 2026-08-04 | pip install inspect-ai | Python görev dosyaları artı CLI | bir modeli benchmark'lamak | yüksek, görevler Inspect'e özel |
| Giskard | Apache-2.0 | PyPI'de 2.19.2 (2026-07-06), v2 hattı | 2026-08-04 | pip install giskard | scan API'si | otomatik zafiyet taramaları | orta, tarama çıktısı Giskard'a özel |
| lm-evaluation-harness | MIT | v0.4.12 (2026-05-11) | 2026-07-13 | pip install lm-eval | görev tanımları üzerinde CLI | standart model benchmark'ları | yüksek, görev tanımları harness'e özel |
| UpTrain | Apache-2.0 | v0.7.1 (2024-05-14) | 2024-07-29 | pip install uptrain | Python check operatörleri | bugün üzerine hiçbir şey başlamayız | geçerli değil |
| Deepchecks | GitHub tarafından algılanmadı | 0.19.1 (2024-12-15) | 2025-11-24 | pip install deepchecks | suite ve check nesneleri | tablosal ve ML doğrulama | yüksek, suite'ler Deepchecks'e özel |
Tarihler her projenin ana dalındaki son commit'i, 2026-08-04 itibarıyla gösteriyor. GitHub'ın repo sayfası herhangi bir dala yapılan son push'u gösterir, bu da buradaki iki proje için daha geç bir tarihtir: UpTrain 2024-08-18 ve Deepchecks 2025-12-28. Hiçbir repo arşivlenmiş değil.
Geçiş maliyeti sütunu insanların atlayıp sonra pişman olduğu sütun. Skorlar sadece sayı olduğu için DeepEval, Ragas, Opik ve phoenix-evals arasında geçiş çoğunlukla bir döngüyü yeniden yazmak demek. Promptfoo veya Inspect AI'den çıkmak, başka yerde eşdeğeri olmayan bir config veya görev formatını yeniden yazmak demek, Evidently'den çıkmak ise yazdığınız her eşiği yeniden denetlemek demek, çünkü ölçeği tersten çalışıyor. Üst sıralardaki sayfaların hâlâ önerdiği framework'lerden ikisi 2024'ten beri sürüm çıkarmadı.
Katmanlar, hosted platformlar ve net bir sıralama mı istiyorsunuz? O ayrı bir iş, ve bunu ücretli platformlar dahil LLM değerlendirme araçlarının sıralı karşılaştırmasında zaten yaptık.
Sekiz LLM Değerlendirme Framework'ü, Kurulum Şekline Göre Gruplandı
Kurulum şekli sizin yaşamak zorunda kalacağınız şey, o yüzden gruplamayı buna göre yaptık.
Testlere import ettiğiniz Python kütüphaneleri
DeepEval (pip install deepeval, Apache-2.0) LLM metriklerini pytest biçimli assertion'lara sarmalıyor: bir LLMTestCase oluşturun, assert_test'e verin, test eşiğinizin altında kalırsa başarısız olsun. Bir ekibin zaten çalıştırdığı unit testlerin yanına bir kalite kapısı koymakta en iyisi. Eval'leriniz diğer her şeyle aynı CI işine ait olacaksa bunu seçin.
Bir kez söylenen bir açıklama: DeepEval'i geliştiren Confident AI, bu sitedeki iki başka yazının, bu sayfanın bağlantı verdiği sıralı karşılaştırma dahil, ücretli partneri. Burada hiçbir özel muamele görmüyor ve bu sayfadaki her DeepEval bağlantısı GitHub repo'suna işaret ediyor.
Ragas (pip install ragas, Apache-2.0) RAG'a özel seçenek: evaluate() soru, context ve cevap satırlarını alıp her metrik için skoru asenkron döndürüyor. Bir Python pipeline'ı içinde retrieval kalitesini ölçmekte en iyisi. Repo'su explodinggradients'ten vibrantlabsai'ye taşındı, son sürümü 2026-01-13 tarihli v0.4.3 ve 2026-02-24'ten bu yana commit yok. RAG metrikleri işin tamamıysa ve sessiz bir repo kabul edilebilirse bunu seçin; daha geniş RAG araç yığınına da bakın.
Opik (pip install opik, Apache-2.0, Comet'ten) metrikleri tek başına çağırabileceğiniz şekilde sunuyor. OPIK_TRACK_DISABLE=true ayarlarsanız AnswerRelevance().score(), hesap, yerel sunucu veya config dosyası olmadan çalışır — ürün pazarlamasının reklamını yapmadığı bir şey. En az satırda gerçek bir skor almakta en iyisi. Şimdi metrik, platformu belki daha sonra istiyorsanız bunu seçin.
Evidently (pip install evidently, Apache-2.0) eval'leri bir dataset üzerinde descriptor olarak ele alıyor ve yan etki olarak bir HTML raporu yazıyor. İkili bir kapıdan çok, birçok satır üzerinde toplu raporlamada en iyisi. LLM skorları ters: 1.0 gerçeğe aykırı demek. Birine borçlu olduğunuz şey kırmızı bir build değil, paylaşılabilir bir raporsa bunu seçin.
Giskard (pip install giskard, Apache-2.0) yazdığınız bir dataset'i puanlamak yerine bir modeli zafiyetlere karşı tarıyor. PyPI paketi v2 hattını çözümlüyor ve projenin kendi README'si, v2'nin "artık aktif olarak bakımı yapılmadığını" belirtiyor. Otomatik red-team tarzı taramalarda en iyisi. Kendi tanımlayacağınız LLM-hakem metrikleri yerine sizin için bulunan zafiyetleri istiyorsanız bunu seçin.
Bir YAML dosyasına karşı çalıştırdığınız CLI-artı-config araçları
promptfoo (npm install promptfoo, MIT) bir YAML dosyasını okuyan bir CLI: provider'ları, test case'lerini ve assertion'ları tanımlayın, npx promptfoo eval çalıştırın, her vaka için geçti/kaldı artı yerel bir sonuç arayüzü alın. Uygulamanız Python'la yazılmadığında prompt değerlendirmede en iyisi. Kalite kapınız Python bilmeyen bir ekip arkadaşının düzenleyebileceği bir config dosyası olsun istiyorsanız bunu seçin.
Harness sınıfı ve platforma gömülü olanlar
Inspect AI (pip install inspect-ai, MIT) İngiltere Yapay Zeka Güvenliği Enstitüsü'nden geliyor ve modelleri Python'da tanımladığınız görevlere karşı, gerçek solver ve scorer soyutlamaları ve bir run viewer ile değerlendiriyor. Tekrarlanabilir görev tanımlarıyla model düzeyinde benchmark'lamada en iyisi. Test ettiğiniz şey uygulamanız değil bir modelse bunu seçin.
Arize Phoenix (pip install arize-phoenix-evals) size FaithfulnessEvaluator ve CorrectnessEvaluator gibi ikili bir etiket artı bir skor döndüren hazır evaluator'lar veriyor. Bir eşik seçmeden geçebileceğiniz deterministik etiketlerde en iyisi. Lisansı, bu yazının başlığındaki parantezin sebebi, ve bu sırada kendi bölümünü hak ediyor.
Arize Phoenix Açık Kaynak mı?
Hayır, Open Source Initiative'ın sürdürdüğü tanıma göre değil. Arize Phoenix, Elastic License 2.0 (ELv2) altında dağıtılıyor. Repo'nun LICENSE dosyasının 1. satırı bunu söylüyor, PyPI de v19.15.0 üzerinde bağımsız olarak license: Elastic-2.0 beyan ediyor. Kaynak kodu okunabilir, fork'lanabilir ve kendi sunucunuzda barındırılabilir (self-host). Kısıtlanan tek şey bir kullanım biçimi.
Önemli olan kısıtlama şu: ELv2, yazılımı üçüncü taraflara hosted veya yönetilen bir servis olarak sunmayı yasaklıyor. Bunu dikkatle okuyun, çünkü göründüğünden çok daha az kişiyi bağlıyor. arize-phoenix-evals'ı kendi uygulamanızı puanlamak için kurarsanız ELv2 size hiç dokunmaz. Phoenix'i dış müşterilere sattığınız bir eval servisine paketleyen bir danışmanlık veya platform ekibiyseniz dokunur. Fark bu kadar, ve Open Source Definition, ELv2'nin başarısız olduğu şey — özellikle kullanım-alanı kısıtlamalarıyla ilgili maddeler.
| Lisans | OSI-onaylı mı? | Kendi sunucunuzda barındırabilir misiniz? | Yönetilen bir servis olarak sunabilir misiniz? | Bu listedeki framework'ler |
|---|---|---|---|---|
| Apache-2.0 | evet | evet | evet | DeepEval, Ragas, Opik, Evidently, Giskard, UpTrain |
| MIT | evet | evet | evet | promptfoo, Inspect AI, lm-evaluation-harness |
| Elastic License 2.0 | hayır | evet | hayır | Arize Phoenix |
Bu sorgu için şu anda sıralanan her sayfa Phoenix'i "açık kaynak" başlığı altında listeliyor, biz de öyle yapıyorduk. Kendi LLM değerlendirme araçları sıralı karşılaştırmamız, Phoenix'i tamamen açık kaynak olarak tanımlıyor, ki bu yanlış ve düzeltiliyor. Phoenix kaynağı erişilebilir (source-available), açık kaynak değil, ve bu ayrım sadece onu bir servis olarak satmayı planlıyorsanız sizi ısırıyor. İhtiyacınız olan şey puanlama değil izleme (tracing) ise, bu buraya değil AI gözlemlenebilirlik platformlarına ait.
Bunlardan Hangileri Hâlâ Aktif Olarak Sürdürülüyor?
Çoğu. Kontrol ettiğimiz on bir repo'dan altısı 2026-08-03 veya 2026-08-04'te main'e bir commit aldı: DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI ve Giskard. İkisi 2024'ten beri sürüm çıkarmadı. Biri GitHub organizasyon değişikliğinin ardından 2026'da sessizleşti.
2026'da yeni bir projeye üzerine başlamayacağımız framework'ler
UpTrain ölü. main dalına yapılan son commit 2024-07-29 tarihli. Son sürümü v0.7.1 ise 2024-05-14'te çıktı — bu da onu, sürüm ölçütünde bile iki yıllık soğuk bir noktaya taşıyor. Repo hâlâ orada ve hâlâ Apache-2.0, yani sizi hiçbir şey durdurmuyor, ama terk edilmiş bir değerlendirme kütüphanesi üzerinde yeni iş başlatmak, ileride açıklamak zorunda kalacağınız bir karar.
Deepchecks için hassas versiyonu belirtmek gerekir. 2024-12-15 tarihli 0.19.1'den bu yana yeni bir sürüm çıkmadı, ancak repo hâlâ commit almaya devam ediyor; main dalındaki son commit 2025-11-24 tarihli. İnsanlar hâlâ bunun üzerinde çalışıyor; sadece on sekiz aydan uzun süredir kimse yeni bir sürüm kesmemiş. Ne UpTrain ne de Deepchecks GitHub'da arşivlenmiş durumda, ikisi de katkılara kapanmamış.
Ragas sadece tarihleri alıyor, başka bir şey değil. Son sürüm v0.4.3, 2026-01-13'te; 2026-02-24'ten bu yana commit yok; repo explodinggradients'ten vibrantlabsai'ye taşındı. Organizasyonun neden değiştiğine dair doğrulanabilir bir açıklama bulamadık, o yüzden uydurmayacağız. Sessiz bir repo bozuk bir repo değildir: bugün bir faithfulness skoru hesaplayan Apache-2.0 kodu, gelecek yıl da aynı skoru hesaplar. Risk, yamalanmamış bağımlılıklar, ki aşağıdaki testte bizi tam olarak bu ısırdı.
Bu sorgu için birinci sayfadaki diğer sayfalar hem UpTrain'i hem Deepchecks'i, öneriye hiçbir tarih eklemeden hâlâ öneriyor. Aralık 2024'ten beri sürüm çıkmayan bir framework, bir özellik kararı değil bir bağımlılık kararıdır.
Bir Eval Framework'üne mi, Bir Eval Harness'ine mi İhtiyacınız Var?
Bir uygulama eval framework'ü, uygulamanızın kendi çıktılarını kendi verinize karşı puanlar. DeepEval, Ragas, promptfoo, Opik, phoenix-evals ve Evidently hepsi bunu yapıyor. Bir model eval harness'i ise bir modeli standart genel görevlere karşı benchmark'lıyor. lm-evaluation-harness ve Inspect AI bunu yapıyor. Bu sayfadaki en pahalı hata, yanlış sınıfı seçmek.
| Boyut | Uygulama eval framework'ü | Model eval harness'i |
|---|---|---|
| Test ettiğiniz şey | prompt'unuz, retrieval'ınız ve çıktınız | bir model checkpoint'i veya endpoint'i |
| Sağladığınız şey | kendi sorularınız, context'leriniz ve cevaplarınız | standart bir suite'ten bir görev adı |
| Tipik çıktı | satır başına metrik skoru, artı geçti/kaldı | yayınlanmış bir benchmark üzerindeki doğruluk |
| Nerede çalışır | CI'nızda, her pull request'te | model veya fine-tune başına tek seferlik bir çalıştırma |
| Örnekler | DeepEval, Ragas, promptfoo, Opik, Evidently, phoenix-evals | lm-evaluation-harness, Inspect AI |
Hata senaryosu somut. Biri lm-evaluation-harness'i RAG chatbot'unu test etmek için bağlar, bir dizi MMLU skoru alır ve retriever'ının doğru pasajları döndürüp döndürmediği hakkında hiçbir şey öğrenmez. Skorlar gerçek. Ama ölçtükleri şey, kimsenin zaten merak etmediği temel model.
Inspect AI'nin şekli kökeninden geliyor: İngiltere Yapay Zeka Güvenliği Enstitüsü'nde MIT altında, sınır modelleri değerlendirmek için inşa edildi, o yüzden solver'lar, scorer'lar ve görevler birinci sınıf vatandaş ve uygulamanız onun bir kavramı bile değil. Ne için yapıldıysa onun için kullanmak iyi bir sebep. Probleminiz tek turlar değil ajanlarsa, üretimde ajanları değerlendirmek tamamen ayrı bir disiplin, ve tool-calling sunucuları MCP sunucularını ve araçlarını değerlendirme rehberimizde kendi başlarına ele alınıyor.
Altısını Kurup Aynı 10 Vakayı Çalıştırdığımızda Ne Oldu
2026-08-04'te bunlardan altısını temiz Python 3.11.14 venv'lerine kurduk (artı promptfoo için npm) ve tek bir hakemle, OpenRouter üzerinden openai/gpt-4o-mini, temperature 0'da, aynı 10 öğelik RAG setini puanladık. Yedi öğe doğruydu. Üçü üç farklı şekilde bozuktu: biri kendi context'iyle çelişiyor, biri detay uyduruyor, biri hiçbir zaman soruyu cevaplamayan akıcı bir metin. Her framework arka arkaya iki kez çalıştı.
Framework (10 öğe, hakem openai/gpt-4o-mini, çalıştırma 2026-08-04) | Kurulum | İlk skora kadar satır | Çalışma süresi, çalıştırma 1 / 2 | Grounding metriğinde yakalanan hatalar | 2 çalıştırma arasında kayan öğe |
|---|---|---|---|---|---|
| DeepEval 4.1.5 | 26.6 sn | 21 | 126.8 sn / 134.1 sn | 3'te 2, ilgisiz cevabı kaçırdı | 10'da 0 |
| Ragas 0.4.3 | 56.1 sn artı bir versiyon pin'i | 23 | 21.2 sn / 25.7 sn | 3'te 3 | 10'da 1 |
| promptfoo 0.121.20 | 337.9 sn | 14 artı 40 dataset | 34.3 sn / 44.4 sn | 3'te 3 | 10'da 2 |
| Opik 2.2.17 | 142.3 sn | 15 | 54.1 sn / 44.8 sn | 3'te 3 | 10'da 4 |
| Phoenix evals 3.3.0 | 8.7 sn | 18 | 41.2 sn / 44.0 sn | 3'te 3 | 10'da 0 |
| Evidently 0.7.21 | 42.6 sn artı openai | 25 | 9.9 sn / 9.7 sn | 3'te 3 | 10'da 4 |
Altı grounding metriğinden beşi üç hatayı da yakaladı. Aşağıdaki üç bulgu, bu bölümün var olma sebebi.
Alaka metrikleri kalite metrikleri değil, ve ikisi kendinden emin bir yalanı doğru bir cevabın üzerine puanladı. Ragas'ın ResponseRelevancy'si, HTTP 404'ün bir 5xx sunucu hatası olduğunu iddia eden öğeyi 0.777 ile puanladı — yedi doğru cevaptan ikisinin üzerinde; uydurulmuş rate limit'leri olan öğeyi 0.813 ile puanladı — dördünün üzerinde. promptfoo'nun answer-relevance'ı da aynısını yaptı: 404 öğesi için 0.800, 0.7 eşiğine karşı temiz bir geçiş, oysa doğru q01'i 0.679'da başarısız saydı. Bu bir hata değil. Kendinden emin yanlış bir cevap, soruyu mükemmel şekilde ele alıyor. Ama panonuzdaki sayı alaka ise, akıcı bir halüsinasyon en iyi çıktınız gibi görünür.
Sadece faithfulness'a dayanan bir kapı, ilgisiz cevabı kaçırıyor. DeepEval, hiçbir zaman soruyu cevaplamayan öğeyi 1.000 faithfulness ile puanladı — temiz bir geçiş, ve bu savunulabilir: context hakkında hiçbir şey iddia etmeyen bir cevap, ondaki hiçbir şeyle çelişmez. Sadece relevancy bunu yakaladı, 0.000 ile. Yukarıdaki tablodaki tek grounding kaçırma bu. Metriklerden herhangi biri tek başına bir açık bırakıyor; ikisi birlikte her ikisini de kapatıyor.
İkili evaluator'lar temperature 0'da kararlıydı. Dereceli olanlar değildi. Phoenix ve DeepEval, iki özdeş çalıştırma arasında on öğeden hiçbirini kaydırmadı. Opik dördünü kaydırdı, hepsi AnswerRelevance'de, 0.05'lik bir gridte; Evidently de dördünü kaydırdı. Burada hiçbir kayma bir kararı ters çevirmedi, ama promptfoo'nun doğru q01'i 0.700 eşiğine karşı önce 0.679, sonra 0.642'ye düştü — bu, kararsız bir CI kapısının tam şekli.
İki küçük not: altıdan üçü (DeepEval, Opik, Phoenix) ilk seferde temiz kurulup çalıştı, Ragas ise langchain-community<0.4'ü pinlemeden import edilmedi. Sadece promptfoo hakem token kullanımını raporladı, çalıştırma 1'de 16.011 assertion token'ı, çalıştırma 2'de 16.010.
Bunun sınırları, açıkça söylenmeli. n = 10, bir metrik doğruluğu değil, bir smoke test'tir: size ergonomi ve kör noktalar hakkında bir şey söyler, metrik doğruluğu hakkında değil. Her şeyi tek bir hakem model puanladı, daha büyük bir hakem her sayıyı, muhtemelen DeepEval ve Ragas'ın aynı doğru öğede ürettiği iki yanlış pozitifi de değiştirirdi. İki çalıştırma kaymanın var olduğunu kanıtlar ama onu karakterize edemez. Cevaplar önceden yazılmıştı, o yüzden burada hiçbir şey üretimi (generation), tracing'i veya dataset yönetimini test etmiyor, ki bu da promptfoo'nun 337.9 saniyelik kurulumunu olduğundan kötü gösteriyor. "En iyi" her zaman bir kısıt için en iyi anlamına gelir: bir CI kapısı, RAG metrikleri veya bir arayüz her biri cevabı değiştirir, çevrimiçi ve çevrimdışı değerlendirme arasındaki ayrım da öyle.
Aynı Kontrol, Üç Farklı Şekilde Yazıldı
Bir arayüz biçimini seçmenin en hızlı yolu, aynı assertion'ı üç kez okumak. İşte gerçekten çalıştırdığımız script'lerden kırpılmış, DeepEval, Ragas ve promptfoo'da tek bir öğe üzerinde bir grounding kontrolü. Metrik adları farklı; onları burada yeniden tanımlamak yerine LLM-hakem metriklerinin gerçekte nasıl çalıştığına bağlantı veriyoruz.
# DeepEval 4.1.5: pytest bicimli, esigin altinda kalirsa testi basarisiz sayar
from deepeval import assert_test
from deepeval.models import GPTModel
from deepeval.metrics import FaithfulnessMetric
from deepeval.test_case import LLMTestCase
judge = GPTModel(
model="openai/gpt-4o-mini",
base_url="https://openrouter.ai/api/v1",
api_key=OPENROUTER_KEY,
)
def test_faithfulness():
case = LLMTestCase(
input=question,
actual_output=answer,
retrieval_context=[context],
)
assert_test(case, [FaithfulnessMetric(threshold=0.7, model=judge)])# Ragas 0.4.3: import yoluna dikkat edin. `from ragas.metrics import Faithfulness`
# bu versiyonda ImportError firlatir; somut metrik yer degistirdi.
from ragas import evaluate, EvaluationDataset
from ragas.metrics._faithfulness import Faithfulness
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI
judge = LangchainLLMWrapper(
ChatOpenAI(model="openai/gpt-4o-mini",
base_url="https://openrouter.ai/api/v1")
)
result = evaluate(
dataset=EvaluationDataset.from_list(rows),
metrics=[Faithfulness(llm=judge)],
)# promptfoo 0.121.20: npm install promptfoo, ardindan npx promptfoo eval
providers:
- id: echo # cevaplari uretmek yerine onceden yazilmis cevaplari puanladik
defaultTest:
assert:
- type: context-faithfulness
threshold: 0.7
tests:
- vars:
query: "Is HTTP 404 a client error or a server error?"
context: "HTTP 404 Not Found is in the 4xx class, which denotes client errors."
output: "HTTP 404 is a server error in the 5xx class."Kurulum satırları koddan daha fazla tuzak barındırıyor, ve aşağıdaki her yorum bize 2026-08-04'te zaman kaybettiren bir şey:
# Gercek promptfoo npm uzerinde dagitiliyor. Ayni isimli PyPI paketi
# ucuncu taraf bir sarmalayici: https://pypi.org/project/promptfoo/ vs
# https://www.npmjs.com/package/promptfoo
npm install promptfoo
# pip install giskard v2 hattini cozumluyor, ve projenin kendi README'si
# bunu artik aktif olarak bakimi yapilmiyor olarak isaretliyor.
pip install giskard
# lm-evaluation-harness, lm-eval paket adi altinda kuruluyor.
pip install lm-eval
# Evidently openai'yi cekmiyor, ve hakem import zamaninda degil cagri
# zamaninda cokuyor, siz zaten dataset'i olusturduktan sonra.
pip install evidently openai
# Ragas 0.4.3, langchain-community 0.4.x'e karsi import edilmiyor.
pip install ragas "langchain-community<0.4"Bir Build'i Eval Skoruna Göre Başarısız Sayabilir misiniz?
Evet. Buradaki her framework sayısal veya ikili bir skor döndürüyor ve bir eşik assertion'ı başarısız olduğunda sıfır olmayan bir kodla çıkıyor, ki GitHub Actions'ın bir build'i kırmızıya çevirmek için tek ihtiyacı bu. Çıkış kodunu bağlamak kolay kısım. Hakem modelinizin yanlışlıkla geçmeyeceği bir eşik seçmek, bir hafta süren kısım.
2026-08-04 testimizdeki versiyonlara pinlenmiş, çalıştırdığımız iş akışının şekli bu:
name: evals
on: [pull_request]
jobs:
eval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.11.14"
- run: pip install deepeval==4.1.5
- name: Score the golden set
env:
# Hakemi pinleyin. Ceyrek ortasi bir model yukseltmesi her skoru degistirir.
JUDGE_MODEL: openai/gpt-4o-mini
# Esikler tek bir yerde yasar, metrik constructor'lari tarafindan okunur.
EVAL_THRESHOLD: "0.7"
OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
run: deepeval test run tests/evals/Eşikten önce iki tuzak ısırıyor. Birincisi, hakem çağrıları ağ çağrıları: 10 öğelik DeepEval çalıştırmamız 126.8 saniye sürdü, çünkü .measure() sıralı çalışıyor, ve her pull request'te bu kod yolunda 200 öğelik bir altın dataset bir kahve molası demek. Testteki diğer her framework varsayılan olarak paralelleştiriyor, ki bu CI duvar-saati süresi üzerindeki en büyük tek kaldıraç.
İkincisi, kararsızlık. Temperature 0'da Opik ve Evidently, arka arkaya çalıştırmalar arasında onda dördünü kaydırdı, promptfoo'nun doğru cevabı ise 0.700 kapısına karşı önce 0.679'da, sonra 0.642'de oturdu. Önlemler sıkıcı ama işe yarıyor: sadece pull request'e göre değişen sabit bir altın dataset çalıştırın, hakem modelini pinleyin, bir etiketin yeteceği yerde ikili evaluator'ları tercih edin, ve mutlak bir tabana değil bir delta'ya göre kapı koyun. Bu sonuncusu çok turlu değerlendirme için en çok önem taşıyor, çünkü tek bir konuşma her biri ayrı ayrı sallanabilecek birçok skor üretir.
Ölçek için: LangChain'in Ajan Mühendisliği Durumu araştırması (18 Kasım - 2 Aralık 2025 arasında toplanan 1.340 yanıt, 12 Haziran 2026'da yayınlandı), organizasyonların %89'unun ajanları için bir tür gözlemlenebilirlik uyguladığını, ancak sadece %52.4'ünün test setleri üzerinde çevrimdışı değerlendirme çalıştırdığını buldu. İzlemek yaygın. Kapı koymak değil.
Bu Hafta Neyi Kurardık
Götüreceğiniz dört şey var. Arize Phoenix, Elastic License 2.0 altında kaynağı erişilebilir ve OSI-onaylı açık kaynak değil, ki bu çoğu okuyucu için hiçbir şeyi değiştirmiyor, eval aracını yeniden satacaksanız her şeyi değiştiriyor. UpTrain ölü, ve üzerinde tarih olmayan sayfalar hâlâ onu öneriyor. Deepchecks de Aralık 2024'ten beri sürüm kesmedi, gerçi repo'su hâlâ commit alıyor. Bir grounding metriği ve bir alaka metriği, birbirinin kapattığı birer açığa sahip, o yüzden ikisine birden kapı koyun. Ve dereceli skorlar temperature 0'da bile kayıyor, o yüzden hakeminizi pinleyin ve eşiklere biraz alan bırakın.
Bu hafta yeni bir eval suite'ine başlıyor olsaydım, CI kapısı için DeepEval kurardım çünkü assertion'lar testlerin yanına ait (yukarıdaki açıklama), ölçtüğümüz en temiz ayrım için Opik'in bağımsız metriklerini eklerdim. Yığınımız Python olmasaydı, hiç tereddüt etmeden promptfoo. Altın seti ve iş akışını sizin yerinize birinin bağlamasını isterseniz, bunu konuşmaktan memnuniyet duyarız.
Sıkça Sorulan Sorular
En iyi açık kaynak LLM değerlendirme framework'ü hangisi?
Tek bir kazanan yok, sadece kısıt başına bir en iyi uyum var. Bir Python test paketi içinde geçti/kaldı bir kapı için DeepEval. Dilden bağımsız bir YAML ve CLI kurulumu için promptfoo. RAG retrieval metrikleri için Ragas, 2026-02-24'ten beri commit'i olmayan bir repo'yu kabul edebiliyorsanız. 2026-08-04 testimizde iyi ve kötü cevaplar arasındaki en temiz ayrım için Opik.
Arize Phoenix açık kaynak mı?
Open Source Initiative'ın tanımına göre değil. Arize Phoenix, PyPI'nin v19.15.0 üzerinde license: Elastic-2.0 olarak beyan ettiği ve repo'nun LICENSE dosyasının 1. satırının doğrudan belirttiği Elastic License 2.0 altında dağıtılıyor. Kaynağı erişilebilir (source-available): onu okuyabilir, fork'layabilir, değiştirebilir ve kendi sunucunuzda barındırabilirsiniz. Tek kısıtlama, yazılımı üçüncü taraflara hosted veya yönetilen bir servis olarak sunmak.
Ragas hâlâ bakımı yapılıyor mu?
Doğrulanabilir gerçekler, 2026-08-04 itibarıyla: son sürüm v0.4.3, 2026-01-13'te; 2026-02-24'ten bu yana commit yok; repo explodinggradients organizasyonundan vibrantlabsai'ye taşındı. Repo arşivlenmiş değil. Organizasyon değişikliği için güvenilir, kamuya açık bir açıklama bulamadık ve spekülasyon yapmayacağız. Apache-2.0 kodu hâlâ çalışıyor; risk yamalanmamış bağımlılıklar.
Bir eval framework'üne mi, bir gözlemlenebilirlik platformuna mı ihtiyacım var?
Sonunda ikisine de, ama farklı sorulara cevap veriyorlar. Bir eval framework'ü, kontrol ettiğiniz bir dataset üzerinde, yayınlamadan önce bir değişikliğin çıktılarınızı iyileştirip iyileştirmediğini söyler. Bir gözlemlenebilirlik platformu, yayınladıktan sonra production'da gerçekte ne olduğunu söyler. Bir CI pipeline'ınız varsa eval framework'üyle başlayın; production tarafı için AI gözlemlenebilirlik platformlarına bakın.
CI/CD'de LLM eval'leri çalıştırabilir miyim?
Evet. Burada ele alınan her framework, başarısız bir eşik assertion'ında sıfır olmayan bir kodla çıkıyor, ki bir GitHub Actions işinin tek ihtiyacı bu. Pratik kısıtlar duvar-saati süresi (hakem çağrıları ağ çağrılarıdır, ve sıralı DeepEval çalıştırmamız 10 öğe için 126.8 saniye sürdü) ve hakem belirsizliği. İş akışının şekli ve önlemler yukarıdaki CI bölümünde.
DeepEval ile Ragas arasındaki fark ne?
Kalite değil, arayüz biçimi ve kapsam. DeepEval pytest biçiminde ve genel amaçlı: test case'leri yazıp metrik eşiklerine göre assert edersiniz, ve birçok türde uygulama çıktısını kapsar. Ragas, evaluate()'i soru, context ve cevap satırlarından oluşan bir dataset üzerinde asenkron çalıştıran RAG'a özel bir kütüphane. DeepEval bir CI kapısına daha doğal oturur; Ragas retrieval'de daha derine iner.
pip install promptfoo neden bana yanlış paketi veriyor?
Çünkü promptfoo bir Node projesi. Gerçek proje npm üzerinde MIT altında yayınlanıyor ve npm install promptfoo ile kuruluyor. Aynı isimli PyPI paketi, upstream proje değil, üçüncü taraf bir sarmalayıcı, ve onu kurmak, dokümanların anlattığı CLI'dan farklı bir CLI'ı debug etmekle sonuçlanan yaygın bir yol.
lm-evaluation-harness bir LLM değerlendirme framework'ü mü?
O, ilişkili ama farklı bir iş olan bir model değerlendirme harness'i. lm-evaluation-harness (pip install lm-eval olarak kuruluyor), bir modeli MMLU gibi standart genel görevlere karşı benchmark'lıyor. Retrieval pipeline'ınızın doğru pasajı döndürüp döndürmediğini söylemez, çünkü uygulamanız onun bir kavramı bile değil. Ayrım için yukarıdaki framework-versus-harness bölümüne bakın.
Bu framework'ler ücretsiz mi?
Lisans açısından, evet. DeepEval, Ragas, Opik, Evidently ve Giskard Apache-2.0; promptfoo, Inspect AI ve lm-evaluation-harness MIT. Her iki lisans da ticari kullanıma, değiştirmeye ve yeniden dağıtıma izin veriyor. Arize Phoenix istisna: Elastic License 2.0, kendi sunucunuzda barındırmaya izin veriyor ama yazılımı üçüncü taraflara yönetilen bir servis olarak sunmaya izin vermiyor. Hakem-model API kullanımı, sağlayıcınız tarafından ayrı faturalandırılıyor.