2026年ベストのオープンソースLLM評価フレームワーク（1つは実はオープンソースではない）

2026年ベストのオープンソースLLM評価フレームワーク（1つは実はオープンソースではない）

Arize PhoenixリポジトリのLICENSEファイル1行目には「Elastic License 2.0 (ELv2)」と書かれている。Apacheではない。MITでもない。広く推奨されているオープンソースLLM評価フレームワークの1つが、OSIの定義ではオープンソースではなく、このクエリで上位表示されているほぼすべてのページがそれでも同じ主張を繰り返している。今日までは、うちのページもそうだった。2026-08-04、私たちは8つのフレームワークのライセンスファイルとデフォルトブランチのコミットログを手作業で読み、さらに上位ページがいまだに推奨する3つも加えて調べ、そのうち6つを実際にインストールして同じ10件のケースを流した。私たちは評価フレームワークを販売していないので、以下のどの評価も自社製品を守るためのものではない。

要点まとめ

• Arize PhoenixはElastic License 2.0の下で提供されており、OSIはこれをオープンソースとして承認していない。
• UpTrainのmainへの最終コミットは2024-07-29。これから新規プロジェクトで使い始めるのはやめたほうがいい。
• pip install promptfooはサードパーティ製のラッパーを入れてしまう。本物のプロジェクトはnpmで配布されている。
• Ragasは2026-02-24以降コミットがなく、GitHubの所属組織もvibrantlabsaiに移った。

2026年、どのオープンソースLLM評価フレームワークをインストールすべきか？

ランキングではなく制約で選ぶこと。既存のテストスイートにpytest形式のアサーションを組み込みたいならDeepEvalを入れる。どの言語スタックにも合うYAML設定とCLIが欲しいならpromptfooを入れる。私たちが計測した中で良い回答と悪い回答の分離がもっとも綺麗だったのはOpikだ。3つともApache-2.0かMITだ。

以下が監査結果だ。対象は8フレームワーク、それに加えてこのクエリで上位表示されているページがいまだに推奨する3つを含む。

日付はすべて2026-08-04時点での各プロジェクトのデフォルトブランチへの最終コミット。GitHubのリポジトリページに表示される「最終プッシュ」はどのブランチも含むため、この2プロジェクトではより新しい日付になる：UpTrain 2024-08-18、Deepchecks 2025-12-28。どちらのリポジトリもアーカイブされていない。

乗り換えコストの列は、みんな読み飛ばして後で後悔する部分だ。スコアはただの数値なので、DeepEval、Ragas、Opik、phoenix-evalsの間を移動するのは基本的にループを書き換えるだけで済む。promptfooやInspect AIから乗り換えるとなると、他に相当するものがない設定形式やタスク形式を書き直すことになるし、Evidentlyから乗り換えるなら、スコアの尺度が逆なので書いた閾値を全部見直す必要がある。上位表示ページがいまだに推奨するフレームワークのうち2つは、2024年以降リリースを出していない。

ティア分けやホスティング型プラットフォーム、単純な順位付けが欲しいなら、それは別の仕事で、すでに有料プラットフォームも含むLLM評価ツールのランキング比較で扱っている。

8つのLLM評価フレームワークを、インストール方法別に分類する

インストールの形は使い続ける限りずっと付き合うことになるので、それを基準にグループ分けした。

テストにインポートするPythonライブラリ

DeepEval（pip install deepeval、Apache-2.0）は、LLMのメトリクスをpytest形式のアサーションでラップする。LLMTestCaseを組み立ててassert_testに渡すと、閾値を下回った時点でテストが失敗する。チームがすでに運用しているユニットテストの隣に品質ゲートを置くのに向いている。評価を他のすべてと同じCIジョブに入れたいならこれを選ぶ。

一度だけ開示しておく。DeepEvalはConfident AIが開発しており、Confident AIはこのサイトの他の2記事（このページがリンクしているランキング比較記事を含む）で有料パートナーになっている。本稿での扱いに特別待遇はなく、このページ内のDeepEvalへのリンクはすべてGitHubリポジトリを指している。

