weekly useful materials - 09/14 -

[GENZITSU]

Dockerfile ベストプラクティス／2022夏

Dockerfileを書く際に気をつけた方がよいポイントが網羅的に整理されている。

自分が知らなかった場所だけメモ

syntax

シンタックスのバージョンを指定します。公式では1.x.xの最新のバージョンを使うよう推奨しています。

# from https://qiita.com/NI57721/items/8179c6f3f29573af05a2

# syntax=docker/dockerfile:1

LABEL

イメージにラベル情報を付け足すことができます。コメントのようなものですね。ライセンス情報やプロジェクトのバージョンを書いておいたりします。Docker 1.10以前は、レイヤーの数を減らすために複数のLABELを1行にまとめて書くことが推奨されていましたが、今はその必要はありません。

# from https://qiita.com/NI57721/items/8179c6f3f29573af05a2

LABEL com.example.version="0.0.1-beta"
LABEL vendor1="ACME Incorporated"
LABEL vendor2=ZENITH\ Incorporated
LABEL com.example.release-date="2015-02-12"

aptよりもapt-getの方が良いらしい

後方互換性が大事なスクリプトでファイルで利用する場合はapt-getの方が良いとのこと

# from https://qiita.com/NI57721/items/8179c6f3f29573af05a2

SCRIPT USAGE AND DIFFERENCES FROM OTHER APT TOOLS
           The apt(8) commandline is designed as an end-user tool and it may change
           behavior between versions. While it tries not to break backward compatibility
           this is not guaranteed either if a change seems beneficial for interactive use.

           All features of apt(8) are available in dedicated APT tools like apt-get(8) and
           apt-cache(8) as well.  apt(8) just changes the default value of some options
           (see apt.conf(5) and specifically the Binary scope). So you should prefer using
           these commands (potentially with some additional options enabled) in your
           scripts as they keep backward compatibility as much as possible.

|を使う場合はpipefailを用いてエラーをキャッチする

|オンリーで利用する場合前段が失敗しても後段が成功すると全体としては成功とみなされてしまうため

# from https://qiita.com/NI57721/items/8179c6f3f29573af05a2

RUN set -o pipefail && wget -O - https://some.site | wc -l > /number

ENVでパスワードを設定してはいけない

ENVを実行する度に中間イメージが作られるため、後から環境変数をunsetしてもdocker historyなどで参照できてしまいます。従って、パスワードなどのクレデンシャルな情報は記入しないようにしましょう。

ONBUILD

いまいちユースケースがわからないがこういうのもあるらしい。

Dockerfileのビルドが完了した後に実行する命令を指定できます。ONBUILDで指定した命令は、ONBUILDが書かれたイメージの任意の子イメージに対して、子イメージの他の命令が実行される前に実行されます。 ONBUILDは指定したイメージに対してビルドを行いたいという場合に便利です。ただし、ONBUILDの中でADDやCOPYを使用する際は、新しいビルドのコンテキストでファイルなどが存在していないと元のイメージのビルドまで失敗してしまうので気を付けましょう。

コメント

ベストプラクティスの大体は既知のものだったので自身の成長を実感する。LABELは複数人で共用サーバーを使う場合にどのイメージが誰のかを把握するために使えそうだ。

シンタックスは新しめの構文を使い時に使うものっぽい

出典

Dockerfile ベストプラクティス／2022夏

[GENZITSU]

AIを活用した誤字検出機能でよりスマートになるゲームシナリオ作り【CEDEC 2022】

cygamesでは昨年からゲーム製作効率化のために自然言語処理を用いた誤字検出AIを作成し運用していたのだが、それがさらに進化したらしい。

(※ CEDECとは日本国内で最大級のゲーム開発者による技術イベント)

初めはシンプルなところから

誤字には漢字の誤り、余計な文字の入り込み、補助動詞を漢字にしてしまう（“～してほしい”を“～して欲しい”にするなど）といった種類があり、まずは誤字の位置を求める機能が開発された。

