ぽんぽこ日記

このブログはタヌキによって書かれています

GCP記事チェックVol.001

たくさんでるGCP関連の記事。
少しでも読もうというモチベーションで書きます。
自分用メモなので直接ドキュメントを読むことをおすすめします。

cloud.google.com

メモリ設定を最適化するための設定とメトリクス

  • Memorystore for Redisで最も重要な設定の1つがmaxmemory-gb
    • Redisのmaxmemory設定を構成し、キーストレージ用に予約されるメモリ量を決定
    • 指定されたメモリの最大量に達すると、Evictionポリシーが使用される
  • Evictionポリシーは、Memorystore for Redisでmaxmemoryポリシーにより設定される
  • デフォルトのポリシーはvolatile-lruで、TTL (time to live)の有効期限が設定された、最も使用頻度の低いキーを退避させる

Best practice:

  • maxmemory-gbをチューニングする際、システムメモリ使用率を80% 未満を目標に監視
  • システムメモリ使用率が80%を超えた場合、これはインスタンスがメモリプレッシャー下にある
  • 対処せず、メモリ使用量が増え続けると、メモリ不足によるインスタンスのクラッシュの危険性がある
  • OOMエラーを防ぐには
    • activedefragをオンにする
    • maxmemory-gbを下げてシステム使用のオーバーヘッドを増やす
    • インスタンスをスケールアップする

マルチスレッドによるパフォーマンス向上のためにRedis 6を使用

  • Redis 6の新機能の1つに、マルチスレッドI/Oの実装ある
  • これまでのRedisはシングルスレッドで、I/OとRedisエンジンが1つのvCPUを共有するため、場合によってはボトルネックになる可能性があった
  • 複数のvCPUを構成した場合のメリットが発揮されない
  • Memorystore for Redisは、バージョン6を実行しているすべてのインスタンスでI/Oマルチスレッドを有効にし、複数のvCPUを使用してI/Oを同時に処理するこ
  • インスタンススループットを向上させることができる

Best practice:

メンテナンスウィンドウを設定する

  • Memorystore for Redisでは、メンテナンスウィンドウを定義することができる
  • 特定の曜日に1時間だけメンテナンスを実行する時間枠
  • メンテナンスウィンドウを設定することで、メンテナンスが発生するタイミングを予測することができる
  • メンテナンスウィンドウがインスタンスに設定されていない場合、メンテナンスはいつでも、どの日でも実行される可能性がある
  • アプリケーションの使用量が多い時間帯にメンテナンスが発生する可能性がある

Best practice:

  • インスタンスのメンテナンスウィンドウを設定し、ピーク時にメンテナンスが発生しないようにし、使用量の少ない時間帯にのみメンテナンスが発生するようにする
  • インスタンスにメンテナンスの更新が予定される少なくとも7日前に、メールで警告を受けるようにメンテナンス通知をオプトインする
  • メンテナンスの開始時に、システムメモリ使用率メトリクスが50%未満であることを確認する
  • インスタンストラフィックが低い時間帯にスケジューリングするか、メンテナンスウィンドウの間にインスタンスサイズを一時的にスケールアップすることで実現可能
  • 最も影響の少ないStandard Tierを検討
  • Basic Tierのインスタンスは、最大5分間続く可能性のあるメンテナンス中に利用できなくなる

キャッシュデータが重要な場合、Memorystoreの高可用性を構成する

  • MemorystoreはBasic tierとStandard tierの2つの層で提供されてる
  • Basic tierは、エフェメラルキャッシュを持つ単一ノードで構成され、レプリケーションはない
  • ベーシック層に障害が発生した場合、バックアップやレプリケーションがないため、キャッシュの日付が失われる可能性ある
  • Standard Tierは、レプリケーションによる高可用性(HA)と99.9%の可用性SLAを提供し、プライマリノードが故障した場合は自動的にレプリカにフェイルオーバーする
  • 高可用性(HA)機能により、障害が発生した場合でも、重要なキャッシュデータにより高い信頼性と一貫性をもってアクセスが可能
  • フェイルオーバーが行われ、プライマリになったレプリカへの接続が確立されるまでの数秒間、インスタンスは一時的に使用できない
  • Memorystore for Redis Standard Tierは、高可用性とスケールのために最大5つのリードレプリカを持つことができる
  • リードレプリカはデフォルトでは有効になっていない
  • 有効にすると、高可用性に加えて、読み取りワークロードのスケールが可能になり、すべてのレプリカノードにクエリを分散させる単一の読み取りエンドポイントを提供する

