Browsing all articles from August, 2011
Aug
30

所謂集體智商

by CeShine

今天看到了某位網路人物寫了一篇關於集體智商的文章(爲了表示這件事完全不是針對個人,我也不指名道姓),我看了一遍之後覺得似是而非,之後一想才覺得有明顯的邏輯謬誤,赫然發現原來MBA的邏輯訓練也就只有這樣的程度,老實說頗為失望。

他的論述是這樣的,在商學院的課程上,老師將學生分組讓他們一起玩一個遊戲,參與者同時記錄了自己的答案和團隊的答案,最後老師公佈正確答案,統計結果發現個人分數的平均比團隊分數的平均高很多,而團隊答案的“綜合”(我也不確定是什麽意思)幾乎和正解一摸一樣,由於所有參與者都不是這個遊戲的專家,由此作者得出了群體智商比個體智商高的結論。

這樣的論述可以用一個反例來推翻,假設一個團隊裡有4個人,四個人的個人成績分別是100、0、0、0,平均25分,由於拿100分的成員A比較強勢,也可能另外三個人B、C和D自己也知道自己完全不會,所以團隊的答案有80%是採用A的,所以團隊得分80分,這個情況完全是在原論述中合理的(雖然作者說明了參與者都不是專家,但是他沒有提出任何具體數據來證明這個說法,比如說個人成績的最高分還是低於團隊分數的最低分),所以我們就可以說這四個人和在一起比他們各別每個人都聰明嗎?顯然不是,僅僅是三個笨蛋把一個天才的智商給拉低了而已,作為老闆正確的決定當然是把這三個笨蛋都開了。

我在另一本書上看到一個類似的遊戲,但是參與者是一個公司中的主管和其下屬,研究者先偷偷把正確答案給了這些下屬,由於這些主管都聲稱他們經常聆聽並接受下屬的建議,我們預期最後團隊的答案會和正確答案幾乎一樣;但結果是,沒有一個團隊的答案和正確答案沾的上邊。

我們不能由此就推斷一個天才的主管或是完全聽從下屬的主管才是這個遊戲的正解,但我們知道了一個不太聰明而且又不聽下屬意見的老闆只會帶來毀滅。所以,身為老闆的你,在宣稱自己只招A級人才之前,不妨先檢視一下自己是不是也具有A級人才的素質,不要發現招不到人的時候才在抱怨市場上沒有好人才,事實可能是,好人才根本不會出現在你面前,他們比你還有自知之明。

我目前最常用的“身體鍛煉”方法有三種:

  1. 某Google AppEngine代理軟體:我瞄了一下原始碼,應該是利用寫死一大串可互相替代的ip地址來解決Google AppEngine不斷被河蟹的問題。速度挺快的,但是由於Google AppEngine的限制有些功能並不支援,在這些狀況還是得藉助其他方法。
  2. SSH Tunnel (Tunnelier):  Tunnelier由於沒有某些限制所以比putty快,但是我手上的ssh服務器速度都沒有Google AppEngine快,所以我只是用來補強Google AppEngine。
  3. VPN:  在Linux裡要用apt-get,pip 之類的東西時用。由於在Linux裏面設定全域的proxy比較麻煩,VPN是快速的解決方法。缺點是VPN是全域的,如果看的是中國網站,連到美國然後再連回來實在有點荒謬,另外免費的VPN服務在高峰期不太穩定,據說付費的也沒好到哪裡去

另外我還用了foxyproxy和switchyproxy來減少不必要的代理使用。

昨天我思考了有沒有可能在天朝內架一個squid服務器,然後將請求加密轉發到美國的服務器(比方說一個免費的EC2 instance),以簡化鍛煉時客戶端的設定。但是我發現由於瀏覽器到squid服務器的HTTP請求還是明碼的,這個想法顯然相當愚蠢且在大範圍上不可行,只能用在比方說公司的內網裏面。但我倒是找到了一個不錯的方法來改進目前我手上的鍛煉手段,也就是利用haproxy這個負載均衡服務。

簡單來說就是在本地服務器上開好幾個ssh tunnel, 分別使用不同的ssh服務器, 然後用haproxy來建立一個Socks5的前段,後端則是用負載均衡的方法在各個ssh tunnel間切換分流,如此一來有兩個好處:

  1. 充分運用手上頻寬:單個SSH服務器到你這裡的頻寬可能不到你的物理頻寬上限,好幾個服務器加起來應該是綽綽有餘。
  2. 依據狀況分配流量:如果某個SSH服務器的頻寬較小,可以按較小的比例分配流量給它。
  3. 簡化客戶端設定:客戶端電腦上不用再開Tunnelier或Google AppEngine代理的client了,只要設定瀏覽器的socks代理就可以。

如果在你的內網中有個Ubuntu的服務器或虛擬機,haproxy應該能很大程度上的緩解身體鍛煉的痛苦。

Read more »

最近的文章

最近的回應

文章分類

文件櫃

統計

cPanel Reseller Hosting