從 API First 到 AI First
Chief Architect @ 91APP
Andrew Wu
大綱: 從 API First 到 AI First - 讓 AI 有效運用 API 的設計
// AI + API
About Me - Andrew Wu
講者簡歷, 個人部落格 (https://columns.chicken-house.net/about/)
演講經歷
我的簡報習慣
AI 話題已經燒了整整一年以上了，我看到的內容大部份是...
我是軟體開發者，我想談談你開發的 “軟體” 或 "服務"，該怎麼 "使用AI" 該怎麼 "被 AI 使用" …���
這就是 API First 到 AI First 的重要環節，也是軟體開發的重要發展路徑
我是軟體開發者，我想談談你開發的 “軟體” 或 "服務"，該怎麼 "使用AI" 該怎麼 "被 AI 使用" …�// 如果我的服務也要用 AI，我該準備什麼? 我該學什麼技能? 我的軟體或服務該做什麼準備或改變?�// 我看到 LLM 開始具備 "使用工具" 的能力之後，AI 跟 API 的關聯就串起來了，突然之間有了各種可能性�
這就是 API First 到 AI First 的重要環節，也是軟體開發的重要發展路徑�// 也是在 AI 世代，軟體架構師應該要做的事 (軟體開發團隊會更加重要，但是你需要掌握相關技能)
1. 前情提要: DevOpsDays 2023 - API First
我沒講出來的背後的想法 (也就是今天的主題):
API 是服務透過現代化的方式提供的管道，給機器用的介面必須比給人用的更對準商業模式才行。API 允許比 UI 更多樣的應用，更高效率的執行。優點會被自動化放大，缺點也會。
因此技術規格，需要對準商業模式，API 才能帶來商業價值。
不過，光是這句話 "技術規格，需要對準商業模式"，就足以搞死大部分的人了。
最終:
研究商業策略的人，應該將商業模式收斂成簡單的模型，來設計公司的服務與對應的組織。
研究技術架構的人，應該定義系統間的運作模型，變成大型系統開發與協作的基礎。
兩個面向的模型必須互通，而且需要持續修正，商業策略才能順利貫通到系統運行。
回顧
BizDevOps?
BizDevOps 通常不是 "單一" 循環；一個 Biz 價值交付可能是來自多個 DevOps (team) 的總和，需要一個 "實體" (服務) 來對應 & 拆解。
團隊中負責對準這兩大模型的角色就是架構師。
如何做到持續交付模型，就是今天的主要內容。
Biz
Srv
Dev
Ops
業務需求
系統服務
實際狀況是:
團隊規模大 (200+, 20+ teams), 每個團隊都只負責部分功能, 只跑部分循環。補上中間產物才能拆解
Tech Model
CPO / CTO / Architect
PO(s) 跑的循環
Feature Team 跑的循環
Biz Model
POC
Sim
模型 (抽象)
回顧
一個老闆
20 個團隊
5 個環境
部署
Q: 這循環要怎麼跑?
三個角度都抽象化到極致，收斂成單一的技術模型，由架構師來對齊中間的落差。
LLM
我實際上在進行的案例
當你有這麼多 "組" 模型，也都各自驗證過... 你是否有能力將這些模型都組合起來?�
你只有熟練這些過程 (變成反射動作)，你才有餘力拆解成獨立的服務，交給不同的團隊負責開發，並且能扮演好用模型來驗證各個系統的開發方向是否符合產品線的設計?
�確保每個團隊做的系統，最終都能彼此合作無間，這就是架構師最重要的任務。
結帳
購物車
訂單
型錄
買什麼?
要多少錢?
你是誰?
購買紀錄
(買的順利)
(逛街)
會員
回顧
今天談的範圍: AI 在每個循環都帶來改變 ...
交付什麼價值?
怎麼有效交付?
思考如何善用 AI 提升開發效率
(開發人員+)
思考如何善用 AI 簡化系統維運
(維運人員+)
思考如何將 AI 融入你的服務之中
(客戶 & 使用者+)
我實際上在進行的案例 (2024)
結帳
購物車
訂單
型錄
買什麼?
要多少錢?
你是誰?
購買紀錄
(逛街)
會員
WEB
APP
AI - Agent
(安德魯小舖GPTs)
像人一樣對話
自然語言的UX
零售系統 API
AI - Copilot
AI - Copilot
維持既有的UX
擴充對話協助
維持既有的UX
擴充對話協助
2. 安德魯小舖 GPTs
安德魯小舖 GPTs 是什麼?
Demo #1, 出一張嘴就能買東西的魔法
Demo #1, 出一張嘴就可以買東西...
情境說明 (對話大綱):
🕐00:00�使用者詢問推薦商品，限定預算，指定商品�店長能協助加入購物車，並且結帳
🕐00:40�使用者查詢購買紀錄，並且按照期待調整呈現方式�表格改成條列 (適合手機)，從訂購紀錄統計商品數量
🕐01:10�使用者直接跟店長說明情境，由店長判定並且推薦適合商品，並且協助完成結帳
這個展示，背後做了什麼事?
1. 設置 GPTs Instruction���
2. 建立 Custom Actions���
3. 設定啟動對話�
4. 發布 GPTs�
�
1. 設置 GPTs Instruction�// 告訴 GPTs 該如何扮演好店長的角色�// (工作準則)�
2. 建立 Custom Actions�// 建立 API Service�// 設定 API 驗證機制 (OAuth)�// 設定 Open API Spec (swagger)
3. 設定啟動對話�
4. 發布 GPTs�
// 實做的技術門檻非常低�// 困難的部分都在 AI 身上 (GPT4o)
背後的 API 規格
就是來自 "商業模型" 設計而來的 API Spec
(參考前面的介紹: 我在進行的案例)
特別留意:
就是來自 "商業模型" 設計而來的 API Spec
(參考前面的介紹: 我在進行的案例)
特別留意:
降維打擊: 透過 AI 來提升使用者體驗
THINK: 你覺得 "安德魯小舖 GPTs" 的 UX 好嗎?
我沒有設計任何畫面 (UI)，也沒有優化操作流程 (Flow)
但是卻有比操作 UI 更好 (?) 的體驗...
主要的差異在於:
我沒有設計任何畫面 (UI)，也沒有優化操作流程 (Flow)
但是卻有比操作 UI 更好 (?) 的體驗...
主要的差異在於:
THINK: 你覺得 "安德魯小舖 GPTs" 的 UX 好嗎?
現在的 UX 改善，都來自厲害的 UX designer 精湛的設計…
�
然而 "安德魯小舖 GPTs" 的 UX 改變，完全是另一條路 …
��
兩者完全是不同 “維度” 的工程技術...
�
現在的 UX 改善，都來自厲害的 UX designer 精湛的設計…
// 主要是呈現在 UI 操作方式跟 Flow 的設計，作為改善的切入點�// 以大量的訪談，大量的追蹤，用數據與案例，設計師的經驗作為改善的基礎
然而 "安德魯小舖 GPTs" 的 UX 改變，完全是另一條路 …
// 來自於 "聽的懂人話" (理解使用者的意圖)�// 能應付設計規格以外的需求 (靠 Runtime, 不是靠 Design Time / Build Time)�// 這些改善的動力都來自 LLM 的進步，與背後算力的支持
兩者完全是不同 “維度” 的工程技術...
// 兩者不互相衝突，可以各自發展�// AI 有機會做到目前 UX 做不到的事
Demo #2, 偵測購買滿意度的魔法
Demo #2, 了解喜好, 判斷情緒
示範情境:
🕐00:00�使用者說明自身喜好，店長推薦商品。�店長自己記下會員摘要註記 (下次會記得)
🕐00:55�三天後使用者再次來訪，只描述情境，店長能根據使用者喜好 (上次留下的註記) + 情境給予推薦商品
🕐01:25�店長口頭給了錯誤的折扣資訊，導致使用者表達不滿。訂單的註記與消費滿意度給了 2 分，並記錄不滿意的原因
THINK (Again): 你覺得 "安德魯小舖 GPTs" 的 UX 好嗎?
我沒有設計任何滿意度問券，也沒有埋追蹤設定，來觀察統計轉換率，跳脫率等等指標�但是卻能從 LLM 解讀對話過程，得到更明確的使用者回饋...，並且可以用於個人化推薦...
主要的差異在於: 從數據統計(ML) vs 從店員有人性(LLM)的關懷
我沒有設計任何滿意度問券，也沒有埋追蹤設定，來觀察統計轉換率，跳脫率等等指標�但是卻能從 LLM 解讀對話過程，得到更明確的使用者回饋...，並且可以用於個人化推薦...
主要的差異在於: 從數據統計(ML) vs 從店員有人性(LLM)的關懷
小結
你注意到 "變革" 發生在哪裡了嗎?
API 的層面，技術完全沒有改變。差別在於 API 的設計上要開始考慮 AI 的 DX 了。
��
體驗上多了 AI 加持，就帶來了體驗與滿意度的改善，而且用的是不同以往的工程作法。
���
你注意到 "變革" 發生在哪裡了嗎?
API 的層面，技術完全沒有改變。差別在於 API 的設計上要開始考慮 AI 的 DX 了。
// 要讓 AI 看的懂，要避開 AI 的不確定性。�// 真正的 "服務" (API)，在這案例內一行都沒有改，我只是調整 "技術" 規格讓 ChatGPT 能順利使用它�// 商業應用層面完全沿用 (甚至更精簡: 我沒有給預算處理的程式碼)
體驗上多了 AI 加持，就帶來了體驗與滿意度的改善，而且用的是不同以往的工程作法。
// AI 帶來了新的抽象層級�// 在同一層級的優化會有極限的�// 多了 AI 這層服務抽象層，效果是加成的。使用得當的話能超過目前做法的極限。�// 多一個維度帶來的差距就是這麼大，站在三次元的視角你可以完全輾壓二次元的生物。
3. 軟體開發，還是你想像的樣貌嗎?
感想: AI "已知用火"
標題回收: "從 API First 到 AI First”
API First 是你能否有效運用 AI 的關鍵基礎。你必須要有 AI 能理解的 API，AI 才能成為你的得力助手:
API First 是你能否有效運用 AI 的關鍵基礎。你必須要有 AI 能理解的 API，AI 才能成為你的得力助手:
Hint: 重視 API 的設計品質是必要的
我這次的 "安德魯小舖"，去年底發行時是 v5.0.0, 過去曾經大翻過 API 四個版本，都是在 API spec 設計的不好，AI 老是無法照我預期的運作。所以 Prompt 越寫越長，AI 行為越來越難控制...
最後我想通了，AI 是按照 "常理"，"通則" 被訓練出來的，我重新按照 "常理" 把 API 梳理了一次..
對，就是去年談 API First 的那套做法:
當你開出來的規格符合 "常理" 了，AI 就看的懂了 (當然真人也看得懂了)
為什麼 "模型" 很重要?
XXX: 某某客戶實在很無理，他說 "只要改個按鈕就好了，這很簡單啊" ..，難道他不知道按鈕背後的一大堆程式跟資料庫都要跟著改嗎?
老闆 / 客戶的立場: 這改變是合理的，只是把 XXX 流程的某個步驟跳過去而已 (背後的流程都完全沒變)，所以 "只要改個按鈕就好了，這很簡單啊"
工程師的立場: 為了簡化需求開發，我特地用了 XXX 技巧，你看，程式碼只要 1/10 就夠了，而且結果剛剛好跟需求要求的一樣。我對過規格了，我們就這樣做。(這些實做設計隱含很多規格沒有提到的 "巧合" 為前提，剛好略過了部分系統 "目前" 不需要理會的邏輯)。結果老闆的這個改動，把我省略的邏輯凸顯出來了，拿掉那個按鈕假設就不對了啊... 所以 "難道他不知道按鈕背後的一大堆程式跟資料庫都要跟著改嗎?"
沒有精準扼要的模型設計，來對齊老闆 (商業模型) 與工程師 (技術模型)，你不會知道你的實做設計有沒有真的對準商業需求...。
架構師的價值，就在於建模。建立的模型，就是你對於系統的設計。
回顧
問題背後的問題:�為何客戶認知的 "異動"，跟系統實際上需要的 "異動" 落差這麼大?�有沒有可能差異早已存在，只是沒有被要求 "修改" 就沒有察覺?
再探背後的問題:�新增 "合理" 的功能會不會也很困難? �真正的問題是否是軟體開發並沒有盡量貼近客戶認同的 "模型"，只是貼近客戶要的 "結果" (規格)?
再探背後的問題:�如何照著模型開發? 如何跟客戶確認模型? 如何將模型變成規格?�
物件導向: 模擬實際世界的運作，變成電腦的理解方式並且能實際運作的科學。
如果你只看結果不看過程，那就好像司機跟乘客的關係 "殊途同歸" 。
走不同的路都能到目的地，但是花費的時間，車資可能不同。
更重要的是乘客如果想要 "順路" 去某地方，很抱歉... 我走捷徑，沒辦法!!
回顧
(設計總結) 標示所有的狀態、操作、事件
每一筆會員資料都代表一個 "會員" 的物件，存活在你的服務當中。
為什麼從狀態機開始? 因為狀態機描述了物件被 "建立"，到被 "銷毀" 的轉移過程，有中間的狀態，也有轉移的行為，非常適合拿來當作有實體資料的模型表達方式。
狀態圖的 "點"，代表了每個物件的 "狀態"；
狀態圖的 "線"，代表了狀態的轉移，背後的涵義通常是有重要的動作引發了狀態轉移，代表了每個物件的 "行為"；
由於狀態的轉移，是改變生命週期的大事，因此外界關注這物件的一舉一動，都會在意他的狀態是否有改變? 因此狀態的轉移，也代表了 "事件" 的發生。
模型對應到系統，分為資料、操作、事件。�1. 資料: DB 內的會員主資料表，必定有 ID + 狀態�2. 操作: Service 內主要的 API 清單�3. 事件: Service 內主要的回呼機制，WebHook
回顧
順序 | Scenario (who / when / what) | Caller | Action | State | 說明 |
S0-01 | 會員本人 (A) 尚未成為巴站的會員，在好好買網站上註冊。 | 會員本人 (A) | register | Unverified | 註冊帳號，尚未驗證 |
S0-01.1 | 系統偵測到註冊成功的事件後，自動發出 email 送出驗證連結 | 系統服務 (D) | event handler | Unverified | 攔截註冊成功事件，取得驗證碼送出信件 |
S0-02 | 會員本人 (A) 註冊帳號後，透過 email 驗證帳號。 | 會員本人 (A) | verify | Verified | 驗證帳號 |
S0-03 | 會員本人 (A)買完商品，選擇到超商取貨。 成立訂單後由系統本身發送簡訊通知 | 系統服務 (D) | get | Verified | 取得手機號碼，發送簡訊 |
S0-04 | 超商需要會員的手機末三碼及姓氏 (不須完整姓名) 。 | 協力廠商 (E) | get-masked | Verified | 取得遮罩過的個資 (手機末三碼，遮罩過的姓名) |
回顧
06. 將所有資訊轉成 API Spec
Actions:
POST /api/members:register
POST /api/members/{id}:verify
POST /api/members/{id}:restrict
POST /api/members/{id}:allow
POST /api/members/{id}:ban
POST /api/members/{id}:permit
POST /api/members/{id}:remove
GET /api/members/{id}
GET /api/members/{id}:reset-password
GET /api/members/{id}:verify-code
GET /api/members/{id}:masked
GET /api/members/{id}:statistics
POST /api/members/login
POST /api/members:import
Events:
state_changed
// 通常隱含在改變狀態的 action 完成時觸發
// 如果你的事件處理機制支援 topics, 則可以合併
{action}_executing
{action}_completed
// 通常不會包含所有的 action
// 主要: 改變狀態的 action
// 次要: 改變資料的 action
// 忽略: 只讀取資料的 action
回顧
06-1. 對照組, 採用 CRUD 設計的 API Spec
Actions (Domain Operation):
POST /api/members:register
POST /api/members/{id}:verify
POST /api/members/{id}:restrict
POST /api/members/{id}:allow
POST /api/members/{id}:ban
POST /api/members/{id}:permit
POST /api/members/{id}:remove
GET /api/members/{id}
GET /api/members/{id}:reset-password
GET /api/members/{id}:verify-code
GET /api/members/{id}:masked
GET /api/members/{id}:statistics
POST /api/members/login
POST /api/members:import
Actions (CRUD):
POST /api/members
// 建立會員資料, 包含匯入、註冊都算。
// 註冊後的狀態要自己更新，判斷該更新成何種狀態。
// 要從參數判斷該發出何種事件
GET /api/members/{id}
// 不同角色能讀取哪些資訊需要額外判斷
// 難以區分像是 login 這類需求的讀取功能。
// 你只能判斷密碼是否正確，而不能傳回密碼…
PATCH /api/members/{id}
// 太多種邏輯難以放到 PATCH 這功能內
// 難以區分停用帳號，重設密碼等等不同需求的更新
DELETE /api/members/{id}
// 同上, 以下省略 300 字..
身為開發者，你覺得哪一組 API 比較好用? 哪一組 API 開發上能正確引導你使用服務?
回顧
開發 AI 應用程式, 你該練習的基本功夫...
THINK: 如何訓練出一階魔法使?
AI 時代的基礎魔法: 理解 AI 怎麼處理問題
學習如何透過程式運用 LLM ( Large Language Models )
or call APIs
System Spec:
(format instructions)
User Input:
In GPTs: Instructions
In GPTs: Custom Action
// 提供 open api spec
// ( swagger )
In GPTs: User Input
// 直接對話輸入
In GPTs: Call Custom Actions (API)
// 直接對應到 Custom Action
// 生成對應的指令與參數, GPTs 直接呼叫取得結果
查詢是否有 30m 的空檔
新增跑步排程紀錄
結果回報: 已安排 9am 跑步
AI 時代的基礎魔法: 理解 AI 怎麼處理問題
重要的是 LLM 如何回應你的提問，挑選合適的模型最優先。
在真正寫 code 之前, 你可以進一步把 API Spec 抽象
步驟:
重要的是 LLM 如何回應你的提問，挑選合適的模型最優先。
// ChatGPT 是個方便的好選擇
// OpenAI 提供的 Playground 工具提供更多的設定介面
在真正寫 code 之前, 你可以進一步把 API Spec 抽象
// 抽象到你能直接在 ChatGPT 直接觀察 LLM 推演過程
步驟:
邏輯推論:
讓 AI 告訴你他會怎麼處理
(因為 LLM 的特性) AI 必須告訴你處理過程，迫使他要完成推論，會花費更多的 token，但是結果會更精確，你也有辦法核對。
// 這不是浪費 token, 而是你沒要求他可能會偷懶
當你確認了 AI 能正確的 "運用" 這些 API 時，你再真正開始開發 API 就行了
產生設計規格:
列出該有哪些頁面，需要執行那些 API
列出那些事件需要訂閱，需要執行那些操作
Demo #3, 安德魯小舖 Copilot
// Prompt Engineering
// 需要大量 "用自然語言" 寫程式的情境
GenAI 雖然令人驚豔，但是現在仍然有許多缺陷待克服..
即使你選擇當今最強的模型，生成式 AI 仍然會有幻覺，會亂掰；�推論能力也還不夠精確，無法保證結果完成正確...
�因此，要有對應的控制手段:
即使你選擇當今最強的模型，生成式 AI 仍然會有幻覺，會亂掰； // 想想 DEMO2, 憑空生出不存在的優惠�推論能力也還不夠精確，無法保證結果完成正確...
�因此，要有對應的控制手段:
AI 成為完全的 Agent 之前，先成為 Copilot …
在 AI 能 100% 成為全功能 Agent 前，都會是協作的模式 ( Copilot )。
安德魯小舖GPTs 走的是 100% 給 AI 掌控，是 Agent Mode
若要有能力控制 AI 的負責範圍，你該走的是 APP (UI) + AI 協作，是 Copilot Mode
Copilot 要能:
在 AI 能 100% 成為全功能 Agent 前，都會是協作的模式 ( Copilot )。
安德魯小舖GPTs 走的是 100% 給 AI 掌控，是 Agent Mode
若要有能力控制 AI 的負責範圍，你該走的是 APP (UI) + AI 協作，是 Copilot Mode
Copilot 要能:
Demo #3, 安德魯小舖 Copilot 版
UI
Controller
(Domain Service)
Data
Skills (API)
Instruction
(persona)
Chat History
(short mem)
Personal Information
Knowledge
(long mem)
LLM
(Copilot)
1. 由你的邏輯判定是否讓 AI 協助
2. 由使用者決定是否向 AI 求助
3. 由你決定要賦予 AI 哪些能力
4. 由你決定 AI 的做事方式
5. 由你決定 AI 的專業知識與個人化 (對使用者)
示範: (1) 由你的邏輯判定是否讓 AI 協助?
// 組裝要提交的訊息 (prompt) 內容, 置入購物車的資訊
示範: (3) 由你決定要賦予 AI 哪些能力
// 配合開發框架的寫法, 能將 C# 原生 method 標上 prompt, 讓 LLM 進行 function calling
示範: (4) Instruction, AI Persona
// 在 system prompt 約定對談的格式 (前置詞), 方便後續回應訊息處理
THINK: 你的開發流程跟 Pipeline 是否需要改變?
Q: Prompts / Instructions, 在軟體開發內算是哪個環節?
Ref: DevOpsDays Taipei 2021, 大型團隊落實 CI/CD 的挑戰 - Andrew Wu
回顧: DevOpsDays 2021
Paul Hammant’s Blog, Provisioning, Deployment and Application Config Cycles
https://paulhammant.com/2014/08/27/provisioning-deployment-and-app-config-cycles/
AI Model
as Code
(MLOps)
Demo #4, 安德魯的部落格 GPTs
安德魯的部落格 GPTs
因此，如果能搭配知識庫做成檢索服務，部署成獨立服務，提供 API ...
�
因此，如果能搭配知識庫做成檢索服務，部署成獨立服務，提供 API ...
// 結果就是 "安德魯的部落格 GPTs" 了�// 它可以用我的文章為基礎來回答你的各種問題
Demo #4, 安德魯的部落格 GPTs
情境說明 (提問內容):
🕐00:00�"我正在聽安德魯在 DevOpsDays Taipei 2024 的演講，他的演講都有連貫性，他提到過去有一系列談 API 設計的主題。��我想了解他過去在 DevOpsDays 演講，以及跟 API 設計有關的文章。請列出相關的清單給我"�
🕐00:45�"幫我彙整一下，安德魯這系列文章背後要表達的想法"�
🕐01:00�// 我幫大家問個問題...
安德魯的部落格 GPTs - 後端服務 API spec
AI 時代基礎能力的運用
善用 AI 的整合與開發能力
AI 基礎建設管理能力
善用 AI 的整合與開發能力
AI 基礎建設管理能力
"安德魯的部落格 GPTs" 檢索流程拆解
"我正在聽安德魯在 DevOpsDays Taipei 2024 的演講...."
“DevOpsDays 演講 API 設計”
{
"query": "DevOpsDays 演講 API 設計",
"noResult": false,
"results": [
{
"link": "default/post-2022-10-26/81d0efa7ce7d402c9453f50df51c078d",
"index": "default",
"documentId": "post-2022-10-26",
"fileId": "81d0efa7ce7d402c9453f50df51c078d",
"sourceContentType": "text/plain",
"sourceName": "content.txt",
"partitions": [
{
"text": "這篇的內容，是我在 DevOpsDays Taipei 2022 的 Keynote 演講的主題: DevOps 潮流下的 API First 開發策略。這場次的內容，正好是我近期正在努力的方向，演講的時間有限，沒能 100% 表達我想講的內容，於是我還是用我最習慣的方式: 文章，重新來闡述一次這個主題吧。\r\nAPI First,\r\n講的是在你的開發流程內，API 應該被擺在第一順位思考的開發策略。一開始就瞄準 API 為主軸的開發方式，你會發現整個流程跟思考方式都不一樣了，這就是我這篇想要傳達的主軸。我在第一部分先花了點篇幅，說明 API 為什麼應該要 \"First\" 的理由。API\r\n是很講究事前的規劃與設計啊，有時候會讓人有跟 DevOps 闡述 \"先交付價值，尋求回饋持續改善\" 的快速循環有所衝突的錯覺。這並非是你要做出二擇一的選擇，而是在持續改善的循環中，有沒有掌握好長期的目標的差別；而 API 的設計往往就是容易被忽略的一環。\r\n因此我多準備了一段: 就是 \"架構師在敏捷團隊中該扮演的角色\"，這是我在演講當下沒時間聊到的段落，我在文章內也把他補上了! 同樣的內容，除了 DevOpsDays Taipei 2022 Keynote (2022/09/16)",
"relevance": 0.66266865,
"partitionNumber": 0,
"sectionNumber": 0,
"lastUpdate": "2024-02-29T15:37:38+00:00",
"tags": {
"user-tags": [
"系列文章",
"架構師的修練",
"microservices"
],
"categories": [
"系列文章: 微服務架構"
],
"post-url": [
"https://columns.chicken-house.net/2022/10/26/apifirst/"
],
"post-date": [
"2022-10-26"
],
"post-title": [
"架構師觀點 - API First 的開發策略"
],
"post-content-type": []
}
},
]
}
LLM 彙整檢索的結果 (prompt)
--
#query: [xxxxxxx]
#facts:
[xxxxxxxxxx, 70%]
[xxxxxxxxxx, 66%]
[xxxxxxxxxx, 58%]
#answer:
小結
判別適合給 LLM 處理的任務
不適合給 LLM 處理維持現狀
讓你的系統有足夠的能力與彈性，各自選擇你需要的部分
4. 實際應用: 零售業的 AI 應用情境
// Generative AI 年會 - 2024, Happy Lee
實際上面對的 "商業模型" 是什麼概念?
「零售的科學」主要分享零售業的相關內容，這是一個個人部落格，全站只有我一名作者：Happy Lee（李昆謀），所有圖文也都是個人原創，花時間一點一點寫下來的，希望對大家都有所幫助。（關於作者請參考最後面）
這裡所有的內容，都是談「零售」，就算談到大數據、會員經營等議題，也都會圍繞在如何協助零售業解決問題。希望對「零售業」有興趣的朋友，可以在這些文章之中，得到對你有幫助的想法。
...... (省略 30 頁) ......
5. 總結
//
延伸思考
應用程式 + AI 值得投入，但是要想清楚怎麼用
���
掌握 AI 時代的基礎功夫
�
現在就該做的: 挑選對你有實質幫助的 AI 工具
��
應用程式 + AI 值得投入，但是要想清楚怎麼用
// 傳統的軟體架構不會消失 ( API 還是很重要 )。�// 為未來做好準備的方式是: 確保你現在的投資 在 AI 時代都能維持價值 ( 人，系統，流程 都是 )�// 例: UI 是否準備好能跟 Copilot 配合?�// 例: API 與相關資訊是否都能讓 AI 善加利用? (文件，知識庫，RAG，Tool Using，Prompt / AI Testing ?)
掌握 AI 時代的基礎功夫
// 過去: (程式設計) 資料結構 + 演算法，物件導向； (流程+文化) DevOps, CI / CD；(部署+維運) Cloud Native�// AI: LLM 相關, 相似性檢索相關, 開發框架相關, 成本 / 算力 的評估與調度能力, 提示工程, 整合能力
現在就該做的: 挑選對你有實質幫助的 AI 工具
// 盡可能用最有效率的方式，用最好的工具做事。�// 熟悉工具的運作方式，使用他之餘，也學習那個工具本身如何善用 AI ?�// 我從 GitHub Copilot 學到的東西, GitHub Copilot 比 ChatGPT 多做了什麼?
今天沒辦法談到的部分
AI 的進步會改變流程，也會改變架構，更會改變開發人員扮演的角色。
��
不要擔心被取代，掌握 AI 時代的基礎能力，善用 AI 加速迭代，抽象化後快速驗證。
�
AI 還不成熟，你還有時間準備，面對 AI 成熟的那一天到來
�
AI 的進步會改變流程，也會改變架構，更會改變開發人員扮演的角色。
// AI 產 Code → AI 用 API (Code) → 接下來會是什麼? ( AI 自己寫 code 給自己用? )�// LLM 擅長大量知識的彙整歸納，各種語言 (包含程式語言) 的無損翻譯。�// 缺的是產生 "設計" 想法，讓 AI 歸納應用翻譯的角色
不要擔心被取代，掌握 AI 時代的基礎能力，善用 AI 加速迭代，抽象化後快速驗證。
// 回顧: 不用寫 code 就能驗證設計的魔法�// 比起寫 code 寫的快，也要開始注意如何寫的對
AI 還不成熟，你還有時間準備，面對 AI 成熟的那一天到來
// 如果 AI 已經夠聰明，已經夠便宜，你會拿來做什麼?�// 如果算力 (GPU) 不再昂貴，不再限制你模型的部署與選擇，你會選擇如何部署?
心得 #1, 思考你的產品服務，未來該用 AI 強化什麼?
結帳
購物車
訂單
型錄
買什麼?
要多少錢?
你是誰?
購買紀錄
(逛街)
會員
WEB
APP
AI - Agent
(安德魯小舖GPTs)
像人一樣對話
自然語言的UX
零售系統 API
AI - Copilot
AI - Copilot
維持既有的UX
擴充對話協助
維持既有的UX
擴充對話協助
心得 #2, 思考你的技術架構，需要補足那些環節?
UI
Controller
(Domain Service)
Data
Skills (API)
Instruction
(persona)
Chat History
(short mem)
Personal Information
Knowledge
(long mem)
LLM
(Copilot)
1. 由你的邏輯判定是否讓 AI 協助
2. 由使用者決定是否向 AI 求助
3. 由你決定要賦予 AI 哪些能力
4. 由你決定 AI 的做事方式
5. 由你決定 AI 的專業知識與個人化 (對使用者)
感謝各位聆聽
# 請記得在滿意度問券給我回饋與評分
# 歡迎到 OST 對談:
13:30-14:10 ROUND 1 @ I棟數位製造區｜Andrew Wu