這篇是 TSMC IT Day 2025 的 Q&A 整理，要看筆記可以點下面連結

[筆記] TSMC IT Day 2025

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

Q: 我們資料平台使用的技術堆疊是什麼？

• 資料儲存：使用 MinIO object store，它是一個 S3 compatible protocol 的 object store 。
• 儲存資料格式 (table format)：選用 Iceberg 。
• 資料收集方式：
  • Streaming (串流)：使用 Kafka 加上 Spark Streaming，Domain Application 將資料丟入 Kafka，再由 Spark Streaming 寫入 MinIO 。
  • Batch (批次)：Domain Application 將資料下載為 CSV、Parquet 等檔案格式，丟到 MinIO 的 Landing Zone，再由 Spark 將資料收集進來 。
• 資料查詢引擎：資料進入儲存層後，前端會掛載 Trino，提供 Query Engine 讓使用者進行資料查詢。Spark 目前尚未支援 。
• Metadata Service：使用 Hive Metastore 。

Q: 資料平台如何支援台積電在半導體製造中的決策？是否有及時數據分析或可視化？

• 及時性：目前處理的場景多為 Near Real Time (近即時)，資料延遲約在 3 分鐘左右 。選擇此延遲是基於成本效益與業務需求考量，若需更即時則需考慮技術架構與程式碼上的成本。目前大多數應用可接受此延遲 。
• 可視化應用：平台上的數據分析主要用於製作報表，例如廠區監看機台產能或晶片良率分析 。這些報表系統可能是 IT 協助開發的系統，或利用 PowerBI 等工具提供可視化應用分析 。

Q: 如何建置自助式大數據平台？是否有支援資料分析的工具或系統能簡化非技術用戶的操作？

• 平台直接接觸的用戶多為 Power User (進階使用者)，他們通常具備 SQL 能力，能直接使用平台提供的工具進行分析 。
• 針對不同技術程度的 Power User，平台提供：
  • PowerBI 或 Superset：用戶可透過它們下 SQL 並進行可視化 。
  • DBT：與 DBT 整合，讓有 Python 程式能力的使用者能建構資料管道 (pipeline) 。
  • Spark：提供給更進階的用戶處理資料 。
• 針對完全不會使用 SQL 的用戶，平台不直接提供工具，而是由各個 Domain Application 在平台上建構應用程式 。這些應用程式會呼叫 Trino 的 SDK (支援 Python, Java, Go 等)，從 Trino 取得資料，並提供使用者友善的 UI (使用者介面)，讓他們可以直接在介面上選擇資料、點擊按鈕，呈現預先定義好的報表 。這是因為各個領域的數據分析需求高度客製化，通常由各 Domain 的數據團隊利用平台作為基礎來建構這些工具 。

Q: 台積電大規模資料平台建置 ETL 如何在台積電有效跨地區、跨系統？是否有特定的技術堆疊或架構設計能分享？

• 跨地區能力：台積電不使用公有雲服務 (如 AWS, GCP)，因為其任務是建立台積電內部的公有雲 。要實現跨地區資料管理，需與基礎建設團隊合作，由他們在各廠區（如台灣的台中、台南、新竹，以及日本、德國、美國等地）建立 Data Center 並串聯起來，資料平台再架構於其上 。
• ETL 流程：大部分 ETL 處理的是該廠區的資料，因為工廠數據直接產生於當地，並寫入該廠區的資料平台 。
• 跨廠區分析需求：
  • Trino 直接查詢：允許在一個廠區的 Trino 直接查詢其他廠區的 MinIO 和 Hive Metastore 資料 。好處是使用者可在同一個廠區跨廠區取用資料，直接用 SQL 進行關聯分析 。缺點是可能佔用較多頻寬 。
  • 資料複製 (Replication)：將台灣廠區的資料複製到美國廠區的某張表，讓美國廠區能在本地直接存取資料進行分析 。這是目前的開發方向之一 。

Q: Iceberg 也有 Metastore，為何會選用 Hive (H)? 是因為原有 Hadoop 存在的關係嗎？

• 選擇 Hive Metastore 的原因的確與台積電內部原有的 Hadoop 維護經驗有關 。
• 面對大規模挑戰，台積電初期選擇了內部相對較為熟悉的組件，且 Hive Metastore 是一個成熟的 Catalog Service 。

Q: 台積電主要解決的分析問題比較偏向分析應用程式如何處理？

• 是的，台積電的「大數據平台」名稱就是 Analytical Big Data Platform，主要處理分析型的應用 (analytical applications) 。
• 至於 OLTP (Online Transaction Processing) 相關的應用，則由另一個團隊負責，提供類似 Oracle Data Warehouse 的服務 。

Q: 團隊在三種 Table Format (Iceberg, Hudi, Delta Lake) 中選擇 Iceberg 的主要原因？

• 架構理解度：經過內部審查，認為 Iceberg 的架構相對清晰、易於理解，未來也更容易進行修改和擴展 。
• Hudi 的 Legacy：Hudi 推出較早，其架構包含較多舊有部分，儘管後來有大型重構，但從導入角度看，Iceberg 結構更清晰 。
• 非排他性：團隊並非不使用 Hudi 或 Delta Lake，Iceberg 僅是第一版採用的格式 。未來考量到 Delta Lake 逐漸偏向 Real-time Streaming 的特性開發，某些特殊應用場景下，團隊仍可能考慮採用 Hudi 或 Delta Lake 。

Q: 針對 Data Hub 想提出舊系統串接問題，有些老舊或封閉系統缺乏 API，較難導入 Data Hub

• 台積電的系統是新開發的，所以較少遇到 Legacy 系統串接 Data Hub 的問題 。
• 在設計之初，團隊有研究過 Data Hub 的串接方式，這部分是客製化的設計 。

Q: Spark SQL 為何會選擇 Trino 呢？

• 聯邦查詢引擎 (Federated Query Engine)：Trino 不僅是 SQL 查詢引擎，它也是一個聯邦引擎，可以連接不同的資料系統 。
• 新舊系統並存：台積電目前的平台新舊系統並存，Trino 可以串接舊世界的 Oracle 或 Cassandra 資料，同時連接到新世界的資料庫，實現聯邦式存取 。
• 使用者友善 (User Experience)：Trino 的使用者體驗較佳，很多人喜歡它能夠立即得到查詢回應 。
• Spark 仍會提供：並非不提供 Spark，而是作為平台，在提供這些工具時，會選擇最適合的 。

Q: 貴公司底層資源運算資源是自己架機嗎？還是沒有使用任何公有雲？

• 是，台積電是自己架設機櫃，沒有使用任何公有雲服務 。
• 在資料處理部分，都是內部自行建置 。

