透過 notebooklm 搭配個人筆記進行的整理，可能有些許錯誤，但仍可作爲參考

只有下午場次

周威廷 Richard Chou｜自助式大數據平臺：平台工程的策略與價值

台積電平台處的使命

旨在彌合基礎設施與應用程式之間的鴻溝，提供工具平台供所有應用程式使用，並需支援超過 5 萬使用者和 1000 種應用程式，同時因無法使用公有雲服務而需自行建構類似雲原生的服務。

第一代資料平台 (Oracle)

約十幾二十年前建立，使用 Oracle 資料庫處理與儲存資料，主要挑戰包括嚴重的資料孤島問題、不一致的管理流程、對 DBA 的依賴，以及因資料量膨脹導致 Oracle 在分析查詢上的效率低下。

第二代資料平台 (Hadoop/HBase/Cassandra)

為了解決擴展性問題而建構，採用分散式架構。主要挑戰是 Spark 程式開發困難，導致效率低下；與第一代 Oracle 並存造成技術碎片化；平台團隊變成操作瓶頸，負擔加劇。

第三代資料平台 (Lakehouse 架構)

採用 Data Lakehouse 的現代架構，前台提供 SQL 介面，支援多樣化查詢方式，解決無法從 Oracle 遷移的問題，同時也提供類似 AWS/GCP 的自助服務介面。

• 自助服務與隔離工作空間：借鑒 AWS/GCP 的自助服務模式，使用者可透過 UI 自行管理資源，同時採用 Share Nothing 架構，為每個團隊提供獨立的工作空間，大幅降低人為錯誤影響整個平台的機率。
• Lakehouse 技術堆疊：儲存層使用開源的 MinIO（支援 S3 協定），資料格式選用 Apache Iceberg（相對 Delta Lake 和 Hudi 更易理解），目錄服務為 Hive Metastore，查詢引擎是標準 SQL 的 Trino，並提供 Spark 環境供進階使用者使用。資料注入層透過 Airflow、MinIO、Spark 進行批次注入，或經由 Kafka、Spark Streaming 進行串流注入。
• 平台優勢與未來展望：消除資料孤島，提供高效且可擴展的分析能力，提升營運效率，並透過 No-code 可配置的資料注入方式降低 Spark 開發依賴。最終目標是實現資料民主化，讓組織內所有人都能輕易找到、存取、理解並信任資料，平台服務以產品角度開發並落地到各廠區。

李昭德 Stanley Lee & 范哲誠 Zhe-Cheng Fan｜融合視覺 AI 與智慧製造，提升操作效率的創新策略

視覺 AI 在台積電工廠的應用

台積電在工廠內廣泛應用視覺 AI，聚焦於三大領域：品質檢測、製程監控與優化、設備監控，以實現智慧製造並提升晶圓品質與流程效率。

品質檢測的挑戰

儘管台積電能收集大量影像資料，但在品質檢測上仍面臨以下挑戰：

• 瑕疵影像與標記稀少：台積電晶圓良率極高，實際瑕疵影像數量極少。儘管有海量影像資料，卻缺乏有標記的瑕疵樣本，造成資料訓練困難。

• 模型需具泛化能力：實際應用中可能出現模型未曾見過的瑕疵，需具備 Defect Prediction / Novelty Detection 能力。

• 難以分析瑕疵成因：僅憑影像難以準確推論瑕疵發生機制與位置、形態等資訊。

• 物理限制：具物理意義的影像資料少，難直接套用傳統物理公式建模。

視覺基礎模型（Vision Foundation Model, VFM）

• 模型訓練方式：VFM 透過大量無瑕疵影像資料進行預訓練，台積電可利用自身影像資源建立模型基底。

• Few-shot 微調能力：透過少量瑕疵資料進行微調，提升辨識新型瑕疵能力。

• 優勢：

  • 顯著縮短訓練時間。
  • 減少標記資料需求。
  • 提升檢測準確度與穩定性。

• 借助外部模型：如 Meta 的 Euronas 物件偵測模型，透過微調後亦能應用於內部資料，展現「站在巨人肩膀上」的策略效益。

生成式 AI（Generative AI）

• 合成資料生成：透過 GAN 等生成模型，產生訓練所需的瑕疵影像，擴充資料集。

• 影像風格轉換：將模擬電路影像轉換為實際晶圓風格，或依需求生成不同解析度影像。