Ragas（pip install ragas、Apache-2.0）はRAG特化のオプションだ。evaluate()が質問・コンテキスト・回答の行を受け取り、メトリクスごとのスコアを非同期に返す。Pythonパイプライン内での検索品質測定に向いている。リポジトリはexplodinggradientsからvibrantlabsaiに移り、最終リリースはv0.4.3（2026-01-13）、2026-02-24以降コミットはない。RAGメトリクスがすべてで、静かなリポジトリでも構わないならこれを選ぶ。より広いRAGツールスタックも参照。

Opik（pip install opik、Apache-2.0、Comet提供）は単体で呼び出せるメトリクスを提供している。OPIK_TRACK_DISABLE=trueを設定すれば、AnswerRelevance().score()はアカウントもローカルサーバーも設定ファイルも不要で動く。これは製品の宣伝文句には出てこない事実だ。最少の行数で実際のスコアを得るのに向いている。今すぐメトリクスが欲しくて、プラットフォームは後回しでいいならこれを選ぶ。

Evidently（pip install evidently、Apache-2.0）は評価をデータセットに対するディスクリプタとして扱い、副産物としてHTMLレポートを書き出す。二値のゲートよりも大量行にわたるバッチレポーティングに向いている。LLMスコアは逆転しており、1.0は「忠実でない」を意味する。誰かに渡すべきものが赤くなったビルドではなく共有可能なレポートなら、これを選ぶ。

Giskard（pip install giskard、Apache-2.0）は、自分で書いたデータセットをスコアリングする代わりに、モデルの脆弱性をスキャンする。PyPIパッケージはv2系を解決し、プロジェクト自身のREADMEはv2について「もう積極的にメンテナンスされていない」と述べている。自動レッドチーム形式のスキャンに向いている。自分で定義するLLM-as-a-judgeメトリクスより、脆弱性を見つけてもらいたいならこれを選ぶ。

YAMLファイルに対して実行するCLI＋設定型ツール

promptfoo（npm install promptfoo、MIT）はYAMLファイルを読み込むCLIだ。プロバイダー、テストケース、アサーションを宣言し、npx promptfoo evalを実行すれば、ケースごとのpass/failとローカルの結果UIが得られる。アプリがPython製でない場合のプロンプト評価に向いている。品質ゲートを、Python未経験のチームメイトでも編集できる設定ファイルにしたいならこれを選ぶ。

ハーネス級＋プラットフォーム同梱型

Inspect AI（pip install inspect-ai、MIT）は英国AI Safety Instituteが手がけており、Pythonで定義したタスクに対してモデルを評価する。本格的なsolverとscorerの抽象化、実行ビューアを備える。再現可能なタスク定義によるモデルレベルのベンチマークに向いている。テスト対象がアプリケーションではなくモデルそのものならこれを選ぶ。

Arize Phoenix（pip install arize-phoenix-evals）は、FaithfulnessEvaluatorやCorrectnessEvaluatorといった組み込み評価器を提供し、二値ラベルとスコアを返す。カットオフを自分で決めなくてもゲートできる決定論的なラベルに向いている。このライセンスこそ、本稿のタイトルに括弧書きが付いている理由で、次のセクションで単独に扱う。

Arize Phoenixはオープンソースなのか？

いいや、Open Source Initiativeが定める定義では違う。Arize Phoenixは**Elastic License 2.0 (ELv2)**の下で提供されている。リポジトリのLICENSEファイルの1行目にそう書かれており、PyPIもv19.15.0でlicense: Elastic-2.0と独自に宣言している。ソースコードは読めるし、フォークもセルフホストもできる。制限されているのは1つの使い方だけだ。

重要な制限はこれだ。ELv2は、このソフトウェアをホスティング型・マネージド型サービスとして第三者に提供することを禁じている。よく読んでほしい。見た目ほど多くの人を縛るものではないからだ。arize-phoenix-evalsを自社アプリケーションのスコアリングに使うだけなら、ELv2はまったく関係ない。コンサルティング会社やプラットフォームチームがPhoenixを外部顧客に売る評価サービスに組み込むなら、話は別だ。それが差分のすべてで、ELv2が満たしていないのはOpen Source Definition、具体的には利用分野の制限に関する条項だ。

