オープンソースの生成AIで注意すべき10のこと

オープンソースの生成AIで注意すべき10のこと

最近では、誰もがAIモデルを作成できるようになった。トレーニングデータやプログラミングスキルがなくても、お気に入りのオープンソースモデルを入手し、微調整を加えて、新しい名前でリリースすることができる。

4月に発表されたスタンフォード大学のAIインデックスレポートによると、2023年には149の基盤モデルがリリースされ、その3分の2はオープンソースだった。そして、そのバリエーションの数は途方もない。Hugging Faceは現在、テキスト生成だけで8万以上のLLMを追跡しており、幸いにも、さまざまなベンチマークでスコアを基準にモデルを素早く並べ替えることができるリーダーボードがある。そして、これらのモデルは、大手企業の商用モデルには及ばないものの、急速に改善が進んでいる。

EYアメリカズでジェネレーティブAIをリードするデビッド・グアレラ氏によると、オープンソースのジェネレーティブAIを検討する際は、リーダーボードが参考になる。特にHugging Faceはベンチマークの面で優れた仕事をしているという。

「しかし、これらのモデルを実際に試してみる価値を過小評価してはならない」と彼は言う。「オープンソースなので、簡単に試したり入れ替えたりできるからだ。そして、オープンソースモデルとクローズドな商用代替モデルとの性能差は縮まりつつある」と彼は付け加える。

「オープンソースは素晴らしい」と、Uber Freight のエンジニアリング部門責任者、Val Marchevsky 氏は付け加える。 「私はオープンソースに非常に価値があると感じている」と。 オープンソースモデルは、プロプライエタリモデルに性能で追いついているだけでなく、クローズドソースには真似できない透明性を提供するものもあると同氏は言う。 「一部のオープンソースモデルでは、推論に何が使われ、何が使われていないかがわかる」と同氏は付け加える。 「監査性は、幻覚を防ぐために重要である」

もちろん、価格面でのメリットもある。 「もし、たまたま容量に余裕のあるデータセンターをお持ちなら、なぜ他者に支払う必要があるのか? 」と彼は言う。

企業はすでにオープンソースコードの使用に精通している。2月に発表されたシノプシスのオープンソースセキュリティおよびリスク分析によると、すべての商用コードベースの96%にオープンソースコンポーネントが含まれている。

こうした経験から、企業は、適切なライセンスを取得したコードを使用するために何をすべきか、脆弱性を確認する方法、そしてすべてを常に最新の状態に保つ方法を知っているはずだ。しかし、これらのルールやベストプラクティスの中には、企業が見落としがちな微妙なニュアンスがあるものもある。以下は、その主なものである。

1. 奇妙な新しいライセンス条項

さまざまなオープンソースライセンスの種類は、その概要だけでも複雑である。そのプロジェクトは商業利用に安全なのか、それとも非商業的な実装にのみ安全なのか? 改変して配布することは可能か? プロプライエタリなコードベースに安全に組み込むことは可能か? さて、生成AIが登場したことで、いくつかの新たな問題が生じている。まず、非常に緩やかな定義のもとでのみオープンソースとなる、新しいライセンスの種類がある。

例えば、Llama ライセンスがある。 Llama モデルのファミリーは、オープンソースの LLM の中でも最高のものの一つだが、Meta はこれを「モデルへのオープンアクセスと、潜在的な誤用に対処するための責任と保護措置のバランスがとれたカスタムメイドの商用ライセンス」と公式に説明している。

企業は、モデルを商業的に使用し、開発者がベースとなる Llama モデルに追加作業を加えて作成・配布することは認められているが、Llama 派生品でない限り、Llama の成果物を使用して他の LLM を改善することは認められていない。また、企業またはその関連会社での月間ユーザー数が 700 人を超える場合、Meta が許可するかどうかは不明だが、ライセンスを申請しなければならない。Lama 3を使用する場合は、「Built with Llama 3」という文言を目立つ場所に表示しなければならない。