前回からの改良点①: 検出位置だけではなく、訂正候補も表示することで、ユーザーが判断できるように

前回からの改良点②: BERTの利用

ちなみに訂正前後でトークン数が異なってしまう問題にういてはを利用しているとのこと。

学習に使われたデータセットは、ゲームシナリオの文章と、それに独自の方法で誤字を入れ込んだ文章だ。ゲーム中に表示される1行の文をひとつのデータとし、元の文章からから5パターンの誤字を追加、さらに正しい文章が正しいと学習するために、元の文章も追加したという。

前回モデルは以下のように複数のMLモデルの組み合わせだったので、それが一つのMLモデルになり推論速度や保守性が高まった

前回からの改良点④: 誤字パターンの増強

以前のバージョンでは、7つの誤字パターンを含む単語リストを使って誤字の入れ換えを行っていたが、新たなバージョンでは“日本語ウィキペディア入力誤りデータセット”を導入し、データ量が大幅に増加。

日本語Wikipedia入力誤りデータセット (v2) はこの界隈では珍しく商用利用可能な言語資源である。

到達精度は以下

かつて40%程度だった誤字の位置検出の精度が60%程度まで伸びている。

コメント

利用者が使いやすい形でAIの機能追加を行っているところは見習っていきたい。 複数MLによる組み合わせコンポーネントは一つ一つのモデルに仮定を挟むことでモデル作成に必要とするデータの量を軽減させることが可能だが、それゆえメンテナンス品質が低下してしまう。
一方でEnd2Endモデルは学習データの量がバカデカくなってしまうので初期段階では手が出せないということで、複数MLによる組み合わせコンポーネント → End2Endのシングルモデルへの移り変わりはプロダクト/サービスのトラクション増大に伴う必然的な流れなのかもしれない。

出典

• AIを活用した誤字検出機能でよりスマートになるゲームシナリオ作り【CEDEC 2022】
• ゲーム制作効率化のためのAIによる画像認識・自然言語処理への取り組み

[GENZITSU]

生鮮野菜の価格予測 1位 解法 & 振り返り

天候や過去の売買価格を用いてきゅうりやミニトマトなどの計16品目の価格を予測するnishikaコンペの1位解法の共有

コンペの概要

解法の方向性

モデリングにあたって

• 価格は多少の急騰はあるかもしれませんが、基本直近の価格±αくらいで推移しそう。
• 野菜によって価格のレンジが大きく異なるため、種類ごとにモデルを作成した方が良さそう。
• 季節で価格が異なるため、学習期間は検証期間と同一の季節/期間で採用した方が良さそう。

前処理

• 予測対象のmode_priceの過去実績値、天気情報の指数平滑移動平均を特徴量として採用しました。
• 学習させるmode_priceは、最新のデータの平均値±2SDでクリッピングしています。

パラメータの決定方法

• 野菜の種類ごとにベイズ最適化を用いて決定しました。
• 最適化するパラメータは、Lightgbmのハイパーパラメータと学習させる期間の２種類です。
• 学習させる期間は、何年分遡るか、前後何ヶ月分を参照するかの組み合わせで考えています。図は、２年分遡り、前後２ヶ月を参照する場合の各データの関係を表しています。

結果

頭ひとつ抜けてる感じ

コメント

学習データに用いる期間もハイパラ探索させているのが印象的。
ハイパラの探索は過去データをうまく使ってCVして決めているのだろうか。

出典

• 生鮮野菜の価格予測 1位 解法 & 振り返り
• 生鮮野菜の価格予測コンペ

[GENZITSU]

オンラインショップの商品検索改善に挑戦！KDD CUP 2022で9位入賞した手法の紹介

アマゾンの商品検索における検索クエリと商品の関係性分類タスクにおいて、9位に入賞したドコモのチームの解法共有

タスクの概要

