大語言模型解鎖了最困難的問題：「為什麼？」
Bard打爆ChatGPT？ 5分鐘看完Google I/O裡AI的一切。 - YouTube
2023/05/10的Google IO大會，Google發起了一連串AI的反攻。最上層的Google Workspace如之前宣布的加入了類似M365的Copilot功能，這目前比較沒有看到什麼亮點。
Google搜尋也採取了和Bing搜尋類似的強化。會在第一頁秀出AI的回答，而且也會列出參考的網頁來源。
也就是說，之前大家的網頁如果都會在意所謂的「SEO(搜尋引擎優化)」的話，接下來可能要關注怎麼把「ARO(回答參照優化)」了。Google和Bing都沒有讓廣告消失(而且怎麼感覺”席次”還變得更少了？)。
Bard不意外的，原生就是可以連網的，不需要用什麼插件。除了不支援中文以外，可以幫用戶新增行事曆事件及設置提醒是挺讚的，不過我想它應該是只能直接設定Google的行事曆吧。可即便如此，這也是很讚很有用的功能。不過，用簡單的數學題考它，它的推論能力竟然比GPT-4還弱，這有點意外。
不過，在SchelleyYuki的評測中，一樣請這些Chatbot列出特定人士的相關資料時，Bard的優勢就顯現出來了。比起Bing Chat，Bard列出來的資訊不僅是網頁上的文字資料，甚至還列出Youtube影片中講過的訊息。這使得Bard的回答就更有深度，也更為詳細。若是要用聊天機器人來學習一些新知的話，而且可接受用英文交談的話，看來Bard可能會是最好的選擇。
SchelleyYuki繼續測試了代碼的分析能力，在刻意選用比較小眾的Haskell語言，再加上把變數名混淆後，實測BingChat和Bard對代碼的理解能力，結果還是BingChat比較強。明明PaLM的參數量(540B)比GPT4(180B)還來得多，但腦比較大雖然是比較聰明，但還是要有足夠的訓練量，才能代表真正的理解能力。
接下來還實測了代碼的寫作能力，同樣是一個Fibonacci數列的生成，BingChat的代碼十分高效，而Bard的代碼卻只是能交差了事(而且還會在那邊解釋自己寫的代碼有多好…)，這幾乎和剛剛分析代碼得到的結論一致：腦是比較大比較聰明，但並沒有受過足夠的訓練。
雖然Bard的表現不如預期，而Google Workspace的整合還沒看到，但最後要講的PaLM還是讓我有不少期待。
根據我和BingChat的討論，得知PaLM的設計是和GPT截然不同的。PaLM的「Pa」是「Pathway」的縮寫，也是PaLM的核心精神，那是代表PaLM的運算會根據輸入及輸出的目標，有不同的推論路徑。也就是說，當OpenAI需根據不同的用途及應用場景，釋出不同的Pretrain Model，像是聊天用的GPT，圖像生成用的DALL-E，寫程式用的Codex，甚至還有道德審查用的Moderation等不同的模型，PaLM的設計是讓這個模型原生就可以「動態選擇」。也就是說，當PaLM得知用戶的需求是純聊天時，它推論的「路線(Pathway)」就會往Chat的方向去，若是得知用戶的目標是產圖時，就會讓它變成產圖的推論模式，其他依此類推。
在這樣的設計下，PaLM的模型產品就沒那麼複雜了(像OpenAI有好幾個Model)，它一共就只有Gecko、Otter、Bison和Unicorn四個(由小到大排序)大小不一的模型而已，我想我們可以簡單理解為4個大小不同的腦，4個成熟(長)程度不一的腦。越大的腦代表的是學過的東西越廣越多，推論能力越好，而越小的腦就代表學過的東西少(但有基本的自然語言交談能力)，推論能力也不那麼強。因為模型已被設計為可以「動態選擇」推論的方式，所以不管用什麼樣的腦，用戶都可以餵它特定領域的資料，將其訓練為特定領域的專家。
要知道，腦不是越大就越符合產品的需求，腦越大記憶體和算力的要求就大，而且並不是什麼產品都需要「上知天文，下知地理」，所以有小一點的腦可以選是很重要的一件事。我如果只是要解決特定領域的問題，我只要選最小的腦，在手機上就可以運行，然後餵它特定領域的資料，有足夠的訓練，就可以做到離線的邊緣運算了。而且，若因應業務需求，這個腦必須學習新的領域知識，甚至接受新型態的提問或資料，我也不一定要換一個腦(除非是要求更好的推論深度)，我只要把新的資料再拿來訓練就好。不用像OpenAI的方案那樣，本來是寫代碼的，如果要有產圖的能力，就只能加一顆DALL-E進來，而不是以寫代碼的腦去增加產圖的能力(算力和記憶體要求就變大了)。
所以現在雖然Bard的能力還略遜GPT-4一籌，不過在「落地到產品應用」這個前提下，我是比較看好PaLM的。
AI將走向哪裡？
隨著大語言模型越來越成熟，回頭看看過去的需求中，「詢問(Ask)」這個一直沒有被直接滿足的需求，總是被各種工具或文件來間接滿足。可這些事前寫出來的東西，除非經過完整紮實的田野調查(Field Research)，不然其實都還是沒有辦法很完整的滿足每個用戶。用戶總是需要花上不少時間，建立該領域的背景知識，不然就是要建立該工具的背景知識，常常是兩者都要。
不管是Microsoft, Google或是我們，其實想把AI落地的方向並沒有太大的差別：用自然語言滿足用戶”說”不出來的需求。
對我們而言，我們的產品手冊或是業務訊息，為什麼還得要在一個分離的區塊，而不是跟機台整合在一起，或是跟即時通訊工具整合在一起？我們找相關窗口詢問目前專案進度，背後的理由是什麼？因為這些資訊被分開了，唯有對應的窗口才存取得到，為什麼我們不能有個統一，365天24小時都能詢問的窗口？為什麼我們都只能用文字詢問及得到回答？為什麼不是用口頭詢問？得到”口頭”回答？
那些我們曾經做過的工具，像競品分析系統，畫面上滿滿的選單和按鈕，為什麼我得先學會這個系統怎麼使用，我才能查到我想要的資訊？我得先學會”分析”這個系統的用法，我才能拿到這個分析系統的結果。為什麼我不是直接口頭這樣詢問：「我想知道【金好運】和【老子有錢】過去5個月，年輕玩家的付費比較」？而是要自己在介面上操作一番後才能拿得到分析表？
這類的問題認真細細去想，會發現數都數不完：
「為什麼遊戲中的這個規格是長這個樣子？這是要滿足新手玩家？還是要滿足大客？」
「為什麼這件事情要花上2個月做？是要做些什麼事情？」
「為什麼我們這個月的流量費用會暴增5倍？究竟是誰吃掉過多的用量？」
「為什麼我們團隊的人力這麼不夠用，每個人究竟在做什麼？哪些是不急的事情？」
每個「為什麼」都不是簡單的「If...then...」可以回答的，都需要大量的資料和推論，最終才(有機會)得到一個適當且正確的答案，這就是我們每個窗口擔任的角色及任務。當大語言模型解鎖了自然語言及推論能力後，「AI將走向哪裡？」這個問題的答案，就像AI技術社團現在將人員分成2組一樣，研發人員會拿AI解決更棘手的技術難題，而應用人員則是用來解決更多的「為什麼」。