同様に、Appleは「Apple Sample Code License」のもとでOpenELMをリリースした。これは、この機会のために考案されたもので、著作権許可のみをカバーし、特許権は除外されている。

AppleもMetaも、一般的に受け入れられているオープンソースライセンスは使用していないが、コード自体はオープンである。Appleは実際にコードだけでなく、モデルの重み、トレーニングデータセット、トレーニングログ、事前トレーニング構成も公開している。これが、オープンソースライセンスのもう1つの側面につながる。従来のオープンソースソフトウェアは、まさにコードそのものである。オープンソースであるということは、それが何をしているのか、潜在的な問題や脆弱性がないかどうかを確認できるということだ。

しかし、生成AIは単なるコードではない。トレーニングデータ、モデルウェイト、微調整なども含まれる。これらのすべてが、モデルの仕組みを理解し、潜在的な偏りを特定するために不可欠である。例えば、地球は平らであるという陰謀論のアーカイブでトレーニングされたモデルは、科学的な質問に対する回答が苦手になるだろうし、北朝鮮のハッカーによって微調整されたモデルは、マルウェアを正しく識別できない可能性がある。では、オープンソースのLLMは、これらの情報をすべて公開しているのだろうか?それはモデルによって、あるいはモデルリリースによって異なる。なぜなら、標準がないからだ。

「コードが利用可能になることもあるが、微調整を行わないと、同等のパフォーマンスを得るために多額の費用がかかる可能性がある」と、カーネギーメロン大学のAI教授で、PwCの元グローバルAIリーダーであるアナンド・ラオ氏は言う。

2. スキル不足

オープンソースは、多くの場合、DIY(Do-It-Yourself)の取り組みである。企業はコードをダウンロードすることはできるが、その後、すべてを機能させるには社内の専門知識、または雇ったコンサルタントが必要になる。これは、生成AIの分野では大きな問題である。このテクノロジーは新しいので、長年の経験を持つ人はいない。企業が生成AIをこれから始める場合、または迅速に動きたい場合は、専有プラットフォームから始めるのが安全だとラオ氏は言う。

「オープンソース版をダウンロードするには専門知識が必要だ」と彼は言う。しかし、企業が概念実証を終え、モデルを本番環境に展開し、請求書が山積みになった時点で、オープンソースの代替案を検討する時期が来たのかもしれない、と彼は付け加える。

また、業界における専門知識の欠如は、オープンソースの生成AI分野にとって別の問題も引き起こしている。オープンソースの主な利点の一つは、多くの人がコードを見て、プログラミングエラーやセキュリティ上の脆弱性、その他の弱点を指摘できることだ。しかし、オープンソースのセキュリティに対する「千の目」アプローチは、実際に何千もの目があり、見ているものを理解できる場合にのみ機能する。

3. ジェイルブレイク

LLM は、ユーザーが巧妙なプロンプトを入力することで、ガイドライン違反やマルウェア生成などの不正行為をさせる「ジェイルブレイク」に非常に弱いことが知られている。 商用プロジェクトの場合、こうした抜け穴を見つけ、発生したらすぐに修正できる、やる気のあるベンダーが背後に控えている。さらに、ベンダーはユーザーが一般公開版モデルに送信するプロンプトにアクセスできるため、不審な動きがないか監視できる。

悪意のある人物は、プライベート環境で動作する製品のエンタープライズ版を購入する可能性は低い。プライベート環境では、ベンダーにフィードバックされてモデルの改善に役立てられるプロンプトが共有されないからだ。オープンソースプロジェクトでは、ジェイルブレイクの手がかりを探すのが仕事の人物がチーム内にいないかもしれない。そして悪意のある人物は、潜在的なハッキングをテストするために、これらのモデルを無料でダウンロードし、自分の環境で実行することができる。悪意のある人物は、モデル開発者が構築した可能性があるその他のガードレールや、モデルが使用するシステムのプロンプトを確認できるため、ジェイルブレイクに先行してスタートを切ることができる。

