Open GENZITSU opened 1 year ago
ニュースデータから知識グラフを構築する際にどのような点で苦労したかをまとめているブログ
以下面白かった点を抜粋
例えば、父と子の間にどのような関係があるのか考えてみます、なのでまず単純な親子関係があるので関係性に親子を作りました。そうすると状況に応じて養子の可能性もあり、生物学的な親と法律的な親の関係がうまく説明できなくなります。
NodeでもEdgeでも、現実世界では基本的に時間に応じて大きく変化しているものですが、グラフデータベースではうまくその状態変化を取り込むことができないです EdgeはまだしもNode自体が変化した場合は...
「何をどれまでラベルをつけたらいいか」の判断により出てくる違うデータセットのバイアスです。どの単語/物をどうラベル付けするかで解像度とかが異なりアウトプットに影響を施します。 一方で、Relation ExtractionはもしN個単語があるとするとNの二乗の関係性が存在していて、その関係性が2単語だけで説明できるとも限らなく、非常にラベル付けがしにくいタスクでもあります REのデータセットはデータセット別で独自の関係性を表示するようにラベル付けをしていて、意図的に汎用性の高いように設定されているので関係性の説明解像度がイマイチ感がある。
OIEの中での関係性は単語との制限がなく、基本的に語句そのものを突っ込んできます。それを単語の数でフィルタリングしても残るは曖昧なis, a のような見ても関係性の意味不明の単語ばかりになります。 文字の関係性判読は基本Relation Extraction一択になっています。古典的な手法ですがその限界を肌で感じました。
Entityを判断する作業ですが、今回のタスクでは語句ではなく文章となると語句の間を跨ぐ認識が上手くできなく、例えば: “That is my house. I lived in there. “の2句だとthereが場所と判断されがちな状況になっています。それを解決するためにCoreference Resolutionの手法が効果的
文章や文法によって確かにEntityは変化しますが、それは全知識グラフとして残すのかというと違うのかと思っています。なので今回の解決法としてはVoting的なやり方で、全文章から抽出した同じ名前を持つEntityに対して、認識されたEntityの回数が一番多いEntityを該当名前のEntityとして扱います。
時制(tense)や複数形(plurals)などの単語を同じく認識するためにstem wordをEntityとして抽出します。 ここで注意すべき点としては、学習のデータでは生データを使っていてstem wordではないため、NER/REモデルで推論する時も生文章のままで推論して、後処理でEntityをstem wordに変換する処理をしています。
著者の1年間の苦労がまとめられていてとても勉強になった。 この取り組み自体はラベルの作成無しでもどこまでできるかを検証してきたようだが、やはりユースケースにあったrelationの定義はマストになりそう。。
研究発表などのスライドをわかりやすくするための9つの推敲技法がスライドのbefore/after付きでまとめられている
複数の説明を1つのスライドで行わない。
関連性の高い物は近くに配置しておく。
矢印を使う場合は使用する意味によってアイコンを変える
メッセージに関わらない要素は削る
図形の形や色などに意味がある場合はスライド全体を通して一貫性を持たせる
情報の羅列や長文の説明は、できるだけ構造化して完結にする
何かを指し示す場合は、視覚的にわかりやすくしておく
言葉の意味が曖昧な物を排除し、明確で限定的な言葉にする
聴衆のレベルに応じて、説明を平易にする
基本的なことではあるが、改めて勉強になる
Metaからリリースされたデータセットの偏り補正のためのOSS (現在beta版)
手元にあるデータと想定していた母集団のデータの統計量を見比べながら、手元のデータの各サンプルのサンプリング重みを調整していくというフレームワークを採用している
公式のデモがわかりやすい
デモを見てみるとサンプリングの際は元のデータからブートストラップしているようなので、重複データが出てくる気がする。 現状はbeta版でGPL2.0ライセンスなので、データセットを補正するようとだけに使うのが良さそう。
テーブルデータ用のドリフト検知ライブラリ
入力データ側(数値・カテゴリカルともに)についてはJS距離やWasserstein距離などを用いて分布の変化を検知し、ターゲット変数についてはχ2乗検定を用いて変化を検知する
そしてビジュアライゼーションが豊富
やってることは単純だが、数行で実行できるのはありがたい。
分布とラベルのペアを用いず、分類したラベルを与えるだけで文書分類を行うことができるhugging face の zero-shot-clasification pipelineの紹介
「含意/矛盾/中立」を判別するモデルに「入力文章」+「"This example is {label名}.」を入力することで、教師無し分類を実現している (参考)
現状は日本語特化モデルはなく、多言語モデルしか選択できない状況にある。
モデルリストを見た感じMoritzLaurer/mDeBERTa-v3-base-mnli-xnli
が良さげか...?
huggingfaceで利用できる文章埋め込みの精度をJSTSとJSICKで比較しているgithub
現状はsonoisa/sentence-bert-base-ja-mean-tokens-v2
が良さげ
Amazon Mechanical Turkによって得られるデータの信頼性について疑問を呈した複数の論文の内容を紹介しているブログ
以下要点のみメモ
An MTurk Crisis? Shifts in Data Quality and the Impact on Study Resultsという論文では2015年末, 2017年春, 2018年夏、2019年春に調査を実施し以下の稀有論を得ている
⑴低品質なデータを提供する参加者が増えた、⑵MTurkを利用した結果が悪化した、⑶回答妥当性指標と事前スクリーニングがデータの質を改善した、という結論を得ています。MTurkの危機は実際に起きていました。
Too Good to Be True: Bots and Bad Data From Mechanical Turkという論文では2022年に実施したAMTでのデータ収集において、以下のフィルターを通したところ、594人の回答者の中で有効な回答がわずか2.6%の14人になってしまったことを報告している
- MTurkが提供する有料フィルター機能の不備
- 同意書に関するクイズへの適当な回答
- 途中でやめちゃった
- 注意チェックに引っかっかった
- 速すぎる回答
- お前は誰だ?チェック
ただ、この論文では60分に及ぶ回答を求めていたので、データの質もそうだが、その他色々な理由がありそう
クラウドソーシングサイトによるデータ収集はとても勘弁だが、今まで以上に注意を払ってデータを扱わないといけないことがわかった
自社でワーカーを抱えているアノテーションベンダー会社にとっては追い風かも
画像生成AIを実際のライブパフォーマンスに適用した事例の紹介
テクニカルな面で面白かったところを抜粋
また今回の映像では、ミクロ・マクロスケールを横断する表現というのを一つのテーマとして掲げていました。 そのような世界観を実現するために、Stable Diffusionを使ってスケール感の異なる様々な画像を大量に生成し、組み上げることで映像を構築していきました。生成の際にはLexicaのようなテキストと生成画像をペアで閲覧できるギャラリーサイトを活用して入力テキストを検索/編集しリストアップ、そしてそれら各テキストに対してそれぞれ数千枚づつ画像を生成していきました。
これらの画像群を映像としてシーケンスを組むために、今回は画像の特徴量に基づいて画像をソートするという手法を採 具体的には、各画像の特徴量を一般的な画像認識モデルを用いて抽出し、画像間の距離を計算し、それらを最短距離で一周するルートを巡回セールスマン問題として解くことで、画像の類似度に基づいて大量の生成画像をソート
今回はこのソート動画にAIを用いたフレーム補間を組み合わせました。元々連続していない画像間を補間するため当然破綻が生じます。その破綻はぐにゃりとした独特のテクスチャとして立ち現れます
より人の痕跡を残しつつ、エフェクトを適用するためのテク
Stable DIffusionではマスクを使用することで指定領域のみエフェクトを適応することが可能ですが、その方法を試したところ単純なスタイル変換とあまり差が感じられませんでした。 今回は、元素材から人領域をSemantic Segmentationを使用してくり抜いた動画をモデルに入力し、特にマスクは使用せずにエフェクトを適応しました。その結果、人としての痕跡は残しつつも大幅にテクスチャや形状を変更することに成功
本職の人が触るとやっぱすごいな...
LightGBMのパラメータチューニングガイド (2022年末著)
しばらく触ってないとわすれるので、まとはありがたい
OpenAI API とGoogle App Scriptを用いて、スプレッドシートからGPT-3を叩く方法を紹介している記事
以下のように関数を通してAPIを読んでいる
すごい (小並感)
モバイルゲーム会社の機械学習グループを立ち上げた話
KLabというモバイルゲーム会社で機械学習グループを立ち上げ、わずか2年で目覚ましい成果の数々を上げた方法論を紹介している記事。
以下重要そうなところだけ抜粋
ResDevOps
通常半年 ~ 一年周期で行われる研究の成果をスムーズに事業に転換するために考案された方法論
以下エッセンス
本来時間のかかる研究を2週間に納めるために、github flowを用いて複数人で一つのアルゴリズムの改善をするスタイルをとっている
また、大規模なモデルによる実験を複数回行う必要があることもあるので、学習基盤としてスパコンを利用している
コメント
足回りを強化しておく重要性がとても伝わってくる。
出典
モバイルゲーム会社の機械学習グループを立ち上げた話