DALL-E 3やStable Diffusionといった人気の画像生成AIの拡散モデルを簡素化し、生成される画像の品質を維持しつつ生成スピードを最大で30倍加速させる技術を、アメリカ・マサチューセッツ工科大学(MIT)の研究チームが公開しました。
MITのTianwei Yin氏は「私たちの研究は、敵対的生成ネットワーク(GAN)の原理と拡散モデルの原理を融合させ、視覚コンテンツ生成を1つのステップで実現するもので、これは現行の拡散モデルが100ステップもの反復的な改良を必要とするのとは対照的です。これは、スピードと品質に優れた新しい生成モデリング手法となる可能性を秘めています」と話しました。
MITのフレド・デュランド氏は、「拡散モデルが誕生してからというもの、反復回数を減らす方法が聖杯のように探し求められていました。それがついに1回のステップでの画像生成が可能になり、演算コストが劇的に削減され、生成の過程が加速されることに大変興奮しています」と話しました。
⇧ amazing...
100ステップを1ステップにするって、もうステップ数の削減は限界と言えそうですな...
ソフトウェア開発の指針のための基盤を提供するEssenceとは
「著書『現場で役立つシステム設計の原則』」でお馴染み、増田 亨（ますだ とおる）氏の登壇されていたイベントに参加して、その存在を知ったのですが、「Essence」とは、
⇧ 上図のような感じで、「開発プロジェクト」の活動について評価するための仕様らしく、イメージとしては、
⇧「知識レベル」が「イデア」で、「運用レベル（実体）」が「現実世界」と考えると分かりやすい気がする。
理想の「ソフトウェア開発手法」を想定して、各々の「開発プロジェクト」がその理想を満たしているかどうかを確認しよう、という意図かと。
つまり、実際の「開発プロジェクト」が理想通りに進行しているんだっけ？というのを、「Essence カーネル」が想定している最適解（本質）でチェックするということらしい。
なので、「Essence カーネル」が想定している最適解（本質）が正しいという前提で話を進める必要がありますと。
引き続き、増田さんの資料が分かりやすいので、「Essence カーネル」の話に戻ると、
⇧ 3つの領域が登場して、
⇧ 3つの領域に、一般的な「開発プロジェクト」を進める上で対応が必要な登場人物を7つ当てはめますと。
で、各々の登場人物について、状態（実現しなければいけないこと）が列挙されていると。
⇧ 各々の状態を次の状態に遷移させる必要があり、
⇧ 上記のようなタスクが必要になってきて、
⇧ 状態とタスクの関係が上図のようになると。
最終的に、状態に対するタスクを完遂するために、
⇧ 上記のようなスキルが必要になると。
「開発プロジェクト」に必要な要素の全体が俯瞰できますと。
そもそも、何故、「Essence」が生まれたのかというと、
SEMATは2009年9月に、人々のソフトウェア開発手法への関わり方を抜本的に変更する時期に来ていると感じた3人、Ivar Jacobson、Bertrand Meyer、Richard Soleyによって創設された [3,4,8] 。彼らは行動宣言を書き、いくつかの致命的な問題を特定し、なぜ行動が必要かを説明し、そして何が必要なのかを示唆した。その行動宣言を以下に示す。
現在のソフトウェアエンジニアリングのいくつかの分野では、未成熟なプラクティス(immature practices)に苦しめられている。
具体的には、以下の問題を含む。
- 言葉の流行が、エンジニアリングの一分野というよりファッション業界のようである。
- 堅固で広く受け入れられるような理論的基礎を欠いている。
- 非常に多くの方法論(methods)とその派生であふれ、それらの違いはほとんど理解されず作為的に強調されている。
- 信頼できる実験的評価(experimental evaluation)と妥当性確認(validation)を欠いている。
- 産業界の実践(industry practice)と学界の研究(academic research)の乖離。
⇧ とあり、
『ソフトウェア開発手法に対するアプローチがイケてなくない？抜本的な見直しの時期に来てるんじゃない？』
ってことで、結局のところ、開発手法がいろいろあるのは構わないけど、開発で必要になってくる部分の本質は変わらないはずだから、その部分を抽出して、あるべき姿として雛型にしてしまえ、という経緯のようです。
基準を決めよう、ってことですかね。
まぁ、武道とかでも「守破離」って言葉がありますし、芸事では「型破り」や「形無し」って言葉もありますし、闇雲にやっていると効果が薄いですからな。
正確な見本を真似ることが重要なのに、見本がブレブレって感じなのが、「開発プロジェクト」ですと。
不確実性を減らすためにも、「Essence」を上手いこと導入する必要がありそうですと。
一応、
⇧ 前回の記事で触れたのですが、ソフトウェアライフサイクルプロセスの国際規格だったり、日本での開発向けにアレンジされた「共通フレームワーク2013」があったりするようなのですが、「Essence」が生まれたということは、他のフレームワークがイケてなかったということですな。
「共通フレームワーク2013」の「工程」と「成果物」について対応した一覧みたいの用意されてないようですし...
IPAが公開してるドキュメントが中途半端で適当過ぎるので、実際は「工程」と「成果物」について対応した一覧があるのかもしれないですが...
ちなみに、「Essence」の仕様については、
⇧ 上記で、PDFが公開されてますが、300ページあるのと英語なので、読むのに相当時間がかかりそう...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
