顯示具有 data analysis 標籤的文章。 顯示所有文章
顯示具有 data analysis 標籤的文章。 顯示所有文章

1/11/2017

企業巫醫 - 統計與謠言



In god we trust all others bring data 

  -  W. Edwards Deming (全面品質管理TQM之父)


網路讓資訊傳播成本降到極端的低,同時也讓資訊品質降的極端的低。

謠言的成因有非常多。有些僅只是美麗的誤會,例如:十幾年前開始流傳的泰戈爾的詩。有些則是恐嚇類型的無風起浪,例如:誠品可怕迷魂盜泰國罐頭。有些只是試圖吸引人目光的搞笑惡作劇,例如:裝翅膀飛起來

最糟糕的類型,莫過於以「統計數字」造出看似符合邏輯的謠言。並且,從這樣的謠言中獲得利益。


許多時候,數據本身難以查詢正確性。而且由數字導引出的邏輯,更容易因人而異,因地制宜。從數字所引導的偏誤,有時候甚至比單純的謠言還可怕,因為它可能會在網路上留存多年,難以辯證。如果只是單純搞笑也就罷了,如果個人或者組織,以這類型的資料來作為決策的判斷依據,那下場可能非常慘。錯誤的資料,比沒有資料更糟。


不過,只要稍微留意,加上合理的好奇心,統計謠言是有機會判斷其可能性:


(1) 不解釋的數字


在各類文章或研究報告中,為求精簡,只會根據重要數字做衍生推論。然而,數字背後通常還有「未解釋」的數字,而這個數字可能更為重要。

企業僅21%的需要大學以上學歷為例。這篇文章,簡單說明勞動部的調查,僅有21%的企業需要大學以上的學歷。然而,這個數字有很大的問題。

也許,該調查隨機抽了100個企業主,其中只有21個企業主宣稱需要大學以上學歷的員工。

也許,該調查抽樣了企業主的「100個正在招募工作職缺總數」,這100個職缺中,只有21個是需要大學學歷。

這兩者有極大的差距。前者,可能這21個企業主,所需要員工數量高達2萬人,而另外79個企業主,所需員工只要79個人也說不定。而後者,正在招募的職缺,和「已經在職」的學歷也並未顯示。而單就此推論,僅21%企業需要大學學歷基本上過於簡化。

所有經過簡化,而沒有附上數據的真實來源的推測,其解釋很容易被扭曲。然而,被扭曲的解釋,當然比較有戲劇性,比較容易被注意。

勞動部網站根本也找不到這份調查。

此外,很多政治性民調也是屬於此類,涵蓋許多不解釋的數字。



(2) 接近完美的不可能


網路上流傳一份超過十幾年的Dr Ephrem Cheng研究顯示,越早退休壽命越長。(參考這裡這裡這裡)  

這份數據流傳非常之廣,被引用次數非常多,每隔數年也會在通訊軟體上流來流去。最近當然就是LINE上流傳的長輩文。

上面提供了一份數字,是退休年齡跟「壽命」的對照表如下。


retirelife
49.986
51.285.3
52.584.6
53.883.9
55.183.2
56.482.5
57.281.4
58.380
59.278.5
60.176.8
6174.5
62.171.8
63.169.3
64.167.9
65.266.8

不會統計的人也可以看出,在這個表中,越早退休,壽命越長。如果49.9歲就退休,那麼可以活到86歲。65.2歲才退休,就只能活到66.8歲。

以相關係數簡單計算,他的相關程度高達-0.96,換言之,這是一份極為完美的負相關數字。

這種過度完美個數字,應該要看研究論文的細節加以瞭解。例如他的樣本有多大?是什麼時候做的研究。就可取得的事實來看,他的樣本很小,並且研究的時間幾乎可以肯定在1990年以前。由於上述的年紀追蹤到80歲,所以研究對象大概是1930-1950嬰兒潮時代的人。

最重要的是,這些數字並非真實研究論文,卻在很多人的轉貼中,莫名其妙的被冠名「美國權威學者」。


這份研究數字會流傳很久的原因,是他剛好契合 (1) 這看起來是個學術研究 (2) 可以被直銷,財務規劃,人生規劃等等產業拿來利用 (3) 可以有趣的解釋它

除此之外,別無他因。雖然已經有些人發現不對勁,例如這裡。但是許多第一次看到此研究的人,仍然不明究理的轉貼。

如果想知道實際的退休年齡和生存年齡的相關性研究:請參考這篇研究。該篇的結論就交由各位判斷,但至少它的研究方式,數字細節,都解釋得十分清晰。

我已經透過管道寫信給該研究者Dr Cheng,懇請取得確實的研究資料以及統計方式等細節(說不定他也是受害者?)。至今2017/Jan/11尚未收到回覆。


(3) 邏輯上的不可能


邏輯上不可能,或者簡單的說「數字兜不攏」。

中國的2010的地方GDP就是邏輯上的懷疑問題。因為 中國31個省份的GDP加總起來,竟然遠超過全國GDP,而且高過很多。這在邏輯上是不可能的事情,因此自然就有合理的統計造假懷疑。

類似的事情也容易發生在沒檢查,而且其實也不打算認真做統計的相關文章上,例如這裡。因為在許多時候,謠言只是想要造成吸引人的目的,其真實性不重要,當然就也不特別檢查數據。所以自己造成自己數據兜不攏,邏輯上不可能的情況並不少見。

這和前兩者不同,邏輯上的不可能,可以單就資訊本身的內容加以探索,或者是再加上一些事實根據來檢視。因此,比較容易看出謠言的真實性。




最後,稍微提醒一下:廣告的統計宣稱,其實難以查證。例如高露潔的「大部分牙醫師推薦」如果不是公平會主動進行查證,一般市井小民根本無法查證屬實與否。





12/28/2016

數據分析從零開始 - (4) 檔案儲存



數據分析的各階段,都有可能需要儲存檔案。而資料的來源,也有可能是已經存在某處的檔案。

(非檔案儲存?參考註1)

越重要的資料,就得更重視儲存的方式。而越是大量複雜的資料,就勢必要對資料存儲做好預先的規劃。

雲端儲存 - 巨量資料


近年來流行的Cloud Storage,通常是將資料以網路上傳(註2)至某個雲端服務公司。最典型的例子是Amazon提供的S3服務。AWS S3因為使用者眾,以至於其的S3 rest http介面,甚至演變成某種標準。許多類似的服務,或者儲存廠商,會以「相符S3 rest api標準」當作重要的功能或賣點!(註3)

顯而易見,雲端儲存具有管理上的優點。理論上,不用擔心備份,擴充,網路,電力,硬體更換...等等營運上的問題。

然而,巨量資料雲端儲存也有幾個顯而易見的缺點

1. 錢:雲端儲存的費用並不便宜。單以S3為例,2016年的每1T資料光是「存著」的費用,一年就高達276美金,相當於8832台幣。這還未計算上傳下載等操作費用。倘若要進行「長期保存」其費用相當驚人。也因此雲端儲存商針對長期保存的檔案也提供比較便宜的方案。然而,仍然是某種成本。然而,自行巨量儲存也要考慮費用,特別是

2. 營運:單純僅只使用雲端儲存,對整體營運的好處有限。並且,企業還是需要自行考慮檔案的有效使用問題。

3. 移轉:儲存到雲端之後,一旦量變大,很難轉換營運商。



雲端儲存 - 少量資料

至於極少量資料,例如10G之內。無論是企業或者是個人,都可以取得幾乎免費的儲存空間。

但也因為是免費空間,不太可能保證資料不會遺失。可是非常適用於新創公司,或者SOHO族。

最好是利用兩個以上的雲端儲存服務,儲存重要的檔案。

例如:利用googledrive + yandex.disk 儲存重要的檔案。這樣幾乎可以確保檔案不會因為單一基礎建設有問題,而導致重要檔案遺失。(註4)

實際作法:

(1) 尋找適當的工具或API,用以一次性整合這兩個雲端儲存

(2) 設定自動化方式,或者撰寫自動化程式

(3) 定時執行自動化備份,同時備份兩份到不同的雲端服務

Yandex disk的範例程式(參考這裡)



自行儲存 - 巨量資料


企業組織非常有可能需要自行處理檔案儲存。無論是因為技術因素或者法律因素。

傳統上儲存會用硬體商的解決方案,近年來多了分散式檔案系統可以考慮。

自行儲存,一樣要考慮錢(費用),營運。

1. 錢(費用)

    - 硬體費用:必須考慮長期硬體維護的費用
    - 軟體費用:授權或者購買維護
    - 人的費用:必須使用假設的最大值!