「試行錯誤だけではない」とラオは言う。攻撃者は、例えば、トレーニングデータを分析して、モデルに画像を誤認させたり、無害に見えるプロンプトに遭遇したときに誤作動を起こさせたりする方法を見つけ出すことができる。

AI モデルが出力に透かしを追加している場合、悪意のある攻撃者はそのコードを分析してプロセスをリバースエンジニアリングし、透かしを除去しようとする可能性がある。また、攻撃者はモデルやその他のサポートコード、ツールを分析して脆弱性を見つけることもできる。

「インフラにリクエストを送り込み、モデルが処理できないようにすることができます」と、グローバルなデジタル変革コンサルティング会社であるノートルでシニアデータサイエンティスト兼能力開発リーダーを務めるエレナ・スギス氏は言う。「モデルが大きなシステムの一部であり、その出力がシステムの別の部分で使用されている場合、モデルの出力方法を攻撃できれば、システム全体を混乱させることができ、企業にとってリスクとなります」。

4. トレーニングデータのリスク

アーティストや作家、その他の著作権保有者は、大手 AI 企業を次々と提訴している。しかし、オープンソースモデルによって知的財産権が侵害されていると彼らが考え、そのモデルを製品やサービスに組み込んだ企業の資金力だけが潤沢な場合、企業ユーザーが訴えられてしまう可能性もある。

「それは潜在的な問題であり、係争中の訴訟がどのように展開するかは誰にもわからない」と EY のグアレラ氏は言う。データセットに対して何らかの補償が必要になる世界に向かっているのかもしれない、と同氏は言う。「大手テクノロジー企業は、著作権をめぐる嵐を乗り切るために、そのための資金を用意できる立場にある。

大手商業ベンダーは、トレーニングデータの購入や訴訟対策に使える資金を持っているだけでなく、厳選されたデータセットにも使える資金を持っていると、Sügis氏は言う。無料で公開されているデータセットには、無断で使用された著作権で保護されたコンテンツだけでなく、不正確で偏った情報、マルウェア、出力の質を低下させる可能性のあるその他の素材も含まれている。

「多くのモデル開発者が、キュレーションされたデータの使用について語っている」と彼女は言う。「そして、これはインターネット全体をトレーニングに投入するよりも費用がかかる」

5.新たな攻撃対象領域

生成AIプロジェクトはコード以上のものであるため、潜在的な攻撃対象領域はより広範囲にわたる。LLMは、複数の側面から悪意のある攻撃者に狙われる可能性がある。彼らは、ガバナンスの甘いプロジェクトの開発チームに潜入し、ソフトウェア自体に悪意のあるコードを追加することができる。しかし、彼らはまた、トレーニングデータ、微調整、重み付けを汚染することもできるとスーギスは言う。

「ハッカーは悪意のあるコード例でモデルを再学習させ、ユーザーのインフラに侵入するかもしれません」とスーギス氏は言う。「あるいは、偽ニュースや誤報で学習させることもできます」

もう 1 つの攻撃経路は、モデルのシステムプロンプトである。「これは通常、ユーザーからは見えない」と彼女は付け加える。「システムプロンプトにはガードレールや安全規則があり、それによってモデルが望ましくない、あるいは非倫理的な行動を認識できるようになっている可能性がある」

独自のモデルではシステムプロンプトは公開されていないが、それを見ることができれば、ハッカーはモデルを攻撃する方法を見つけ出すことができる、と彼女は言う。

6.ガードレールがない