• 文字生成影像（Text-to-Image）：依據文字描述（如瑕疵位置、大小、深度等）生成對應影像，用於模型訓練。

• 知識強化：透過生成資料輔助模型理解與分析瑕疵，進一步推估可能成因。

Segment Anything Model（SAM）

• Meta SAM：支援 Zero-shot 分割，使用者透過文字、點擊或邊界框指定區域，即可自動分割物件。

• 應用於台積電：可結合內部資料進行微調，用於瑕疵檢測等任務。

• SAM2 優化：

  • 處理影片的速度提升 6 倍。
  • 目前仍不支援文字輸入，需依靠視覺提示如點擊或框選。

視覺語言模型（Vision Language Model, VLM）

• 基本功能：VLM 可將影像內容轉換為文字，並進行判斷與問答（VQA）、物件偵測等。

• MoMo-7B 模型：

  • 整合影像、文字與座標資料。
  • 可輸出影像中特定物件的精確座標資訊。

• 與 SAM2 結合應用：

  • MoMo-7B 分析影像並輸出座標。
  • SAM2 接收座標並執行高精度影像分割。

物理引導 AI（Physics-guided AI）

• 概念釐清：

  • Physics-guided AI：將物理定律、公式或專家知識融入 AI 模型中，常見於損失函數設計。
  • Physical AI：指與數位雙生（Digital Twins）結合、可與實體設備互動的 AI，目前台積電聚焦於前者。

• 應對資料稀缺：

  • 相較傳統資料驅動模型，Physics-guided AI 可在資料有限時，利用物理知識輔助模型訓練與收斂。

• 應用價值：

  • 提升模型預測準確性。
  • 強化物理領域的模型應用能力，例如光學逆向設計，從期望光場反推出所需材料參數。

游友誠 Yu-Cheng Yu｜AI 服務開發全解析：從技術藍圖到落地實踐

成功 AI 服務的構成要素

台積電成功的 AI 服務產品由三大核心要素構成，以確保快速落地和滿足使用者需求：

• 明確的業務目標：需滿足使用者場景需求，支援決策預測，以提升效率或實現 AI 創新。
• 多職能團隊協作：透過不同職能團隊的整合與分工，快速同步專案需求，加速開發流程。
• 平台技術支援：整合雲端運算資源等不同技術平台與解決方案，加速 AI 產品的設計、開發、部署與維運.

AI 服務業務目標

台積電的 AI 服務主要圍繞三個目標：

• 效率提升：透過 AI 改善內部系統、開發與維運流程，實現自動化與智慧化，例如在瑕疵檢測中可望減少 60-70% 的人工檢測時間。
• 改善使用者體驗：建立如專家系統、AI Agent 應用以節省人際溝通獲取知識的時間，並透過 AI 分析回饋來提供個人化功能。
• 推動創新：鼓勵從學界業界吸取經驗、專研技術，並嘗試引入內部驗證可行性，推出全新的 AI 功能。

團隊角色分工

AI 服務開發涉及多個專業角色協作：

• 專案經理 (PM)：負責收集產品需求，組織技術與開發團隊，並帶領雛形與使用者討論以收集回饋。
• 資料科學家 (DS)：專注於最新技術研究提供解決方案，或偏向開發實作 AI 解決方案，確保 POC 階段的功能驗證。
• 使用者經驗與介面設計師 (UX/UI)：思考如何在 AI 服務中凸顯 AI 能力，確保使用者能方便上手與使用。
• 前後端開發工程師 (F/B)：負責架構設計後的實作，整合前後端資源，進行功能開發。
• 網站可靠性工程師 (SRE)：建立穩定且具備延展性的平台與架構，確保 AI 服務能在穩定的平台上運行。
• 值得一提的是，台積電團隊已大量導入 AI Agent/Assistant 協助日常工作 (如報告、翻譯、資料會診) 及作為領域專家 (如新人訓練、SOP、問題排除)，開發者也使用 AI Co-pilot 提升程式碼品質和安全性。

AI 技術藍圖

台積電的 AI 技術藍圖包含平台層與應用層，構成完整生態系：