このクエリで現在上位表示されているページはすべてPhoenixを「オープンソース」に分類しており、私たちも同じだった。自社のLLM評価ツールのランキング比較ではPhoenixを完全なオープンソースと書いていたが、これは誤りで、現在修正中だ。Phoenixはソースアベイラブル（source-available）であり、オープンソースではない。この違いが問題になるのは、サービスとして販売するつもりがある場合だけだ。 本当に必要なのがスコアリングではなくトレーシングなら、それは本稿ではなくAIオブザーバビリティプラットフォームの話だ。

この中で今も活発にメンテナンスされているのはどれか？

ほとんどはそうだ。確認した11リポジトリのうち6つ、DeepEval、promptfoo、Opik、Arize Phoenix、Inspect AI、Giskardは2026-08-03か2026-08-04にmainへコミットが入っている。2つは2024年以降リリースを出していない。1つはGitHubの組織移動後、2026年に入って静かになっている。

2026年に新規プロジェクトで使い始めないフレームワーク

UpTrainは死んでいる。mainへの最終コミットは2024-07-29、最終リリースのv0.7.1は2024-05-14で、どちらの指標で見ても2年間動きがない。リポジトリ自体はまだ存在していてApache-2.0のままなので使うこと自体は止められないが、放棄された評価ライブラリで新しく作業を始めれば、後でその判断について説明する羽目になる。

Deepchecksには正確なバージョンを添えておく必要がある。0.19.1（2024-12-15）以降リリースはないが、リポジトリは今もコミットを受け付けており、mainへの最終コミットは2025-11-24だ。People are still working on it（人々は今も取り組んでいる）。ただし、18か月以上バージョンを切っていない。UpTrainもDeepchecksもGitHub上でアーカイブされておらず、どちらもコントリビューションを締め切ってはいない。

Ragasについては日付以外語ることがない。最終リリースはv0.4.3（2026-01-13）、2026-02-24以降コミットはなく、リポジトリはexplodinggradientsからvibrantlabsaiに移った。組織が変わった理由について検証可能な情報は見つからなかったので、憶測は書かない。静かなリポジトリは壊れたリポジトリではない。今日faithfulnessスコアを計算するApache-2.0のコードは、来年も同じように計算する。リスクは未パッチの依存関係で、まさにそれが下のテストで私たちを刺した。

このクエリの検索結果1ページ目にある他のページは、いまだにUpTrainとDeepchecksの両方を推奨しており、その推奨に日付は添えられていない。2024年12月以降リリースがないフレームワークは、機能の判断ではなく依存関係の判断になる。

必要なのは評価フレームワークか、評価ハーネスか？

アプリケーション評価フレームワークは、自社アプリの出力を自社データに対してスコアリングする。DeepEval、Ragas、promptfoo、Opik、phoenix-evals、Evidentlyはすべてこれにあたる。モデル評価ハーネスは代わりに、標準化された公開タスクに対してモデルをベンチマークする。lm-evaluation-harnessとInspect AIがこれにあたる。どちらのクラスを選ぶかを間違えるのが、本稿で最もコストの高いミスだ。

失敗のパターンは具体的だ。誰かがRAGチャットボットのテストにlm-evaluation-harnessを組み込み、MMLUのスコアを一式受け取るが、リトリーバーが正しいパッセージを返しているかどうかについては何一つ分からない。スコア自体は本物だ。ただ測っているのはベースモデルであり、そこは誰も心配していなかった部分だ。

Inspect AIの形は、その出自から来ている。フロンティアモデルを評価するために英国AI Safety InstituteがMITで開発したもので、solver、scorer、taskがファーストクラスの概念であり、アプリケーションという概念自体を持っていない。だからこそ、本来の用途で使うぶんには理にかなっている。単発のやり取りではなくエージェントが問題なら、本番環境でのエージェント評価はまた別の分野で、ツール呼び出しサーバーについてはMCPサーバー・ツールの評価ガイドで個別に扱っている。

6つを実際にインストールし、同じ10件を流した結果

2026-08-04、私たちはこのうち6つを新規のPython 3.11.14 venv（promptfooはnpm）にインストールし、同一の10件RAGセットを、judgeにはopenai/gpt-4o-miniをOpenRouter経由・temperature 0で使って採点した。7件は正解だった。3件はそれぞれ違う形で壊れていた。1件はコンテキストと矛盾し、1件は具体的な情報をでっち上げ、1件は流暢な文章ながら質問に一切答えていない。各フレームワークは連続で2回実行した。

6つのうち5つのgrounding指標は3件の欠陥すべてを検出した。以下の3つの発見が、このセクションが存在する理由だ。

関連性メトリクスは品質メトリクスではない。しかも2つは、自信満々の嘘を正解より高く評価した。 RagasのResponseRelevancyは、HTTP 404を5xxサーバーエラーだと主張する項目を0.777と採点し、これは7件の正解のうち2件より高いスコアだった。存在しないレートリミットをでっち上げた項目には0.813を付け、これは4件の正解より高い。promptfooのanswer-relevanceも同じことをした。404の項目には0.800を付け、0.7の閾値をきれいにクリアした一方、正解のq01は0.679で不合格になった。バグではない。自信満々の間違った回答は、質問に完璧に「応答」している。しかし関連性がダッシュボードに表示される数値なら、流暢なハルシネーションは最良の出力に見えてしまう。

faithfulnessだけのゲートは無関係な回答を見逃す。DeepEvalは質問に一切答えていない項目にfaithfulness 1.000を付け、クリーンな合格とした。これは筋が通っている。コンテキストについて何も主張していない回答は、コンテキストの何とも矛盾しないからだ。それを検出できたのはrelevancyだけで、スコアは0.000だった。これが上の表にある唯一のgrounding見逃しだ。どちらのメトリクスも単体では穴があるが、2つ組み合わせれば両方カバーできる。

二値評価器はtemperature 0で安定していた。段階評価のものはそうではなかった。PhoenixとDeepEvalは、同一条件で2回実行しても10件中0件しか値がぶれなかった。Opikは4件動いており、すべてAnswerRelevanceで0.05刻みの範囲内。Evidentlyも4件動いた。今回はぶれによって判定が反転することはなかったが、promptfooの正解であるq01は0.679から0.642へと動き、0.700の閾値に対しては不安定なCIゲートの典型的な形になっている。

細かい点を2つ。6つのうち3つ（DeepEval、Opik、Phoenix）はインストールも実行も1回目からクリーンに通ったが、Ragasはlangchain-community<0.4を固定するまでインポートできなかった。judgeのトークン使用量を報告したのはpromptfooだけで、run1が16,011アサーショントークン、run2が16,010アサーショントークンだった。

この検証の限界について、率直に述べておく。 n=10はスモークテストであってベンチマークではない。分かるのは使い勝手や盲点であって、メトリクスの精度ではない。すべてを1つのjudgeモデルで採点しており、より大きなjudgeを使えばすべての数値が動くはずだ。おそらくDeepEvalとRagasが同じ正解項目で共に出した2件の偽陽性も含めて。2回の実行はぶれが存在することを証明するだけで、その性質までは特徴づけられない。回答は事前に書いたものなので、生成もトレーシングもデータセット管理も一切試していない。そのせいでpromptfooの337.9秒というインストール時間は、実際よりも悪く見えている。「ベスト」は常に「ある制約に対してのベスト」を意味する。CIゲート、RAGメトリクス、UIのどれを重視するかで答えは変わるし、オフライン評価とオンライン評価のどちらを選ぶかによっても変わる。

同じチェックを3通りの書き方で

インターフェースの形を見極める一番早い方法は、同じアサーションを3回読むことだ。ここではDeepEval、Ragas、promptfooそれぞれで1件のgroundingチェックを、実際に動かしたスクリプトから抜粋して示す。メトリクス名はそれぞれ異なるが、ここで再定義する代わりにLLM-as-a-judgeメトリクスの実際の仕組みにリンクしておく。

# DeepEval 4.1.5: pytest形式、閾値を下回るとテストが失敗する
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: インポートパスに注意。`from ragas.metrics import Faithfulness`は
# このバージョンではImportErrorになる。具体的なメトリクスが移動した。
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 の後、npx promptfoo eval
providers:
  - id: echo          # we scored pre-written answers instead of generating them
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."

インストール行のほうがコードより罠が多い。以下のコメントはすべて、2026-08-04に私たちの時間を実際に食ったものだ。