以下のようなクエリと商品のペアにつけられた関係性ラベルの値を分類するタスク。
使える情報はクエリと商品の言語, 商品のタイトルと説明文, 販売元など。

英語、日本語、スペイン語の3言語からなる商品で構成され、検索クエリー商品のペアが約260万件提供。

言語の比率は、英語が69.4%、日本語が17.0%、スペイン語が13.6%で、ラベルの比率は Exact 65.2%、Substitute 21.9%、Complement 2.9%、Irrelevant 10.0%

9位の解法

① 不均衡データ対策

最初に多数派のデータをランダムにアンダーサンプリングしてクラス間でサンプル数を揃えて学習した後に、すべてのデータでFine-tuningするという、Two phase Lerningを採用

②ラベル誤り検出

データセット中に間違いっぽいものがあるので、それを修正するためにConfident Learningを活用。

タスクの説明で紹介した実際のデータを見てみると、例えば4行目のデータでは「針なしほっちきす」に対して商品コードB09F3B413Jの商品がExactと判定されています。しかし、この商品はproduct_bullet_pointに「使い針タイプ」という説明があり、針があるホッチキスのようです。このようにラベルに誤りが含まれていることがあります。

Confident Learningは著者実装のcleanlabというものがあり以下のように簡単に利用できる。

ラベル誤りを検出するのに必要なのは、正解ラベルと各クラスの所属確率のデータです。 Cross-validationを行ってモデルの学習に使っていないデータに対して正解ラベルと各クラスの所属確率を用意して実行します。

from cleanlab.filter import find_label_issues

ordered_label_issues = find_label_issues(
    labels=labels,
    pred_probs=pred_probs,
    return_indices_ranked_by='self_confidence',
)

confident learningの概要は以下

訓練済みのモデルを利用して、noisy labelで学習したモデルが出力するラベルの分布とnoisy labelの同時分布を考えて

以下のように同時分布からさ算出されるサンプル数分、予測確率の差が大きいものからnoiseとみなしていく。

③ 分類モデル

以下のようなCross Encoderという手法を採用。
実装自体はSentenceTransformersを活用すれば以下のように利用可能

model = CrossEncoder('モデル名', num_labels=ラベル数)

今回はトークンをより意味のある分割にするために言語別BERTも利用した。

今回は多言語向けモデルとしてMicrosoftのmDeBERTaを利用しました。 言語別のモデルには、英語はMicrosoftのMPNet、日本語には東北大学乾研究室で公開している日本語BERT、スペイン語にはHuggingFaceでダウンロード数が最も多かったスペイン語BERTを利用しました。

④アンサンブル

多言語モデルの方が全ての商品ペアのデータを活用できるため重みづけが大きくなっているのかも？

今回は、コンペの環境で実際にsubmitしてみて、多言語モデル：言語別モデル＝2：1で重み付けする方法が精度がよかったので重み付け平均を採用しました。

⑤後処理

以下のようにクエリと商品タイトルの最大重複文字割合は最終的に割り振られるラベルに大いに影響していることが判明。

一方で予測が間違っている際のTop1,Top2のpredictionの差は小さい場合が多かったため、以下のようなルールを導入

「Top1とTop2の差が0.2未満かつ検索クエリの80%以上が商品タイトルに含まれていたらExactにする」

もしかストESCIのラベルは人間が降っているのではなく、カスタマーの購買行動をもとに機械的に割り振られているのかもしれない。 (文字列重複割合はダイレクトに検索エンジンの結果に影響を与えそう。)

これらをまとめたablationが以下

アンサンブル関係が最も精度向上に寄与していて、ルールベースによる後処理が次点、confident learningはほぼ誤差(test dataにもそれなりに間違いがあるのかも)

コメント

Two Phase Learning / clean lab / sentence transormersといった実践的(?)なテクをおさらいできてよかった。