• 平台層 (Platform)：提供大量的 CPU 和 GPU 雲端運算資源，具備自動化開發管線、服務註冊中心、MLOps 自動化模型訓練與版本追蹤。也負責收集業界開源的基礎模型與預訓練模型，並建立績效排行榜與實驗場供 POC/MVP 試用。監控與運維方面，已實作診斷、異常偵測與日誌服務，並導入 AI 輔助診斷和問題排除。
• 應用層 (Application)：使用基礎模型與 SDK，內部團隊也會建立 SDK 或框架進行服務串接整合。提供多樣化的模型服務，如語言、圖像、文件等，以滿足不同使用者群體 (如 ITRD 或工廠部門) 的需求。

開發流程

AI 服務的開發是一個從概念到實踐的嚴謹過程：

• 初始階段 (Project In)：明確目標、評估成本，建立初步的概念驗證 (POC) 或原型，以最小單位的 AI 元件或功能進行實作。
• 驗證階段 (Validation)：透過內部審查驗證 AI 功能及準確度，並使用實際生產資料進行模擬，甚至讓部分使用者試用並微調。
• 產品化 (Production)：建構完整的 AI 服務架構，使其系統化並符合標準的 AI 服務樣貌，此階段前後端團隊的工作負擔較大。
• 部署 (Deployment)：最終發布，確保所有功能上線時運作正常，並整合所有系統監控與異常偵測機制。

挑戰

台積電在推動 AI 服務時面臨多方面挑戰：

• 問題定義：需明確解決的問題與解決方案，並與使用者大量溝通，了解其領域知識與痛點，同時考量資安與資料使用限制。
• 範圍界定：需深入探討使用者、資料與 AI 功能的範圍，並定義明確的里程碑。
• 生產就緒：AI 服務需適應不同的生產環境（如工廠的實體隔離），並實踐敏捷開發，以兩週為一個 Sprint 規劃任務。
• 風險評估與控管：確保符合資安規範，資料使用受限於場域時需風險評估到位。同時注重品質確保、版本控制與文件管理，建立完整的 User Guide、Guideline 和 SOP。

持續運維

AI 服務上線後，持續運維至關重要：

• 服務水平協議監控 (SLA)：持續監控服務健康度，統計 API 請求數據，並定義 SLA 以觸發警報自動通報維運人員，這些機制在部署階段就需建立。
• 響應時間與流量監控：即時監控流量，對服務質量進行嚴密監控。
• 故障排除 (Troubleshooting)：制定明確的程式碼規範，維運人員遵循規範進行故障排除與根本原因定位，開發團隊建立完整 SOP 以規範維運成本。
• 自動化復原 (Automatic Recovery)：從平台角度考慮伺服器備援、資源使用、資料備援、網路流量轉導等，確保維運人員了解當前資源配置。

總體而言，台積電的 AI 開發流程在角色分工、平台資源使用上都有明確規劃與執行。團隊持續接觸並累積新技術，鼓勵創新應用，並將業界 AI 技術實際落地到台積電環境中。

莊育珊 Nicole Chuang｜Generative AI 在全球化擴廠中扮演的角色

台積電面臨的三大挑戰

1. 技術轉移 (Technology Transfer)：

   • 台灣廠區間的技術轉移已具挑戰，跨國廠區的有效知識轉移更困難。
   • 過去知識儲存零散且易流失，文件常過時，且龐大知識庫難以查找。

2. 語言隔閡 (Language Barriers)：

   • 不同國家廠區間語言溝通是一大門檻，尤其與日語或德語溝通時更具挑戰。
   • 文化差異也可能影響溝通與團隊信任。
   • 半導體產業的術語與行話（如「前段」、「卡關」、「接水」）與直譯不同，外部模型難以理解。

3. 新人培訓需求 (New Employee Training Needs)：

   • 跨廠區擴張與產能需求增加，使新員工需求上升。
   • 新人培訓通常耗時，現有教材品質不一，不同廠區訓練內容可能不同。
   • 需提供個人化學習路徑，並減輕資深員工負擔。

生成式 AI 解決方案

生成式 AI 在解決上述挑戰方面扮演關鍵角色：

