Meilleurs Frameworks d'Évaluation LLM Open Source en 2026 (l'Un N'Est Pas Vraiment Open Source)

Meilleurs Frameworks d'Évaluation LLM Open Source en 2026 (l'Un N'Est Pas Vraiment Open Source)

La ligne 1 du fichier LICENSE du dépôt Arize Phoenix indique « Elastic License 2.0 (ELv2) ». Pas Apache. Pas MIT. Un framework d'évaluation LLM open source très recommandé n'est pas open source selon la définition de l'OSI, et presque toutes les pages classées sur cette requête répètent pourtant l'affirmation. La nôtre aussi, jusqu'à aujourd'hui. Le 2026-08-04, nous avons lu à la main le fichier de licence et l'historique de commits de la branche par défaut de huit frameworks, plus trois autres que les meilleures pages recommandent encore, puis nous en avons installé six et testé les mêmes 10 cas sur chacun. Nous ne vendons pas de framework d'évaluation, donc aucun verdict ci-dessous ne protège un produit.

Points Clés

• Arize Phoenix est distribué sous licence Elastic License 2.0, que l'OSI n'approuve pas comme open source.
• Le dernier commit d'UpTrain sur main date du 2024-07-29. Ne démarrez pas un nouveau projet dessus.
• pip install promptfoo installe un wrapper tiers. Le vrai projet est distribué sur npm.
• Ragas n'a plus eu de commit depuis le 2026-02-24 et a changé d'organisation GitHub pour vibrantlabsai.

Quel Framework d'Évaluation LLM Open Source Installer en 2026 ?

Choisissez selon votre contrainte, pas selon un classement. Pour des assertions au format pytest dans une suite de tests existante, installez DeepEval. Pour une configuration YAML et une CLI qui s'adapte à n'importe quelle stack, installez promptfoo. Pour la séparation la plus nette entre bonnes et mauvaises réponses que nous avons mesurée, installez Opik. Les trois sont sous licence Apache-2.0 ou MIT.

Voici l'audit. Huit frameworks passés au crible, plus trois autres que les pages les mieux classées sur cette requête recommandent encore.

Les dates correspondent au dernier commit sur la branche par défaut de chaque projet au 2026-08-04. La page GitHub du dépôt affiche le dernier push sur n'importe quelle branche, ce qui est plus récent pour deux projets ici : UpTrain 2024-08-18 et Deepchecks 2025-12-28. Aucun des deux dépôts n'est archivé.

La colonne coût de changement est celle que tout le monde ignore, avant de le regretter. Les scores ne sont que des nombres, donc passer de DeepEval à Ragas, Opik ou phoenix-evals revient surtout à réécrire une boucle. Quitter promptfoo ou Inspect AI implique de réécrire un format de config ou de tâche sans équivalent ailleurs, et quitter Evidently implique d'auditer chaque seuil que vous avez écrit, parce que son échelle fonctionne à l'envers. Deux des frameworks encore recommandés par les pages les mieux classées n'ont pas eu de nouvelle version depuis 2024.

Vous cherchez plutôt des niveaux, des plateformes hébergées et un classement direct ? C'est un autre exercice, et nous l'avons déjà fait dans notre comparatif classé des outils d'évaluation LLM, plateformes payantes incluses.

Les Huit Frameworks d'Évaluation LLM, Regroupés par Mode d'Installation

La forme d'installation, c'est ce avec quoi vous devez vivre au quotidien, d'où ce regroupement.

Bibliothèques Python à importer dans vos tests

DeepEval (pip install deepeval, Apache-2.0) enveloppe les métriques LLM dans des assertions façon pytest : construisez un LLMTestCase, passez-le à assert_test, et le test échoue en dessous de votre seuil. Le plus adapté pour placer une porte de qualité juste à côté des tests unitaires qu'une équipe fait déjà tourner. Choisissez cette option si vos evals doivent vivre dans le même job CI que tout le reste.

Une précision, formulée une seule fois : DeepEval est développé par Confident AI, partenaire payant sur deux autres articles de ce site, dont le comparatif classé que cette page cite. Ça ne lui vaut aucun traitement de faveur ici, et chaque lien DeepEval de cette page pointe vers le dépôt GitHub.

