2024-10-07 機械学習勉強会

Title by AI
歴史的文書画像解析のための事前学習における制御データの利用
Tags
論文
AI summary
2024年10月7日の機械学習勉強会では、KPIの集計や異常通知のフロー、ダッシュボードの運用、BM25を用いたRAG精度向上、LLMとSmall Modelsの協力関係、PythonのLinter導入、歴史的文書画像の解析手法について議論された。特に、人工データを用いた事前学習が精度向上に寄与し、小型モデルの有効性が示された。
担当者
Shun ItoShun Ito
今週のTOPIC
Title
Historical Document Image Analysis using Controlled Data for Pre-Training

今週のTOPIC


@Naoto Shimakoshi

[blog] text-embeddings-inference で日本語トークナイザーモデルの推論をする

  • hugging faceが提供しているhttps://github.com/huggingface/text-embeddings-inference という推論サーバーがある (gRPC API)
    • 以下のような特徴がある
      • No model graph compilation step
      • Metal support for local execution on Macs
      • Small docker images and fast boot times. Get ready for true serverless!
      • Token based dynamic batching
      • Optimized transformers code for inference using Flash AttentionCandle and cuBLASLt
      • Safetensors weight loading
      • Production ready (distributed tracing with Open Telemetry, Prometheus metrics)
      GPUアーキテクチャが FlashAttention-2 対応以降なら、推論速度も python の transformers ライブラリで動かすよりも約1.5~2倍弱の速さ
    • 対応GPU
      • Ampere, Ada, or Hopper GPUs (e.g., A100, RTX 3090, RTX 4090, H100). Support for Turing GPUs (T4, RTX 2080) is coming soon, please use FlashAttention 1.x for Turing GPUs for now.
  • めっちゃ便利そうだが、RustベースのFastTokenizerを用いて動かすことが条件らしく、unidicやmecabなどのpythonを用いた形態素解析を使うので、使うのにクセがある。
  • 以下のような工夫でtokenizer.jsonを作成
    • dummy の tokenizer.json を用意する
      • 適当にその辺りから拾ったもので問題なし
    • dummy の tokenizer.json を使ったモデルでサーバを起動する
      • 自作で作成
    • 手元で token_ids に変換して API を叩く
      • 以下のように叩く
      • from transformers import AutoTokenizer
        import requests
        import numpy as np
        
        tokenizer = AutoTokenizer.from_pretrained("hotchpotch/ruri-base-dummy-fast-tokenizer-for-tei", use_fast=False)
        
        sentences = [
            "クエリ: 瑠璃色はどんな色?",
            "文章: 瑠璃色(るりいろ)は、紫みを帯びた濃い青。名は、半貴石の瑠璃(ラピスラズリ、英: lapis lazuli)による。JIS慣用色名では「こい紫みの青」(略号 dp-pB)と定義している[1][2]。",
            "クエリ: ワシやタカのように、鋭いくちばしと爪を持った大型の鳥類を総称して「何類」というでしょう?",
            "文章: ワシ、タカ、ハゲワシ、ハヤブサ、コンドル、フクロウが代表的である。これらの猛禽類はリンネ前後の時代(17~18世紀)には鷲類・鷹類・隼類及び梟類に分類された。ちなみにリンネは狩りをする鳥を単一の目(もく)にまとめ、vultur(コンドル、ハゲワシ)、falco(ワシ、タカ、ハヤブサなど)、strix(フクロウ)、lanius(モズ)の4属を含めている。",
        ]
        
        token_ids = tokenizer(sentences, padding=False, truncation=False, return_tensors="np")["input_ids"]
        token_ids = [t.tolist() for t in token_ids]
        
        url = "http://127.0.0.1:8080/embed"
        payload = {"inputs": token_ids, "normalize": False, "truncate": True}
        headers = {"Content-Type": "application/json"}
        
        response = requests.post(url, json=payload, headers=headers)
        embeddings_data = response.json()
        embeddings = np.array(embeddings_data)
        print(embeddings.shape)
        
        # calc cosine similarity
        normalized_embeddings = embeddings / np.linalg.norm(embeddings, axis=1, keepdims=True)
        similarities = np.dot(normalized_embeddings, normalized_embeddings.T)
        
        print(similarities)
        
        Python
  • 実際にdummyで準備したtokenizer.jsonは使わないので、問題ない。

