← Career advice
Advice Columnist

天文台的理想與現實

香港天文台的預測經常令你失望?是你的心理作用,還是這台的預測真的有偏差?

我們會在有誤差的時候埋怨,但天文台也可以為自己辯解,聲稱其他日子其實也很準確,到最後雙方都好像不夠說服力。這一回,我決定利用 Web Scraping,配合 d3.js ,透過 Visualisation 和數據,讓大家都把誰是誰非一眼看通透!!!(如對程式沒有興趣,可直接拉到最後看結果)

十年不更新的格式

很多朋友初學 Web Scraping,多半都是到天文台抓取資料。而筆者則在十多年前已經開始嘗試抓取天文台的資料,為自己的桌面作一個小型「我的天文台」。

不過,每一位曾經抓取天文台資料的朋友,必然會發現,香港天文台的資料並不方便電腦處理。天文台在自己的網站 (https://rss.weather.gov.hk/rss_uc.html) 和政府的「資料一線通」網站 (https://data.gov.hk/) 都公開了讓程式讀取的資料位置,但你能夠拿到的東西,卻與「純文字版」沒太大分別。例子如下:

 

<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet href="flwc.xsl" type="text/xsl" ?><rss version="2.0">
<channel>
<title>本港地區天氣預報</title>
<link>http://www.weather.gov.hk/wxinfo/currwx/flwc.htm</link>
<description>本港地區天氣預報</description>
<language>zh-tw</language>
<webMaster>[email protected]</webMaster>
<copyright>本檔案的內容,包括但不限於所有文本、平面圖像、圖畫、圖片、照片以及數據或其他資料的匯編,均受版權保障。香港特別行政區政府是本檔案內所有版權作品的擁有人。</copyright>
<image>
<url>http://rss.weather.gov.hk/img/logo_dblue.gif</url>
<title>本港地區天氣預報</title>
<link>http://www.weather.gov.hk/</link>
</image>
<item>
<guid isPermaLink="false">
      http://rss.weather.gov.hk/rss/LocalWeatherForecast/20190503000000</guid>
                        <pubDate>Thu, 02 May 2019 16:00:00 GMT</pubDate>
<title>香港天文台於2019年05月03日00時00分發出之天氣報告</title>
<category>F</category>
<author>香港天文台</author>
<link>http://www.weather.gov.hk/wxinfo/currwx/flwc.htm</link>
<description><![CDATA[
一股清勁至強風程度的偏東氣流昨日影響廣東沿岸。本港昨日多雲,早晚有幾陣驟雨,新界多處地區錄得超過5毫米雨量。預料該偏東氣流會在今明兩日繼續影響廣東沿岸。<br/><br/>
本港地區(五月三日,星期五)天氣預測:<br/>大致多雲,有幾陣驟雨。日間驟雨逐漸減少,短暫時間有陽光。氣溫介乎21至25度。吹和緩至清勁偏東風,離岸間中吹強風。<br/><br/>
展望: 星期六部分時間天色明朗,亦有一兩陣驟雨。隨後數天驟雨增多及有狂風雷暴。 ]]></description>
</item>
</channel>
</rss>

 

這個模樣的報告,根本和電台的講稿一模一樣!我們用程式沒辦法輕易找得出會下雨或是不會下雨,還要用 XML 格式,對於某些初學者來說,可能比在純文字版本找東西更多了一重處理 XML 的障礙,尤其近年來,XML 在一般大眾中的應用越來越少。

幸好,天文台使用的字眼十年如一天,我發現每逢天文台預測下雨的時候,總會以「有…雨」來形容,或者提及最挑動大家情緒的「狂風雷暴」。例如「稍後時間有幾陣雨」、「早晚有一兩陣驟雨」或「有狂風雷暴」。於是,我們便可以利用 Regular Expression,把這些字眼,以一兩行程式碼便抽取出來:

 

let match = result.forecast.match(/本港地區今日天氣預測:<br\/>(.*?)<br\/>/);
let heavyRain = match[1].match(/狂風雷暴/)
let rain = match[1].match(/有[^有雨]*?雨/)

 

我們把這四個月的資料整合,發現天文台只有四種形容方法:「有微雨」,「有驟雨」,「有雨」和「狂風雷暴」。

玩更多 Regular Expression: https://regexr.com/

歷史預測

既然有了方法拆解預測,那麼過往的預測又能怎樣拿到呢?

一般來說,如果沒有在過去的時間把資料儲存下來,那麼過去的資料就找不回來了。也是說,若然沒有其他來源之下,你希望找回過去每一天的天文台早上預報,是沒有可能的,你唯有從今天開始每一日妥善儲存到自己的電腦或雲端上。

那麼我們要不要等數個月才有結果?!不用怕,原來政府自 2017 年開始在 data.gov.hk 提供歷史數據,其實就是政府幫我們一直儲存著這些資訊,可以按每小時抓取過往四個月的天文台的天氣預報。

話說回來,政府的開放數據一直都是為人詬病,這次也不會令大家「失望」!在我們查找的過程中,發現兩個問題

  1. 縱然看起來數據是每小時記錄一次,但這個「每小時」的間距並不保證準確!正常時候是整點 (07:00, 08:00, 09:00…),偶然會失常早一分鐘遲一分鐘甚至誤差十數分鐘!(07:01, 07:47, 08:30…)
  2. 在找天文台數據時,2018-12-07 09:00 至 2019-01-01 08:00 的歷史記錄不見了,難道是那數十天負責的同事放假去了旅行⋯⋯?

 

所以,我們這次的調查只能覆蓋一至四月了。

實際的降雨量: 降雨量竟然有 API

來到這裡,我們手頭上已經拿到足夠的「天氣預報資料」,而實際降雨量方面,原本打算在「每小時降雨量」配合傳統的 HTML 拆解方法 (利用 cheerio 或 BeautifulSoup) 把每小時不同地區的降雨量抓下來。

不過,偶然發現原來天文台有一個「每日數據摘錄」,完整收集了自 1884 年起計的每一日的總雨量記錄。而且,這個頁面更是以 Client-side Rendering 的方式顯示,換句話說,即是資料來源是有 API 可攝取,大大方便了我們作分析工作。

只可惜預報方面缺少了部份歷史數據,更沒有以往年代的預報,否則我們更可以比較古今天文台的準繩度!(照道理應該是越來越準確吧!)

調查結果

萬事俱備,這次我們用 d3.js 把降雨和預測資料,用月曆的方式顯示出來。

從上表中可以看到,一月二月未踏入香港的雨季,實際上有雨的日子並不多。不過,苦口婆心的天文台,幾乎不間斷地提醒大家有微雨或驟雨,二月份更加只有七日沒有預報有雨。在「狂風雷暴」的警示下,只有 4 月 19 日達 75 毫米,其他日子的降雨量並不多,最極端的「狂風雷暴日」 4 月 26 日只有 0.9 毫米降雨量。似乎這結果和我們的想法都符合————天文台預測下雨但其實都不大機會下雨!

反過來看,雖然天文台經常令我們白白帶了傘外出,但在天文台預測沒雨時日子,幾乎全部都真的是沒雨和極微雨(只有 0.2 毫米)!即是說,如果你當天發現天文台的預測沒有提及任何「雨」的字眼,你可以十分放心把雨傘放在家中。

然而,只是數日子好像不夠科學。其實我們更可運用 Confusion Matrix 和統計數據,更清晰看得出以上的結論。

 

 

單單是看 Accuracy,我們能指出天文台的準繩度是 70%,但這樣的說法並不夠仔細。因為

Precision 的計算的方法是 (True Positive) / (True Positive + False Positive),即計算天文台預測有雨的日子中,有多少天是真的有下雨,而得出的數字是 0.57,換句話說即是 當天文台話有雨,只有 57% 機會真的下雨!

而 Recall 則是 (True Positive) / (True Positive + False Negative),即計算實際有雨的日子中,有多少天是天文台有成功預測到的,這次運算達到 94%,代表實際很少情況下,會在天文台沒有預測的時候下雨起來, 當天文台說沒雨,很少機會是真的下雨 。要留意的是,如果每天都說會下雨,其實 Recall 可以達到 100% 的。所以縱然有 94% Recall,配合 57% Precision 來分析,其實就是代表天文台總是偏向預測會下雨,讓大家「有備無患」。

後記:還有更多改良空間

今次為了簡化起見,把降雨量的資料依賴了「每日數據摘錄」,不過,假若降雨記錄只是發生在淩晨 00:00 至早上 08:00 這個時段,其餘時段沒有雨,而天文台又預計當天會下雨的話,其實也算是錯誤的預計!既然我們這次的調查,看得出天文台總是常常預測有雨(Precision 的比率十分低),假若剛才的情況(清晨有雨,日間沒雨)經常發生的話,這個統計是錯誤地推高了天文台的準確率呢!

還有,我們把 0.1 毫米或以上的雨量也當作是有下雨(幾乎是幾滴雨!),我相信帶了雨傘的大家一定不會認為天文台是預測準確。

所以,其實這次對天文台是手鬆了很多呢。

✦✦✦
不論是什麼年紀,追求自己所喜愛的事情而決定重頭開始並沒有錯。假如您希望投身於科技行業,讓GetLinks陪伴您走過路上的每一步吧!
GetLinks Recruitment

GetLinks Recruitment

GetLinks Recruitment 是一家全方位的人材招募公司。 自2015年以來,我們已經為亞洲超過20,000位人才找到了完美的匹配, 我們的 使命是為求職者和僱主提供一個高效 的 連接平台。 GetLinks Recruitment 迅速成為不少 公司值得信賴的合作夥伴,在全球多個地點設有辦事處,提供一個真正全球化的專業人士和企業網路。

Keep reading

Related career advice

【IT事務所】數位經濟與平台經濟:差異與對企業的深遠影響
Advice Columnist

【IT事務所】數位經濟與平台經濟:差異與對企業的深遠影響

在當今快速變遷的科技時代,「數位經濟」(Digital Economy)與「平台經濟」(Platform Economy)是兩個常被交替使用的名詞。然而,兩者在經濟學定義與商業運作邏輯上具有顯著的差異。對於企業而言,理解這些差異不僅是理論上的探討,更是擬定未來發展策略、因應市場挑戰的關鍵。 一、 數位經濟與平台經濟的差異 要釐清兩者的差異,我們可以從「宏觀」的經濟型態與「微觀」的商業模式來進行深入探討。 數位經濟是一個廣泛的總體經濟概念,涵蓋了所有依賴數位科技、數據化資訊與網際網路作為關鍵生產要素的經濟活動。它不僅包括純粹的網路產業,也包含了傳統產業的數位化轉型。只要是運用數位科技來提升效率、創造價值的商業行為與經濟體系,都屬於數位經濟的範疇。例如,一家傳統銀行開發了手機應用程式,讓客戶可以在線上完成轉帳與理財,這種利用數位技術提升營運效率的行為,便是數位經濟的典型展現。 相對而言,平台經濟是數位經濟中一個極具顛覆性的特定商業模式。平台本身通常不直接生產商品或提供實體服務,而是作為一個「中介載體」,利用數位基礎設施來媒合雙邊或多邊市場。在價值創造方式上,數位經濟關注技術如何提升生產力,而平台經濟的核心則在於「降低交易成本」與「創造連結」。延續前述的金融例子,如果一家企業建立的是一個P2P網路借貸平台(如LendingClub),它本身不擁有放貸資金,而是純粹媒合有閒置資金的投資人與需要借款的消費者,這就是平台經濟的運作邏輯。 平台經濟最顯著的特徵是「網路效應」(Network Effects)。在這種模式下,平台的價值會隨著使用者數量的增加而呈指數型成長。以叫車服務平台Uber為例,當平台上的司機越多,乘客的等待時間就越短;乘客體驗變好後,會吸引更多乘客使用,進而又吸引更多司機加入以獲取更高收入。這種跨邊網路效應在一般的數位經濟企業中並不一定存在,卻是平台企業爆發性成長的關鍵引擎。 此外,平台經濟徹底顛覆了傳統的所有權概念,轉向「資產輕量化」與「使用權」的共享。傳統的跨國連鎖飯店如希爾頓(Hilton)或萬豪(Marriott)需要耗費鉅資購買土地、興建飯店並雇用大量員工;然而,Airbnb作為全球最大的住宿提供者,本身卻不擁有一間客房。平台企業藉由調動社會上的閒置資源,以極低的邊際成本進行擴張,這是傳統數位轉型企業難以企及的優勢。 二、 平台經濟對企業的影響 平台經濟的崛起,徹底改變了傳統企業的競爭環境、成本結構與消費者期望。其對企業的影響呈現出強烈的雙面性,既帶來了前所未有的全球化機遇,也伴隨著嚴峻的生存與依賴挑戰。 商業模式的重塑與創新 : 平台經濟迫使傳統企業從「線性價值鏈」(即生產、行銷、銷售給終端消費者)轉型為「生態系統」思維。企業不再只是單純地銷售產品,而是轉向提供服務、體驗,甚至自己轉型為平台。例如,全球知名的農業機械製造商約翰迪爾(John Deere)不再只是一間賣牽引機的公司。他們將設備連上網路,建立了一個農業數據平台,讓農夫、種子供應商與軟體開發者可以在平台上共享天氣、土壤與作物數據,成功從傳統硬體製造商轉型為平台生態系的管理者。 降低市場進入門檻與全球化擴張 : 對於新創公司與中小企業而言,平台經濟大幅降低了接觸消費者的門檻。過去,一個在地工匠或獨立設計師若要將產品賣到國外,需要耗費巨資建立實體通路、尋找代理商或建置昂貴的跨國電商網站。如今,透過如Pinkoi、Etsy或Amazon等大型平台,企業可以「隨插即用」這些現成的數位基礎設施與全球金流、物流系統,迅速將商品賣給全世界的用戶。這種便利性讓企業能將資源集中在產品創新與服務優化上。 競爭加劇與「贏者全拿」效應 : 平台經濟高度依賴數據與網路效應,這極易導致「強者恆強」的局面。當一個平台累積了龐大的用戶基數與數據後,其演算法會變得更精準,進一步形成跨越不過的護城河。例如在搜尋引擎領域的Google,或是社群媒體領域的Meta,因為其龐大的網路效應,後進者幾乎無法撼動其地位。這種「贏者全拿」(Winner-takes-all)或寡占的動態,意味著傳統企業若無法加入主流平台生態圈,或在其中找到無可取代的利基市場,將面臨被邊緣化的巨大風險。 高度的平台依賴風險 : 水能載舟,亦能覆舟。當企業過度依賴單一大型平台時,會喪失對定價、客戶數據以及品牌體驗的控制權。例如,許多餐飲業者高度依賴Foodpanda或UberEats等外送平台來獲取訂單,這不僅意味著必須支付高昂的抽成費用,更代表著他們無法掌握顧客的真實聯絡方式與消費輪廓。同樣地,許多依賴Facebook粉絲專頁獲取流量的新聞媒體與電商,只要平台演算法稍作修改,其觸及率與營收便可能面臨雪崩式的下滑。這種高度的依賴風險,是當代企業在擁抱平台時必須謹慎管理的課題。 數據成為核心競爭資產 : 在平台生態中,數據是最有價值的戰略武器。平台企業透過掌握雙邊用戶的行為數據,能進行極度精準的行銷與產品優化。這種資訊不對稱有時會對依賴平台的企業造成威脅。以Amazon為例,平台上累積了無數第三方賣家的銷售數據;當Amazon發現某款商品極度熱銷時,便可能利用這些數據推出自家的「Amazon Basics」自有品牌產品,以更低的價格與更好的搜尋排名與原本的賣家競爭。因此,傳統企業在利用平台的同時,也必須設法建立自己收集第一手數據(First-party data)的渠道,以維持長期的競爭力。 三、 結論 數位經濟為我們勾勒了技術賦能的廣闊藍圖,而平台經濟則是這幅藍圖中最具爆發力與顛覆性的引擎。透過豐富的實際案例可以看出,面對平台經濟的浪潮,現代企業不能僅僅停留在「將現有業務數位化」的階段。企業必須深入理解多邊市場的運作邏輯與網路效應的威力,思考如何巧妙地融入現有的平台生態系,妥善管理依賴風險,甚至在特定的利基領域中構建屬於自己的微型平台,方能在這場沒有邊界的競爭中立於不敗之地。

【職場 Hacker】PATH 框架:如何規劃職涯路線圖
Advice Columnist

【職場 Hacker】PATH 框架:如何規劃職涯路線圖

「以下故事,純屬虛構,如有雷同,實屬巧合」 Mia 是一位 28 歲的設計師,工作 5 年後,她感到迷茫。 「Kenneth,我不知道我的職涯要往哪裡走,」Mia 說。「我該繼續做設計,還是轉管理?」 「你需要一個職涯路線圖,」我說。「PATH 框架可以幫你。」 什麼是 PATH 框架 PATH 是 MAKER 層中的 Map(PATH)模組,專門用來規劃職涯路線圖。 PATH 代表四個步驟: – Purpose(目的):釐清你為何而做、想成為什麼樣的人 – Ambition(野心):定錨你願意追求的高度與標準 – Terrain(地形):辨識產業與角色的地形與通路,放大能力的用武之地 – Horizon(視野):拉高與拉長視野,規劃長短期里程碑與能力組合 Mia 的 PATH 規劃 我用 PATH 框架幫 Mia 規劃職涯路線圖: P – Purpose(目的) 第一步是明確定位。我問 Mia:「你想成為什麼樣的人?」 Mia 思考後說:「我想成為一位設計主管,能帶領團隊打造產品。」 我幫她設定三個階段的里程碑來對齊這個目的: – 短期(1 年):資深設計師,能獨立負責產品設計 – 中期(3 年):設計主管,能帶領 5 人團隊 – […]

【職場心理學】為何你費盡心思解釋產品的好處,客戶卻依然不買單?
Advice Columnist

【職場心理學】為何你費盡心思解釋產品的好處,客戶卻依然不買單?

你準備了詳盡的產品資料,邏輯清晰,圖表精美,能夠解答客戶幾乎所有的技術問題。 但到最後,客戶還是說:「我再想想。」 曾有學員在人際溝通實戰班下課後走過來問我:「YY姑娘,我每次見客都準備得很充分,解釋得也很清楚,為什麼對方還是遲遲不決定?是不是我說得還不夠多、不夠詳細?」 我沒有立即回答。我先問了他一個問題: 「你上一次成功的交易,你究竟是講了很多,還是聽了很多?」 他愣了一下。 問題不在於說得太多,而在於說話的方向 有一種常見的誤解,認為頂尖銷售員之所以成功,是因為他們能說、敢說、說得好。這個觀察並不完全錯誤——但它掩蓋了一個更核心的事實:說得好,不等於說得多,而是說出了對方心裡已有、但尚未能表達的話。 心理學研究早已指出,當人感到自主決策的空間被壓縮,即使對方說的是事實,大腦也會產生反射性的抗拒——心理學稱之為「心理抗拒」(Psychological Reactance)。你越是努力說服,對方越是想逃離(Brehm, 1966)。這不是客戶刁難你,而是人類大腦面對壓力時的本能保護機制。 與此同時,認知負荷理論(Cognitive Load Theory)告訴我們,人的工作記憶容量是有限的(Sweller, 1988;Miller, 1956)。當一次性接收的信息超出處理能力,人的本能反應不是努力消化,而是逃避決策。 「我再想想」,很多時候不是真的需要更多資料,而是認知系統在說:「我已經無法再處理了。」 頂尖銷售員與普通銷售員的真正差異 我曾在決策心理學課中分享過一項研究:RAIN Group 對全球逾500宗成功銷售案例的分析顯示,客戶最常提及促成最終決策的因素,是「顧問讓我感覺被理解」,而非「顧問的產品知識豐富」(RAIN Group, 2018)。頂尖銷售員的傾聽比例,顯著高於一般銷售員。 換言之,頂尖銷售員與普通銷售員最根本的差異,不在於他們掌握多少產品知識,而在於他們說的內容,是否真正對應客戶內心正在思考的問題。 此外,行為經濟學的框架效應(Framing Effect)同樣值得關注。同一項保障或服務,以客戶自己的語言框架表述,與以公司的產品框架表述,所引發的情緒反應可以截然不同(Kahneman & Tversky, 1979)。客戶不是在購買一個產品,他們是在購買一個解決自己憂慮的答案。如果你的語言和他的憂慮從一開始就不在同一頻道上,解釋得再清楚,也只是自說自話。 四個值得誠實面對的指標 我有時會在人際溝通實戰班請學員對照以下四點,評估自己上一次的客戶對話: 解釋完之後,客戶問的是「這個對我有什麼用」——說明你說的,和他想知道的,從一開始就不在同一條線上。你無法用客戶自己說過的話來描述他的需求——說明你從未真正聽進他所說的。講解中,超過一半的內容是關於產品功能,而非針對他表達過的特定憂慮。同一個客戶,你需要不只一次從頭解釋同樣的東西——說明上一次,他根本沒有吸收,因為那不是他關心的問題。 這四點,不是用來批評任何人的。這是一個誠實的鏡子。 真正的問題,從來不在資料量 很多銷售員在遇到瓶頸時,第一反應是「我需要更好的產品資料」、「我需要更有力的說辭」。但如果問題的根源在於對話的方向從一開始就走錯了,那麼更多的資料,只會讓客戶更快說出那句:「我再想想。」 你的客戶說過的話,你有多少是真的記得? 那些被你記住的細節,才是真正打開對話的鑰匙。 參考資料 Brehm, J. W. (1966). A theory of psychological reactance. Academic Press. Kahneman, D., & Tversky, A. (1979). […]

天文台的理想與現實 | CPJobs Career Advice