2024-06-27 機械学習勉強会
今週のTOPIC[blog] MLの裏側を支えるアノテーション組織運営の実践禄[blog]RAG評価ツールの "RAGAS" を使って、RAGパイプラインの性能を測定する[blog] Powering Streaming Features with Apache Flink at Brex: An Insight into Our Journey[論文] BROS: A Pre-trained Language Model Focusing on Text and Layout for Better Key Information Extraction from Documents[blog] How to Design Better Metrics 9 best practices from leading companies like Uber & Meta[blog] Your prompts are using 4x more tokens than you need[論文] SelfDocSeg: A Self-Supervised vision-based Approach towards Document Segmentation(ICDAR2024)概要IntroductionDocument Layout Analysisの歴史Document Layout Analysisの課題本論文の貢献SelfDocSegレイアウトの疑似ラベル生成BYOLによる事前学習BYOLをベースにした項目オブジェクトの表現と位置の学習実験評価まとめ
今週のTOPIC
@Naoto Shimakoshi
[blog] MLの裏側を支えるアノテーション組織運営の実践禄
- CADDiのアノテーション組織についてのブログ
- 機械学習エンジニア、プロダクトマネージャー、オペレーションマネージャー、アノテーターが協働でアノテーションサイクルを回している模様
- アノテーションルール
- データ分析観点:機械学習エンジニア
- ドメイン観点:プロダクトマネージャー
- PdMがアノテーションの優先順位やモデルの目標精度を設計したりする他、イレギュラーパターンへの対応やルールの微修正を行ったりする。
- 業務サイクル
- アノテーションルール・定義の見直しを、作業を進めながら頻繁に行っている
- 分かりみが深い
我々がとりあつかう図面というのは、兎にも角にも自由な書き方がなされています。どれだけ製造業に詳しい人であっても、すべての表記パターンを前もって洗い出すことができないほどです。
- 以下のようなことに真面目に取り組んでいて参考になりました。
- アノテーターの質問にスピーディーに解消しなければ作業が停滞する
- ルール改善と周知を徹底的にやらないとデータ品質が落ちる
- アノテーターとの信頼関係ができていないとサイクルが回らなくなる
@Yuya Matsumura
[blog]RAG評価ツールの "RAGAS" を使って、RAGパイプラインの性能を測定する
- RAGにおける出力の評価を行うフレームワーク RAGAS の紹介
- ‣
- 質問-回答のGTを作成して、RAGの回答と回答を作るために参照したコンテキストを食わせてあげるといくつかの観点で評価してくれる。
- Generation と Retrieval それぞれのファネルで評価できる。
- E2Eでの評価もできる。
@Tomoaki Kitaoka
[blog] Powering Streaming Features with Apache Flink at Brex: An Insight into Our Journey
- brex社がApache Flinkを用いてストリーミング機能プラットフォームを刷新した話
- before: 自社開発のストリーミング機能プラットフォーム
- ボトルネック/欠点
- 非効率的な状態管理: 大量のfeatureデータにより読み書きが遅くなり、Postgresでの処理が遅延。
- featureの取得遅延: featureの読み取りと集計に時間がかかるため、遅延が発生。
- スケーラビリティと隔離: 1つのコンシューマグループで全てのストリーミング機能を処理するのは限界。1つの重たい処理が他の処理のパフォーマンスに影響を与えていた。
- 複雑な機能の連鎖: 機能Aが機能Bの値を集計するなど、依存関係が複雑になるとコードベースが煩雑化。
- Kafka pythonライブラリの扱いにくさ: いくつかのバグによりパイプラインを停止することも。
- after: Apache Flinkを使ったプラットフォーム
- 移行後のメリット
- パフォーマンスの向上
- 効率的な状態管理: Flinkは大規模な状態を効率的に管理できるため、状態の読み書きが高速化され、全体のパフォーマンスが向上しました。特に、EmbeddedRocksDBStateBackendを使用することで、ディスクベースの状態管理が可能になり、大量のデータを効率的に処理できるようになりました。
- 遅延の低減: 状態の読み書きにかかる時間が短縮され、機能取得の遅延が減少しました。これにより、リアルタイムでのデータ処理と集計がより迅速になりました。
- スケーラビリティの向上
- 高いスケーラビリティ: Flinkの分散処理能力により、より多くのストリーミング機能を同時に処理できるようになりました。これにより、システム全体のスケーラビリティが向上し、増加するデータ量にも対応可能になりました。
- 信頼性の向上
- 堅牢なデータ処理: Flinkはデータの冗長性チェックや状態の管理を効率的に行えるため、データの一貫性と信頼性が向上しました。また、Flinkのチェックポイント機能により、障害が発生した場合でもデータの損失を最小限に抑えられます。
- 冗長メッセージの処理: Redisの外部コンポーネントを使用せずに、Flinkの内部状態を利用して冗長性チェックを行うことで、より一貫性のあるデータ処理が可能になりました。
- 開発効率の向上
- 設定駆動の機能定義: Flinkでも設定駆動のアプローチを維持することで、データサイエンティストが新しいストリーミング機能を簡単に定義できるようになりました。これにより、機能の開発とデプロイが迅速化されました。
- 再利用性の向上: 一度定義した機能設定を繰り返し利用できるため、新しい機能の追加が容易になりました。
- メンテナンスの簡素化
- 簡単な管理: FlinkのKubernetesオペレーターを使用することで、Flinkジョブのデプロイと管理が簡素化されました。これにより、システムのメンテナンスと運用が効率化されました。
- 将来的な拡張性: FlinkのAPIや機能は進化し続けているため、今後のアップデートや新機能を容易に取り入れることができます。
- lessons learned
- 制約と限界を事前に考える:
- システム設計時に制約を明確にすることで、合理的な選択ができ、メンテナンスの問題を回避しやすくなります。
- シンプルに始める:
- 複雑なユースケースは特別に処理し、一般的でない複雑な機能のためにシステム全体を複雑にしないようにします。段階的な変更で対応する方が後々簡単です。
- 車輪の再発明を避ける:
- 移行は困難で時間がかかるため、既存の解決策を活用することで無駄な移行を避けます。
- 業界の仲間と知識を共有する:
- 他社の経験から学び、特に広く使われているオープンソースソリューションを採用する際には、他社と協力や学習をすることが有益です。
@Shun Ito
[論文] BROS: A Pre-trained Language Model Focusing on Text and Layout for Better Key Information Extraction from Documents
- AAAI2022
- BERT Relying On Spatiality (BROS)
- OCRされた文字列からの情報抽出
- トークン間の位置関係を捉えるためのencoding手法、空間情報を取り入れた事前学習タスクの2種類を提案
- BROS encoding
- トークン間の相対的な位置関係による重み付け
- p_i, j: 2点間のx軸・y軸方向の差
- tl (top-left), tr (top-right), br (bottom-right), bl (bottom-left) について計算し重み付け和を取る
- トークン i → j に関する attention logit で、付与される
- 第1項は、通常のattentionと同じ(意味的類似性)
- 第2項で、Qに関するベクトルにトークン間の位置関係に関する情報を付与している(空間的関係性)
- 事前学習タスク
- 2つのタスクを解く
- ランダムに選ばれたトークンをマスキングして予測する
- (提案)ランダムに選ばれた領域に完全に含まれるトークンを全てマスキングして予測する
- 実験結果
- text + Layout を使った手法と比較して性能改善
- OCRで読み取られたトークン列をシャッフルしてどうなるかを比較(左が並び替え前・右が並び替え後)
- トークンの並び替えに対してもロバストな性能になっている
@Ryosuke Fukazawa / qluto
[blog] How to Design Better Metrics 9 best practices from leading companies like Uber & Meta
この記事では、UberやMetaのようなトップ企業の実例をもとに、優れたメトリクスを設計するための9つのベストプラクティスについて説明しています。メトリクスは進捗を測定し、チームのインセンティブを高め、アカウンタビリティを確立するための重要なツールですが、適切なメトリクスを選ぶことは簡単ではありません。著者は、良いメトリクスを見分けるための一般的な原則を紹介しています。
9のベストプラクティス
- 代理指標として適切であること:
- 測定したい内容に対して、直接測定できない場合は、適切な代理指標を選ぶことが重要です。
- 計算と理解が容易であること:
- メトリクスは簡単に計算でき、理解しやすいものでなければなりません。複雑なメトリクスは誤解やエラーの原因となります。
- 迅速に反応すること:
- 業務の管理に使用するメトリクスは、迅速に変化に反応する必要があります。遅延のあるメトリクスは改善サイクルを遅らせる可能性があります。
- 操作が難しいこと:
- メトリクスは意図しない操作を防ぐために、簡単に操作できないように設計する必要があります。
- 恣意的な閾値を避けること:
- メトリクスの閾値はデータに基づいて設定されるべきであり、恣意的なものは避けるべきです。
- 文脈を持たせること:
- メトリクスには文脈が必要です。絶対数だけでなく、割合などの形で文脈を持たせることが重要です。
- 明確な責任者を設けること:
- メトリクスの改善には、明確な責任者が必要です。複数のチームが関与する場合でも、単一のオーナーが必要です。
- ノイズを最小限に抑えること:
- メトリクスはノイズが少なく、変動を正確に解釈できるものでなければなりません。
- 業界標準に従うこと:
- 一部のメトリクスは業界標準に従うべきです。これにより、他社との比較が可能となります。
@Yosuke Yoshida
[blog] Your prompts are using 4x more tokens than you need
- LLMから情報抽出するときは、プロンプトに JSON Schema よりも type-definitions を使用することを提案
- type-definitionsはJSON Schemaと比較して、60%少ないトークン数で実行でき、コスト、レイテンシ、精度の向上につながる
- 例えば以下のような構造で抽出したいときに、
- JSON Schema場合
- type-definitionsの場合
- Why type-definition prompting works better (or at least our thoughts)
- type-definitionはJSON Schemaのロスレス圧縮
- LLM tokenizerはtype-definitionsに最適化されている
- string → string[], int → int[] にしてもトークン数は変わらない
- 関連するトークンが近い
- JSON Schemaだとrequired との距離が遠い
[論文] SelfDocSeg: A Self-Supervised vision-based Approach towards Document Segmentation(ICDAR2024)
Subhajit Maity, Sanket Biswas, Siladittya Manna, Ayan Banerjee, Josep Lladós, Saumik Bhattacharya, Umapada Pal
概要
- Document Layout Analysis(DLA)のための、画像ベースの自己教示学習手法のSelfDocSegを提案
- ドキュメント画像から抽出したvisual featureだけを使って自己教示学習を行うフレームワークで、テキストやbboxなどのレイアウト情報は使用しない
- 疑似的にレイアウトのマスク画像生成し、それを疑似ラベルとして利用することでドキュメント内の項目の位置の特定と、その項目の意味的な特徴のための表現学習を行う
- 提案手法で事前学習済みの画像エンコーダを使って、DLAための物体検出モデルやインスタンスセグメンテーションモデルをファインチューニングすると性能が良くなる
- 事前学習にテキストやレイアウト情報を使うSOTAの自己教示学習手法であるLayoutLMv3、UDoc と同等の性能を達成
- アノテーション付きデータが少ない小規模データセットにおいて、DocSegTrなどのTransformerベースの手法よりも優れた性能
- 他の手法が使用する100万〜4200万のデータを事前学習に使ったりするが、提案手法は事前学習データを81000に制限しても他の手法に匹敵する性能
Introduction
Document Layout Analysisの歴史
- Document Layout Analysis(DLA)自体は、deep learningの隆盛前から長年研究対象になっているテーマであり、 古き良き画像処理から最新の学習ベースの手法までたくさんのアプローチがある
- ドキュメントから項目を抽出する用途においては、古典的な画像処理よりも学習ベースの方が近年明らかにいい性能を示しているので、学習ベースの物体検出やインスタンスセグメンテーションなどのDocument Object Detection(DOD)タスクとされることがほとんど
Document Layout Analysisの課題
- 新しいドキュメントが日々生まれるビジネスアプリケーションにおけるDODの課題
- 複雑で見たことのないレイアウトのドキュメント(直訳すると型破り文書)への対応
- アノテーションタスクの煩雑さが増大
- これらの課題に対して、自己教示学習がとても重要
- アノテーション付きデータの不足への対応
- 大量の未アノテーションデータを有効活用できる
- DODタスクに自己教示学習を適用する上での課題
- 自己教示学習でよく使われているcontrastive learningを直接適用できない
- 1つのドキュメントにクラスラベルが複数存在するので、クラスを使ったりしてドキュメント同士のpositive pairやnegative pairを作ることができない
- 項目がどこにあるか(object localization)まで学習できない
- テキストやbboxなどのレイアウト情報が必要
- 既存手法は画像、テキスト、レイアウトのペアを数百万、数千万使っているが、データを集めるのも学習回すのにもコストがかなりかかる
- ここまでの課題を解決するためにSelfDocSegを提案
- Bootstrap Your Own Latent(BYOL)をベースにした自己教示学習手法
- 古典的な画像処理を使って、ドキュメントからレイアウトの疑似的なマスク画像を疑似ラベルとして生成して利用
- 項目オブジェクトの特徴表現(representation)と項目がどこにあるか(localization)を同時に学習する手法
本論文の貢献
- 単純に性能が上がる
- アノテーションせずとも画像さえあれば、SelfDocSegを使ってDOD向けの事前学習ができる
- 事前学習のデータ数が少なくても性能がいいので、コストカットにもつながる
SelfDocSeg
DODの通常のデータセット
アノテーション付きデータセット
ファインチューニングなどで使う
- : RGB ドキュメント画像
- : 画像内の個の項目オブジェクトに関するアノテーション
- : 画像内の項目オブジェクト
- : 項目オブジェクトのピクセル座標セット
- : 項目オブジェクトのクラスラベル
DODの自己教示学習のデータセット
アノテーションがないので、疑似ラベルをアノテーションとしたデータセット
自己教示学習で使う
- : RGB ドキュメント画像
- : から生成された粗いバイナリマスク
- は画像の物理的レイアウトを表現
SelfDocSegでやりたいこと
- データセットで画像エンコーダを自己教示学習方式で事前学習
- : 画像エンコーダ
- : 画像エンコーダのパラメータ
- : 抽出されたfeatureマップ
- をバックボーンとして、データセット用いてオブジェクト検出モデル(例: Mask R-CNN, Yoloシリーズ)をファインチューニング
レイアウトの疑似ラベル生成
- 古典的な画像処理によって、ドキュメント画像からレイアウトの疑似的なバイナリのおおまかなマスク画像を生成する
- 手順
- RGB画像をグレースケール変換
- 閾値処理による二値化
- Erosion(侵食)
- 文字や線を太くして、一つの塊(オブジェクト)にする
- 白黒反転
- 白黒反転して、[0, 1]にnormalize
- オブジェクトが存在する部分が1(白)、それ以外が0(黒)
BYOLによる事前学習
- DeepMindから出てるBootstrap Your Own Latent(BYOL)という画像の自己教示学習手法
- BYOLはcontrastive learningを拡張した手法
- contrastive learningは、特徴空間で同じ画像(positive pair)間は距離を近くし、違う画像(negative pair)間は距離を遠くするという考え方の自己教示学習手法
- 1つの画像からaugumentationで2つのビューを生成し、同じ画像起因のビュー同士は特徴表現の距離が近くなるようにして、違う画像起因のビュー同士は遠くなるように学習する
- augmentationで物理的な見た目が変わっても意味的な特徴空間では近いところに埋め込みを作りたいイメージ
- ただcontrastive learningは、negative pairの作り方によっては学習が安定しないので、大きなバッチサイズや、memory bankを利用する必要があるので、positive pairだけで自己教示学習がしたい
- positive pairだけを使って、特徴空間で同じ画像間は距離を近くするようなタスクを学習すると、常に同じ出力にすればロス自体は下がるので、どの画像を入力しても同じ特徴表現になるというcollapseが起こってしまう、これを解決するためにBYOLを提案
- BYOLでは同じ画像起因の異なるビュー(positive pair)だけで学習するために、2つのネットワークを使う
- online network
- 真に学習したいモデル、SelfDocSegでいうと画像エンコーダ
- online networkとtarget networkにpositive pairを入力し、online networkはtarget networkの出力とのコサイン類似度が高くなるような出力をするように学習を進めていく
- target network
- online networkと全く同じ構造で、パラメータを持ち、更新方法が違う
- パラメータをランダムに初期化し、学習が進むに連れて指数移動平均で少しずつonline networkのパラメータにパラメータを近づける
- online networkとtarget networkのパラメータが近くなるまで十分に学習が進むと、collapseが起こることなく、ブートストラップ的に良い特徴抽出ができる画像エンコーダが得られているという仕組み
BYOLをベースにした項目オブジェクトの表現と位置の学習
SelfDocSegにおける用語と定義
- Online Branch: 真に学習したいネットワーク
- 画像エンコーダ : ResNet50
- プロジェクタ : 2層MLP (隠れ層4096次元, 出力256次元)
- プレディクタ : 2層MLP (隠れ層4096次元, 出力256次元)
- Momentum Branch: BYOLでいうtarget network
- 画像エンコーダ
- プロジェクタ
- , : 入力画像から生成されたの2つの異なるビュー
- , , , : 画像エンコーダ, によって、, から抽出された特徴マップ
- Online Branchの出力が、Momentum Branchの出力が
- マスクプーリング
- featureマップとからオブジェクトに関係する領域の特徴ベクトルだけ取得する処理
- , , : マスクプーリングの出力
- , , , : とを入力としたプロジェクタの出力
- , : を入力としたプレディクタの出力(Online Branchのみ)
オブジェクトの表現(representation)学習手順
- Online Branchでの処理
- 画像からaugmentationで2つのビュー, を生成
- Gaussian blurring, color jittering, color dropping, solarization
- 後述のマスクプーリングという処理と相性が悪いので、クロッピングのような処理はしない
- 画像エンコーダ でビュー, から、それぞれfeatureマップ, を抽出
- マスクプーリングでfeautureマップからレイアウト特徴を取得
- レイアウトマスクから画像内のオブジェクトごとのマスクを作成
- featureマップとマスクを使って、オブジェクトの特徴を抽出:
- featureマップから、あるオブジェクトの部分だけ注目して、average poolingでというオブジェクト固有の特徴ベクトルにまとめる感じ
- 画像内の全てのオブジェクトの特徴ベクトルをスタックしてひとつのレイアウト特徴 として取得
- ここまでで、
- プロジェクタ、プレディクタでを取得
- Momentum Branchでの処理
- 2つのビュー, を入力とし、Online Branchと同じ処理でを取得
- 損失関数
- 2つのブランチに異なるビューを入力したときに、Momentum Branchの出力をOnline Branchの出力が近づくように学習
オブジェクトの位置(localization)学習手順
- バイナリのセグメンテーションタスク
- 入力: featureマップ
- 出力: レイアウトマスク
- 損失関数
- focal lossを採用していて、重みづけαが0.25、フォーカシングγが2
パラメータ更新手順
- Online Branch
- 勾配学習
- Momentum Branch
- パラメータθの指数移動平均。τがモメンタム係数で、学習が進むに連れてパラメータξがθに近づく
ファインチューニング
- 事前学習済みをMask RCNNのバックボーンとして使用
- アノテーション付きデータセットで訓練
- Detectron2で学習
実験
- 事前学習
- DocLayNetの画像81000枚で学習
- A40(48GB)で800エポック
- ファインチューニング
- DocLayNet, PubLayNet, PRImA, Historic Japaneseそれぞれで学習
- A40(48GB)でバッチサイズ128で300000イテレーション
評価
- Document Object Detectionの性能で評価
- テキストやレイアウト情報を明示的に使っていないが、他の自己教示学習手法(LayoutLLMv3, UDoc)に匹敵する性能を示した
- 提案手法では81000の画像だけ使っており、他の手法(LayoutLMv3: 11M, UDoc: 1M, DiT: 42M)と比べて少ないデータ量でも性能がいい
- PRImAデータセットはアノテーション付きの学習データが350枚しかないが、小規模データセットではTransformerベースの手法(DocSegTr)を上回った
まとめ
- アノテーションせずとも画像さえあれば、Document Object Detection向けの事前学習ができる
- 事前学習のデータ数が少なくても性能がいいので、コストカットにもつながる
- 提案手法は画像だけでどこまでできるか検証しているが、提案手法をマルチモーダルな事前学習に組み込むことで更なる性能向上を期待