Ragas (pip install ragas, Apache-2.0) est l'option spécialisée RAG : evaluate() prend des lignes question, contexte et réponse et retourne des scores par métrique de façon asynchrone. Le plus adapté pour mesurer la qualité de récupération dans un pipeline Python. Son dépôt est passé de explodinggradients à vibrantlabsai, sa dernière version est v0.4.3 du 2026-01-13, et il n'y a plus eu de commit depuis 2026-02-24. Choisissez cette option si les métriques RAG sont tout votre travail et qu'un dépôt silencieux ne vous dérange pas, et consultez la pile d'outils RAG au sens large.

Opik (pip install opik, Apache-2.0, de Comet) fournit des métriques que vous pouvez appeler seules. Définissez OPIK_TRACK_DISABLE=true et AnswerRelevance().score() tourne sans compte, sans serveur local et sans fichier de config, ce que le positionnement produit ne met pas en avant. Le plus adapté pour obtenir un vrai score en un minimum de lignes. Choisissez cette option si vous voulez des métriques maintenant, et peut-être la plateforme plus tard.

Evidently (pip install evidently, Apache-2.0) traite les evals comme des descripteurs sur un dataset et génère un rapport HTML en effet secondaire. Le plus adapté pour du reporting par lots sur de nombreuses lignes plutôt qu'une porte binaire. Ses scores LLM sont inversés : 1.0 signifie infidèle. Choisissez cette option si ce que vous devez à quelqu'un est un rapport partageable, pas un build en rouge.

Giskard (pip install giskard, Apache-2.0) scanne un modèle à la recherche de vulnérabilités au lieu de noter un dataset que vous avez écrit. Le paquet PyPI résout la ligne v2, et le README du projet indique lui-même que la v2 « n'est plus activement maintenue ». Le plus adapté pour des scans automatisés façon red-team. Choisissez cette option si vous voulez qu'on trouve les vulnérabilités à votre place plutôt que des métriques LLM-as-a-judge que vous définissez vous-même.

Outils CLI-et-config à exécuter sur un fichier YAML

promptfoo (npm install promptfoo, MIT) est une CLI qui lit un fichier YAML : déclarez providers, cas de test et assertions, lancez npx promptfoo eval, et obtenez un pass/fail par cas plus une UI de résultats locale. Le plus adapté pour évaluer des prompts quand votre appli n'est pas écrite en Python. Choisissez cette option si votre porte de qualité doit être un fichier de config qu'un coéquipier non-Python peut modifier.

Classe Harness (Eval Harness) et Solutions Intégrées à une Plateforme

Inspect AI (pip install inspect-ai, MIT) vient de l'UK AI Safety Institute et évalue des modèles sur des tâches que vous définissez en Python, avec de vraies abstractions solver et scorer et un visualiseur d'exécutions. Le plus adapté pour du benchmarking au niveau modèle avec des définitions de tâches reproductibles. Choisissez cette option si ce que vous testez est un modèle plutôt que votre application.

Arize Phoenix (pip install arize-phoenix-evals) fournit des évaluateurs prêts à l'emploi comme FaithfulnessEvaluator et CorrectnessEvaluator, qui retournent une étiquette binaire plus un score. Le plus adapté pour des étiquettes déterministes sur lesquelles bloquer sans choisir de seuil. Sa licence est la raison pour laquelle cet article a une parenthèse dans son titre, et ça fait l'objet de la section suivante.

Arize Phoenix Est-il Open Source ?

Non, pas selon la définition maintenue par l'Open Source Initiative (OSI) — autrement dit, non approuvé OSI. Arize Phoenix est distribué sous Elastic License 2.0 (ELv2). La ligne 1 du fichier LICENSE du dépôt le confirme, et PyPI déclare indépendamment license: Elastic-2.0 sur la v19.15.0. Le code source est lisible, forkable et auto-hébergeable. Un seul usage est restreint.

La restriction qui compte : ELv2 interdit de fournir le logiciel à des tiers en tant que service hébergé ou managé. Lisez ça attentivement, parce que ça concerne beaucoup moins de monde qu'il n'y paraît. Si vous installez arize-phoenix-evals pour noter votre propre application, ELv2 ne vous concerne jamais. Si vous êtes un cabinet de conseil ou une équipe plateforme qui empaquette Phoenix dans un service d'évaluation vendu à des clients externes, ça vous concerne. C'est toute la différence, et c'est la Open Source Definition qu'ELv2 ne respecte pas, plus précisément les clauses sur les restrictions de champ d'usage.