# 本物のpromptfooはnpmで配布されている。同名のPyPIパッケージは
# サードパーティ製のラッパー: https://pypi.org/project/promptfoo/ 対
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskardはv2系を解決するが、プロジェクト自身のREADMEは
# これをもう積極的にメンテナンスしていないとしている。
pip install giskard

# lm-evaluation-harnessはパッケージ名lm-evalとしてインストールされる。
pip install lm-eval

# Evidentlyはopenaiを自動では入れない。judgeはインポート時ではなく
# 呼び出し時にクラッシュする。つまりデータセットを組み終えた後だ。
pip install evidently openai

# Ragas 0.4.3はlangchain-community 0.4.x系に対してインポートできない。
pip install ragas "langchain-community<0.4"

評価スコアでビルドを失敗させられるか？

できる。ここで挙げたすべてのフレームワークは数値または二値のスコアを返し、閾値アサーションが失敗すると終了コードが非ゼロになる。GitHub Actionsがビルドを赤くするのに必要なのはそれだけだ。終了コードを配線するのは簡単な部分だ。judgeモデルがうっかり超えてしまわない閾値を選ぶのが、1週間かかる部分だ。

以下は私たちが実際に運用しているワークフローの形で、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: ゴールデンセットを採点
        env:
          # judgeを固定する。四半期の途中でモデルが変わるとすべてのスコアが動く。
          JUDGE_MODEL: openai/gpt-4o-mini
          # 閾値は1か所にまとめてあり、メトリクスのコンストラクタから読まれる。
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

閾値にたどり着く前に噛みついてくる罠が2つある。1つ目、judge呼び出しはネットワーク呼び出しだ。私たちの10件のDeepEval実行が126.8秒かかったのは.measure()が逐次実行だからで、この経路のまま200件のゴールデンセットを流せば、プルリクエストのたびにコーヒーブレイクになる。テストした他のフレームワークはすべてデフォルトで並列実行するので、これがCIの実時間を左右する最大のレバーだ。

2つ目、不安定さだ。temperature 0でも、Opikは10件中4件、Evidentlyも10件中4件が連続実行の間に値がぶれ、promptfooの正解回答は0.700のゲートに対して0.679から0.642へと動いた。対策は地味だが効く。プルリクエストごとにしか変わらない固定のゴールデンデータセットを使う、judgeモデルを固定する、ラベルで十分な場面では二値評価器を優先する、絶対的な下限ではなく差分でゲートする。最後のポイントはマルチターン評価で特に重要だ。1つの会話が複数のスコアを生み、それぞれがぶれうるからだ。

規模感として、LangChainのState of Agent Engineering調査（回答1,340件、2025年11月18日〜12月2日実施、2026年6月12日公開）によれば、組織の89%が何らかの形でエージェントのオブザーバビリティを導入している一方、テストセットに対するオフライン評価を実行しているのはわずか52.4%だった。見張ることは一般的だが、ゲートすることはそうではない。

今週インストールするならこれ

持ち帰るべきことは4つ。Arize PhoenixはElastic License 2.0の下でのソースアベイラブルで、OSI承認のオープンソースではない。これはほとんどの読者にとっては何も変えないが、評価ツールを再販するなら話は全く別だ。UpTrainは死んでおり、日付のないページはいまだにこれを推奨している。Deepchecksも2024年12月以降リリースを切っていないが、リポジトリは今もコミットを受け付けている。groundingメトリクスと関連性メトリクスは互いの穴を補い合うので、両方でゲートすること。そして段階評価のスコアはtemperature 0でもぶれるので、judgeを固定し閾値には余裕を持たせること。

もし今週新しく評価スイートを組むなら、アサーションはテストの隣に置くべきだという理由でDeepEvalをCIゲートに使い（開示済みの件は上記の通り）、私たちが計測した中で最も綺麗な分離を見せたOpikの単体メトリクスを追加する。スタックがPythonでないなら、迷わずpromptfooだ。ゴールデンセットとワークフローの配線を他の誰かに任せたいなら、お気軽にご相談ください。

よくある質問

最良のオープンソースLLM評価フレームワークは何か？