Q: 台積電目前是否自行開發 GPU 算力資源平台？

• 這部分不在資料平台的範圍內，應由其他平台團隊負責 。

Q: MinIO 最近有一些 License 相關的議題，怎麼去應對？

• MinIO 的負責團隊是獨立的，資料平台團隊與其合作 。雖然知道他們可能正在追蹤這方面的問題，但這不在資料平台團隊的雷達範圍內 (即他們主要負責 Trino, Spark, Kafka 等) 。

Q: 團隊平常工作一整天會長什麼樣？

• 平台開發分兩部分：
  • Self-service Console 開發：主要負責 Console 的後端開發 。
  • ETL Pipeline 開發：負責 ETL 管道的開發 。
• 這是現階段的重點 。

Q: 這麼多技術選擇，團隊是怎麼評估的？

• 經驗與流行度：由於需處理的資料量極大，評估策略會從團隊成員經驗較多的技術開始，並優先選擇社群資源豐富且多人使用的熱門工具 (如 Iceberg, Hudi, Delta Lake 等) 。
• 逐步嘗試新技術：並非只使用現有經驗的工具，而是在逐步過程中嘗試新東西 。但必須有基本工具能保證處理現有量級的資料 。
• 持續轉變：例如，目前選擇 Iceberg，但不保證未來不會轉用其他 Table Format，會根據遇到的挑戰進行轉換 。

Q: 內部對開源是鼓勵的嗎？

• 是，鼓勵使用開源軟體 。
• 例如，許多平台的核心技術堆疊都是開源的 。

Q: Data Engineer 是屬於單位，還是會散到其他使用平台的團隊？

• 不同 Data 團隊的 Data Engineer 職位要求不同 。
• 資料平台這邊招募的 Data Engineer 更偏向要求 Spark 能力、對 SQL 的理解 。
• 其他 Domain Data Engineer 可能更專注於 SQL 應用，例如 Oracle Stored Procedure 轉換為 Trino SQL 或 DBT 寫作 。
• 具體職位要求建議與 HR 詢問 。

Q: IT 部門如何衡量各應用題目、使用者需求及開發順序？

• 初期由於專案相對較新，使用者數量漸增，尚未遇到應用優先順序問題 。
• 目前已開始遇到問題，因為各團隊 (T) 需求眾多 。
• 現在已有 PM 加入，會與各團隊討論需求，排定優先順序，並有 Review Process 處理這部分 。

Q: 貴單位團隊大概需要多少人起來撐起整個技術？

• 目前約 20 人左右，還在持續擴張中 。

Q: 可以使用免費軟體嗎？

• 如果指的是開源軟體 (Open Source)，那團隊建構的技術堆疊都是開源的，所以沒問題 。
• 如果是其他免費軟體，則需視公司規範 。

Q: Console 是從零開始開發，還是有參考其他開源專案？

• Console 是從零開始開發的 (from scratch) 。
• 因為團隊有針對使用者互動進行設計，且沒有找到合適的開源專案可供參考 。

Q: 資料平台是架在 K8S (Kubernetes) 上還是 Hadoop 上？

• 舊有的 Hadoop 是獨立系統，資料平台不想直接與其綁定 。
• 資料平台是獨立架設，且目前都架設在 Kubernetes (K8s) 上 。
• Spark 也是架設在 K8s 上 。

Q: 如何導入新的開源工具和技術？怎麼克服引進時的摩擦力？是設計一個最小可行性模型來說服其他人嗎？

• 流程：
  1. 首先會用團隊現有經驗較多的技術，先建立一個基礎版本 (base version) 。
  2. 建立後會有衡量指標 (matrix) 和成熟度基準 (mature baseline)，以便未來評估新技術帶來的改善效果 。
  3. 接下來會探索各種技術發展，進行內部評估，包括效能 (performance)、效率 (efficiency)、可靠性 (reliability) 等是否優於舊技術 。
  4. 內部會有一個審核流程 (review process)，這正是提問中提到的「最小可行性模型 (Minimum Viable Product, MVP)」階段 。
  5. 若整個團隊經過審核認為可行，就會採用 。

Q: 各世代平台轉換需多久時間？轉換方式會是怎麼選擇？

• 時間：轉換將會花費相當長的時間，可能需要數年 。
• 挑戰：台積電過往累積了幾十年的資料，其上的應用程式已有成百上千個 。與各應用程式協調轉換時程將是巨大的成本 。

Q: 總結：團隊的角色定位、專注方向與挑戰

• 角色定位：團隊是 Data Scientist 或 Data Analyst 的助手與夥伴 (partner)，不直接看資料內容，而是提供「軍火庫」來幫助他們開發與加速 。
• 專注方向：
  • Productivity (生產力)：實施自助式平台，希望讓台積電從上到下，任何有資料存取或分析需求的人都能輕鬆使用平台 。
  • Performance & Efficiency (效能與效率)：在大規模數據下，挑戰如何做到更高效能、更快速度的資料處理，並提升複雜 SQL 查詢的執行速度 。
  • Robustness (穩定性)：作為平台，穩定性至關重要，在如此大的量級下處理數據的穩定性是核心挑戰 。
• 最大挑戰：規模 (Scale)，包括資料的量級、應用的量級與複雜度 。

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

Q: 在微服務架構中的挑戰有哪些？例如 Trace ID 的傳播會不會掉？掉了怎麼辦？

• 微服務化帶來的挑戰：進行 Observability 的很大一部分原因就是為了微服務化，這也帶來了系統承載和規劃的挑戰，以避免服務過載 。
• Trace ID 傳播：
  • Propagation (傳播) 的重要性：Trace ID 涉及資訊的產生 (context) 和傳遞 (propagation) 。OpenTelemetry 等標準規範可以幫助解決溝通問題 。
  • 傳播策略：
    • 修改 Application 等級：可能需要購買 SDK 等來實現 。
    • Sidecar 或 Proxy 方式：透過 Sidecar 或 Proxy 來進行傳播 。
  • 這些策略各有優劣，需根據實際技術選型和權衡來決定哪種最適合 。

Q: 如何做 Observability 平台整合 Log、Trace 以及可視化關鍵指標？

• 回歸本質：關鍵在於「你的系統到底要監控什麼？」這會影響到你記錄什麼 Log 和 Metric 。
• Google 的 Golden Signals：若不知從何開始，Google 建議至少監控四個黃金訊號：
  • Latency (延遲)：請求所花費的時間 。
  • Traffic (流量)：系統處理的請求數量 。
  • Errors (錯誤)：請求失敗的速率 。
  • Saturation (飽和度)：系統的資源利用率 。