Best practice:

  • キャッシュのフルフラッシュを許容できないアプリケーションには、Standard Tier
  • RDBスナップショットを活用することで、さらなるデータ耐久性を実現

Redisコマンドとアンチパターンを避けるために

KEYSコマンドの使用 - KEYSコマンドを使用すると、大規模なデータベースで使用した場合、インスタンスのパフォーマンスに大きな影響を与える可能性ある

Best practice:

  • 実稼働環境でのKEYSコマンドの使用を避ける
  • KEYSコマンドを使用する代わりに、SCANコマンドを使用

未束縛の結果を返すコマンドを避ける - LRANGE、HGETALL、ZRANGE などの特定のコマンドは、非常に大量のキーとデータを返すことがあり、サーバーの性能に悪影響を及ぼします。

Best practice:

  • サポートコマンドでデータ構造のサイズを確認し、サイズが大きすぎないことを確認する

高可用性またはRDBスナップショットを使用しない永続層としてのRedis - 高可用性または定期的なRDBスナップショットが設定されていない場合、インスタンス障害時にメモリストアRedisデータは失われます。

Best practice:

  • 重要なデータやアプリケーションがMemorystore for Redisのある程度の永続性に依存している場合、Standard TierとRDB Snapshotsを使用して高可用性を使用

クライアント接続ロジックへの指数関数的バックオフの実装

  • Exponential backoffは標準的なエラー処理方法
  • 失敗したリクエストを、増加しつつもランダムな遅延で再試行する とによって動作
  • 遅延の一時的な増加の結果、ユーザーがリフレッシュを押したり、 受信したリクエストのバックログが多いために、大量のリクエストが発生する シナリオを緩和するのに有用
  • ランダム化は、再試行戦略の重要なコンポーネント
  • 再試行のたびに時間が増えますが、同時に再試行の大きな波が発生しないように、ランダムな変動も必要
  • ランダムな変動は、通常1-1000ミリ秒の間になります。-
  • リトライ戦略は、リトライが32秒または64秒以上待たされ、最終的に失敗しないように、最大バックオフを含める必要ある

Best practice: - リトライロジックを開発する際に、少しランダムだがバックオフを増加させること

  • 最終的にはタイムアウトし、アラートメカニズムでアプリケーションチームに通知する必要がある
  • redisクライアントですでに実装されている場合があります。

アラート/モニタリングの設定

2022年3-9月でMLエンジニアのタヌキが読んでよかった本

2022年3月から9月までで40ちょい本読んでました。(漫画を除く)
個人的に良かった本を読んだモチベーション別に紹介します。
読書記録はこのサービスを使用しています。 booklog.jp

[重要] おすすめの本があったら教えてください!

質のいいコードが書きたい

オブジェクト指向でなぜつくるのか 第3版 知っておきたいOOP、設計、アジャイル開発の基礎知識

多分、オブジェクト指向系の本で一番丁寧だと思われる。
最初の一冊におすすめかと。

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

「良いコード/悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方」とセットで読むのがおすすめ。

良いコード/悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方

テスト駆動開発

テスト駆動の開発の具体例が書いてあって、理解が深まる1冊。

アーキテクチャを勉強しよう

ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ

ケーススタディとセットに紹介されているところが、理解にを助ける1冊。
メジャーなものから、流行りのマイクロサービスアーキテクチャまでカバーしている。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

言わずと知れた名著。

アーキテクトの審美眼

流行りというか本質的なところを説明しようとしている本。
しっかり理解しようという逃げない心が大切かもです。

Rustを勉強しよう

結婚式に参加したら同じテーブルの人に式の間ずっとRustの布教されたので勉強しようとかなと

プログラミング言語Rust 公式ガイド

Rust勉強するならこの本読んどけと言われた本。
日本語版もwebで公開されているっぽい。

The Rust Programming Language 日本語版 - The Rust Programming Language 日本語版

実践Rustプログラミング入門

公式ガイドとは違い、手を動かして理解しよう!みたいな本。
どっちから入るかは好みだと思います。

システムパフォーマンスの話も知っときたい

達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践

