- • Site Reliability Engineer specializing in DevOps, AIOps, and Kubernetes
- • Microsoft Most Valuable Professional (MVP) since 2020
- • Active speaker at CNTUG, DevOps Taipei, GDG Taipei, and Golang Taipei
- • Passionate about Cloud, AI, and promoting DevOps/SRE best practices
AI O11y:數據決策到技術選型
📅 活動時間:2026-10-15 🔗 活動連結 📘 聯繫我 Facebook 📑 投影片 Title AI O11y:數據決策到技術選型 Outline LLM application 與 AI agent 的問題,通常不只是在服務是否存活。當模型輸出品質下降、latency 變高或成本突然增加時,團隊需要知道每一次 request 經過了哪些步驟、使用了什麼模型與 prompt,以及最後產生了什麼結果。傳統的 logging 與 metrics 往往不足以回答這些問題。 本次分享將介紹 LLM observability 的基本概念,並以 Langfuse 為例,示範如何建立 tracing、觀察 model call 與 agent workflow,從 traces 中分析品質、延遲與成本,逐步建立可供開發與維運使用的 feedback loop。 為什麼 LLM application 需要新的 observability Trace、span、generation 與 metadata 使用 Langfuse 收集與查看 LLM traces 從 tracing 分析 latency、token usage 與成本 觀察 prompt、model output 與 agent workflow Observability 的限制:如何走向 evaluation 與 decision system Demo & POC 將 LLM application 串接 Langfuse 查看單次 request 的完整 trace 比較不同模型與 prompt 的 latency、成本與輸出 從 observations 建立 dataset 與 evaluation 的起點 Target group 正在導入或維運 LLM / Agent 系統的工程團隊 關心品質、延遲、成本與上線風險的 Tech Lead / SRE / Platform Team 已有 logging 與 metrics,但缺乏 LLM tracing 的開發團隊 想使用 Langfuse 建立 AI application observability 的工程師 主要收穫 你將能理解 LLM tracing 與傳統服務 observability 的差異,使用 Langfuse 追蹤模型呼叫與 agent workflow,並從 traces 取得品質、延遲與成本分析所需的資料,為後續 evaluation 與 regression 建立基礎。 ...
AI Gateway:AI 治理的第一步
📅 活動時間:2026-10-15 🔗 活動連結 📘 聯繫我 Facebook 📑 投影片 Title AI Gateway:AI 治理的第一步 Outline 當團隊開始使用多個 LLM provider 與模型,API Key、模型路由、成本控管、權限與 tracing 很快就會分散在各個應用程式中。AI Gateway 提供一個統一入口,讓團隊能集中管理模型存取與應用流量,也讓後續的觀測、評估與治理更容易落地。 本次分享將從實務問題出發,介紹 AI Gateway 的核心能力與導入方式,並討論它能解決什麼、不能解決什麼,以及如何與 observability、evaluation 和 AI application workflow 整合。 為什麼團隊需要 AI Gateway 統一模型存取、路由與 fallback API Key、權限與成本治理 串接 tracing、logging 與 LLM observability 以實務情境設計 AI Gateway workflow 導入限制、風險與後續演進 Target group 正在導入 LLM 或 AI application 的後端與平台工程師 負責 API、雲端基礎設施與開發維運的 DevOps / SRE 想建立模型治理、成本控管與 observability 的技術主管與架構師 主要收穫 你將能理解 AI Gateway 在 LLM application architecture 中的角色,掌握模型路由、權限、成本與 tracing 的基本設計,並具備評估團隊是否適合導入 AI Gateway 的實務判斷依據。 ...
Observe and evaluate LLM Coding Agents
📅 活動時間:2026-08-09 🔗 活動連結 📘 聯繫我 Facebook 📑 投影片 Title Observe and evaluate LLM Coding Agents Outline 在導入 LLM Coding Agent 到日常開發後,很多團隊會遇到問題:品質不穩、風險難估、模型升級缺少客觀依據。本分享會從實務流程出發,介紹如何觀測 Agent 行為、把評估流程自動化,並建立可持續迭代的 decision system。 為什麼 LLM Coding Agent 需要 O11y 與 Evaluation 從 trace 開始:觀測 agent 任務、工具調用與失敗模式 Observability != Decision System:看得到不代表能決策 LLM-as-a-judge 在 coding 任務中的價值與限制 從 daily coding logs 抽取 dataset 建立 regression evaluation pipeline 與 quality gate 用量化結果比較不同模型與 agent framework 把模型升級與框架切換變成可驗證工程流程 Demo & POC https://github.com/chechiachang/llm-o11y Trace and observe local coding agents Build coding-task evals with LLM-as-a-judge Extract datasets from real developer-agent interactions Run regression tests for model / framework change decisions Target group 正在導入 AI coding workflow 的工程團隊 關心品質、成本、延遲與回歸風險的 Tech Lead / SRE / Platform Team 已有 tracing / logging,但缺少可執行評估與 deployment gate 的團隊 Slides 完整投影片與講稿 Author Che-Chia Chang 是一名專注於後端開發、開發維運、容器化應用及 Kubernetes 開發與管理的技術專家,同時也是 Microsoft 最有價值專業人士(MVP)。 ...
When Not to Vibe:從 Vibe Coding 到 Spec-driven AI Engineering 的轉折點
活動時間:2026-07-01 12:00-12:30 活動連結 聯繫我 Facebook 投影片 Title When Not to Vibe 從 Vibe Coding 到 Spec-driven AI Engineering Outline AI 讓「寫 code」變得容易,但實際在開發上,常見現象是一開始很順、越做越亂,LLM 逐步偏離設計,context 越長結果反而越不準。這不是 prompt 不夠強或模型不夠大,而是 LLM 本質上不擅長長時間、持續演進的任務。vibe coding 適合快速探索小範圍任務與短期 context,但長任務會走向失焦(loss of alignment);context window 也不是越大越好,資訊堆疊會造成 attention 稀釋,且 LLM 沒有真正長期記憶。 這場分享現實:AI 讓寫 code 變快,卻不保證長時間任務不失焦;為何 vibe coding 會在 context 拉長後 drift。並以 SpecKit 補上的結構化上下文價值、並了解其代價,以及從 spec-driven 走向 agent-driven 的實務經驗。 從 Vibe 出發:為何 LLM 在長時間任務中逐漸失焦 LLM 原理:Context 不斷堆疊,為何反而降低準確性 SpecKit 的價值:從 Prompt Chaos 到 Structured Spec 作為 Source of Truth 現實限制:Spec Tax、Drift,以及無法解決的痛點 SDD(Spec-driven Development)適用場景:PoC、Greenfield 等 從 Spec-driven 到 Agent-driven:Speckit 作為過渡形態 你將能清楚辨識 vibe coding 的有效範圍與失效訊號、理解 LLM 在長上下文下準確率下降的原因、評估 SpecKit 在實務上的收益與成本,並帶走一套可用於 PoC、Greenfield 與複雜系統規劃的導入與決策視角。 ...
LLM O11y:從 Observability 到 Decision System
📅 活動時間:2026-07-02 15:30-16:00 🔗 活動連結 📘 聯繫我 Facebook 📑 投影片 Title LLM O11y:從 Observability 到 Decision System Outline 在導入 LLM 與 Agent 開發流程時,團隊常面臨規格難以驗證、品質無法量化、以及回歸測試成本高等痛點。本分享將介紹如何在 AI Agent Coding 流程中結合 Langfuse 與 LLM-as-a-judge,將自然語言規格轉化為可執行的 evaluation,建立自動化的驗證與 feedback loop。你將學到如何使用 llm ai gateway、langfuse tracing、實作 evaluation & judge 流程、抽取 dataset,打造第一個可觀測、可量化的 AI 開發工作流,讓 Agent 系統開發更穩定、更可預測。 用 impression 做 model/framework 選擇決策。使用新 model framework 可能增加 latency 與降低可用度 從 observability 開始: bifrost + langfuse observability 還不夠:Observability != Decision System LLM-as-a-judge 的價值與限制 從 observability 到 closed-loop feedback system evaluation / dataset / regression / decision gate llm-o11y PoC:decision layer 最小可行實作 把 LLM framework 選擇,從 gambling 變成可驗證決策 Demo & POC https://github.com/chechiachang/llm-o11y ...