由於工作上長期都接觸緊 GenAI，第一下睇完條片嘅反應係：「個 Prompt 都未 Optimize 😂」

非學術 GenAI 一次性「公平」測試

見過好多非學術 GenAI 一次性「公平」測試，操作通常係用一個首選模型，前前後後改咗 N 次 prompt ，調整到出靚效果之後，再將個 prompt 放去其它模型「公平」測試，然後得出最後結論決定用哪一個模型，如下圖：

但現時 GenAI video generation 非常依賴 best effort prompt engineering，測試時冇 best effort 就只是 by chance，所以用 1 個 prompt 測試 N 個模型並不是理想測試方法，有極大機會改少少 prompt 之後，生成效果有顯著改善。

言而大部份模型設計或訓練時已經預設有說明書，介紹如何 prompt engineering best practice、解釋不同設定如何影響 generation，但始終人類時間有限，今天 generate 一條 6 秒 video 最少要幾分鐘，如果以下 8 個 GenAI tool 都試 30 次（改 prompt 改 config）嘅話，連同學習及應用 best practices，時間成本太高，不符合出 social post 成本效益。

相對公平方法？

每個 tools 都由「對應專家」花使用相同時間做 N 個 prompt

「對應專家」- LLM

「對應專家」現時最理想是一個 GenAI 再給它 prompting guideline + samples 學習，同時 parallel generate N 個 prompt 再 generate N videos，如下圖：

GenAI 沮喪的地方 - 找 Open Question 的答案

GenAI 時代最尷尬又令人沮喪嘅地方：「模型未必真係做唔到，只係個 Prompt/設定未調較得到。」換句話說，如要用 GenAI 解決一個複雜問題：

由揀模型到 prompt engineering，喺未做到之前都係一條冇正確答案嘅 Open Question。

用一啲 text-to-any 嘅 GenAI 工具，盡可能都會用 LLM generate 一啲 idea 或方向去解決一啲問題，再整合一啲 GenAI 工具說明書列出黎嘅 best practice 及 samples 去 generate 新 prompt。

未出發之前，對 AWS re:Invent 嘅印象就只係一個 Cloud 技術發佈會，今次遠赴美國 Las Vegas 親身感受過之後，不論場地規模到活動安排都與想像中大有不同，所以想以香港人嘅角度分享下整個體驗、反思以及技術心得，順道留個記錄俾自己。

根㯫官方數據，今次整個 AWS re:Invent 2024 Las Vegas 為期 5 日 2 - 6 Dec 2024 ，總共有 6 萬人參加，一共有 4000+ sessions。

AWS Hong Kong re:Invent re:Cap

AWS 香港團隊亦會於12月19日舉辦 AWS re:Invent re:Cap由 AWS 技術專家分享活動精華和介紹適合香港應用的新服務！

立即報名

場地規模

起初未做資料搜集之前，以為 re:Invent 只一個會展好大嘅場行黎行去睇 Expo。實際用上 5 個巨型場地搞（見下圖），完全唔同級數：

• Caesars Forum
• Mandalay Bay Resort
• MGM Grand Hotel (美高梅)
• The Venetian Resort (威尼斯人、Keynote 主場)
• Wynn Resort (永利)

場地之間嘅距離超過 2km，AWS 本身已經用哂大部份酒店嘅 event space，意想不到嘅係其它大嘅 AWS Partner 係週邊都包起整間餐廳做 private space、亦會 book 成層主場酒店客房（Suite 級數）做 meeting rooms 開會，世界各地 AWS Partner 以及其客戶都會聚係 re:Invent 見面，不單只一個純技術發佈會。

一 個 6 萬人嘅活動，究竟可以點安排？

Logistic

re:Invent 前一日，喺 Las Vegas 機場就可以拎 badge，避免當日大排長龍。

會場大部份主要通道都會有水牌大約指個方向去行，但因為個場真係太大，好難短時間靠水牌就有信心行到去目的地。

所以行人通道上可以話係「三歩一崗、五步一哨」一定會搵到身穿 Tiffany blue 顏色衫嘅工作人員。試過幾次就咁隨便行去過去問都解答到我點行去目的地，最深刻係有一位應該超過 60 歲嘅婆婆工作人員喺袋拎咗本筆記簿出黎對完再答我，感覺好有準備，唔係臨時拉夫。

會場過會場之間要搭 shuttle bus 來回，5 - 10 分鐘一班，每班通常都坐滿座再開。

後期發現 AWS event app 入面原來有 offline floor plan 以及 indoor positioning，仲可以直接 search by name，行 Expo 時搵對應攤位方便好多（見下影片）：

解決咗 logistic 之後仲有膳食要安排，今次應該係我第一次見過萬人嘅飯堂。

膳食安排

每間酒店都有一兩個場地食早餐及午餐，而威尼斯人(The Venetian) 主場嘅飯堂真係好誇張，一落去第一眼就見唔到盡頭（見下影片），食物質素就係正常平價自餐助質素，工作人員設定好嘅時間放人流去某個 zone，確保客人喺 zone 一定會拎到嘢食。

第二日去咗永利 (Wynn) 嘅午餐，場地係酒店宴會廳，環境上優雅好多。

早午餐前後，一啲多人聚集或者通過嘅地方都會有啲 finger food，補水補糖份。