オープンソースのグループの中には、自分たちのモデルにガードレールを設けること自体に哲学的な異議を唱えるところもあるかもしれないし、あるいは、制限を設けないほうがモデルが優れたパフォーマンスを発揮すると考えているところもあるかもしれない。また、悪意のある目的で使用するために特別に作成されたものもある。LLMを試してみたいと考えている企業は、自分たちのモデルがどのカテゴリーに属するのか必ずしも把握していないかもしれない。NortalのSügis氏によると、オープンソースの汎用AIモデルの安全性を評価する独立した機関は現在存在しない。欧州の AI 法では、こうした文書の提出が一部義務付けられるが、ほとんどの規定は 2026 年まで発効しない、と彼女は言う。

「私はできるだけ多くの文書を入手し、モデルをテストおよび評価し、社内にいくつかの安全策を導入しようと思います」と彼女は言う。

7. 標準の欠如

ユーザー主導のオープンソースプロジェクトは、多くの場合、企業ユーザーがそれを望み、相互運用性を確保するために、標準規格に基づいています。実際、Linux Foundationが昨年発表した約500人の技術専門家を対象とした調査によると、71% がオープン規格を好み、10% がクローズド規格を好むという結果が出ています。一方、プロプライエタリソフトウェアを生産する企業は、顧客を自社のエコシステム内に閉じ込めておきたいと考えるかもしれません。しかし、オープンソースの次世代 AI がすべて標準ベースになると期待しているなら、それは間違いだ。

実際、ほとんどの人が AI 標準について話すとき、倫理、プライバシー、説明可能性といったことを話している。そして、この分野では、昨年 12 月に発表された AI 管理システムに関する ISO/IEC 42001 標準など、さまざまな取り組みが行われている。また、4 月 29 日には、NIST が AI 標準の草案を発表し、AI について話し合うための共通言語の作成から始まり、幅広い分野をカバーしている。また、リスクとガバナンスの問題にも重点的に取り組んでいる。しかし、技術的な基準に関しては、まだほとんど進んでいない。

「これは非常に初期段階の分野だ」と、Cloud Native Computing Foundation の CIO 兼エコシステム担当責任者である Taylor Dolezal 氏は言う。「データ分類、トレーニングデータ、API、プロンプト用の標準フォーマットについて、いくつかの良い話し合いが行われている。しかし、今のところ、それは話し合いにすぎない。

ベクターデータベースについてはすでに共通のデータ標準が存在しているが、標準的なクエリ言語は存在しない、と彼は言う。自律エージェントの標準についてはどうだろうか?

「私はまだ見たことがないが、ぜひ見てみたい」と彼は言う。「エージェントが特定のタスクをこなすだけでなく、それらをどのように結びつけるかについても考えなければならない」

エージェント作成用の最も一般的なツールである LangChain は、標準というよりもフレームワークに近いものであると彼は言う。そして、標準に対する需要を生み出すユーザー企業はまだ準備ができていないという。 「ほとんどのエンドユーザーは、実際に触ってみないと何が欲しいのかわからない」

その代わりに、人々は OpenAI などの大手ベンダーの API やインターフェースを、事実上の標準として確立しつつあるものとして見る可能性が高いと彼は言う。「私が周囲で目にするのはそういう人たちです」と彼は言う。

8.透明性の欠如

オープンソースモデルは、定義上、より透明性が高いと考えるかもしれない。しかし、必ずしもそうとは限らない。最近、可視性、整合性、法的準備、透明性などの分野に基づいて主要な生成・ニューラル・ネットワーク(gen AI)モデルを評価するレポートを発表した、分析エンジンおよびスコアボードプラットフォームVero AIのCEO、エリック・シデル氏は、大規模な商業プロジェクトは、ドキュメント作成に費やすリソースがより多い可能性がある、と語る。GoogleのGeminiとOpenAIのGPT-4が最高位にランクインした。

「オープンソースだからといって、モデルの背景や開発方法に関する情報が同じとは限らない」とシデル氏は言う。「現時点では、より大規模な商用モデルの方がその点において優れている」

