giskard-oss v3 評価の対象と、v2 から引き継げないもの

giskard-oss が埋めようとしている穴

通常のユニットテストは、同じ入力に対して同じ出力が返る前提で書かれている。LLM を使ったエージェントはその前提を満たさない。同じ質問に対して表現の違う複数の正解があり、多段のツール呼び出しが挟まると、どの時点の出力を検証すべきかも自明ではなくなる。giskard-oss はこの非決定性を前提にした評価の枠組みを提供する。README は evals を「traditional unit tests とは異なり、非決定的な出力のために設計されている」と説明している。対象は LLM 単体、ブラックボックスのエージェント、複数ステップのパイプラインで、いずれも同期・非同期の callable として包めるとされる。利用者は、変更のたびに挙動が壊れていないかを確認したい LLM アプリケーションの開発者、RAG の回答が検索結果に根拠を置いているかを検証したいチーム、そしてエージェントに対する攻撃耐性を確認したいセキュリティ担当者になる。

v3 で分けられたパッケージの境界

v3 は単一の大きなライブラリではなく、必要な依存だけを持つ複数のパッケージの集合として作られている。README の表で Stable とされているのは giskard-checks と giskard-scan の 2 つだ。giskard-checks はテストと評価を担い、scenario API、組み込みチェック、LLM-as-judge を含む。giskard-scan はエージェントの脆弱性スキャンと RAG の品質評価を担い、vulnerability_scan が v2 の Scan の後継、quality_scan が v2 の RAGET の後継と明記されている。この 2 つの下には giskard-core（共有ユーティリティとテレメトリ）、giskard-llm（プロバイダ非依存の LLM ルーティング）、giskard-agents（エージェントとワークフローのオーケストレーション）が置かれ、自動的に取り込まれるが直接使うことはまれだとされる。バージョン番号もこの分割に対応しており、v3.0.0 に加えて giskard-scan/v1.0.0 と giskard-llm/v1.0.0 が別々にリリースされている。ライセンスは Apache-2.0。

Scenario と Check で評価を組み立てる仕組み

giskard.checks の中心は 4 つの概念だ。Target はテスト対象で、(inputs) -> outputs の callable、任意で trace も返せる。Scenario は 1 つの評価であり、interaction と check の組でできている。Check は trace に対するアサーションか LLM ジャッジ。Suite は複数の Scenario をまとめて実行する。README の Quickstart では Scenario に名前を付け、interact(inputs=..., outputs=get_answer) で対象を登録し、check(Groundedness(...)) で判定を付けてから await scenario.run() を呼び、result.print_report() で結果を出力する流れが示されている。Groundedness は LLM ジャッジなので、provider の extra（例: pip install "giskard[openai]"）と対応する API キーが必要で、既定モデルは openai/gpt-4o-mini と記載されている。組み込みの評価には文字列一致、比較、正規表現、意味的類似度、そして Groundedness、Conformity、LLMJudge がある。

Generator という名前が 2 箇所で衝突する

README は giskard.agents.Generator がワークフローやジャッジ用の LLM クライアントであり、giskard.checks の入力ジェネレータ（LLMGenerator）がユーザーメッセージを合成するものである点を明示的に区別している。同じ Generator という語が別の役割で 2 つのパッケージに現れるので、ドキュメントやコードを読むときに取り違えやすい。エージェント側の Generator は判定や生成のためのモデル呼び出し、checks 側の LLMGenerator はテスト入力を作るためのものだ。評価シナリオを書いているときに「ユーザー発話を増やしたい」のか「ジャッジ用のモデルを差し替えたい」のかで、触るべきクラスが変わる。

インストールと実行、テレメトリの止め方

前提は Python 3.12 以上。pip install giskard で checks と agents、llm、core が入り、脆弱性スキャンや品質スキャンまで使うなら pip install "giskard[scan]"、または pip install giskard-scan を別途実行する。LLM ジャッジやジェネレータに provider の SDK を使う場合は pip install "giskard[openai]" のように extra を指定する。テレメトリは giskard-core 経由の任意の集計で、プロンプトや出力は送信されないと README は述べている。無効化は export DO_NOT_TRACK=1 または export GISKARD_TELEMETRY_DISABLED=1、作業ディレクトリの .env に同じキーを書く方法もある。import より前に設定すれば ~/.giskard/id の作成自体をスキップでき、後から設定した場合も以降の送信は止まる。CI で回すなら、この環境変数をジョブの定義に最初から入れておくのが素直だ。

