BI決定AI是「硬用」還是「應用」
AI是沒有「品質」可言的
Github及Copilot是軟體人員在社團例會中最關心的題目，而非軟體人員則是一直在追問，何時會有M365可以使用？呵呵，這應該是很有得等了，明年看有沒有機會吧。
近期AI應用社團在大家的協助下，還是盡最大的努力，在還沒有殺手級應用的情況下，不斷地介紹一些第三方開發的工具。儘管我們對這些工具都不是很瞭解，或是這些工具真的都還不夠成熟到可以大規模的優化我們的工作流，但在這個過程中，我們都慢慢理解，上次我在早會中分享Bill Gates說的那句話：我們真的太高估AI「現在」能給我們的效益及影響。
論文中提到的一些新技術，拜現在開發技術進步，有些論文都會直接附上Demo程式可以「試玩」一下，範例的展示都非常完美，可若我真的用實際上的資料或用例去測試時，就會發現這些技術真的要落地，穩定度都遠遠低於預期。自己玩玩當然是沒問題，可這實在是沒辦法推給別人用。
不說第三方開發的那些新工具，就連ChatGPT前陣子也被網友發現「變笨了」，而我自己是發現本來蠻愛用的BingChat，這陣子何止是變笨了，簡直連基本溝通能力都有點問題了。同樣的提詞，不管我怎麼調整優化，以前很ok的，現在竟然完全是無法work的了，不是品質不行，是根本連低標都不到。
有人說，AI能提升「個人」的生產力沒有問題，但是它沒有辦法大規模的提升企業的生產力。本來我有點看不懂，個人都可以了，不就等於企業的生產力也提升了嗎？技術上是這麼說沒錯，但重點不是有沒有提升，而是無法「大規模」。這有點像半導體晶片產業，美國他們很擅長設計，但他們在大規模的生產上就無法比得過台積電。「護國神山」一定累積了許多技術和經驗，才讓他們能在大規模的生產下，穩定度更好，品質更好。
其實，所謂的品質，很多時候就是指這種穩定性。
AI不一定解得了BI的問題
之前有一個服務叫TextQL，它除了可以讓我們直接說出想要的試算報表，更可以讓我們直接丟進一個Excel檔後，用自然語言說出要分析的目標為何。一開始我很開心地介紹給同事試用，這幾乎是我之前定義社團的長期目標之一，也就是「分析小助手」的實作了，我想這真的是絕佳的落地工具了吧，多少人都還是需要對Excel中的內容作分析，如果有了這個，一定可以為大家省下許多時間的。
它有一個設計很特別，就是它並不是直接解決問題，而是嘗試產出Python Code來解決問題。一開始我不太懂為什麼是這樣解決問題的？許多工具都是讓用戶直接說，然後AI把答案丟出來給用戶不是嗎？甚至我覺得這可能只是一種實作的手段而已，沒花太多時間去想。
後來，建豪在使用的過程中，發現它並沒有辦法很正確的分析他的報表（當然也就沒辦法得到他想要的答案了）。我本來以為，是不是他描述的不夠清楚？還是表格真的「長得」很奇怪？結果真的一看，覺得也還好啊，這明明應該是人類可以輕鬆理解的格式啊。結果我自己試，試了各式各樣的提詞，甚至是改造了表格自身的表現格式，來找出問題究竟在哪裡。結果是，簡單的例子和中規中矩，長得像資料庫的報表是還算穩定，只要表格中有一些「特別」的設計，它不只是有可能會辨識不出哪個是欄位，哪邊是資料。有時明明提詞是同一個，它吐出來的源碼還會有其他奇怪的結果。整個試下來，我幾乎癱坐在椅子上得到一個很無力的答案：它完全應付不了實務問題。
這個問題在「debug」的過程中，我想起另一件事，也是把一些長相為A的資料轉成長相為B的資料。結果也是很類似這樣的狀況，大部分的狀況都還可以，有時候就是有些小bug，出來的內容不是格式不對，就是內容有些跑掉。一開始想沒關係，反正是我自己用，看到結果有錯的話，自己快速修一修就好了。後來實在是受不了，明明提詞是同一個，model是同一個，不管是ChatGPT還是BingChat，都無法穩定的給我正確答案，而且我也不曉得問題出在哪裡，只能「多試個幾次」嘗試拿到正確的答案（這前提還是在我知道什麼是「正確的答案」的前提下）。我那時的想法就覺得真是夠了，這樣根本沒有省到我的心力及時間，最後索性直接叫ChatGPT產Javascriot前端程式給我，反正轉換邏輯是一樣的，我只是需要有人可以來寫這份程式。花了點時間和ChatGPT一起Cowork之後，最終這份工具到現在，都還是很穩定的解決資料的轉換需求。
我還是用BI的方式來解決AI解決不了的問題。
我總算搞懂TextQL的思路了。大語言模型的數學是國文老師教的，數字的問題最好還是讓程式語言來算。而且，整個分析的過程，除了可讓用戶知道這最後的答案是怎麼來的，若這其實會是一個常態性的報表需求，對用戶而言，一份穩定的Python源碼，才是能真正能穩定的解決問題的方法，1+1一定就是要等於2，數字可不是可以讓AI可以發揮「創意」的地方。
Plugin才是用戶看得到的，其他的都叫API
5月24日Microsoft照例舉辦了Build大會。當然，最重要的還是關於AI的相關動向。
不出意料的，Microsoft為自家所有的產品都計畫了Copilot進去。M365是之前就宣告過的，這次是除了把Azure裡的服務和Skype也都加入了Copilot，連Windows都要加入Copilot了。外行的看熱鬧，內行的就知道這真的是近乎是「射月」等級的目標。
另外一個重磅消息則是，ChatGPT的插件介面，將和上述的Copilot使用一樣的介面。意思是說，如果開發者在ChatGPT開發了一個套件，這個套件將可以同步適用在剛剛說的M365上的Copilot，也可以用在Azure上有的Copilot，甚至可以用在Windows的Copilot上！
當Copilot這個概念出現在M365上時，大部分的用戶膝反射式的念頭應該是「好棒哦，以後可以更快地完成工作了耶！」。嘖嘖募資平台策略長Manny就點出了一個重要的趨勢：接下來所有App的UI/UX的重要性將開始是一個問號。當用戶直接把需求講出來，App就可以直接完成的時候，選單在哪裡，按鍵怎麼排，一個頁面要放多少控制項，流程應該怎麼設計才會順…這些問題突然都不是問題了。或是說，這些問題都變成是軟體開發商的問題了。
當Copilot這個概念出現在Windows上時，大部分的用戶膝反射式的念頭應該不會差太多，可接下來的趨勢就更重要了：如果用戶跟作業系統的互動方式，也變成自然語言了，剛剛的M365，未來的Windows，又何嘗不是一個“更大”的ChatGPT？那Windows中內建的，或是安裝第3方的App又是什麼？
其實不都是一種插件嗎？
以前，我們要在系統中裝7-Zip來解壓縮，裝ACDSee/XnView來看圖，裝WinAmp來聽音樂，裝KMPlayer來看影片(你看看你看看…為什麼你可以喊得出那麼多骨董啊…)，這些工具用途不同，用法不同，每個工具都有所謂的「上手門檻」。可當這些工具的功能，都可以由作業系統透過自然語言直接驅動的時候，每個App幾乎就只有被調用的時候，才能出來露個臉，它們不過就是Copilot的插件而已。其他的時候用戶都不需要知道，這些App“還”能做什麼。就算這些App是純文字介面也無所謂，只要他們會知道哪個App能使命必達，能多才多藝，用戶就會喜歡一直使用它。
App的”插件化“這件事，背後有著我們不能再視而不見的問題。
除了Microsoft的Build大會外，其實OpenAI這個月也有重要更新。大多數的用戶在意的是GPT-3.5的Token數放大到16K，這很棒。對開發者而言有一個很重要的功能是「Function Calling」。簡單來說，就是OpenAI把ChatGPT「怎麼叫插件做事」這件事給正規化了，而這件事也沒那麼深奧，就是插件要在註解中明確的註明，自己能做什麼事，而這件事要呼叫哪支API來做。
當我們在做「業務小助手」的技術驗證時，發現其實最頭痛的不是AI的部分，而是知識資料的長相會千奇百怪。有的是PDF，有的是Word，有的是Excel，文件自身及內容的介面，都是我們難以預期的，如果我們沒辦法有效正規化資料的處理方式，AI再厲害也難為無米之炊；當我們在做「分析小助手」的技術驗證時，發現其實最頭痛的結果也不是AI的部分，而是我們要怎麼讓Model來“控制”競品分析系統？它根本沒有設計API要“被控制”啊！
Bezos當時在要求Amazon裡所有的資訊的流通，一律只能用API進行時，該說是他“深謀遠慮”嗎？他一定不是未卜先知，他只是在解決軟體工程的問題。但可想而知，將來Amazon一定會有許多服務，可以馬上跟Copilot串接上去被用戶使用。軟體服務怎麼被串接使用，這根本是BI的問題，而不是AI。
結合可控的BI才真的能「應用」
🐹倉鼠週報20：當AI成為人類情感的寄託 - by 李元魁 - 🐹 知識倉鼠
你有想過與 AI 機器人成為朋友嗎？也許現在我們都很排斥將情感寄託於機器人，但眾多的數據都表明，也許未來 AI 將成為我們關係網中的一員，成為我們都朋友、家人，甚至寵物。
不管是從應用領域的一些典型案例，還是多模態的應用能力演進，都可以看到同一個事實：目前真的還是在「初步思維鍊可控」。也就是說，我們若只想找看看有沒有哪個第3方應用寫得很完美及穩定，直接導入就可以大規模的優化我們的製程效率，這個想法現在可能是過早了。就像一開始我自己的經驗那樣，AI可拿來發想產生創意，也有推論能力解決問題，但只能是在「個人」的層級上。真的要落地到大規模，多模態及高複雜度的實務需求時，還是只有用我們的BI寫出來的工具，才是真的靠譜。當然，這個領域的變化一直都很快，現在我們會需要有足夠的基礎知識及實務經驗，來判斷什麼問題該用model解，什麼問題該用code解，也許過不了多久，什麼問題都有model可以解了，或是都有model可以產出程式來解。
應用社團除了會繼續關注AI技術的發展趨勢，分享成熟的小工具，增加個人層級的生產力以外，最重要的是我們還會繼續投入「Copilot」及「Plugin」的研發能力。「Copilot」是讓現有的工具更容易被使用，更多人願意用，更有生產力；而「Plugin」的開發則是為將來的「Copilot生態系」做好準備，現在已有超過400個以上的插件在ChatGPT Plus上給付費用戶使用，再過一陣子免費的用戶就會開始意識到，ChatGPT上能做的事越來越多，幾乎都不用去官網走網頁流程處理了。等到M365正式推出，Windows11的Copilot也上線了，大家看到的介面都是插件了，App的功能和官網的API都是插件的內容而已，再也不一定是用戶接觸的第一個介面了。
我們在「業務小幫手」和「ChatIGS」的投入已經幫我們取得了一些概念驗證（POC）成果。我們已有Copilot及Plugin的基礎開發能力，但還需要在「分析小助手」這個案例中做一個更大規模，更正式的開發經驗，才能確保我們有足夠的know-how，來根據產品單位需求自行開發，或是評估合適的外包或產學。
第三方開發的東西如果沒有足夠的成熟度及穩定度，那就真的是個人用用就好，別「硬用」。接下來的Roadmap是Copilot及Plugin了，它們才真的是要大規模的「應用」了，現在我們一定要趕快掌握相關的研發技術，能把我們自己的BI結合到產品的Copilot或是ChatGPT類的Plugin上，穩定工作，Get things done，那才叫「應用」。