• Dashboard 呈現：知道要監控什麼後，再決定如何呈現 Dashboard 。對於硬件類的常規指標 (如 CPU, Memory)，Grafana 等工具通常已有現成的 Dashboard 可供參考，從現有範本修改會比從零開始容易 。

Q: 關於分散式、高效能架構，如何選擇技術以及如何收集資料？

• 優先順序：首先思考 Log、Metric 和 Trace 這三者是否都要做？優先順序為何？
• 技術選型：針對不同部分，選擇合適的技術 。
• 資料收集模式：考慮採用何種收集模式 (Push 或 Pull) 和方式 (SDK 或其他) 。這些方式各有優劣，取決於環境和狀況 。
• 承載能力與管理：在多服務環境下，需考慮服務的承載能力，避免因發送過多數據而對服務造成壓力 。部署和管理這些服務的方式也很重要，例如可利用 Infrastructure as Code 的概念，甚至 Observability as Code 來快速部署到不同環境 。
• 多服務環境：台積電規模龐大，不可能單一服務就能支撐所有應用程式 。需要規劃多個服務實例，並考慮物理限制 。

Q: 台積電每天收集多少 Observability 資料？

• 具體數量未提及，但講者指出，僅 Log 的量就非常龐大 。若加上 Metric、Tracing 和多個環境、多個廠區的數據，數量將會是「非常大」且「很困難」的級別 。
• 這項工作是必須執行的，因為停產線的影響度極大 。

Q: AP 是否透過 Elastic Agent 拋資料到 Hotrod Collector？為何 VM 的 AP 不走這條路？

• 講者當時描述的是 Log 的部分，任何東西都可以這樣做，並無不能這樣做的原因 。
• 當時主要著重於如何透過不同方式達到 Log 資料收集的效果，而非特定焦點 。

Q: 台積電在資料收集這塊，如何確保 Log 從檔案端到 Elastic 的過程中沒有掉失？如果 Log 很重要，有沒有監控在裡面？

• 掉失可能性：資料掉失是可能發生的 。
• 重要性區分：
  • 對於 Mission Critical (任務關鍵型) 的 Log，會投入大量資源確保不掉失，並有對應的監控 。
  • 對於非 Mission Critical 的 Log，會進行權衡取捨，因為不可能所有 Log 都以最高標準處理 。
• 這是一個取捨而非對錯的問題 。

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

Q: 除了通靈與猜之外，怎麼解決一些官方文件、Git Issue 都沒有記載的問題？

• 這類問題確實很難解決，Git Issue 也是大家遇到才去問的 。
• 排查步驟：
  1. 從系統指標 (Monitoring 或 Observability) 觀察異常症狀，並結合對系統的理解進行推測 。
  2. 查看源碼 (Source Code)：這是最核心的方法 。現在 AI 工具發展使得查看源碼比以前容易，可以輔助簡化 。
  3. 重現問題 (Reproduce)：只要能重現，後續排查就相對容易 。這類問題可能需要進入更深層次，例如使用火焰圖 (Flame Graph)、Go Profiler 或 GDB 等工具，針對不同程式語言使用不同除錯工具 。
  4. 善用關鍵字搜尋：有時 GitLab Issue 並非不存在，而是不知道如何用關鍵字查詢 。透過症狀抽絲剝繭找到相關案例後，就有機會找到正確的關鍵字 。

Q: Kubernetes Service Mesh (例如 Istio) 存在許多隱藏風險，為何台積電仍使用它？好處比壞處多嗎？

• 好處：從平台角度來看，Service Mesh 提供統一的方法來實現功能 (例如 Istio 提供的功能，若沒有它則每個使用者需自行實作) 。
• 風險與管理：最大的問題在於「壞分子」：如果使用者不遵循規範，錯誤的使用方式會對整個叢集或平台造成比想像中更大的影響 。
• 功能考量：某些功能若不依賴 Service Mesh 則難以實作 。例如：
  • 多叢集備機/保護：跨多套 Kubernetes 叢集、跨 Availability Zone (AZ) 的保護 。
  • 跨叢集通訊：讓 A 叢集的 Pod 能連接到 B 叢集的 Pod 。目前最成熟的工具是 Service Mesh (Layer 7) 或 CNI (Layer 3/4)，兩者專注層次不同，Service Mesh 在特定應用中（如流量管理、認證授權）仍有優勢 。
• 不依賴 Service Mesh 也能做到，但需投入更多資源和精力在網絡層面進行抽象和封裝 。

Q: etcd 預設使用 Base64 編碼儲存 Secret，有沒有類似的工具 (如 Vault)？

• 有使用 Vault 。
• 注意事項：使用 Vault 時需特別注意其 Sync Period 。ETCD 在大量相同資料更新時，容易造成儲存空間的請求或分配問題，最終可能導致需要更頻繁地進行 Defrag 。Sync 時間太長會讓使用者覺得更新未生效，太短則可能對 K8s 造成額外負擔 。

Q: 三年前的 TSMC IT Day 提到在研究 Serverless (無伺服器) 架構，想問有沒有遇到什麼問題？以及 Serverless 是否能解決 CPU 和 Memory 的問題？

• Serverless/NbMO (Network as a Service based Microservice Orchestration) 發展快速，但實際應用並非那麼好用 。
• 挑戰：
  • 與傳統機制衝突：Serverless 需要額外的 CNI (Container Network Interface) 安裝，多套 CNI 環境切換會很麻煩 。
  • 實作複雜度高：其原理比純 K8s 更複雜，例如封包流量攔截透過 eBPF (Extended Berkeley Packet Filter) 搭配 Kernel 方式，若不熟悉會比 IPtable 更難除錯 。
  • Layer 7 功能不完善：例如 Sticky Session 等功能，在 NbMO 中目前支援度不佳 。
• Serverless 並不完全解決 CPU 和 Memory 問題，它更多是抽象化和管理資源的方式 。

Q: 台積電的 GPU 管理平台也是採用 K8s 架構嗎？或是有自行開發的排程軟體？

• 是，目前使用 Kubernetes 架構 。
• 對於 GPU 管理，主要使用 NVIDIA 的 Operator 等工具，並結合內部支持進行整合，因此仍以 Kubernetes 為基礎，搭配 Device Plugin 或相關資源請求的 Query 來管理 。

Q: 會建議所有服務都統一在一個 Cluster 中嗎？或是會根據不同專案提供不同 Cluster？

• 這個問題關於 Share Cluster (共享叢集) 或 Dedicated Cluster (專用叢集)，沒有完美答案，因應用情境不同 。
• 共享叢集優點：數量少，管理相對簡單 (Day 1: 建置、更新；Day 2: 日常維運、問題排查)，資源共享和調度較簡單 。
• 共享叢集缺點：若有「壞人」或錯誤使用情境，可能影響所有人 。
• 專用叢集優點：彼此獨立，互不影響，單一錯誤只影響自身 。
• 專用叢集缺點：資源利用率可能較低，造成浪費 。
• 這是一個持續學習和權衡的過程，需觀察哪種應用程式需要專用叢集，哪些可以共享，以及團隊有多少人力進行管理 。

Q: 使用 Ceph 有遇到什麼樣的問題嗎？

• Metadata Server 量大時的困境：Ceph 在 Metadata Server 量大時，會遇到許多處理上的困境。
• 建置注意事項：K8s 內雖有 Rook 等工具簡化安裝，但對於優化和問題排查仍需回歸到 Ceph 本身的知識 。
• 若要善用 Ceph，必須掌握其原理和文件，才能在規模擴大、使用者增多時妥善處理問題 。

Q: K8s 升級是一個很重要的平台議題，包含 CNI, CSI 升級都會有大量相容性或 API 問題，台積電怎麼做？

• 嚴謹測試：K8s 官方雖稱兩個 Minor 版本內不會有 API 不相容問題，但仍需實際測試驗證 。
• 多環境驗證：台積電會在 Stage (預演) 和 Dev (開發) 叢集進行升級驗證與測試 。例如，K8s 1.30 版曾發生與官方說法不符的 API 不相容情況 。
• 輔助工具：建議導入 ClusterLoader 等官方測試工具，產生大量不同工作負載，驗證 Control Plane 運作效能和 KPI，確保基本功能不受影響 。
• CNI、CSI 等網路、儲存和運行時元件的升級，都需在 Stage 和 Dev 環境進行驗證 。

Q: 貴團隊是否透過 AI (LLM) 協助除錯跟 Log 分析，進一步修復問題？

• 有嘗試過 。
• AI 輔助分析：AI 確實可以幫助快速分析 Log 。
• 問題解決核心：然而，大多數問題都回歸到元件非常深層的地方，單純看 Log 可能無法找到真正問題 。要真正找到問題並解決，還是需要對專案的源碼和內部機制有深入了解 。

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

Q: AI 持續發展中，從大型模型到 AI Agent 的應用，對於現行系統整合發展上有何影響與需要注意的地方？

• 影響：對於企業最大的影響是知識庫的利用率 。以往企業內部封閉式的知識散落各處，整合和維護成本高，且效益僅限於查找 。LLM 結合 AI Agent 的出現，實質上給予企業巨大誘因，促使各單位貢獻並整合知識，進而透過知識執行額外的動作 。
• 注意事項：
  • 不確定行為：LLM 和 AI Agent 本身會產生不確定行為，因此在設計時必須適當加入人工檢查點 (Human-in-the-loop) 。
  • 權責劃分：需明確人類與 Agent 的權能劃分，並釐清出問題時的責任歸屬 。

Q: 台積電如何將使用 AI 工具來輔助 IT 系統的開發及維運？以及 AI 將來如何協助生產？

• AI 輔助 IT 系統：AI 最終會像人類一樣，以多個角色協同人類工作 。例如：
  • 產品規劃：初期的產品規劃會由一個了解企業規範和客戶背景的 Agent 協助 PM 。
  • 設計架構：有會做設計架構的 Agent 協助架構師 。
  • 程式碼生成：有會寫程式碼的 Code Generator (市面已有多種產品) 。
  • 除錯與測試：協助 Debug、Unit Test、監控和部署的 Agent 。
• 未來 IT 的功能人員必須學會引導這些 Agent 協同工作 。
• AI 協助生產：早在 LLM 出現之前，台積電就已透過許多其他技術協助生產，並已取得很大進展 。LLM 和 AI Agent 的最大幫助在於更深層次的能力，例如歸因分析 (Root Cause Analysis) 或建議 (Recommendation) 等更複雜的層面 。

Q: 台積電在自己研發內部系統時，面對既有流程與新技術 (如 ML、雲架構) 的整合挑戰，如何做技術決策或系統演進？

• 決策流程：
  1. 專案初期：PM 和資料科學家會審慎評估可能的解決方案，了解業務目標和影響，並估算專案成本，最終提出提案 。
  2. 後期：經理角色會參與技術決策，以完整啟動專案 。
• 系統演進：由 PM 主導開發團隊，制定整體 Roadmap，並在擬定技術藍圖時討論和測試新技術的導入與評估 。

Q: 台積電 IT 部門的工作文化如何？是否鼓勵創新與敏捷開發？

• 台積電 IT 是一個樂於分享技術、以跨團隊協作方式進行專案的團隊 。
• 團隊之間溝通協調快速，為推動知識累積和技術實施，各團隊基本上都執行敏捷開發 (Agile Development) 。
• 鼓勵創新：部門鼓勵成員提出自己的想法和見解，可能會研究最新技術或解決方案，與 PM 討論後提出更完整的解決方案。

Q: 台積電如何導入 AI 工具運用在現行工作流程？

• 釐清痛點與評估衝擊：在工作需求上，需釐清痛點是什麼，並評估 AI 工具可能造成的衝擊，因為在台積電環境中，任何影響都可能非常大 。
• 直覺與方便：在釐清這些之後，才會推出更直覺、更方便使用者使用的 AI 工具或服務 。

Q: 主要使用哪些程式語言及開發工具？AI 相關軟體可以使用嗎？

• 程式語言：主要開發語言包含 Python、JavaScript 等多種 。
• 開發工具：主流的開發工具都可以使用 。
• AI 軟體：由於涉及資安 (Security) 和智慧財產權 (IP) 議題，必須經過公司管控，並在確認符合 IP 相關規範後才能使用 。許多新的 AI 工具已在台積電內部使用 。

Q: 對於新技術引入公司流程的方式？

• 基本上會透過明確且嚴謹的流程，每個階段都經過嚴格審查後才會進行 。
• 不論是評估、測試、開發或新技術的引入，都需走完前端流程，經過提案、開發、驗證等階段，才能確認 AI 新技術或服務可實際落地於台積電環境 。

Q: AI 如何優化？

• 使用者回饋 (User Feedback)：最常見的做法是收集使用者族群的回饋 。台積電推出 AI 服務時，可能面對不同使用者族群，會分階段讓不同族群試用，收集回饋後迭代修改、優化、改善，或推出新功能 。
• 技術團隊主動提案：技術團隊也可以從自身角度出發，提出新的功能或技術解決方案，取代舊有方式或進行優化，並經過評估後推行 。

Q: 如何用 AI 技術協助公司內部的知識管理？

• 輔助撰寫：AI 可協助簡化撰寫工作，例如總結、翻譯或格式修改 。
• 品質與格式一致性：透過 AI 確保內部知識儲存的品質與格式一致性 。

Q: 是否使用框架開發 Agent？

• 是，會使用許多框架來開發 Agent 。
• 若 AI 技術研發需要使用外部框架或 Library，會經評估後引入開發 。若內部有特定需求，也會自行開發框架或 SDK 。

Q: Agent 如何部署及管理？

• Agent 的部署與管理有相應的平台 (Platform) 協助執行整個自動化流程，目前已支援 。
• 這些平台不僅提供資源，也支援傳統的 ML (機器學習) 和 ML Training 。

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

Q: 如何在半導體高度精密製程環境中減少大型語言模型 (LLM) 的「幻覺」問題，並提高準確性？

• 幻覺是固有問題：幻覺是 LLM 的先天缺陷，目前技術只能緩解，無法根除 。隨著時間推移，新模型幻覺率已越來越低 。
• 工程面解決方案：
  • RAG (Retrieval-Augmented Generation)：最流行的方法是檢索增強生成，但 RAG 之後仍可能存在問題 。
  • 歸因 (Attribution) 和 Forcing 等模組：在 RAG 後端增加這些模組，可大幅緩解幻覺問題，但無法達到 100% 解決 。
• 使用者素養與風險評估：隨著 AI 工具普及，使用者對其天生缺陷的認知逐步提高 。導入 LLM 時應思考其風險：
  • 高風險應用：若應用錯誤會導致嚴重後果 (如金融業的客服)，應謹慎考慮是否採用，或透過其他設計方式避免此狀況 (如僅提供資訊，不做關鍵決策) 。
  • 低風險應用：若效益高且風險相對低 (如企業內部找文件、研究輔助工具)，即使有幻覺，只要在產品設計上多加使用說明或介面引導，使用者仍願意接受 。
• Human-in-the-loop (人機協作)：在產品設計中，Human-in-the-loop 是非常必要的，最終決策權仍由人類承擔 。

Q: 台積電如何看待 AI 對於高階決策的支援？未來是否有計畫讓 AI 在策略制定中扮演更重要的角色？

• 嚴謹的 AI 政策：台積電內部對 AI 應用非常嚴謹，去年制定了 AI 政策，定義了全公司使用 AI 的核心原則 。
• 人類為決策核心：根據現行政策，高階決策仍以人類為核心 。AI 的角色僅限於輔助分析和提供洞察 (insights)，最終決策仍由人類承擔與負責 。
• 保留靈活性與避免風險：目前高階決策不敢完全依賴 AI，以保留決策靈活性，並避免完全依賴 AI 可能帶來的風險 。

Q: IT 部門的 AI 工程師與其他部門 (如 CIM、AIFBI) 的 AI 工程師的工作差異為何？

• IT 部門 AI 工程師：作為一個較為中心化 (centralized) 的組織，IT 部門的 AI 團隊服務範疇非常多元，涵蓋製造廠區、研發單位、財務、法務、人資等所有領域 。因此，他們處理的題目也極為多元和有趣 。
• 其他部門 AI 工程師：
  • CIM (Computer Integrated Manufacturing)：偏向廠區歸屬的組織，其應用主要符合該單位的領域範疇，服務廠區相關的 AI 應用 。
  • AIFBI (AI for Business Intelligence)：負責公司的一些商業智慧任務 。
• 因此，不同部門的 AI 應用範疇和工作重點有所不同 。

Q: 如果公司本身的舊文件就整理得不好，即使使用 LLM 效果也不會好，要將舊文件重整很不實際，如何解決相關問題？

• 這是一個常見問題，當 RAG 效果不佳時，往往發現是源文件整理不善 。
• 建議做法：
  1. 分階段、分主題、有優先序地整理：不必一開始就將所有文件整理完整，而是從公司最重要的資產開始，有系統地建立，並讓流程自動化 。
  2. AI 輔助內容優化：在文件中加入 AI 輔助工具，確保內容品質符合要求，例如 AI 可以在寫作過程中提供提示，避免完全由人工撰寫和審閱 。
  3. 定義品質模板：在特定領域，定義文件品質的模板和寫作指南 (guideline)，AI 即可輔助產出符合規範的內容 。
  4. 自動抽取與標準化：鼓勵員工在使用公司重要系統時，將實驗結果等結構化數據透過 AI 轉換為更易於 AI 讀取和利用的格式，自動產出完整的報告 。
• AI 介入點：AI 可以在多個環節介入，例如透過機器和 AI，結合人類的指導，自動產出完整且符合 AI 讀取格式的報告 。

Q: 針對未知 (unseen) 的公司大量資料，如何與 LLM 結合？例如 Log file 的分析、大型資料庫資料分析等？

• LLM 不理解企業內部資料：大型模型在訓練時，因訓練資料關係，無法讀懂企業內部的機密資料 。
• RAG 適用文件：RAG 是一種常見方式，但主要用於文件型資料 (document-based data) 。
• Agent 架構應對大量 Log/資料庫分析：針對大量 Log File 或大型資料庫分析，非常建議導入 Agent 架構 。
  1. 問題解讀：當有系統或機台問題出現時，Agent 架構會先解讀問題 。
  2. 知識庫輔助：Agent 會搭配一個知識庫 (KM) 。問題出現後，Agent 應能查詢 KM 獲取相關指南 (guideline) 。
  3. 自主規劃與執行：得到 Guideline 後，Agent 能夠自主進行規劃 (planning)，知道手邊有哪些工具 (例如處理 Log 檔案的工具、資料庫工具)，並根據問題和 Guideline 決定從何處存取資料，進行整理 。
  4. 最終回覆：最後 Agent 將整理好的資訊回覆給使用者 。

Q: IT 部門有專職的測試工程師嗎？還是開發團隊兼任測試工程師？

• 對於企業內部的大型專案，IT 部門的組織分工非常細緻 。
• 有負責開發 (Dev)、後端基礎設施支援 (Infra Support)、平台工程師等 。
• 大型專案會有專門的 QA 團隊，當產品經理定義產品、開發團隊實作後，在進入 MVP (最小可行產品) 階段時，專業 QA 團隊會作為先行用戶進行測試並回饋問題。

Q: 台積電有沒有研究地端 (On-premise) 的 SLM (小型語言模型)？如何落地？

• 有研究，且非常推薦走 SLM 這條路 。
• 原因：
  • 成本效益：大型語言模型的託管成本極高 。若企業內部有機密資料需求，不適合呼叫外部模型 。地端部署 LLM 也很昂貴 。SLM 可以大幅降低企業內部 GPU 的成本需求，提高效率 。
  • 特定領域效能：若能定義好模型範圍 (scope)，訓練出的 SLM 在該單一領域的表現 (效果和品質) 會非常好 。
  • 效率提升：SLM 搭配 Agent 應用時，LLM 呼叫次數非常多，SLM 能顯著提升整體效率 。
• 現行做法：台積電目前也支持並正在朝著大小語言模型在同一個應用上共同運作的方向發展，以達到更好的整體效率 。

Q: 怎麼在 A2A (Agent to Agent) 加上 NCP (Natural Language Processing for Conversational Platform) 架構下，NCP Server 要怎麼做到格式一致、錯誤可回報以及對外部 Agent 的安全控制？

• 這是一個複雜的問題，只能從概念上說明 。
• A2A 與 NCP 協同：概念上，函數程式碼可整理成 NCP，形成 Agent，Agent 之間再透過 A2A 溝通 。關鍵在於如何設定 Agent 的解析度 。
• 格式一致與錯誤回報：
  • 介面標準化：保持介面一致性、標準化介面層 。
  • 數據轉換流暢：確保數據轉換順暢 。
  • 工具註冊與描述：工具的註冊和描述需有統一規範，例如定義檢查機制 。
  • 錯誤代碼與敘述一致：錯誤回報需使用統一的錯誤代碼和敘述 。
  • 集中式日誌管理：採用集中式日誌管理，並利用現有工具追蹤回傳 。這需要大量人員參與整體溝通和設計 。
• 外部 Agent 安全控制：
  • 身份認證：執行身份認證等安全措施 。
  • 行為監控：若 Agent 會執行到實際生產線行為，必須有監控機制，例如 Human-in-the-loop (人機協作)，由人類在其中進行管控 。
• 台積電政策：台積電對此方面政策較為保守 。公司的 AI 政策區分兩種：AI 輔助人類 和 AI 替代人類做事 。通常 A2A 或 NCP 形成的 AI Agent 會歸類在第一類，即輔助人類作用，決策仍由人類決定 。因此這方面需謹慎 。

Q: 現有的黑白箱測試工具可利用 AI 替代嗎？台積電有實現這部分嗎？

• 有部分實現，但細節不便透露 。
• AI 輔助作用：AI 確實可以幫助補足人類可能未考慮到的測試面向 。
• 知識庫導入：需將公司（如台積電）的知識庫灌輸給 AI 。人類不可能知道所有知識，因此當知識庫灌輸後，只要架構設計得好，AI 理論上可以想到人類單一 PM (產品經理) 無法想像的測試面向 。
• 生成測試數據：利用 AI 發現的這些面向，再透過生成式模型生成測試數據 (data)，這是可以實現的 。

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

Q: TSMC 是否已實際採用 AI 技術進行晶片設計，例如自動化設計 (Auto Design)、圖案化 (Patterning) 的邏輯模擬與驗證？這是否成為提升設計效率的關鍵？

• 晶片設計與製造分工：工廠端負責製造，研發端負責設計，中間有大量的模擬與驗證過程 。
• 與客戶合作：台積電與許多客戶合作，客戶負責 IC 設計，台積電會拿客戶的 Layout 進行更多優化，使其更適合製造 。
• AI 在晶片設計中的應用：
  • Layout Patterning 優化：包括 Layout 設計優化和光罩設計優化 。光罩設計優化與良率 (FB) 相關，因為它影響最終曝光結果 。
  • 數值與影像分析：許多數值分析和影像分析都用於 Layout Patterning 。
  • 缺陷熱點預測：例如，某些圖案 (Pattern) 可能特別容易產生缺陷 (DF) 的熱點，AI 可用於分析和預測這些問題 。
• 這些技術確實是提升設計效率的關鍵 。 以下是將提供的文本內容整理成 copyable markdown 格式：

Q: 在 AI 視覺辨識任務中，面對高良率的生產環境，低缺陷影像難以收集，如何在少樣本的情況下訓練有效的模型？

• 這是一個業界常見的難題，特別是在低瑕疵檢測領域。
• 兩種主要做法：
  1. 訓練 Foundation Model：根據內部收集的大量影像資料訓練一個大型的 Vision Foundation Model (視覺基礎模型)。期望透過看過大量內部各式影像和電路圖的圖案，模型在看到未曾見過的低缺陷影像時，仍有機會辨識出來。
  2. 生成低缺陷影像：透過下達 Prompt，利用生成式 AI 模型來生成所需的低缺陷圖案 (Pattern) 或樣貌。
     • 這在台積電內部已有多年實踐，因為真實產線良率很高，缺陷影像非常稀少。
     • 透過生成影像的方式來產生模型訓練所需的低缺陷資料。

Q: 生成有瑕疵的 Image 所使用的 Foundation Model 是使用少量瑕疵進行 Fine-tune 嗎？需要多少量瑕疵才能有好的效果？

• 引入外部 Foundation Model 並 Fine-tune：在訓練時會引入外部的 Foundation Model。
• 分層訓練與數據量：電路是層層堆疊的，有許多不同的圖案層。在生成時，會關注每一層的圖案小影像大約有多少。根據經驗，每一層的圖案影像通常需要收集至少 1000 張以上的量，才能用於 Fine-tune 引入的 Foundation Model。
• 生成效果：在此情況下，下達的 Prompt 就可以有效生成該層可能需要的低缺陷影像，包括其位置、大小或強度 (申淺) 等。

Q: AI Vision 部分有 OCR (光學字元辨識) AIV (AI Vision) 部分，目前中文部分團隊中有專門訓練嗎？還是大多使用雲服務？

• 面臨多語言挑戰：台積電在全球擴廠，會面臨許多不同語言的問題。
• 從外部引入到內部訓練：初期確實有導入外部已訓練好的 Foundation Model 進行測試，但發現不太能滿足內部使用或落地需求。因此，目前已開始慢慢建立自己的資料集，並開始訓練自己的模型。

Q: 在實際情況中，當有新資料持續加入時，通常是定期重新訓練模型還是其他方式？例如影像或感測資料有所不同嗎？

• 嚴謹測試與監控：模型上線前需經過嚴謹測試，上線後會定期監控 (Monitor) 模型的效能 (Performance)。
• 效能下降觸發重訓練：當模型效能下降時，就會進行重新訓練。
• 依據資料更新週期更新：台積電業務繁忙，不斷有新的影像資料（新客戶）進來。會根據題目不同以及資料更新週期，定期更新線上模型。
• 未來方向：未來的努力方向是減少模型訓練的次數或時間，這會呼應到前面提到的 Foundation Model 做法。

Q: 基於 AI 技術更新迭代速度很快，想問台積電會透過哪些管道或流程來獲取新技術的相關資訊以及評估、導入的技術？

• 讀書會：台積電內部的 AI 部門會有讀書會，追蹤最新的技術。
• 應用環境評估：在評估技術時，會考慮其應用環境。例如，若要生成瑕疵資料，所需的精準度可能不需太高，只要與真實影像相似即可。但若生成的資料要給產線或機台使用，則需要很高的精確度。
• 落地考量：評估技術能否使用時，會依據其是否能實際落地並真正供工廠使用。標準會因題目不同而異。

Q: 使用 LLM 讀取表格資訊，如果表格密集會導致幻覺非常嚴重，台積電應該有使用 LLM 做這方面的嘗試，你們根據經驗會建議如何優化，利用 LLM 完成這類 OCR 相關服務？

• 有嘗試過使用 LLM 模型讀取 PDF 檔案。
• 幻覺問題：幻覺問題確實存在，尤其在讀取表格時會有一些困難。
• 優化建議：
  1. OCR 預處理：目前做法是先透過 OCR (光學字元辨識) 將表格資訊讀取出來。
  2. 表格後處理與轉換：接著對讀取出的表格進行相應的處理。讀入的表格格式可能與讀出後的格式不同。
• 這類問題需要投入精力進行處理，以確保準確性。

未列於特定講座標題的 QA 內容：台積電 IT 部門策略與人才發展 (由資訊長 Chris 及 HR 代表 DC、Owen 回答)

Q: 台積電 IT 的分工模式及職位設定有怎樣的分工？針對不同職位是否有特定的面試流程跟評估標準？

• 分工模式：對標業界，內部遵循專業分工，包括 SWE (軟體工程師)、DevOps、SRE (網站可靠性工程師)、Data Engineer (資料工程師)、Infrastructure Engineer (基礎設施工程師)，同時也有 IT 團隊經理及 UX (使用者體驗) 專業人員。
• 面試流程與評估標準：
  • 面試流程主要分為四個階段。
  • 針對不同職位，不會有各自獨立的面試流程，但主管面談部分會依據不同職位的要求與徵才標準，設計不同的考題進行評估。

Q: 台積電的職缺重視哪些核心技能？是否有特定技術認證會有加分效果？履歷及面試、技術測驗中如何有效展現能力並做好準備？

• 核心技能：在徵才說明 (QR code) 中有完整介紹，包括所需技能 (Skill)、程式語言、架構知識等，建議應徵者參考。
• 履歷撰寫建議：
  • 務必清楚描述關鍵字和關鍵技能，說明掌握程度。
  • 詳細描述過往工作經驗中相關且獨特的專案歷練，包括規模大小、最終成果。
  • 資訊越清楚豐富，越有機會被主管透過關鍵字搜尋而脫穎而出。
• 技術測驗：目前使用 HackerRank 平台檢視應徵者的 Coding Skill。
  • 時間與題目：90 分鐘內需解開三道題目。
  • 評估標準：判斷解題正確性與解題能力，了解 Coding 專業程度。
  • 準備建議：若有多年工作經驗且久未刷題寫程式，建議預先準備，這是工程師招募的必備環節。

Q: IT 部門薪資與結構如何？是否有別於其他科技公司 IT 職位的競爭優勢？

• 薪資結構：包含本薪和分紅兩部分。
• 競爭優勢：
  1. 薪資成長性：薪酬與公司每年營收緊密結合。除了每年隨通膨調薪外，若公司營收大幅成長，同仁分紅也會顯著增加。
  2. 薪酬天花板：IT 組織是人才積極單位，有嚴謹分工和明確職涯路徑 (工程師到初階、中階主管)。每次晉升薪酬都會顯著成長，天花板比其他業界公司更高，未來薪酬想像空間大。
  3. 產業穩定性 (Job Security)：台積電有 500 多個客戶，進行專業晶圓代工。不論外部市場和科技巨頭競爭如何，最終都需回歸台積電的技術製造晶片。預期未來 5-10 年營收成長穩健，這不僅代表薪資成長，也代表工作安全性和薪酬隨公司全球版圖持續提升的空間。

Q: IT 工程師在台積電的職涯發展上是否有多元化路徑？例如從工程師轉型到管理職的機會和支持有哪些？

• 答案是肯定的。
• 橫向發展：
  • 多元工作機會：內部有公開的轉職申請平台，同仁看到合適職缺即可應徵，通過面試後可在規定時間內轉調新領域發展。
  • 輪調機會：根據組織需求和同仁能力，主管會安排跨部門輪調，培養多元技能。
• 縱向發展 (工程師轉管理職)：
  • 部門內主管會有相應安排與規劃。
  • 從獨立工作到帶領專案或新人，逐步培養管理能力。
  • 主管會依同仁特質與能力，安排參加公司內部的新主管訓練課程。

Q: 台積電是否針對 IT 部門人才有培育計畫？是否有提升員工技能和職涯發展的機會？

• 公司提供豐富學習資源和管道：除了實體課程，還有許多學習資源。
• 個人推薦：LinkedIn Learning 讓每位員工可申請帳號，內含多元學習主題 (設計、溝通能力、管理技能、語言學習等)，可依需求設計個人發展計畫。
• IT 組織層面：定期檢視組織發展需求，設計相應課程讓同仁學習。
  • AI 相關技能：推行 AI 相關課程，提升同仁 AI 技術能力與工作效率。
  • 溝通能力：設計關鍵溝通 (Critical Communication) 課程，增進 IT 同仁跨團隊溝通協作能力。
• 總結來說，台積電內部有非常多的發展機會與空間，公司提供豐富學習資源，鼓勵同仁依需求安排規劃職涯發展。

Q: ESPP (員工認股計畫) 每個月提撥 20%，公司另外補助 15%，沒有閉鎖期，請問有沒有任何關於年資、職等等等的條件限制？

• 沒有任何限制。
• 只要是台積電的正式員工，就可以加入每月購股計畫，鼓勵每位員工成為公司股東。

Q: 假如要加入 IT，英文是必要的條件嗎？

• 是，加入 IT 組織需要具備一定基礎的英文能力。
• 原因：
  • 自主學習技術：許多 IT 技術需要員工自主學習，而英文是世界的語言，許多教材、資料和課程都是英文撰寫。
  • 全球化互動：台積電是全球性企業，即使在台灣總部工作，也會有越來越多機會與不同國籍員工互動，基礎英文溝通能力有助於工作和人際互動。
• 英文要求不嚴格，但有一定門檻。

Q: 台積電是否有很具體的文化策略來幫助跨部門協作，讓大家來創新？怎麼平衡創意跟工作效率？