v2 から v3 へ移せない部分

v3 は書き直しであり、v2 は残っているが活発には保守されないと README が明言している。v3 のスキャナは giskard-scan にネイティブで入り、v2 への依存はない。ただし例外が 1 つあり、表形式・機械学習モデル向けのレガシーなスキャンだけは v2 専用のままだと書かれている。つまり v2 を表形式モデルの公平性や妥当性の検証に使っていたチームは、その用途について v3 に移行先がない。エージェントや RAG の評価だけを使っていた場合は移行の障害は小さいが、モデルスキャンとエージェント評価を同じツールでまとめていた構成は、ここで分岐する。v3 が「重い依存を落とした」と表現している点も、v2 の機能をそのまま引き継いだのではなく対象を絞り直した結果だと読むべきだろう。

LLM-as-judge を判定に使うことの限界

Groundedness や Conformity は LLM によるジャッジであり、判定結果はジャッジ用モデルの挙動に依存する。README は既定モデルが openai/gpt-4o-mini であることと、provider の extra と API キーが必要であることを示すが、判定の安定性やスコアの較正については記述がない。非決定的な出力を評価するための道具が、それ自体非決定的な判定器に依存しているという構図になる。同じ入力に対してジャッジの判定がぶれる可能性は残るし、判定基準を自然言語のコンテキストで与える以上、境界事例の扱いはモデル任せになる。決定的な検証で足りる部分（文字列一致、正規表現、数値比較）を先に固め、LLM ジャッジは意味的な判定が要る箇所に限定する使い方が現実的だ。また、この評価は外部のモデル API を呼ぶので、オフライン環境や API キーを CI に置けない環境では動かない。

代替手段との違い: 汎用テスト基盤とどう棲み分けるか

pytest のような汎用テストフレームワークは、テストの収集・実行・レポートの仕組みを持っているが、非決定的な出力に対する判定の語彙は持たない。giskard-checks は Scenario と Check という単位でその語彙を提供し、Suite でまとめて実行する。逆に言えば、テストの並列実行、fixture、マーカー、失敗の再実行といった実行基盤の機能は giskard 側には見当たらず、README にも言及がない。既存の CI に組み込むなら、giskard の評価を pytest から呼び出す形にして、実行とレポートは既存の基盤に任せる構成が素直だろう。もう 1 つの違いは対象の抽象化にある。giskard は Target を (inputs) -> outputs の callable として受け取るので、HTTP 越しのエージェントでもローカルの関数でも同じ扱いにできる。フレームワーク固有の計装を要求しない代わりに、エージェント内部のステップを細かく検証したい場合は trace を自分で返す必要がある。

導入を決める前に確かめること

最初に確認すべきは Python のバージョンだ。3.12 以上が要件なので、3.11 以前で動くサービスに組み込むなら別環境を用意することになる。次に、LLM ジャッジを使うかどうかで依存とコストが変わる。使うなら provider の extra と API キー、そして CI から外部 API に出られるネットワークが必要になる。テレメトリを止めるなら DO_NOT_TRACK=1 を import 前に設定する。v2 からの移行を検討している場合は、v2 で表形式モデルのスキャンを使っていないかを先に洗い出す。使っているなら、その部分は v3 に移らないので代替を別途探すことになる。最後に、自社のデータで Groundedness や Conformity の判定がどの程度安定するかを測ってから、CI のゲートとして使うかどうかを決めるのが順当だ。判定がぶれるものを必須チェックにすると、パイプラインが理由の分からない失敗を繰り返す。

編集部の結論

非決定的な出力を継続的に検証したい LLM エージェントのチーム、とくにプロンプト注入やジェイルブレークを CI で回したいチームに向く。v2 で表形式モデルの公平性スキャンを使っている場合、その部分は v3 に移っていないので、v2 の保守終了を前提に別の手段を用意する必要がある。導入前に確認すべきは、Python 3.12 以上が前提であること、LLM ジャッジを使うなら provider の extra と API キーが要ること、そして LLM-as-judge の結果が判定モデルに依存する以上、まず自社のデータで判定の再現性を測ることだ。

公式情報源

1. Giskard-AI/giskard-oss on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases