.NET Walker

最近上課常被問到，如何在地端環境搭建出大語言模型(LLM)，並且呼叫其API。 一開始我不太理解為何會有這樣的需求(因為在地端自行搭建運行LLM的成本不一定比較低，即便可能比較安全)，但被問多了，也就開始遍尋相關的解決方案，看看有沒有什麼最簡單的方式，可以讓開發人員在地端測試大語言模型? 後來我選擇 LM Studio ，它就是一款設計來運行大型語言模型（LLM）的平台，有個算是挺優雅的整合環境，讓一般 end-user 或開發人員，都可以輕易地在 local 端進行模型的部署和測試。 LM Studio 本身支援多種模型架構和框架，當然，最重要的是，它是免費的。 下載安裝 都很容易，我就不多說。 安裝好之後，你可以看到首頁中已經呈現了許多 Hugging Face上的模型： 這顯然是因為Hugging Face是大部分免費開源模型的集散地。 你可以搜尋自己喜歡的模型，透過LM Studio下載到local之後，就可以直接載入(下圖一)： 隨手設定一下 system prompt(上圖二)，然後，就可以直接對談了。(上圖三) LM Studio會使用你的GPU進行運算(如果有的話)，你會發現，原來有好的設備(GPU)，運行的速度可以如此之快。 Local Server 對於開發人員來說，它還有個超級更友善的功能。 LM Studio本身還提供一個 local server，可以幫你把模型包裹起來讓你直接透過API呼叫該模型的功能，例如： 上圖是我們開啟 LM Studio中 Local Server功能後的結果，你可以透過 localhost 的 1234 port 來呼叫這個被 LM Studio 運行起來的大語言模型。(有沒有發現，我們用的也是 chat/completions API) 透過Postman簡單提供一下 JSON Body: { "model": "LM Studio Community/Meta-Llama-3-8B-Instruct-GGUF", "messages": [ { "role": "system", "content": "你是AI助理，請一律用繁體中

問題 這幾天在上 敏捷開發與DevOps 課程時，學員問到了一個非常有意思的問題。學員這麼說： “Mike Cohn這類專家，對於User Story抱持一種用完可丟的想法（尤其是用紙本卡片時），但是團隊總會覺得有些討論過的需求沒有在 work item 之外的地方記錄時，只靠記憶力是很不可靠的。想請問老師對於紀錄專案諸項功能的需求文件，有沒有建議的作法?” 這個問題本質上，跟之前很多問到敏捷開發要不要寫文件，其實是有點類似的討論議題。 這個議題的緣由是因為，敏捷宣言中有這麼一條 “ 可用的軟體 重於 詳盡的文件 ” : 自此，開發人員分成了兩派。 一派人員認為這是指文件不需要繁瑣，但並非完全不寫文件的意思。(畢竟宣言中說的是 重於 ) 另一派人員則認為，能用的軟體才是重點，程式碼本身應該就要有高可讀性，讓程式碼足以表達傳統的系統文件想要說明的事情即可，其他文件寫了以後也是會變，寫多了根本沒用。 和以前不同，最近這幾年上課時，我都不太想挑戰大家既有的想法。但既然同學問到了，我就說說我的看法。 真需要文件? 首先，僅用 文件 兩字，來表達軟體開發中所需要記錄下來的東西，其實是不精確的。即便再怎麼概括的分類，至少也能將軟體開發的相關文件分成兩大類。 一種 是用來在開發行為發生前，描述需求的文件，這一類的文件主要是讓開發人員能夠清楚明白該怎麼開發用的； 另一種 則是在開發完成後，用來描述系統建立過程與現況的，這種文件主要是讓後續的維護人員(當然也包含開發團隊自己或後續接手加工的人)，可以方便進行系統維護或功能添加用的。 當天學員所提到的 User Story，指的是前者。你會發現其實這一類的文件，不管是 User Story, Acceptance Critiria, 或是傳統的 Requirement Spec…在敏捷開發認為需求會持續不斷改變的這個前提下，這種文件的有效性其實極低，從寫下的那一刻起，就注定了它會淘汰和快速失效的命運。 因此，你會發現敏捷開發的思路上，對於 “寫” 這類文件，實在沒什麼興趣。所以寫這類文件時，往往是愈精簡愈好，User Story 就是這類的產物， 它的主要目的也不是 “紀錄” 或 “存留”，而是 “引發溝通” 。 User Story 寫出來的東西也不是聖旨，就只是當下那一刻，我們 “對需求的理解”

昨天上課的時候，碰到詭異的事件。 我想Demo一個寫好了的範例，主要是 semantic kernel 加持下的 agent 開發，我把code run起來，開始跟agent對話： 不對，我覺得它今天有點胡言亂語。 我第一個檢查的是 GPT Model，為我知道 semantic kernel 必須使用GPT-4而不是 3.5，看了一下程式碼： var OpenAIModel = "gpt-4-turbo-preview" ; 沒錯啊，gpt-4-turbo-preview，這是 OpenAI 既有的模型，不該有問題才對。我執行的環境是 VS Code，試了半天，找不出程式碼有任何問題。只好切換到 Windows 的 Terminal，怪了，沒問題： 上面這樣的對談才是正確的結果啊! 為何在 VS Code的 Terminal 中不行呢? 請 Copilot 幫我寫了段 code 測試： 果然是 charset 的問題。 先找解決方案，測試了一下，在 vs code 當中預設的 code page 是 473，改為 950 或 65001結果一樣，沒效。 既然從外界無法解決，那就調整程式碼了。試著在指令碼中，將輸入輸出改為通用的 Unicode： //將輸入出入改為 UTF-8 Console . InputEncoding = System . Text . Encoding . Unicode ; Console . OutputEncoding = System . Text . Encoding . Unicode ; 觀察執行的結果，搞定： 除了上面的測試，Agent對談的時候也恢復正常了。 後記： 這個問題有一定的獨特性，因為我的環境是由英文版的作業系統轉為中文版，這個狀況才會發生，如果你在純中文版環境上安裝 VS Code，則根本不會出現這個問題。 儘管少見，但一開始的現象讓人摸不著頭緒，還是寫個紀錄留給未來的自己和大家參考。

LINE 在日前推出了一個功能，恰恰好適合現在許多開發人員正在設計的 - 搭配LLM(大型語言模型AI) - 的 AI 對談機器人。 這個功能 ‘Display Loading Animation’ 讓開發人員可以在LINE Bot回覆訊息前，先出現個幾秒底下這樣的圖示： 這個圖示可以設定最長顯示時間，從 5~ 60秒 之間的5的倍數均可，時間到了，會自動消失。而即便時間還沒到，如果LINE Bot(不是用戶)後面有訊息發送，動畫也會自動消失。 要讓你的 LINE Bot 出現這樣的動畫非常簡單，我們的 LineBotSDK 也在第一時間更新了，使用我們 SDK 的 C# 開發人員，現在可將 LineBotSDK更新到最新版，即可輕鬆的透過底下的程式碼，來顯示出這樣的 Loading 動畫： using isRock . LineBot ; // create bot instance var bot = new Bot ( channelAccessToken ) ; // show ladding animation var ret = bot . DisplayLoadingAnimation ( chatId , 15 ) ; // display the result Console . Write ( ret ) ; 特別是對於現在需要串接LLM(大語言模型)的Chat Bot來說，呼叫LLM的API，回應時間往往都比較長，因此，我們在 Reply 用戶的訊息前，可以先讓用戶看到這樣的，然後再呼叫LLM相關的API(像是OpenAI API)，如此一來，假設 LLM API 回覆的時間較長，用戶也比較不會有空等不耐煩的感覺。 而且這個指令執行之後，如果有 Push/Reply 的訊息發送，Loading 圖示就會自動消失，讓整個用戶的體驗不至於有突兀感。 適當的使用，會讓你的 Chat Bot 有更生動擬真的感覺，有需要的朋友可以立刻試試看。 Enjoy it. 😊

什麼是向量資料庫? 在許多的AI實作當中，都有向量資料庫的使用需求。例如RAG(檢索增強生成)、或是資料的相關性比對、相似性搜尋…等，這些應用情境中，我們都會用到向量資料庫。 向量資料庫主要的任務，當然就是存儲和查詢向量數據。被儲存的向量數據通常是高維度的資料，以陣列(集合)的形式呈現。 例如，OpenAI就有提供一組Embedding API，讓我們可以把文字給向量化。你可以透過該 API，把一句話(一段文字)轉換成向量數據，類似底下這樣： OpenAI 的這組 Embedding API，在預設狀況下，會把資料轉成 1536 維度的向量數據，其背後的行為是把文字送給一個訓練好的模型，透過該模型跑出這組向量數據，再回傳給用戶。 然而，把一段文字給向量化的目的是什麼呢? 當我們把文字做了這種轉換後，在 1536 維度的座標空間(向量數據)中，愈相似的文字，透過Embedding API會得到距離愈接近的座標點，藉此，我們得以迅速的判斷兩段文字在語意上的相似性。 而向量資料庫中所謂的查詢功能，主要就是向量的檢索，像是『近鄰搜索（Nearest Neighbor Search）』，當用戶或應用程式提交一個向量查詢時，向量資料庫會幫我們找出資料庫中，與之最相似(接近)的向量座標點。 因此，開發人員只需要透過 Embedding API，把文字轉成向量，再把轉換好的向量座標值，儲存到向量資料庫之中，未來就可以透過向量資料庫來查詢相似(接近)的文字。 關於這個部分，如果讀者有興趣，前陣子有段網路上的影片把多維度向量資料庫的概念介紹的蠻清楚的: https://www.youtube.com/watch?v=W_ZUUDJsUtA https://www.youtube.com/watch?v=ct20Kv8yn0U 為何需要? 向量資料庫最實務上的應用，就是找到類似的特徵值。 例如，當我們把人臉的特徵值以向量資料的形式儲存到向量資料庫中之後，我們就可以透過資料庫本身提供的搜尋功能，快速地尋找出相似的人臉，這也是許多AI應用實現的基礎。 我們底下的程式碼範例，則是找出最接近的問題。(呃…什麼意思?🤔 請往下繼續看) 我們在建立對談機器人時候，常常需要讓機器人回答用戶的問題。這時，我們會讓用戶輸入問句，然後透過 Embedding API

這是出乎我意料之外的事情。 今(2024)年2月中旬的一個晚上，那時才開工沒多久，大家估計還在農曆年節的休假氣氛中。我邀請了本書的三位作者，一同來我的線上直播節目接受專訪。 談論的主題，當然是過去一整年資訊界無人可忽視的 --『生成式AI』。當天精彩的訪問與對談，在這邊我暫不贅述，有興趣的朋友可以在YT頻道搜尋 『.net walker - 與微軟AI MVP大神漫談生成式AI的發展與未來』，或掃描底下QR Code觀賞。 讓我出乎我意料的是，當天即時觀看的線上人數和日後點閱的人數，雙雙突破過去的紀錄，這還是在年假剛過、開工不久、加上沒有任何廣宣的狀況下。 當時，現場網友詢問問題之熱情，讓我和三位受訪者(也就是本書的三位作者)，幾乎無法結束訪談，即便早已超過原本預定的受訪時間。 在節目現場，我的這三位好友，在我和線上網友的聯合提問夾擊之下，分享了生成式AI相關的許多重要技術概念，包含Embedding、RAG(檢索增強生成)、Semantic Kernel、向量資料庫…等，整個對談暢快淋漓、欲罷不能。 由於時間的限制，即便明知還有許多議題和網友提出的問題都還沒談到，身為主持人的我，也不得不讓三位作者暫時喘口氣。但讓人興奮的是，當天作者們分享的內容，以及後來來不及談論到的更多深入議題，都出現在您現在所看到的這本書當中。 這本書，有技術、有實務，而且有為數不少的實作範例，由三位身為微軟MVP、在AI領域首屈一指的專家們共同著作，相信對需要深入了解生成式AI應用與相關技術的你，是絕佳的選擇。 如果您遺漏了他們合著的上一本著作，這次，千萬別再錯過。 Microsoft Regional Director / Microsoft MVP / 光岩資訊資深技術顧問 董大偉

一般來說，我都是看完整本書之後，才會決定要不要推薦，能讓我還沒看完就忍不住推薦的書極少。 但『一如既往』，就是這極少中的之一。 這本書的主題很難界定，你既可以說它是在談投資、也可以說他在談經營或企管、有些內容說的是競爭、但有時候你會覺得他講的是人生。 然而重點在於，這本書寫得非常好看。 我超愛的科幻小說家倪匡，曾說過：『好看的小說非常簡單，必定要有豐富的情節、鮮活的人物，小說寫得不好看，裏面有再多的學問、道理、藝術價值，都沒有用。』 一如既往，這本書的作者厲害之處，就是他能夠把每一篇都寫得環環相扣、異常好看，然而即便我知道每篇文章的pattern，想要模仿也是很難(這是個苦功來著)。 基本上那個pattern就是…以引人入勝的故事開頭，使用對照法讓故事撐托出主題，以極具說服力的文字或數據讓主題凸顯出價值，讓讀者有所收穫，最後在最短的文字內把一篇文章總結，然後預告下一篇作者想要接著談論什麼。 就這樣，你會一篇接著一篇，不由自主的閱讀下去，每一篇，你都會有一些驚訝、會有一些省思、接著會有一些take a way。 整本書，看似信手拈來、行雲流水，一氣呵成。但我知道，這是精心設計與編排後的結果。 一本書，最要緊是好看。 好看，讓人讀得下去，裡面豐富的內容才對身為讀者的你有意義。 『一如既往』這本書做到了，而且做得很徹底。 我快看完了，看完之後，如果有時間，我還想針對裡面某幾篇特別分享，如果你等不及，不妨先找來看看。

還記得疫情那時候嗎? 有一段時間，醫療院所內的護理師面對應接不暇的來電，都是為了詢問跟疫苗有關的問題。像是: 疫苗施打的順序? 何時可以輪到我? 如果有過敏該如何選擇? 注射時應該要注意些甚麼? 我能不能不打疫苗? 諸如此類的詢問，塞爆了正常的電話掛號系統，導致許多真正需要幫忙的病患，無法得到該有的醫療資源以及諮詢，而護理師也無法專注於本來應該進行的護理工作。 這時，有些醫院開始導入對談機器人，透過手機APP或是網頁，可以讓一般民眾詢問疫苗相關的問題，並且提供正確的回覆。 當時，還沒有 ChatGPT 這樣的大型語言模型，醫院的資訊單位也不是AI領域的專家，要如何在極短的時間內，建構出一個可以準確回答用戶疫苗相關QA問題的對談機器人? 來幫助醫院在面對突乎其來的詢問電話時，可以透過分流來舒緩客服壓力? 答案，就在底下這個影片裡。我們從這個影片中可以看到，要如何在幾分鐘內，將既有的 知識庫 轉換成對談機器人，讓用戶可以直接透過網頁或手機問問題： 底下這個影片，加碼介紹如何把這個QA對談機器人，變成LINE Bot(也就是LINE官方帳號)，讓用戶只需要用LINE就可以直接得到答案： 參考 課程： https://www.studyhost.tw/NewCourses/LineBot

過去，只要上到 DevOps 課程，我就會強調單元測試在 CI/CD Pipeline中的重要性，絕對是屬於必須的(must have)。自動化頻繁交付想要不斷的交付(產生)價值，而不是不斷的產生bug，那單元測試絕對不可或缺。 你可能會想，那最近幾年，敏捷開發與DevOps這麼普及，大家都號稱能夠頻繁交付，那想必單元測試實施的比例肯定也很高，對吧? 答案是：『不，並沒有』。 因為，開發團隊不寫單元測試的理由，比寫單元測試的理由實在多太多了，例如： 測試程式本身需要花額外的時間 寫功能/趕進度 的時間都不夠了，怎麼有時間寫單元測試 不是每一個人都知道怎麼開始寫 方法(Mrthod)或類別的 相依性/耦合度 太高，難以撰寫單元測試 團隊中沒有這個氛圍，推動沒多久就無疾而終 PM或老闆不認為單元測試有價值 … 隨手都可以舉出一大堆，這些都是上課時問學員，學員真實的回答。沒辦法，每個團隊都有各自難念的經，我尊重。 不過，那是去年。 今年開始，有一個非常大的理由，讓我覺得，可以重新要求開發人員，把 Unit Test 的建立視為標配，並且放入每一個 CI Pipeline當中。 沒錯，又是AI。 現在，透過 GitHub Copilot 你可以更輕鬆的建立單元測試，你可以用 GitHub Copilot 幫你產生測試案例，也可以用 GitHub Copilot 幫你重構，或是調整主程式，以配合單元測試的運行… 過去覺得需要花費大把時間、耗費許多工夫的作業，如今 GitHub Copilot 可以幫我省去近一半的時間。卡關不知道該怎麼做的時候，還能跟 GitHub Copilot Chat 聊聊，技術問題迎刃而解。 我底下錄了一段影片，展示了如何使用 GitHub Copilot 建立單元測試。如果，你的團隊過去也屬於(有諸多原因導致)無法傳寫單元測試的一族，不妨看一下影片，或許在新的一年，將有不同的可能性出現? 參考 課程： https://www.studyhost.tw/NewCourses/ALM