創新工場和BCG諮詢合作的「+AI改造者」系列：創新工場投資的Insilico Medicine，看AI新藥研發平臺如何賦能傳統藥企，一起進行“AI＋生命科學”的顛覆式創新！
改造者系列：AI醫藥的下一站是長壽 -- 本文来自BCG微信公眾號，經授權轉載。
近期，創新工場聯合BCG波士頓咨詢旗下亨德森智庫，推出「AI融合產業：『改造者』如何促進AI普惠」系列研究。人工智能在中國大陸有著明確的落地應用場景，大量的AI企業活躍於這些垂直場景中，我們定義這些企業為「改造者」。「改造者」通過傳授其AI技術和垂直行業理解，極大地打破了傳統企業應用AI的瓶頸。
作為擅於趨勢前瞻的TechVC，創新工場長期看好AI領域，深入佈局，至今已經投出了7只AI獨角獸。在系列研究中，我們采訪了數家創新系AI企業，通過這些「改造者」的視角，探究傳統企業擁抱AI的範式與路徑。
創新工場投資的英矽智能（Insilico Medicine）是一家由人工智能驅動的全球領先生物技術公司，通過發明和迭代人工智能藥物研發平臺，變革創新藥物和療法的發現方式。
英矽智能的AI藥物研發平臺已經證明了自己的能力：在今年2月和8月，半年的時間內，先後公佈了兩種臨床前候選藥物，分別用於治療特發性肺纖維化和腎臟纖維化。
在采訪中，英矽智能創始人兼首席執行官Alex Zhavoronkov博士表示，AI醫藥企業的下一個重要問題將是如何更好地理解生物學和跨物種生物學，長壽業或者抗衰老技術將會是未來的方向。以下：
■系列導讀
本系列由BCG亨德森智庫與創新工場董事長兼首席執行官李開復博士帶領的創新工場團隊共同推出，圍繞「AI融合產業：『改造者』1如何促進AI普惠」的課題，我們致力於探究傳統企業在應用AI過程中的關鍵要素與合作夥伴，以及傳統企業擁抱AI的範式與路徑。
AI製藥領域於2014年左右興起，在2018—2020年間全面爆發。AI能夠快速識別大量樣本中的客觀規律，加速尋找和測試潛在靶點的過程。「有了AI，我們50個人可以做到的事情，比得上一個典型的製藥公司5000人所做的事情」，英矽智能創始人Alex Zhavoronkov在「未來呼嘯而來」一書中如是分享。2
1 「改造者」 通過傳授其AI技術和垂直行業理解，極大地打破了傳統企業應用AI的瓶頸，充當產業中傳統企業應用AI的橋樑。「改造者」包括AI企業與成功轉型AI的傳統企業。
2「未來呼嘯而來」，彼得·戴曼迪斯（Peter H.Diamandis）和史蒂芬·科特勒（Steven Kotler）著。
■本期受訪嘉賓：Alex Zhavoronkov
英矽智能（Insilico Medicine）是一家由人工智能驅動的全球領先生物技術公司，通過發明和迭代人工智能藥物研發平臺，變革創新藥物和療法的發現方式，加速研發進程，為癌症、纖維化、抗感染、免疫和抗衰老等未被滿足的臨床治療需求提供創新的藥物和療法方案。
Alex Zhavoronkov是英矽智能的創始人兼首席執行官。他擁有皇后大學學士學位，約翰·霍普金斯大學生物技術碩士學位，以及莫斯科國立大學物理和數學博士學位。
■對談實錄
Q1 英矽智能原來在美國創立，後來為什麼選擇遷至中國？
Alex：中國構建了一套完善的體系和土壤，吸引創業企業、大型企業紛紛入駐。中國大陸多樣化的投資者，包括傳統藥企、科技巨頭、PE/VC等各類投資者，能將最優質的AI人才、CRO、藥企融合在一起。投資者能為初創企業提供資質牌照、幫助招聘、企業管理和宣傳等等。英矽還與許多學校開展了合作研究，擁有豐富的內部研發管線。中國完整的生態夥伴體系使得像我們這樣的企業能夠迅速擴大研發規模，甚至與大藥廠競爭。
Q2 英矽智能和輝瑞、安斯泰來、楊森製藥等諸多藥企都有合作，在和大型藥企合作的過程中有什麼心得或者經驗？
Alex：創新型的AI生物技術公司按照創立時間可以分為三大類：2014年之前成立、2014年—2015年左右成立、最近5年成立。2014年之前成立的企業通常不運用深度學習（deep learning），或者不具備向藥企提供解決方案所需的行業知識。2014—2015年間成立的企業則創立的正是時候，生成式對抗網絡（Generative Adversarial Network）出現，AI製藥開始興起。同時，許多藥企缺乏AI的專業知識和AI團隊，如果想要獲取AI方面的知識和技能，就必須與初創企業合作。作為交換，那時候的藥企也通常願意向初創企業提供資料和各類資源。英矽智能很幸運，創立時間（2014）正處於大藥企對外部合作最為開放和寬鬆的時期。而最近幾年成立的企業就沒那麼幸運了，很多藥企已經開始自建AI團隊、自研AI應用，只有具備非常特定細分領域AI技術的初創企業才有可能成功撬動藥企，與之建立合作。
然而據我的觀察，儘管許多大藥企都建有自己的AI部門和數據科學家團隊，但他們並沒有足夠強的AI能力——他們往往缺乏具備足夠AI知識的團隊。以生物醫藥方面的論文發表為例，在2014—2019年間，英矽智能發佈了上百篇AI相關的論文，然而發表AI論文數量最多的藥企阿斯利康則只有65篇，位列其次的諾華有54篇。
藥企往往也不知道從何處開始應用AI，而這正是AI初創公司能夠創造價值的地方。但是，在AI初創公司開始接觸藥企和銷售方案之前，首先要充分理解大型藥企錯綜複雜的組織架構和部門分工，針對不同部門銷售定制化的模塊，而非從一開始就銷售整體性、綜合性的解決方案。這是因為藥企內部通常很難有一個部門能夠處理所有的模塊，部門之間的協同往往沒有那麼強。因此，AI初創公司在提供解決方案的時候也要靈活地劃分模塊，對症下藥，英矽智能通常一次只銷售一個模塊。
儘管銷售是模塊化的，AI初創公司需要具備端到端、全鏈路的解決方案。英矽根據不同的研發週期，設計了三大AI平臺——新藥靶點發現平臺、分子生成和設計平臺、臨床試驗預測平臺。據我們瞭解，中國還沒有任何一家同行，同時擁有生成生物學和生成化學兩大AI平臺，能把靶點發現和小分子化合物生成有機結合在一起的公司很少。此外，英矽智能的AI系統可以用軟件形式呈現，藥企可以自行操作，用自己的數據運算測試。這些都為我們創造了差異化的優勢。
最後，對於藥企而言，如果想要應用綜合的AI解決方案，需要有整體性的戰略為引領。咨詢公司可以充當整合各部門組織、統籌整體戰略的角色，AI企業可以選擇與之合作。
Q3 在您看來，未來AI醫藥領域的發展趨勢是什麼？
Alex：在未來，最重要的不是AI技術，而是如何將AI和行業特定的實驗數據或模型結合。現在市場上已經充滿了各種各樣的技術企業，他們在不斷精進演算法模型和數據。未來的競技不會是關乎演算法或者算力，而是新的商業模式或者應用AI的新方式。
AI初創公司需要積累足夠的行業專識，理解藥企的需求，學習藥企的經驗，並向藥企證明自己提供的模塊能夠在真實的商業環境下應用，並且模塊之間能夠很好地兼容，能融入業務流程，且符合監管要求。比如機器學習加速了藥物識別，但還有很多步驟和流程並不能被加速或跨越：實驗論文不能被跨越，你依然需要向藥物監管部門提供大量實驗數據和模型來證明研究的有效性；實驗中的生物過程不能被加速，你依然需要等待生物體自然的新陳代謝和細胞活動，你也不可能直接從大鼠實驗跨越到人類實驗。而這些都涉及到更細分的新技術問題。
所以，對於AI醫藥企業而言，下一個重要的問題將是如何能夠更好地理解生物學？如何理解跨物種生物學？正因如此，我判斷長壽業或者抗衰老技術將會是未來的方向，即如何運用AI來監督和追蹤生命體在漫長時間裡無數細微的實時變化，來創建數字孿生（digital twin），進行跨物種比較、跨疾病模型比較。我相信AI是説明我們更好地認識生命體的最佳工具。
■要點回顧
1、中國的資本環境天然地聚集了垂直產業領域的優質企業，幫助AI初創公司，即「改造者」，迅速汲取經驗、擴大規模，加速行業創新與賦能。
2、在與垂直行業企業合作時，「改造者」既要有端到端的解決方案，也要有靈活、敏捷的銷售和服務模式。端到端、全鏈路的方案有助於「改造者」更靈活地根據傳統企業的需求組合方案，能夠擴大服務範圍和客群，提升「改造者」的競爭優勢。
3、未來最重要的不是AI技術，而是如何將AI與行業特定的實驗數據或模型結合。限制因素並不是演算法或者算力，而是新的商業模式或者應用AI的方式來實現行業定制化。
敏捷管理心得 在 Re: [心得] 敏捷課程觀察心得- 看板Soft_Job - 批踢踢實業坊 的推薦與評價
感覺清明連假挺好的，發文跟看文的人都有比先前多一點。
除了掃掃墓，也要掃掃各種觀念的新仇舊恨 !?
改變一經啟動，最先遇到就是混亂。你一定也經歷過，
就是當你用了新工具、新程序，卻發現比以往還糟的時候，
有人會說：「要是把這些新玩意丟掉，或許能重拾秩序...」
你飽受學習曲線的折磨，並認為問題就出在改變上，這項評斷或許沒有錯，
至少在當時是對的，當時的你真的比以前還糟。
這就是為什麼人對改變的反應是如此情緒化的原因，放棄專精已久的做法，
再次變成初學者，真是令人洩氣與尷尬，沒有人喜歡掙扎的感覺，
更何況你知道用老方法可以做得更好。
很不幸，混亂是改變的必經之路，沒有捷徑。
Peopleware P. 260
※ 引述《YAYA6655 (YAYA)》之銘言：
: 以我20年的經驗來說，什麼敏捷，設計模式，很多都是脫褲子放屁。
: 更早期還有什麼OO方法論，部分人神鬼上身，什麼東西都要OO一下，連寫個九九乘法
: 表都要開一個 class ninenine。
: 就好像1995年，C++鋒頭上的時候，說C++難用的會被一堆腦粉抨擊，不外乎就是說，
: 不是C++難用，是你不會用。
: 這是不是跟太極拳很像？太極拳多強，打輸泰拳，腦粉會跟你說，不是太極沒用阿，
: 是你自己沒有把太極的精髓發揮出來。
: 到最後這根本就是信仰了。但時間會證明一切阿，C++就是產能低落，太極就是打不贏
: 綜合格鬥。
: 回到正題吧，有一段期間我們公司也導入設計模式，搞到每一個簡單的動作都要有
: USECASE，你能想像這是怎麼回事嗎？這就像建構式數學，明明簡單到可以9x5=45的東西，
: 他規定你要9+9+9+9+9。
: 工程師是人，不是白癡。每一個輸出入函示都要UNIT TEST？有些簡單到如同9x5的東西
: 你真的還要替他見一個UNIT TEST？單步追蹤一次就夠了吧，裡面程式碼沒幾行，還是
: 呼叫共用的函示庫，這能出錯叫做共業，根本不需要花時間在這種地方演戲。
: 後來我們導入設計模式大約一兩年後，大家就慢慢不了了之，很多狀況都是慢慢不了了
: 之的，沒有人會願意出來說，我們當初想法天真錯誤啥的，就一切盡在不言中了。
先說說對於整篇文章的看法，
過去我們的學習適教學者為權威，不管他教的好的，或教不好的都太深信不已。
在整個『國立編譯館』的洗腦框架與競試 KPI 下，
我們挺少反思知識的來源是否正確，或對自己是否有價值，該不該追求它。
離那個代年越遠，我們的思考才會越活絡，更加能對知識產生質疑。
由前輩的分享，可以看出在公司導入新觀念、新技術時，
所受到的不平無法抒發之處，這些東西必需有計劃的導入，
本質上得學習組織的活性要足夠，那並不是拿著『權力』大筆一揮，
宣示一下就能成功的事，而是由一連串的小變動，讓組織
(先想個小一點的，例如 3 ~ 5 人的 team) 適應保持變動。
累積足夠的活性與習慣接受新觀念並願意改善行為後，
才能有真正的大幅革新，例如替換工作方法、工作流程。
或是得有回饋機制產生正增強。
先來做點簡單的名詞或概念釋疑
: 以我20年的經驗來說，什麼敏捷，設計模式，很多都是脫褲子放屁。
: 更早期還有什麼OO方法論，部分人神鬼上身，什麼東西都要OO一下，連寫個九九乘法
: 表都要開一個 class ninenine。
就先從敏捷開始吧.
提到『敏捷』就得提與它相對，作為他『假想敵』的 waterfall。
實際上，他們並不是真正的對抗關係，以『定義良好』的系統，
並『完全符合使用者需求的 SD/SA 後』產生的規格書，
並寫了簡易的 reference implemenation (或若干組 POC)，
直接發包、大撤幣是一種相當有效率，而且相當直覺得軟體開發流程。
若上面的『前提』都能滿足，那專案管理與人力調整，
那就單純是程式的『生產線』順不順暢的問題。
是什麼東西，破壞了這些前提呢？軟體開發最終還是在實現需求，
但使用者也許不一定真的理解需求，特別是在若干次使用者訪談之後，
可能發生矛盾的需求，特別是東西做出了一個雛型後，將使用者由
「想像」拉回現實，使用者接著反應「這不是我要的」。
那麼我們還要繼續走完 waterfall 嗎？或是回頭 blame 當初的 SA/SD 嗎？
以商業角度來說，那都不適當，合約在走，違約日一天一天逼進，
不是做完領錢、逾期賠錢或是違約倒閉。
所以，自然地，不太應該在一開始就想著最初的規格是會走完的，
得設定小一點、合理的目標先達成它，
並週期性確認雙方認知是否還在同一個線上，但認知明顯不同
才能以較小的『成本』反應需求變更，以敏捷常用的單位就是 iteration
而後續相依需求的 iteration 也都不用再排入到工作內。
時時確認客戶的需要，適時反應改變，才能符合需求達到降低違約的風險的目標
後來發現，除了對客戶間的互動，開發人員之間也得多多互動。
每個人對於規格或需求的解讀不太一樣，或設想的前提假設也不同，
所以才會有週期性短短的會議，不管是時間預估或是反省會議，
都有機會透過其他人的角度來看事情，知道為什麼不同人估同一個工的時間不同
是他多想了，還是我少想了，或是他知道有哪些既有的 library 或演算能採用
以加快處理的速度。
PS. 由於篇幅有限，其中也很重要的 working software 就省略一下了
大致上，專案在開發初期頭幾個 iteration 就可以有完整的軟體能跑，
好處是客戶能玩到會動的東西，不會過度想像，它就像我們剛進入
新的遊戲，基本功能都能動，但有很多未開發的關卡，等實作到了才開放
再來，談談單元測試 (雖然在你腦中是設計模式)
在聊了敏捷後，看單元測試就特別有意思了。
對比儘可能直衝整個進度的 waterfall，
或幾個 iteration 釋出新版本的敏捷開發，
『單元』是僅測試一部分軟體的功能，而不是整個完整的軟體。
特別是在進入 OOP 的年代，物件與物件之間的界線更好區分了，
而那個界線，自然地可以成為單元測試的切入點，
若是非 OOP 語言也會有其他可以作為界線的部分，
讀者倒是不用太擔心是哪種類型的語言
原 PO 是停留在一組簡單的 unit test 要如何實作的引言部分
但還需要充實一下部分的觀念：
* unit test 測試粒度，至少以 OOP 來說，我們只測 public method
* 不管你喜歡 TDD 或 BDD 都蠻值得看一看的
* 怎麼樣的實作，讓 unit test 難以實現 (ex. singleton pattern)
與適當的工具知識的補充，像是
*. 單元測試常用的 library，怎麼方便建立 test fixture
*. 需要 mock/stub 時，哪些 library 可以輔助
*. mock/stub 成本太高，是否要改用整 e2e 測試
*. 建置持續性整合環境 (並考慮邁向持續性部署)
推薦閱讀：
《Growing Object-Oriented Software, Guided by Tests》
看著原 PO 的年資與對 OO 痛恨的感覺，可以理解並表示同情
因為在早些年代的 OO 概念，確實比較傾向『對應現實世界』的實作方式，
像是弄個 Car 類別，再給他 N 個輪子，給他喇叭之類的東西。
比較現代化的方法，其實很少這麼作，除非學習者只看了入門教材就放棄了
剛入門的人，確實需要較『具體』的解說，但在實際開發的情況，
我們並不會那麼做，千萬不要那麼做 (除非有相當好的理由)
常見的設計方向有 3 種：
1. 標準的 OOAD，就定義好各種 interface 與它們間的互動關係
(語言提供的標準 API 大致走這個路線)
2. 隱喻，採用隱喻或一組故事來設計，比較容易記憶，而且有趣味!?
3. 由 2. 為主，但基底包裝好的 Design Pattern.
簡單來說，我們要過 Design Pattern 學習時，
練習出的眼光試著將程式面對『變更』的節奏做『抽象化』的處理。
Design Pattern 實作可能會讓程式變得比原長，但這代價挺低廉的。
Design Pattern 的精華並不在 Pattern，而是在每章開頭的 Intention
雖然意圖可能不儘相同，但目標如何『動態』地面對改變與擴充。
這裡的『動態』是指 Runtime 為主 (自以為)，
即使在這個 source code 很好取得的年代，
我們並不希望直接修改其他人的程式碼，
或是期望原本的專案，一開始的需求固定處理某些情境就行，
但後來得動態擴充它，都能由 Design Pattern 找到靈感
雖然不求有一模一樣的情境，但我們回頭推敲，
能簡單地設計一下，達到 Open-Closed Principle 的目標
我們該學的除了具體的 "Pattern"，同時是訓練識別 Intention 的眼光
同樣的理由，會出現在 refactoring 的學習上，refactoring 技法固然重要
但培養出快速嗅出 bad smell 的直覺。
====================================================================
回到最開頭講的，脫離了過去教育方式的框架後，
我們有機會『越過』第一次授與知識的源頭，
例如：像是認同原 PO 想法的人且初次知道這些『名詞』
不能只是停留在各自的同溫層取暖，也不能全然相信我單方面的解說。
要略過我們，找找原文書看看那些知識如何使用。
特別在這個資訊多元，價值多元的時代，
更應該鼓勵一些過去受過不好經驗的人，正視一下那些荒謬的經歷
學不學它都沒關係，但至少讓自己由惡夢中醒來。
同時，也該接納不是所有人都能學習的會那些被鼓勵學習的技術，
以我個人來說，對於 agile 沒特別的好惡，並鼓勵『自助餐』
開發者，或同事，只要能做出他能有最大貢獻的『選配』就行了。
我個人『進度至上』主義的，只要求是要有足夠的生產力。
code 寫得好不好看，有沒有 OO 什的，倒不那麼重要，
反正重構技能與砍掉重練技能點滿了，
等那部分要賺錢了、得能 scale out 時，再整理就是。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.233.73
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1523003605.A.7EF.html
※ 編輯: qrtt1 (36.231.233.73), 04/06/2018 16:35:21
※ 編輯: qrtt1 (36.231.233.73), 04/06/2018 16:35:51
https://www.books.com.tw/products/0010644283
路過，補個書
※ 編輯: qrtt1 (36.231.233.73), 04/06/2018 16:48:12
... <看更多>