-
從 API First 到 AI First
這篇的內容，是我在今年 DevOpsDays Taipei 2024 擔任 Keynoye 演講 + 時間不夠被我略過的部分寫下來的文章。延續 2022, 2023 談的 “API First”, 延伸到 AI 應用程式開發，正好銜接到我半年前在研究的 LLM App 時寫的三篇文章內容, 這次投稿就用了這標題 “從 API First 到 AI First” 來聊聊這內容。
各行各業的每個環節, 大家都在想怎麼善用 AI 與相關工具了, 不過開發人員把它當作服務或元件，用在自家的產品上的案例就少得多。我自己是軟體開發產業的人，我的角色是架構師，我看到的是: AI 是個強而有力的元件，只要掌握清楚它的特性，就有機會在你的應用程式好好的利用他，而這也是這半年間，我下班時間都在摸索的事情。我驗證過好幾種想法，在那段時間我的 ChatGPT plus 的額度每天都被我用光了，到現在也算是有點心得，於是就有了這個主題，也有了這場演講 & 這篇文章。
這整篇的心得，其實摘要起來只有一段話，就是:
未來 AI 充分運用在各個領域的年代，你現在的軟體開發基礎只會越來越重要。
要確保未來 AI 盛行的世代還保有競爭力，請把基礎的功夫做好。 -
替你的應用程式加上智慧! 談 RAG 的檢索與應用
來源: 動畫瘋, 不起眼女主角培育法 S1.EP2, 這動畫一定是在談 embedding space (咦?)..
LLM 應用開發，來到第三篇。這篇我想談談 LLM 應用程式處理資料的做法。在 LLM 帶來很好的語言理解能力後，這需求也延伸到資料處理 (資料庫) 的領域了。這些過程跟我過去理解的資料庫正規化等等技巧，完全是不同領域啊，為了補足這段空缺，前兩篇研究完 LLM 如何替你呼叫 API 完成任務後，這篇我想以同樣角度，研究讓 LLM 能幫你找出並應用你的 DATA 的作法了。在軟體開發的領域，行為跟資料同樣重要，一直都是開發人員關注的兩大主題。補完這篇，我覺的對整個 LLM 應用開發的版圖就完整了。
這次我拿我自己累積的文章為主的應用: “安德魯的部落格 GPTs” 來示範吧。我希望能藉著 AI 的力量，讓我的讀者們能更有效的運用 (我期待不只是閱讀) 我的文章，來解決各位開發設計上的問題。我的部落格，一直是我過去 20 年來不間斷持續維護的 side project, 我除了改善系統本身之外，也不斷地在累積文章內容，因此不論文件的質、量、儲存格式等等，我都有十足的掌控能力，拿來做這次的 PoC 再適合也不過。
-
替你的應用程式加上智慧! 談 LLM 的應用程式開發
圖片來源: DALL-E, 這篇都是過年期間的研究心得, 就用龍(年) + 未來都市當主題吧
上一篇文章 架構師觀點 - 開發人員該如何看待 AI 帶來的改變?，展示了我嘗試的 安德魯小舖 GPTs 整合應用，實現了讓 AI 助理的嘗試，我開始真的可以用自然語言就完成整個購買流程的操作了。過程中，AI 也幫我 “腦補” 了部分我 API 沒有提供的功能 (指定預算跟購買條件，AI 自動幫我思考購買組合)。這結果其實比我預期的還理想，完成之後，我開始探索接下來的這兩個問題:
- 未來的應用程式，會怎麼運用 “AI” ?
- 未來軟體開發的流程與角色，會變成甚麼樣貌?
因此，這篇我就要面向應用程式的開發面，來探討該怎樣把 “智慧” (我暫時把 “智慧” 解讀為能理解語意的能力，拿 LLM / Large Language Model / 大型語言模型 當作代表) 加到你的應用程式內。雖然目前 LLM 還有很多缺點，但是應該開始把 LLM 當作 “人” 來看待了，溝通的方式都要把它當作 “人” 的方式溝通 (因此要善用 prompt, 而不是 function + parameters)。這其實跟傳統的軟體開發結構完全不同，也是我這篇想繼續往下挖的主題。
-
[架構師觀點] 開發人員該如何看待 AI 帶來的改變?
(圖片來源: DALL-E, 不過我參不透 AI 想表達啥 XDD)九年前 (2016)，寫過一篇文章: .NET 開發人員該如何看待 Open Source Solutions?，當時會想寫這篇的動機很單純，那是個 Microsoft 新 CEO 剛上任, 策略大幅改變的年代, 所以我寫了這篇文章來說明我的看法。
到了 2023, 整個軟體資訊業，都被 AI 翻了一輪，Microsoft 大舉跟進 AI 相關應用與服務，我覺得另一個軟體開發領域的大改變來了。我去年本來也打算再寫一篇，無奈當時還是個 AI 的門外漢，應該寫不出什麼東西.. 不過累積了一年，加上最近想通了一些事情，就有了這一篇文章。
在開始講我的看法前，第一段就先來看看我的 PoC 吧，我自己刻了線上商店的 API，很單純的瀏覽商品、加入購物車、結帳這些動作。這 PoC 的重點在於，我想打造了一個 安德魯小舖 GPT 的應用專案，看看 GPTs 能否完全代替店員，讓我用聊天的方式完成整個購物的過程。
這篇文章後面我的心得，跟我想表達的觀點，都可以從這個簡單的 PoC 得到驗證。想看我到底做了什麼 PoC 的，就繼續往下看；想直接看觀點的可以跳到 第二段 開始。
-
架構面試題 #5: Re-Order Messages
好久沒有來練習解題的技巧了，這次來聊個有趣的題目:
如果我透過 API 短時間收到大量的 Request, 我如何保證訊息必須按照順序處理?
順序問題，我常碰到的是都不分青紅皂白的就丟到 Message Queue, 結果塞進去的順序就已經不對了，才來問我順序該怎麼辦, 我只能雙手一攤說我也沒轍啊 XDD! 如果你沒辦法一開始就用對的順序放進 Message Queue，你就必須自己面對這問題了。這篇我就是想來聊聊，當 “必要” 時，你會如何處理這種問題?
當年在學網路通訊時，TCP 跟 UPD 的差異就是會處理封包順序 & 重送問題，也剛好讀過背後的作法，你懂原理後就會有機會自己解決。類似例子其實很多，QoS 的應用也是，先前研究過的 微服務基礎建設: 斷路器 #1, 服務負載的控制 那篇，你懂 QoS 怎麼做 Rate Limit，必要時你就能自己解決商業需求。
