Tag: learning

Amazon EC2 的 P2 instance

Amazon EC2 為了 GPU 而推出的 P2 type：「New P2 Instance Type for Amazon EC2 – Up to 16 GPUs」。

p2.large 有這樣的規格：

This new instance type incorporates up to 8 NVIDIA Tesla K80 Accelerators, each running a pair of NVIDIA GK210 GPUs. Each GPU provides 12 GB of memory (accessible via 240 GB/second of memory bandwidth), and 2,496 parallel processing cores.

而最大台的 p2.16xlarge 也就是 16 倍... 每小時單價也刷新了之前 x1.32xlarge 的記錄 $13.338/hr (us-east-1)，來到了 $14.4/hr...

另外也推出了 deep learning AMI，內裝了一堆常見支援 GPU 的 ML framework：

In order to help you to make great use of one or more P2 instances, we are launching a Deep Learning AMI today.

透過演算法修照片的工具

看到「A simple interface for editing natural photos with generative neural networks.」這個工具，直接看這個兩分鐘的影片比較清楚知道他想要做的事情：

當你修正了某一個點後，這個工具就透過演算法改變其他的點，讓照片看起來變得自然... 作者所發表的論文可以在「Neural Photo Editing with Introspective Adversarial Networks」這邊下載到。

透過 Deep Learning 辨識人臉馬賽克的技術

在某些新聞報導透漏出了受害者的某些背景身份，於是你手上有了這兩個資料：

  • 符合這些背景身份的四十個人的照片。
  • 人臉被馬賽克後的新聞照片。

現在的問題是，要怎麼判斷出新聞照片裡是哪個人：「Defeating Image Obfuscation with Deep Learning」。

類似這樣的實驗，從 40 個人中找出正確的人，有 50% 的正確率：

也許 50% 不算到能用的程度，但這代表老大哥的技術已經在發展了...

機器學習減肥法

在 Hacker News Daily 上看到的方法，作者利用機器學習的方法試著找出那些因素導致他變胖，然後再規劃減肥計畫：「Discovering ketosis: how to effectively lose weight」，文章有點長，講重點。

首先作者把每天的體重與行為記錄起來，像是這樣：

#
# -- Comment lines (ignored)
#
Date,MorningWeight,YesterdayFactors
2012-06-10,185.0,
2012-06-11,182.6,salad sleep bacon cheese tea halfnhalf icecream
2012-06-12,181.0,sleep egg
2012-06-13,183.6,mottsfruitsnack:2 pizza:0.5 bread:0.5 date:3 dietsnapple splenda milk nosleep
2012-06-14,183.6,coffeecandy:2 egg mayo cheese:2 rice meat bread:0.5 peanut:0.4
2012-06-15,183.4,meat sugarlesscandy salad cherry:4 bread:0 dietsnapple:0.5 egg mayo oliveoil
2012-06-16,183.6,caprise bread grape:0.2 pasadena sugaryogurt dietsnapple:0.5 peanut:0.4 hotdog
2012-06-17,182.6,grape meat pistachio:5 peanut:5 cheese sorbet:5 orangejuice:2
# and so on ...

當時只是記錄，並沒有刻意減肥：

I was not dieting at that time. Just collecting data.

剩下的就跑分析直接拉出哪些行為的幫助最大，於是就有這張圖了：

Humble Bundle 對抗信用卡盜刷的方法

Humble Bundle 說明他們如何對抗信用卡盜刷的方法，主要是不斷的降低風險，然後讓人介入的機會降低 (因為人事成本很高)：「How Humble Bundle stops online fraud」。

其中第一點是特別想提的：

Our first line of defense is a machine-learning-based anti-abuse startup called Sift Science, which we’ve been training for years across 55,000,000 transactions. Given how many orders we process, Sift Science has a really good idea when someone is up to no good. The model adapts daily as we get more data.

Sift Science 在 2014 的時候提過：「偵測信用卡交易是否為盜刷的服務」。做的事情很簡單，你把大量的資料傳給 Sift Science，包括了各種使用者身份資訊，以及信用卡資料，Sift Science 可以透過 Machine Learning 的方法告訴你這筆交易的風險，讓你進一步的判斷。