商品数がかなり多そうなデータセットであるのにBi encoder (それぞれの入力をBERTにかまして内積を取るやつ)ではなくCross Encoderを利用しているのはコンペティション故だろうか？
実際に使おうとすると都度Cross Encoderに入れるのは相当厳しそうだが、、、
とはいえCross Encoderの方が両方の文章を見て情報抽出ができるので精度が上がりやすいのは納得。

出典

オンラインショップの商品検索改善に挑戦！KDD CUP 2022で9位入賞した手法の紹介

[GENZITSU]

コードの不吉な臭い・バージョン2

マーチン・ファウラーのリファクタリングという書籍で提唱された概念「コードの不吉な匂い」を簡単にまとめている記事。

特に勉強になったものだけ抜粋

☆は第二版にて導入された概念

☆奇妙な名前(Mysterious Name)

名前付けは難しく、それゆえに名前の変更を行うリファクタリングは頻繁に行うことになります。

When you can’t think of a good name for something, it’s often a sign of a deeper design malaise. いい名前が思いつかないなら、設計がまずい兆候である。 Refactoring, 2nd edition

特にML系のコードを書いていると無駄に長い名前の関数が出来上がることが往々にしてあるので、注意していきたい。

☆長すぎる関数(Long Function)

長すぎる関数は適宜関数を分割することで見通しをよくした方が良いよねというやつ。

経験の浅いプログラマーは短い関数を嫌い、全てをmain関数に押し込みます。しかし、プログラミングのためのメンタルモデルが育ってくると、全体像を頭に入れつつ必要に応じて細部を把握することができるようになってきます。こうなると、短い関数の連なりによって構成されたプログラムの方が理解しやすくなります。また、コードの再利用性のためにも、短く役割のはっきりした関数を書くことは重要です。

短い関数を使って、保守性の高いコードを書くための鍵は名前付けです。名前が関数の役割を的確に表していれば、その関数の中身を見なくても、コードを理解することができます。

↓ のコメントも個人的に刺さるものがあった。

また、一つの教訓として、「何かにコメントを付けたいと思ったときは、その処理を関数化すべきである」というものがあります。

長すぎるパラメータリスト(Long Parameter List)

特にMLはめちゃくちゃ長いパラメータをtrain()が引き受けることが多々ある。
configクラスや、config.yamlを作ることで簡素化してきたい。
さらにはパラメータの数が膨大になりがちなので、パラメータも適宜意味ごとにclass分けしておくという手もありそう。

関数に必要なものを引数として渡すのは、悪いことではありません。グローバル変数に依存するよりは、はるかにマシです。しかし、長すぎるパラメータリストは悪いコードの兆候です。

引数リストが長い場合、そのリストを1つのオブジェクトにする(Introduce Parameter Object)といったリファクタリングが適用できます。

☆変更可能なデータ(Mutable Data)

MLのコードはdfやtrain_Xなどの同じ名前の変数をコロコロ使い回したりするがやっぱり良くないよねというやつ。
あるobject Aの値を更新するときは、値が変わったobject Aではなく、新しい値がセットされたobject Bを返すべきだよねというのはミノ駆動本の最初の方でもみた気がする。

データへの変更は、予期しないバグを生み出します。関数型プログラミングの考え方では、データ構造に変更を加える際は、値を書き換えるのではなく、変更後の値を持った新しいデータ構造を返すべきである、とされています（そのようにしかできない言語もあります）。

変更可能なデータのスコープが数行程度であれば問題ありませんが、スコープの広い変数が変更可能である場合、それが問題を引き起こすリスクは高まります。

データの群れ(Data Clumps)

最近これと似たような事象に遭遇した。大事

いつも連れ立って使用されるデータは、1つのクラスにまとめた方がいいかもしれません。たとえば、ユーザの名前とメールアドレスは、別々の変数として管理するのではなく、Userクラスのフィールドにするのが良いでしょう。

基本データ型への執着(Primitive Obsession)

整数や文字列といった基本データ型のみでプログラムを書いてます...。 適宜独自のデータ型を定義して行った方がいいですね...

整数や文字列といった基本データ型のみを使用してプログラムを書くことも、経験の浅いプログラマーに見られる兆候です。

たとえば、郵便番号を単なる文字列型に格納することがあります。しかし、郵便番号の扱いには独特のドメインロジックがあり、単純な文字列以上の存在とみなすことができます。このような場合は、基本データ型をオブジェクトで置き換えることを検討すべきです。

コメント(Comments)

そもそもコメントを書かないといけないほど複雑なコードってどうなんだろうねというやつ。

コメント自体は悪いものではありませんが、悪いコードを説明するためにコメントを手厚く書いているような場合があります。 このような場合、関数の抽出などを通して、コメントが不要なコードに改善することができます。

コメント

MLのコード気づいたら汚くなりがちなので、日頃から注意していきたい。

出典

コードの不吉な臭い・バージョン2

[GENZITSU]

【atama plus×カミナシ×キャディ】スタートアップと技術的負債 by SELECK イベントレポート

MLプロジェクトでありがちな技術的負債とそれを極力産まないためのcaddi AI Lab内の取り組みが紹介されている。

特に関心したところだけ抜粋。

ありがちな技術的負債

• 時間が経つと再現不可能になるモデル、データ、バージョン管理
• 機械学習のライブラリは扱っている問題が複雑故にwrapにwrapを重ね難度化しています
• 機械学習モデルの進捗も早く、画像認識分野などでは1年前のモデルは古いと言われたりします
• “厳密”にあらゆるバージョンを管理する事が本来求められますが、非常に早い業界スピードの中では劣後されがちです

→ あるあると言われているがちゃんとrequirements.txtのバージョンを固定 & Docker & そのとき使ったデータを固定化しておけばある程度対処可能そう

• モデル推論、学習に関連するテストコードが書きにくい事をいいことに前処理やAPI実装に書かれないテスト
• 複数の機能がwrapされた便利な機械学習ライブラリを使う事が多い反面、method単位のtestが書きにくくなっています
• そういった背景から、モデルの周辺コードのテストがサボられるケースがあります
• テストのないコードはそれだけで負債と言えます

→ 最後の一文がボディブローのように聞いてくる。 → 同様のタスクに継続して取り組まないのであれば書きづらいのではあるが...

CADDi AI Labにおける対策

• 小チーム制とチーム内PdM、Tech Lead
• PJが大きくなり人が増えれば複雑性が増し負債が発生する可能性は高まるのでチームは小さく保っています
• 小チーム内の事はメンバー同士の手が届く状態にしています
• チーム間での「負債を許容するか」「返却するか」はTech PdM / Tech Leadが判断しています
• 判断にはビジネス上の意義や他チームの状態など様々な要因が絡むためです

→ メンバー同士が手の届く状態にすることで何が負債であるかの把握が進む気がする。 多くの現場では何が負債であるかすら把握されずに、いつの間にか破産申請(コードの作り直し)を出すことになりそう。

• ドキュメントの記載
• 機械学習エンジニアもDesign Docや実験ドキュメント、Model Cardを書いています
• 実験ドキュメントはGitHub上で管理し、lexicoを使って社内から閲覧できる状態にしています
• 基本的にフリーフォーマットですが実験を他者に引き継げる状態を期待しています **- Model Cardはproductionにdeployされるモデルについて以下のような内容を必ず記載しています
• 概要
• 開発者
• 入力
• 出力
• 学習データセット、方法
• 評価方法、評価結果
• 想定ユースケース
• 性能に関する要素**
• これらはレビューにより負債化を防止したりもしています
• プロジェクトが進んでも方向がブレにくくなるだけでなく、チームとして技術的負債をそもそも生みにくくする体制、知識共有の役割を果たしています

→ Model Cardは増えていくMLプロジェクトを管理していく上で、絶対に必要だと個人的には感じている。
使用したデータセット(入出力の意味含む)とそれを動かすためのコード, その時の精度を保存しておくだけでも良いと思う。
あの時作ったデータが別のタスクで活用できるようになったりするので

• Working Agreement
• ローカル実験から本番まで「成果」となるラインをAgreementとして共有
• 必須の項目は「時間を掛けてやる」ことを明言しています 今もまさにWorking Agreement追従のためにスプリントを丸々使って改修を行っているメンバーが居ます。

→ 個々人や特定チームの自助努力に委ねても全くワークしないので、全体として共通認識を固める必要がある。 → どんなに締め切りがきつくてもやらねばならない事として仕組み化することが重要。

スクショ中の以下が特に響いた。 → 他人が再現できない実験コードは価値を産んでいない。 → preprocess, postprocessのtestを必須とする。 (test作りにくいけど、そこどう乗り越えてるんだろう) → Example Dataによる動作確認必須

コメント

多くの技術的負債を借りた状態で産む成果は、複利で損害を発生させ続け実質損失であることを強く意識したいと感じた。

出典

【atama plus×カミナシ×キャディ】スタートアップと技術的負債 by SELECK イベントレポート

[GENZITSU]

MMDeployでJetson AGX Orinの物体検出速度をAGX Xavierと比較してみた

MMDetectionで提供されているモデルの推論速度をMMDeployによるTensorRT化 / 使用デバイスの軸で比較検討している記事。

大まかな推論速度を知るのにとても有益な記事。

実験設定

使用したデバイスは以下の2点です。

• Jetson AGX Xavier
• Jetson AGX Orin 32GB いずれのデバイスにもNVIDIA JetPack SDK 5.0を導入しています。 評価データセットは5000枚の画像からなるCOCO Val 2017を使いました。 そしてMMDeployは変換したモデルのベンチマークを計測することができるので、本記事ではこの機能を用いてXavierとOrinそれぞれにおけるTensorRTモデルの推論速度(FPS)を計測しました。

実験コードは こちら にアップロードしていますので参考にしてください。

これまではMMDeployはOrinで利用できなかったのだが、著者のPRにより可能になったとのこと。すごい

実は以前までは内部で使われているビルドオプションの都合上Orinに対応したバイナリがビルドできずMMDeployをOrinで使うにはひと手間必要でしたが、私のプルリクエストによりversion 0.6以降はデフォルトの設定で利用できるようになっています :)

結果

performanceとspeedの観点だとYOLOX-sの優秀さが目立つ。Orinを用いるだけで60fpsを超えるのは最早ギャグ。
当然ながら2stage系はOrinでも遅いのだがTensorRT化しても30fps程度なのは驚き...

コメント

なんとなくYOLOXだよなぁと思っていたが、これほどまで差がついていたとは驚き。
訓練のしやすさや精度、速度、対象物体の大きさの観点でみるとFaster-RCNNも最新のモデル達と比べて意外と負けてない。

出典

MMDeployでJetson AGX Orinの物体検出速度をAGX Xavierと比較してみた

[GENZITSU]

深層学習 Day 4 - BatchNorm、LayerNorm のまとめ

Batch / Layer / Instance Normの違いが一目瞭然なまとめ

コメント

個人的には巷にあふれる以下の図の数倍わかりやすいと思う

出典

深層学習 Day 4 - BatchNorm、LayerNorm のまとめ

[GENZITSU]

ArcFaceの仕組み

ArcFaceが導入された背景や何に対する損失なのかを丁寧に図解した資料。

コメント

わかりやすい。

出典

ArcFaceの仕組み

[GENZITSU]

Kaggleで使用される敵対学習方法AWPの論文解説と実装解説

表題の通り

コメント

AWP完全理解者になった

出典

Kaggleで使用される敵対学習方法AWPの論文解説と実装解説

[GENZITSU]

NeRFモデルの品質を上げる方法

表題の通り。

入力写真の撮影

