發表文章

使用 Dify 以No Code方式建立記帳機器人

圖片
LLM改變了軟體開發的一切 每每碰到一套新的工具或技術,我都會想把過去熟悉的例子重新實作一次,一方面有助於了解新技術的瓶頸或極限,另一方面也可以實際體驗新工具所能帶來的改變與節省的時間。針對LLM和Dify的出現,我當然也這麼做了。 過去,我們曾經出版過一本『LINE Bot與人工智慧辨識開發實戰』的書籍,內容在闡述使用LINE官方帳號和微軟的AI技術(cognitive services)進行 對談/客服 機器人的建立。當然,那是在還沒有LLM的時代。 如今LLM的出現,改變了開發對談機器人的一切。 過去書中有一個例子,我一直想拿LLM重新做一次,就是 記帳機器人 。 而且這一次,我不想再寫任何程式碼了。 記帳機器人 記帳是獲得財富自由的首要關鍵(不知道曾看到哪本書上這樣說的,但我愈來愈覺得那本書裡面的內容有一半是安慰人的,不過我們暫且擱置爭議)。關於記帳這件事情,如果能有一個隨身帳本,可以幫你記錄每一筆消費,應該是一個好的開始。 有很多app有這樣的功能,但大多數App都是透過表單輸入的方式,讓你自己輸入每一個欄位,而我希望做的這個對談機器人,要能夠直接透過自然語言輸入,就能完成記帳。例如: 剛才在加油站把油加滿,花了1200元 午餐吃了7-11的雞腿便當,130塊 用戶直接用自然語言輸入類似上面這樣的句子,記帳機器人就能夠幫我們將這些消費紀錄寫入資料庫。that’s it。 使用 Dify 開發與測試 如今,在有LLM和Dify工具的狀況下,要實現這個需求變的很容易,我們先整理一下需求,並且整理一下初步的思路。 當用戶輸入一句話,我們就丟給LLM去判斷(注意,是判斷),如果用戶在這一句話中已經包含我們所需要的所有資訊(參考底下): 金額(Amount) 商店名稱(Store) 消費項目(Item) 時間日期(DateTime) 備註(Memo) 我們就把上述消費資料轉成 JSON,然後呼叫一個 Rest API 把這消費紀錄存入資料庫。如果用戶只說了一部份,還有缺少的資料,例如: 剛才花了150元 這句話缺了消費項目與商店名稱等資訊,那我們就讓LLM持續追問,直到蒐集完所有資訊為止。 上述邏輯很簡單,而我們用Dify進行開發,過程更簡單,整個流程設計大概像是底下這樣,幾乎不用寫什麼程式碼: 上圖中的重要

使用 Dify API 快速建立一個包含前後文記憶的對談機器人

圖片
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

使用 Dify 建立企業請假機器人

圖片
八卦與未來 上個月,前Google執行長Eric Schmidt在史丹福有場演講,媒體關注的是八卦消息(如果你也曾關注,網路上有很多鐵定可以找到),但我注意到的則是他提到了自己認為接下來 AI(特別是大語言模型) 可能的發展方向,包含: Large Context Window AI Agent Text-to-Action 底下這邊有這一個段落的影片: https://www.youtube.com/watch?v=zl3k1ksFZdY 為何我會關注這部分? 因為上述的三個方向,也是身為開發人員的我,過去這一年,來與LLM打交道後的感想。昨天,我在 twMVC 的研討會分享中,展示了一個其實我過去早做過了N百次的範例,就是企業的請假機器人。(唯一不同的是,這次我幾乎沒有寫任何程式碼) 場景是,員工在家裡生病了,想要透過語音或是app進行請假,你可以看底下這個運行的範例 (git圖檔會循環播放,開始是 『我好像感冒了』): 用自然語言對談的方式,即可完成請假。 我說過,類似這樣的範例我做過很多次,用 LINE Bot 搭配 C# 做過,用MS Bot Framework 做過,前陣子也用 Semantic Kernel 框架做過,更早期,還沒有AI的時代,我也在EIP和HR系統裡做過。 但我想說的是,這 就是 Text-to-Action 的呈現,也是一個典型的 AI Agent 的例子,它讓我們透過自然語言(可以是語音或文字),直接命令機器人(Chat Bot、AI 助理、Agent、Assistant …不管你叫它什麼…)幫你完成一件事情(請假、售票、查詢資料、做財務報表、統計圖表、寫程式…etc.)。 這是一直以來人類對電腦最底層的需求與期待。 隨著 LLM 能夠處理和記憶的 Context 愈來愈被放大,AI Agent 所能夠處理的任務就更加的不受限制。 自然語言才是最符合人類直覺的操作 順帶一提,我昨天在研討會中講了一個故事。 有天,你覺得自己需要聘請一位助理,因此上網張貼徵人啟事,沒多久,你找到了一位號稱上知天文、下知地理的高材生,來幫助你更有效率的完成工作。 他什麼都好,唯一的一個小缺點是,你不能直接對這個助理下達指令,你必須用一種只有這個助理看得懂的語法,才能要求這個助理幫你完成特定的工作。這些語法還挺

使用 Dify 串接 LINE Bot