其實不少家都有做類似的服務，像是 MaxMind 的 minFraud (就是做 GeoIP database 很有名的那家公司的另外一個產品)。當交易量很大的時候是個很有趣的應用，降低處理盜刷後續處理的成本。

Facebook 大量蒐集 GPS 定位資訊後用機械學習「猜測」你可能認識的人

在 Bruce Schneier 這邊看到「Facebook Using Physical Location to Suggest Friends」這則文章，引用自「Facebook is using your phone’s location to suggest new friends—which could be a privacy disaster」這篇報導，報導開頭寫著更新的資訊：

Update (June 28): After twice confirming it used location to suggest new friends, Facebook now says it doesn’t currently use “location data, such as device location and location information you add to your profile, to suggest people you may know.” The company says it ran a brief test using location last year. New story here.

跟 Facebook 第二次確認後發現是標準的「啊！靠腰！是 PR 災難」的處理方式。在第一次跟 Facebook 確認時，Facebook 發言人的正式回覆說明了手機的位置是計算的條件之一：

“People You May Know are people on Facebook that you might know,” a Facebook spokesperson said. “We show you people based on mutual friends, work and education information, networks you’re part of, contacts you’ve imported and many other factors.”

One of those factors is smartphone location. A Facebook spokesperson said though that shared location alone would not result in a friend suggestion, saying that the two parents must have had something else in common, such as overlapping networks.

“Location information by itself doesn’t indicate that two people might be friends,” said the Facebook spokesperson. “That’s why location is only one of the factors we use to suggest people you may know.”

靠背...

RAID 卡的電池維護

實際的世界都是由 workaround 疊 workaround 解決問題的...

MySQL 資料庫一般都用 RAID 10，利用 RAID 1 的特性保護資料，並且利用 RAID 0 的特性提昇 IOPS 能力。

而這些 RAID 卡通常都會提供 cache，預設應該都會開 read cache，可以大幅增加 random read 的速度。而另外也可以打開 write cache (也就是 write-back)，寫入時先寫到 cache 裡，RAID 卡馬上就會跟作業系統回報完成，藉以加速 random write 的速度。

但這樣就會有風險，當資料還沒寫入硬碟就斷電時就會遺失資料。所以在設定 write-back 的 RAID 卡上安裝電池就變成解法之一。

而電池會有壽命問題，所以配電池的 RAID 卡會每隔一陣子就放電測試電池可以撐多久，但在放電測試時，如果斷電就有可能造成資料遺失，於是又冒出很多方法解決。

也就是在「Learning to Deal With Learning」這篇提到 RAID 卡電池維護的事情。

每一層都是 workaround 想辦法解決問題，然後再用 workaround 解決前面造成的問題...

Anyway，有幾種解法，其中仍然對上層作業系統與應用程式透明的解法是：

  • 雙電池架構，很明顯的可以一次只測一顆。
  • 改用 NVRAM，就不需要電池了，不過速度以及成本會是另外一個問題。

另外，對上層作業系統與應用程式有影響的方式：

  • 放電測試時將 write cache 關閉，切回 write-through。這點在原文裡也有提到，效能其實會受到蠻大的影響。
  • 不放電測試了，但這樣的缺點就是拿安全性交換，當斷電時不知道能不撐過去。
  • 或是自己控制放電測試的時間，這可以配合上面切回 write-through 的方式，挑負載比較輕的離峰時間做。

看了下來雙電池架構還不錯，增加的成本還算可以接受，而且因為效能不受到影響，也確保資料安全性，整體維護起來比較簡單。而之後在規模更大的時候，應該就會直接考慮跳到自己放電測試的方式來處理電池問題...

Machine Learning 的課程 (2013 年一月開課，已經完結)

在「推薦系統的課程...」這篇推薦了 2013 秋天的課程，不過整理舊文章的時候發現有另外一門講 Machine Learning 的課程已經結束 (不僅僅是 Recommendation System)。

CMU 的課程：「Introduction to Machine Learning」，課程都有 PDF slide 與錄影可以看。

相較於推薦系統，機器學習的課程比較篇理論，而且也比較廣泛，而推薦系統比較偏應用。