写真はスマホやデジカメで撮影します。解像度が高いほど良いです。 オブジェクトの写真が さまざまな角度と視点 から撮影されていることが非常に重要です。

また、写真の数 も重要です。 10 ～ 30 枚の写真をお勧めしますが 撮影枚数が多すぎると、カメラ位置の推定が遅くなり、難しくなり、視点の悪いカメラが生成される可能性があります。

さらに、画像はオブジェクトのパースペクティブを共有する必要があります。つまり、写真の間に別の写真のパースペクティブが見えようにすべきです。 そうしないと、カメラの位置を計算できなくなります。

カメラ位置が推定しやすいような画像、具体的にはSIFTが計算しやすいような高コントラスト画像を入力する

カメラの位置を計算するには、Colmap と呼ばれる手法を使用します。 Colmap は、2D 画像から 3D 点群を再構築するために使用されるソフトウェアです。 ただし、異なる視点から撮影された同じオブジェクトの写真を使用して、カメラの位置を三角測量するためにも使用できます。 Colmap の心臓部は SIFT (Scale Invariant Feature Transform) と呼ばれます。

SIFT 特徴は通常、コントラストの高い画像の一部です。通常 オブジェクトの境界線、角、または先端 のように。 SIFT では、対照的な境界線、角、または先端を持つ画像が必要です。そうでない場合、特徴を抽出できません。 SIFT は、空の雲、白い壁、光沢のある反射素材など、 フラットまたはプレーンなコントラストを持つ画像の特徴を抽出できません。

そのため、NeRF 画像には SIFT 機能 (角、境界、またはヒント) が必要です。スキャンしたいオブジェクトにこの機能がない場合は、 Colmap がカメラの位置を正しく計算できるように、背景にコントラストの高い別のオブジェクトを配置します。

colmapのデバッグ

誤ってカメラ位置が推定された写真はデータから削除するとクオリティが上がる

Colmap は非常に便利ですが、完璧ではありません。 Colmap は向きの悪いカメラを生成することがあります。 不良カメラを検出するには、NeRF プロジェクションが影またはゴーストオブジェクトを作成するかどうかを確認します。そうである場合は、カメラの番号を書き留めて、JSON から手動で削除します。

コメント

NeRFにこのようなTipsがあるのは知らなかった。
上記を克服するような論文をいくつか出てそうだが、NeRF実装時の基本的な確認事項として押さえておきたい。

出典

NeRFモデルの品質を上げる方法

[GENZITSU]

「3Dデジタル生物標本」1400点以上、九大が公開　ダウンロード自由、メタバースでも利用可

九州大学は8月26日、3Dモデル化した生物標本1400点以上をオンライン公開した。被写体をさまざまな角度から撮影し3Dモデル化する手法「フォトグラメトリ」を使い、水生生物など700種以上1400点のデジタル標本を作成したという。ライセンスはCC BY 4.0で、誰でも自由にダウンロードや配布が可能。

九州大学持続可能な社会のための決断科学センターの鹿野雄一特任准教授が開発した、生物標本を対象としたフォトグラメトリ手法「バイオフォトグラメトリ」を使い、3Dモデルを作成した。これまで生物学分野ではフォトグラメトリはあまり活用されず、CTスキャナーやMRIでの内部構造のモデル化が主流だったという

コメント

この3Dモデルさあればある日突然コクワガタ検出器を作ってと言われても対応できるかもしれない笑

出典

• 「3Dデジタル生物標本」1400点以上、九大が公開　ダウンロード自由、メタバースでも利用可
• 配布場所

[GENZITSU]

【CEO直撃】THE GUILD深津氏が画像生成AI「Stable Diffusion」開発元に聞く、AIビジネスの“新時代”

8月31日に実施されたStable Diffusionの開発会社Stability AIの社長に対する取材にて彼らが描く未来が紹介されていた。

面白かったところだけ抜粋

