LayerX 採用情報/📖Media Bookmark List/LayerX Machine Learning勉強会/勉強会/2024-12-03 機械学習勉強会

2024-12-03 機械学習勉強会

2024/11/27 19:282024/12/3 17:52

今週のTOPIC [論文] Plots Unlock Time-Series Understanding in Multimodal Models [blog]オートコンプリートでの日本語入力の問題を解決する Ramp's Google Calendar Integration uithub.com [論文] Cautious Optimizers: Improving Training with One Line of Code [論文] A Survey on LLM-as-a-Judge メインTOPIC [論文] The AI Scientist: Towards Fully Automated Open-Ended Scientific Discovery 概要 Introduction 背景本研究の貢献 The AI Scientist 1. アイディア生成 2. 実験実行 3. 論文執筆 4. 査読実験設定結果展望

今週のTOPIC

※ [論文] [blog] など何に関するTOPICなのかパッと見で分かるようにしましょう。

出典を埋め込みURLにしましょう。

@Naoto Shimakoshi

[論文] Plots Unlock Time-Series Understanding in Multimodal Models

Googleが出したマルチモーダル基盤モデルの時系列データに対する応用についての論文

結論的には、時系列データをテキストとして渡すことより、画像としてplotして見せることによって精度も向上し、Tokenコストも最大90%削減できたという話。

タスクとして以下のものを解いた

人工データ

関数認識

相関推論

クラスター数のcounting

関数だけでなく導関数の同定まで行う

Fall detection and activity recognition：IMUデータから転倒などの行動認識
Readiness assessment: 28日のトレーニングデータから高負荷か低負荷かを判断
Forecastは今回は対象外で、Time series understandingに重きを置いている

結果として、全体的な傾向を認識することが必要なタスクで優位に優れていた

先行研究として、タスクに特化したモデルが作られていたりするが、今回の研究はそれらを凌駕すると主張するのではなく、テキストのみを使用する場合と比較して、基礎モデルからはるかに優れた性能を達成できることを示す。

LangFunを使って構造化プロンプトを作成。実際に作ったものは全て論文上の公開されている。

以下のように書ける。

結果

人工データでは優位にplotを使った方が精度が高い

Fall Detecion

textだとfew-shotを与えても良くなるわけではない。ほぼRandom精度。

Activity Recognition

同様に優位に優れている

その他、Ablation Studyでplotは系列毎に分割した方が良かったなどが報告されている。(今回の場合は加速度計と角加速度計を分離)

@Yuya Matsumura

[blog]オートコンプリートでの日本語入力の問題を解決する

毎年恒例「情報検索・検索技術 Advent Calendar 2024」の1日目の記事

パワーを感じたが実際の問題に取り組まれていて面白かったので紹介

Query Auto Completion(QAC、クエリオートコンプリート)に関する日本語ならではの課題に取り組んだ内容の記事

入力クエリをQAC用のElasticsearchにかけて候補を獲得する

ESには文書から名詞を抽出してサジェストキーワードとして登録している

課題

ローマ字入力の表記揺れ

「ヘボン式」「訓令式」「MS-IME形式」

「ナレッジ」を表すローマ字入力だけでも以下のようなパターン

narezzi
narejji
nareltuzi
nareltuji
narextuji

日本語 + 入力中のローマ字

最終的に「東京」と入力したい際には「とうｋｙ」「とうきｘ」などが途中で入力される。これらではQACできない。

解決策

ローマ字カタカナ変換処理の実装

Google日本語入力とMS-IMEのローマ字入力の変換のルールをサーバー側に実装し、入力されたローマ字をカタカナに変換して検索を行う

「narejji」や「narezzi」とユーザーが入力した際に「ナレッジ」で検索

日本語+入力中のローマ字に対して、可能性のあるクエリを生成

入力クエリ中の文字列のひらがらからカタカナに変換

「とうｋｙ」→「トウky」

文字の末尾のローマ字をもとに可能性のあるカタカナをすべて生成

「トウky」の「ky」が「キャ(kya)」「キィ(kyi)」「キュ(kyu)」「キェ(kye)」「キョ(kyo)」の可能性がある

「トウキャ」「トウキィ」「トウキュ」「トウキェ」「トウキョ」すべてで検索

@Tomoaki Kitaoka

Ramp's Google Calendar Integration

‣

以下の項目をサジェストしている

参加者
メモ

セキュリティ

shared calendar eventsのみを利用し、private calendar eventsは利用しない
一時的に予定を保存することはあっても、長期的には保存しない

デモ動画ではカレンダーの以下の情報を利用しているように見える

予定名
場所
日付
参加者

@Yuta Kamikawa

uithub.com

github.comのをに変えるだけでGithubリポジトリを丸々テキスト化してくれるらしい

Web検索できる系のツールと合わせて使いたい

LLMのロングコンテキスト化が進めば、RAG的なことをせずともコードベースを対象に色々質問できそう

@Shun Ito

[論文] Cautious Optimizers: Improving Training with One Line of Code

arxiv2024

AdamWの改良版 Cautious-AdamW

（既存）AdamとAdamW

**Decoupled Weight Decay Regularization (ICLR2019) より**

AdamWでは、weight decayを正規化計算の外に出して、相互の影響を回避している

（提案）C-AdamW

weight decayの更新を勾配とモーメンタムの符号（正負）が一致する時に限る
損失関数が単調減少する（一時的な増加を防ぐ）ことで学習が安定する

2次元パラメータのoptimizationでの軌跡

実験

AdamW, Lion（AdamWの別の改良版）に適用した結果。training lossがより効果的に減少

@qluto (Ryosuke Fukazawa)

[論文] A Survey on LLM-as-a-Judge

「LLM-as-a-Judge」(評価者としてのLLM)に関する包括的なサーベイ論文。

Section 2 主な方法論

In-Context Learning による評価タスク定義方法

スコア生成
Yes/No質問
ペアワイズ比較
複数選択肢選択

評価に際してはGPT-4のような汎用LLMを利用に限らず、PandaLMやJudgeLMなど、評価タスク用にfine-tuningされたLLMを利用する選択肢も広がっている
LLMの出力を最終的な評価結果に変換する後処理手法

特定のトークンの抽出
出力の確率分布の正規化
関連する文章の選択

これら手法を最終的にはパイプラインとして構築することになる。主に3つの用途。

LLM自体の性能評価
データのアノテーション
エージェントの評価

「Quick Practice」として、実践的な実装ガイドラインも掲載されている。

Section 3 改善戦略

プロンプト設計の最適化: タスク定義の最適化、アウトプット形式の最適化
モデルの評価能力の向上: 評価用LLMのfine-tuningやfew-shotプロンプトのチューニングを、時には外部LLMを利用しフィードバックデータを生成した上で継続的に改善する手法などが紹介されている
最終評価結果の信頼性を高めるための戦略：

(a) 複数の評価結果の統合

同じ内容に対する複数回の評価結果の統合
複数のLLM評価者による結果の組み合わせ

(b) LLM出力の直接的な最適化

出力スコアのスムージング
自己検証による信頼性の低い結果のフィルタリング

Section 6 実応用 - 機械学習

幅広い分野での実用が進んでいるとしつつ、感情分析、機械翻訳、テキスト要約というNLPタスクの評価の様子について紹介
感情分析: LLMベースの判断に影響を与える多数のバイアスが特定されている。
機械翻訳: LLM評価者の有効性はその英語トレーニングに大きく影響することが示されており、非英語の文脈における文化的、事実的な正確性の評価の限界が指摘されている
テキスト要約: セマンティック品質をより適切に捉え、hullucinationを最小化するための評価が開発されている