1. 助攻技術轉移：

   • 建立知識庫 (Knowledge Base Construction)：

     • 知識應儲存在可線上共同編輯的中央平台，而非個人硬碟。
     • AI 可將 Word、PowerPoint、PDF 轉換為標準化 Markdown 格式。
     • 透過 AI 定義模板並擷取數位足跡，協助系統性儲存與品質管理。
     • 根據領域定義文件模板，統一段落結構，提升可讀性。

   • AI 偵測知識品質與打造資料飛輪：

     • 設計權限控管與簽核流程以確保機密與品質。
     • 為資料建立標籤與元資料，利於搜尋與管理。
     • 定期偵測過時知識，自動提醒與更新。
     • AI 可查找舊解法並主動推薦行動方案，實現知識閉環。

   • 核心技術堆疊 (Core Technology Stack)：

     • 包含 LLM、ETL、OCR、NLP、Vector DB、RAG 與多代理架構。
     • 初期應先使用先進模型驗證可行性，再導入自建方案。

2. 語言隔閡解法：

   • 即時翻譯與轉錄 (Real-time Translation and Transcription)：

     • 利用 LLM 實現即時口譯與文字翻譯，提升跨語言會議效率。
     • 涵蓋所有需翻譯文件，如 SOP、手冊、合約與教學影片。

   • 處理術語與內容在地化：

     • 術語分為：專業術語、內部定義、慣用語、部門行話。
     • AI 容易處理前兩者，但需特別訓練才能理解後兩者。
     • 建立企業術語庫：透過提報、挖掘、自動化整理等方式建立與維護。
     • 術語應具備定義、標籤、同義詞、版本與生命週期管理。
     • 採用 RAG 策略，即時檢索術語並輔助翻譯，避免模型幻覺。

   • 溝通文化調整：

     • 減少非正式行話，鼓勵使用標準術語。
     • 建立回饋與獎勵制度，持續改善術語庫。
     • 透過人工修正與資料飛輪，逐步提升翻譯品質。

3. AI 協助培訓：

   • 個人化教練 (Personalized Coach)：

     • 結合多語知識庫與 AI，提供即時解答與指導。

   • AR/VR 模擬環境：

     • 建立虛擬實作訓練環境，減少實地培訓成本。

   • 自動生成教材 (Automated Content Generation)：

     • AI 可從文件提取資訊，自動生成互動教材。
     • 根據學習曲線與需求，規劃專屬培訓路徑。

   • 推動策略：

     • 先在關鍵崗位試點，收集反饋後擴展至全廠區。

未來重點

1. Physical AI 機器人：

   • 結合生成式 AI，提升機器人智能與靈活性，協助更多製程自動化。

2. 數位雙生 (Digital Twins)：

   • 在虛擬環境中測試製程與產品，加速開發與異常預警。

風險管理

1. LLM 幻覺風險管理：

   • 幻覺無法完全消除，應視應用風險等級設計對策。
   • 使用 RAG、歸因模組、強制邏輯等方式減緩風險。
   • 高風險場景應由人決策；低風險可加註使用說明。

2. AI 定位與責任界定：

   • 台積電 AI 政策明確：AI 僅為輔助，人類保有最終決策責任。

其他相關資訊

• 台積電 AI 實踐：政策明確、流程嚴謹，強調以人為核心。
• IT 與應用部門分工：IT AI 團隊支援橫向部門，CIM 與 AIFBI 聚焦應用場景。
• 文件整理策略：
  • 不需一次性清理舊文件，應按主題分批優先處理。
  • 結合 AI 工具與模板提升內容品質。
  • 自動擷取數位足跡並轉化為報告，便於知識積累。
• LLM + 內部知識整合：
  • 透過 Agent 架構將 LLM 與內部 log、資料庫等資訊整合，形成工具型智慧解答。
• 測試工程機制：由專業 QA 團隊支援 MVP 測試與產品驗證。
• 地端小語言模型 (SLM)：
  • Hosting 成本較低，且在特定領域有良好表現。
  • 可與大型模型搭配使用，提升整體效率。

蔡孟玹 Alan Tsai｜從 Monitoring 到 Observability：快速發現與解決問題的進化之路

Monitoring vs Observability

前者被動、僅記錄事件，針對單一系統；後者主動、可分析問題根源與預兆，側重於跨系統。

商業價值

停產一天可能導致損失達 30 億台幣，提早發現問題可大幅減損。

三大支柱

