DeepEval

DeepEvalは、LLMアプリケーションをtest case、dataset、metric、traceに基づいて評価し、pytest/CIへ組み込めるオープンソースの評価フレームワークである。現在の公式ドキュメントでは、end-to-end、trajectory-based、component-levelの評価を扱い、agent、multi-turn chatbot、voice、RAG、MCP、tool-use等を対象にする。

ただしDeepEvalは客観的な「正解判定器」ではない。評価結果は、dataset、metric/classifier、judge model、threshold、trace scope、DeepEval version、target versionなどの組合せで成立する証拠であり、本番品質・安全性・法令適合を包括的に保証しない。

end-to-end評価は外部から見た結果を測り、trajectory-based評価はagentの計画・model call・tool call・handoff等の順序を含む実行経路を測り、component-level評価はtrace内の個別spanやtool、retriever等を測る。これらは相互代替ではない。

componentのscoreが良好でもwhole-system successは確定せず、end-to-end scoreだけでは内部failureの局在化はできない。trajectory評価も、観測されていない副作用や業務transactionの正しさまで自動的に証明するものではない。

現行公式metric documentationでは50+のmetricがあり、ほぼすべてのpredefined metricがLLM-as-a-judgeを使う。scoreとthresholdによるsuccess/failureは、設定された評価規則の結果である。

したがってthreshold変更、judge変更、rubric/template変更、provider挙動の変化によって、target outputが同じでも判定が変わり得る。G-Eval等の主観評価系を、deterministicなoracleとして扱わない。

DeepEvalはlocal-firstで、accountなしでも実行できる。しかしLLM judgeを使うmetricではjudge providerへの通信が発生し得る。Confident AIへsign-inした環境ではtest resultやtraceのupload経路が別に存在する。

現行local backend documentationではJSONまたはSQLiteへrunを保存できる一方、Confident AIへlogged-inの場合はlocal backendを選んでもtest runがuploadされる。local persistenceの採用だけで「外部送信なし」と判断してはならない。

benchmarkはtask/dataset、scorer、few-shot/CoT等のprompting条件を含む。比較時はDeepEval version、target model/API revision、judge、metric、threshold、dataset hash、prompting、trace scope、cache/retry/error policyを固定または記録する。

条件が変わったrun同士を、targetだけが変わった比較として扱わない。

DeepEvalのquality evaluationと、DeepTeamによるsecurity/red-team testingは別のevidence surfaceである。selected attackでred-team testを通過しても、未選択attackやsystem外部の脆弱性が不存在とは言えない。

Confident AIのcommercial/enterprise surfaceもOSS DeepEvalの機能保証と分離する。SSO、RBAC、audit、self-host、retention、region等は、契約・plan・tenant configurationの一次証拠なしに利用可能と断定しない。

• judge driftやprovider/model更新でscore distributionが変わる。
• threshold変更だけでpass/failが反転する。
• weak/biased goldensによりCIがgreenでも重要failureを検出できない。
• rate limit、timeout、cache、async/concurrency errorをmodel-quality failureと誤認する。
• trace instrumentation不足によりhidden state、副作用、tool外処理を観測できない。
• local storeを設定したことでcloud uploadやjudge-provider egressも止まったと誤認する。
• evaluator upgradeとtarget upgradeを同時に行い、差分原因を分離できなくなる。
• test codeとして動くcustom metric/callbackやagent toolに過剰権限を与える。

• DeepEval version、target version、judge provider/model、metric/classifier、threshold、custom rubric/template、dataset hash、trace scopeをrun artifactへ記録する。
• evaluator upgradeとtarget upgradeを別changeとして検証し、judge/model/metric変更後はbaselineを再確立する。
• deterministic/bounded checkとLLM-judged metricを別系列で報告する。
• execution error、rate-limit、timeout、transport failureをquality scoreと混同しない。
• JSON/SQLite等のlocal persistence、Confident AI sign-in/upload、judge-provider通信、telemetryを別々のdata-flowとして確認する。
• CI gateはall-greenだけでなく、seeded failureを期待どおり検出できるかを検査する。
• agent/tool evaluationではsandboxed non-production fixtureを使い、real secretやdestructive actionを評価fixtureへ持ち込まない。
• audit artifactとしてconfig、dataset hash、metric definition、judge、threshold、target revision、timestamps、error count、result artifactを保持する。

DeepEvalの評価能力が広いことは、任意の業務品質を自動的に測定できることを意味しない。評価対象をtest caseやtraceへ正しく投影できるか、golden/rubricが業務要求を表現しているかは利用組織側の設計問題である。

現行documentationはmulti-turn、voice、MCP、trajectory/component evaluation等へ拡張されており、2026-09-29時点の「component-levelはsingle-turnのみ」という旧境界は現在の一般的説明としては採用しない。公開記事ではcurrent documentationを優先する。

LLM-as-a-judgeの出力はjudge/model/provider/rubricへ依存する。高scoreをground truthやhuman reviewの完全代替として扱わない。

custom metrics、callbacks、agent toolsは評価コードとして権限を持ち得る。CI secret、production credentials、外部tool権限を最小化し、red-teamは承認済みtargetで行う。

evaluation corpusやtraceにはcustomer data、prompt、retrieved context、tool resultが含まれ得る。judge provider、Confident AI upload、telemetry、local artifactの各destinationとretentionを別々に確認する。

AUDIT: 「どのtargetを、どのdataset・metric・judge・threshold・versionで評価したか」を再現できるartifactを残す。

LLM judge、trajectory/component評価、regression suite、prompt optimizationはmodel callを増やす。CI frequencyとsample sizeを含めてcost budgetを管理する。

retry/error policy、rate-limit、cache、concurrency、artifact retention、baseline更新手順を明示し、評価systemのfailureをtarget systemのfailureと区別する。

• 当該組織のConfident AI契約、retention、RBAC、SSO、audit、self-host、region/SLA。
• 当該tenantで実際に有効なupload/telemetry/judge-provider data flow。
• Promptfoo、RAGAS、Inspect AI等との同一fixture・同一judge条件での比較効果。
• 実workloadで必要なsample size、variance、false-positive/false-negative許容値。
• 既存historical Luna packet locator。
• 現在利用するDeepEval releaseのexact package version/commit。公開時・導入時にlockfileとrelease provenanceで固定する。

UNKNOWNを推測で閉じない。

DeepEvalは、LLM/AIアプリをtest case・dataset・metric・traceに基づいて評価し、pytest/CIへ組み込めるlocal-firstのOSS evaluation frameworkである。end-to-end、trajectory、componentなど複数scopeを扱えるが、多くのmetricはLLM-as-a-judgeであり、pass/failは固定したdataset・metric・judge・threshold・version等の条件下での評価結果である。本番品質、安全性、法令適合の包括保証とは扱わない。local storageを利用する場合も、judge provider、Confident AI sign-in/upload、telemetry等の外部data flowを別途確認する。