https://yennj12.js.org/yennj12_blog_V4/tags/%E7%B9%81%E9%AB%94%E4%B8%AD%E6%96%87/Recent content in 繁體中文 on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSat, 27 Jun 2026 15:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/shopping-cart-high-concurrency-part1-zh/Sun, 24 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/shopping-cart-high-concurrency-part1-zh/前言 電商系統有一個非常典型的流量特徵：平時風平浪靜，一到促銷活動瞬間湧入幾千上萬個並發請求。 如果你的購物車系統跑在默認的 Spring Boot 設定上，這個瞬間幾乎必定會讓系統崩潰——不是 OOM，就是資料庫連線耗盡，要不然就是 Tomcat 執行緒池打滿、請求開始逾時。 這篇文章深入剖析我們在 PR #227 中對一個 Spring Boot 購物車系統進行的高並發改造，涵蓋三個核心技術方向： JDK 21 Virtual Threads：讓每個請求都跑在輕量級虛擬執行緒上 HikariCP 連線池調校：消除資料庫連線成為瓶頸的問題 Redis 分層快取：把熱點讀取從資料庫移到記憶體 系統架構概述 先看清楚我們在改什麼。這是一個標準的 Spring Boot 電商後端： Client (Web/App) ↓ HTTP Spring Boot API (port 9999) ├── CartController → CartService → MySQL (cart table) ├── ProductController → ProductService → MySQL (products table) ├── OrderController → OrderService → MySQL (orders/order_items) │ → Stripe API (付款) ├── UserController → UserService → MySQL (users) └── AuthController → AuthenticationService → MySQL (auth_tokens) 技術棧：Spring Boot 3.https://yennj12.js.org/yennj12_blog_V4/posts/crewai-series-part1-introduction-zh/Thu, 21 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/crewai-series-part1-introduction-zh/前言 你有沒有遇過這樣的情境？ 你想讓 AI 幫你完成一個任務，但任務太複雜，單一的 ChatGPT 對話沒辦法做好： 需要同時搜尋網路、分析資料、寫報告 不同步驟需要不同的「專業角色」 任務很長，單一 context window 放不下 CrewAI 就是為了解決這個問題而生的。它讓你可以建立一個由多個 AI Agent 組成的團隊，每個 Agent 有自己的角色、工具和目標，協作完成複雜任務。 什麼是 CrewAI？ CrewAI 是一個開源的 Python 框架，專門用來建立多 Agent 協作系統。 用一個類比來說： 傳統 LLM 呼叫：你問一個全才顧問所有問題 CrewAI：你僱用一個團隊——研究員、分析師、文案、專案經理——各司其職 CrewAI 的核心理念是角色扮演 + 任務分工： 每個 Agent 有明確的職責（role）、目標（goal）、背景故事（backstory） 任務按照依賴關係自動排序和傳遞 Crew 負責協調整個流程 CrewAI vs 其他 Multi-Agent 框架 框架 特點 學習曲線 CrewAI 角色扮演導向，強調協作，設定直覺 低 LangGraph 圖形化流程，狀態機，彈性高 中高 AutoGen Microsoft 出品，對話式協作 中 LangChain Agents 工具豐富，但單 Agent 中 CrewAI 的設計哲學：讓非工程師也能理解 Agent 的邏輯（因為你在描述一個「團隊」，而不是寫演算法）。https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part1-zh/Mon, 18 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part1-zh/前言：「準確率 90%」到底代表什麼？ 當有人告訴你「我們的 AI 模型準確率達到 90%」，你的第一個反應應該是問：「在什麼任務上？用什麼指標衡量的？」 因為一個疾病篩查模型，如果只是把所有病人都判斷為「健康」，在某些罕見疾病的數據集上，準確率照樣可以高達 99%。這樣的數字毫無意義，甚至危險。 準確率（Accuracy） 只是眾多評估指標中最基礎的一個，而且它往往不是最重要的那個。 本系列文章分三篇，帶你系統性地了解如何客觀衡量 AI 的準確度： 第一篇（本文）：分類與回歸任務的基礎評估指標 第二篇：大型語言模型（LLM）的評估方法 第三篇：RAG 檢索增強生成系統的可靠性評估 一、分類任務指標（Classification Metrics） 分類任務就是讓模型把輸入歸到某個類別，例如： 這封郵件是不是垃圾郵件？ 這張 X 光片是否顯示腫瘤？ 這則評論是正面還是負面的？ 混淆矩陣（Confusion Matrix） 一切的起點是混淆矩陣。它把模型的預測結果與真實標籤交叉對照，分成四個格子： 預測為正 預測為負 實際為正 TP（真陽性） FN（假陰性） 實際為負 FP（假陽性） TN（真陰性） TP（True Positive）：模型說「是」，實際也是「是」。✅ TN（True Negative）：模型說「否」，實際也是「否」。✅ FP（False Positive）：模型說「是」，但實際是「否」。❌（誤報） FN（False Negative）：模型說「否」，但實際是「是」。❌（漏報） 最基礎的準確率定義就是： $$\text{Accuracy} = \frac{TP + TN}{TP + TN + FP + FN}$$ 但當數據嚴重不平衡時（例如只有 1% 的郵件是垃圾郵件），全部預測為「非垃圾」就能拿到 99% 的準確率，模型根本沒在做事。 精確率（Precision）：我說的「是」有多可信？ $$\text{Precision} = \frac{TP}{TP + FP}$$ 精確率衡量的是：模型預測為正類的結果中，有多少是真的正類。 適用場景：當誤報（FP）代價很高時。 例如垃圾郵件過濾——如果系統把重要的客戶合約誤判為垃圾郵件，損失就很大。此時我們希望「被標記為垃圾的郵件」要盡量都是真的垃圾。https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part1-foundations-zh/Sat, 16 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part1-foundations-zh/前言 如果你曾經問過 ChatGPT 最新的新聞，它會告訴你它的知識有截止日期（knowledge cutoff）。 如果你問它你公司內部的文件，它完全不知道。 這是大型語言模型（LLM）的根本限制：訓練資料是靜態的。 RAG（Retrieval-Augmented Generation） 就是解決這個問題的主流方法。它讓 LLM 在回答前先「查資料」，就像一個學生考試時可以翻開參考書——而不是完全靠記憶。 這個系列共五篇，帶你從基礎到進階，完整掌握 RAG 的設計與優化。 為什麼 LLM 需要 RAG？ LLM 的三大知識限制 問題 說明 知識截止日期 模型只知道訓練時間點之前的資訊 無法存取私有資料 公司內部文件、資料庫、個人筆記都不在訓練集裡 幻覺（Hallucination） 對不確定的問題，模型會「編造」聽起來合理的答案 解法比較 方案 A：Fine-tuning（微調） 優點：模型真正「學會」知識 缺點：成本高、資料需要大量、難以更新、模型大小增加 方案 B：RAG（檢索增強生成） 優點：即時更新、成本低、可追溯來源 缺點：需要維護向量資料庫、回答品質受檢索品質影響 結論：對大多數企業應用，RAG 是更實際的選擇。Fine-tuning 適合改變模型「風格」或「推理方式」，不適合注入大量知識。 RAG 的核心架構 一個標準的 RAG 系統分成兩個主要流程： 1. 索引流程（Indexing Pipeline）— 離線執行 原始文件（PDF、Word、網頁） ↓ 文字擷取（Text Extraction） ↓ 切塊（Chunking）— 將長文件切成小片段 ↓ 向量化（Embedding）— 將文字轉成數字向量 ↓ 存入向量資料庫（Vector Store） 2. 查詢流程（Query Pipeline）— 即時執行 使用者問題（Query） ↓ 向量化（Query Embedding） ↓ 向量搜尋（Similarity Search）— 找出最相關的文件片段 ↓ 組合 Prompt（Context + Question） ↓ LLM 生成答案（Generation） ↓ 回傳給使用者 這個最基本的架構被稱為 Naive RAG（樸素 RAG）。https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part1-strategy-zh/Thu, 30 Apr 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part1-strategy-zh/前言 想像你是一家小型 AI 顧問公司的創辦人。客戶問你：「我們公司要怎麼導入 AI？」 你不可能 24 小時隨時接電話，但 AI Bot 可以。 這個系列文章將帶你從零開始，用純 Bot 建立一支能夠： 接受客戶需求、提問、釐清問題 產出顧問報告草稿 自動分派任務給不同專業角色 追蹤執行狀況並彙整成果 的 AI 顧問團隊。 本篇（第一篇）專注在策略層面：應該選哪條技術路線？各自的優缺點和適用場景是什麼？ 商業背景：我們要解決什麼問題？ 根據 ai_consultant 這個商業計劃的核心理念，AI 顧問的工作可以拆成幾個主要環節： 客戶需求輸入 → 問題釐清與診斷 → 方案設計 → 報告產出 → 執行追蹤 傳統顧問公司靠人來完成每個環節。我們的目標是： 用一組協作的 AI Agent 取代或增強每個環節，讓少數人力就能服務更多客戶。 這不是「一個超級 AI 什麼都做」，而是多個專責 Agent 分工合作的概念。 三條技術路線 路線 A：Claude Code + Skills / AGENTS.md 核心概念： 利用 Claude Code CLI 的原生 multi-agent 機制，透過 AGENTS.md（或 CLAUDE.md）定義每個 Agent 的角色、工具權限與行為邊界，搭配 Skills（可重複呼叫的 slash command 腳本）讓 Agent 之間能互相協作。https://yennj12.js.org/yennj12_blog_V4/posts/shopping-cart-high-concurrency-part2-zh/Mon, 25 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/shopping-cart-high-concurrency-part2-zh/前言 第一篇解決了系統的吞吐量問題：Virtual Threads 讓執行緒不再阻塞在 I/O 上，HikariCP 調校讓資料庫連線不再是瓶頸，Redis 快取讓熱點讀取從記憶體直接回傳。 但吞吐量提升後，反而暴露出一個更深層的問題： 並發請求同時寫入同一份資料，怎麼保證正確性？ 想像雙十一活動開始的那一秒，同一個用戶的兩個 Tab 同時按下「加入購物車」；或者同一個人網路不穩，重試了兩次「立即結帳」——這兩種場景都會導致重複訂單或資料不一致。 這篇介紹 PR #228 帶來的三個進階改造： Redisson 分散式鎖：防止同一用戶的並發寫入互相干擾 讀寫分離路由：把讀請求分流到 Replica，Primary 只處理寫入 Docker HA 水平擴展：Nginx + 多個 App 實例 + MySQL 主從複製 方案四：Redisson 分散式鎖 為什麼需要分散式鎖？ 第一篇的 CartService.addToCart() 在高並發下有一個隱患： 1// Part 1 的版本（沒有鎖） 2public void addToCart(AddToCartDto addToCartDto, Product product, User user) { 3 Cart cart = new Cart(product, addToCartDto.getQuantity(), user); 4 cartRepository.save(cart); // ← 多個執行緒可能同時執行這一行 5} 當同一個用戶同時發出兩個「加入購物車」請求時： Thread A: new Cart(productX, qty=1, user) → save → 購物車有 1 個 productX Thread B: new Cart(productX, qty=1, user) → save → 購物車有 2 個 productX（重複！） cartRepository.https://yennj12.js.org/yennj12_blog_V4/posts/crewai-series-part2-real-world-tasks-zh/Fri, 22 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/crewai-series-part2-real-world-tasks-zh/前言 上一篇我們建立了第一個 CrewAI 應用。 這篇直接進入真實工作場景，用三個完整範例展示 CrewAI 能為企業解決什麼問題。每個範例都有完整可執行的程式碼，以及設計上的關鍵決策說明。 場景一：競爭對手情報分析系統 業務背景 產品經理每週需要花 2-3 小時手動追蹤競爭對手動態：新功能、定價變化、媒體報導。這是一個重複性高、但需要一定判斷力的工作，非常適合 CrewAI 自動化。 系統設計 使用者輸入：公司名稱清單 + 分析重點 ↓ [情報收集員] 搜尋每家公司的最新動態 ↓ [分析師] 分析收集到的情報，找出威脅與機會 ↓ [報告撰寫員] 產出格式化的週報，附行動建議 完整程式碼 1import os 2from crewai import Agent, Task, Crew, Process 3from crewai_tools import SerperDevTool, ScrapeWebsiteTool 4from pydantic import BaseModel 5from typing import List 6 7os.environ["OPENAI_API_KEY"] = "your-api-key" 8os.environ["SERPER_API_KEY"] = "your-serper-key" 9 10search_tool = SerperDevTool() 11scrape_tool = ScrapeWebsiteTool() 12 13# ---- Pydantic 模型定義輸出結構 ---- 14 15class CompetitorInsight(BaseModel): 16 company: str 17 recent_news: List[str] 18 new_features: List[str] 19 pricing_changes: str 20 threat_level: str # low / medium / high 21 opportunities: List[str] 22 23class IntelligenceReport(BaseModel): 24 summary: str 25 competitors: List[CompetitorInsight] 26 key_threats: List[str] 27 recommended_actions: List[str] 28 29# ---- 定義 Agents ---- 30 31intelligence_collector = Agent( 32 role="市場情報收集員", 33 goal="系統性地收集競爭對手的最新公開資訊，確保資訊的時效性和完整性", 34 backstory="""你是一位專業的市場情報分析師，擅長從公開資源中找到有價值的競爭情報。 35 你熟悉如何在新聞、官方部落格、社群媒體、產品更新公告中尋找關鍵訊號。 36 你注重資料的來源和時效性，只引用近期（3 個月內）的資訊。""", 37 tools=[search_tool, scrape_tool], 38 llm="gpt-4o-mini", 39 verbose=True, 40 max_iter=15, 41) 42 43market_analyst = Agent( 44 role="市場策略分析師", 45 goal="分析競爭情報，識別對公司的威脅和市場機會，提供有深度的策略洞察", 46 backstory="""你是一位有豐富經驗的市場策略分析師，曾在頂尖顧問公司工作多年。 47 你擅長從零散的資訊中找出規律和趨勢，並評估其業務影響。 48 你的分析既有宏觀視野，也有具體的行動建議。""", 49 verbose=True, 50 llm="gpt-4o", 51) 52 53report_writer = Agent( 54 role="商業報告撰寫員", 55 goal="將分析結果轉化為清晰、可行動的週報，讓高層能快速掌握重點", 56 backstory="""你是一位資深的商業報告撰寫專家，了解高層主管的閱讀習慣： 57 重點先說、數據說話、建議要具體。你的報告簡潔有力，能讓繁忙的決策者 58 在 5 分鐘內掌握所有關鍵資訊。""", 59 verbose=True, 60 llm="gpt-4o", 61) 62 63# ---- 定義 Tasks ---- 64 65collection_task = Task( 66 description="""收集以下競爭對手的最近 4 週內公開資訊： 67 競爭對手清單：{competitors} 68 分析重點：{focus_areas} 69 70 對每家公司，請搜尋並整理： 71 1.https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part2-zh/Mon, 18 May 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part2-zh/前言：文字回答沒有「標準答案」 在第一篇文章中，我們討論了分類與回歸任務的評估——這些任務都有明確的真值（ground truth）可以比對。 但大型語言模型（LLM）面對的是一個根本不同的問題： 「請幫我摘要這篇報告。」 這個問題沒有唯一的正確答案。一個好的摘要可以有很多種寫法，每種都合理。那我們怎麼知道模型給出的摘要是「好」還是「差」的？ 這正是 LLM 評估最困難的地方，也是這個領域近幾年最活躍的研究方向之一。 本文將介紹四種主要的評估方法： 字面重疊指標：BLEU、ROUGE 困惑度：Perplexity 語意相似度：BERTScore 以 AI 評估 AI：LLM-as-a-Judge 一、字面重疊指標：BLEU 與 ROUGE 這是最早用於評估文字生成品質的方法，核心思路是：把 AI 的輸出與人類寫的「參考答案」做字詞重疊比較。 BLEU（Bilingual Evaluation Understudy） BLEU 最早設計用於機器翻譯評估，衡量模型輸出的 n-gram（連續 n 個字的片段）有多大比例出現在參考答案中。 計算邏輯（簡化版）： 模型輸出：The cat is sitting on the mat. 參考答案：The cat sat on the mat. 1-gram 重疊：The, cat, on, the, mat → 5/7 ≈ 71% 2-gram 重疊：The cat, on the, the mat → 3/6 = 50% BLEU 分數是多個 n-gram precision 的幾何平均，加上一個「簡短懲罰」（防止模型生成很短但精確率高的回答）。https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part2-chunking-vectordb-zh/Sun, 17 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part2-chunking-vectordb-zh/前言 上一篇我們建立了一個最基本的 RAG pipeline。 但實際上，Chunking 策略和向量資料庫的選型會直接決定你的 RAG 系統品質。 這篇深入討論這兩個核心基礎建設。 Part 1：Chunking 策略 Chunking 是把長文件切成小片段的過程。切法不對，後面的搜尋再精準也救不了。 為什麼 Chunking 很重要？ 想像你有一篇 10,000 字的技術文章，如果直接整篇丟進去，問「Python 的優點是什麼」，向量搜尋要在 10,000 字的「語意海洋」裡找到準確答案，難度極高。 好的 Chunking 原則： 每個 chunk 應該是語意完整的單元（不要切斷句子、段落中間） 大小適中：太小 → 資訊不夠完整；太大 → 搜尋精準度下降 有適度重疊（overlap）：避免邊界上的資訊遺漏 策略 1：固定大小切塊（Fixed-Size Chunking） 最簡單的方法，按字元數或 token 數切割。 1from langchain_text_splitters import CharacterTextSplitter 2 3splitter = CharacterTextSplitter( 4 chunk_size=500, 5 chunk_overlap=50, 6 separator="\n", # 優先在換行處切割 7) 8 9text = "你的長文字..." 10chunks = splitter.split_text(text) 優點：簡單、可預測、實作快速 缺點：可能把語意相關的句子切開 適合：快速原型、結構單純的文件 策略 2：遞迴字元切塊（Recursive Character Chunking） 這是最常用的預設策略。它會依照優先順序嘗試不同分隔符： \n\n → \n → .https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part2-implementation-zh/Thu, 30 Apr 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part2-implementation-zh/前言 上一篇 我們比較了三條技術路線的優缺點。本篇進入動手實作，每條路線都包含： 環境設定 角色（Agent）定義 實際執行範例 關鍵注意事項 路線 A：Claude Code + AGENTS.md + Skills 1. 環境設定 1# 安裝 Claude Code CLI 2npm install -g @anthropic-ai/claude-code 3 4# 確認版本 5claude --version 6 7# 登入（需要 Anthropic 帳號） 8claude auth login 建立專案目錄： 1mkdir ai-consultant-team && cd ai-consultant-team 2. 建立 AGENTS.md（團隊憲章） AGENTS.md 是整個 Agent 團隊的「組織架構圖」，定義各角色的職責與協作方式。 1# AI 顧問團隊 - 組織架構 2 3## 團隊宗旨 4協助中小企業做出明智的 AI 導入決策，提供從需求診斷到執行規劃的完整顧問服務。 5 6## 角色定義 7 8### Coordinator（協調員） 9- **職責**：接收初始需求，判斷複雜度，分派給對應 Agent 10- **不做**：不直接撰寫報告，不做技術分析 11- **輸出格式**：JSON，包含 task_id、assigned_agent、priority 12 13### Intake Agent（需求收集師） 14- **職責**：與客戶對話，收集結構化需求資訊 15- **問題清單**：產業、公司規模、現有系統、痛點、預算範圍、時程 16- **輸出格式**：Markdown 的需求摘要文件 17 18### Analyst Agent（問題分析師） 19- **職責**：根據需求摘要，診斷問題根源，評估 AI 導入可行性 20- **輸出格式**：包含 feasibility_score (1-10)、risks[]、opportunities[] 的分析報告 21 22### Strategist Agent（策略顧問） 23- **職責**：設計 AI 解決方案，評估 ROI，排列優先順序 24- **輸出格式**：方案比較表 + 建議路徑 25 26### Writer Agent（報告撰寫師） 27- **職責**：整合所有 Agent 的輸出，產出最終顧問報告 28- **格式**：Executive Summary + 詳細分析 + 行動計畫 3.https://yennj12.js.org/yennj12_blog_V4/posts/crewai-series-part3-advanced-flows-zh/Sat, 23 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/crewai-series-part3-advanced-flows-zh/前言 前兩篇建立了 CrewAI 的基礎和實戰應用。 這篇是進階篇，涵蓋讓 CrewAI 真正走到生產環境的關鍵技術： Flows：當 Crew 的線性流程不夠用時 Memory 記憶體：讓 Agent 記得過去的對話和經驗 錯誤處理與成本控制：生產環境的必要設計 部署：把 CrewAI 包成 API 服務 Part 1：CrewAI Flows——事件驅動的複雜工作流程 Crew 的限制 Process.sequential 是線性的：任務一個接一個執行。但真實世界的工作流程往往需要： 條件分支：根據分析結果走不同的路徑 迴圈：重複執行直到滿足條件 平行執行：多個 Crew 同時跑，最後彙整 狀態管理：跨步驟保存和傳遞複雜的狀態 CrewAI Flows 就是為了處理這些複雜場景設計的。 Flow 的三個核心 Decorator 1from crewai.flow.flow import Flow, listen, start, router 2from pydantic import BaseModel 3 4class MyFlow(Flow): 5 6 @start() 7 def step_one(self): 8 """Flow 的入口點，Flow 啟動時執行""" 9 return "step one result" 10 11 @listen(step_one) 12 def step_two(self, step_one_output): 13 """當 step_one 完成後自動觸發，可以接收上一步的輸出""" 14 return f"processed: {step_one_output}" 15 16 @router(step_two) 17 def decide_next(self, step_two_output): 18 """根據 step_two 的輸出決定下一步走哪條路""" 19 if "error" in step_two_output: 20 return "error_path" 21 return "success_path" 22 23 @listen("success_path") 24 def handle_success(self): 25 return "成功！" 26 27 @listen("error_path") 28 def handle_error(self): 29 return "處理錯誤.https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part3-zh/Mon, 18 May 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part3-zh/前言：RAG 帶來了新的評估挑戰 在第一篇和第二篇中，我們分別探討了傳統機器學習任務與 LLM 的評估方法。 現在，許多企業級 AI 應用走向了 RAG（Retrieval-Augmented Generation）架構： 用戶問題 ↓ [檢索器] → 從知識庫取出相關文件段落（Context） ↓ [LLM] → 根據 Context 生成回答 ↓ 最終答案 RAG 的評估比純 LLM 更複雜，因為它有兩個可能出錯的環節： 檢索器：有沒有找到正確的資料？ 生成器（LLM）：有沒有忠實地根據資料回答，而不是憑空幻想？ 本文將系統性地介紹 RAG 的評估框架，包括核心指標、評估工具（RAGAS），以及企業實際落地時的最佳實踐。 一、RAG 評估的三個核心維度 評估一個 RAG 系統，需要從三個維度同時切入： ┌─────────────────┐ │ 用戶問題 (Q) │ └────────┬────────┘ │ ┌──────────────▼──────────────┐ │ 檢索器 │ └──────────────┬──────────────┘ │ ┌──────────────▼──────────────┐ │ 檢索到的 Context (C) │ ← 評估維度 1：檢索品質 └──────────────┬──────────────┘ │ ┌──────────────▼──────────────┐ │ LLM 生成 │ └──────────────┬──────────────┘ │ ┌──────────────▼──────────────┐ │ 最終答案 (A) │ ← 評估維度 2：生成品質 └─────────────────────────────┘ │ ← 評估維度 3：端到端品質（Q→A） 二、核心指標詳解 2.https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part3-advanced-retrieval-zh/Mon, 18 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part3-advanced-retrieval-zh/前言 Naive RAG 的核心問題：搜尋品質決定了答案品質。 一個常見的現象是，明明知識庫裡有答案，但因為使用者的問題措辭跟文件不同，向量搜尋就找不到。或者，找到的 Top-5 結果裡，真正相關的其實排在第 4 位，LLM 因此被無關資訊干擾。 這篇介紹四個能顯著提升搜尋品質的技術。 技術 1：混合搜尋（Hybrid Search） 核心問題 純向量搜尋（Semantic Search）擅長找「語意相近」的內容，但對精確術語、專有名詞、縮寫效果差。 問題：「GPT-4o 的 context window 是多少？」 純向量搜尋找到：「大型語言模型通常有輸入長度限制...」（語意相近但沒答案） BM25 關鍵字搜尋找到：「GPT-4o 支援 128K token 的 context window」（精確命中） 混合搜尋 = 語意搜尋 + 關鍵字搜尋，兩者結果用 RRF 或加權融合。 BM25 簡介 BM25 是 TF-IDF 的改進版，計算關鍵字與文件的相關度： Score(D, Q) = Σ IDF(qi) * (tf(qi, D) * (k1 + 1)) / (tf(qi, D) + k1 * (1 - b + b * |D| / avgdl)) 不需要理解公式，只需知道：BM25 對精確詞彙匹配非常靈敏。https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part3-devops-zh/Thu, 30 Apr 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part3-devops-zh/前言 你已經建好了 AI 顧問 Agent 團隊（第一篇、第二篇），現在問題來了： 「這系統真的有在正常工作嗎？品質夠好嗎？出了問題怎麼辦？」 AI Agent 系統不像傳統軟體，你不能只看 HTTP 200。你需要評估輸出品質、追蹤推理過程、並且在 LLM 開始說廢話之前就發現它。 本篇從 DevOps/SRE 的角度，完整說明如何讓 AI 顧問團隊穩定、可觀測、持續進化。 一、系統效能評估：怎麼知道 Agent 表現好不好？ 1.1 評估的四個維度 品質（Quality） → 輸出內容是否正確、有用、符合顧問標準 速度（Latency） → 每個 Agent 節點的回應時間 成本（Cost） → 每次顧問對話的 Token 花費 可靠性（Reliability）→ 成功完成整個流程的比率 1.2 建立評估資料集（Golden Dataset） 這是最重要的第一步。準備 20-50 個有代表性的客戶案例： 1# evaluation/golden_dataset.py 2GOLDEN_CASES = [ 3 { 4 "id": "case-001", 5 "input": "我們是一家 50 人的電商公司，客服每天要處理 500 封郵件，想用 AI 減輕負擔。", 6 "expected_intake": { 7 "industry": "電商", 8 "size": "50人", 9 "pain_points": ["客服郵件量大"], 10 "ai_type": "自動化" 11 }, 12 "expected_strategy_keywords": ["聊天機器人", "郵件分類", "自動回覆"], 13 "quality_rubric": { 14 "relevance": "策略必須針對客服場景", 15 "feasibility": "建議的方案在 100 萬預算內可行", 16 "actionability": "至少有 3 個具體的下一步行動" 17 } 18 }, 19 # .https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part4-optimization-zh/Tue, 19 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part4-optimization-zh/前言 前兩篇解決了「搜尋」的問題。這篇要解決兩個更深層的問題： 問題本身就難以直接搜尋：複雜問題需要先轉換或拆解 Context 品質不夠純粹：塞給 LLM 的資訊裡有太多噪音 這裡介紹三個技術：Step-Back Prompting（退一步提問）、Self-RAG（自我反思 RAG）、Context Compression（上下文壓縮）。 技術 1：查詢轉換（Query Transformation） 問題：複雜問題無法直接搜尋 有些問題不適合直接拿來做向量搜尋： ❌ 直接搜尋困難的問題類型： 「為什麼我們公司的 API 最近變慢了？」 → 問題太具體，知識庫不可能有這個答案 「除了 Redis，還有哪些快取方案？」 → 包含否定條件，搜尋容易找到 Redis 的文章 「比較 PostgreSQL 和 MySQL 的優缺點，然後說明哪個適合我們的場景」 → 多個子問題，一次搜尋無法全部覆蓋 Step-Back Prompting（退一步提問） 核心思想：先把具體問題「退一步」抽象化，搜尋更通用的背景知識，再回答具體問題。 具體問題：「Estrogen 會影響 BRCA1 的 transcription 嗎？」 退一步：「BRCA1 基因的調控機制是什麼？」 → 先搜尋通用知識，再回答具體問題 1import openai 2 3client = openai.OpenAI(api_key="your-api-key") 4 5 6def step_back_query(original_query: str) -> str: 7 """生成一個比原始問題更抽象的退一步問題""" 8 prompt = f"""你是一個搜尋查詢優化助手。 9將以下具體問題「退一步」，改寫成一個更通用、更基本的問題， 10這個更通用的問題可以幫助找到回答原始問題所需的背景知識。 11 12具體問題：{original_query} 13 14更通用的退一步問題（只輸出問題，不要解釋）：""" 15 16 response = client.https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part4-outsourcing-zh/Thu, 30 Apr 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part4-outsourcing-zh/情境設定 公司背景： TechBridge Studio，台灣台北，10 人軟體外包公司 主要業務： 承接中小企業的網站、APP、後台系統開發 每月詢問量： 約 40-60 個潛在客戶詢問 核心痛點： PM 每天要花 3-4 小時回覆詢問、估時、報價 需求不清楚的客戶佔 70%，常常來回溝通一週才能確定範圍 報價單格式不統一，常常漏掉風險評估 客戶問進度時 PM 要手動查詢 Jira，很耗時 目標： 用 AI Agent 團隊處理 80% 的初步詢問與報價流程，讓 PM 只需審核最終結果。 整體架構設計 客戶詢問（LINE / Email / 網頁表單） ↓ ① Intake Agent（需求釐清師） → 提問 10 個標準問題，整理結構化需求 ↓ ② Scope Agent（範圍評估師） → 拆解功能清單，標記模糊需求，評估風險 ↓ ③ Estimator Agent（報價估算師） → 根據功能清單估時、報價，套用公司價目表 ↓ ④ Proposal Agent（提案撰寫師） → 產出正式提案文件（含時程、里程碑、付款條件） ↓ ⑤ PM Review（人工審核） → PM 在 5 分鐘內審核並核可 ↓ ⑥ Follow-up Agent（追蹤師） → 3 天後自動詢問客戶是否有問題，追蹤成交 技術選型 本案例使用 Claude Code + AGENTS.https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part5-production-zh/Wed, 20 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part5-production-zh/前言 你的 RAG 系統「感覺」不錯，但你能量化它有多好嗎？ 這是生產環境中最常見的盲區：工程師花大量時間優化 Chunking、調整 Reranker，卻沒有客觀的指標來驗證改動是否真的有效。 這篇是系列的最後一篇，涵蓋三個主題： RAG 評估（RAGAS）：如何量化 RAG 品質 GraphRAG：當向量搜尋不夠用時的替代方案 Agentic RAG：RAG + Agent，讓 AI 自己決定如何搜尋 Part 1：RAG 評估——RAGAS 框架 為什麼評估很難？ RAG 的輸出是自然語言，沒有標準答案可以直接比對。 「這個答案好不好」，需要從多個維度判斷。 RAGAS 的四個核心指標 RAGAS（RAG Assessment） 是目前最流行的 RAG 評估框架，定義了四個指標： 1. Faithfulness（忠實度） 答案是否只根據 context，沒有幻覺？ 計算方式： Step 1: 把答案分解成一組陳述句（claims） Step 2: 對每個陳述，判斷 context 是否支持它 Step 3: Faithfulness = 有 context 支持的陳述數 / 總陳述數 理想值：接近 1.0 2. Answer Relevancy（答案相關性） 答案是否真的回答了問題？ 計算方式： Step 1: 讓 LLM 根據答案生成 N 個「可能的問題」 Step 2: 計算這些問題與原始問題的向量相似度 Step 3: Answer Relevancy = 平均相似度 理想值：接近 1.https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part5-digital-marketing-zh/Thu, 30 Apr 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part5-digital-marketing-zh/情境設定 公司背景： PixelFlow Agency，台灣台中，8 人數位行銷公司 主要服務： 社群媒體管理、廣告投放（Meta / Google Ads）、SEO、內容行銷 服務客戶數： 同時服務 15-20 個品牌 核心痛點： 每個客戶每月需要 30-50 篇社群貼文，文案師產能跟不上 廣告成效報告每月要花 2 天手動彙整，格式各異 新客戶的「內容策略規劃」每次都要從頭寫，耗時 3-5 天 客戶問「我們這個月的廣告怎麼樣」時，帳號管理師要翻資料才能回答 目標： AI Agent 承擔 60% 的文案產出、100% 的報告彙整、80% 的策略草稿。 整體架構設計 定期觸發（每日/每週/每月）+ 客戶即時請求 ↓ ① Brand Agent（品牌守門員） → 載入品牌 DNA，確保所有輸出符合品牌調性 ↓ ┌────────────────────────────────┐ │ 並行執行（Parallel Execution） │ ├──────────────┬─────────────────┤ ② Content Agent ③ Ad Copy Agent （內容策略師） （廣告文案師） └──────────────┴─────────────────┘ ↓ ④ Analyst Agent（數據分析師） → 讀取廣告成效數據，產出洞察 ↓ ⑤ Report Agent（報告撰寫師） → 整合所有產出，製作月報/週報 ↓ ⑥ Presenter Agent（簡報師） → 把報告轉成客戶易讀的簡報格式 技術選型： 本案例使用 LangGraph + Claude API（路線 C）https://yennj12.js.org/yennj12_blog_V4/posts/stock-analysis-avav-aerovironment-part3-valuation-verdict-zh/Sat, 27 Jun 2026 15:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/stock-analysis-avav-aerovironment-part3-valuation-verdict-zh/多數人估值 AVAV 只會說「分析師喊 $305,現價 $142,上漲一倍,買!」 但 DCF 算出來只值 $123,EV/Rev 說 $160,分析師喊 $305——三個答案差超過兩倍。 大多數人不知道分析師的 $305 可能是「還沒下修的後照鏡」。 真正的功夫,是搞懂崩跌 66% 後,哪個價位才真正有安全邊際,以及 6/29 財報會把天平推向哪邊。 分析日期：2026 年 6 月 26 日 ｜ 股價：$142.35 ｜ 市值：約 $7.10B ｜ 52 週區間：$147.75 – $417.86 ⚠️ 重要時點：AVAV 將於 2026/06/29 公布 Q4 FY2026 財報——本篇所有估值情境,都須以此二元事件為前提。 本系列由 Claude Code 搭配 InvestSkill us-stock-analysis 插件生成,格式參考 Full Demo — RKLB。 所有數據為公開資料整理與模型估算,僅供教育用途,不構成投資建議。 系列導覽 本篇為 AeroVironment（AVAV）三部曲分析的第三部（完結）： （上）基本面與產業競爭力 （中）技術面、籌碼面與市場情緒 （下）估值模型與投資裁決 ← 你正在這裡 目錄 估值方法選擇與關鍵假設 DCF 估值（三情境機率加權） 敏感性分析與安全邊際 方法二：EV/Revenue 估值 方法三：本益比（P/E）估值 方法四：可比國防公司分析 足球場估值匯總 資本配置與股本稀釋分析 分析師共識對比（與下修風險） 目標價區間與情境 綜合投資裁決 一、估值方法選擇與關鍵假設 1.https://yennj12.js.org/yennj12_blog_V4/posts/stock-analysis-avav-aerovironment-part2-technical-sentiment-zh/Sat, 27 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/stock-analysis-avav-aerovironment-part2-technical-sentiment-zh/多數人看到 AVAV 跌破 $147 創 52 週新低,直覺是「下降趨勢,別碰」。 但籌碼面藏著張力：12% 的高空頭部位、機構仍重押、分析師目標價還掛在 $305——這是「墜落天使」的典型畫面。 大多數人只看到崩跌的價格,沒看到「空方擁擠 + 估值已腰斬 + 財報在即」三者疊加的爆發潛能。 真正的訊號,藏在超賣指標、空單回補天數、與 6/29 財報的交叉點上。 分析日期：2026 年 6 月 26 日 ｜ 股價：$142.35 ｜ 市值：約 $7.10B ｜ 52 週區間：$147.75 – $417.86 ⚠️ 重要時點：AVAV 將於 2026/06/29 公布 Q4 FY2026 財報——技術面與籌碼面的所有判斷,都須以此二元事件為前提。 本系列由 Claude Code 搭配 InvestSkill us-stock-analysis 插件生成,格式參考 Full Demo — RKLB。 所有數據為公開資料整理與模型估算,僅供教育用途,不構成投資建議。 系列導覽 本篇為 AeroVironment（AVAV）三部曲分析的第二部： （上）基本面與產業競爭力 （中）技術面、籌碼面與市場情緒 ← 你正在這裡 （下）估值模型與投資裁決 目錄 均線系統與趨勢判斷 支撐與阻力區間 RSI / MACD / 布林通道 成交量分析 圖表視覺化儀表板 內部人士交易分析 機構持股分析 空頭興趣與軋空潛力 總體經濟分析 市場情緒綜合判斷 一、均線系統與趨勢判斷 AVAV 是典型的「墜落天使（fallen angel）」——從 $417.https://yennj12.js.org/yennj12_blog_V4/posts/stock-analysis-avav-aerovironment-part1-fundamentals-zh/Sat, 27 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/stock-analysis-avav-aerovironment-part1-fundamentals-zh/多數人看到 AVAV 從 $417.86 崩到 $142，直覺就是「國防泡沫破了，別接刀」。 但真正該問的是：核心的 Switchblade 巡飛彈生意垮了嗎？還是只有新買的 BlueHalo 部門在拖後腿？ 大多數人被「Q3 營收大幅落空 + 財測下修」嚇跑， 但同一份財報裡，自主系統部門卻成長 >50%、Book-to-Bill 高達 1.60——故事是分裂的。 分析日期：2026 年 6 月 26 日 ｜ 股價：$142.35 ｜ 市值：約 $7.10B ｜ 52 週區間：$147.75 – $417.86 ⚠️ 重要時點：AVAV 將於 2026/06/29 公布 Q4 FY2026 財報——為近期最關鍵的催化劑 / 風險事件。 本系列由 Claude Code 搭配 InvestSkill us-stock-analysis 插件生成，格式參考 Full Demo — RKLB。 所有數據為公開資料整理與模型估算,僅供教育用途,不構成投資建議。 系列導覽 本篇為 AeroVironment（AVAV）三部曲分析的第一部： （上）基本面與產業競爭力 ← 你正在這裡 （中）技術面、籌碼面與市場情緒 （下）估值模型與投資裁決 目錄 核心問題：AVAV 為什麼從 $417 崩到 $142？ 公司概況與雙部門商業模式 損益表分析（Income Statement） 資產負債表分析（Balance Sheet） 現金流量表分析（Cash Flow） 成長性分析 Q3 FY2026 財報與 SCAR 訂單風險 財務強度評分（Piotroski 風格） 產業分析：國防無人機與巡飛彈賽道 競爭分析與護城河 基本面投資結論（上篇） 一、核心問題：AVAV 為什麼從 $417 崩到 $142？ AeroVironment（AV）是美國最純正的 戰術無人機 + 巡飛彈（loitering munition） 上市龍頭。Switchblade 系列「神風自殺式無人機」在烏克蘭戰場一戰成名，使 AVAV 成為 2024–2025 年國防主題的當紅炸子雞，股價一路狂飆到 $417.https://yennj12.js.org/yennj12_blog_V4/posts/stock-analysis-pl-planet-labs-part3-valuation-verdict-zh/Sat, 27 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/stock-analysis-pl-planet-labs-part3-valuation-verdict-zh/多數人估值 PL 只會丟一句「市銷率 20 倍，太貴」。 但 DCF 告訴你純現金流值 $18，相對估值告訴你值 $30，分析師喊到 $39.80——三個答案差兩倍。 大多數人不知道該信哪一個，於是乾脆不做決定。 真正的功夫，是理解每個模型在「衡量什麼」，再用機率加權拼出一個誠實的合理區間。 分析日期：2026 年 6 月 26 日 ｜ 股價：$28.42 ｜ 市值：約 $9.4B ｜ 52 週區間：$5.52 – $51.76 本系列由 Claude Code 搭配 InvestSkill us-stock-analysis 插件生成，格式參考 Full Demo — RKLB。 所有數據為公開資料整理與模型估算，僅供教育用途，不構成投資建議。 系列導覽 本篇為 Planet Labs（PL）三部曲分析的第三部（完結）： （上）基本面與產業競爭力 （中）技術面、籌碼面與市場情緒 （下）估值模型與投資裁決 ← 你正在這裡 目錄 估值方法選擇與關鍵假設 DCF 估值（三情境機率加權） 敏感性分析與安全邊際 方法二：P/S 倍數估值 方法三：EV/Revenue 估值 方法四：可比公司分析（CCA） 足球場估值匯總 股息與資本配置分析 分析師共識對比 目標價區間與情境 綜合投資裁決 一、估值方法選擇與關鍵假設 1.1 為什麼 PL 要用「多模型 + 機率加權」？ PL 正卡在「成長股」與「剛轉正企業」之間，單一模型都會失真：https://yennj12.js.org/yennj12_blog_V4/posts/stock-analysis-pl-planet-labs-part2-technical-sentiment-zh/Sat, 27 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/stock-analysis-pl-planet-labs-part2-technical-sentiment-zh/多數人看到 PL 從 $51.76 腰斬到 $28，就斷定「趨勢壞了」。 但籌碼面說的是另一個故事：機構持股 432 家、Alphabet 在列、空頭僅 9%——這不是恐慌出貨的型態。 大多數人只看價格，忽略了「誰在買、誰在賣、為什麼股價在這裡盤整」。 真正的訊號藏在均線、空單天數、與國防預算週期的交叉點上。 分析日期：2026 年 6 月 26 日 ｜ 股價：$28.42 ｜ 市值：約 $9.4B ｜ 52 週區間：$5.52 – $51.76 本系列由 Claude Code 搭配 InvestSkill us-stock-analysis 插件生成，格式參考 Full Demo — RKLB。 所有數據為公開資料整理與模型估算，僅供教育用途，不構成投資建議。 系列導覽 本篇為 Planet Labs（PL）三部曲分析的第二部： （上）基本面與產業競爭力 （中）技術面、籌碼面與市場情緒 ← 你正在這裡 （下）估值模型與投資裁決 目錄 均線系統與趨勢判斷 支撐與阻力區間 RSI / MACD / 布林通道 成交量分析 圖表視覺化儀表板 內部人士交易分析 機構持股分析 空頭興趣分析 總體經濟分析 市場情緒綜合判斷 一、均線系統與趨勢判斷 PL 與（上篇 RKLB 範例中那種「多頭完美排列」的標的）完全不同——它剛經歷一次主升段後的大幅回檔，技術面進入「高檔修正 / 中期盤整」階段。https://yennj12.js.org/yennj12_blog_V4/posts/stock-analysis-pl-planet-labs-part1-fundamentals-zh/Sat, 27 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/stock-analysis-pl-planet-labs-part1-fundamentals-zh/多數人看到 PL 從 $51.76 高點回落到 $28，直覺反應是「動能股泡沫破了，閃」。 但真正該問的是：這家公司是不是剛從「燒錢的太空夢」轉成「有現金流的國防數據工廠」？ 大多數人盯著 GAAP 一季虧 $1.39 億的數字嚇跑， 但其中 $1.065 億是認股權證重估的非現金損失——撥開帳面雜訊，故事完全不同。 分析日期：2026 年 6 月 26 日 ｜ 股價：$28.42 ｜ 市值：約 $9.4B ｜ 52 週區間：$5.52 – $51.76 本系列由 Claude Code 搭配 InvestSkill us-stock-analysis 插件生成，格式參考 Full Demo — RKLB。 所有數據為公開資料整理與模型估算，僅供教育用途，不構成投資建議。 系列導覽 本篇為 Planet Labs（PL）三部曲分析的第一部： （上）基本面與產業競爭力 ← 你正在這裡 （中）技術面、籌碼面與市場情緒 （下）估值模型與投資裁決 目錄 核心問題：PL 到底是什麼生意？ 公司概況與商業模式 損益表分析（Income Statement） 資產負債表分析（Balance Sheet） 現金流量表分析（Cash Flow） 成長性分析 Q1 FY2027 財報電話會議分析 財務強度評分（Piotroski 風格） 產業分析：對地觀測賽道 競爭分析與護城河 基本面投資結論（上篇） 一、核心問題：PL 到底是什麼生意？ Planet Labs PBC 不是「火箭公司」，也不是「衛星製造商」。它是一家 對地觀測數據訂閱（Earth Observation Data-as-a-Service） 公司——擁有全球最大的商業對地觀測衛星群，每天為地球拍攝一遍，把「影像」變成「可訂閱、可分析的數據流」。