2024-08-08 機械学習勉強会
今週のTOPIC[論文] UniversalNER: Targeted Distillation from Large Language Models for Open Named Entity RecognitionMaestro: Data/ML Workflow Orchestrator at Netflix【開発ブログ】クレジットカードの不正利用に打ち勝つために!!<対策を始めて半年後の記録>[blog] Heron-Bench: 日本語Vision&Languageモデルの性能評価ベンチマークの公開[blog] ニューラルネットのレコメンドをメモ化して高速にする[blog] Introducing Structured Outputs in the API[blog] Apple just solved LLM hallucination (from X)[論文]Is ChatGPT Transforming Academics’ Writing Style?[blog]Stable Fast 3Dのご紹介:単一の画像からの高速3Dアセット生成[論文] Transformers are SSMs: Generalized Models and Efficient Algorithms Through Structured State Space DualityメインTOPICSnapper: Accelerating Bounding Box Annotation in Object Detection Tasks with Find-and-Snap Tooling概要手法実験まとめ
今週のTOPIC
@Naoto Shimakoshi
[論文] UniversalNER: Targeted Distillation from Large Language Models for Open Named Entity Recognition
- Microsoft Researchと学生さんの論文 (ICLR2024)
- 商用利用は不可
- ChatGPTを用いてNERのためのInstruction Tuning用のデータセットを構築
- 240,725個のEntityと13,020のEntity Typeが含まれる45,889件のデータ
- PERSONのような一般的なドメインからMEDICAL CONDITIONのような医療ドメインまで幅広く網羅
- 左側のようなPromptを使って作成し、右側の表のようなEntityの分布になっている
- 会話形式のInstruction Tuningを行った。
- 文章を読ませた上で、Entityについて説明を求める。どこにその単語があったかは分からない。
- 例) Hugging Faceで公開されてる
- Negative Samplingとして、元の文章に含まれていないEntity Typeについても出力を求め、空のJSONとして出力させるように学習。
- Negative Samplingの有無で精度が大きく変わる
- 結果
- 43個のNERデータセットかつ、9個のドメインで比較したところChatGPTの精度をZero-shotかつ小さいモデルで凌駕した
- さらにFineTuningを行った結果、SoTAを達成。(BERT-baseの方が強い分野も全然ある)
@Yuya Matsumura
Maestro: Data/ML Workflow Orchestrator at Netflix
- Netflix社がworkflow orchestratorシステムのMaestroをOSSとして公開した。
- ‣
- 水平スケーリングして大規模なworkflow(データパイプライン、MLモデル学習パイプライン等)を管理する。
- 毎日平均50万ジョブ、多い時で200万ジョブ。どういうこっちゃ。
- Docker imageやnotebook、bash script、SQL、Pythonなど幅広くサポート
- DAGだけでなく巡回するようなworkflowもサポートしており、for each loopやsub workflow、条件分岐などの再利用可能なパターンにも対応している。
Maestro now launches thousands of workflow instances and runs half a million jobs daily on average, and has completed around 2 million jobs on particularly busy days.
- Netflixでは無数のworkflowが動いているが、いくつかに分割して異なるクラスタで管理することは、不必要な複雑さを生んでしまうという理由で選ばなかった。データもひとつのDWHに存在していることもあるし。
- workflowは以下のようなJSONで定義する。 とかが見える。
- プロパティ:作成者や所有者の情報、実行設定などが記述される
- メタデータ:IDや説明、タグ、タイムアウト設定、重要度レベルなどが記述されており、バージョニングされている。追跡や差し戻しが容易に行える。
例:‣
- 実行設定
- Sequential Run Strategy:FIFOで一つずつ実行される。それまでの状態に依存せずに実行されていく。
- Strict Sequential Run Strategy:基本FIFOでひとつずつ実行されるが、失敗すると止まる。解決されるまで後続のworkflowはキューに入れられたまま。
- First-only Run Strategy:実行中のworkflowの完了を待ってから次のworkflowをキューに入れる。冪等性担保。
- Last-only Run Strategy:実行中のworkfllowが最新のトリガーされたものであることを保証する。実行中に新しいworkflowがキューイングされた場合、実行中のものを停止し新しいものを実行する。常に最新のデータを処理したいようなケースに有効。
- Parallel with Concurrency Limit Run Strategy:並列実行。古いデータのバックフィルなどに有効。
- コードを使って動的なパラメタを機銃することができる。
- 無限ループ仕込んでしまってOOMで死ぬとか、セキュリティ的な懸念がある。
- 独自の言語(SEL; safe expression language)を開発し、組み込まれたコードを解析して安全を担保する。
- Workflow Execution Patterns
- Foreach Support:反復処理。foreach内のサブグラフの実行は、別のworkflowインスタンスとして処理される。
- Conditional Branch Support:条件分岐
- Subworkflow Support:あるworkflowから別のworkflowを実行する。
@Tomoaki Kitaoka
【開発ブログ】クレジットカードの不正利用に打ち勝つために!!<対策を始めて半年後の記録>
- 赤裸々に書いてあってめちゃくちゃ面白い
- 過去記事はこちら↓↓
- 2024/2/5【開発ブログ】クレジットカードの不正利用に打ち勝つために!!<その後>
- 2023/11/22【開発ブログ】クレジットカードの不正利用に打ち勝つために!!<後編>
- 2023/11/21【開発ブログ】クレジットカードの不正利用に打ち勝つために!!<前編>
ひたすら目視で不正利用の傾向を分析(涙ぐましい
- 明らかに会員氏名がおかしい!
- 明らかに会員氏名がおかしいものはやっぱり怪しい注文が多いです。氏名が”様名様名”とか”名前”とか。さすがにそれは注文確認時に気づけます。それで騙せると思っているのか!?と問いたいです。ほかにも名前が会員登録されている氏名のふりがながおかしいものはかなり怪しいです。例えば津田さんは”つだ”ではなく”しんでん”、小川は”おがわ”ではなく”しょうせん”など。音読み優先プログラム(そんなのあるのか!?)で変換されているのかもしれません。でも難しいのは、本当に「そうなの?あってる?」という難しい読み方の苗字が日本にはたくさんあり、どれも疑わしく見えてくるということです。。。また、会員名とカード名が違うのも怪しい類なのですが、割と問題ない場合もありこれだけでは決め手にはなりません。
- Eメールアドレスに傾向あり!
- 不正利用されやすいEメールアドレスドメインを絞り込みました。ここにも類似の記事がありますが、弊社のデータと遠からずです。ただ、Gmailやhotmailは全体数がとても多いのでそれがわかったところで1個1個チェックするのは現実的ではないという問題もあります。また、@docomo.ne.jpや@ezweb.ne.jpなどキャリア系は本体契約しないと取得できないから安全とか、フリーメール系でも二段階認証が必須なものより簡単に取得できるものの方が怪しい率が高い、とかは容易に想像つきます。もちろんアカウント自体を乗っ取られる可能性もあるので100%ではないですが。他にも、Eメールアドレスに使用するローカル部(ユーザー名?)にも一定の傾向を出すことができました。
- アクセス元にも傾向あり!
- 不正利用を試みる側も効率的に不正注文を入れたいでしょうから、それ用のプログラムを作るのでしょう。そのため、Amazonなどのホスティングサーバー経由のアクセスは怪しいものが多いです。ただ、企業経由などホスティングサーバー経由の問題ないアクセスもそれなりにあるので、決め手とはなりません。また、海外からのアクセスも要注意です。というのも弊社は海外発送を承っていないからです。ただこれも、海外在住の方が日本の方に贈答するとか海外出張中に注文するとかが一定数あるので、これだけでは決め手とはなりません。実際、国内の有名なプロバイダー経由の不正注文もかなり多いです。
- 賞味期限が長いもの、賞味期限がないものは狙われやすい
- これは傾向分析せずにもわかっていたことですが、賞味期限が短い生鮮品や保管管理が難しい冷蔵・冷凍品よりは賞味期限が長い常温品や酒類や米、サプリメント、賞味期限がない食器や調理器具が圧倒的に狙われやすいです。転売しやすいからですね。ただこれも必ずそうなわけではなく、先月まさに即日出荷の松茸がやられてしまったばかりです。。。
- なんとなくの違和感がある注文はアウトなことが多い
- 例えば、近江牛のA5ランクを1.5キロを冷蔵便で頼んでいるのに日付指定していない、とか、夏なのにお歳暮熨斗指定、とかです。ケースは色々ですが、通常の注文と買われ方が違うものはアウトなことが多いです。そういう注文の送り先を調べてみたら過去に不正注文の送り先として使われていたり、レオパレス宛てだったりします。ここの微妙な違和感は将来的にはAIという可能性はあるかもしませんが、現時点ではシステム化できないのでサイトのお客様を理解し、注文一つ一つと向き合って知見をためていかないといけない領域なのかなと感じています。
- → 詳細は書いてないがルールベースで不正検知ロジックを追加。
- 多分ECなので発送する前に検知できればOKで、アラートみたいなのを出して発送する前にアラート出ているものを人間が追加でチェックしてそう
- イメージ的には8割はシステム化し、2割は人による確認を行っているとのこと
- その後の結果
- めっちゃ効果出ててすごい
- その後の傾向
- 低額の不正注文が増えた
- 常温や非食品だけでなく、フルーツや鮮魚の不正注文が増えた
- 手口が巧妙になってきた
@Yuta Kamikawa
[blog] Heron-Bench: 日本語Vision&Languageモデルの性能評価ベンチマークの公開
- Turingさんが公開した日本語Vision and Language Model(VLM)のベンチマークHeron-Benchについてのブログ
- 今まで高い言語能力を持ったLLMを用いて、日本語データで学習されたVLMはほとんど公開おらず、そもそもちゃんと評価する方法もなかった
- 今後の日本語VLMの発展に向けて、Heron-Benchという自動運転に限らない汎用的な性能ベンチマークを提案
- 日本特有の画像とそれに対するいくつか質問のペアを含む
- 定量評価
- closedなモデルであるGPT-4VとClaude 3 Opusがやっぱり強い
- 定性評価
- 正解している例
- 間違っている例
- GPT-4VとかClaude 3 Opusでも土俵に3人力士がいるのに2人と回答し、間違えている
- 一般常識(普通土俵上には対戦する2人)からくるバイアスではと考察されている
- VLMはカウントが苦手みたいな、過去の機械学習勉強会で取り上げられてる話もありそう
- 自動運転に限らず、日本語VLMの発展のための取り組みということ
@Shun Ito
[blog] ニューラルネットのレコメンドをメモ化して高速にする
- レコメンドの推論時に、itemのembeddingを毎回言語モデルを呼び出して生成せず “メモ化” されたものを参照することで高速に推論できる
- 細かい工夫だいじ
@Yosuke Yoshida
[blog] Introducing Structured Outputs in the API
- OpenAIでJSON Schemaで指定した構造で出力させる Structured Outputs
- 二段階のアプローチを採用
- 複雑なスキーマを理解し、それに一致する出力を生成させるようにトレーニング
- 性能は向上したがベンチマークでは93%であり、完全に一致させることはできなかった
- 決定論的なエンジニアリングベースのアプローチ
- 制約付きサンプリングまたは制約付きデコードと呼ばれる
- 通常、モデルが出力を生成するためにサンプリングされるとき、次の出力として任意のトークンを選択できるが、この柔軟性がミスを犯す原因
- 有効な出力を強制するために、モデルを提供されたスキーマに従って有効なトークンのみに制約することで無効なトークンの確率を実質的に0にする
- 実際に試してみたがあまりうまくいかなかった
- JSON Schemaのすべての仕様に対応しているわけではない
- e.g. format: date
- 深いネストのスキーマに対応できない。エラーではネストの上限は5までとある。
- 7 levels of nesting exceeds limit of 5
- ネスト減らすためにプロパティ減らしたら謎のエラー (原因不明)
- The server had an error while processing your request. Sorry about that!
@Ryuhei Kawabata
@Shuitsu Koyama
[論文]Is ChatGPT Transforming Academics’ Writing Style?
どのようなの論文か:chatgptのrelease後のarXiv論文のabstractにどのような変化が見られるか分析
データ:arXivに投稿された論文.2018/8~2024/1までの100万本
分析方法:単語頻度の変化を測定.gptのリリース前後の特定の単語の出現頻度の観察
分析結果:
- are,isといった一般的な単語の頻度が2023年に大幅減少.個人的にはbe動詞が減ることに少し驚き。
- 明らかに頻度上昇している単語が見られる. significant, effectivelyとか.
- significantやeffectivelyとか、形容詞副詞の多様性が失われていそう
- csの分野で特に影響が大きい.数学分野ではそうでもない.
- 個人的に思ったこととして、llmに数学聞いても頓珍漢な答えしか返ってこないので数学者に使う習慣があまりなかったりするのかもしれない、とか。
- cs分野で思ったより顕著なのが面白い。みんな便利なもの大好き。
結論:学術論文への影響の増大が統計的根拠に基づき確認された. gpt以外のllmを使用している場合もあるため, それらの影響はgptと類似していても一致してはいないはずなので注意する. より良い指標も考えられるはず.
@NishimuraTakayuki
[blog]Stable Fast 3Dのご紹介:単一の画像からの高速3Dアセット生成
‣
Stable Fast 3Dは、1枚の画像から高品質の3Dアセットをわずか0.5秒で生成
Stable Fast 3Dは、いくつかの重要な点で競合他社を凌駕しています。
- 比類なき速度:7GB VRAMを搭載したGPUで1つの3Dアセット生成にわずか0.5秒、あるいは Stability AI API で約1秒。
- 高品質なUV展開メッシュとマテリアルパラメータ
@NagashimaShunya
[論文] Transformers are SSMs: Generalized Models and Efficient Algorithms Through Structured State Space Duality
- Mambaと同様、著者はcmuのAlbert GuとPrinceton UnivのTri Dao
- [ICML24 poster]
- Transformerに代わる次世代のモデルであると期待される状態空間モデル (SSM)の最新手法
- 状態空間モデルとは
- 概念自体は制御工学の分野で有名なカルマンフィルタでお馴染みルドルフ・カルマンによって提唱された
- Kalman, Rudolph Emil. "A new approach to linear filtering and prediction problems." (1960): 35-45.
- システムの内部状態を観測データに基づいて推定するための統計的なフレームワーク
- 状態変数と観測変数の2つの変数でシステムを記述
- 状態空間モデルのパラメータ推定の研究(ジェフリー・ヒントン)はじめ、多くの研究
- Ghahramani, Z., & Hinton, G. E. (1996). "Parameter estimation for linear dynamical systems". University of Toronto Technical Report CRG-TR-96-2.
- ニューラルネットと統合され出したのは2016年くらい
- Fraccaro, Marco, et al. "Sequential neural models with stochastic layers." Advances in neural information processing systems 29 (2016).
- 数式
- tは時刻、xは入力、yは出力、hは隠れ状態
- 機械学習におけるSSMの応用
- HiPPO: Recurrent Memory with Optimal Polynomial Projections [Gu+., NeurIPS20]
- HiPPO(High Order Polynomial Projection Operators)を用いた新しいメモリ構造が提案、時系列データのモデル化
- LSSL: Combining Recurrent, Convolutional, and Continuous-time Models with Linear State-Space Layers [Gu+., NeurIPS21]
- 状態空間モデルにHiPPO導入、再帰および畳み込みどちらの処理も可能
- S4: Efficiently Modeling Long Sequences with Structured State Spaces [Gu+, ICLR22]
- H3: Hungry Hungry Hippos: Towards Language Modeling with State Space Models [Fu+, ICLR23]
- 上記の数式において、Mamba以前のS4, H3等々はパラメータA, B, Cは時刻に依存しないTime-invariantなパラメータ
- こうすると計算が畳み込みで表現されるため高速
- しかし表現力がpoor
- この表現力不足を補うためにA, B, Cは時間に依存するように変更したのがMamba
- Mamba-2では、半分離行列(Semi-separable; SSS)の変換が、Mambaと一部のTransformer(線形注意機構)と同様の計算であることを示す
- これにより、Mambaで問題であった”行列”として扱えない問題を解決し、高速で処理することができる
- 表現力を保ちつつ、より高速に
- 詳しくは
メインTOPIC
Snapper: Accelerating Bounding Box Annotation in Object Detection Tasks with Find-and-Snap Tooling
概要
- IUI2024で発表された論文
- 物体検出のためのbounding boxアノテーションを効率化するためのUIを作成し、実験的に有効性を検証
- 提案手法: Snapper
- 人間が描いた粗いbounding boxを、MLモデルで調整 (Snapping) する
- caddiさんのアノテーションUIに関するブログで紹介されていた機能と似ている
手法
- Find-and-Snap Technique と呼ばれる手順でアノテーションしていく
- (Find) 人間が粗いbounding boxを描く
- (Find) bounding boxの周囲含めて探索範囲を決める
- (Find) 入力されたbounding boxをもとに、正しそうなbounding boxを予測する
- (Snap) 人間が描いたbounding boxを予測結果に変換する
- 正しそうなbounding boxの予測方法
- 予測の流れ
- 入力: 人間が描いたbounding box(4頂点の座標)と対象の画像
- 予測したい物体が何かは知らないで予測する
- モデル: ResNet-50ベースのCNN
- 出力: 正しそうなbounding box(4頂点の座標)
- モデルの学習
- データセット: MS COCO(33万画像、91クラス)
- Ground Truthのbounding boxをランダムにスケーリングし、人間が描くbounding boxを再現
- モデルの評価
- 評価指標
- IoU
- 重なり具合を評価。
- 大きなbounding boxの場合、正解の辺や頂点との乖離があっても重なる面積は広くなり、過大評価されてしまう
- IoU自体は使いつつ、以下の2つの指標を別途用意
- Edge Deviations, Corner Deviations
- 辺・頂点に関する距離
- 評価結果
- COCO: bounding boxをスケーリングした状態での結果。 +Snapperはモデルによって補正された時の結果。
- DETR: DETRの予測結果。+Snapperはモデルによって補正した後の結果
- IoUは向上しつつ、Edge, Cornerに関する誤差も減らせている
実験
- 実験デザイン
- 被験者: 18人
- 比較対象として複数のアノテーション手段を用意
- Baseline (BL): 一般的なbounding boxアノテーション
- Extreme Clicking (EC): 物体の上下左右4点をアノテーション(点をもとにbboxを推定)
- Snapper (SN): 提案手法。
- Snapper - GroundTruth (SN-GT): 予測されるbboxをGTから流用する
- Snapper - DynamicModel (SN-DM): 提案モデルを使ってbboxを予測
- アノテーションタスクの割り当て
- 全員がBL, EC, SNを全て経験するように割り当て(順番のバイアスを除くため、割り当て順は人によって変える)
- SN-GT, SN-DMは、いずれか一方しか経験しないようにする(どちらかの挙動に慣れてしまい、他方のアノテーションのバイアスとなるのを防ぐため)
- データセット: PASCAL VOC2012の11530枚の画像から90枚を選んで利用する
- 90枚を30枚ずつ3つのブロックに分割。
- それぞれのブロックごとに、どの物体も隠れていない15枚と、少なくとも1つの物体が隠れている15枚とが配分されるように調整
- 実験結果
- 全体的な評価: System Usability Scale (SUS) スコアは平均74.8で他の手法 (BL=70.7, EC=70.4) より高い
- Baselineは「描いたまま記録される」点が評価され、Snapperは予測が時々間違っている点が指摘されたが、スピード観点ではSnapperがポジティブに評価された
- Extreme Clickingは作業の単純さは評価されたが、やや練習が必要という指摘があった
- アンケートベースでは、好ましさのランキング・スピードと精度のいずれも、Snapperが最も良く評価された
- アノテーション精度(IoU)は、SN-GTが一貫して良く、その他は横並びかSN-DMがやや低くなる
- アノテーションにかけた時間
- タスク全体の時間: BL=81.7s, EC=117.4s, SN-GT=63.4s, SN-DM=47.1sで提案手法がもっとも効率的
- 最初のbboxを作る平均時間: BL=3.7s, EC=6.9s, SN-GT=2.9s, SN-DM=2.2sで提案手法がもっとも効率的
- bboxを編集する平均時間: BL=2.2s, EC=2.4s, SN-GT=2.1s, SN-DM=1.5sで提案手法がやや効率的ではあるが、大きな差ではない
まとめ
- Snappingと物体検出アノテーションの組み合わせが有効だと示された
- 今後の課題・リミテーション
- 他のデータセット・実験参加者による検証はまだまだ必要
- 精度観点でSN-GTとSN-DMとに差があるため、モデルの改善が必要
- 精度や効率に個人差があるため、ツールとしてのカスタマイズ機能を増やす