唯一の勝者はいない。あるのは制約ごとのベストフィットだけだ。Pythonテストスイート内のpass/failゲートならDeepEval。言語を問わないYAML＋CLI構成ならpromptfoo。RAG検索メトリクスならRagas。ただし2026-02-24以降コミットがないリポジトリを受け入れられればの話だ。私たちの2026-08-04のテストで良い回答と悪い回答の分離が最も綺麗だったのはOpikだ。

Arize Phoenixはオープンソースか？

Open Source Initiativeの定義では違う。Arize PhoenixはElastic License 2.0の下で提供されており、PyPIはv19.15.0でlicense: Elastic-2.0と宣言し、リポジトリのLICENSEファイルの1行目も直接そう述べている。ソースアベイラブル（source-available）だ。読める、フォークできる、改変できる、セルフホストできる。唯一の制限は、このソフトウェアをホスティング型・マネージド型サービスとして第三者に提供することだ。

Ragasは今もメンテナンスされているか？

2026-08-04時点で検証可能な事実はこうだ。最終リリースはv0.4.3（2026-01-13）、2026-02-24以降コミットはなく、リポジトリはexplodinggradients組織からvibrantlabsai組織に移った。リポジトリはアーカイブされていない。組織変更について信頼できる公開説明は見つからなかったので、推測は書かない。Apache-2.0のコードは今も動く。リスクは未パッチの依存関係だ。

必要なのは評価フレームワークか、オブザーバビリティプラットフォームか？

最終的には両方必要になるが、答える問いが違う。評価フレームワークは、リリース前に、自分で管理するデータセットに対して、変更が出力を良くしたか悪くしたかを教えてくれる。オブザーバビリティプラットフォームは、リリース後の本番環境で実際に何が起きたかを教えてくれる。CIパイプラインがあるなら評価フレームワークから始めるといい。本番側についてはAIオブザーバビリティプラットフォームを参照。

CI/CDでLLM評価を実行できるか？

できる。ここで扱ったすべてのフレームワークは、閾値アサーションが失敗すると非ゼロで終了する。GitHub Actionsのジョブに必要なのはそれだけだ。実務上の制約は実時間（judge呼び出しはネットワーク呼び出しであり、私たちの逐次DeepEval実行は10件で126.8秒かかった）とjudgeの非決定性だ。ワークフローの形と対策は上のCIセクションにある。

DeepEvalとRagasの違いは何か？

品質の差ではなく、インターフェースの形とスコープの差だ。DeepEvalはpytest形式の汎用ツールで、テストケースを書いてメトリクスの閾値をアサートし、さまざまな種類のアプリケーション出力をカバーする。RagasはRAG特化のライブラリで、evaluate()が質問・コンテキスト・回答の行から成るデータセットに対して非同期に実行される。DeepEvalの方がCIゲートに自然に馴染み、Ragasの方が検索まわりを深く掘り下げる。

なぜpip install promptfooだと間違ったパッケージが入るのか？

promptfooがNodeのプロジェクトだからだ。本物はnpm上でMITライセンスで公開されており、npm install promptfooでインストールする。同名のPyPIパッケージは本家プロジェクトではなくサードパーティ製のラッパーで、これを入れてしまうと、ドキュメントに書かれているのとは別物のCLIをデバッグする羽目になりがちだ。

lm-evaluation-harnessはLLM評価フレームワークか？

モデル評価ハーネスであり、関連はしているが違う仕事だ。lm-evaluation-harness（pip install lm-evalでインストールする）は、MMLUのような標準化された公開タスクに対してモデルをベンチマークする。検索パイプラインが正しいパッセージを返したかどうかは分からない。なぜならアプリケーションという概念自体を持っていないからだ。両者の違いについては上のフレームワーク対ハーネスのセクションを参照。

これらのフレームワークは無料で使えるか？

ライセンス上は無料だ。DeepEval、Ragas、Opik、Evidently、GiskardはApache-2.0、promptfoo、Inspect AI、lm-evaluation-harnessはMITだ。どちらのライセンスも商用利用、改変、再配布を許可している。例外はArize Phoenixで、Elastic License 2.0はセルフホストは許可するが、マネージドサービスとして第三者に提供することは許可していない。judgeモデルのAPI利用料は、プロバイダーから別途請求される。