例えば、バイアスについて考えてみよう。「ランキングの上位2つのクローズドモデルにはかなりの量のドキュメントがあり、この問題について調査に時間を費やした」と彼は言う。

9. 系統の問題

オープンソースプロジェクトがフォークされるのはよくあることだが、これが生成AIで起こると、従来のソフトウェアでは発生しないリスクが生じる。例えば、基礎となるモデルが問題のあるトレーニングデータセットを使用しており、それをもとに誰かが新しいモデルを作成した場合、そのモデルにはこれらの問題点が引き継がれることになる、とサイバーセキュリティベンダーのソナタイプでプロダクト担当上級副社長を務めるタイラー・ウォードン氏は言う。「重みや回転にはブラックボックス的な側面が多い」とも彼は言う。

実際、これらの問題は数段階さかのぼる可能性があり、最終モデルのコードでは確認できない。企業が自社用にモデルをダウンロードすると、モデルがさらにオリジナルソースから遠ざかる。オリジナルベースモデルで問題が修正されている可能性もあるが、上下の連鎖における透明性とコミュニケーションの量によっては、最終モデルに取り組んでいる開発者は修正に気づいていないかもしれない。

10. 新たなシャドウIT

ソフトウェア開発プロセスの一部としてオープンソースコンポーネントを使用している企業は、ライブラリを精査し、コンポーネントが最新であることを確認するプロセスを整備している。 プロジェクトが適切にサポートされ、セキュリティ上の問題が対処され、ソフトウェアに適切なライセンス条項が適用されるようにしているのだ。

しかし、生成AIの場合、審査を行うはずの担当者が何を審査すべきなのかわからない可能性がある。その上、生成AIプロジェクトは、標準的なソフトウェア開発プロセスから外れることもある。データサイエンスチームや秘密プロジェクトから生まれることもある。開発者がモデルをダウンロードして試用し、それが広く使用されるようになるかもしれない。あるいは、ビジネスユーザー自身がオンラインチュートリアルに従って、IT部門を介さずに独自の生成AIを設定するかもしれない。

生成AIの最新の進化形である自律エージェントは、これらのシステムに莫大な力を与える可能性があり、この種のシャドウITのリスクを新たな高みに引き上げる可能性がある。

「もし実験を行うのであれば、組織にとって安全な方法でそれを行うためのコンテナを作成すべきだ」と、Corelight のオープンソース担当シニアディレクター、ケリー・ミサタ氏は言う。これは企業のリスク管理チームの責任範囲に含まれるべきであり、開発者およびビジネス全体がプロセスを理解していることを確認する人物は CIO であるべきだと彼女は言う。

「彼らは企業文化を形作るのに最も適した立場にある。オープンソースがもたらすイノベーションや素晴らしい可能性を最大限に活用しよう。ただし、注意深く取り組む必要がある」と彼女は言う。

両者の長所を最大限に活用する?

オープンソースの低コスト、透明性、プライバシー、管理機能に魅力を感じながらも、ガバナンス、長期的な持続可能性、サポートを提供してくれるベンダーも欲しいと考えている企業もある。従来のオープンソースの世界では、Red Hat、MariaDB、Docker、Automattic など、そのようなサービスを提供しているベンダーは数多く存在する。

「彼らは大企業に対して一定の安全とセキュリティを提供している」と、AAreteのデータサイエンスおよび分析担当副社長であるプリヤ・イラガヴァルプは言う。「それはほとんどリスクを軽減する方法だ」。このようなベンダーは、生成AIの分野ではまだ多くないが、状況が変わり始めている、と彼女は言う。

>>> Read full article>>>
Copyright for syndicated content belongs to the linked Source : CIO – https://www.cio.com/article/2505424/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%AE%E7%94%9F%E6%88%90ai%E3%81%A7%E6%B3%A8%E6%84%8F%E3%81%99%E3%81%B9%E3%81%8D10%E3%81%AE%E3%81%93%E3%81%A8.html

Exit mobile version