倫理や著作権に関する懸念もありますし、そのすべてに対する答えは持ち合わせていません。しかし、ネガティブな反応よりもポジティブな反応の方が圧倒的に多いのが現状です。

著作権に対する懸念は認識しつつもポジティブな反応の方が世間としては多いらしい。

私はStable DiffusionをAIの民主化のためのツールだと捉えています。8月に発表したものはシリーズの第1弾で、9月には音声、その後は動画、3D、言語、コードにも対応していきます。Dream Studio（Stability AIが展開するStable Diffusionを使った画像生成を可能とするサービス）の完全版はアニメーションの作成にも対応します。

今後は音声や動画、言語、コード生成などもサポートしていく予定とのこと。

Stable Diffusionをトレーニングするために使った最初のデータセットは10万ギガバイトでした。現在のファイルサイズは2.1ギガバイトですが、ゆくゆくは100メガバイトまで縮小させていくつもりです。その100メガバイト、もしくは2ギガバイトのファイルをもとに、想像できるものを何でも作れる。これは素晴らしいことだと思いませんか。

訓練に必要なデータセットのサイズはどんどん小さくなっている

私は「インテリジェント・インターネット」というビジョンを掲げています。個人でも、会社でも、国でも、誰もが自身のためのAIを持てるようになる。私たちは今、消費することを教えられ、消費し続けていますが、それは結果的に私たち自身をも消費しつつあります。一方で、自ら主体的に創造できることほど素晴らしいことはないでしょう。

クリエイティブAIの民主化を進めることで、全人類がクリエイターとなれる世界を目指している。

Stable Diffusionにより、人類全体の創造性が向上していくのです。コストもどんどん下げていきます。来年には100枚の画像を1セント（約1.4円弱）で作れるようにする予定です。

画像生成にかかるコストもどんどん下げる予定。

加えて、私たちはクリエイターがより簡単に報酬を得られるようにしたいとも考えています。そのため、数週間以内には、Stable Diffusionの独自モデルを構築するためのガイドラインを、クリエイター向けに公表します。 マーケットプレイスも構築していきます。そこでクリエイターは独自モデルで生成したコンテンツや、独自モデルの（クリエーターの）特性を他のクリエイターに販売する。もしあなたがピクセルアートに特化したモデルを作ったとしたら、ピクセルアートに関するアセットを求めるクリエイターは、汎用モデルではなく、あなたのモデルを利用することでしょう。

個人が作成したクリエイティブAIのマーケットプレイスを作ることで、クリエイターが収益を得られるようにする。

（表計算ソフトの）「Excel」の登場により会計士の役割が変わったように、物事の本質が変わっていかなければならないのです。（画像編集ソフトの）「Photoshop」や「Procreate」が登場したように、技術は衝撃的なまでに急速に進歩しています。 アーティストにとって重要なのはファンとコミュニティ、そしてナラティブです。これらを代替できるものはありません。アーティストを職業として捉えるならば、その本質は変わっていく必要があるのではないでしょうか。

アーティストの仕事の本質を捉え直す必要がある。

ですが、自身のスタイルを利用されたくないアーティストもいます。そのため、ある有力企業の協力のもと、Stable Diffusionを使ったサービスが、希望するアーティストのスタイルを利用できなくするための仕組みを構築していきます。

自身のスタイルをDiffusion Modelで利用できなくする技術があるらしい

コメント

非常に貴重なインタビュー記事。 Stable Diffusionの学習に必要なデータを削減するテクニックにはどのようなものがあるのだろうか？
今度調べてみたい。

出典

【CEO直撃】THE GUILD深津氏が画像生成AI「Stable Diffusion」開発元に聞く、AIビジネスの“新時代”

[GENZITSU]

keigo_transfer_task

東北大が公開している敬語がつかわれていない390文の日本語文章を日本語話者２名によって敬語変換した評価データセット

コメント

ライセンス不明だけど何かに使えるかも

出典

keigo_transfer_task