• 指標 (Metrics)：特定時間點的數值，如 CPU 使用率、記憶體用量。它們量體較小，可透過「標籤 (Label)」區分不同維度資訊，但需注意避免「高基數」問題.
• 日誌 (Logs)：記錄特定時間點發生的事件或動作的詳細內容。日誌量體通常最大，建議使用結構化格式（如 JSON）和正確的日誌層級，並包含使用者、交易、請求等基本資訊以便快速定位問題.
• 追蹤 (Tracing)：代表一個使用者請求在整個分散式系統中，從開始到結束的完整流程狀況。幫助迅速定位哪個環節出現問題或延遲。建議遵循 OpenTelemetry 等標準.

平台架構 (GPA)

整合了多種工具

• Metrics 收集：主要使用 Prometheus
• 日誌儲存：主要發送到 Elasticsearch (ES)，透過 Kibana 查閱
• 視覺化：Grafana 用於 Metrics 的儀表板，Jaeger 用於 Tracing 視覺化
• 警示：Alertmanager 觸發警示，可透過 Bot 通知
• 支援 Kubernetes (TsmcKS) 和傳統虛擬機 (VM) 環境
• 因應多環境和龐大資料量，建議採用「可觀察性即程式碼 (Observability as Code)」概念來快速部署和管理

最佳實踐

• Metrics 命名：應有意義、包含單位、避免高基數標籤
• 日誌結構化：使用 JSON 等結構化格式，區分日誌層級，並包含使用者 ID、請求 ID 等基本資訊
• 警示設計：基於症狀而非原因，區分警示層級，並透過「抑制 (Inhibition)」和「靜默 (Silencer)」避免告警疲勞，可結合自動化處理
• 儀表板策略：設計儀表板時，應以終為始，思考要監控什麼。常見策略有 USE (Utilization, Saturation, Errors) 和 RED (Rate, Errors, Duration/Latency)。Google 建議的「四大黃金指標」為延遲 (Latency)、流量 (Traffic)、錯誤率 (Errors) 和飽和度 (Saturation)

資料規模挑戰

• 台積電面臨數十 TB 甚至更大的日誌量，挑戰極大。
• 應對策略包括資料生命週期管理、資料過濾壓縮、分級儲存（如將歷史資料轉存到 MinIO 等成本較低的系統）.

邱宏瑋 Hung-Wei Chiu｜面對大規模 Kubernetes 叢集：挑戰與機遇並存

優點與挑戰

k8s 的優點在於支援大規模應用、自動部署與修復、快速回復故障，但同時也有以下挑戰

• 作為開源生態系統，k8s 版本更新迅速，功能豐富但也伴隨大量錯誤和整合困難。
• 在大規模環境下，單一元件的缺陷或預設配置可能導致整個叢集的不穩定或效能瓶頸。
• 台積電無法使用公有雲服務，需自行建構符合環境的 k8s ，這需要從零開始組合與測試各種開源組件。
• 解決 k8s 的深層問題需要整合不同領域的知識（如Linux、作業系統、網路、儲存、排程等），並深入分析原始碼。

Scheduler 問題

• 預設 Scheduler 會將 Pod 分配到最不忙碌的節點，但當大量 Pod（例如批次作業）瞬間產生時，這會導致 image Pull 瓶頸（網路或CPU），使得所有 Pod 啟動延遲
• 可能觸發每秒Pod建立數量限制（例如，建議不超過20個），導致SLA無法達成

Controller 問題

• 作為 k8s 的自癒核心，控制器以主動/備用（active/standby）模式運作，無法無限水平擴展以支援大量的 Pod。
• Job 控制器在處理過多 Job 時，會因忙碌而導致 Pod 結束時間與 Job 實際標記完成時間脫鉤，進而影響 CronJob 的下次執行。
• 其處理量受 API 每秒請求（QPS）參數限制，且工作佇列大小在 k8s 1.28 版之前無法調整。

Kubelet 問題

inode 耗盡、Log 滿載、du 計算慢等

• inode 耗盡：運行過多 Pod 或使用大型 image，可能導致節點上的 inode（檔案系統節點）迅速耗盡，造成 Worker 節點當機。
• log rotate 問題：日誌輸出過快或輪替不即時，會導致節點磁碟空間不足，也可能消耗額外的 CPU 資源。
• Kubelet 計算 inode 的方式在早期版本中效率低下（使用du），雖然後續版本有所改善，但也可能引入新的功能問題。

ETCD 問題

資料碎片化需 Defrag，但會中斷服務

