https://yennj12.js.org/yennj12_blog_V4/tags/architecture/Recent content in Architecture on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 29 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part3-comparison-zh/Mon, 29 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part3-comparison-zh/大多數人問「知識圖譜會不會取代資料庫？」 正確答案是：問錯問題了。它們解決的是不同維度的問題。 大多數人看到向量資料庫很紅，就以為知識圖譜過時了。 正確答案是：在 LLM 時代，兩者反而是最佳拍檔（Part 4 詳述）。 接續前文 Part 1 講概念、Part 2 動手建。這一篇要把知識圖譜放到擂台上，和四種常見的資料儲存技術正面比較，幫你建立清楚的選型判斷力。 一、核心問題：四種技術在解什麼問題？ 先用一句話定位每種技術的「世界觀」： ┌──────────────────┬──────────────────────────────────────────────┐ │ 關聯式 (RDBMS) │ 「我有結構化的表格，要保證交易一致性」 │ │ 文件 (Document) │ 「我有半結構化的 JSON，schema 常變」 │ │ 向量 (Vector DB) │ 「我要找『意思相近』的東西（語意相似）」 │ │ 知識圖譜 (KG) │ 「我要表達並推理『實體之間的關係』」 │ └──────────────────┴──────────────────────────────────────────────┘ 關鍵洞察：它們優化的維度不同。RDBMS 優化交易一致性、文件庫優化 schema 彈性、向量庫優化語意相似、知識圖譜優化關係推理。問「誰取代誰」是問錯了；該問的是「我這個問題的本質是哪一種」。 二、知識圖譜 vs 關聯式資料庫（RDBMS） 這是最常被拿來比的一組。差異的核心在於：關係是如何被表示的。 面向 知識圖譜 關聯式資料庫 關係表示 一等公民，直接存在邊上 靠 foreign key + JOIN 隱式重建 多跳查詢 圖遍歷，效能與跳數弱相關 多重 JOIN，跳數越多越慢 Schema 彈性 高，加關係不需 migration 低，改表結構成本高 交易一致性 多數圖庫較弱（部分支援 ACID） 強項，成熟的 ACID 聚合運算 較弱 強（SUM/GROUP BY 等） 成熟度/生態 相對年輕 數十年積累、人人會 SQL 為什麼選知識圖譜不選 RDBMS：當你的查詢核心是「關係的關係」—— 多跳路徑、最短路徑、社群偵測、影響力傳播。例如風控要查「這筆交易的對手方，透過幾層人頭帳戶連到黑名單」。https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-11-async-event-driven-pipeline-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-11-async-event-driven-pipeline-zh/核心定義：Async Event-Driven Pipeline 是將每個長時間運算（如 LLM 推論）拆成「接受請求 → 寫訊息佇列 → 立即回 202 → 背景 Worker 處理 → 客戶端輪詢或推送結果」五個步驟，徹底切斷 HTTP 連線與運算時間的綁定關係，讓連線池資源不再成為系統瓶頸。 面試情境： 「你們的 AI 寫作助理功能在發布後一週內，DAU 從 500 成長到 8,000，但後端開始出現大量 503，LLM 回應也從 3 秒變成 30 秒超時。你作為 FDE，如何診斷問題並提出架構改善方案？你的方案需要能支撐 50,000 DAU 而不需要垂直升級 LLM endpoint。」 一、為什麼面試官問這個 面試官真正在測試的是你對連線資源生命週期與系統容量天花板的直覺，以及你能否在架構層面解決「延遲長」這個根本矛盾，而不是靠「加機器」硬撐。這題在 FDE 面試中特別常見，因為 LLM 整合幾乎是現代應用的標配，而 LLM 的推論延遲（2–30 秒）與 Web Server 的同步模型之間存在根本性衝突。 測試點一：容量計算能力。 你能否當場估算「1,000 並發 × 15 秒 LLM 延遲 = 需要同時持有 1,000 個連線」，並說明為什麼典型的 Gunicorn + FastAPI 配置在 200–500 個並發時就會開始出現 503。面試官想看到的是工程師對資源約束的量化思維，而不是模糊的「系統會變慢」。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase7-part1-transformer-architecture-zh/Sun, 21 Jun 2026 15:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase7-part1-transformer-architecture-zh/大多數人覺得 Transformer 就是「注意力機制加上前饋網路」，說完就結束了。 真正的工程師知道：矩陣分塊如何影響 GPU 記憶體帶寬，KV Cache 如何讓首 token 延遲從 8s 降到 400ms， 為什麼 GQA 能在保持 95% 品質的前提下省掉 75% 的快取記憶體。 架構不是魔法——它是一系列在硬體限制下做出的工程取捨。 面試情境：「你負責將一個 7B 參數的 LLM 部署到生產環境，P99 首 token 延遲必須 < 500ms，批次吞吐量 > 200 req/s，GPU 記憶體預算 40GB。請說明你會在 Transformer 架構層面做哪些優化決策，以及你如何取捨精度與速度。」 一、核心問題：為什麼 Transformer 取代了一切 1.1 RNN/LSTM 的根本瓶頸 在 Transformer 出現之前，序列模型靠 RNN 與 LSTM。它們有一個無法繞開的硬傷：序列依賴（sequential dependency）。 時間步 t=1 → t=2 → t=3 → ... → t=n 每步必須等上一步完成，無法並行 後果： 訓練速度隨序列長度線性增長 梯度消失導致長距依賴難以學習 GPU 大量計算資源閒置（利用率 < 30%） 1.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part14-memory-architecture-zh/Wed, 03 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part14-memory-architecture-zh/LLM 是無狀態的，但用戶是有狀態的。 Memory 系統要解決的問題只有一個： 讓無狀態的 LLM 表現得像是「記得你」。 怎麼設計這個橋樑，以及這個橋樑的代價——是這篇的核心。 一、核心問題：為什麼需要不同類型的 Memory 沒有 Memory 的 Agent 每次對話從零開始： Session 1： User: "我主要用 Python，偏好簡短的回答" Agent: "好的！" （記不住） Session 2（三天後）： User: "幫我寫一個排序函數" Agent: "您好！請問您用哪種程式語言？" ↑ 明明說過了，還在問 但「把所有對話都記住」也不可行： 問題 1：儲存量 10K 用戶 × 每天 10 輪 × 365 天 = 3,650 萬條對話記錄 問題 2：Context 限制 把所有歷史塞進 LLM context → 超過 context window 問題 3：相關性 3 年前討論的內容，現在可能完全不相關 結論：需要多種記憶類型，各自解決不同的問題。 二、四種記憶類型：各解決什麼問題 問題 解決方案 ───────────────────────────────────────────────────── 當前對話的臨時狀態？ → Working Memory（工作記憶） LLM context window 生命週期：當次對話 記得過去發生過什麼？ → Episodic Memory（情節記憶） 向量化的對話歷史 生命週期：跨 session，可衰減 記得這個人是什麼樣的人？→ Semantic Memory（語意記憶） 結構化的 user profile 生命週期：持久化，主動更新 知道怎麼做某件事？ → Procedural Memory（程序記憶） Few-shot examples / Fine-tuning 生命週期：模型層，最持久 三、完整 Memory 架構圖 用戶請求 │ ▼ ┌──────────────────────────────────────────────┐ │ Memory Retrieval Layer │ │ │ │ ┌──────────────────────┐ │ │ │ Semantic Memory │ ← 用戶偏好、profile │ │ │ (Structured DB) │ 每次對話都載入 │ │ └──────────────────────┘ │ │ + │ │ ┌──────────────────────┐ │ │ │ Episodic Memory │ ← 相關歷史片段 │ │ │ (Vector DB) │ 按語意相似度召回 │ │ └──────────────────────┘ │ └──────────────────┬───────────────────────────┘ │ 組合成 Working Memory ▼ ┌──────────────────────────────────────────────┐ │ Working Memory │ │ (LLM Context Window) │ │ │ │ [System Prompt] │ │ [User Profile from Semantic Memory] │ │ [Relevant History from Episodic Memory] │ │ [Current Conversation] │ │ [Current Query] │ └──────────────────┬───────────────────────────┘ │ ▼ LLM │ ▼ 回應 │ （對話結束後，非同步） ▼ ┌──────────────────────────────────────────────┐ │ Memory Update Layer │ │ │ │ ┌────────────────────────────┐ │ │ │ 提取重要資訊 │ │ │ │ → 更新 Semantic Memory │ ← 偏好、事實 │ │ └────────────────────────────┘ │ │ ┌────────────────────────────┐ │ │ │ 壓縮對話摘要 │ │ │ │ → 存入 Episodic Memory │ ← 做了什麼 │ │ └────────────────────────────┘ │ └──────────────────────────────────────────────┘ 關鍵設計決策：Memory Update 是非同步的https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part30-constraint-driven-architecture-zh/Thu, 04 Jun 2026 21:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part30-constraint-driven-architecture-zh/大多數的架構設計課程從「最優解」出發。 但 FDE 的真實工作，是從「客戶的限制」出發。 「所有資料不能出 VPC」、「模型不能用 SaaS API」、「每個 API call 都要有審計日誌」—— 這些限制不是問題，是你設計的起點。 面試情境 面試官：「你的客戶是一家銀行。他們的 IT 安全政策規定：所有含有客戶 PII 的資料不能傳送到外部網路，所有 API 呼叫必須在私有網路內完成，並且每個 AI 模型的調用都要有審計日誌。他們想在這個條件下部署一個 RAG-based 合約審閱 Agent。你的架構是什麼？」 一、FDE 面對限制的第一步：分類 收到限制條件，先做分類，不要立刻開始設計架構： 限制分類框架： 類型 1：資料主權限制（Data Residency） 「資料不能離開特定地理區域」 → GCP Region 選擇問題 → 影響：model endpoint 必須在指定 Region 類型 2：網路隔離限制（Network Isolation） 「API 呼叫必須在私有網路內」 → VPC 架構問題 → 影響：需要 Private Service Connect / VPC-SC 類型 3：資料分類限制（Data Classification） 「PII 不能傳給外部服務」 → 資料流設計問題 → 影響：需要 PII detection + 資料遮罩 pipeline 類型 4：審計與合規限制（Audit & Compliance） 「所有 AI 調用要有 audit log」 → Observability 架構問題 → 影響：Cloud Audit Logs + SIEM 整合 本題的限制：類型 2 + 3 + 4，三個同時 二、核心技術：VPC Service Controls（VPC-SC） 這是 Google Cloud 上的金融/政府客戶必備知識：https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part39-scalability-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part39-scalability-zh/10,000 個內部員工用，一切都很順。 百萬外部用戶第一天上線，系統在 30 分鐘內崩潰。 「加更多機器」不是答案—— 正確的問題是：哪些地方讓你根本無法加機器？ 面試情境 面試官：「你幫一家金融公司做了內部員工 AI 助手，10,000 個內部用戶，系統很穩定。現在 CEO 決定把這個產品開放給外部客戶，目標是百萬 MAU（月活躍用戶）。你說需要重新設計架構。從哪裡開始？你會做哪些改動？為什麼？」 一、為什麼 10K → 1M 不只是「加機器」 10K 內部用戶的隱性假設（這些假設在 1M 時全部失效）： 用戶行為： ├── 行為模式可預測（9-18 點工作時間，流量曲線平滑） ├── 用量相對均勻（員工配額相似，不會有人瘋狂濫用） └── 系統問題可以容忍（內部用戶有耐心，可以接受偶爾慢） 系統設計： ├── Session State 在記憶體（少數實例，重啟少） ├── 認證：單一 LDAP/SSO（一種身份系統就夠） ├── 沒有速率限制（員工不會惡意攻擊自家系統） └── SLA：P95 < 10s 內部用戶接受 1M 外部用戶：每一個假設都被打破 假設失效 真實挑戰 系統症狀 ────────────────────────────────────────────────────────────── 行為可預測 病毒式傳播：1 小時內 100x 流量 Auto-Scale 來不及 → 503 用量均勻 惡意用戶濫用、失控的客戶端 Bug 一個用戶拖垮整個平台 Session 在記憶體 Scale-Out 後新實例找不到 Session 對話斷掉，用戶流失 無速率限制 機器人、爬蟲、Bug 迴圈呼叫 LLM 配額耗盡 → 全平台崩潰 SLA 寬鬆 外部客戶不等待，直接離開 用戶留存率崩潰 成本不計較 1M × 50 queries × $0.https://yennj12.js.org/yennj12_blog_V4/posts/aws-dynamodb-complete-guide-optimization/Mon, 29 Sep 2025 10:02:35 +0800https://yennj12.js.org/yennj12_blog_V4/posts/aws-dynamodb-complete-guide-optimization/Introduction Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. This comprehensive guide explores DynamoDB’s architecture, data structures, indexing strategies, and advanced optimization techniques to achieve maximum performance for your applications. DynamoDB Architecture Overview Core Architecture Components graph TB subgraph "DynamoDB Service Architecture" APP[Application Layer] SDK[AWS SDK] API[DynamoDB API] subgraph "DynamoDB Core" AUTH[Authentication & Authorization] ROUTER[Request Router] METADATA[Metadata Service] subgraph "Storage Layer" PARTITION1[Partition 1] PARTITION2[Partition 2] PARTITION3[Partition 3] PARTITIONN[Partition N] end subgraph "Index Layer" GSI[Global Secondary Indexes] LSI[Local Secondary Indexes] end end subgraph "Infrastructure" SSD[SSD Storage] REPLICATION[Multi-AZ Replication] BACKUP[Automated Backups] end end APP --> SDK SDK --> API API --> AUTH AUTH --> ROUTER ROUTER --> METADATA ROUTER --> PARTITION1 ROUTER --> PARTITION2 ROUTER --> PARTITION3 ROUTER --> PARTITIONN PARTITION1 --> SSD PARTITION2 --> SSD PARTITION3 --> SSD PARTITIONN --> SSD SSD --> REPLICATION REPLICATION --> BACKUP DynamoDB vs Traditional Databases Feature DynamoDB Traditional RDBMS MongoDB Data Model Key-Value & Document Relational Tables Document Schema Schema-less Fixed Schema Flexible Schema Scaling Horizontal (Auto) Vertical (Manual) Horizontal (Manual) Consistency Eventually Consistent ACID Transactions Configurable Query Language PartiQL & APIs SQL MongoDB Query Language Performance Single-digit millisecond Variable Variable Management Fully Managed Self-Managed Self/Managed Options DynamoDB Data Structures Primary Key Structures DynamoDB supports two types of primary keys: