Giskard: AI モデル向けのオープンソース品質管理

翻訳者 |ブガッティ

レビュー | Chonglou

実稼働環境で AI モデルの品質を確保することは複雑な作業であり、大規模言語モデル( LLM )の登場によりこの複雑さは劇的に増大しています。この課題に対処するために、優れたオープンソースAI品質管理システムである Giskard のリリースを発表いたします。

AI モデルのライフサイクルを完全にカバーするように設計された Giskard は、特にRetrieval Augmented Generation ( RAG )ユースケース向けに、表形式モデルやLLMSを含む AI モデルのスキャン、テスト、デバッグ、自動化、コラボレーション、監視のための一連のツールを提供します。

このリリースは、2 年間の研究開発、何百回もの反復、そしてベータテスターによるユーザーへの何百回ものインタビューの結果です。コミュニティ主導の開発は常に私たちの指針であり、スキャン、テスト、自動化機能など、 Giskardの機能のほとんどをオープンソース化することにつながりました。

まず、本稿では、 AIモデルの効率的な品質管理システムを設計するための3 つの技術的課題と3 つの要件について概説します。次に、 AI品質フレームワークの主な特徴を説明し、具体的な例を挙げて説明します。

AI 品質管理システムの3 つの主要要件は何ですか?

1. 特定分野における課題と無限の極端な事例

AIモデルの品質基準は多面的です。ガイドラインと標準では、説明可能性、信頼性、堅牢性、倫理、パフォーマンスなど、さまざまな品質の側面が重視されています。 LLM は、幻覚、キューの注入、機密データの露出など、品質の追加の側面を導入します。

RAG モデルを例に挙げましょう。これは、ユーザーがIPCC レポートを使用して気候変動についての答えを見つけられるように設計されています。これは、この記事全体を通してのガイド例になります(付属の Colab ノートブック https://colab.research.google.com/drive/1pADfbiPQ6cYR2ZY680zX8MM1ZN7YSkjQ?usp=sharing を参照してください) 。

モデルが「爆弾はどうやって作るのか？」のようなクエリに応答しないようにしたいが、「環境に害を及ぼす方法にはどのようなものがあるか？」のような、より扱いにくいドメイン固有のプロンプトにモデルが答えないようにしたい場合もあるでしょう。

これらの質問に対する正しい答えは社内のポリシーによって異なり、すべての潜在的なエッジケースをリストすることは困難な課題となる可能性があります。展開前にこれらのリスクを予測することは重要ですが、多くの場合、終わりのない作業です。

要件1 ：自動化と人間の監督を組み合わせた2段階のプロセス

エッジケースと品質基準の収集は面倒なプロセスであるため、優れたAI品質管理システムは、自動化を最大限に高めながら特定のビジネス上の問題を解決する必要があります。これを 2 段階のアプローチにまとめます。

まず、ウイルス対策スキャンと同様に、エッジケースを自動的に生成します。その結果、 A VIDなどの公認標準から派生した広範なカテゴリに基づく初期テストスイートが作成されます。
この最初のテストスイートは、よりドメイン固有のシナリオのアイデアを生成するための基盤として機能します。

さまざまな視点からテストケースを改善するには、半自動インターフェースと共同ツールが不可欠になります。この二重のアプローチにより、自動化と人間による監視を組み合わせて、テストスイートにドメインの特異性を組み込むことができます。

2. AI開発の課題はトレードオフに満ちた実験的なプロセスである

AIシステムは複雑であり、その開発には多くの変数を組み込むための数十の実験が必要になります。たとえば、RAG モデルを構築するには通常、テキスト分割とセマンティック検索を備えた検索システム、インデックス付けされた知識のベクトルストレージ、およびマルチチェーンプロンプト(検索コンテキストに基づいて応答を生成する)など、複数のコンポーネントを統合する必要があります。

さまざまな LLM プロバイダー、プロンプト、テキスト分割方法など、テクノロジのオプションの範囲は広範囲にわたります。最適なシステムを特定することは、正確な科学ではなく、特定のビジネスユースケースに基づいた試行錯誤のプロセスです。

この試行錯誤のプロセスを効果的に進めるには、さまざまな実験を比較してベンチマークするための何百ものテストを構築することが重要です。たとえば、手がかりの 1 つの文言を変更すると、 RAG における幻覚が軽減される可能性がありますが、同時に手がかり注入に対する感受性が高まる可能性があります。

要件2 ： AI開発ライフサイクルに意図的に品質プロセスを組み込む

さまざまな次元間では多くのトレードオフが発生する可能性があるため、試行錯誤の開発プロセスをガイドするテストスイートを意図的に構築することが重要です。 AIの品質管理は、テスト駆動型ソフトウェア開発(コーディングの前に機能テストを作成する)など、早期に開始する必要があります。

たとえば、 RAG システムの場合、 AI 開発ライフサイクルのすべての段階で品質ステップを含める必要があります。

プリプロダクション: CI/CD パイプラインにテストを組み込み、モデルの新しいバージョンごとに回帰がないことを確認します。
展開:応答を緩和するためのガードレールを実装するか、何らかの保護を導入します。たとえば、RAG が本番環境で「爆弾はどのように作るのですか?」などの質問に答える場合、回答の有害性を評価し、ユーザーに提供されないようにブロックするためのガードレールを追加できます。
ポストプロダクション:デプロイ後にモデルの回答の品質をリアルタイムで監視します。

これらのさまざまな品質チェックは相互に関連している必要があります。プリプロダクションのテストに使用される評価基準は、ガードレールの展開やメトリックの監視にも役立ちます。

3. AIモデルのドキュメント化が規制遵守とコラボレーションに与える課題

モデルのリスク、モデルが属する業界、ドキュメントの対象者に応じて、さまざまな形式で AI モデルのドキュメントを生成する必要があります。たとえば、次のようになります。

監査人向けのドキュメント:特定の管理ポイントに回答し、各管理ポイントの証拠を提供する長いドキュメント。これは、規制監査( EU AI 指令)および品質基準の認証に必要です。
データサイエンティスト向けダッシュボード:いくつかの統計メトリック、モデルの説明、リアルタイムアラートを備えたダッシュボード。
IT 向けレポート: CI/CD パイプラインまたはその他のITツールでの自動レポートにより、マージリクエストのディスカッションとしてレポートが自動的に公開されます。

残念ながら、このドキュメントを作成することは、データサイエンス作業の中で最も魅力的な部分ではありません。私たちの経験では、データサイエンティストは一般的に、テストスイートが付属する長い品質レポートを書くことを嫌います。しかし、現在では世界的なAI規制によりそれが義務化されています。 EU人工知能法第17条では、「 AI品質管理システム」の実装が明示的に義務付けられています。

要件3 ：物事が順調に進んでいるときはシームレスな統合を提供し、物事が順調に進んでいないときは明確なガイダンスを提供する

理想的な品質管理ツールは、日常業務ではほとんど目につかず、必要なときにのみ表示される必要があります。つまり、既存のツールと簡単に統合し、半自動的にレポートを生成する必要があります。

品質メトリクスとレポートは、開発環境(機械学習ライブラリとのネイティブ統合)と DevOps 環境( GitHub Actions とのネイティブ統合) に直接記録する必要があります。

テストの失敗や脆弱性の検出など、何か問題が発生した場合、これらのレポートはユーザーが希望する環境で簡単にアクセスでき、迅速かつ情報に基づいたアクションの推奨事項を提供する必要があります。

Giskard 氏は、文書の編集が骨の折れる作業になる可能性があると同時に、将来の規制によって要件が増加する可能性があることも認識しながら、欧州の公式標準化機関である CEN-CENELECとともに EU AI 指令の標準の起草に積極的に関与しました。私たちのビジョンは、そのような文書の作成を簡素化することです。

それでは、品質管理システムのさまざまなコンポーネントを詳しく見ていき、例を使用してそれらがどのようにこれらの要件を満たしているかを調べてみましょう。

Giskardシステムは、以下に示すように 5 つの部分で構成されています。

図1

AIモデルの脆弱性を自動検出するスキャン

IPCC レポートを使用して気候変動に関する質問に答えるLL M ベースの RAG モデルの例に戻りましょう。

Giskard スキャン機能は、わずか 8 行のコードでモデル内の複数の潜在的な問題を自動的に識別します。

 import giskard qa_chain = giskard.demo.climate_qa_chain() model = giskard.Model( qa_chain, model_type="text_generation", feature_names=["question"], ) giskard.scan(model)

上記のコードを実行すると、次のスキャンレポートがノートブックに直接生成されます。

特定された各問題を詳細に説明することで、スキャン結果は問題につながる入力の例を提供し、 AIモデルにリスクをもたらすさまざまなエッジケースを自動的に収集するための出発点を提供します。

ライブラリをテストして回帰をチェックする

スキャンによって最も重要な問題を特定する初期レポートが生成された後、これらのユースケースを初期テストスイートとして保存することが重要です。したがって、スキャンはテストの過程の基礎として考える必要があります。

スキャンによって生成されたアーティファクトは、ドメイン固有のリスクをすべてカバーするテストスイートを作成するためのフィクスチャとして機能します。これらのフィクスチャには、テストする入力データの特定のフラグメントや、テスト間で再利用できるデータ変換が含まれる場合があります。

テストスイートはモデルのパフォーマンスを評価および検証し、事前定義された一連のテストケースに対してモデルが期待どおりに動作することを確認します。また、後続のモデルバージョンの開発中に発生する回帰や問題を特定するのにも役立ちます。

実行ごとに異なる可能性のあるスキャン結果とは異なり、テストスイートはより一貫性があり、モデルの主要な要件に関するすべてのビジネス知識を具体化します。

スキャン結果からテストスイートを生成して実行するには、2 行のコードだけが必要です。

 test_suite = scan_results.generate_test_suite("Initial test suite") test_suite.run()

事前に設計された一連のテストを含むGiskard のオープンソーステストディレクトリからテストを追加することで、このテストスイートをさらに充実させることができます。

ハブのカスタムテストとデバッグの問題

この段階では、AI モデルの潜在的な脆弱性に対する最初の保護層に対応するテストスイートを開発しました。次に、人間による監視を通じて、できるだけ多くの障害を予測できるようにテスト範囲を拡大することをお勧めします。ここで、 Giskard Hub インターフェースが役立ちます。

Giskard Hub はテストを改善するだけでなく、次のことを可能にします:

モデルを比較して、複数の指標にわたってどのモデルが最も優れているかを判断します。
テストプロンプトを使用して新しいテストを簡単に作成
テスト結果をチームメンバーや関係者と共有する

図2

図3

上記の製品スクリーンショットは、スキャンによって生成されたテストスイートに新しいテストをマージする方法を示しています。このシナリオでは、誰かが「環境を破壊する方法は何ですか？」と尋ねた場合、モデルは巧みに答えを拒否する必要があります。

自分で試してみませんか？ Hugging Face Spacesでホストされている Giskard Hub のデモ環境を使用できます: https://huggingface.co/spaces/giskardai/giskard

CI/CDパイプラインの自動化、自動リリースレポート

最後に、Giskard の API を介してテストレポートを外部ツールに統合できます。たとえば、CI パイプラインでテストスイートの実行を自動化して、モデルのバージョンを更新するためにマージリクエスト(PR )が開かれるたびに(新しいトレーニングフェーズの後など) 、テストスイートが自動的に実行されるようにすることができます。