[app] connectedpapers.com

  • ただの紹介
  • 引用数とかをグラフで可視化してくれるので、興味ある論文から次の論文何読もうとなった時に便利。
  • 例えばLayoutLMv3の論文からだと以下のように見える
  • 日付とかでフィルタもできる
 

@Yuya Matsumura

[blog] Enhancing your gen AI use case with Vertex AI embeddings and task types

  • "質疑応答"や"ファクトチェック"などのタスクを指定することで、より適当なqueryのembeddingが獲得できる Vertex AIの機能の紹介ブログ
  • 課題感はお馴染みの"question is not the answer" problem.
    • 質問queryのembeddingと、その回答として適当なdocumentのembeddingは意味的に近しいわけではない問題。
    • ex. "Why is the sky blue?" とその回答である "The scattering of sunlight causes the blue color" は文章の”意味”として近いわけではない。
  • この問題自体は情報検索分野でも非常に”classic”なもの。Google Searchでも2015年とかから取り組んできている。
    • (一部界隈ではさも新しい問題かのように騒いているけどね!)
    • コンテキスト・ドメインの異なる2種類の文書集合を同一のベクトル空間に埋め込む方法としては Dual encoder model(two-tower model)が有名。query と answerの関係性も学習した上でembeddingを生成しようとする。
  • with LLMな世界での”Advanced RAG” としての手法もいくつか存在
    •  HyDE: queryに対するanswerをLLMに生成させ、そのembeddingを用いてretrieval
    • query expansion with LLM : LLMを利用してquery自体を拡張してretrieval
    • → 毎回LLMで生成を行うのでレイテンシーやコストなどのダウンサイドが否めない。
  • Vertex AI Embeddings API の "text-embedding-004" "text-multilingual-embedding-002" などのモデルでは以下のような “task type”をサポートしており、指定したtask typeに応じた文書のembeddingを獲得できる。
    • 以下に加えて CODE_RETRIEVAL_QUERY というコード生成用のtaskも追加されたとのこと。
  • QUESTION_ANSWERINGを指定して”Why is the sky blue?" の、 RETRIEVAL_DOCUMENTを指定して”The scattering of sunlight causes the blue color"のembeddingを獲得すれば、それらのembeddingの距離が近くなる!
  • 裏側ではLLMを使って蒸留したtwo-tower型のencoderを利用。
    • LLMを使ってtaskごとにqueryを生成
    • task x 生成queryごとに関連文書を(通常の)検索し、このquery-and-documentペアがtaskに対して正しいものかをLLMで判定
    • 得られたtaskごとに正しいquery-and-documentペアを正解データとしてtwo-tower型のencoderモデルを作成
  • 利用方法はとても直感的
    • from vertexai.language_models import TextEmbeddingInput, TextEmbeddingModel
      
      model = TextEmbeddingModel.from_pretrained("text-embedding-004")
      input = TextEmbeddingInput("Why is the sky blue?", "QUESTION_ANSWERING")
      embeddings = model.get_embeddings([input])
      print(embeddings[0].values)
      SQL
  • うまくいっていそうな気配を感じる

@Tomoaki Kitaoka

3-Way Match with Ramp Procurement

  • 3-way matchingは、買掛金の管理において、発注書(PO)受領書(納品書)、そして請求書の3つの書類を照合することで、サプライヤーに対して正確な支払いを行うことを確保し、不正やエラーを防ぐこと。
  • how it works
    • 納品書を受領するとそれを発注書に紐づける。この時Receiving statusは以下の3つから構成される
      • not received
      • partially received
      • fully received
    • 3-way matching
      • 請求書が購入注文書(PO)と商品受領書に照合されると、請求書の各品目行に直接受領ステータスが表示される。
      • 請求書に記載されている品目数が全て受領されている場合、緑色のアラートが表示され支払いプロセスを進めることが可能。
      • 受領した商品の量の記入は手動の模様

