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

2024-11-26 機械学習勉強会

2024/11/21 23:152024/11/26 8:03

今週のTOPIC [slide] The Rise of LLMOps [論文]SAMURAI: Adapting Segment Anything Model for Zero-Shot Visual Tracking with Motion-Aware Memory [document]How Snowflake Document AI Works PDFの図表をPolarsのDataFrameに変換するサンプルコード [blog] 工数6割削減! 生成AIとOCRを組み合わせ、店舗毎に形式が異なるレストランメニューを読み取らせてみた [論文] AutoSurvey: Large Language Models Can Automatically Write Surveys [slide] FastAPIでのasync defとdefの使い分けメインTOPIC Contextual Document Embeddings 概要定式化提案手法: Contextual batching + Contextual embedding 実験実験設定実験結果

今週のTOPIC

@Naoto Shimakoshi

[slide] The Rise of LLMOps

第11回 Data-Centric AI勉強会の資料

LLM出現時にLLMOpsというワードが誕生したが、その時点では単純に既存のMLOpsをLLMOpsに流用するものだった

これを前提とするとLLMは継続的に訓練は行われないし、継続訓練せずに活用している企業もいっぱいあるという、現状の運用にそぐわない形になっている

Googleから必ずしも再訓練を必要としないLLMOps (GenOps)はどちらかというとDevOpsとの類似点が多いというBlogが公開。

データサイエンス「データからモデルを作成」 ↔ 生成AI「モデルからAI対応サービスを作成」
https://cloud.google.com/blog/ja/products/devops-sre/genops-learnings-from-microservices-and-traditional-devops

実際にエンジニアにどのような運用をしているかをヒアリングし、LLMOpsを再考。

課題

システムが正しく動いているか誰にもわからない
品質評価の観点を事前に列挙することが困難。出力から事後的に得られる。

LLMにおける継続的改善とは

Eval-Centricな方法論が必要

技術

RAG
プロンプトエンジニアリング
LLM-as-a-Judge
オズの魔法使いパターン
ユーザーテスト
トレース

最終結果を生成するまでの途中で何が起きているかを記録し、分析できるようにする。LangSmithやLangfuseは対応している。

ガードレール

BedRockではこの機能だけ使えたりするらしい

プロンプトのバージョン管理

プロンプトは長くなりがち、デグレしがち
バージョン管理とともに継続的に評価を行う

Red Teamingなども有効

@Yuya Matsumura

[論文]SAMURAI: Adapting Segment Anything Model for Zero-Shot Visual Tracking with Motion-Aware Memory

Cheng-Yen Yang, Hsiang-Wei Huang, Wenhao Chai, Zhongyu Jiang, Jenq-Neng Hwang

Segment Anything Model 2 (SAM 2)をベースとした改良モデルである SAM-based Unified and Robust zero-shot visual tracker with motionAware Instance-level memory(SAMURAI) が提案されている。

SAM2の課題として以下を挙げている

空間的・時間的な一貫性よりも物体の外見の類似性に過度に依存している

→ 見た目が似ている物体が多数存在する、特に密集している際に正しく物体の識別ができない（Case 1）

動いている物体の動きの情報を予測時に十分に考慮できていない

→ 物体が動いている、特に高速に動いているケースで正しく物体の追跡ができない（Case 2）

メモリ管理（過去frameを学習や推論に利用する）が固定ウィンドウ式で過去N件を利用するだけである

→ 物体が一時的に隠れるようなケースで正しく物体の追跡ができない（Case 2）

→ 低品質なフレームも無駄に残しているため効率が悪い

大きく２つの変更をSAM2のアーキテクチャに適用することで問題を緩和

既存の学習済みのSAM2のモデルの一部アーキテクチャを変更するだけで再学習は不要

Motion Modeling

従来のSAM2の予測に追加してカルマンフィルタによる予測を行い、それぞれのスコアを組み合わせて利用
カルマンフィルタを利用することで物体の動きを考慮するイメージ

Motion-Aware Memory Selection

以下の3つのスコアを利用してメモリ管理するframeを選別する。シンプルにそれぞれ独立して閾値を決めている。

mask affinity score: 予測したマスクの確信度（SAM2のMask Decoderの出力のひとつ）
object score: 対象物体の存在確率（SAM2のMask Decoderの出力のひとつ）
motion score: カルマンフィルタによる予測との一致度

