.NET Walker

只要活著，就會改變。 我常說，只要你待在資訊領域夠久，那『 變化 』這件事情對你來說，就絕對是家常便飯。 LINE Bot 最近的變化是，從 2024/9/4 之後，開發人員無法透過 LINE Developer Console 建立 LINE Bot 帳號囉。 過去，開發人員一般都在 LINE Developer Console 建立 LINE Bot 對談機器人( LINE Messaging API channel)，其實也就是官方帳號，為了讓入口更加一致，現在改為統一在 LINE Official Account Manager 才能建立。 如果你從 LINE Developers Console 進去，試圖建立 LINE Bot 帳號，現在會看到底下畫面： 也就是請您改為到 LINE Official Account Manager 建立，點選按鈕之後，會出現: 依照步驟建立好之後，你可以選擇暫時不要申請認證帳號: 進入管理畫面後，可以先去開啟 LINE Messaging API 功能： 這個步驟一定要做，否則，你將無法在 LINE 開發人員後台(LINE Developer Console)看到該帳號 過程中你會成功的讓該官方帳號啟用 LINE Messaging API功能，並且選擇或建立 Service Provider: 同時也可以在這邊設定 WebHook： 我自己覺得這個改變很是關鍵。 這讓對談機器人的建立主導權，從開發團隊移轉到帳號擁有者身上。這是一件好事，怎麼說呢? 過去，很多甲方的客戶(業主)並不知道其實自己就可以建立一個新的對談機器人，或是可以自行把已經建立好的官方帳號升級(加入)對談機器人的功能，以為必須透過開發商(乙方)來建立。甚至可能也不知道其實不需要開發商的介入就可以自行設定 WebHook 來改變官方帳號的自動化行為。 這導致，開發商總是用自己的公司(或工作室)名稱來幫業主申請官方帳號，徒增後續的帳號認證和管理、移轉權限的困擾。如今這樣調整之後，整個帳號建立、設定的主導權從開發商回歸官方帳號的業主身上，省去彼此間權利義務歸屬的困擾。 建議未來，都由帳號擁有者(業主、客戶)自行建立官方帳號(或是LINE Messaging API Channel)，而開發商則是專注於在測試、

開源 一個軟體或產品，要讓人信任它最簡單的方法，就是『開源(open source)』。 有時，用戶心裡會想：『我在你們這個技術上投資，萬一哪天你們整個開發團隊解散了怎麼辦? 我的投資不就打水漂了嗎? 』的確，這顧慮不無道理，產品的開發團隊也知道。 怎麼辦呢? 答案很簡單，就是『👉開源』。 怎麼讓用戶相信產品開發團隊在雲端上host的平台很正直，不會拿客戶上傳的資訊幹些什麼壞事? 答案也很簡單，又是『👉開源』。 總之呢，開源是快速獲取用戶信任的好方法。除了原始程式碼開源，最好連運行的環境也一併容器化，也開源。放上docker hub上讓大家可以免費下載。很佛心，沒錯，但它要換來的就是，你的信任和使用。 Dify 好唷，Dify 這個 2023年才開始的專案就是這麼幹的，這讓你可以比較放心這個其實只有20多人的新創團隊(而且還不是歐美血統)所開發的大語言模型 AI Agent 運行平台/框架。 Dify.AI 有一個雲端版本的 portal (如下圖)，功能面我先不在這篇文章說，這篇只講容器化，但讀者可以自行上網申請一個帳號體驗一下： 總的來說，Dify 對自己的定位是 LLMOps 平台，負責幫你代勞一堆有的沒的LLM相關整合大小事。(前面說了，這個你自己上網查或申請個帳號去體驗一下) 我們來看它如何在地端環境執行，首先，它整個專案在 GitHub上，可以透過底下指令下載： git clone https://github.com/langgenius/dify.git clone 下來之後，進到 \dify\docker 資料夾： 接著透過 docker-compose指令： docker-compose up -d 來運行，接著稀哩哩嘩啦啦的執行一陣： 接著你可以開啟 http://localhost/install ，進入整個系統的設定畫面： 設置好帳密之後，以後就可以透過 http://localhost/apps 網址登入站台囉： 整個畫面跟前面說到的 Dify.ai 網站完全相同，等於是你可以把人家整個網站 host 一份在自己的地端伺服器上，確保你的投資(例如設計的 AI Agent) 不會變成孤兒。 而我們在雲端設計好的 AI Agent，也可以透過匯出 DSL，直接在地端匯入： 匯

