使用 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進行開發,過程更簡單,整個流程設計大概像是底下這樣,幾乎不用寫什麼程式碼:
圖片

上圖中的重要節點逐一說明如下:

  1. 取得今天的日期,這是為了讓LLM知道今夕是何夕,我們會將取得的日期放入一個變數中,在後續流程中丟給LLM節點(以提示詞餵入)。
  2. LLM,這部分是主要邏輯,判斷用戶輸入的句子是否包含完整資訊,如果不包含,則繼續追問,如果包含,則輸出一個JSON格式的消費紀錄:圖片
  3. 回覆用戶,這部分是Dify的標準輸出,將LLM的回應結果整理後顯示給用戶
  4. 檢查是否包含JSON,這個節點是判斷LLM節點的產出,如果內容包含JSON,顯然是表示蒐集到了足夠的消費資訊,可以進行資料庫寫入了,這個節點會把完整的JSON存入 {x} result 變數(以便於後續呼叫API寫入資料庫)
  5. IF 判斷,這邊判斷上一個節點 "檢查是否包含JSON"的輸出,如果是JSON,則 {x} result 變數不應為空,因此只需要判斷{x} result 不為空值,即可進行後續的儲存。
  6. HTTP 請求,假設 {x} result 變數不為空 ,我們就透過 HTTP Post 呼叫,把 JSON(消費紀錄) 當作參數,並呼叫執行寫入消費資料庫的Web API。(這時消費紀錄就被寫入資料庫了)
  7. 如果 API呼叫成功,則顯示成功訊息,失敗則顯示失敗訊息。

如此這般,這樣的流程設計,可以讓我們不用寫什麼程式碼,只消花一個下午的時間,就可以完成一隻記帳機器人。
我們先在 Dify 開發環境中測試一下:

資料庫的部分我們用 AirTable 暫代,由於它有內建的CRUD API,我們搭配Dify的 HTTP Request 節點即可輕鬆操作,這AirTable 工具我曾在前面介紹過。

如果你想要搭配LINE,當然也不是問題,我們先前也介紹過 Dify 如何與 LINE整合。
執行結果如下:

LINE對談中有些 JSON出現的部分,是由於我們在測試中,因此先顯示出來,給end-user實際使用的版本,當然可以隱藏掉這些訊息。

我們何時準備讓自動駕駛全面接手?

不知道你有沒有發現一件事。

除了我們用Dify開發,相較以往速度異常之快,幾乎完全不用寫程式碼之外,還有一件非常重要的事情,就是系統在解析自然語言和判斷用戶所輸入的消費資料是否足夠這一塊,完全是由LLM自行決定的,也就是說,我們把原本過去應該由人類來承擔的主要程式碼開發的這部份工作,交給了AI大語言模型。

我想說的是,AI甚至GAI時代的來臨,開發人員將會慢慢的、逐步的,把應用程式的核心邏輯hand over給AI。

幾年前,這個範例在書上我是用C#撰寫,花我最多時間的部分,當然是蒐集用戶記帳的相關資訊(像是金額、消費項目、商店名稱…等),以及自然語言判斷(也就是用戶所輸入的敘述當中,關於消費資訊的關鍵字詞解析與擷取)。

而如今,這個部分全部由AI自行承擔,過去需要撰寫的程式碼完全不見了,取而代之的就是類似底下這樣的提示詞:
圖片

也就是說,提示詞的撰寫,取代了過去我需要花幾千行程式碼才能完成的核心邏輯判斷,對身為開發人員的我,其實是有點震驚的。

但當我採用AI來完成這些事情的同時,也意味著,我把這一部份的判斷全數交給AI(而非我寫的程式碼)來進行,那我們該如何確保AI的判斷是正確的呢? 我們是否要在AI的判斷之後,加上額外的檢查或是錯誤時的補償措施呢? 是否在採取 action(例如寫入資料庫)前,要先由人類做最後的確認(confirm or approve)? 還是就允許 AI 直接寫入資料庫?

我想這些是未來的開發人員即將面對的問題。


參考 課程:
ChatGPT(Azure OpenAI) 對談機器人開發實戰

留言

這個網誌中的熱門文章

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

VS Code的字體大小

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

使用 Dify 串接 LINE Bot

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