https://yennj12.js.org/yennj12_blog_V4/tags/optimization/Recent content in Optimization on YennJ12 Engineering BlogHugo -- gohugo.ioen-usTue, 30 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/crypto-quantitative-trading-part3-production-deployment/Sat, 24 Jan 2026 22:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/crypto-quantitative-trading-part3-production-deployment/Deploy cryptocurrency trading strategies to production. Master walk-forward analysis, parameter optimization, live trading integration, real-time monitoring, and machine learning enhancements. Complete production-ready system with AWS deployment and comprehensive risk controls.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase2-part2-ensemble-optimization-zh/Sun, 21 Jun 2026 10:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase2-part2-ensemble-optimization-zh/大多數工程師遇到瓶頸時，會去換一個更複雜的模型。 真正的做法是：把多個「夠好的模型」組合起來。 單棵決策樹 Accuracy 70%，一千棵樹投票後達到 91%。 集成不是魔法，而是偏差–變異數分解的數學必然。 面試情境 面試官： 你們公司的信用風險模型已上線，目前用單一 XGBoost，AUC 0.84。產品希望 AUC 提升到 0.88 以上，但訓練資料不能增加、特徵工程已飽和。請說明你會採取哪些策略，並解釋為什麼選擇這些方法而非其他替代方案？推論延遲需維持在 50ms 以內，每日預測量約 500 萬次。 一、核心問題：單一模型的天花板與集成的突破 1.1 偏差–變異數困境 機器學習的核心矛盾可以用一個公式描述： 期望錯誤 = Bias² + Variance + 不可減少的噪音 高偏差（High Bias）：模型太簡單，欠擬合。線性回歸在非線性問題上的典型症狀。 高變異數（High Variance）：模型太複雜，過擬合。深度決策樹在小資料集的典型症狀。 單一模型在這條光譜上只能找到一個平衡點。你無法同時大幅降低偏差和變異數——除非你使用集成方法。 1.2 為什麼集成能突破天花板 Bagging（自助聚合） 降低變異數： 對同一資料集做多次 bootstrap 取樣 每個子模型看到不同的資料子集，學到不同的模式 N 個獨立模型的平均值，變異數是單模型的 1/N（若模型間相關性為 0） Boosting（提升法） 降低偏差： 序列訓練，每個新模型專注修正前一個模型的錯誤 把 N 個「弱學習器（Weak Learner）」串聯，逼近任意複雜的函數 Stacking（堆疊） 同時降低偏差與變異數： 不同類型的模型抓到不同的資料模式 Meta-learner 學習如何最佳組合這些互補的預測 1.3 實際數字 方法 典型 AUC 提升幅度 訓練時間倍增 推論時間倍增 單一決策樹 → Random Forest +0.https://yennj12.js.org/yennj12_blog_V4/posts/ai-fde-essential-guide-part4-zh/Tue, 26 May 2026 17:05:09 +0900https://yennj12.js.org/yennj12_blog_V4/posts/ai-fde-essential-guide-part4-zh/前言 生產環境 AI 系統的監控與最佳化是確保企業 AI 應用成功的關鍵。從模型效能追蹤、基礎設施監控到成本控制，AI FDE 需要建立全方位的可觀測性體系。本文將深入探討 LLM-native 指標設計、分散式監控架構、智能故障診斷與企業級成本最佳化策略。 1. LLM-native 指標與評估體系 核心效能指標設計 LLM 特定指標框架： 1from dataclasses import dataclass 2from typing import Dict, List, Optional, Union 3import numpy as np 4from collections import deque 5import time 6import asyncio 7from enum import Enum 8 9class MetricType(Enum): 10 LATENCY = "latency" 11 THROUGHPUT = "throughput" 12 QUALITY = "quality" 13 COST = "cost" 14 RELIABILITY = "reliability" 15 16@dataclass 17class LLMMetrics: 18 timestamp: float 19 request_id: str 20 model_name: str 21 22 # 效能指標 23 time_to_first_token: float # TTFT - 首個 token 延遲 24 time_per_output_token: float # TPOT - 每個輸出 token 時間 25 total_latency: float 26 tokens_per_second: float 27 28 # 品質指標 29 perplexity: Optional[float] = None 30 bleu_score: Optional[float] = None 31 rouge_score: Optional[Dict[str, float]] = None 32 human_feedback_score: Optional[float] = None 33 34 # 成本指標 35 input_tokens: int = 0 36 output_tokens: int = 0 37 compute_cost: float = 0.https://yennj12.js.org/yennj12_blog_V4/posts/mkdocs-site-size-deploy-perf-tuning-zh/Tue, 30 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/mkdocs-site-size-deploy-perf-tuning-zh/多數人優化靜態站台的做法：壓縮一下圖片、開個快取就收工。 但當站台是由 42 個機器人每天自動寫進去的 5,000 頁報告時，問題不在「檔案大」， 而在「整個 pipeline 的每個環節都在重複放大成本」——搜尋索引、導覽樹、git 歷史、部署觸發頻率。 真正的調校，是找出那些被無限複製的單位成本。 一、問題：一個會自己長大的站台 finance_data 是一個自動化金融分析站台。它的內容不是人手寫的，而是由大約 42 個每日排程任務自動產生：10-K / 10-Q / 13-F 財報摘要、investor day 筆記、AI 生成的個股報告、notebook PDF……每天都有新的 dated report 被寫進 repo，再透過 MkDocs（Material 主題）建置成靜態站台，部署到 GitHub Pages。 這種「機器人持續寫入」的特性，讓站台的成本不是線性增加，而是在好幾個環節同時被放大。等到我們去看的時候，數字已經很難看： 症狀 數字 ────────────────────────────────────────────── 搜尋索引 (search_index.json) 195 MB 首頁 HTML 1.07 MB 單一深層報告頁 HTML 590 KB 單次部署 payload 752 MB 建置完成的站台總大小 ~3.1 GB CI 建置 + 部署時間 ~15 分鐘 每天觸發部署次數 ~42 次（每個分析任務 push 一次） 最致命的不是任何單一數字，而是它們互相加乘：5,000 頁 × 每頁 1MB 的導覽樹 = 站台爆炸；42 次/天 × 752MB 的部署 = CI 排隊塞車。我們要做的，是逐一拆掉這些放大器。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:https://yennj12.js.org/yennj12_blog_V4/posts/optimizing-database-performance/Sun, 10 Aug 2025 15:28:17 +0800https://yennj12.js.org/yennj12_blog_V4/posts/optimizing-database-performance/A comprehensive guide to database performance optimization techniques that helped us reduce query response times from seconds to milliseconds.