SAM2と比較して定量的に高いスコア

LaSOT, LaSOTextは動画データセット

SAM2が苦手と主張していたようなシチュエーションでうまくいっている雰囲気を感じる

@Tomoaki Kitaoka

[document]How Snowflake Document AI Works

セットアップはざっくり2 step

Preparing a Document AI model build
Extracting information from documents

Preparing a Document AI model build

ファイルをアップロード → アノテーション → trainでモデルを作成できる

Extracting information from documents

こんな感じで読み取り項目を指定してtrainしたモデルを実行

‣

もちろんアップロードされたらOCRが実行されるパイプラインを組むことも可能

@Yuta Kamikawa

PDFの図表をPolarsのDataFrameに変換するサンプルコード

PDFの図表情報をPolarsのDataFrameに変換するまでの簡単な検証。

Table Transformerにおける図表理解タスクの枠組みで、以下の4ステップで行った。

Table Detection

PDFから図表の座標を検出

Table Transformerを利用

図表の座標が検出できればいいので、Document Layout Analysis系のモデルも選択肢になりうる

Table Structure Recognition

図表部分の画像から行と列の座標を検出し、図表のセルを抽出

Table Transformerを利用

ここはTable Detectionより選択肢が少ない気がする

OCR

図表のセルからテキストを抽出

EasyOCRを利用

Google Vision API、PaddleOCR、Tesseractでもなんでもいい

1 ~ 3で抽出した図表情報をPolarsのDataFrameに変換

請求書PDFでの検証

Table Detection

Table Structure Recognition

まとめ

(当然だが)Table Detectionの検出結果が、後続の処理に大きく影響するのでTable Detectionではかなり正確にTableを検出できている必要がありそう

Table Detectionモデル自体が、論文ベースのデータセットで学習されていることが多いので、図表は図表だがデータセットのドメインはやはり重要

セルの座標で絞り込んだ部分画像からテキストを抽出するのでOCRとしての難易度は低いのかも(基本的なOSSなら大体できそう)

@Shun Ito

[blog] 工数6割削減! 生成AIとOCRを組み合わせ、店舗毎に形式が異なるレストランメニューを読み取らせてみた

食べログのメニューを画像から抽出する作業を、生成AI+OCRで効率化する

文字認識は、GCPのDocumentAIを利用

LLMに文字認識されたidと一緒に回答させる

文字列だけ抽出させると斜めの時にうまくいかなかった

写真が斜めだとOCRやAIの精度が落ちることがあり、その補正を glfx.js というライブラリを使って実装

@qluto (Ryosuke Fukazawa)

[論文] AutoSurvey: Large Language Models Can Automatically Write Surveys

NeurIPS 2024

LLMを使用して学術サーベイを自動生成する手法。

コンテクストウィンドウの制限、パラメトリック知識の制約、評価基準の欠如を生成のための大きな課題としてあげつつ、それらを解決する手法について紹介している。

コンテクストウィンドウの制限: LLMの入出力に関するトークンサイズの制限は数百本の論文を解読し数万トークン規模にわたっての出力を行う必要があるサーベイ論文生成に当たっては大きな障壁となる

パラメトリック知識の制約: LLM内部の知識だけに頼ることは最新研究の内容を取り込み、包括的で正確なサーベイ論文生成の障壁となる

評価基準の欠如: LLMによる出力の品質評価に関して、信頼できる指標は存在していない。品質評価を人間のレビューに依存するのはリソースの課題、スケーラビリティの課題がある

AutoSurveryの全体アルゴリズム

評価方法

引用品質。は先行研究のLLMによるもの。主張がその参照文献によって支持されているかをLLMによって判定します。

引用リコール (Citation Recall)

生成されたテキスト中のすべての主張が引用された文献に完全に支持されているかを測定します。これは以下の式で計算されます：

引用精度 (Citation Precision)

不適切な引用を特定し、提供された引用が主張を適切かつ直接的に支持しているかを保証します。精度の式を示す前に、関数 g を次のように定義します：

この関数は、論文 r_{ik} が主張 c_i に関連しているかを測定します。精度は次の式で計算されます：

内容品質 (Content Quality):

カバレッジ(Coverage)：トピックの網羅性を5段階で評価
構造(Structure)：論理的な構成と一貫性を5段階で評価
関連性(Relevance)：研究トピックとの整合性を5段階で評価