Dify 這個產品我就暫時先不介紹了，它找到了一個挺好的切入點跨入AI Agent市場。讓不喜歡(或不擅長)寫太多 Code 的開發人員，也可以快速的建立一個具有前後文、記憶的對談機器人。 其實若單就設計 Chat Bot 來談，它本質上和 GPTs 有那麼一點點像，你只需要給一個 system prompt ，再加上一點點的資料上傳做為 RAG 的數據來源，就可以生出一隻有模有樣的對談機器人。 但 GPTs 做出來的 Chat Bot 被綁在 ChatGPT 的 UI 裡面，你不容易把它跟 LINE Bot (LINE 官方帳號) 或其它 UI (例如 MS Teams) 串在一起，而 Dify 呢? 則給你了一個 chat-messages API，讓你能很快的實現這個功能，把你在 Dify 平台上做好的 Chat Bot 轉變成可以正式運行的 LINE Bot 或 其它 Bot。 這也是今天我們要介紹的部分。 建立 Assistant 我們先用 Dify 以底下這個 system prompt 建立了一個請假助理： 發佈後，你可以在Dify 內建的 Web UI 上測試： 你會發現，這個 chat bot 已經有著基本的記憶，然後可以依照 system prompt 完成對談和任務。 不要問我在這邊建立出一個假單有什麼用，正常情況下是要直接讓 chat bot 寫入資料庫(例如 HR 系統，直接完成請假)，只是我們還沒談到這一段，這部分以後再展開來談。 chat-messages API 好，透過上面那樣建立一個對談機器人超容易，且內建就有了記憶和前後文的功能。讓開發人員快樂的不得了。跟使用無腦 GPTs 生成術差不多。然而，如果只能在 Web 上用，不能串接 MS Teams、LINE…等介面，做了也是白搭。 但，Dify 貼心的提供了 API，我們來試試看。先Gen個 API Key： 生成了 API key 之後，你只需要透過底下這樣的 rest api，即可進行呼叫： 你會發現，開發人員只要使用單一的這一個 https://api.dify.ai/v1/chat-messages API 即可進行對談。每次只需要透過 query 輸入用戶說的話，response 中的 answer 則是 LLM (Assist

颱風天，你在幹嘛? FB上，看到我一個朋友，在颱風假前立了 Flag ，說如果放假兩天，就要寫一篇RAG技術文件。 而我呢? 則是一整天都在上課。對，沒錯，在聽課。原廠的線上即時教育訓練內容(這可沒辦法因颱風而放假)，聽了一整天印度人的英文，頭暈腦脹。想轉換一下心情，來看一下最近要上的課程。 AI-900: Microsoft Azure AI Fundamentals 隨著AI持續發酵，感覺最近有點企業AI覺醒的fu~最近排了幾堂AI-900的認證課，AI-900 是一個很基礎的Course，但內容其實算挺扎實的。從Machine Learning開始，到 Azure 上既有 AI Services，諸如人臉、圖像、語音、文字辨識…等、最後還加上了生成式 AI 的介紹。 課程的對象是一般的非開發人員，因此裡面的 Labs 大多比 AI-102 (Designing & Implementing Azure AI Solution) 來的簡單。是一個很適合初階技術人員優先入手的證照。 不過，內容簡單歸簡單，其中有幾個 Lab 我覺得還蠻實用的，底下就是其中之一： Explore Microsoft Copilot in Microsoft Edge ref 這個 Lab 介紹了如何使用 Edge 內建的 Copilot 從無到有的完成一個商業企畫書，包含使用DALL-E產生Logo，使用 Copilot 產生 Word 企劃書，加上 ppt 投影片, 以及產生專業的 outlook 信件… 這些功能本來都是需要以 M365 中的 Copilot 來完成，但畢竟 M365 的 Copilot 需要額外付費，若沒有採購的話，Edge 內建的這套 Copilot 就是不錯的替代選擇。 可能大部分人都還不知道，可以透過 Edge 內建的 Copilot 完成類似 M365 中 Copilot 的功能。 底下這就是AI-900認證考試的原廠 Lab 操作流程: Explore Microsoft Copilot in Microsoft Edge 我把整個操作過程錄製了影片： 颱風天，總是得找點事情做。

最近上課常被問到，如何在地端環境搭建出大語言模型(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