解説が非常に丁寧でびっくりしました。
業務でパフォーマンスチューニングしてない人でも知っていて損はない知識がいっぱいありました。

Prometheus実践ガイド: クラウドネイティブな監視システムの構築

Prometheusの本。

アルゴリズム(純粋に好き)

問題解決のための「アルゴリズム×数学」が基礎からしっかり身につく本

ハードルをなるべく低くしてアルゴリズムを学べる本。
大学1年生の時とかに出会ってたら、別の人生を歩んでいたかもしれない。

エンジニア心構え

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

これもすごい有名な本ですね。

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法

内容も面白いけど、たまにあるコラムが非常に良き

データ基盤

実践的データ基盤への処方箋〜 ビジネス価値創出のためのデータ・システム・ヒトのノウハウ

データ基盤の全体像を丁寧に説明してくれている本。

【自分用メモ】マイクロサービスの概要を読んで

google様が素晴らしいドキュメントを公開しているので忘れないように自分用メモ。
自分のコメントはこの色で記述しています。
直接ドキュメントを読むことをおすすめします。 cloud.google.com

モノリシックアプリケーション

モノリシックアプリケーションは、さまざまなモジュールが 1 つのプログラムに結合される単一層ソフトウェアアプリケーション

モノリスの長所

モノリシックアーキテクチャは、アプリケーションを構築するための従来のソリューション

  • ツールを使用して、モノリシックアプリケーションのエンドツーエンドのテストを実装できる
  • モノリシックアプリケーションのデプロイは、パッケージ化されたアプリケーションをサーバーにコピーするだけでできる
  • モノリシックアプリケーションのすべてのモジュールがメモリ、容量、リソースを共有するため、ロギング、キャッシュ、セキュリティなど、横断的な問題に単一のソリューションで対応できる
  • モノリシックアプローチでは、モジュールが直接相互を呼び出すことができるため、パフォーマンスが向上しやすい

モノリスの課題

複雑なモノリスでは、ビルド、デバッグ、論証が次第に困難になる(めっちゃ、わかる)

  • 異なるモジュールでリソース要件が競合している場合、スケーリングが難しくなる
  • すべてのモジュールが同じプロセス内で実行されるため、メモリリークなどのモジュールのバグにより、システム全体がダウンする可能性がある
  • 新しいフレームワークと言語を採用する場合、モノリシックアプリケーションは、より複雑になる。例えば、新しいフレームワークを使用するようにアプリケーション全体を書き換えると、そのフレームワークが著しく改善されていても、時間の面でもお金の面でもコストがかかる

マイクロサービスアプリケーション

マイクロサービスは、それぞれが独自のアーキテクチャビジネスロジックを持つミニアプリケーション

  • アプリケーションとデータベース間の関係が大幅に変化する
  • 1 つのデータベースを他のサービスと共有するのではなく、各サービスで要件ごとに最適なデータベースを用意することを推奨
  • サービスごとに 1 つのデータベースがある場合、データに対するすべてのリクエストは共有API ではなくサービス API を経由するため、サービス間の疎結合が発生する

マイクロサービスの長所

モノリスの課題である複雑さの問題に対処できる

  • 全体的な機能は同じだが、マイクロサービスを使用して、アプリケーションを管理可能なチャンクやサービスに分割

  • 各サービスには、RPC またはメッセージドリブンのAPIの形式で明確に定義された境界がある

  • 個々のサービスで開発時間が短縮され、把握と保守が容易になる
  • 自律型チームは個々のサービスを個別に開発できる
  • プロダクトの技術的能力ではなく、ビジネス境界を中心にマイクロサービスを編成できる
  • 開発からテスト、デプロイ、メンテナンス、モニタリングに至るまで、割り当てられたソフトウェアのライフサイクル全体にわたって単一の独立したチームを編成できる
  • 開発者は異なるプログラミング言語で各マイクロサービスを作成し、多言語で記述されたアプリケーションを作成できる
  • マイクロサービスごとに最も効果的な言語を使用すると、アプリケーションをより迅速に開発し、アプリケーションを最適化してコードの複雑さを軽減し、パフォーマンスと機能を向上させることができる
  • 機能をモノリスから切り離すことにより、独立したチームによるマイクロサービスの独立したリリースが可能になる
  • 独立したリリースサイクルで、チームの開発スピードと製品化までの時間を改善できる
  • マイクロサービスアーキテクチャでは、各サービスを個別にスケーリングできる
  • 容量と可用性の制約を満たす各サービスのインスタンスを大量にデプロイできる
  • サービスを個別にスケーリングすると、システム全体の可用性と信頼性が向上する

マイクロサービスの課題

  • アプリケーションが分散システムであることで生じる複雑さ
  • デベロッパーは、サービス間通信メカニズムを選択して実装する必要があるサービスで、アップストリームサービスの部分的な障害と使用不能性も処理する必要がある
  • 異なるマイクロサービス間でトランザクションを管理する必要がある(分散トランザクション)
  • 複数のビジネスエンティティを更新するビジネスオペレーションは一般的であり、通常、すべてのオペレーションが適用されるか、すべてが失敗するかのアトミックな方法で適用される
  • 単一のデータベーストランザクションで複数のオペレーションをラップすると、アトミック性が保証される
  • マイクロサービスベースのアプリケーションでは、ビジネスオペレーションが複数の異なるマイクロサービスに分散される可能性があるため、さまざまなサービスが所有する複数のデータベースを更新する必要がある
  • 障害が発生した場合、さまざまなマイクロサービスの呼び出しの失敗または成功を追跡し、状態をロールバックすることが重要
  • 最悪のシナリオでは、障害による状態ロールバックが正しく行われない場合、サービス間にデータの不一致が生じる可能性がある
  • マイクロサービスベースのアプリケーションの包括的なテストは、モノリシック アプリケーションのテストよりも複雑
  • マイクロサービスベースのアプリケーションのデプロイは、モノリシックアプリケーションのデプロイよりも複雑
  • マイクロサービスアーキテクチャでは、モニタリングとアラートを行うサービスが増えるため、運用のオーバーヘッドが増加する
  • マイクロサービス アーキテクチャでは、サービス間の通信が増えるため、より多くの障害点が生じやすい
  • モノリシックアプリケーションを、小規模なアプリケーションサーバクラスタにデプロイする必要がある
  • マイクロサービスベースのアプリケーションでは、複数の言語や環境でビルド、テスト、デプロイ、実行を行う個別のサービスが多数存在する場合がある
  • これらのサービスはすべて、フェイルオーバーと復元力のためにクラスタ化する必要ある
  • マイクロサービス アプリケーションを製品化するには、高品質のモニタリングとオペレーションのインフラストラクチャが必要
  • マイクロサービスアーキテクチャでサービスを分割すると、アプリケーションでより多くの機能を同時に実行できる
  • モジュールは分離サービスとして実行されるため、サービス間のネットワーク呼び出しのためにレスポンス時間にレイテンシが発生する
  • すべてのアプリケーションがマイクロサービスに分割できるほどの大きさであるわけではない
  • リアルタイムのデータの高速ストリームを処理する必要があるアプリケーションなどはコンポーネント間の緊密な統合が必要
  • サービス間に通信レイヤが追加されると、リアルタイム処理が遅くなる可能性がある
  • サービス間の通信を事前に考えておくと、サービス境界を明確にマークする際に役立つ分析情報を得ることができる
  • マイクロサービスのベストプラクティスでは、サービスごとのデータベースが必要になる
  • アプリケーションのデータモデリングを行う際に、サービスごとのデータベースがアプリケーションに適合するかを確認する必要がある
  • マイクロサービスアーキテクチャを実装する際には、ボトルネックの特定、障害の検出と防止、診断のサポートを行なえるように、環境のインストルメンテーションとモニタリングを行う必要がある
  • マイクロサービス アーキテクチャでは、各サービスに個別のアクセス制御を行っている
  • セキュリティを確保するには、環境内でも API を使用する外部アプリケーションからも、各サービスへのアクセスを保護する必要がある
  • 同期サービス間通信により、アプリケーションの可用性が低下するのが一般的
  • 非同期でメッセージベースの通信を実装すること推奨

モノリシックアプリケーションをマイクロサービスに移行するタイミング

  • すでにモノリスを正常に実行している場合、マイクロサービスを採用するのはチームにとって大きな投資費用となる
  • マイクロサービスの基本的性質はチームによって実装方法が異なる
  • マイクロサービス アプローチが目標を達成する最良の方法であると思われる場合は、まずモノリスから 1 つのサービスを抽出し、それを開発、テスト、本番環境でデプロイすることがいい

