1. 替你的應用程式加上智慧! 談 RAG 的檢索與應用

    來源: 動畫瘋, 不起眼女主角培育法 S1.EP2, 這動畫一定是在談 embedding space (咦?)..

    LLM 應用開發,來到第三篇。這篇我想談談 LLM 應用程式處理資料的做法。在 LLM 帶來很好的語言理解能力後,這需求也延伸到資料處理 (資料庫) 的領域了。這些過程跟我過去理解的資料庫正規化等等技巧,完全是不同領域啊,為了補足這段空缺,前兩篇研究完 LLM 如何替你呼叫 API 完成任務後,這篇我想以同樣角度,研究讓 LLM 能幫你找出並應用你的 DATA 的作法了。在軟體開發的領域,行為跟資料同樣重要,一直都是開發人員關注的兩大主題。補完這篇,我覺的對整個 LLM 應用開發的版圖就完整了。

    這次我拿我自己累積的文章為主的應用: “安德魯的部落格 GPTs” 來示範吧。我希望能藉著 AI 的力量,讓我的讀者們能更有效的運用 (我期待不只是閱讀) 我的文章,來解決各位開發設計上的問題。我的部落格,一直是我過去 20 年來不間斷持續維護的 side project, 我除了改善系統本身之外,也不斷地在累積文章內容,因此不論文件的質、量、儲存格式等等,我都有十足的掌控能力,拿來做這次的 PoC 再適合也不過。

    2024/03/15 系列文章: 架構師觀點 架構師觀點 技術隨筆 AI Semantic Kernel

  2. 替你的應用程式加上智慧! 談 LLM 的應用程式開發

    圖片來源: DALL-E, 這篇都是過年期間的研究心得, 就用龍(年) + 未來都市當主題吧

    上一篇文章 架構師觀點 - 開發人員該如何看待 AI 帶來的改變?,展示了我嘗試的 安德魯小舖 GPTs 整合應用,實現了讓 AI 助理的嘗試,我開始真的可以用自然語言就完成整個購買流程的操作了。過程中,AI 也幫我 “腦補” 了部分我 API 沒有提供的功能 (指定預算跟購買條件,AI 自動幫我思考購買組合)。這結果其實比我預期的還理想,完成之後,我開始探索接下來的這兩個問題:

    • 未來的應用程式,會怎麼運用 “AI” ?
    • 未來軟體開發的流程與角色,會變成甚麼樣貌?

    因此,這篇我就要面向應用程式的開發面,來探討該怎樣把 “智慧” (我暫時把 “智慧” 解讀為能理解語意的能力,拿 LLM / Large Language Model / 大型語言模型 當作代表) 加到你的應用程式內。雖然目前 LLM 還有很多缺點,但是應該開始把 LLM 當作 “人” 來看待了,溝通的方式都要把它當作 “人” 的方式溝通 (因此要善用 prompt, 而不是 function + parameters)。這其實跟傳統的軟體開發結構完全不同,也是我這篇想繼續往下挖的主題。

    2024/02/10 系列文章: 架構師觀點 架構師觀點 技術隨筆 AI Semantic Kernel

  3. [架構師觀點] 開發人員該如何看待 AI 帶來的改變?

    (圖片來源: DALL-E, 不過我參不透 AI 想表達啥 XDD)

    九年前 (2016),寫過一篇文章: .NET 開發人員該如何看待 Open Source Solutions?,當時會想寫這篇的動機很單純,那是個 Microsoft 新 CEO 剛上任, 策略大幅改變的年代, 所以我寫了這篇文章來說明我的看法。

    到了 2023, 整個軟體資訊業,都被 AI 翻了一輪,Microsoft 大舉跟進 AI 相關應用與服務,我覺得另一個軟體開發領域的大改變來了。我去年本來也打算再寫一篇,無奈當時還是個 AI 的門外漢,應該寫不出什麼東西.. 不過累積了一年,加上最近想通了一些事情,就有了這一篇文章。

    在開始講我的看法前,第一段就先來看看我的 PoC 吧,我自己刻了線上商店的 API,很單純的瀏覽商品、加入購物車、結帳這些動作。這 PoC 的重點在於,我想打造了一個 安德魯小舖 GPT 的應用專案,看看 GPTs 能否完全代替店員,讓我用聊天的方式完成整個購物的過程。

    這篇文章後面我的心得,跟我想表達的觀點,都可以從這個簡單的 PoC 得到驗證。想看我到底做了什麼 PoC 的,就繼續往下看;想直接看觀點的可以跳到 第二段 開始。

    2024/01/15 系列文章: 架構師觀點 架構師觀點 技術隨筆

  4. 架構面試題 #5: Re-Order Messages

    好久沒有來練習解題的技巧了,這次來聊個有趣的題目:

    如果我透過 API 短時間收到大量的 Request, 我如何保證訊息必須按照順序處理?

    順序問題,我常碰到的是都不分青紅皂白的就丟到 Message Queue, 結果塞進去的順序就已經不對了,才來問我順序該怎麼辦, 我只能雙手一攤說我也沒轍啊 XDD! 如果你沒辦法一開始就用對的順序放進 Message Queue,你就必須自己面對這問題了。這篇我就是想來聊聊,當 “必要” 時,你會如何處理這種問題?

    當年在學網路通訊時,TCP 跟 UPD 的差異就是會處理封包順序 & 重送問題,也剛好讀過背後的作法,你懂原理後就會有機會自己解決。類似例子其實很多,QoS 的應用也是,先前研究過的 微服務基礎建設: 斷路器 #1, 服務負載的控制 那篇,你懂 QoS 怎麼做 Rate Limit,必要時你就能自己解決商業需求。

    2023/10/01 系列文章: 架構師的修練 系列文章 架構師的修練 架構師觀點 刻意練習 抽象化

  5. 架構師觀點 - API Design Workshop

    最近這陣子,我對外分享的主題,其實都集中在 “API First” 身上。碰到一些朋友給我的 feedback, 我覺得挺有趣,我挑一個,放在這篇實做篇的最前面:

    Andrew 你談的技巧 (例如: 狀態機, 認證授權, API 開發與測試) 其實我都懂,但是為何你能把這些技巧串再一起? 用這方法來開 API Spec, 我連想都沒想過,而且外面也沒多少人是像你這樣組合起來用的… blah blah (以下省略閒聊的 800 字)

    是啊,這老兄講得沒錯啊,這的確是我自己的經驗談。我擅長的就是只靠幾樣精通的基本功夫,善加利用組合,就能拿來面對許多未知的問題。先前一篇聊職涯發展的文章,我就談到 “知識的連結”,這就是我展現出來的應用。當你每一項技巧都熟練到某種程度以上,你就有自由變化的能力了。能夠達到這種層次的技能不用太多,但是你只要多掌握一個,你能應付的範圍就是別人的好幾倍。我拿來應用在 API First 這主題,就是其中一個案例。

    API 的成功與否,規格定的好不好 (這是設計議題) 占了 70% 以上,規格定對了,後面的實做 (效能,可靠度等等) 做得好才有加分。而 API 的規格怎麼定,講白了很吃設計者的經驗。前陣子 FB 都在分享一篇 “一流工程師可以用很簡單的方法解決問題”,這情境套用在 API 的設計上再洽當也不過了。你如果能看透 API 背後要解決的問題,開出適合的介面,並且用恰到好處的技術跟工具把她實現出來,這就是個成功的 API。對我而言,我的手法就是 OOP,如何用物件導向的想法去分析 API 背後要處理的問題,然後把物件的介面 (interface) 翻譯成 API 的規格。

    因此,正文開始之前,我就加一段在正式演講都沒有談到的內容: 物件導向的思考方式 吧!

    2023/01/01 系列文章: 微服務架構 系列文章 架構師的修練 microservices