2025-01-21 機械学習勉強会
今週のTOPIC[blog] 100倍速で実用的な文章ベクトルを作れる、日本語 StaticEmbedding モデルを公開[paper] DeepSeek-R1[blog] Common pitfalls when building generative AI applications[slide] 第12回 Data-CentricAI勉強会_データ品質向上のために１年間一人で取り組んだアノテーションのリアル[blog] Introducing Phi-4: Microsoft’s Newest Small Language Model Specializing in Complex Reasoning | Microsoft Community Hub[slide] リポジトリをまるごとAIでレビューするPDF構造解説オブジェクトファイル構造ヘッダ本体相互参照テーブルトレーラドキュメント構造トレーラ辞書ドキュメントカタログページとページリスト
今週のTOPIC
※ [論文] [blog] など何に関するTOPICなのかパッと見で分かるようにしましょう。
出典を埋め込みURLにしましょう。
@Naoto Shimakoshi
[blog] 100倍速で実用的な文章ベクトルを作れる、日本語 StaticEmbedding モデルを公開
- 既存のEmbeddingは作成のたびに、tokenizer → token tmbedding → 推論 → text embeddingの過程を通るためハイコスト。
- Static Embeddingの場合は、Word2Vecのように事前計算されたベクトルを辞書的に返す。
- 訓練方法
- 対照学習
- Matryoshka Representation Learning
- 効率的にベクトルの次元を下げる方法 (らしい)
- パッと見、学習時に低次元のベクトルにも損失をかけて学習しているだけっぽい？
- なるものがある。
- sentence_transformersの を使って学習
- 中身はtorchの を使っている。
- tokenize → Text Embeddingに直接行ってる感じ
- 技術要素としてはModel2Vecなどが関連
- 話が逸れたが、今回はこれを日本語のモデルで作ってみた、という話。実際、総合スコアでに若干及ばないくらいで、CPUで126倍高速という速度を実現している。
- 1秒で10万件のセンテンスを処理できる。(長さによるとは思うが)
- JMTEBのmr-tidyタスクで700万文章をベクトル化する際にRTX4090で4分で終わったらしい。
- mr-tidyの項目が著しく悪いらしく、大量の文章を検索するようなタスクではBM25とかの方がいい可能性が高いらしい。
@Yuya Matsumura
[paper] DeepSeek-R1
- MIT License のつよつよモデル DeepSeek-R1 がリリース
- ‣
- いくつかの蒸留モデルとともに重みが公開されている。家庭用GPUでも高性能LLMが！
- ‣
- モデル自身の試行錯誤の中で新しい解答戦略を見つける（「あ、わかった！」と突然言い出す） aha moment が観測された。
‣
- 使ってみたけど思考(reasoning)過程が見れて面白い
- 日本語で考えると微妙になるので、英語で考えた上で日本語で説明してもらっています。
@Yuta Kamikawa
[blog] Common pitfalls when building generative AI applications
生成AIを利用したアプリケーション開発における落とし穴6選
1. 不必要な場面での生成AIの使用
単純な最適化や予測タスクに対して生成AIを使用する
例:
- 電力消費の最適化（単純なスケジューリングで解決可能）
- ネットワークトラフィックの異常検知
- 顧客コール量の予測
これらの問題の多くは、より単純で信頼性の高い従来の手法で解決できます。新しい技術を試すこと自体は良いですが、問題解決と生成AIの使用は異なる目標であることを認識する必要がある
2. 「悪いプロダクト」と「悪いAI」の混同
ユーザーの否定的なフィードバックをAIの問題としがちだが、実際はプロダクトのUXの問題であることも多い
例:
- 議事録要約：ユーザーが求めていたのは要約ではなく、自分に関連するアクションアイテムだけでした
- LinkedInのスキル評価チャットボット：正確な回答よりも、有用な回答が求められていました
- Intuitの税務チャットボット：ユーザーは入力を嫌がり、クリック式の提案質問を導入して成功しました
3. 初めから複雑なことをする
例:
- 直接のAPI呼び出しで十分な場合にエージェントフレームワークを使用
- 単純な検索で十分な場合にベクターデータベースにこだわる
- プロンプトで解決できる場合にファインチューニングを行う
初期段階では、シンプルな解決策から始めることが重要
4. 完成度80%-100%の難しさを過小評価する
- 0%から80%までの到達は比較的容易
- 80%から90-95%への改善は非常に困難
5. 人による評価の軽視
生成AIによる自動評価だけでなく、人による定性評価も重要
- AI評価と人による評価の相関確認
- ユーザー行動の理解
- パターンと変化の検出
毎日30-1000件程度のサンプルを人が評価することで、重要な考察が得られる
6. 企業全体で明確な戦略を立てずに個人のアイディアを独立して実装する
- 個人の日常的な問題に偏りがち
- 費用対効果の最大化を考慮していない
- 小規模で影響の少ないアプリケーションの乱立につながる
@Shun Ito
[slide] 第12回 Data-CentricAI勉強会_データ品質向上のために１年間一人で取り組んだアノテーションのリアル
- 1人で1年以上かけて約600,000個の画像アノテーション（物体検出・骨格検出）をした経験を受けての知見共有
- 人間はミスをする前提で、認知負荷や複雑さを抑えたタスク設計にする
- 同じような情報をまとめてアノテーションすると認知負荷下がってよい
- データ量をただ求めるのではなく、情報量の多さや品質の高さを重視して進める
- 学習を回しながらモデルの弱いところを見つけてアノテーションを繰り返す（能動学習）
- アノテーションはツラい作業ではある
- 正確さを求めるなら単調作業になるまで詰めておかないといけない
- 依頼する場合は「なぜこの作業が必要でどういう価値貢献になるのか」を伝えるべき
@qluto (Ryosuke Fukazawa)
[blog] Introducing Phi-4: Microsoft’s Newest Small Language Model Specializing in Complex Reasoning | Microsoft Community Hub
1ヶ月ほど前のものですが改めて。
テクニカルレポートによると、Phi-3からのアーキテクチャ上の大きなアップデートはないですが、データ品質の向上、学習手法の改善などによって特にSTEM分野での推論性能が大幅に向上しました。
Phi-3の頃からデータの品質に重きを置いて良い結果を得るための工夫がされていましたが、Phi-4ではそれがさらに強まっています。
Phi-4はデータ品質により重点を置いており、合成データが学習データの大部分を占めています
@Yosuke Yoshida
[slide] リポジトリをまるごとAIでレビューする
- 背景
- 様々な言語、アーキテクチャやプラットフォームのものがあり、レビュワーの技術スタックでカバーしきれない
- 短期間に幅広い範囲をレビューする必要があり、すべてを網羅的にレビューしきれない
- レビューシステム概要
- LongContextモデルを活用し、リポジトリ全体を単一のコンテキストとして、複数の評価基準に基づいて包括的に分析
- 改善提案を自動生成
- レビュープロセス概要
- レビュープロセスの中で、Claude3.5 SonnetとGemini1.5 Proを使用
vllmのレビュー結果
- 技術的なポイント
- AIによる回答に一貫性を持たせ、キャッシュできるようにTemperature=0
- コンテキスト長が長くても一度に全体を取り込めないリポジトリは多い
- レビューするファイルそのものもAIによって選定
- 出力が長くなるとJSONが不安定になる
- マークダウンで出力し正規表現で解析
- メリットと効果
- レビュワー担当者の技術スタックによらず一定精度のレビューが可能になった
- 課題
- 提案内容の妥当性を人間が評価できる必要がある
- レビュー対象のファイル選定の精度がファイルパスに依存
- CodacyやSonarQubeなどの競合サービスとの比較ができていない
PDF構造解説
- PDF構造解説
- John Whitington 著、村上 雅章 訳
- https://www.oreilly.co.jp/books/9784873115498/
- サンプルPDF
- 書籍にあるサンプルPDFをベースに説明しています (pdftkによる変換で書籍と若干差分はあります)
helloworld.pdf
オブジェクト
基本的なオブジェクト
- 整数や実数
- e.g. 42、3.1415、-1
- 文字列
- 丸括弧で囲む
- e.g. (TheQuickBrownFox)
- 名前
- ではじまり辞書のキーやさまざまな用途に用いられる
- e.g. /Blue
- ブーリアン値 (true / false)
- null
複合オブジェクト
- 配列
- 他のオブジェクトを複数格納した順序付きのコレクション
- e.g. [50 30 /Fred]、[/Green /Blue [/Red /Yellow]]
- 辞書
- 名前からオブジェクトへの対応付けを行った順序無しマップ
- e.g. <</Contents 4 0 R /Resources 5 0 R>>
- ストリーム
- イメージやフォント等のバイナリデータと、データの長さや圧縮パラメータといった各種の属性を格納した辞書のセット
例
オブジェクト間の関連付け
- 間接参照
- あるオブジェクトから他のオブジェクトへのリンクを作成
- e.g. 2 0 R (オブジェクト番号2、世代番号0、 R は間接参照を意味するキーワード)
ファイル構造
PDFファイルには4つのセクションが存在
- ヘッダ
- 本体
- 相互参照テーブル
- トレーラ
ヘッダ
- 最初の行でドキュメントが使用しているPDFのバージョンを指定
- 2行目はファイルがバイナリであることを識別できるよう、10進数で127よりも大きな値(ASCIIの範囲外)となるバイトを含ませている
- FTPのテキストモードによるファイル転送などで、行末符号を変換されることでファイルが破損することを防ぐ
本体
- ファイルの本体はオブジェクトの並びで構成される
- オブジェクトはそれぞれの先頭でオブジェクト番号と世代番号、objキーワードが1行に記述され、最後の行はendobjキーワードとなる
相互参照テーブル
- 相互参照テーブルは、ファイルの本体に存在する各オブジェクトへのバイトオフセットを一覧にしたもので、オブジェクトへのランダムアクセスが可能となる
- これによって先頭からファイルを読み進めていく必要がなくなり、使用することのないオブジェクトを読む必要もなくなり、巨大なPDFドキュメントのページ数を数えるような処理でも高速に実行できるようになる
- 例えば、オブジェクト3のバイトオフセットは281となる
トレーラ
- トレーラの最初の行はtrailerキーワードで、この後にトレーラ辞書が続きます
- トレーラ辞書には、 /Size、/Root エントリが必須
- /Sizeエントリ
- 相互参照テーブル内のエントリ数
- /Rootエントリ
- ドキュメントカタログのオブジェクト番号
- ドキュメントカタログ - 本体に定義されるオブジェクトグラフのルート要素
- startxref
- 相互参照テーブルの開始位置を示すバイトオフセット
- %%EOF
- PDFファイルの終端
- トレーラを読み込む際には、ファイルの終端を表すEOFマーカーを見つけた後、相互参照テーブルの開始オフセットを読み込み、トレーラ辞書の解析を行い、trailerキーワードに到達した時点で、トレーラの上端に達したことを認識する
ドキュメント構造
トレーラ辞書
ドキュメントカタログ
ページとページリスト
ページリスト
ドキュメント中のページを列挙するための構造体
ページ
- グラフィックスコンテンツやテキストコンテンツを描画するための命令群をそのリソース(フォント定義などを含む構造体)とともにまとめたもの
- メディアボックスやその他のボックスで使用される矩形というデータ構造は、4つの数値の配列となっている (通常左下隅と右上隅の座標)
- /Rotate エントリで閲覧時のページの角度を設定可能
- 座標変換にはcmオペレータを使う
- 方向にそれぞれ の並行移動は
- 方向にそれぞれ 倍する場合は
- 反時計回りに ラジアンの回転の場合は
- 以上をまとめると座標変換前の座標を 、座標変換後の座標を とすると以下のアフィン変換を行うことになる