感想

  • どっちも複雑だけど、どっちの複雑性を取るかみたいな話だなと

Learning Fine-grained Image Similarity with Deep Ranking

Deep Metric Learning系の論文を読んでいこうかなと思います。
Learning Fine-grained Image Similarity with Deep Ranking [1]
この論文は有名なTriplet Lossが提案された論文です。CVPR2014で発表されました。
時の流れを感じる(´;ω;`)

0. ざっくり説明

全部読むの面倒くさい人用

1. 導入

embeddingした画像同士の距離(非類似度)は以下のように定義できる。
この距離を上手く学習したい。

{ \begin{align}  D(f(P),  f(Q)) = | | f(P) - f(Q) | |_{2}^{2}  \end{align}\tag{1}}

 D(., .) : embedding spaceのユークリッド距離
 f(.) : embedding function
 P, Q : 画像

2. 主な考え

[2] より引用

Negative(Anchorと別カテゴリの画像)よりもPositive(Anchorと同じカテゴリ)よりもξ(マージン分)に遠くにいてねという考え
注: この論文ではAnchor, Positive, Nagetiveという表現ではなくQuery, Positive, Negativeという表現をしています。

具体的例

[1] より引用

3. 定式化

Negative(Anchorと別カテゴリの画像)よりもPositive(Anchorと同じカテゴリ)よりもξ(マージン分)に遠くにいてね

これを定式化 {\begin{align} D(f(p_i),   f(p_i^{+})) \lt   D(f(p_i),   f(p_i^{-})),  \\  \forall p_i, p_i^{+}, p_i^{-} ~ \mbox{such that}   ~ r(p_i, p_i^{+}) \gt r(p_i, p_i^{-}) \end{align} \tag{2}}

 r(., .) : pairwise relevance score (画像ペアの関連度合いを示す関数)

{t_{i}=(p_i, p_i^{+}, p_i^{-})} : クエリ(画像{p_i})に対して、距離が小さい(似ていてほしい画像)と距離が遠い(似てほしくない画像)の組み合わせ
ここでトリプレットという考え出てきたんですね。

各トリプレットに対して、損失は以下のように定義できる。
{\begin{align} l(p_i, p_i^{+}, p_i^{-}) = \max \lbrace 0, g+D(f(p_i),   f(p_i^{+})) - D(f(p_i),   f(p_i^{-})) \rbrace \end{align} \tag{3}}

{g} : {(p_i, p_i^{+})}{(p_i, p_i^{-})}の距離を調整する正則化パラメータ

最適化問題

{
\begin{align}
&\min \sum_{i}  \xi_i + \lambda \| \textbf{W} \|_{2}^{2}  \\\
&s.t. : \max \lbrace 0, g+D(f(p_i),   f(p_i^{+})) - D(f(p_i),   f(p_i^{-})) \rbrace \\\
&\forall ~ p_i, p_i^{+}, p_i^{-} ~  \mbox{such that}    ~ r(p_i, p_i^{+}) \gt r(p_i, p_i^{-})
\end{align}
\tag{4}
}

{\xi_i} : { \max \lbrace 0, g+D(f(p_i),   f(p_i^{+})) - D(f(p_i),   f(p_i^{-})) \rbrace }と同じ
{\lambda} : 過学習を防ぐ正則化パラメータ(論文では{\lambda=0.001}を採用)
{\textbf{W}} : 学習されるパラメータ

[1] より引用

4. Network Architecture

式(4)で定義した損失関数を以下のアーキテクチャで学習

[1] より引用

5. OptimizationとSamplinng

5.1 Optimization

5.2 Triplet Sampling

基本的な考え: 検索結果上位に興味があるので、 対象となる画像の近くだけ上手く学習できていればいい
{
\begin{align}
r_i=\sum_{j:c_j=c_i, j \neq i}^{N} r_{i,j}
\end{align}
\tag{4}
} {c_i} : 画像{p_i}が属するカテゴリ
{r_i} : 画像{p_i}と同カテゴリの画像とのpairwise relevance scoreの総和

5.2.1 画像{p_i}の選び方

  • {r_i}の割合によってサンプリングされる。
  • {r_i}の値が大きければ大きいほど、画像{p_i}がクエリとしてサンプリングされやすくなる。

5.2.2 Positiveの選び方

{p_i}に対して高いpairwise relevance scoreを持つ画像をPositiveとしてサンプリングしたい

{
\begin{align}
P(p_i^{+})= \frac{\min \lbrace T_{p} , r_{i,i^{+}}  \rbrace}{Z_i}
\end{align}
\tag{5}
} {T_p} : 閾値
{Z_i} : the normalization constant, {\sum_{i^{+}}P(p_i^{+})}と同じ

5.2.3 Nagetiveの選び方

2種類ある。
1つ目: 画像{p_i}とは異なるカテゴリから選ぶ方法 (Out of class negative sample)
別カテゴリに属する画像から一様にサンプリングされる。

2つ目: 画像{p_i}とは同じカテゴリから選ぶ方法(In-class negative samples)
画像{p_i}と同じカテゴリだが、画像{p_i}とのpairwise relevance scoreが低い画像

トリプレットが満たすべき条件

全てのトリプレットは式(6)を満たすようにする。
{
\begin{align}
r_{i,i^{+}} - r_{i,i^{-}} \geq T_r, \\
\forall ~ t_i = (p_i, p_i^{+}, p_i^{-})
\end{align}
\tag{6}
}

どうやっているか

流れとしては画像{p_i}選んで、positiveを選び、negativeを選ぶ。

Positiveサンプル 学習データを全てメモリにのせて計算することは不可能なのでBuffersを使う。
- 各Bufferは一定の容量を待つ(下の図だと画像6枚分)。同じカテゴリの画像を保持する。
- Bufferに空きがあるなら画像{p_j}をBufferに入れる。
- Bufferが埋まっているならBuffer内の最小の{k^{ \prime }_j}の値を守る画像{p^{ \prime }_j}と画像{p_j}を入れ替える。

{k_j = u_j^{\frac{1}{r_j}}} : 画像をBufferに入れるかどうかを決めるスコア。{r_j}が大きければ大きい値を持つように設計されている。
{r_j} : 画像{p_j}と同カテゴリの画像とのpairwise relevance scoreの総和
{u_j} : {uniform(0,1)}からサンプリングされた値

Negativeサンプル 画像{p_i}とは異なるカテゴリから選ぶ方法では 他のBufferから一様にサンプリング。

画像{p_i}とは同じカテゴリから選ぶ方法
式(6)を満たすやつをサンプリングする。

どっちのNegativeサンプリングを行うかはパラメータを与えて制御する。

[1] より引用

6. 実験

6.1. データ

ImageNet ILSVRC-2012データセット
ConvNetのpre-trainに使用
- 1000カテゴリ
- 各カテゴリ約1000枚
- training images 約120万枚
- validation images 5万枚

Relevance training data
筆者が作ったデータセット。 fine-tuningに使用。
- Google画像検索から10万件の検索クエリより作成
- 各クエリから上位140件の画像結果を取得
- 画像数は約1400万枚
- 同じ検索クエリからの画像に対して{r_{i,j}}を計算
- 異なるクエリからの画像は{r_{i,j} =0}とする

Triplet Evaluation Data
トリプレットデータセット。モデルの評価に使用。
- 1000のクエリ用意し、Google画像検索エンジンから各クエリの検索結果上位50件からトリプレット(Q、A、B)をサンプリング
- 人間の評価者を用いて、トリプレット(Q、A、B)を評価
- 人間の評価者は以下の4種類の評価を各トリプレットに与える
(1) 画像AとBの両方がクエリ画像Qに類似する
(2) 画像AとBの両方がクエリ画像Qに類似しない
(3) 画像AはBよりもQに類似する
(4) 画像BはAよりもQに類似する
- 各トリプレットは3人の評価者によって評価される
- 3人の評価者の評価が一致したトリプレットのみが最終的なデータセットとして採用
- (1)と(2)の評価を与えられたトリプレットは画像の類似度順序を反映していないため、今回のデータセットしては採用しない
- 約14,000個のトリプレットが用意された

6.2. 評価指標

  • similarity precision

  • score-at-top-K (K=30)

実験1: representationの比較

比較手法

Hand-crafted Features
- Wavelet - Color (LAB histoghram) - SIFT-like features - SIFT-like Fisher vectors - HOG - SPMK Taxton features with max pooling

モデル
上の特徴量を全て使って以下のモデルを適用
- L1HashKCPA
- OASIS

実験結果

提案手法: Deep Ranking(画像{p_i}とは異なるカテゴリから選ぶ方法の割合を20%)

  • 学習させてない(Wavelet, Color, SIFT-like features, SIFT-like Fisher vectors, HOG, SPMK Taxton features with max pooling)やつの性能は微妙
  • L1HashKCPAは1000次元という次元の割にはいい性能だが、DeepRankingには負ける
  • OASISはRelevance training dataを情報を用いているが、DeepRankingには負ける。「特徴抽出」-「モデル学習」の二段階のアプローチよりも画像に対してランキングモデルを直接学習することがいい

Table 1. Similarity precision (Precision) and score-at-top-30 (Score-30) for different features.
[1] より引用

実験2: アーキテクチャーの比較

比較手法

  • ConvNet
  • Single-scale deep neural network for ranking
  • Single-scale deep neural network for rankingの出力に対して、OASIS学習させたもの
  • Single-scale deep neural network for rankingの出力とHand-crafted Featuresを組み合わせたもの

実験結果

  • Deep Ranking (提案手法)が強い

    Table 2. Similarity precision (Precision) and score at top 30 (Score-30) for different neural network architectures.
    [1] より引用

実験3: サンプリングの比較

画像{p_i}とは異なるカテゴリから選ぶ方法の割合変えたらどうなるの?

実験結果

  • 一様サンプリングよりもいい
  • Out of class negative sampleの割合を大きくするとscore-at-top30は下がる
  • Out of class negative sampleの割合を20%を超えるとsimilarity precisionが上がる

    Figure 6. The relationship between the performance of the proposed method and the fraction of out-of-class negative samples.
    [1] より引用

実験4: Ranking Examples

実際Rankingは上手くいっているのか?

実験結果

Figure 7. Comparison of the ranking examples of ConvNet, Oasis Features and Deep Ranking. [1] より引用

References

[1] Wang, Jiang, et al. "Learning fine-grained image similarity with deep ranking." Proceedings of the IEEE conference on computer vision and pattern recognition. 2014.
[2] Schroff, Florian, Dmitry Kalenichenko, and James Philbin. "Facenet: A unified embedding for face recognition and clustering." Proceedings of the IEEE conference on computer vision and pattern recognition. 2015.

【自分用メモ】103 Bits of Advice I Wish I Had Knownでよかったもの抜粋

103 Bits of Advice I Wish I Had Knownが非常によかったので個人的に心掛けたいものを抜粋
- 日本語ver

  • 約99%の確率で、今こそがそのタイミングです

  • 自分がなりたくない人のために働くのは絶対にやめよう

  • 効率は非常に過大評価され、サボりは非常に過小評価されます。定期的な休息、長期休暇、あてのない散歩、オフタイムは、あらゆる種類の最高のパフォーマンスを発揮するために不可欠です。最高の労働倫理は、優れた休息倫理を必要とします

  • プライベートで批判し、公の場で褒めなさい
  • 先生からすべてを聞き出すのが生徒の務めであり、生徒からすべてを聞き出すのが先生の務めです
  • 自分が正しいかのように自信を持って話し、自分が間違っているかのように注意深く耳を傾ける
  • 努力(運動、交友、仕事)は、量よりも一貫性が大切です。毎日行う小さなことに勝るものはなく、たまに行うことよりもずっと重要です
  • あなたに必要な3つのこと:うまくいくまであきらめない力、うまくいかないことをあきらめる力、そして、その2つを区別するのを助けてくれる他人への信頼
  • 時間通りというのはありえません。遅刻するか、早退するか、どちらかです。あなたの選択です
  • あなたが尊敬する人に聞いてみてください。彼らの幸運は、主な目標から遠回りしたところにあるのです。だから、回り道を受け入れましょう。人生は誰にとっても一直線ではありません
  • 子どもや動物の場合は特に、悪い行動を罰するよりも良い行動を褒める方が10倍良い結果が得られるでしょう
  • とんでもなく野心的な目標の利点はハードルを非常に高く設定することです。たとえ失敗しても,普通の人の目から見れば成功かもしれません
  • 褒め言葉を否定したり、はぐらかしたりするのは失礼にあたります。たとえ相応しくないと思っても、感謝の気持ちを持って受け止めましょう
  • 悪い日に何をするかは、良い日に何をするかよりも重要です
  • 頭のいい人に、お金のためだけに一生懸命働いてもらうことはできない
  • あなたは、あなたのために何もしない人たちにどれだけよくしてあげられるかで周りから判断されるでしょう
  • 私たちは、1日にできることを過大評価し、10年に達成できることを過小評価しがちです。10年かければ、奇跡的なことが成し遂げられる。長い目で見れば、小さな積み重ねが大きな失敗を克服することになるのです
  • あなたの人生を変えてくれた先生に感謝しましょう
  • うまくコミュニケーションできない超頭のいい人よりも、うまくコミュニケーションできるあまり頭のよくない人のほうが、ずっといい結果を出せる可能性があります。コミュニケーション能力を向上させるのは、知能を向上させるよりもずっと簡単だからです
  • たまに騙されることは、誰に対してもベストを尽くすためのわずかな代償なのです
  • 行き詰まったときは、他人に自分の問題を説明しましょう。問題を整理することで、解決策が見えてくることがよくあります。「問題を説明すること」をトラブルシューティングのプロセスの一部にしてください
  • あなたのグループは、周りから感謝されているということを示すだけで、身の丈をはるかに超えた大きなことを成し遂げることができます
  • 習慣はひらめきよりもずっと頼りになる。習慣を身につけることで、進歩を遂げましょう。体型を整えることに集中せず、運動を欠かさない人間になることに集中しましょう
  • あなたは他人の2%しか見ていませんし、相手もあなたの2%しか見ていません。隠された98%に意識を向けましょう
  • 大きな収穫を得るためには、自分が興味のないことに特に好奇心を持ってください
  • 目的地ではなく、方向を重視して下さい。正しい方向を維持すれば、行きたいところにたどり着けるはずです
  • 新しい仕事のために給料を交渉するのに最適なタイミングは、相手があなたを欲しいと言ってきた後であり、その前ではありません。そうすると、お互いが先に金額を名乗るチキンレースになりますが、先に数字を出させた方が有利です
  • 老いに対する最大の予防策は、驚き続けることです

タヌキの機械学習系論文の読み方

原則: 質の良い論文をたくさんきちんと読むことが大切だと考えています。
背景: 機械学習は近年熱いテーマであり、日々新しい論文が大量に発表されています。 そのため、論文の質も玉石混交。そんな機械学習界隈での自分なりの論文の読み方をまとめてみました。

注) 完全に個人のやり方です。アドバイス頂けると嬉しいです。🙇

自分の興味のある論文の探し方(最初の1本)

質の確認

論文を読んでる最中に気をつけていること

落合先生のフォーマットを埋められるようにする

https://www.slideshare.net/Ochyai/1-ftma15より引用

自分は簡略verでやることが多いです(スライド1枚に収めるため)

その他の心掛け

speakerdeck.com

次読む論文の決め方

ラーメン二郎のスクレイピング

最近ダイエットしていて、ラーメン二郎を食べていないので画像をスクレイピングしてみました。

pip install icrawler

ドキュメント

from icrawler.builtin import GoogleImageCrawler
img_path = 'your_image_dir/zirou2' # 保存先のディレクトリパス
google_crawler = GoogleImageCrawler(storage={'root_dir': img_path})
google_crawler.crawl(keyword='二郎', max_num=10)
filters = dict(
    size='large',
    color='orange',
    license='commercial,modify',
    date=((2022, 4, 1), (2022, 4, 15)))
google_crawler.crawl(keyword='二郎', filters=filters, offset=0, max_num=1000,
                     min_size=(200,200), max_size=None, file_idx_offset=0)

色々設定できるみたい。
type – “photo”, “face”, “clipart”, “linedrawing”, “animated”.
color – “color”, “blackandwhite”, “transparent”, “red”, “orange”, “yellow”, “green”, “teal”, “blue”, “purple”, “pink”, “white”, “gray”, “black”, “brown”.
size – “large”, “medium”, “icon”, or larger than a given size (e.g. “>640x480”), or exactly is a given size (“=1024x768”).
license – “noncommercial”(labeled for noncommercial reuse), “commercial”(labeled for reuse), “noncommercial,modify”(labeled for noncommercial reuse with modification), “commercial,modify”(labeled for reuse with modification).
date – “pastday”, “pastweek”