• 資料碎片化：頻繁的 Pod 建立與刪除（特別是 Job 和 CronJob）會導致 ETCD 的儲存空間碎片化。
• 碎片整理（Defrag）：碎片整理操作是必要的，但它會暫停 ETCD 所有的讀寫操作，導致所有 API 請求瞬時失敗或卡住，對服務造成影響，且目前沒有完全自動化且安全的解決方案。

CoreDNS 問題

負責叢集內外DNS解析

• Ready Plugin 錯誤：其就緒探針（ready plugin）的設計缺陷導致即使 CoreDNS 實際故障，也可能一直回報為「就緒」，流量仍會導向故障的 CoreDNS。
• 日誌模式問題：開啟詳細日誌模式可能導致記憶體暴增（OOM），因為日誌寫入速度跟不上生成速度。
• IPv4/IPv6 交互影響：應用程式內部可能預設發送 IPv6 DNS 請求，即使環境不支援，導致大量無效請求和額外負荷。
• kubeadm 升級重置設定：使用 kubeadm 升級 k8s 會將 CoreDNS 的客製化設定重置回預設值。
• 缺乏流量限制：CoreDNS 沒有內建的請求流量限制，惡意行為或不良應用可能導致其過載甚至癱瘓。

CRI-O 問題

預設行為是避免同一 Pod 內相同 image 的平行下載，但對於多個 Pod 同時下載同一個大型 image 時，會導致頻寬耗盡、CPU 使用率飆高，並使 Pod 卡住無法啟動

Cilium (CNI，容器網路介面)

• Egress Gateway問題：Egress Gateway 提供固定對外 IP，但其 NAT 表可能因連接埠耗盡（未及時回收）而滿載，阻止新的對外連線。
• BPF Map容量限制：Cilium 底層使用的擴展柏克萊封包過濾器（eBPF）Map 有固定大小限制，當連接數或物件數量超過限制時，新的連線會失敗，且調整這些 Map 大小通常需要重啟節點。
• 啟動時間緩慢：Pod數量眾多時，Cilium 控制平面處理網路設定可能需要 10~20 秒甚至更長時間，導致新啟動的應用連線延遲。
• 連接垃圾回收（GC）問題：Cilium 的連接追蹤表 GC 可能存在缺陷，導致表項累積，影響效能。

Istio (服務網格) 問題

Sidecar 過重、錯誤訊息模糊、CRD 對 ETCD 壓力大

• 網路複雜性增加：將單一 TCP 連接拆分為多段 TCP 連接，增加了網路層次的複雜度，使得超時和錯誤追蹤變得困難。
• 模糊的錯誤訊息：Sidecar 會攔截並包裝請求，導致錯誤訊息不夠清晰，難以除錯（例如，只回報 “protocol error”）。
• 資源消耗：每個 Pod 旁的 Sidecar 會額外消耗 CPU 和記憶體，在大規模部署下可能導致整體效能下降。
• ETCD壓力：Istio 引入大量自定義資源定義（CRD），這些頻繁的 ETCD 操作會加劇資料碎片化問題。
• 控制平面收斂時間長：隨著 Pod、服務等物件數量的增加，Istio 控制平面需要更長的收斂時間來更新網路路由，導致新服務上線或更新延遲。
• 高基數度指標：Istio 產生極大量的指標，可能導致 Prometheus 等監控系統因高基數度問題而過載。

趙秉祥 Bing Siang Chao｜大型語言模型在軟體工程中的應用：多代理系統的創新與挑戰

SDLC 現況挑戰

當前的軟體開發生命週期面臨多項挑戰，主要原因包括軟體複雜度不斷提升、市場需求增長以及過去開發流程中大量仰賴人工步驟。

• 效率低落：
  • 傳統的瀑布式開發（Waterfall）按部就班，每個階段必須完成才能進入下一個階段。
  • 即使敏捷式開發（Agile）和 DevOps 提升了效率，但執行過程仍以人工為主。
  • 這導致例如修改一個 Bug 可能需要花費三天時間。
• 溝通斷層：
  • SDLC 的六個基本階段（規劃、設計、開發、測試、部署、維護）通常由不同專業的團隊分工負責。
  • 規劃階段（planning）作為需求與開發之間的橋樑，涉及大量決策與邏輯。
  • 若設計階段（design）的決策不佳，可能導致後續一系列不好的結果。
  • 這些人工步驟容易造成資訊傳遞上的落差和效率低下。
