OpenAIのチャットAIであるChatGPTや、Googleの開発する大規模言語モデル(LLM)のPaLM-2などから、機密情報や一部機能を盗み出すことができる「モデル窃盗攻撃(model-stealing attack)」を、AI研究者が発表しました。
研究チームはモデル窃盗攻撃が成功した理由について、「少数のモデルプロバイダーが、ロジットバイアスパラメーターを利用可能にしたため」と指摘しており、この種のAPIを提供していないモデルプロバイダーとしては「Anthropic」の名前が挙げられています。API設計におけるほんの小さな決定により、AIモデルに対する攻撃が可能になってしまうという今回の事例から、「セキュリティを念頭に置いたAPI設計が必要です」と研究チームは指摘しました。
研究チームはモデル窃盗攻撃よりも実用的なAIモデルをターゲットとした攻撃手法が今後登場することになるだろうと指摘しています。
⇧ 機能開発の難しさを物語ってますな。
とりあえず、
⇧ 情報漏洩とかは何とかして欲しい...
Git LFS（Large File Storage）とは？
GitHubの公開している情報によると、
⇧ とある。
「Git LFS（Large File Storage）」はと言うと、
Git Large File Storageについて
Git LFSは、リポジトリに実際のファイルではなく、ファイルへの参照を保存することで大きなファイルを扱います。 Git のアーキテクチャを回避するため、Git LFS では実際のファイル (どこか別の場所に格納されています) への参照として働くポインター ファイルが作成されます。 GitHubはこのポインタファイルをリポジトリ中で管理します。 リポジトリをクローンすると、GitHubはこのポインタファイルを大きなファイルを見つけるための地図として使います。
ファイルごとの 5 GB の制限を超えた場合、ファイルは Git LFS によってサイレントに拒否されます。
⇧ ということらしい。
Git LFS（Large File Storage）は、外部のストレージを指定できるらしい
何やら、
GitHubでは、公式サービスとしてGitHub LFSが提供されています。
しかし、GitHubが提供しているLFSサーバーは無料枠でアカウントごとに2GBまで使用することが可能であるものの、それを超えて使用する場合には「data pack」を購入する必要があります。
コストを削減したい為、GitHub LFSをS3に切り替えることにしました。
S3ベースのGit LFSサーバーの構築にあたり、いくつかOpenSourceがありますが、今回は構築の利便性および導入後の運用性を考慮した上でRudolfsを選定しました。
以下は当初検討になった各OpenSourceです。
- lfs-test-server
- S3と連携する仕組みがない為却下
- LFS2S3Proxy
- 個人の製品ですからセキュリティおよび今後のアップデートを考慮した上で却下
- meltingice/Git LFS S3
- Rudolfs
- ★S3をバックエンドとして利用可能、かつDocker化されており運用もしやすい為採用★
⇧ 上記サイト様によりますと、「Git LFS（Large File Storage）」としてAmazon S3を指定することができるOSSライブラリがあるそうな。
⇧ とある。
「Rudolfs」をインストールし、セットアップすれば、git pushした際に、容量の大きいファイルの実体については、「Git LFS（Large File Storage）」で指定したストレージにアップロードされるようにできる模様。
「継続的インテグレーション/継続的デリバリー（CI/CD）」も実現できそう？
そも、「継続的インテグレーション/継続的デリバリー（CI/CD）」とは？
In software engineering, CI/CD or CICD is the combined practices of continuous integration (CI) and continuous delivery (CD) or, less often, continuous deployment. They are sometimes referred to collectively as continuous development or continuous software development.
Comparison
⇧ 継続可能なソフトウェア開発、まさに、
（じぞくかのうなかいはつもくひょう、英語: Sustainable Development Goals、略称: （エスディージーズ））は、2015年9月25日に国連総会で採択された、持続可能な開発のための17の国際目標である。
その下に、169の達成基準と232の指標が決められている。
⇧ SDGsを地で行く感じですな。
AWSのドキュメントによると、
AWS CodePipeline は、ソフトウェアの構築、テスト、デプロイのタスクを自動化する継続的デリバリーサービスです。このサービスは現在 GitHub、、AWS CodeCommit、および Atlassian Bitbucket によって管理される Git リポジトリをサポートしています。ただし、一部の企業では、シングルサインオン (SSO) サービスとMicrosoft Active Directoryと統合されたサードパーティ製の Git リポジトリを認証に使用しています。カスタムアクションとウェブフックを作成 CodePipeline することで、これらのサードパーティーの Git リポジトリを のソースとして使用できます。
⇧ とあるので、頑張れば、「継続的インテグレーション/継続的デリバリー（CI/CD）」も組み合わせられそうな雰囲気ですな。
一応、AWSのドキュメントによりますと、
このプロジェクトでは、AWS で継続的インテグレーションと継続的デリバリー (CI/CD) のパイプラインを設定する方法について説明します。パイプラインを使用すると、ソフトウェア配信プロセスのステップを自動化できます。例えば、自動的に構築を開始してから、それを Amazon EC2 インスタンスにデプロイできます。ここでは、AWS CodePipeline を使用します。このサービスでは、コードの変更があるたびに、定義されたリリースプロセスモデルに基づいてコードを構築、テスト、デプロイします。
⇧「継続的インテグレーション/継続的デリバリー（CI/CD）」を実現する方法として「AWS CodePipeline」を上げていらっしゃるので。
とりあえず、「Git LFS（Large File Storage）」で外部のストレージを指定するライブラリとして、Amazon S3にしか対応していないっぽいので、他の「クラウドサービスプロバイダー」での実現は厳しそうね...
そもそも、ゲーム業界とかでもない限り、「Git LFS（Large File Storage）」の出番が無さそうな感じなんかね？
通常の業務Webアプリケーションとかであれば、Gitで管理するファイルのサイズが100MBを超えるようなことは、無いと考えておけば良いということですかね？
う～む、分からん...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