@Yuta Kamikawa

[blog] KPIのモニタリング自動化と運用体制の整備

  • ZOZOTOWNの推薦システムのKPIのモニタリングや運用体制をアップデートした話
  • 課題1: KPIの異常検知の閾値が固定で、キャンペーンなどのトレンドを考慮できていなかった
    • Prophetを利用することで、季節変動やイベントの影響を考慮した動的な閾値を設定
  • 課題2: 実際に異常が発生した際のアラート対応フローが不明確で属人化していた
    • アラート対応フローを整備し、対応の属人化を解消
    • Vertex AI Pipelinesをスケジュール実行しKPIを集計。異常が発生していればSlackで通知しフローの通りに対応
  • 課題3: メール配信数やクリック率などのKPIをSlackで定期配信していたが、最終的にはほとんど誰も目を通さなくなっていた
    • 毎週1回20分のダッシュボードを見る会というミーティングの運用
        1. ファシリテーターを中心にダッシュボードを見て、先週から ±N% 以上の変化率か、グラフの形状が大きく変わったかを確認
        1. 大きな変化がある場合、祝日、イベント、障害が発生していないか等原因を調査
        1. 時間内に原因解明が出来なかった場合は、ファシリテーターが問題をチケット化し調査タスクをバックログへ積む
    • 定期的なミーティングによって異常の取りこぼしが削減された

@Shun Ito

[blog] Introducing Contextual Retrieval

  • Anthropicのブログポスト
  • RAGの精度を上げるためにBM25の利用とcontextを含めたembeddingが有効だという内容
  • BM25の利用ケース
    • vector databaseと併用してTF-IDF indexを作成
    • queryに対してvector databaseの検索と、BM25による検索を両方実行してTop-Kを抽出
    • 重複排除してgenerative modelに入力する
  • contextを含めたembedding
    • chunkをそのままembeddingせず、一度LLMに投げてcontextを付与させる
  • 精度(average % of failed retrievals @20)が改善
 

@qluto (Ryosuke Fukazawa)

[論文] What is the Role of Small Models in the LLM Era: A Survey

LLMs と Small Models のコラボレーションと競合についてサーベイした論文
Small Models の定義としてはっきりしたものはないと前置きしつつも、ここではBERTからLLaMA-8BくらいまでをSMsとして扱っている様子。
 
コラボレーションについては下図のように分類を行っている。
SMsによるLLMsの強化:
  • データキュレーション: SMを使ってLLMの学習データを選別・重み付け
  • 弱から強への学習: SMを使って大きなモデルを監督・調整
  • 効率的な推論: モデルのアンサンブルや投機的デコーディングによる推論の最適化
  • LLMの評価: SMを使ってLLMの出力を評価
  • ドメイン適応: 特定ドメイン向けにLLMを調整
  • 検索拡張生成: 外部知識の取り込み
  • プロンプトベースの推論: プロンプトの最適化
  • 欠陥修正: LLMの弱点を補完
LLMsによるSMsの強化:
  • 知識蒸留: LLMの知識をSMに転移
  • データ合成: LLMを使って学習データを生成・拡張
 