• 品質不穩：
  • 由於人工介入的環節多，程式碼品質（code quality）、測試（testing）和部署（deployment）的過程都可能因為人為因素導致不穩定。
  • AI 的介入旨在改善這種對人工的依賴，提高容錯率和反應速度。

AI 協助 SDLC 的核心概念

AI 的出現大大改善了我們的生活，並預期將成為 SDLC 發展的必然趨勢。AI 介入 SDLC 的核心是透過大型語言模型（LLM）和自治代理（Autonomous Agent）來提升自動化和精準度。

• 核心參與者：
  • 大型語言模型 (LLM)：在文字處理、理解和生成方面已接近人類水準。
  • 自治代理 (Autonomous Agent)：定義為觀察周遭環境、做出決策並執行任務的智慧實體。當 LLM 被視為自治代理的「大腦」時，它們能進行人類級別的推理和操作。
• 多代理系統 (Multi-Agent System, MAS)：
  • 如同人類需要協同合作，代理也需要協同工作。
  • 多代理系統允許 AI 代理化身為不同專業角色，如需求分析師、設計師、測試人員等，在 SDLC 的各階段協同作業。
  • 這些代理的設計目標是模擬人類的能力，因此具有明確的分工。
  • 每個 AI Agent 都需要具備記憶、規劃、決策、使用工具以及從錯誤中學習的基本能力。
  • 多代理系統的工作流仍會遵循設計者定義好的代理協同模式來執行。
• 通訊與協作機制：
  • NCP (Natural Language Command Processing)：將原本需要函數程式碼來記憶每個函數的功能，轉變為統一管理的介面，大大增加彈性。NCP 可以處理資料查詢、資料處理等具體任務。
  • A2A (Agent to Agent)：由 Google 提出，允許代理之間透過某種協定進行更抽象的溝通。代理 A 可以要求代理 B 完成某項任務，而不需要詳細了解具體功能實現。例如，追蹤客戶進度或回覆 Email 等較大型的任務可以透過 A2A 進行溝通。NCP 和 A2A 是互補的概念。
• RAG 技術輔助 (Retrieval Augmented Generation)：
  • 在企業內部知識整合中扮演著非常重要的角色。
  • 企業的知識通常是私有的，要讓外部的 AI Agent 了解企業內部的知識儲備，RAG 是不可或缺的工具。
  • 優勢：透過整合企業內部的知識，RAG 可以減少幻覺（Hallucination），提升效率並提高成本效益。
  • 運作方式：AI Agent 驅動的 RAG 會先判斷使用者的意圖，再決定是否需要額外收集資料，或直接從資料庫中檢索，並將檢索到的資料整合回原來的生成過程，最後給出結果。

AI 在 SDLC 各階段的應用

1. 開發階段應用 (Development & Implementation)：

   • AI Agent 的應用已非常成熟，不僅輔助程式碼撰寫，還涉及更嚴謹的程式碼產生、除錯和安全檢查。
   • 分工概念：多代理系統能在此階段實現分工，例如有些代理負責產生程式碼骨幹，有些專注於優化，還有些則檢查程式碼的安全性。
   • FixAgent：根據 Review Agent 提出的問題，嘗試修改程式碼並與原始碼保持一致。其基本流程包括接收修復建議、原始需求描述和目前程式碼，然後透過 LLM 生成修復版本，再由 Validate Agent 進行驗證。這種迭代方式讓程式碼錯誤率不斷降低。
   • EVM (Evolutionary Virtual Machine)：將程式撰寫邏輯與模型概念結合，分為 Coding Agent 和 Unit Test Agent。Coding Agent 撰寫程式碼，Unit Test Agent 撰寫單元測試，並在環境中評估兩者。透過「文字的反向傳播」概念，根據損失（loss）判斷代理的完成度，並更新代理的貢獻。
   • 人類角色轉變：人類在寫程式方面，角色已轉變為引導 AI。