• IT 轉型：台積電 IT 幾年前從專案導向的任務型組織轉型為 Product DevOps 組織。
• Product 方面 (促進協作與創新)：Product Manager 直接與 End User 討論、腦力激盪，共同思考如何提升組織效率。這種協作是動態的，會根據需求不斷前進，由大家共同設計。 Product Manager 負責需求分析和 UX 設計，推動創新。
• DevOps Team (平衡效率)：DevOps Team 掌握整個技術堆疊，能自主決定如何使用最佳技術或何時清除技術債、引入新技術，以達到效率最大化。這種平衡由整個團隊成員和資深工程領導者共同決定。
• 創新氛圍：工程師不斷引入新技術並與他人分享，內部有 Podcast、直播，以及完整的 Engineering Discipline Practice，由各單位資深成員分享實踐經驗。

Q: 在跨領域及提升自身技能時，公司如何幫助大家做到？

• 公司提供豐富資源：台積電已提供大量學習資源。
• IT 做法 (依需求設計學習)：
  • 新技術與案例分享：分享新技術和優良案例給內部同仁。
  • Product Training 與 Design Thinking：轉型為 Product DevOps 時，引入 Product Training 和 Design Thinking，讓同仁從「接單」轉變為「設計、思考、提問、找到效益」。
  • Critical Communication：發現同仁需要更好的溝通技巧時，引入 Critical Communication 課程，提升解決衝突的軟技能。
  • AI 技能：鑑於 AI 趨勢，內部 AID (AI Development) 同仁協助設計 AI Hands-on 課程，讓所有 IT 同仁具備使用 AI 及編程 AI 的技能。
• 總之，公司會觀察需求，幫助同仁學習。

Q: 工作期間可以使用 AI 工具協助開發嗎？

• 是，可以。
• 台積電內部還有計畫要將 AI 輔助開發做得比現有外部工具更完整，以提升開發者的生產力。

Q: 台積電是否有針對智慧工廠進行全面數位化的規劃？這對企業未來競爭力的影響是什麼？

• 有規劃，且已在進行中。
• 過去幾年：已涵蓋製造、研發 (R&D)、業務營運等方向。
• 未來幾年：將深入推進，覆蓋更廣泛領域，目標不僅是增加生產力 (Productivity)，還要加速創新週期 (Innovation Cycle)。
• 對競爭力的影響：
  • 創造巨大價值：提升生產力意味著更多產出，可為公司帶來倍增效益，創造巨大價值 (例如增加訂單、提升利潤、有效進行全球擴張)。
  • 核心競爭力：智慧工廠全面數位化與公司的核心競爭力緊密相關。這有助於實現製造的持續改進，不斷提升效能。面對日益艱難的技術挑戰，研發需要更快速度和更多機會，才能應對。
  • 技術領導與卓越製造：數位化有助於達成公司的技術領導地位 (Technology Leadership) 和卓越製造 (Manufacturing Excellence)。

Q: 每個 Site 都會建置 IT 團隊嗎？例如高雄？

• 是。
• IT 部門允許員工在職責範圍內享有 Site Flexibility (地點彈性)。例如，公司在台北設立 IT 辦公室，是為了提供想加入台積電但通勤不便的同仁更多選擇。
• 只要有空間、有機會且職責符合，員工可以在不同地點工作。例如也有 IT 同仁到合資單位 JASM (日本) 工作。

Q: 台積電部門政策是否支持遠端工作或混合工作模式？

• 不支援。
• 台積電是一個非常一致性的公司，IT 部門的政策與公司 HR 政策一致。除了疫情期間有遠端工作外，疫情好轉後，所有員工都在公司內部直接工作，不採混合工作模式。
• 提供彈性：公司在可行範圍內提供不同彈性，例如彈性上下班時間 (如 7:30、8:30、9:30)，讓員工可依生活需求安排。
• 特例處理：若有緊急需求或特殊情況，可與經理透過 HR 進行個案討論與審核。

Q: 在國外投履歷面試會有困難嗎？美國 IT 有職缺嗎？

• 所有職缺都在網上，可自行查詢。
• 投遞後會依標準流程處理，由招聘經理進行面試。

Q: IT 部門會很重視學統嗎？工程師是不是受限於特殊技術或鼓勵內部調轉？

• 不重視學統。
• 面試流程會進行程式設計測試，主要看應徵者的技能水平 (Skill Level) 和專業能力，而非學歷或原公司背景。
• 不限制特定技術，鼓勵內部調轉。
• 工程師的職涯由自己決定，可以依興趣在專業上持續發展。若覺得在某單位發展成熟，可以在適當的時機點轉調到不同單位歷練，不必等待經理安排輪調。這給予很大的彈性。

Q: 治安政策有什麼特點？怎麼應對威脅？

• 傳統策略：台積電一直以來的治安策略是縱深防禦 (Defense in Depth)。即執行正確的基礎措施，如安裝防毒軟體、修補作業系統、設定防火牆、禁用不安全協議、外部存取採用雙因素驗證等。這與其他公司類似，但台積電做得更細緻。
• 新策略 (Secure by Design)：近幾年 IT 部門與資安團隊合作，增加了 Secure by Design (設計安全) 的策略。
  • 這意味著不僅僅是修補或加固現有系統，IT 也可以重新設計整個系統，從源頭上實現安全性。
  • 這種做法不僅提高安全性，也能讓大家發揮創新機會，同時提升生產力 (Productivity)。
• 應對威脅：外部威脅不斷增加且速度越來越快，只能持續改進。透過縱深防禦和設計安全兩種策略的結合，希望能更快、更好地應對挑戰。

Q: 從 Infra 到企業應用到不同 Workflow，目前有計畫改善「珍惜生命，遠離產線 IT」的傳言嗎？

• 講者表示不理解「珍惜生命，遠離產線 IT」這個說法。
• IT 與產線協作：台積電的 IT 部門與產線是站在一起的。IT 人員多數在辦公室寫程式，但也會進入產線觀察實際運作情況。
• 目標：IT 的產品經理會觀察產線人員如何使用 IT 開發的軟體，以提升他們的生產力。
• 這是一個關於認知而非事實的問題，建議更新觀念。

Q: 在 IT 組織內部，如果只想好好做技術職，不擅長帶人，職涯路徑有專門做技術主管 (Technical Lead) 嗎？

• 答案很簡單，是「有」。
• 台積電有雙軌制 (Dual-track system)，希望讓大家做自己喜歡做的事情，並能在職涯上走得更遠。

影片連結

https://www.youtube.com/watch?v=225dpUEyqWg&list=PLT3USJy3vydAu1XUGO5dY30gd2RBw1QgT&index=9