2. 營運

    - 如何讓其他系統使用
    - 有問題的時候怎麼辦
    - 備份與災難復原 


傳統巨量檔案資料,是購買netapp之類的硬體解決方案,配合網路架構,讓企業的巨量資料有集中管理的地方。2000年之後,分散式檔案系統因為效率和成本的關係,慢慢變成另一個可行的選項。

早期使用分散式檔案系統管理者,要跨越比較高的技術門檻,這幾年分散式檔案系統日漸成熟,管理也越趨方便。常見的有:(這頁wiki上有詳盡的清單。)

(1) glusterfs
(2) ceph
(3) HDFS
(4) mooseFs
(5) mogilefs
(6) GridFS
(7) Lustrefs


這些分散式檔案系統各具特色,大部分都可以無償取得使用權。然而,有些需要額外的知識或技能才有辦法長期維護。

因此,如果可預期的資料量,以及資料存取技術與成本,小於硬碟技術的成長。使用分散式檔案系統不見得有利。

硬碟的技術符合約略的摩爾定律。在1996年,每1G的硬碟約127美金,2006年,每1G的硬碟價格為0.3美金,但是在2016年,每1G的硬碟價格已經小於0.03美金。(參考這裡

除了價格逐年降低之外,存取速度也是逐年增長。如果預期資料成長量並不高,其實單就更換更換同價格的硬體設備搞不好也就夠了。

然而,巨量資料的增長往往遠超過預期,尤其近年來大資料分析蔚為風潮的情況下,盡可能保留資料便於未來使用成為企業組織對資訊科技的期待。也因此,使用分散式檔案儲存的組織越來越多。

選用分散式檔案系統,必須考慮:

(1) 使用目的和環境條件
(2) 營運計畫
(3) 實際測試


考慮雖然需要詳盡,但是這些「考慮」都是為了配合實際運作。因此,按照上述的考量,擬定可以「每日」有進展的「逐步」前進的計畫,是讓分散式系統成功運作的最好作法。

舉個例子:

(1) 使用目的和環境條件:要能夠簡單擴增(scale-out),並且能利用現有已經存在的NAS/SAN,而且非常容易營運與維護。檔案不需要striping,存取效能一般即可。

(2) 營運計劃摘要:一開始預計使用12台機器,共48顆硬碟。未來一年可能擴增到20台機器,80顆以上硬碟。總資料量可能成長為120TB。僅有一位開發維運人員(devops)。

(3)實際測試:實際分別以4台VM測試過glusterfs, mogilefs, ceph, Lustrefs。其中以mogilefs最為簡單使用。





自行儲存 - 少量資料


少量檔案的儲存,仍然附著在其他系統上。例如email上的附件,版本控制系統,wiki上的附件等等。

大部分的組織,很少著重於少量資料的整體計畫。大多數僅只為「安全性」的規範。例如客戶資料不得外洩之類。實務上,完全依賴個人行為。

現在,大部分的作業系統,都已經可以對其下的檔案做全文檢索(例如mac finder),而也都支援某種程度的備份功能。




摘要



巨量資料少量資料
雲端儲存 錢, 營運, 移轉考慮 
(1) 自動化
自行儲存(1) 傳統NAS 
(2)分散式檔案系統
考慮 
(1) 傳統備份 
(2) 全文檢索 





註1:非檔案儲存有傳統的RDB(例如Mysql, Oracle), Document DB(例如Lotus Notes), 有比較新潮的nosql (HDFS, mongodb, couchbase)。 這目前不在本文的討論範圍

註2:通常是指http。不過由於ftp在2000年之前應用範圍真的太廣,所以還是有不少雲端公司會額外提供ftp介面。

註3:參考這裡 -> http://www.s3-client.com/s3-compatible-storage-solutions.html

註4:為何選擇這兩者?google當然是不用說,因為它的基礎建設相當完整。而yandex則號稱為俄羅斯的google,很明顯由於是俄羅斯最大search engine,大概不會和google採用重複的基礎建設,因此選用兩個截然不同的廠商,可以降低風險。

9/13/2016

數據分析從零開始 - (2)資料取得和前處理




既然要分析資料數據,自然要有資料數據才能分析。資料取得是必要的事情。

資料來源有很多種,取得並且事後處理的難易度各有不同。

但可以確定的是基本情況是:

1. 資料的時間,會遠超過自己的想像

2. 在開始進行分析之前,資料整理的所花的時間精力,也會遠超過自己的想像

3. 資料整理,幾乎不可避免

4. 資料整理,沒有捷徑也沒有神奇的密技,只能靠不懈怠的努力耐心以及經驗

5. 實際上有創意,有價值的數據分析,都不能免除資料取得和整理。 



第一手資料:


在「嚴格的一手資料」定義下,做資料分析的人真的拿到一手資料的機會極端的少。不過如果你是購物網站的大老闆,則購物網站上產生的營運資料,web server的log等等,對你而言就是第一手資料。

實務上最常看到的第一手資料,應該就是網頁存取日誌(web log)。在2016年網頁伺服器市場上,apache加上nginx仍然佔了半數以上,其他的網頁伺服器種類雖然也不罕見,但網頁的log格式反倒似乎都很統一,因此,以網頁存取來說,資料取得跟分析都已經存在既有的工具。剩下就看規模和個人技巧。

其他類型第一手資料就包山包海,以業務來說,發票檔案(invioce)當然是貨真價值的第一手資料。以軟體開發來說,git上所有的commit log也是第一手資料。

以現在軟硬體的成本之低,第一手資料原則上都可以盡量保持「原來的樣子」,頂多保存的時候壓縮而已,不太需要進行破壞性過濾處理。

要點一:使用shell 做基本的確認以及雜訊處理。


mac或linux可以用的基本文字處理的技術太多。伺服器的log最基本的處理方式,應該先用shell快速瞭解一下現況。

舉例來說:

以下指令可以把access.log中的第11欄,http response code列出來,並且簡單統計一下各return code的次數。


#cat access.log | awk '{print $11}' | sort | uniq -c
以上圖來說,結果就是有3個http return 400,有134個return 200,沒有任何500的回傳值。至於什麼是http return code,請參考w3規範

要點二:用excel做最基本統計檢視


過去許多excel版本都有筆數的限制(最多六萬五千多筆),2013之後就放寬很多(大約一百萬筆),請參考官方網站

即便有數量的上限,也非常值得資料中,先擷取樣本來試著分析。使用樞紐分析表,可以很快看到資料欄位彼此可能的關係,在未來進行分析時候是很有用的參考。

如果到現在你還不知道什麼是pivot-table(樞紐分析表),那表示你根本不懂excel。  怎麼使用樞紐分析,請參考官方網站的說明。下一篇,我們會用政府公開資料簡單做個樞紐分析表。


要點三:以自動化的方式產生濃縮的摘要(二手資料)


只要能取得第一手資料,盡量使用自動化方式,自動產生有意義的濃縮摘要,這個摘要就算是二手資料。

當然,這要配合要點一的shell文字處理,例如以下指令:


#cat access.log | grep "GET /login" | awk '{print $6}' | cut -d ":" -f 1 | sort | uniq -c

這可以產生簡要報告,說明登入(login)頁面每天有多少人次來使用,執行結果如下圖:

這圖上的執行結果顯示,9/12有15個人次,而9/13有2個人次。


現存二手資料的資料


所謂二手資料當然就是不是直接產生資料的來源的資料。資料分析採用二手資料的機會非常高。

所有組織外部取得的資料,絕大部分都算是二手資料。因此在下一節中會特別說明外部資料的取得處理。

要點一:取得過程的紀錄,以及基本分析


無論資料是自己拿或者這別人給,都需要紀錄取得的過程。

舉例來說,如果IT「自動」會給你一份,wifi的使用者登入時間,以及最後封包產生時間,你就需要有方式「自動」記錄這個過程。

如果是外部網站,也應該要記錄當時取得的方式,假設是curl取得,則用了哪些參數,執行多少時間等等。

基本分析則和前一節相同,先用shell和excel對資料有基本理解。

要點二:正確性判斷


二手資料很可能不正確,或者,對資料的解釋不正確,會大幅影響資料的使用方式。

資料解釋不正確:舉例來說,只要有用過就知道,政府公開資料很多都宣稱編碼是utf-8,但實際根本就是Big5(例如 房地產實價登陸)。

資料不正確:二手資料取得的資料本身判斷正不正確很困難,特別是在大規模的資料收集下,很難簡單判斷正確與否。而且有些資料的正確性,可能連第一手資料來源都不能保證(例如天氣觀測)

但是可以透過「多面向」的方式來探究單一資料的正確性。簡單的說就是多找幾種資料來交叉比對。舉例來說,如果你的天氣資料來自不同的網站,如下兩個圖:



雖然這兩個圖在同一個時間點的氣溫還是差了兩度,不過起碼是一個合理的範圍,因此大致還能知道資料是合理。

要點三:自動化進行轉換格式以及二次儲存


二手資料無論是什麼格式,幾乎都會被轉移格式,或者合併,或者改換儲存媒介。例如csv檔案,常常就被改為json格式並且存進nosql中。

但重點是要「自動化」進行。雖然格式轉換或者改變儲存的形式,幾乎都有現成的工具可供匯入匯出,但是只要太多「人為手動操作」,都會讓資料處理越來越花時間,越來越難保證整個流程的品質。


外部取得資料



9/05/2016

人工智慧的淺顯應用 - 製作Facebook或Line聊天機器人

自2022年有chatgpt之後,原本的fb聊天機器人已經停止使用。新的聊天機器人使用chatgpt, 想要試用的,可以email聯絡:consultant.3rd@gmail.com



聊天機器人(chatbot)並不是什麼新鮮事,早在1950年間圖靈(註一)在提出關於人工智慧判別方式時,就提到利用文字訊息 - 因要把人和機器分開 - 來和兩個對象聊天,其中一個對象是人,另一個對象是電腦,如果一個正常人在聊天的過程無法區分這兩者誰是電腦,誰是人,則可判別這電腦程式,是真正擁有智慧。

要達到這個目的難上加難,在wiki上可以看到目前僅有在2014年一個名為Eugene Goostman的聊天程式通過這個測試。

目前可取得的人工智慧演算法或相關技術都沒有太驚人的發展。然而,由於網路上的資料取得越來越容易,電腦執行速度越來越快,以致於不需要有驚人的技術能力,也不需要有對人工智慧會不會變成奴役人類的電影劇情的深思,就可以開發出有意義的應用。


Facebook聊天機器人也是其中之一。

商家,企業,甚至某些個人都擁有FB page (粉絲頁 專頁),而從2015年開始,facebook開始出現具有固定反應或者訊息回應的聊天程式。不過台灣似乎比較少見非特定用途的聊天機器人,因此我們就做了一個在粉絲頁上。參考下圖:


https://www.facebook.com/sandy4ai/ 具有人工智慧聊天的粉絲頁

這個聊天機器人會回應你的訊息,根據她內建的知識庫和基本的語意分析,會回應你訊息。當然,她也會慢慢學習對話,這個聊天程式並不會需要額外的facebook權限,因此她沒有太多額外的功能。下圖是聊天實況範例:



和具有人工智慧聊天的粉絲頁聊天


Line在今年(2016)也開放bot api,作法和Facebook幾乎很雷同。不過雖然都是webhook,他們的api實際傳遞內容當然完全不一樣。

Facebook/Line 聊天機器人的可能應用:


1. 基本客戶問題:

企業組織在網路上最常「被」查。查詢營業時間,查詢電話,查詢服務項目等等。在台灣,這幾年用facebook來做生意來越頻繁,而聊天機器可以提供24x7的基本回答問題服務。

2. 促銷活動:

聊天機器人在某些權限下,可以主動傳遞訊息,或者貼文給facebook使用者。這和一般廣告貼文有些許不同,因為貼文之後,使用者可以持續和貼文者 - 也就是聊天機器人互動。

3. 例行客戶服務:

預約預定,提醒預約,服務調查,生日賀卡貼文等等。




如何製作Facebook臉書聊天機器人:



1.摘要步驟

  (1) 到AWS開設帳號。 開發過程會用到Lambda, API Gateway, elasticsearch, s3 cloudwatch 等服務。

  (2) 到facebook建立facebook app。(簡稱 fb app)

  (3) 新增並撰寫基本的Lambda 以回應 之後fb app webhook時的GET驗證。

  (4) 新增撰寫基本的Lambda 以用在 接下fb app message hook回應

  (5) 新增 API Gateway 的GET/POST,對應到Lambda

  (6) 設定fb app 的webhook 對應到API Gateway的URL
  
  (7) 讓fb app的設定頁verify(基本上就是http  GET) API  Gateway

  (8) 讓fb app設定頁訂閱message 並記得在lambda程式回覆訊息時使用page token

  (9) 此時可以進行知識庫的連結,在AWS建立elasticsearch並且匯入經過程式處理的資料,這裡我們以台灣e院資料為範例。

   (10) 修改lambda程式,讓使用者的訊息,在elasticsearch查訊相關訊息,並且回復給原送訊息者

   (11) 至此完成,其結果大致如下圖:



2. 詳細步驟:

    ....<待續>...


如何製作Line聊天機器人:


1.摘要步驟

  (1) 到AWS開設帳號。 開發過程會用到Lambda, API Gateway, elasticsearch, s3 cloudwatch 等服務。

  (2) 到line developer建立帳號以及channel。

  (3) 新增並撰寫基本的Lambda 和 api gateway 用以回應之後在line的channel上link時的驗證。Line的api基本上只用到POST

  (4) 將自己的line帳號 加入剛剛自己增加的channel。就是設好友的意思,這樣才能測試

  (5) 將line channel所需要的api key, secret以及token設定在lambda 要傳回給line bot api的地方。

  (6) 此時可以進行知識庫的連結,在AWS建立elasticsearch並且匯入經過程式處理的資料,這裡我們以台灣e院資料為範例。

   (7) 修改lambda程式,讓使用者的訊息,在elasticsearch查訊相關訊息,並且回復給原送訊息者

   (8) 至此完成,其結果大致如下圖:


2. 詳細步驟:


    ....<待續>...



參考: https://www.facebook.com/sandy4ai/ 

 註一:Turing 就是電影模仿遊戲的主角
 註二:詳細步驟還沒有時間寫...反正不見得有人需要:)