Toutes les pages actuellement classées sur cette requête rangent Phoenix dans « open source », et c'était aussi notre cas. Notre propre comparatif classé des outils d'évaluation LLM décrit Phoenix comme entièrement open source, ce qui est faux, et c'est en cours de correction. Phoenix est source-available (code source disponible), pas open source, et la distinction ne mord que si vous comptez le vendre comme service. Si c'est du tracing plutôt que du scoring dont vous avez besoin, ça relève des plateformes d'observabilité IA, pas d'ici.

Lesquels Sont Encore Activement Maintenus ?

La plupart. Six des onze dépôts que nous avons vérifiés ont reçu un commit sur main le 2026-08-03 ou le 2026-08-04 : DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI et Giskard. Deux n'ont pas eu de nouvelle version depuis 2024. Un s'est tu en 2026 après un changement d'organisation GitHub.

Frameworks sur Lesquels Nous Ne Démarrerions Pas un Nouveau Projet en 2026

UpTrain est mort. Son dernier commit sur main remonte au 2024-07-29 et sa dernière version, v0.7.1, date du 2024-05-14, ce qui en fait un projet froid depuis deux ans sur les deux mesures. Le dépôt est toujours là et toujours sous Apache-2.0, donc rien ne vous en empêche, mais démarrer un nouveau projet sur une bibliothèque d'évaluation abandonnée est une décision que vous devrez justifier plus tard.

Deepchecks mérite la version précise des faits. Il n'a eu aucune nouvelle version depuis la 0.19.1 du 2024-12-15, bien que le dépôt reçoive encore des commits, le dernier sur main datant du 2025-11-24. Des gens continuent d'y travailler ; personne n'a coupé de version depuis plus de dix-huit mois. Ni UpTrain ni Deepchecks ne sont archivés sur GitHub, et aucun des deux n'est fermé aux contributions.

Ragas n'a droit qu'à des dates, rien de plus. Dernière version v0.4.3 le 2026-01-13, aucun commit depuis le 2026-02-24, et le dépôt est passé de explodinggradients à vibrantlabsai. Nous n'avons trouvé aucune explication vérifiable de ce changement d'organisation, et nous n'allons pas en inventer une. Un dépôt silencieux n'est pas un dépôt cassé : du code Apache-2.0 qui calcule un score de fidélité aujourd'hui le calculera encore l'an prochain. Le risque, ce sont les dépendances non patchées, exactement ce qui nous a mordus dans les tests ci-dessous.

D'autres pages en première page sur cette requête recommandent encore UpTrain et Deepchecks, sans aucune date associée à la recommandation. Un framework sans nouvelle version depuis décembre 2024 est une décision de dépendance, pas une décision de fonctionnalités.

Avez-Vous Besoin d'un Framework d'Évaluation ou d'un Eval Harness ?

Un framework d'évaluation applicative (application eval framework) note les propres sorties de votre appli face à vos propres données. DeepEval, Ragas, promptfoo, Opik, phoenix-evals et Evidently font tous ça. Un harness d'évaluation de modèle (model eval harness) benchmarke un modèle sur des tâches publiques standardisées à la place. lm-evaluation-harness et Inspect AI font ça. Se tromper de catégorie est l'erreur la plus coûteuse de cette page.

Le mode d'échec est concret. Quelqu'un branche lm-evaluation-harness pour tester son chatbot RAG, récupère une série de scores MMLU, et n'apprend précisément rien sur le fait que son retriever renvoie ou non les bons passages. Les scores sont réels. Ils mesurent le modèle de base, dont personne ne se souciait.

La forme d'Inspect AI découle de son origine : il a été construit à l'UK AI Safety Institute sous MIT pour évaluer des modèles de pointe, donc solvers, scorers et tasks y sont des citoyens de première classe, et votre application n'est pas un concept qu'il connaît. C'est une bonne raison de l'utiliser pour ce à quoi il sert. Si votre problème concerne des agents plutôt que des tours uniques, évaluer des agents en production relève d'une discipline encore différente, et les serveurs à appel d'outils ont droit à leur propre traitement dans notre guide sur l'évaluation des serveurs et outils MCP.

Ce Qui S'est Passé Quand Nous en Avons Installé Six et Testé les Mêmes 10 Cas

Le 2026-08-04, nous en avons installé six dans des venvs Python 3.11.14 fraîchement créés (plus npm pour promptfoo), et noté un même jeu RAG de 10 items avec un seul juge, openai/gpt-4o-mini via OpenRouter à température 0. Sept items étaient corrects. Trois étaient défaillants de trois manières différentes : l'un contredit son contexte, l'un invente des détails précis, l'un est une prose fluide qui ne répond jamais à la question. Chaque framework a tourné deux fois, dos à dos.