2. 維護階段應用 (Maintenance)：

   • 維護是 SDLC 中最容易被忽略但卻非常重要的一環，軟體工程師約 60-70% 的時間花費於此。
   • 自動修復 Bug：AI Agent 能輔助除錯（debug），例如 DeepC Fix 使用靜態分析器找出錯誤，重寫最小的可復現版本，再透過另一個合併（merge）代理將修復後的程式碼整合回原始版本。
   • 程式碼審查與文件撰寫：維護階段需要 Code Review Agent 和 Document Agent 來幫助程式碼審查和文件生成。
   • 系統更新與無痛升級：當版本更新導致部分套件無法使用時，AI Agent 可以協助進行無痛升級。它們能夠在產品線上即時更新，例如協助版本控制和兼容性處理。
   • 綜合應用：維護環節是前面各階段情境的統整，因此會需要多種 AI Agent 協同合作來處理線上產品的即時更新和持續維護。

實際案例與工具

• 中華電信案例：
  • 中華電信將 15 年、共 171 組文件匯入為 RAG 的資料來源，利用 AI Agent 協助撰寫客戶需求分析、系統分析以及後續的軟體開發和整合。
  • 這項實踐節省了約 40% 的需求與文件生成效率，並提升了約 30% 的程式碼撰寫效率。
• Amazon Q 作為 AI 助手：
  • 一個完整的 AI 助理產品，旨在為企業提供基礎工具，開發自己的 AI 輔助功能（copilot 或 co-assistance）。
  • Amazon Q Business：功能類似於中華電信的 RAG 應用。使用者可以輸入文件，查詢需求中的政策或注意事項。可協助撰寫使用者故事（user story），並將其轉換為 Jira 等系統的工單（tickets）以便後續追蹤。
  • Amazon Q Develop：一個成熟的程式碼協作工具。可在 VS Code 或其他 IDE 中使用，功能非常完整，能幫助撰寫程式碼，甚至根據執行結果優化程式碼。
  • 測試應用：可以分析日誌，標註異常行為。幫助檢查應用程式是否存在潛在漏洞或運算瓶頸。
  • 特點：Amazon Q 將多種功能整合為一套完整的系統，不同於大多數需要自行組合的開源工具。

未來趨勢與挑戰

• 軟體工程師角色轉變：AI 在 SDLC 中的應用已不再僅僅是工具，它更像是一個人類的合作夥伴，甚至能夠參與設計和思考。未來，軟體工程師的角色將轉變為引導 AI 協同工作的決策者和架構師，不再僅是撰寫程式碼的人。
• AI 將主導開發流程：例如 Google 的 Gemini 產品，可以理解自然語言需求，自動進行除錯、修復、測試、軟體更新、重構，並可連接 GitHub 自行處理 CI/CD。這預示著未來 AI 可能會從輔助轉變為主導，人類則扮演引導和監督的角色。
• 主要挑戰：
  • 任務誤解：AI 可能會誤解人類給予的任務。
  • 工作流限制：AI Agent 的工作流仍會遵循設計者定義好的代理協同模式來執行。
  • 效能與穩定性：AI 生成的程式碼品質和可靠性仍需人為監控。
  • 整合性問題：將 AI 技術整合到企業已有的數十年程式碼基底中是一大挑戰。
  • 安全與信任：AI 本身可能被蒙騙，AI 安全控管是重要議題。此外，AI 生成程式碼的產權歸屬也可能是一個問題。
  • 人機互動與權責劃分：人類如何與 AI Agent 共處？權責如何劃分？出問題時由誰負責？這些都是企業需要討論的關鍵問題。台積電在政策上傾向將 AI Agent 定義為輔助人類決策的工具，而不是替代人類。
  • 知識庫利用率與整合：企業大量散落的私有知識庫，在 LLM 和 Agent 出現後，有了更強的誘因去整合和利用，從而產生額外的行動和效益。這需要投入大量精力進行整理和維護。
  • 格式一致性與錯誤回報：A2A 和 NCP 架構下，需要保持介面標準化、數據轉換流暢，並統一工具註冊規範與錯誤代碼、敘述等，通常需要集中式日誌管理系統協助。
  • 外部代理的安全控制：需要身份認證，並在 AI Agent 執行涉及生產環境的行為時加入人工審查（Human-in-the-loop）進行監控。
  • 測試工具應用：AI 確實可以幫助補償人類在測試方面的盲點，特別是當注入公司專有的知識庫後，AI 理論上可以想到人類單一產品經理想像不到的面向，並生成測試數據。

連結

• 議程 https://www.tsmc.com/static/chinese/careers/2025tsmcitday/index.html
• 影片清單 https://www.youtube.com/playlist?list=PLT3USJy3vydAu1XUGO5dY30gd2RBw1QgT