9/02/2016

數據分析從零開始 - (1)事前準備



當你打算從零開始,變成一個有足夠能力的資料工程師,一開始會需要準備基本工具。而隨著時間過去,自然而然你會瞭解並且學習到更多工具。

在此提供簡單的確認清單(Check List),讓在打算開始學習並應用數據分析時的準備參考。

1. 電腦


既然是資料分析,電腦自然是必備工具。

最推薦的是Mac的notebook,如果沒有太大的經濟壓力,最好買記憶體越大的越好。13吋MacBookPro,RAM 16G價格大概四萬八。其他可以考慮dell的linux desktop


選用Mac或者OS為Linux的電腦有許多原因,內建的終端機(terminal)可在bash等環境快速執行各類型資料處理的前期工作。現在windows也有powershell,並且至今技術工程師在對比unix/linux的shell時,常常會有各種爭論。

不過,就打算從零開始的數據工程師,別想太多,就選unix/linux吧!

2. 作業系統


無論你的電腦是桌上型還是筆記型,無論他原本是什麼作業系統。你都需要一個Linux作業系統。在MacOS上可以安裝VirutalBox或者VMware來執行Linux虛擬機器(VM)

3. 基本知識技能與其標準


雖然說是基本,但真要搞定以下知識與技能需要很長的一段時間,就從零開始的情況而言,「盡你所能」的了解以及練習是不二法門。


(1) Linux基本操作:在終端機(或者Shell)中,完全了解以下幾圖中的指令的意義:
(圖一)


   (圖二)

   (圖三)

(2) 網路工具自我學習與操作:能有耐心的看完這篇AWS CLI,並且能用AWS CLI上傳檔案到S3。在整個過程,僅使用官方文件,不在google上搜尋非官方說法。

AWS有提供許多免費工具,用在資料分析上非常適合。但是如果你有PB等級的資料,在AWS上做大數據分析是非常花錢的。

(3) 程式設計基本能力:利用python或任何程式語言,將台北市的住宅竊盜公開資料處理分析加總之後,列出各區的竊盜案件次數表。這裡要注意編碼(encoding)的問題。
如下圖:

(4) 英文閱讀能力:

其實英文閱讀能力對數據分析,甚至其他技術學習是非常重要的基礎。如果不習慣閱讀英文,而老是只查中文網頁,那麼就等於少了60%的網路知識存取。

如果對自己的英文閱讀能力有疑慮,可以先試著不查字典看完這本書:How To Read A Book,這本書用詞遣字相當簡單,而書的本身就是「增加閱讀能力」的方式。因為是本很老的書,應該很便宜,或許早已經沒有版權?