Cinq métriques de grounding sur six ont détecté les trois défauts. Les trois constats ci-dessous sont la raison d'être de cette section.

Les métriques de pertinence ne sont pas des métriques de qualité, et deux d'entre elles ont noté un mensonge assuré au-dessus d'une bonne réponse. Ragas ResponseRelevancy a noté à 0.777 l'item affirmant que HTTP 404 est une erreur serveur de classe 5xx, au-dessus de deux des sept bonnes réponses, et à 0.813 l'item aux limites de débit inventées, au-dessus de quatre. promptfoo answer-relevance a fait pareil : 0.800 pour l'item 404, un passage propre face à un seuil de 0.7, tout en faisant échouer la bonne réponse q01 à 0.679. Pas un bug. Une mauvaise réponse assurée d'elle-même répond parfaitement à la question posée. Mais si la pertinence est le chiffre affiché sur votre tableau de bord, une hallucination fluide ressemble à votre meilleure sortie.

Une porte basée uniquement sur la fidélité rate la réponse hors sujet. DeepEval a noté l'item qui ne répond jamais à la question à 1.000 de faithfulness, un passage propre, ce qui est défendable : une réponse qui n'affirme rien sur le contexte ne le contredit en rien. Seule la relevancy l'a détecté, à 0.000. C'est l'unique défaut de grounding manqué dans le tableau ci-dessus. Chaque métrique prise seule a un trou ; la paire couvre les deux.

Les évaluateurs binaires étaient stables à température 0. Les évaluateurs à score gradué, non. Phoenix et DeepEval n'ont fait bouger aucun des dix items sur deux runs identiques. Opik en a fait bouger quatre, tous sur AnswerRelevance, sur une grille de 0.05 ; Evidently aussi en a fait bouger quatre. Aucune dérive n'a fait basculer un verdict ici, mais la bonne réponse q01 de promptfoo est tombée à 0.679 puis 0.642 face à un seuil de 0.700, ce qui a exactement la forme d'une porte CI capricieuse.

Deux notes plus mineures : trois sur six (DeepEval, Opik, Phoenix) se sont installés et ont tourné proprement du premier coup, tandis que Ragas refusait de s'importer tant que nous n'avions pas pinné langchain-community<0.4. Seul promptfoo a rapporté l'usage de tokens du juge, 16 011 tokens d'assertion au run 1 et 16 010 au run 2.

Les limites de tout ça, dites clairement. n = 10 est un smoke test, pas un benchmark : ça vous renseigne sur l'ergonomie et les angles morts, pas sur la précision des métriques. Un seul modèle juge a tout noté, et un juge plus gros ferait bouger chaque chiffre, probablement y compris les deux faux positifs que DeepEval et Ragas ont tous deux produits sur le même item pourtant correct. Deux runs prouvent que la dérive existe, mais ne suffisent pas à la caractériser. Les réponses étaient pré-écrites, donc rien ici ne teste la génération, le tracing ou la gestion de dataset, ce qui fait paraître l'installation de 337.9 secondes de promptfoo pire qu'elle ne l'est vraiment. « Meilleur » veut toujours dire meilleur pour une contrainte donnée : une porte CI, des métriques RAG ou une UI changent chacun la réponse, tout comme le choix entre évaluation offline et online.

La Même Vérification, Écrite de Trois Façons

Le moyen le plus rapide de choisir une forme d'interface, c'est de lire la même assertion trois fois. Voici une vérification de grounding sur un item dans DeepEval, Ragas et promptfoo, extraite des scripts que nous avons réellement exécutés. Les noms des métriques diffèrent ; nous renvoyons vers comment fonctionnent réellement les métriques LLM-as-a-judge plutôt que de les redéfinir ici.

# DeepEval 4.1.5 : format pytest, le test échoue en dessous du seuil
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 : notez le chemin d'import. `from ragas.metrics import Faithfulness`
# lève une ImportError dans cette version ; la métrique concrète a été déplacée.
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, puis npx promptfoo eval
providers:
  - id: echo          # nous avons noté des réponses pré-écrites au lieu de les générer
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."

Les lignes d'installation cachent plus de pièges que le code, et chaque commentaire ci-dessous nous a fait perdre du temps le 2026-08-04 :

