https://yennj12.js.org/yennj12_blog_V4/tags/python/Recent content in Python on YennJ12 Engineering BlogHugo -- gohugo.ioen-usTue, 30 Jun 2026 13:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-fde-essential-guide-part1-zh/Tue, 26 May 2026 16:53:54 +0900https://yennj12.js.org/yennj12_blog_V4/posts/ai-fde-essential-guide-part1-zh/前言 AI Forward Deployed Engineer (FDE) 是連接前沿 AI 技術與生產環境的關鍵角色。不同於傳統的顧問職位，FDE 需要深入客戶環境，從快速原型開發到生產級系統部署，實現可量化的商業價值。本系列文章將深入解析成為優秀 AI FDE 所需的核心技能。 1. Python 生態系統精通 核心語言特性 必須掌握的概念： 1# 生成器與迭代器 - 記憶體效率處理大型數據集 2def data_generator(file_path): 3 with open(file_path, 'r') as f: 4 for line in f: 5 yield process_line(line) 6 7# 異步程式設計 - 提升 I/O 密集型操作效率 8import asyncio 9import aiohttp 10 11async def fetch_embeddings(texts): 12 async with aiohttp.ClientSession() as session: 13 tasks = [get_embedding(session, text) for text in texts] 14 return await asyncio.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/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/crypto-quantitative-trading-part1-fundamentals/Sat, 24 Jan 2026 20:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/crypto-quantitative-trading-part1-fundamentals/Master the fundamentals of cryptocurrency quantitative trading. Learn essential concepts, data collection methods, technical indicators, and build your first crypto trading analysis pipeline with Python. Complete with practical examples for Bitcoin and Ethereum.https://yennj12.js.org/yennj12_blog_V4/posts/building-mcp-servers-claude-code-development-part1/Sat, 27 Sep 2025 10:00:00 +0000https://yennj12.js.org/yennj12_blog_V4/posts/building-mcp-servers-claude-code-development-part1/Complete guide to setting up Model Control Protocol (MCP) servers for Claude Code, from basic configuration to building custom tools that enhance your AI-powered development workflow.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/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/crypto-quantitative-trading-part2-strategies-backtesting/Sat, 24 Jan 2026 21:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/crypto-quantitative-trading-part2-strategies-backtesting/Build production-ready cryptocurrency trading strategies with comprehensive backtesting. Learn trend following, mean reversion, pairs trading, and arbitrage strategies. Master risk management, position sizing, and performance evaluation with real Bitcoin and Ethereum examples.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/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/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/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/langfuse-intro-part2-tracing-sdk-zh/Tue, 30 Jun 2026 13:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part2-tracing-sdk-zh/可觀測性最大的阻力,從來不是「值不值得」,而是「要改多少程式碼」。 Langfuse 的設計哲學是:讓你從「完全沒追蹤」到「完整 trace」,只需要加幾行——甚至一行。 這篇就帶你把第一個 trace 送上儀表板。 一、起手式:安裝與設定 Part 1 講完概念,這篇全是實作。先裝套件、設好金鑰。 1pip install langfuse 到 Langfuse Cloud(免費)或你自架的實例,建一個專案,拿到一組金鑰,放進環境變數: 1LANGFUSE_PUBLIC_KEY="pk-lf-..." 2LANGFUSE_SECRET_KEY="sk-lf-..." 3LANGFUSE_BASE_URL="https://cloud.langfuse.com" # 自架的話填你的網址 SDK 會自動讀這些環境變數,所以程式裡通常不必硬寫金鑰。接下來有三種接法,由淺入深。 二、接法一:@observe 裝飾器(最省力) 最快的方式:在你想追蹤的函式上加一個 @observe() 裝飾器。它會自動把這個函式變成一個 observation,捕捉輸入、輸出、執行時間。 1from langfuse import observe, get_client 2 3@observe() 4def retrieve_docs(query: str) -> list[str]: 5 # 你的檢索邏輯 6 return ["doc1", "doc2"] 7 8@observe() 9def generate_answer(query: str, docs: list[str]) -> str: 10 # 你的生成邏輯 11 return "答案..." 12 13@observe() # 最外層 → 這會是一個 Trace 14def handle_request(query: str) -> str: 15 docs = retrieve_docs(query) # 巢狀的 Observation 16 answer = generate_answer(query, docs) 17 return answer 18 19handle_request("分析這份財報的風險") 關鍵在於:巢狀的函式呼叫會自動形成巢狀的 observation 樹。 你不需要手動串接 parent/child——handle_request 成為 trace,裡面的 retrieve_docs 和 generate_answer 自動成為它的子 observation。這正是 Part 1 講的那棵樹,而你只加了三個裝飾器。https://yennj12.js.org/yennj12_blog_V4/posts/finance-data-sec-edgar-toolkit/Tue, 24 Feb 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/finance-data-sec-edgar-toolkit/Introducing finance_data — a lightweight Python toolkit that automates downloading SEC financial filings (10-K, 10-Q, 13-F) from EDGAR. Search by ticker symbol, download in bulk, and respect SEC rate limits out of the box.https://yennj12.js.org/yennj12_blog_V4/posts/llm-fine-tuning-aws-bedrock-complete-guide/Sun, 21 Dec 2025 11:00:00 +0000https://yennj12.js.org/yennj12_blog_V4/posts/llm-fine-tuning-aws-bedrock-complete-guide/Comprehensive guide to fine-tuning and customizing Large Language Models (LLMs) with AWS Bedrock - covering supervised fine-tuning, continued pre-training, and reinforcement fine-tuning with practical examples and AWS CDK infrastructure setup.https://yennj12.js.org/yennj12_blog_V4/posts/orchestration-agents-claude-code-comprehensive-guide/Sun, 21 Dec 2025 10:00:00 +0000https://yennj12.js.org/yennj12_blog_V4/posts/orchestration-agents-claude-code-comprehensive-guide/Comprehensive guide to building multi-agent orchestration systems with Claude Code - learn to coordinate specialized AI agents for complex software development workflows, from architecture design to implementation.https://yennj12.js.org/yennj12_blog_V4/posts/deploying-huggingface-models-aws-cdk-sagemaker/Sun, 30 Nov 2025 12:00:00 +0000https://yennj12.js.org/yennj12_blog_V4/posts/deploying-huggingface-models-aws-cdk-sagemaker/🎯 Introduction Deploying machine learning models to production is a complex challenge that goes far beyond training a model. When working with large models from Hugging Face—whether it’s image generation, text-to-image synthesis, or other AI tasks—you need robust infrastructure that handles: Scalability: Auto-scaling to handle variable loads from 0 to thousands of concurrent requests Cost Efficiency: Paying only for what you use while maintaining performance Reliability: 99.9%+ uptime with proper error handling and monitoring Security: Protecting models, data, and API endpoints Observability: Comprehensive logging, metrics, and tracing This comprehensive guide demonstrates how to deploy a Hugging Face model to AWS using infrastructure as code (CDK with TypeScript), combining SageMaker for model hosting and Lambda for API orchestration.