最後一道難題：4000+ sessions 係咪要 4000+間獨立房？

開放式會場

最容易想象嘅設定都係每間房搞一個 session，而 re:Invent 則用上 quietevent 無線耳機，將一個大中小型宴會廳變成 6 - 20+ 個 sessions（見下影片）：

一啲 AWS featured session 亦佔用整個宴會廳，冇需要帶耳機。

基本上 4000＋ sessions 總會搵到啲啱心水嘅去聽，身在 event 當然唔只係坐係度聽，最難得可以親身接觸到行業 expert 問到啲 behind the scene 資訊，所以覺得個 session 啱聽就一定要試下搵 speaker deep dive 少少傾。

一個早 90 分鐘排隊都未必到嘅場嘅 Keynote

Keynote

AWS re:Invent 重頭戲一定係 Keynote 發佈會，最多技術發佈就係星期二 《CEO Keynote with Matt Garman》，我比預定時間早少少到已經入唔到場，問番其他出黎嘅人先知佢地早 90 分鐘開始排隊入場。

當日入唔到去發佈會主場，唯有係場外繼續聽，我整合咗一啲非常值得留意嘅發佈可參考《深刻的技術發佈會 - AWS re:Invent 2024 CEO Keynote》。

第二日 《Dr. Werner Vogels Keynote》冇咁爆場，早咗 30 分鐘仲入到去坐尾位（見下影片）。

今次 Amazon CTO Dr. Werner Vogels 分享一啲 20 年以來的 lesson learnt from Amazon，雖然係講經咁，但其中有一句好深刻：

Complexity can neither be created nor destroyed.
Only moved somewhere else – 15:04

Dr. Wener 用呢句帶出 intended complexity V.S. unintended complexity，說穿了就係有冇意識知道 complexity 所在的地方再有效地 abstract，令我諗起自己差不多 10 年前入行兩年寫嘅《行外人看不見的債務 - 技術債務》，如果而家我寫多一個相關主題，相信我有更多真實經驗可以分享俾後輩。

Expo

re:Invent 最後一個與技術相關係重頭戲就係 Expo，感覺就好似行年宵咁，差別就係變哂 technical demos、pain points、派 SWAGs，花咗兩日行咗幾轉，我粗略估計會場有超過 200 個 technical demos，而大部份嘅都與 GenAI 有關，就一啲主打 observability platform datadog 都有 GenAI integration。

2024 係一個 GenAI 技術急速成長年，成功發掘到 agentic 呢條路大幅提升準確度，同時又有新嘅 attention mechanism 及 AI 晶片大幅降低成本以及 inference 速度。而家最新 Amazon Nova Lite models on Amazon Bedrock 仲平過 OpenAI GPT4o-mini / Google Gemini 1.5 flash。

除咗 demos 之後，AWS 都展示咗好多硬件，包括

• 最新嘅 Trainium 2 UltraServers 將 4 隻 metal instance 駁通做 model training / inferencing
• 仲有 Graviton 1-4 代晶片，會見到粒晶片愈做愈大粒，代表良率控制得好好。
• 整棟 Amazon Outposts Rack(42U) 見影片

另外一啲未來感比較重嘅 AWS GenAI demos

• Hyper-personalized shopping experience
• Portfolio manager
• Mortgage manager

Conference first, Party next
呢啲 Party 就真係夜繽紛

最喜愛 Demo & After Party & 技術後記

待續... AWS re:invent 2024 的日與夜 - Las Vegas (下)

今次親身去 re:Invent 2024 睇實時發佈，發佈會有兩個位觸動到我聯想起港式 Meme「人類總是犯同樣的錯」、「我全都要」，見 storage、database、analytics、GenAI 都有新突破，分享一下幾深刻嘅新產品及功能。

AWS Hong Kong re:Invent re:Cap

AWS 香港團隊亦會於12月19日舉辦 AWS re:Invent re:Cap由 AWS 技術專家分享活動精華和介紹適合香港應用的新服務！

立即報名

突破一：幾何級數壓低 LLM inferencing 及 training 成本

由 Amazon CEO Andy Jassy 整個發佈過程提到好多喺 Amazon production GenAI use cases 好值得學習，親自發佈新 Amazon Nova foundation models：

• Nova Micro
• Nova Lite
• Nova Pro
• Nova Premier

根據 benchmark 係可以匹敵 gpt4o-mini、gpt4o、gemini-1.5-pro、gemini-1.5-flash，對應級數嘅 Nova inference 成本減 75% 而且速度快 1 倍！

Andy Jassy 發佈時 (1:44:30) 提到一個「人類總是犯同樣的錯 - never going to be one tool to rule the world」，舉例有啲人用 10 年時間去拗 NoSQL v.s. RDBMS 結果百花齊放、用 7 年去証明 Tensorflow will be the one AI framework 最後由 Pytorch 跑出，寓意 GenAI 作為其中一件工具，喺一啲特定場景啱用夠，時代証明咗「工具啱用已經係最理想」。

另外 training 方面，AWS AI chip Trainium 升級到第二代 Trainium 2 比起上代快咗 40%，仲透露下一年 Trainium 3 用 3nm 製程而可以，每粒可以再快 40%，一個罕見嘅幾何級增長。

有 Chip 只係第一步，Amazon Bedrock 最新加入 Managed Model Distillation 功能，developers 簡單準備一啲特定場景嘅 prompts，後台自動用「大 LLM」generate synthetic response fine-tune「細 LLM」，於特定場景下可以做到「大 LLM」差唔多嘅效果但快 5 倍以及慳 75% 成本。

AWS CEO Matt Garman：

Generative AI will be a core component of every application

我都相信 Generative AI 加速改變 user behaviour，今年由 infrastructure 到 application development 都可以做 LLM optimization，相信一啲開發成本到運行 LLM 成本問題而行唔通嘅 use cases，展望 2025 可以有突破性發展。

突破二：Database 「我全都要」

AWS CEO Matt Garman 發佈會當中一直埋下伏筆講不同類型 Database 的 trade-off，講一啲 design challenage，再列出 engineers 期望例如 Multi-region、active-active、strong consistency，最後用「Tyranny of OR - Genius of AND」表達「我全都要 AND」去發佈最新 Amazon Aurora DSQL 以及 Amzon DynamoDB global tables 能夠全部做到哂，相信日後 enterprise 要滿足 compliance 會易容好多。

突破三：S3 不再是純粹 Object Storage

最新 Amazon S3 Tables 擁有所有 S3 優點亦可以直接儲 tabular structured data ，用 Apache Icebreg 跑 analysis 快 3 倍以及 10 倍 throughput。

開得呢條新路，我有好強烈預感之後會有更多新 structured data format 去 optimize computation。

突破四：AI x Data x Analytics 結合成為一整個產品

發佈會入面有一張圖我幾鐘意，將整個 AI & Data & Analytics & Control and Goverance 打包做一個整合體驗，推出 Amazon SageMaker Unified Studio，宏願係一個 online IDE 搞掂哂成條路 query -> transformation -> analysis -> training，加速一啲對 data scientist R&D 嘅速度。

我幾鐘意最後完場前一句，短短一句解通咗點解咁多人去 re:Invent。

We invent so you can reinvent

AWS re:Invent 2024 後記

話說呢兩日過咗 Las Vegas AWS re:Invent，黎到先發現原來 re:Invent 與我想像中係幾唔同，感受到好強烈 Learn Hard, Play Hard。 整個日程基本上唔愁早午晚餐，朝早 Learning 傍晚 Party ，而且內容由 level 100(entry) 到 level 400 (expert) 都會有，加上有大量 Demo 可以玩，任何與 IT 相關嘅都唔會悶親。

今日只係黎到第三日，晚晚都有 party 未有時間寫得好詳細，黎緊我會將整個 re:Invent 系列寫多幾篇分享下喺會場見到嘅 GenAI use cases、體驗、反思以及技術心得，順便留個記錄俾自己。

MTR 出咗一個 web3 比賽俾參賽者使用 MTR 自家 Generative AI (Stable Diffusion) 出未來 AI 列車圖！

作為一個 90 後聽到「未來列車」一詞，最強烈嘅想像就係災難電影「屍殺列車」，本來以為 MTR 會擋哂所有血腥暴力恐佈之類嘅 Generation，就嘗試下寫 Prompt 試下有冇可能出到我想要嘅嘢。

屍殺列車之旅

一開始冇頭緒當然試下空白 prompt，睇下有冇嘢出。

(whitespace)

(whitespace)

點知空白 prompt 都會出到一架正常樣嘅列車同埋人，估計係用咗 Stable Diffusion (SD) 嘅 inpainting 去做呢次比賽，試下加入一啲恐佈場景元素以及一啲喺 SD 常用嘅 Prompt：

horible, horrific, scary, sun shine, sparking, photo realistic, 
4D, multiverse, dirty, untidy

(whitespace)

好似真係陰森咗小小，試下入血 blood 元素：

horible, horrific, scary, blood, sun shine, sparking, 
photo realistic, 4D, multiverse, dirty, untidy

(whitespace)

見到背景成功出現血跡，感覺列車後的背景在 Stable Diffusion 比較可以自由控制，試下加入月亮 moon 元素及試下有冇辦法出 bloody logo：

horrific, scary, blood logo, bloody moon background, 
sparking, photo realistic, 4D, multiverse, dirty, untidy

bloody logo

見到背景成功轉成月亮，試下加入喪屍元素 zombie：

horrific, scary, blood logo, bloody zombie background, 
sparking, photo realistic, 4D, multiverse, dirty, untidy

bloody logo

見到地面多咗一啲血跡，試下有冇可能出到一啲屍體係地下，加入dead body on the ground 同埋 empty skull 落件衫度 ：

horrific, scary, blood logo, bloody zombie background, 
sparking, photo realistic, 4D, multiverse, dirty, untidy, dead body on the ground

bloody t-shirt with empty skull 

嘩，誤打誤撞發現原來車頭都可以有咁大發揮空間，試下直接變做骷髏頭 skull，唔知關唔關人物個 Prompt 事，移除 empty skull：

horrific, scary, blood logo, bloody zombie background, 
sparking, photo realistic, 4D, multiverse, dirty, untidy, dead skull

bloody logo

今次多咗對眼，用同一個 Prompt 再 Generate 多幾次：

喺 GLT 討論社群分享緊，有朋友問：

改一改試下轉做將骷髏頭轉做 monkey , animal ：

horrific, scary, blood logo, bloody zombie background, 
sparking, photo realistic, 4D, multiverse, dirty, untidy, 
monkey, animal

bloody t-shirt with empty skull 

結果真係出咗猿人樣嘅列車！成個效果好似一個食人列車，夠哂「屍殺」味道！

「元」於你想象嘅未來港鐵又係點嘅樣呢？

總結

要發展一個 Responsible GenAI (Generative AI) Tool 其實一啲都唔容易，始終 LLM (Large Language Model) 使用上龐大數據去堆砌出黎，因為數據量太多太大，要寫一啲規距去「控制及防止」一啲 Prompt 去觸發一啲不想出現嘅 Output 其實好困難。

正如今次 MTR 出嘅呢個 Stable Diffusion 工具，我想 Generate 一張「元」於我想像嘅屍殺列車風格嘅圖片，圖片唔多唔少都必定會含有血腥成份，好簡單咁諗：

封殺所有血腥成份嘅 Generation 咪得囉！

但點封？

從 Prompt 及關鍵字入手一定沒完沒了，好容易就會被用戶「Jailbreak」，要諗到 AI 會將邊啲字眼產生 Correlation 極級困難。

從 Image Source 入手重新 Train 過一個模型，需要有大量 Computing 資源，雖時極長，最後還會產生大量碳排放。

Work around 的話，一個簡單但不 Efficient 嘅方法就係產出每張圖片之後，加入 AI 檢查圖片是否含有血腥、暴力或色情元素⋯⋯

ChatGPT、Bing AI、Google Bard 後面其實有大量不同專家去幫手做一個 「Responsible AI」，減少將人類的陰暗面暴露在 GenAI 的 Output 之中，反觀過來：

這可能就是人類自我限制的「極限」。

現在科技界三大巨頭 Microsoft、Google 及 Apple 各自有為 Developer 準備每年一度嘅技術發佈會，分別命名為 Microsoft Build 、Google I/O 及 Apple WWDC，發佈最新技術、產品發展及公司未來願景。

而不得不提 Microsoft 其實早喺 2019 及 2021 一共投資咗幾十億美元俾 OpenAI 去開發 AI。Open AI 喺 2022 年尾終於嶄露頭角，開放免費使用 ChatGPT 令更多人認識 Generative AI 的研究成果。今年 Microsoft 亦開始為不同 Microsoft Ecosystem 加入 Generative AI，主要是 Copilot 為主。

所以我非常推薦 Developer 睇今年嘅 Microsoft Build 2023 Keynote，短短地 30 分鐘大致上了解現時 AI 喺 Microsoft Ecosystem 嘅生態發展，話唔定可以諗到一啲新工具解決你現有的 Pain Point。

以上都係一啲全球性嘅發佈會，三大巨頭之中，就只有 Microsoft 有官方舉辦香港本地 Microsoft Build Hong Kong！

Microsoft Build Hong Kong 實況

是次 Microsoft Build Hong Kong 活動於觀塘 The Wave 場地舉行，大約有 300 個座位，我準時於 14:00 登記，坐無虛席。

座位後排位置設有水吧，讓參加者可以補充水份及糖份。

場地有一個角落擺放了一些攤位進行小遊戲及 Ask The Expert，讓參加者可以與 Microsoft 專家互動。

主辦方安排了幾位 Microsoft 專家包括 Cloud Solution Architect、Senior Cloud Advocate、Microsoft Technical Trainer 以廣東話去講解一啲 Microsoft Build 精華，以下是當天的流程表：

於第一節 Welcome and Keynote @Henry Li 以廣東話簡述 Microsoft Build 的重點，開始的第一幕提到：

AI is talking the computer age from the bicycle to the stream engine – Microsoft CEO Satya Nadella

這句話引起了我的注意，通常當我見到這類型 Quote 都會不其然去 face check 一下 Microsoft CEO 句前後嘅 Context，以免斷章取義誤解當時講者想表達的意思，這成為了我的待辦事項（於文末會分享相關的 face check）。

由於是次活動內容相當豐富，不能盡錄，以下是一些活動照片及分享一些我自己備註了的待辦事項。

我的待辦事項

• Check Copilot Stack Status
• Data Analytic Solution in AI - Microsoft Fabric 、One Lake
• Apply and try Azure Cognitive Search - Vector Search (Private Preview) 報名試用連結
• Understand Azure Open AI Content Filtering(Preview)
• Check the future of Copilot & GitHub Next https://githubnext.com/

到場福利

除了有 Microsoft 專家為是次活動準備的內容之外，於每個環節完結後有一條搶答問題，現場觀眾答對會獲得價值 $2300 的 Jabra Evolve 2 55，大家都十分踴躍搶答，目測有 20-30% 人舉手搭答問題，氣氛相當良好。

中場及離場時，到場參加者可以以抽奬形式獲得印有 Microsoft Logo 的 SWAG，種類包括 T-shirt、毛巾、USB 線及環保袋。

總語

香港係一個 Business Driven 嘅地方，大財團要花人力物力搞一個十分純粹的 Developer-only 嘅活動其實好困難，一來面向窄，二來未必有 Lead 返或者 Connect 到 Business Relationship。

所以 Microsoft HK 有人力物人搞 Microsoft Build Hong Kong 對本地 Developers 而言相當難得，始終有一啲行業專家以廣東話母語去 Recap 一次全球性嘅 Event 會多一份親切感。我明白大部份內容大家總可以上網睇，但呢類形實體 Event 最特別嘅地方係可以有機會 1 對 1 咁「Ask the Expert」去排解一啲心目中嘅疑問或者一齊傾下對未來科技願景，將一啲想法及願景由接觸得最近科技核心嘅專家帶到 Community，係有一個非常健康的發展。

有人一定會話「場地和規模不及 Google Cloud Summit 或 AWS Summit」，但對應相同 Audience 嘅係另一個旗艦 Microsoft Envision Event 而非 Microsoft Build，正如本文初所提到，Microsoft Build、Google I/O 及 Apple WWDC 三大巨頭的 Developer Events 就只有 Microsoft Build 有官方香港的版本。

Microsoft Build Hong Kong 2023 活動整個流程、人手及安排上基本上無可挑剔，但係場地而言，The Wave 樓底唔夠高令 Projector Screen 掛得唔夠高及唔夠大，體驗上有約 30-40% 面積嘅 Project Screen 會被前排遮住咗（如上述活動照片），要郁黎郁去先睇得到。

The Fact Check & 反思

在這個活動完結後，這是 face check 後的結果，以下是一段節錄於  Microsoft Build Opening 的片段 2:45 - 3:30。

AI is talking the computer age from the bicycle to the stream engine – Microsoft CEO Satya Nadella

Microsoft CEO 想指出的是製造 Bicycle 與 Steam Engine 所需要嘅工具將會完全唔同，而 Microsoft 非常專注地開發 Developer Stack 給 Developer 去創造 「Steam Engine」。

如果有 Content Farm 利用同一個 Quote 去借題發揮，例如：

我也不感到意外，這就是現時斷章取義及嘩眾取寵的 Content Farm 營利模式。

Software Builders’ Night 係我喺 Google Developer Group 搞嘅第一個活動，有一個長遠目標及與別不同嘅實踐方式，名符其實係「我推的活動」。

正所謂「已所不欲，勿施於人」，我搞嘅活動希望至少自己是滿意的。

十年以嚟，我用 Audience、Organizer、Speaker 身份參加過不同大大小小嘅 Event 例如 RISE、Cloud Summit、Show me the code、HKOSCon、Web Submit、DevFest… 等等，每個身份體驗我都有思考各種各類的期望。

今次搞 Software Builders’ Night 就係要滿足哂三個身份嘅期望。

Audience

• 希望門票是免費的
• 希望可以即時問下啲唔明嘅內容
• 希望知道點樣先可以成為 Speaker，究竟係咪靠關係
• 希望知道搞呢類型嘅 Event 有咩要考慮
• 希望知道幾時會有下次
• 希望時間唔好係星期五、六、日- 希望有嘢學、拎得走、識到新朋友
• 希望可以拎到份 Presentation Slide
• 希望獲得一啲職業上的方向及發展心得

Speaker

• 希望主辦方會有錄影
• 希望主辦方有一個 Public Portfolio Reference
• 希望可能遇到不同 Domain 嘅人一齊討論相近問題
• 希望 Presentation Slides 準備得有價值
• 希望可以獲得動力推動自己深入研究
• 希望可以收集 Audience 意見檢討
• 希望可以與 Audience 有時間交流

Organizer

• 希望可以貫徹 Event 目標
• 希望可以透過以往 Event 目標質素及人數搵到同路 Sponsor （場地 / Refreshment / SWAG）
• 希望不斷搵到新高手做 Speaker
• 希望可以全院滿座- 希望免費門票都會有高成數出席率
• 希望可以有 words of mouth 見到人聯朋結隊咁一齊參加

以上係我有嘅期望，而總結後得出圖中三個結構性元素必須於 Software Builders’ Night 實踐。

1. Transparent Operations
2. Community Driven
3. Mutual Growth Driven

Transparent Operations

在設計上利用 GitHub 平台將所有流程透明及公開地進行包括 Organizer Handbook、Speaker Onboarding、Talks Submission、Panel Discussion Title。

Community Driven

根據 Community 在 GitHub 上的 Reaction 去排 Priority。同時也歡迎任何人的 Pull Request Contribution 及其它 Event 參考我們的 Model 進行 Fork。

Mutual Growth Driven

我鼓勵 Audience 或 Speaker 之間可以有 pre-talk discussion / post-talk discussion 亦是在 GitHub 上進行，也會為 Speaker 在分享後收集 匿名 Audience Feedbacks 去協助 Speaker 成長。

總語

以技術會友係我一直想做嘅事，但如何建立一個系統有效率地做得好及處理 Scalability 問題更是我一直希望能透過設計去解決。最後希望參與這個 Software Builders’ Night 的朋友可以有以下體驗：

聽君一席話，勝做十連 Search！

今次小試牛刀，座位有限，你報咗名未？

現時大部份 Clickbait 都會使用 《AI 將會於 N 年內取代 XXX 工作》為題去恐嚇普羅大眾 AI 已經進化足以取代人類，但事實上這個說法嚴重地低估了人類的慣性及高估了人類在語言上的表達能力，過份樂觀地假設了世界上所有人都能平等地使用、相信 AI 產品而導致行業固有需求減少，這是不現實的。

首先，Generative AI 的出現在悲觀預測下的確有能力令某些行業的需求下降，但導致這結果的過程並不是由「AI 取代人類」而是「AI 產品『賦予』了人類一個可能性去完成某些任務自給自足」，從而令固有需求下降，甚至「任何人也能使用 AI 迅速地向他人提供服務」令服務成本及價值下降，改變整個行業生態。

所以現階段所指的「行業沒落」預言，不是指「AI 取代人類」而是預測「有人利用 AI 『賦予』的可能性」去改變行業生態，而此改變有可能創造出更多不同類型的新工作及需求。各行各業擁有著不同的生態及不同的人，單純地透過 AI 科技發展增加不同「可能性」是不足夠的，要改變一個行業生態，必須突破人類的慣性及大幅度地提升向 AI 表達思想的能力。

人類的慣性

慣性是一種帶有安全感、信任、穩定、低風險及舒適的行為及思考模式。

例如當企業之間有了信任，公司 A 習慣了外判責任去代工 A，就算代工 B 利用最新 AI 科技大幅度壓低服務價錢並聲稱能提高更高質素，亦未必能獲得公司 A 青睞，這是一個慣性考驗，而慣性可以凌駕大部份判斷。

與此同時，代工 A 因 AI 興起而多了一些選擇：

• 可以選擇維持現狀
• 可以活用 AI 賦予的能力更有效率完成同一質素的服務
• 可以完全依賴 AI 但犧牲一些準確性創立新服務

這又會是另一個企業內部的慣性的考驗，一層推一層直到每一個人都會經歷一次慣性的考驗。

人類向 AI 表達思想的能力

AI 完成指定任務之前，AI 需要接收任務需求，任務需求愈清晰，AI 的反饋準確性愈高。一些容錯率較高或任務需求簡單的服務本質上容易受到影響，例如小說翻譯、小型應用程式開發、Icon 設計、封面設計等等，但這並不足以令人生畏。

人們生畏的是來自網上展示的 Generative AI 成果都十分華麗成功，引發無限睱想，但自己卻無能力產生相近的成果。

那些華麗的成果已經達到「可接受範圍」及立即使用，甚至比起二三線的服務提供者的產出更好。可是，要製作那些華麗成果的大前提是「人類可以有效率地向 AI 表達所思所想」，以 ChatGPT 及 Midjourney 熱門工具為例，使用者需要透澈地理解 AI 的運作原理、分析所需要的資料、將任務難題拆解再描述給 AI 及根據 AI 的反饋不斷調整，最後獲得預期或超出預期的成果。

這種技能現稱為「Prompt Engineering」，這將會成為一個新興專業，對 Generative AI 科技知識及語言表達技巧要求相當之高，需要長時間與 AI 特定工具練習及了解各種 AI 背後原理。

Prompt Engineering 並不是普羅大眾能擁有的技能，侍這類人才出現並在多如繁星的可能性下為各行各業找出精妙的捷徑之前，我相信普羅大眾使用 Generative AI 工具時通常會有一種「書到用時方恨少、執筆忘字」的感覺，有些簡單或準確率要求不高的任務可以從容解決，但有些相對複雜或需要 100% 準確的任務上卻會感到不知如何開始表達。

現階段欲期望普羅大眾突破慣性，要求人人精準地活用新 AI 產品自給自足地降低行業服務固有需求，從而去摧毁並重建一個新的行業生態，談何容易！

結語及觀望

AI 不會「取代」任何人，只是 Generative AI 「賦予」人類一個可能性去改變整個行業生態，但發展這個可能展仍要依賴每個行業的專才。

在這場改變之中，開發新 AI 產品的新公司及與 AI 互動的新職位將會接種而來，而無法適應行業生態改變的公司將會面臨巨大挑戰。我預測 Generative AI 發展要突破人類慣性至少要三年，要普及到各行各業都能活用 AI 至少要一個年代。

以史為鑑，Windows OS 出現了三十多年，Search Engine 出現了二十多年，Smart Phone OS 也出現了十多年，各行各業生態也會圍繞這些軟件而改變，Generative AI 只不過是隨後的第四波而已，而我深信 Generative AI 的演變進程將與其它科技一樣，大方向發展會一如以往起初由 Productivity (生產力) 轉向到 Entertainment (娛樂) 發展，屆時不同行業會以「AI『賦予』的可能性」為軸心創造比現在更多的工作需求，持續而且無限地提升人們生活質素。

在云云人海之中，曾於 Search Engine 使用「+ 」、「-」、「""」、「site:」 … 的人你認識有多少個？那究竟相信不久將來人人也有效率地向 AI 描述的自信從何而來？

在每個科技演變進化之中，

懂的人會把握機會飛黃騰達，
不懂的人也會有圈子活得自在。

你懂的。

可能有機會係只睇 Configuration 而卻漏咗 Calculation 部份涉及 log2(Count)，即係話 2 個 Like 係等如 2^30 個 Reply，不是只有 30 倍。

P.S. TensorflowBasedRankingParams 係基於 LinearRankingParams

代表一個簡單嘅 Like Feedback 好過要打字嘅 Reply，雖然唔知咁樣定個有乜嘢科學根㯫但如果 Facebook 都係類似咁嘅話，大家記得積極啲俾 Like 你地喜歡嘅內容！咁已經係對內容創作者最大嘅技持！

後記 - 小技巧

睇多少少發現如果想喺 Twitter 睇多啲英文 Technical Post，記得將個 UI 轉做英文，因為若 App UI language 與 Tweet language 不同，Tweet 推薦分數會下降！

超突發！Elon Musk 將一整套最高度機密嘅 Twitter Recommendation Algorithm Open Source 咗！包括圖中所有 Service！

呢個 Open Source 行動絕對可以令整件事透明化以及提高 Software Engineer 「自我優化」動力！另外，有心人有心力有時間亦可 Review 及有機會指出箇中設計缺陷去加以改善。

值得反思嘅位係：

Elon Musk 此舉動真正對 Twitter有咩影響？

最後喺 Twitter Engineering Blog 中提到呢套 Algorithm 仲會繼續開發：

Twitter is the center of conversations around the world. Every day, we serve over 150 billion Tweets to people’s devices. Ensuring that we’re delivering the best content possible to our users is both a challenging and an exciting problem.

We’re working on new opportunities to expand our recommendation systems—new real-time features, embeddings, and user representations—and we have one of the most interesting datasets and user bases in the world to do it with. We are building the town square of the future.

If this interests you, please consider joining us.

GitHub: https://github.com/twitter/the-algorithm

Twitter: https://twitter.com/elonmusk/status/1641876892302073875

Twitter Engineering Blog: https://blog.twitter.com/.../twitter-recommendation...

後記 - 真係有 author_is_elon

估唔到真係會用 author_is_elon 去做 feature flag，而且真係 hard code 喺入面。

Flutter 黎緊可以直出 100% WebAssembly，Docker 亦有 WASM runtime 及 Architecture 去行未來嘅 Backend Application。

Flutter Web 嘅好處及壞處就係直接用 Canvas 處理所有 UI Rendering 及 Interaction，好處係可以最大程度去使用 GPU 以及免去 DOM manipulation ，壞處係等於直接放棄咗 SEO。

日後 Flutter 不需要再經 dart2js 轉 javascript 而係轉 WebAssembly ，最開心位係少咗啲 javascript 52bit number 轉換嘅問題，同時直接使用最高效率處理 business logic 及 multi-threading。

現時大部份主流嘅 Language 已經開始支援 compile to WebAssembly 例如 Kotlin, Rust, Go, C#, C++, etc，未來十年有可能成為比起 JVM 更熱門嘅選項，因為同一個 Deliverables 唔需要再分開 Platform Compile。

Flutter WebAssembly Demo: https://flutterweb-wasm.web.app

Docker+Wasm: https://docs.docker.com/desktop/wasm/

申請 Google Bard waitlist 見到呢段字，激起我思考到不久嘅將來

當 Offline Generative AI 可以有權限做到 Actionable Task 之時，Rule-based Software 將會很容易被取代

例如寫兩句 Prompt 就做到 2022 年可能要兩三個 Developer 做兩三日嘅功能。

Task 1

- Use this SendGrid API key xxxxxx to send welcome 
email to the newly registered users. 

- Remember to validate the user email before your send. 

- Use the following email templates to draft the email:

"""
You’re on the waitlist

You’ll receive another email when it’s your turn to test Bard.

In the meantime, we asked Bard to write you a little poem while you wait.{{Personalized delightful poem}} ~ Your PA

Thank you for registering.’
"""

Execute Task 1 when there is a new registration completed 
event in the message queue. 

Connect to the message queue by using the username=xxx, password=xxx, URI=xxxxx.

When executing Task 1, create the email sending history 
for audit purpose.

屆時 Generative AI 嘅 Context Length 就係每個獨立 Customized Rule 嘅 Limit。

當我地要做一個 GPT 產品開發，要做一個良好嘅 UX，AI 要「記得」用戶講過及自己答過嘅嘢以及答得「準」，所以 Context Length 及 Accuracy 係最重要。

今次 GPT-4 發佈最驚喜嘅地方係將個 Context 由 4096 tokens(GPT-3.5 turbo) 提升到 8192 tokens，更有 GPT-4-32k 提供 32768 tokens！呢個差異可以大大改變 GPT 產品嘅限制及做多更廣更闊嘅設計。

而 GPT-4 V.S. GPT-3.5 背後有龐大數據差異（傳聞相差至少 100倍），相信 GPT-4 會答得更加準，價錢亦上升咗 3 倍由 $0.002/1k tokens 上升到 $0.006/1k tokens (completion)。

GPT-4 發佈連結 : https://openai.com/research/gpt-4

《上咗 Production 出事再改 Requirement 之乜都係 IT 問題》

本故事內容取自真實題材，將有可能發生的技術限制及負面會談角度以故事形式敘述。如有雷同，實屬巧合及不幸。

以下故事之部份內容可能會引致情緒不安，有興趣晉身 IT 的請在 IT 朋友陪同下閱讀，敬請留意。

<Story>

PM：「收到指引要將主頁變黑白色, ASAP」

Developer: 「係咪所有嘢都變哂黑白就得？」

PM：「係！」

Developer：「咁我加一句 CSS 就做到架喇～」

PM：「掂！原來咁簡單！仲以為要改好多句先做到，咁你放低哂手上嘅嘢集中搞咗呢個先！」

Developer：「Ok」

（Developer 改完之後 deploy 咗上 UAT 俾 QA 檢查…）

QA：「有冇 Ticket 講番個 Requirement 係乜嘢？」

Developer：「冇喎，但聽聞壇嘢好趕，冇時間搞啲咁嘅嘢，Requirement 就係所有嘢變哂黑白色。」

（QA 檢查後）

QA：「Passed！」

PM：「QA Pass 咗，咁可以推上 Production 喇 ～」

Developer：「Ok！Done！」

（上咗 Production 後數小時，遭無數網民恥笑網頁出現黑白大頭相）

PM：「點解 CEO 張大頭相會變咗黑白色架，你地做嘢之前有冇用腦架？仲有連啲象徵地區嘅旗都變番黑白色，而家 CEO 炸型喇，即刻同我改番啱佢啦！」

Developer：「吓？但你嗰時話所有嘢都變哂黑白就得。」

QA：「我收到嘅 Requirement 都係話將所有嘢由彩色變黑白色，我所有部件都對過冇問題。」

PM：「你兩個幾多歲呀？大頭相變黑白色有特別意義，象徵地區嘅旗幟唔可以擅自改顏色，呢啲 Common Sense 嘅嘢唔洗人講吓話，總之而家要將呢兩樣嘢改番彩色。」

Developer：「啲旗係 Static Content 就快改到嘅，但啲相同埋字係 CMS Dynamic 控制再 Export HTML，啲相冇特定嘅 Tag 我控制唔到佢唔變黑白，一係就將所有相都變番彩色，咁好似好奇怪…」

Developer：「一係就幫 CMS 加新功能俾佢地落 Tag，但起碼搞幾日」

PM：「…吓，少少嘢都做搞幾日？我而家即刻要喎，咁仲有冇其它方案？」

Developer：「一係叫 User 喺 CMS 將啲有人嘅相換走佢，或者 User 自己幫啲 Dynamic HTML 加 CSS， 我可以俾啲 Source Code 佢，但佢加錯位有可能炒爛其它嘢嘅樣」

PM：「…吓，咁要搞到班 User 喎，但係我見其它網頁做到架喎，點解我地嗰個又做唔到？」

PM：「唉，算啦。我試下叫 User 嗰邊可唔可以換走 CEO 啲相啦」

（PM 搵 User 解釋後）

User：「咁啫係搵著我地黎搞架姐，個網頁轉咩內容要拎 Approval 架，冇你想像中咁簡單...」

PM：「冇辦法啦，班 IT 話做唔到，CEO 炸哂型呀要急改番正，拍爛檔幫幫手搞，如果唔係我就要拉個大會傾 Solution，到時 IT 一樣係話做唔到搞著你地」

User：「唉，又要我呢邊幫 IT 執屎，我出埋佢地份糧好唔好」

User：「等下啦，冇咁快 Approve 到」

PM：「Ok..」

(主頁移除了所有有 CEO 頭像及把旗幟改回彩色）

</Story>

究竟問題出現在哪𥚃？

我會於 GDG DevFest 2022 分享《Deep Dive the Real World Performance of Kotlin Coroutine》。如果有用緊 Spring Boot 及 Kotlin 嘅朋友，我強烈推薦你黎聽下～

今次有實體演講！有興趣嘅聽嘅朋友記得登記才可出席，屆時也有直播 Link 於線上同步。

登記連結：https://gdg.community.dev/events/details/google-gdg-hong-kong-presents-devfest22-gdg-hong-kong/

不得不提 2016 年我用 2 個星期時間去了解 Kotlin 1.0 發現整個語言設計非常優秀，更 100% compatible w/ Java，正值公司要開發一個全新 Android Application，我更於 「Google 2017 年正式宣佈 Kotlin 成為 Android First Class Language」 一年之前使用 100% Kotlin 去寫 Android Application，寫了三篇文解釋箇中原因：

• Part 1 : Picking Kotlin for Android — The Reason Behind
• Part 2 : Picking Kotlin for Android — Killing Features
• Part 3 : Picking Kotlin for Android — Swift in Android?

然後 2018年更擴展 JVM Backend 也使用 Kotlin/JVM，整段時間使用成為一個 Kotlin Trainer 也學習了很多 Kotlin 甚至深入了解語言設計上的考慮。

Google Developer Expert Program

我非常憧憬 Google Developer Expert Program 所提供的支援讓我做得更好，從而再將 Kotlin 的使用心得推廣得更遠更多受眾！

呢幾個月一直忙於準備 Amsterdam 舉行嘅 KotlinConf 2023 演講題目，減少咗喺 Gap撈Tech 活躍嘅時間；在整個準備過程之中也深造了 Kotlin，若能被選中成為 KotlinConf 講者將會錦上添花，就算落選也已經獲得了大量有趣資訊分享給 Kotlin 用戶。

Kotlin GDE Profile: https://g.dev/garylo

來年嚟緊除咗會極力推廣 Kotlin 之外，更會以新方式分享更多有關 Software Engineering 行業秘密、通病及一些我認為非常重要嘅 Engineer 意識形態！