# Le vrai promptfoo est distribué sur npm. Le paquet PyPI du même nom est un
# wrapper tiers : https://pypi.org/project/promptfoo/ vs
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard résout la ligne v2, que le README du projet lui-même
# indique comme n'étant plus activement maintenue.
pip install giskard

# lm-evaluation-harness s'installe sous le nom de paquet lm-eval.
pip install lm-eval

# Evidently n'installe pas openai, et le juge plante au moment de l'appel
# plutôt qu'à l'import, une fois que vous avez déjà construit le dataset.
pip install evidently openai

# Ragas 0.4.3 ne s'importera pas avec langchain-community 0.4.x.
pip install ragas "langchain-community<0.4"

Peut-on Faire Échouer un Build sur un Score d'Éval ?

Oui. Chaque framework ici retourne un score numérique ou binaire, et chacun sortira avec un code non nul quand une assertion de seuil échoue, ce qui est tout ce dont GitHub Actions a besoin pour passer un build au rouge. Câbler le code de sortie est la partie facile. Choisir un seuil que votre modèle juge ne franchira pas par accident est la partie qui prend une semaine.

Voici la forme de workflow que nous exécutons, épinglée aux versions de notre test du 2026-08-04 :

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: Noter le golden set
        env:
          # Épinglez le juge. Une montée de version du modèle en plein trimestre fait bouger chaque score.
          JUDGE_MODEL: openai/gpt-4o-mini
          # Les seuils vivent à un seul endroit, lus par les constructeurs de métriques.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

Deux pièges mordent avant même le seuil. D'abord, les appels au juge sont des appels réseau : notre run DeepEval de 10 items a pris 126.8 secondes parce que .measure() est séquentiel, et un golden set de 200 items sur ce chemin de code devient une pause café à chaque pull request. Tous les autres frameworks du test parallélisent par défaut, ce qui est le levier le plus important sur le temps d'exécution CI.

Ensuite, la volatilité. À température 0, Opik et Evidently ont chacun fait bouger quatre items sur dix entre deux runs consécutifs, et la bonne réponse de promptfoo s'est posée à 0.679 puis 0.642 face à une porte de 0.700. Les mitigations sont ennuyeuses et elles fonctionnent : faites tourner un golden dataset fixe qui ne change que par pull request, épinglez le modèle juge, préférez des évaluateurs binaires quand une étiquette suffit, et bloquez sur un delta plutôt qu'un plancher absolu. Ce dernier point compte le plus pour l'évaluation multi-turn, où une seule conversation produit de nombreux scores qui peuvent chacun vaciller.

Pour donner une échelle : l'enquête State of Agent Engineering de LangChain (1 340 réponses, collectées du 18 novembre au 2 décembre 2025, publiée le 12 juin 2026) a trouvé que 89 % des organisations ont mis en place une forme d'observabilité pour leurs agents, tandis que seulement 52.4 % exécutent des évaluations offline sur des jeux de test. Regarder est courant. Bloquer ne l'est pas.

Ce Que Nous Installerions Cette Semaine

Quatre points à retenir. Arize Phoenix est source-available sous Elastic License 2.0 et n'est pas open source au sens approuvé par l'OSI, ce qui ne change rien pour la plupart des lecteurs et change tout si vous revendez de l'outillage d'évaluation. UpTrain est mort, et des pages sans aucune date continuent de le recommander. Deepchecks non plus n'a pas eu de nouvelle version depuis décembre 2024 ; son dépôt, cela dit, reçoit toujours des commits. Une métrique de grounding et une métrique de pertinence ont chacune un trou que l'autre couvre, donc bloquez sur les deux. Et les scores gradués dérivent à température 0, donc épinglez votre juge et laissez de la marge à vos seuils.

Si je démarrais une nouvelle suite d'évaluation cette semaine, j'installerais DeepEval pour la porte CI, parce que les assertions ont leur place juste à côté des tests (précision ci-dessus), et j'ajouterais les métriques autonomes d'Opik pour la séparation la plus nette que nous avons mesurée. Si notre stack n'était pas Python, ce serait promptfoo, sans hésiter. Si vous préférez que quelqu'un d'autre câble le golden set et le workflow, c'est une conversation que nous avons plaisir à avoir.

Questions Fréquentes

Quel Est le Meilleur Framework d'Évaluation LLM Open Source ?