また競合については以下のような考え方ができるとしている。
LLMとSMの競合:
  • 計算資源制約下での環境
  • タスク特化型の環境
  • 解釈可能性が求められる環境
 
  • LLMsによるSMsの強化についてはやや身近な話題なため、著者が感じた今後の方向性についてのコメントを紹介
    • 知識蒸留
      • 今後の方向性 (1) 現在の知識蒸留アプローチは主に、クローズドソースLLMによって生成されたラベルと説明を使用して、単純な教師あり微調整を通じて学習モデルを訓練することに重点を置いています。しかし、学習モデルの出力に対するフィードバックや特徴知識を含む、教師モデルから転移される知識の範囲を拡大することで、追加の利点を提供できる可能性があります。 (2) LLM知識蒸留の取り組みは、主にLLMからの様々なスキルの転移に焦点を当てており、有用性、誠実さ、無害性などの信頼性に対する注目は比較的限られています。
    • 合成データ
      • 今後の方向性 (1) 現在、クローズドソースのLLMはオープンソースの対応物よりも強力です。しかし、データ合成にクローズドソースモデルを使用すると、特に患者データを含む医療シナリオなどの機密性の高い文脈でプライバシーとセキュリティの懸念が生じる可能性があります。このプロセス中にデータのプライバシーをどのように保護するかを解決することは重要な懸念事項です。 (2) 大規模モデルを使用して訓練データを生成するのはコストがかかるため、高品質のデータを生産しながらも経費を削減する方法を探ることが不可欠です。例えば、最近の研究では、より小規模で性能の低いモデルが時として優れた訓練データポイントを生成できることが示唆されています。
 

@Yosuke Yoshida

[blog] チームで培われたベストプラクティスをlintとして周知する

  • 2週間から1ヶ月程度で新規プロダクトをリリースするなど、高速にプロダクトを開発
  • その過程で、「この書き方は落とし穴があるから使わない方がいい」といった開発に際したベストプラクティスが溜まっていきます
  • PythonのLinterとしてruffを使っているが、ruffには独自ルールを記述したり、自作pluginを読み込ませたりする機能が無い
  • 開発・運用上のチーム内のベストプラクティスに従っているかを検知するLinterの独自ルールを社内向けに作成し、CIに組み込んでいる
  • star数が多く機能もミニマルなPylintを採用

 

メインTOPIC

Historical document image analysis using controlled data for pre-training (ICDAR2023)

概要

  • ラベル付きデータの限られた歴史的な文書画像のレイアウト解析のための事前学習を考える
  • 人工的に作成したデータの利用・自己教師あり学習使った事前学習タスクの2種類の戦略を提案
  • 特に軽量なモデルにおいて、学習時間・性能面での改善が見られた

背景

  • 文書画像のレイアウト解析、特に歴史的な文書の画像を扱う
  • 文書画像のレイアウト解析でのラベリングタスク
    • Region classification: 文章のブロック単位でのセグメンテーション
    • Typographic labeling: 文字の体裁に関する分類(文字見出し、大文字・小文字・上下にはみ出た部分など)
    • Text line detection and classification: 文章の行単位でのセグメンテーションとその分類
  • 大量のアノテーションデータを用意するのは難しいため、大量のアノテーションデータに依存しない事前学習手法を提案する
  • 論文では、text line detection and classificationに注目する

関連研究

自己教師あり学習
  • Noroozi & Favaro: Unsupervised learning of visual representations by solving jigsaw puzzles. (ECCV2016)
    • 画像のパッチを並べ替える「ジグソーパズルタスク」を提案
  • Gidaris et al: Unsupervised representation learning by predicting image rotations (arxiv2018)
    • 画像を任意の角度で回転させ、その回転角度を予測するタスク
少ないラベル付きデータでの学習
  • Boillet et al.: Multiple document datasets pre-training improves text line detection with deep neural networks. (ICPR2021)
    • 少ないデータでも有効に学習できるDoc-UFCNを提案。実験の比較手法として使われている。
生成モデルによるデータ拡張
  • Vögtlin et al.: Generating synthetic handwritten historical documents with OCR constrained GANs. (ICDAR2021)
    • GANを使って学習データを生成

提案手法

利用するネットワーク

  • U-Net-S: オリジナルのU-Net。
  • Adaptive-Unet: オリジナルからフィルタ数をやや抑えたもの。
  • Doc-UFCN: text line detectionのために提案されたアーキテクチャ。U-shapeのFCN。
  • U-Net-16: 軽量版のU-Net。各ブロックのフィルタ数を16に固定。(この論文オリジナル?)