結果

速度においてAutoSurveyが大幅に優位
引用品質で単純なRAGベースの性能を上回り、人間に迫る性能を発揮した
内容品質は人間の執筆とほぼ同等レベルで、単純なRAGベースのLLM生成を上回った

メタ評価。評価方法と人間による評価の整合性を検証するためのもの

手順

専門家には我々の評価で使用した採点基準を提供し、それを参照して評価を行ってもらった

専門家は20件の生成されたサーベイをランク付けし、それをLLMによる評価結果と比較した

比較にはスピアマンの順位相関係数 (Spearman’s rank correlation coefficient) を使用し、人間の評価とLLM評価の整合性を測定した

結果

スピアマンの相関係数は、LLMと人間の専門家のランキング間に中程度の正の相関があることを示した
複数のモデルを組み合わせた評価方法が最も高い相関係数である0.5429を達成した

考察

この結果は今回の評価方法が人間の好みとよく一致していることを示している

エラー分析

100の未サポート主張とその引用を分析し、以下の3種類のエラーを特定：

位置ずれ(Misalignment): 39%

例：GDPRについて言及する際に、実際にはGDPRを提案していない論文を引用

誤解釈(Misinterpretation): 10%

例：文脈学習に関する主張で、実際には文脈外学習に焦点を当てた論文を引用

過度の一般化(Overgeneralization): 51%

例：特定のケースについての研究結果を、より広い文脈に一般化してしまう

学び

LLMは引用文献の内容理解はほぼ適切にできる（誤解釈が10%と低い）
パラメトリック知識への依存が強い（過度の一般化が51%と高い）

@Yosuke Yoshida

[slide] FastAPIでのasync defとdefの使い分け

メインTOPIC

Contextual Document Embeddings

ICLR2025 submitted (in review) https://openreview.net/forum?id=Wqsk3FbD6D

概要

text retrievalのための埋め込み表現の学習を考える

古典的な方法はBM25など。最近はニューラルネットが使われる。

基本的なニューラルネットモデルだと、documentとqueryの埋め込み表現を、それぞれ独立で学習する

例えばIDFだと、データセットのcontext情報（データセットの中で頻度が低い単語に強い重みを与えるなど）を比較的簡単に与えられる。このようなcontextに関する情報をニューラルネットでの学習に持ち込みたい。

定式化

text retrievalについて

は document と query のmatching scoreを計算する関数で、documentの埋め込み , queryの埋め込みの組み合わせ（内積）で計算される。
データセットの中で、マッチ度が最も高いdocument, queryのペアを見つけ出す

documentの埋め込み , queryの埋め込みの学習

ある query に対する正解の document がデータとして与えられており、その対数尤度を最大化させる
注目しているdocumentについて、negative sampleを集めてくる

提案手法: Contextual batching + Contextual embedding

Motivation

例えば以下の文章を考える

The National Football League Draft is an annual event in which the National Football League (NFL) teams select eligible college football players...

“NFL” という単語は、Corpus全体から見ると珍しい単語だが、スポーツドメインに絞るとよく出てくる単語になる
全体だけを見て “NFL” に重きを置いて検索するようなモデルができると、スポーツドメインの中で検索したいときにうまくいかない
→ 似たようなcontextの中でも、見るべき情報を取り入れた埋め込み表現を獲得したい

提案: 似たcontextのdocumentをnegative sampleとして置いて、documentの埋め込み , queryの埋め込みを学習する

Contextual batching

似たcontextのdocument同士をまとめる手法
手順

documentをクラスタリング

本来求めたい埋め込み表現の前処理的な位置付けなので、既存の学習済みモデルを利用

batchにまとめる

クラスタリングの結果はサイズがまちまちなので、同じくらいのサイズにbatchにまとめる

クラスタリングの時点ではbatchサイズより小さいサイズで作り、最適化問題を解いて同じクラスタ同士を結合してほぼ同じ大きさのバッチにまとめる

false negativeを除いて学習

同じクエリq に対して、書類 d よりスコアが以上大きい書類は除外する

> As one datapoint, Qu et al. (2021) found that over 70% of top-retrieved passages in MS Marco are false negatives.
の計算に使うについても、既存の学習済みモデルを利用する。true negativeが多めに除外されてしまうのは許容する。