Il n'y a pas un seul gagnant, juste le meilleur choix selon votre contrainte. Pour une porte pass/fail dans une suite de tests Python, DeepEval. Pour une configuration YAML et CLI indépendante du langage, promptfoo. Pour des métriques de récupération RAG, Ragas, si vous acceptez un dépôt sans commit depuis le 2026-02-24. Pour la séparation la plus nette entre bonnes et mauvaises réponses dans notre test du 2026-08-04, Opik.

Arize Phoenix Est-il Open Source ?

Pas selon la définition de l'Open Source Initiative — non approuvé OSI. Arize Phoenix est distribué sous Elastic License 2.0, que PyPI déclare comme license: Elastic-2.0 sur la v19.15.0 et que la ligne 1 du fichier LICENSE du dépôt affirme directement. C'est du source-available : vous pouvez le lire, le forker, le modifier et l'auto-héberger. La seule restriction est d'offrir le logiciel à des tiers en tant que service hébergé ou managé.

Ragas Est-il Encore Maintenu ?

Les faits vérifiables, au 2026-08-04 : la dernière version était la v0.4.3 du 2026-01-13, il n'y a plus eu de commit depuis le 2026-02-24, et le dépôt est passé de l'organisation explodinggradients à vibrantlabsai. Le dépôt n'est pas archivé. Nous n'avons trouvé aucune explication publique fiable de ce changement d'organisation et nous ne spéculerons pas. Le code Apache-2.0 tourne toujours ; le risque, ce sont les dépendances non patchées.

Ai-je Besoin d'un Framework d'Évaluation ou d'une Plateforme d'Observabilité ?

Les deux, à terme, mais ils répondent à des questions différentes. Un framework d'évaluation vous dit si un changement a amélioré ou dégradé vos sorties avant que vous ne le déployiez, sur un dataset que vous contrôlez. Une plateforme d'observabilité vous dit ce qui s'est réellement passé en production après le déploiement. Commencez par le framework d'évaluation si vous avez un pipeline CI ; consultez les plateformes d'observabilité IA pour le volet production.

Puis-je Exécuter des Évals LLM en CI/CD ?

Oui. Chaque framework couvert ici sort avec un code non nul quand une assertion de seuil échoue, ce qui est tout ce dont un job GitHub Actions a besoin. Les contraintes pratiques sont le temps d'exécution réel (les appels au juge sont des appels réseau, et notre run DeepEval séquentiel a pris 126.8 secondes pour 10 items) et le non-déterminisme du juge. La forme du workflow et les mitigations sont dans la section CI ci-dessus.

Quelle Est la Différence Entre DeepEval et Ragas ?

La forme d'interface et le périmètre, pas la qualité. DeepEval est de forme pytest et à usage général : vous écrivez des cas de test et vérifiez des seuils de métrique, et il couvre des sorties applicatives de toutes sortes. Ragas est une bibliothèque spécialisée RAG dont evaluate() tourne de façon asynchrone sur un dataset de lignes question, contexte et réponse. DeepEval s'intègre plus naturellement à une porte CI ; Ragas va plus loin sur la récupération.

Pourquoi pip install promptfoo Installe-t-il le Mauvais Paquet ?

Parce que promptfoo est un projet Node. Le vrai projet est publié sur npm sous MIT et s'installe avec npm install promptfoo. Le paquet PyPI du même nom est un wrapper tiers, pas le projet upstream, et l'installer est un moyen courant de finir par déboguer une CLI qui n'est pas celle décrite par la documentation.

lm-evaluation-harness Est-il un Framework d'Évaluation LLM ?

C'est un harness d'évaluation de modèle, une tâche voisine mais différente. lm-evaluation-harness (installé via pip install lm-eval) benchmarke un modèle sur des tâches publiques standardisées comme MMLU. Il ne vous dira pas si votre pipeline de récupération a renvoyé le bon passage, parce que votre application n'est pas un concept qu'il connaît. Consultez la section framework-contre-harness ci-dessus pour la distinction.

Ces Frameworks Sont-ils Gratuits ?

Côté licence, oui. DeepEval, Ragas, Opik, Evidently et Giskard sont sous Apache-2.0 ; promptfoo, Inspect AI et lm-evaluation-harness sont sous MIT. Les deux licences autorisent l'usage commercial, la modification et la redistribution. Arize Phoenix fait exception : Elastic License 2.0 autorise l'auto-hébergement mais pas le fait d'offrir le logiciel à des tiers en tant que service managé. L'usage de l'API du modèle juge est facturé séparément par votre fournisseur.