圖片
一開始寫這篇文章的時候,我有點困擾。 到底這一篇我到底該命名 『使用 Dify 串接 LINE Bot』 ,還是 『使用 LINE Bot 串接 Dify』?? 但我想,反正你應該知道我的意思,本文就是討論如何把兩者串在一起。 如果不熟悉 Dify ,本篇文章的前面還有兩邊文章你可以簡單的介紹了一下,所有連結位置在底下: https://studyhost.blogspot.com/search?q=dify 總的來說(我20年前就這麼說話了,最近有人說AI很喜歡說『總的來說』,但顯然是AI學我的),我們可以在 Dify 裡面設計一個類似底下這樣的 workflow,他可以是一個簡單的對談聊天機器人,也可以是串接到後端HR請假系統,可以協助企業進行請假的 AI 助理: 顯而易見,使用 Dify 的好處很多。而在這邊它對我們來說,意義上是一個所視即所得的 Chat Bot(AI助理)設計平台,你可以在 Dify 中先把對談流程設定好,並且進行測試。 設計初步完善之後,我們可以透過Dify API來進行串接,例如串接到 Teams Bot或是LINE Bot。API的部分我們之前在 這一篇 介紹過。 由於Dify內建處理了對談前後文與記憶的部分,並且可以直接串接OpenAI的API(或是其它LLM亦可,同時也便於抽換),這讓我們開發 AI 助理輕省不少。 這也是我覺得 Dify 作為一個 LLMOps 開發平台(Platform)應該算是當之無愧的原因了。 串接到 LINE Bot 那在Dify上開發測試完之後,我們當然希望能夠整合在 LINE Bot(或是隨便其它什麼 Bot)上面。前面說過,由於 Dify 有提供一組API,我們可以透過該API輕易地進行串接,API的部分,我們在先前 這一篇 介紹過。因此,我們底下要更進一步,談談如何實際跟 LINE Bot 整合在一起。 其實架構上不複雜,我們只需要建立一個 LINE Bot 的 WebHook ,並且在其中呼叫 Dify API即可: 也就是上圖中,紅色虛線框起來的這一段。 這部分該如何進行呢? 倒也容易,我們看底下 WebHook 的部分: var responseMsg = "" ; //準備回覆訊息 if ( LineEvent != n

在 Power Automate Desktop 中運行 Python

圖片
我是覺得 Power Automate Desktop 本身已經很強,過去幾年,MS推過這類 no code/low code 產品N次,但就像我有位好朋友才剛剛說的:『你早人家一步是先知,早人家兩步往往是烈士!』一個產品要獲得最後的成功,總是得蒐集齊了天時、地利、與人和。 我覺得這次 Power Automate Desktop 算是做得很不錯,actions 的數量和生態系頗好。我最近也幫不少企業做了 Power Automate Desktop 的教育訓練。 然而今天,居然差點被學員的一個小問題給考倒了。 有位學員碰到一個我覺得頗簡單的情境,希望能夠在 Power Automate Desktop 的流程運行中計算一個字串變數的長度。我想說這個隨便哪一種語言都能做的功能,Power Automate Desktop應該可以吧,結果,找了半天,竟然沒有!!! Power Automate Desktop中,字串相關的 actions 清單在底下: 文字動作參考 - Power Automate | Microsoft Learn 還真的沒有。 怎麼辦? 身為程式設計師的想法當然是–>那我寫 code 總可以了吧。 找到了 Run Python Script 的 action: 用的時候發現,寫code是很容易,但怎麼把變數傳進去和把計算結果傳出來,倒是花了我一點時間。原來,run python script 居然可以透過 print 來把運行結果傳出來,所以,底下這段指令可以取得 UserInput 字串,並且透過運行 Python Code 取得長度,最後設定在 PythonScriptOutput 變數中: 如此一來,不只可以取得字串長度,基本上你想幹什麼都行。底下透過三個action做一個示範,讓用戶輸入文字,然後透過 python 計算該文字的長度,最後透過對話視窗顯示出來: 最後,整個流程完整的 script 設計如下: 結果,no code solution 還是透過 code 解決了問題 🤣 後記: 這篇其實主要是想介紹在RPA中透過 Run Python Script 來實現系統中可能無法直接提供的功能。但基於RPA的精神,還是應該少寫一點code比較好。 因此,網友提供了一個比較標準的作法,可

2024 LINE Bot 帳號申請流程變革

圖片
只要活著,就會改變。 我常說,只要你待在資訊領域夠久,那『 變化 』這件事情對你來說,就絕對是家常便飯。 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),而開發商則是專注於在測試、

使用容器化技術運行 Dify

圖片
開源 一個軟體或產品,要讓人信任它最簡單的方法,就是『開源(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,直接在地端匯入: 匯

庶民 Copilot 其實也很好用 - 如何使用 Edge 內建的 Copilot 從無到有的完成一個商業企畫書

圖片
颱風天,你在幹嘛? 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 我把整個操作過程錄製了影片: 颱風天,總是得找點事情做。

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

圖片
最近上課常被問到,如何在地端環境搭建出大語言模型(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 寫出來的東西也不是聖旨,就只是當下那一刻,我們 “對需求的理解”