データセット

リアルデータ: DIVA-HisDB: 中世の文書データセット。3種類(CSG18, CSG863, CB55)のうちCB55, CSG18を用いる。
  • CB55: 14世紀のイタリアで書かれたダンテの『神曲』の写本。複雑なレイアウトと多様な手書きスクリプトが特徴。120ページ(うち40ページがラベル付き。10ページをtrain、10ページをvalidation、20ページをtestで利用) 、960x1344px。
  • CSG18: 9〜12世紀に書かれた聖ガレンの写本で、礼拝に関するテキストや天文学の内容を含む。図や装飾も多く含まれ、解析が難しい文書。40ページのうち10ページをtrain、10ページをvalidation、20ページをtestで利用、960x1344px。
pretext taskのためのデータ
  • 3ステップでデータ画像を作成(Otsu binarizationという手法)
      1. blueチャネルに対して、1 x 45 px のフィルタでラインを水平方向ににじませる
      1. blueチャネルに対して、25 x 25 px のフィルタでラインを水平・垂直方向ににじませる
      1. 1つ目の結果をredチャネル、2つ目の結果をgreenチャネル、blueチャネルを0埋めした画像を作成
  • 黄・緑・赤・黒の4ラベルを予測する問題として学習する
人工 (artificial) データ
  • VAEなどで生成せず、ある程度定まった方法で作成する(そのニュアンスを込めてsyntheticではなくartificialとしている)
    • 特徴的なフォーマット(テキストブロックや文字見出しなど)を含める
    • 文字は手書きやイタリックなどのフォントを使うものと、抽象的な幾何学形状でテキストラインを埋めて、”dummy text” を作成するものとがある
    • マージンやカラムの幅などもランダムに変化させる
  • 作成したデータは自動でラベルが付与され、学習に利用される

事前学習

3種類のデータセットでU-Net-16の事前学習+real dataでのfine-tuningを行い、最も精度の良かったSetMを採用
  • SetD: dummy textの人工データで構成
  • SetF: Carolus, Papyrusフォントを使った人工データで構成
  • SetM: dummy text, Carolus, Papyrusの混合

学習方法

  • baseline: real dataで800epochs from scratch
  • proposed: artificial data(120枚をtrain、60枚をvalidation)で事前学習を100epochs、fine-tuningを100epochs
  • pretext task: pretext task用のデータ(CB55から60枚をtrain, 20枚をvalidation)で200epochs, fine-tuningを100epochs

実験結果

人工データによる事前学習 vs. リアルデータによる事前学習
  • CB55, CSG18の両方で、U-Net16でbaselineに対して人工データが精度改善。ネットワークによって傾向が異なるので、アーキテクチャの影響を受けやすいと考えられる。
 
人工データによる事前学習 vs. リアルデータによる事前学習 カテゴリ別
  • U-Net-16のHighlightカテゴリが大きく改善
    • Highlightが含まれているデータが少なく、baselineでは1つも読めなかったらしい
    • Highlightについては、他のモデルも改善傾向
 
baseline vs. pretext task
  • 精度の高さはU-Net-S with Morpho (pretext taskのデータ) が高く、U-Net16は改善幅が大きい
 
実行時間
  • パラメータが少なく実行時間の短いU-Net-16が、精度面でも良いパフォーマンスを発揮している点がgood
 
定性評価
  • U-Net-16がHighlightの行をうまく抽出できている
  • 今回提案した事前学習の方法は、小さいネットワークと相性がよかった
    • ここのより詳しい調査はfuture work
 

感想

  • データの作り方で精度が大きく変わるのは他のタスク含めてよく挙げられる観点だが、文字っぽい記号を並べても今回のタスクでも有効に働くというのはあまり見たことがなく面白かった。
  • 大量のデータでSoTAを目指す研究もよいが、こういった堅実な研究も大切。