AI 方法論知識地圖 · 部署與維運
部署與服務化
API, Docker, Edge
觀念教學
將訓練好的模型封裝成 API (如 FastAPI/Flask) 或 Docker 容器，部署到雲端或邊緣裝置 (Edge AI)。
TCO（Total Cost of Ownership，總持有成本）
AI 專案不只是「買模型」的錢，TCO 涵蓋整個生命週期的所有成本：
直接成本
- 硬體/雲端算力（GPU、儲存、網路）
- 軟體授權（模型 API、平台費用）
- 資料取得與標註成本
隱藏成本（常被低估）
- 系統整合：串接現有系統的開發工時
- 人力：ML 工程師、資料工程師、維運人員
- 訓練：員工教育訓練、流程改造
- 維運：模型監控、重訓練、版本管理
- 治理：合規審查、偏見檢測、稽核
- 升級：模型迭代、架構更新
TCO vs ROI
- TCO = 花了多少（總成本）
- ROI = 賺回多少（投資報酬率）= (收益 - TCO) / TCO
- 考試重點：ROI 高不代表 TCO 低，要兩個一起看才完整
比喻：買車不只看車價（直接成本），還要算油錢、保險、維修、停車費（隱藏成本），全部加起來才是 TCO。
應用場景
評估指標
iPAS 歷屆考題詳解(28 題)
先自行作答,再展開詳解。題目出處均為 iPAS AI 應用規劃師正式考題,著作權屬原主辦單位。
某雲端服務公司計畫將大型語言模型部署於線上系統，並以批次推論（Batch Inference）方式處理每日上百萬筆用戶請求。專案團隊在評估可能遇到的挑戰時，下列哪一項通常不會被視為批次推論階段的主要難題？
- A如何確保訓練語料的涵蓋性與標註品質，以避免模型偏差影響輸出
- B當批次規模增大時，如何降低推論延遲並保持即時回應能力
- C在推論過程中，有效管理與分配龐大的輸入資料量以避免資源壅塞
- D在叢集環境中精確安排推論任務，以提升 GPU/TPU 等硬體資源的利用率
看正解與逐選項詳解
正解:A
正確答案:(A)
【正解解析】
批次推論(Batch Inference)是將已訓練完成的模型部署後,對大量累積的請求進行批量預測的階段,挑戰集中在系統與資源層面:延遲控制、資料量管理、硬體資源調度。選項 (A) 所述的訓練語料涵蓋性與標註品質,屬於模型「訓練階段」的資料準備工作;進入推論階段時模型參數已固定,語料品質造成的偏差在訓練時即已決定,無法於推論階段處理,因此通常不會被視為批次推論階段的主要難題。
【為何其他選項錯了?】
- (B):每日上百萬筆請求下,批次規模增大會拉長整體處理時間;如何控制推論延遲、維持回應能力,是批次推論的典型效能挑戰。
- (C):大量輸入資料若缺乏有效的管理與分配機制,容易造成 I/O 與運算資源壅塞,影響整體處理穩定性,屬於批次推論必須處理的資料工程問題。
- (D):在叢集環境中安排推論任務排程,以提升 GPU、TPU 等高成本硬體的利用率,是批次推論在成本與效能上的核心議題。
提示:區分生命週期階段:語料品質與標註屬訓練階段議題;延遲、資料管理、資源排程才是推論階段的難題。
某智慧城市專案導入 AI技術,以優化垃圾收集路線調度並即時監測空氣品質變 化。系統需持續蒐集環境數據(如 PM2.5、氣體濃度)與設備狀態(如垃圾桶滿 溢度)。下列何種技術最直接支援上述需求?
- A專家系統(Expert System)
- B決策支援系統(Decision Support System)
- C啟發式決策引擎(Heuristic Decision Engine)
- D感知器網路(Sensor Network)
看正解與逐選項詳解
正解:D
正確答案:(D)
【正解解析】
題幹關鍵在「持續蒐集環境數據(PM2.5、氣體濃度)與設備狀態(垃圾桶滿溢度)」,這是對實體世界進行感測與資料蒐集的需求。感知器網路(Sensor Network)由大量感測器節點組成,負責即時偵測並回傳環境與設備的狀態資料,是最直接支援此需求的技術。
【名詞白話語典】
- 感知器網路(Sensor Network):由許多感測器節點構成的網路,負責從實體世界偵測與蒐集溫度、濕度、光線、壓力等各類資訊,是物聯網架構中的資料來源層。
【為何其他選項錯了?】
- (A):專家系統模擬人類專家的知識與規則進行推論判斷,重點在「決策」,本身不具備蒐集實體環境資料的能力。
- (B):決策支援系統是輔助管理者進行決策的分析工具,它處理與分析既有資料,但不負責從現場蒐集資料。
- (C):啟發式決策引擎以經驗法則進行快速決策,同樣屬於決策層技術,與資料蒐集無關。
提示:題幹問的是「蒐集資料」的技術;專家系統、決策支援系統、啟發式引擎皆屬決策層,只有感知器網路屬感測層。
在AI 推論服務架構設計中,「批次推論(Batch Inference)」與「即時推論(Real- time Inference)」常依任務特性選擇不同機制。下列關於兩者特性的敘述何者最正 確?
- A批次推論通常以同步請求方式回傳結果,以確保資料一致性;即時推論則多採 非同步機制以提升系統吞吐量(Throughput)
- B批次推論多用於延遲容忍度較高的大規模資料處理,通常以吞吐量 (Throughput)最佳化為優先;即時推論則著重於請求回應時間的穩定性與低延遲 特性
- C批次推論因計算資源需求高,僅適用於影像類模型;即時推論則主要應用於結 構化資料模型
- D即時推論為確保回應速度,通常限制為單筆資料輸入;批次推論則可支援同步 多筆資料即時回傳
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
兩種推論機制的核心差異在最佳化目標。批次推論(Batch Inference)將大量資料累積後一次性處理,不追求即時回應,以單位時間處理總量(吞吐量, Throughput)最佳化為優先,成本效率高,適用於報表生成、離線資料分析等延遲容忍度高的任務。即時推論(Real-time Inference)針對單一請求立即回應,追求低延遲與回應時間的穩定性,適用於人臉辨識、即時推薦、線上客服等需要立即反應的場景。選項 (B) 正確描述「批次重吞吐量、即時重低延遲」的核心權衡。
【為何其他選項錯了?】
- (A):敘述正好相反。批次推論通常採非同步機制,任務提交後於完成時回傳結果;即時推論則以同步請求為主,發出請求後等待即時回應。
- (C):兩種推論方式皆適用於各類資料型態與模型,並無「批次限影像、即時限結構化資料」的限制。
- (D):即時推論可透過小批次(mini-batch)方式處理多筆資料以提升效率,不限於單筆輸入;批次推論的結果通常為非同步回傳,並非「即時回傳」。
提示:批次推論=延遲容忍、吞吐量優先;即時推論=低延遲、回應穩定;同步/非同步與資料類型限制的敘述多為陷阱。
在大型語言模型(LLM)的推論服務中,常透過請求批次處理(Batching)來提升 系統效能。關於批次處理(Batching)機制的影響,下列敘述何者最正確?
- ABatching 可提升加速器資源使用效率並增加整體吞吐量(Throughput),但在部 分情境下可能對單筆請求延遲造成影響
- BBatching 主要用於加快單筆請求回應時間
- CBatching 的效益主要來自降低記憶體使用量,對於吞吐量(Throughput)與延 遲表現影響有限
- DBatching 在低併發(Concurrency)請求下,仍能顯著提升系統效能
看正解與逐選項詳解
正解:A
正確答案:(A)
【正解解析】
批次處理(Batching)將多筆請求合併後一次送入 GPU 等加速器運算。加速器具備大規模平行運算能力,處理一筆與處理數十筆請求的時間差距有限,合併處理能大幅提升硬體使用效率,使單位時間可完成的請求總數(吞吐量)顯著增加。代價是個別請求可能需要等待批次湊齊或等到固定的觸發時點才開始運算,因此在部分情境下單筆請求的延遲會上升。選項 (A) 同時陳述效益與代價,最為正確。
【名詞白話語典】
- 吞吐量(Throughput):單位時間內系統能處理的總工作量,數值越高代表系統整體處理效率越好。
- 延遲(Latency):從發出請求到收到回應所花費的時間,數值越低代表反應越快。
【為何其他選項錯了?】
- (B):Batching 的目的為提升整體吞吐量;單筆請求因等待批次成形反而可能延遲增加,並非加快單筆回應。
- (C):Batching 的效益來自提升運算效率進而提升吞吐量;更大的批次尺寸實際上需要更多記憶體,「降低記憶體使用量」的敘述錯誤。
- (D):低併發時請求量不足,為湊齊批次而等待會顯著增加延遲,效益不佳;Batching 在高併發情境下效益最高。
提示:Batching 的本質是以單筆等待時間換取整體吞吐量;低併發時效益差,批次越大記憶體需求越高。
某保險公司每月處理約50 萬筆理賠申請,希望建立 AI 系統自動識別可疑的詐欺 案件。由於公司內部缺乏 AI 專業人員,且需要快速上線驗證效果,IT 資訊主管正 在評估不同的 AI平台解決方案。在去識別化個人隱私資料後,下列哪一種平台類 型最適合該公司的需求?
- A從零開始建立深度學習框架並自行訓練模型
- B採用開源機器學習框架進行客製化模型開發
- C使用雲端 AutoML 平台進行自動化模型訓練
- D購買現成的詐欺偵測軟體套件直接部署
看正解與逐選項詳解
正解:C
正確答案:(C)
【正解解析】
題幹的關鍵條件有二:內部缺乏 AI 專業人員、需要快速上線驗證效果。雲端 AutoML(自動化機器學習)平台正是針對此情境設計:使用者備妥資料後,平台自動執行模型選擇、超參數調校與效能評估,大幅降低機器學習的技術門檻並縮短開發時程;且模型以公司自身的理賠資料訓練,能貼合實際業務樣態,適合快速驗證詐欺偵測的可行性。
【為何其他選項錯了?】
- (A):從零建立深度學習框架並自行訓練,所需的專業能力與開發時程最高,與「缺乏 AI 人員、快速上線」兩項條件完全相悖。
- (B):採用開源框架進行客製化開發,仍需具備完整的機器學習工程能力,不符合公司現有人力條件。
- (D):現成套件雖可快速部署,但功能與模型固定,未必符合該公司特定的業務規則與資料樣態;AutoML 以自有資料訓練,客製化程度更高,更符合「驗證效果」的目標。
提示:「缺乏 AI 人才+快速驗證」即對應 AutoML;自建與開源客製門檻高,現成套件難貼合自有資料。
某紡織製造公司導入AI系統進行布料瑕疵檢測,每天需處理來自30條產線的影像資料,包括高解析度照片、感測器數值、生產參數記錄等多種格式。該公司收集的資料量從每日 2GB 增長至50GB,且需在布料離開產線前的3秒內完成瑕疵判定。近期團隊發現系統在尖峰時段容易出現判定延遲,影響製程節奏。若要優先改善此問題,下列哪一種做法最適合?
- A擴充資料儲存容量,以因應長期資料累積需求
- B強化即時資料處理與推論計算資源配置,以降低延遲風險
- C調整資料格式標準,以降低跨來源整合複雜度
- D增加資料驗證與清理機制,以提升資料品質穩定性
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
題幹的核心問題是「判定延遲」:系統需在布料離開產線前 3 秒內完成瑕疵判定,但尖峰時段處理速度不足,直接指向即時處理與推論運算能力的瓶頸。在資料量由每日 2GB 成長至 50GB 且有嚴格時限的條件下,最直接有效的改善方向是強化即時資料處理與推論計算資源,例如升級推論硬體、優化推論服務配置、增加服務實例分攤負載,以提升即時處理能力、降低延遲風險。
【為何其他選項錯了?】
- (A):擴充儲存容量解決的是「資料存放不足」的問題,與尖峰時段的運算延遲無直接關聯。
- (C):統一資料格式有助於降低跨來源整合的複雜度,但對計算量造成的推論延遲改善有限,非當前優先事項。
- (D):資料驗證與清理能提升資料品質,但會增加處理步驟與時間,對延遲問題不僅無益,反而可能加劇。
提示:題幹指向「處理太慢」就補運算與即時處理能力;儲存解決存放問題、格式統一解決整合問題、清理解決品質問題,皆非對症。
某企業規劃透過Low-Code 平台建置可視化儀表板,以支援營運數據的即時監控與分析判讀。若企業特別關注儀表板顯示結果的穩定性與分析可信度,下列何者最應優先確認?
- A是否具備穩定的資料串接能力與即時更新機制
- B是否提供自動化決策建議與預測分析模組
- C是否支援彈性介面設計與多角色權限管理
- D是否整合流程觸發與跨系統通知功能
看正解與逐選項詳解
正解:A
正確答案:(A)
【正解解析】
可視化儀表板的價值建立在資料的正確與即時之上。若資料來源串接不穩定或更新不及時,儀表板呈現的所有圖表與指標都會失真,即時監控與分析判讀便失去依據。題幹強調「顯示結果的穩定性與分析可信度」,對應的正是底層資料管線(Data Pipeline)的品質:穩定的資料串接能力與即時更新機制是其他一切功能的前提,應最優先確認。
【為何其他選項錯了?】
- (B):自動化決策建議與預測分析屬加值功能;若基礎資料有誤,產出的建議同樣不可信,並非優先事項。
- (C):彈性介面與權限管理攸關使用體驗與存取安全,與資料本身的穩定性、可信度沒有直接關係。
- (D):流程觸發與跨系統通知是儀表板的延伸應用,其正確性同樣以資料正確為前提。
提示:題幹問「穩定性與可信度」即指向資料層;介面、權限、通知、預測模組皆屬資料正確之後的加值項目。
某企業導入生成式 AI 客服系統後發現,系統整體運作穩定,且在單位時間內可處理大量對話請求。部分使用者仍反映在互動過程中回覆出現卡頓感,經初步排除網路連線與前端介面效能問題後,若專案團隊希望針對此現象進行效能測試,下列何者最符合測試重點?
- A評估系統長時間運作的穩定程度
- B測量系統單位時間的總處理量
- C比較不同回覆內容的語言品質
- D分析單次互動回覆的反應速度表現
看正解與逐選項詳解
正解:D
正確答案:(D)
【正解解析】
使用者反映的「卡頓感」對應的效能指標是延遲(Latency),即從發出訊息到收到回覆所需的時間。題幹已說明系統整體運作穩定(排除長時間穩定度問題)、單位時間可處理大量請求(排除吞吐量問題),並已排除網路與前端因素,因此效能測試的重點應聚焦於「單次互動回覆的反應速度」,量測並分析單一請求的延遲表現,找出回應時間過長的環節。
【名詞白話語典】
- 總處理量(Throughput):衡量系統的承載能力,例如每秒可處理的請求數量。
- 反應速度/延遲(Latency):衡量系統處理單一請求的速度,即從請求送出到回應完成所需的時間。
【為何其他選項錯了?】
- (A):長時間運作穩定度屬穩定性測試;題幹已述系統整體運作穩定,非本次問題所在。
- (B):單位時間總處理量屬吞吐量測試;題幹已述系統可處理大量請求,與使用者反映的卡頓無關。
- (C):語言品質評估的是回覆內容的正確與流暢,屬品質面向,與回應速度無關。
提示:「卡頓感」對應延遲測試;吞吐量看承載、穩定性看長期運作、語言品質看內容,皆與單次反應速度不同。
某製造企業規劃於設備端建置邊緣運算(Edge Computing)架構,並以 No-Code/Low-Code 平台開發即時監控應用。測試顯示,系統在雲端環境執行順暢,但在部署至邊緣裝置後出現回應延遲與效能下降。依此情境判斷,下列何者最合理解釋該現象?
- A邊緣運算架構可降低系統對效能的需求
- BNo-Code/Low-Code 平台僅能在雲端環境執行
- C雲端部署通常比邊緣部署更容易出現延遲
- D邊緣裝置通常受限於運算能力與可用資源
看正解與逐選項詳解
正解:D
正確答案:(D)
【正解解析】
雲端環境具備充足的運算資源與彈性擴充能力;邊緣裝置(Edge Device)如感測器、攝影機、工業電腦等,受限於體積、功耗與成本,其處理器、記憶體與加速資源遠低於雲端伺服器。同一應用在雲端執行順暢,部署至邊緣裝置後出現回應延遲與效能下降,最合理的解釋即是邊緣裝置的運算能力與可用資源受限,形成效能瓶頸。
【名詞白話語典】
- 邊緣運算(Edge Computing):將運算移至靠近資料來源的裝置端執行,以降低網路傳輸延遲與頻寬壓力的架構。
【為何其他選項錯了?】
- (A):邊緣運算改變的是運算發生的位置,不會降低應用程式本身對效能的需求;此敘述因果顛倒。
- (B):多數 No-Code/Low-Code 平台支援將應用打包部署至邊緣裝置;且題幹中應用已在邊緣裝置上執行,僅效能下降,「僅能在雲端執行」的敘述與事實不符。
- (C):雲端部署的延遲主要來自網路傳輸;就運算效能而言雲端遠強於邊緣,若瓶頸在運算,雲端反而較快,此敘述無法解釋題幹現象。
提示:「雲端順暢、邊緣變慢」優先考量裝置資源受限;邊緣運算降低的是傳輸延遲,不是運算需求。
某零售企業規劃提升門市數據應用能力,目標包括:門市主管可自行調整分析畫面與檢視指標呈現,以及由行銷部門建立銷售預測模型,以支援補貨與促銷規劃。企業在選型時以工具的主要功能定位與典型用途作為評估依據。依此需求判斷,下列哪一項 AI 工具使用規劃最合理?
- A以 AutoML 作為分析介面調整平台,No-Code 平台用於模型訓練
- B以 No-Code 平台支援分析與介面調整,AutoML 負責模型建立
- C僅導入 No-Code平台,同時滿足高階模型建立與分析需求
- D僅導入 AutoML,以兼顧介面調整與模型訓練
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
本題考兩類工具的功能定位。No-Code 平台的強項是視覺化介面搭建與分析畫面調整,讓非工程背景的門市主管能自行設定儀表板與檢視指標呈現;AutoML 平台的強項是自動化模型建立,協助缺乏資料科學專業的行銷部門完成銷售預測模型的訓練與調校。依「主要功能定位與典型用途」評估,由 No-Code 平台支援分析與介面調整、AutoML 負責模型建立,是各司其職的合理規劃。
【為何其他選項錯了?】
- (A):角色配置顛倒。AutoML 的定位不在分析介面調整,No-Code 平台也不以模型訓練見長。
- (C):No-Code 平台的模型建立能力有限,難以滿足銷售預測模型的建置需求,單一工具無法同時涵蓋兩類任務。
- (D):AutoML 專注於模型自動化訓練,介面調整與指標呈現的彈性不足,無法滿足門市主管自助分析的需求。
提示:對應典型用途:介面與自助分析找 No-Code,模型自動訓練找 AutoML;宣稱單一工具包辦兩者的選項多為陷阱。
某企業提供大型語言模型(LLM)API 服務,需支援高併發請求與流量波動,同時要求服務不中斷並具備故障容忍能力。若以高可用性與可擴展性為主要設計原則,下列哪一種部署方式較為適當?
- A採用單一高效能虛擬機(VM)集中部署,以提升資源使用效率
- B建立多個模型服務實例並透過負載分散機制提供服務
- C將推論任務改由用戶端設備分擔,以降低伺服器負載壓力
- D使用 FTP 協議傳輸請求與回應,以減少服務通訊負擔
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
題幹要求高併發、流量波動、服務不中斷與故障容忍,對應的設計原則是高可用性(High Availability)與可擴展性(Scalability)。標準作法是建立多個模型服務實例(Replicas)分散部署,前端以負載平衡器(Load Balancer)將請求分配至各實例:單一實例故障時其餘實例仍可提供服務,確保高可用;流量成長時增加實例數量即可水平擴展(Horizontal Scaling),因應流量波動。
【為何其他選項錯了?】
- (A):單一虛擬機無論規格多高都是單點故障(Single Point of Failure),一旦故障服務即中斷;且垂直擴展有硬體上限,無法因應高併發與流量波動。
- (C):大型語言模型推論需要大量運算資源,一般用戶端設備難以負擔;將推論移至用戶端亦衍生模型資產外洩與版本管理問題,不符合服務架構需求。
- (D):FTP 為檔案傳輸協定,並非為高併發 API 請求設計,無法支撐即時推論服務的通訊需求。
提示:「高可用+可擴展」的標準組合:多實例+負載平衡+水平擴展;單機再強仍是單點故障。
某大型製造工廠導入生成式 AI 系統來優化能源消耗,每日需處理約 10 萬筆設備數據並生成能源優化建議。系統每月 API 調用成本約 15 萬元,內部維護人力成本8萬元,基礎設施成本5萬元。該工廠評估導入效益時,下列哪一項總體擁有成本(Total Cost of Ownership, TCO)分析最完整?
- A主要以 API 調用成本15 萬元作為 TCO 評估基礎
- B以 API 調用成本15 萬元及維護人力成本8萬元進行整體估算
- C綜合 API 調用、維護人力與基礎設施等直接成本進行評估,共約28 萬元
- D除直接成本外,並考量訓練、系統整合與資安合規等相關支出
看正解與逐選項詳解
正解:D
正確答案:(D)
【正解解析】
總體擁有成本(Total Cost of Ownership, TCO)要求納入系統整個生命週期的所有相關成本,而非僅計算帳面上的營運費用。題幹列出的 API 調用(15 萬元)、維護人力(8 萬元)、基礎設施(5 萬元)屬於直接成本,合計 28 萬元;完整的 TCO 分析還須納入間接成本,例如員工訓練、系統整合、資安與法規遵循等相關支出,以及後續升級與遷移成本。選項 (D) 同時涵蓋直接成本與間接成本,是最完整的評估。
【為何其他選項錯了?】
- (A):僅以 API 調用成本評估,連直接成本都未列齊,是最不完整的估算。
- (B):納入 API 與人力成本,仍遺漏基礎設施成本與所有間接成本。
- (C):28 萬元僅涵蓋全部「直接成本」,未計入訓練、系統整合、資安合規等間接支出,仍非完整的 TCO。
提示:TCO=直接成本+間接成本(訓練、整合、合規、升級);只加總帳面費用的選項都不完整。
某機構計畫導入生成式 AI 旅遊資訊服務對話系統自動生成多語言對話。目前每月需人工翻譯 600 則訊息,每則成本50元;若改用 ChatGPTAPI,每則訊息需 2000 Tokens,而 Token 成本0.8元/1000 Tokens,但需額外投入系統整合費用20萬元。關於投資報酬率(Return on Investment, ROI) 評估,下列何者最為正確?
- A每月節省成本29,040元,系統整合成本約7個月回收
- B每月節省成本30,000元,系統整合成本約7個月回收
- C每月節省成本28,040元,系統整合成本約8個月回收
- D每月節省成本 25,000 元,系統整合成本約8個月回收
看正解與逐選項詳解
正解:A
正確答案:(A)
【正解解析】
依題目條件逐步計算。原人工翻譯成本:600 則 × 50 元 = 每月 30,000 元。改用 API 後,每則成本為 2000 Tokens ÷ 1000 × 0.8 元 = 1.6 元,每月 AI 成本為 600 則 × 1.6 元 = 960 元。每月節省金額為 30,000 - 960 = 29,040 元。系統整合費用 200,000 元,回收期為 200,000 ÷ 29,040,約 6.9 個月,即約 7 個月可回收。選項 (A) 的節省金額與回收期皆與計算相符。
【為何其他選項錯了?】
- (B):30,000 元是原人工成本總額,未扣除改用 API 後仍須支付的每月 960 元,節省金額計算錯誤。
- (C):28,040 元與正確算式(30,000 - 960 = 29,040)不符;以正確節省金額計算,回收期約 6.9 個月,亦非 8 個月。
- (D):25,000 元無對應的計算依據;回收期 8 個月同樣與正確結果不符。
提示:ROI 計算題先算「新舊方案每月成本差」,再算「一次性投資 ÷ 每月節省」;常見陷阱是忘記扣除新方案本身的營運成本。
某紡織公司希望建立自動化品質檢測流程,既有的 AI 系統檢測到布料瑕疵時,需自動拍照存檔、發送通知給品管人員。該公司具有一定開發人力,希望快速建置此工作流程,並保有彈性調整空間,下列哪一種解決方案最適合?
- A使用 n8n建立工作流(Workflow),整合 AI 檢測 API、檔案系統、通訊軟體
- B委外開發客製化程式,完全符合公司需求規格
- C採購現成的品質管理軟體,直接導入使用
- D使用 Excel 巨集搭配人工作業處理檢測結果
看正解與逐選項詳解
正解:A
正確答案:(A)
【正解解析】
需求關鍵字:自動化工作流程、整合多個系統(AI 檢測 API、檔案存檔、通訊軟體通知)、快速建置、保有彈性,且公司具一定開發人力。n8n 這類工作流程自動化平台提供視覺化流程編輯,以節點串接各系統的 API,可快速組裝「檢測到瑕疵即拍照存檔並發送通知」的自動化流程;各節點與流程可隨需求調整,兼顧建置速度與修改彈性,與題幹條件完全對應。
【為何其他選項錯了?】
- (B):委外開發客製化程式雖可完全符合規格,但成本高、開發週期長,不符合「快速建置」的需求,後續調整也受限於委外廠商。
- (C):現成品質管理軟體功能固定,未必能與公司「既有的 AI 檢測系統」整合,缺乏流程調整彈性。
- (D):Excel 巨集搭配人工作業難以實現穩定的跨系統自動化整合,無法滿足自動存檔與即時通知的需求。
提示:「快速建置+跨系統整合+保有彈性」對應工作流程自動化平台;委外開發速度慢、現成套件彈性低、巨集難以跨系統整合。
某農業合作社希望建立一套自動化工作流程,當農民透過手機 APP 回報田間病蟲害照片時,系統能自動通知相關專家、建立案件紀錄並排程現場訪查。該合作社IT 資訊人力有限,僅有一位具備基礎程式概念的人員。下列哪一種開發方式最適合此需求?
- A採用傳統程式開發,從零開始撰寫完整系統
- B使用純粹的No-Code平台,完全不需要任何程式技能
- C使用 Low-Code平台,結合視覺化拖拉與少量程式碼
- D直接購買現成的農業管理軟體,不進行客製化
看正解與逐選項詳解
正解:C
正確答案:(C)
【正解解析】
情境條件:IT 人力有限,但有一位具備基礎程式概念的人員,需求為跨系統的自動化工作流程(APP 回報、通知專家、建立案件紀錄、排程訪查)。Low-Code 平台以視覺化拖拉元件快速完成大部分功能,遇到需要客製邏輯或串接特殊服務時,再以少量程式碼擴充,恰好對應「人力有限但具基礎程式能力」的條件,兼顧開發速度與必要彈性。
【為何其他選項錯了?】
- (A):傳統程式開發從零撰寫完整系統,開發與維護負擔遠超過僅一名技術人員的量能,亦不符合快速建置的期待。
- (B):純 No-Code 平台在客製化邏輯與特殊系統整合上彈性不足,且未善用既有的基礎程式能力,可能無法完整滿足流程需求。
- (D):現成農業管理軟體不進行客製化,難以貼合合作社「回報、通知、建案、排程」的特定流程。
提示:「人力有限+具基礎程式概念」是 Low-Code 的典型適用條件;完全無程式能力才傾向 No-Code,人力充足才考慮自行開發。
隨著企業加速導入 AI,No-Code/Low-Code 平台逐漸成為模型開發與產品化的常見工具。相較於傳統自行撰寫程式的建模流程,下列何者最能正確描述此類平台在模型訓練機制上的典型特性?
- A透過視覺化介面與標準化流程,協助完成模型訓練與調校
- B主要提供既有模型推論能力,通常不支援重新訓練
- C著重資料處理與轉換,模型訓練仍需外部工具完成
- D多數僅適用於特定大數據框架(如 Spark)的訓練流程
看正解與逐選項詳解
正解:A
正確答案:(A)
【正解解析】
No-Code/Low-Code AI 平台的核心價值,在於將機器學習流程圖形化與標準化:以視覺化介面串接資料讀取、特徵處理、模型選擇與訓練等步驟,平台內建標準化流程引導操作,並常整合 AutoML 功能自動搜尋模型與超參數,協助使用者完成模型訓練與調校。相較於傳統手寫程式的建模流程,此類平台以「視覺化+標準化」降低技術門檻,使非 AI 專業背景人員也能參與模型開發。選項 (A) 最符合其典型特性。
【為何其他選項錯了?】
- (B):多數平台支援使用者以自有資料重新訓練模型,並非僅提供既有模型的推論能力。
- (C):此類平台通常將資料處理、模型訓練與部署整合於同一環境,模型訓練不需依賴外部工具完成。
- (D):平台普遍支援多種資料來源與運算框架,並未侷限於特定大數據框架。
提示:No-Code/Low-Code 建模的關鍵字是「視覺化介面+標準化流程」;「不支援訓練」「僅限特定框架」等絕對化敘述多為誘答。
某醫療院所希望改善行政效率,規劃讓各科室人員可自行建立行政回報與內部申請表單,並導入 AI 功能以自動判讀與分類填寫內容(如問題類型或需求性質),同時需兼顧流程調整彈性與降低系統開發維運負擔。下列哪一種技術組合最適合?
- ALow-Code 平台 × 預訓練語言模型 API
- BNo-Code 平台 × 規則式自動化(Rule-based Automation)
- C傳統程式開發 × 自建深度學習模型
- D試算表工具 × 手動資料標記分析
看正解與逐選項詳解
正解:A
正確答案:(A)
【正解解析】
需求可拆解為三項:各科室人員自行建立表單與流程(需低門檻開發工具)、AI 自動判讀與分類填寫內容(需自然語言理解能力)、兼顧流程調整彈性與降低開發維運負擔。Low-Code 平台可快速搭建表單與流程並保留客製彈性;判讀與分類用語多變的自由文字,直接串接成熟的預訓練語言模型 API 是最快速且維運負擔最低的作法,不需自行訓練與維護模型。兩者組合可同時滿足全部條件。
【為何其他選項錯了?】
- (B):規則式自動化依賴預先定義的條件,面對語意多變的填寫內容,判讀與分類的涵蓋率與準確度不足。
- (C):傳統程式開發加自建深度學習模型,開發成本與維運負擔最高,與「降低系統開發維運負擔」的目標相悖。
- (D):試算表搭配手動標記缺乏自動化能力,無法達成自動判讀分類,亦無法改善行政效率。
提示:「自建表單+語意判讀+低維運」的組合:開發面選 Low-Code,語意面選預訓練模型 API;規則式自動化難以處理自然語言。
某企業規劃導入生成式 AI 助理,在正式全面部署前進行概念驗證(PoC),下列何者最不適合作為此階段的主要工作?
- A驗證模型在實際使用情境下的回覆品質與穩定性
- B測試 AI 功能與業務需求的匹配程度
- C制定跨部門使用規範,與長期治理框架
- D評估系統整合可行性與技術限制
看正解與逐選項詳解
正解:C
正確答案:(C)
【正解解析】
概念驗證(Proof of Concept, PoC)的目的是在投入大量資源前,以小規模實驗確認技術與需求的可行性,重點包括:模型在實際情境的回覆品質與穩定性、AI 功能與業務需求的匹配程度、系統整合的可行性與技術限制。「制定跨部門使用規範與長期治理框架」屬於 PoC 驗證成功、確定全面導入之後的治理階段工作;在 PoC 階段投入大量資源制定長期規範,不符合快速驗證的目的,故為最不適合的主要工作。
【為何其他選項錯了?】
- (A):驗證實際使用情境下的回覆品質與穩定性,正是 PoC 檢驗技術可行性的核心工作。
- (B):測試 AI 功能與業務需求的匹配程度,是 PoC 判斷方案是否值得投入的關鍵依據。
- (D):評估系統整合可行性與技術限制,可及早發現導入障礙,屬 PoC 階段的必要工作。
提示:PoC 驗證可行性;使用規範與長期治理框架屬全面導入階段的工作,階段錯置者即為答案。
某金融服務公司規劃導入生成式 AI,在評估模型部署方式時,基於內部控制與治理要求,企業考慮將大型語言模型建置於公司可管理環境,而非直接採用外部雲端服務。下列何者最能合理說明此部署決策的潛在優勢?
- A有助提升模型回覆穩定性並降低隨機性影響
- B可降低敏感資料需傳輸至外部服務的風險
- C可直接減少模型訓練與維運所需資源投入
- D可避免模型輸出偏差與幻覺(Hallucination)問題
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
將大型語言模型建置於公司可管理環境(私有化部署,如地端或私有雲),相較於直接採用外部雲端服務,最直接的優勢在資料安全:使用者輸入的敏感查詢與內部文件皆在企業自有環境內處理,不需傳輸至第三方服務,大幅降低敏感資料外流、被不當儲存或利用的風險。對受高度監理、重視資料主權的金融業而言,這正是「基於內部控制與治理要求」選擇自建環境的核心理由。
【為何其他選項錯了?】
- (A):回覆穩定性與隨機性取決於模型本身、解碼參數(如溫度)與提示設計,與部署位置無關。
- (C):私有化部署須自行承擔硬體、人力與維運成本,資源投入通常增加而非減少。
- (D):輸出偏差與幻覺(Hallucination)是模型本身的特性,改變部署位置無法解決;降低幻覺須仰賴檢索增強生成(RAG)等技術手段。
提示:私有化部署的核心優勢是「敏感資料不出企業環境」;穩定性、成本、幻覺皆不因部署位置改變而自動改善。
某金融監理機構規劃導入生成式 AI 以協助內部人員分析申報文件與監理報告,系統需處理大量涉及企業敏感資料與未公開資訊。主管機關明確要求「資料安全與法規遵循必須優先於導入速度與成本考量」。在此條件下,下列哪一種策略最為適當?
- A採用雲端大型語言模型 API,並透過資料遮罩與加密機制降低外洩風險
- B導入開源模型進行私有化部署,以兼顧成本彈性與模型可控性
- C自行訓練並私有化部署模型,同時建立存取控管與稽核機制
- D先驗證模型效益,再逐步補強合規與資安架構
看正解與逐選項詳解
正解:C
正確答案:(C)
【正解解析】
題幹的最高原則是「資料安全與法規遵循優先於導入速度與成本」。在此前提下,自行訓練並私有化部署模型,可確保資料與模型全程留在機構可控環境,訓練資料來源可控且合規;再配合存取控管與稽核機制,滿足監理機關對權限管理與可追溯性的要求,構成安全等級最高、配套最完整的方案,符合「安全優先、不計速度與成本」的條件。
【為何其他選項錯了?】
- (A):採用雲端 API 意味敏感資料仍需傳輸至外部服務,遮罩與加密只能降低而無法消除外洩風險,與「安全優先」的前提不符。
- (B):開源模型雖可私有化部署,但其訓練資料來源與授權狀態不易查核,潛藏偏誤與法律風險;該選項亦未包含存取控管與稽核配套,完整性不及 (C)。
- (D):先驗證效益、後補合規,順序與題幹要求相反,屬高風險做法。
提示:題幹給定「安全與合規壓倒一切」時,選控制程度最高、配套最完整的方案;「資料送外部」或「先做再補」的選項都不符前提。
某製造企業規劃導入生成式AI 協助產線異常紀錄分析,系統將根據設備回報與維修紀錄自動產出問題摘要與建議處置說明。在試行測試階段,為降低營運與決策風險,下列何者最應優先驗證?
- AAI 生成建議與實際工程判斷的一致性與正確性
- B系統在高資料量輸入下的處理速度與延遲表現
- C模型對不同設備品牌資料格式的轉換能力
- D異常分析報告的視覺化呈現與介面易讀性
看正解與逐選項詳解
正解:A
正確答案:(A)
【正解解析】
系統產出的是問題摘要與「建議處置說明」,屬於輔助決策的內容。若建議錯誤而被現場人員採納,可能導致錯誤維修、產線停擺甚至工安風險,這正是題幹所稱營運與決策風險的直接來源。因此試行階段最應優先驗證 AI 生成建議與實際工程判斷的一致性與正確性,確認輸出內容可靠之後,其他面向的優化才有意義。
【為何其他選項錯了?】
- (B):處理速度與延遲屬效能議題;內容正確性未確立前,回應再快也無法降低決策風險。
- (C):資料格式轉換屬資料前處理的技術細節,影響的是涵蓋範圍與便利性,非決策風險的核心。
- (D):視覺化與易讀性屬使用體驗;呈現得再清楚,內容錯誤仍會誤導決策。
提示:輔助決策類 AI 的驗證順位:先驗證內容正確性(與專家判斷比對),再談效能、格式與介面。
某企業使用 Low-Code平台建置內部營運系統,系統需整合財務、庫存與第三方物流服務。團隊希望確保系統在跨部門流程與外部服務整合下,具高可靠性與可測試性。下列哪一項作法最能達成目標?
- A只透過平台提供的流程模擬與即時預覽,檢查常用操作路徑
- B建立自動化測試流程,結合模擬外部服務與可重複執行的整合測試
- C將測試重點放在使用者介面操作,確認操作流程是否順暢
- D上線後再透過使用者回饋與報表監控系統行為,進行修正
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
系統需整合財務、庫存與第三方物流等多個內外部服務,要達成高可靠性與可測試性,標準作法是建立自動化測試流程:將測試案例腳本化,每次變更後可重複執行回歸測試,避免修改引發連鎖錯誤;並以模擬(Mock)方式替代外部服務,使測試不依賴第三方系統的可用性與費用,能穩定、可重複地驗證整合邏輯與異常處理。此作法同時涵蓋可靠性與可測試性兩項目標。
【為何其他選項錯了?】
- (A):平台內建的流程模擬與即時預覽只能檢查常用操作路徑是否通順,無法驗證真實的資料交換、邊界條件與異常處理。
- (C):僅測試使用者介面操作,無法驗證後端與外部服務間的資料正確性與錯誤處理,涵蓋面不足。
- (D):上線後才依使用者回饋修正,等於以正式營運承擔測試風險,是最被動、風險最高的作法。
提示:跨系統整合的可靠性關鍵字:自動化、可重複、模擬外部服務;預覽與 UI 測試僅驗證表面,上線後補救不是測試策略。
某金融集團評估將大型語言模型導入客服與風控系統，團隊採用如120B 參數等級的超大型語言模型以確保回應品質。請問下列何者最能說明企業在正式環境部署超大型語言模型時，最需要優先考量的因素？
- A模型參數量龐大，導致每次輸出結果差異極大，難以符合金融業對回應一致性的要求；
- B超大型模型無法支援批次處理，在高併發的客服場景下將造成嚴重的服務瓶頸；
- C推理延遲較高且運算資源消耗龐大，每次請求成本遠高於小型模型，需在模型效能與營運成本之間審慎權衡；
- D模型會依任務複雜度自動調整運算資源配置，因此不需特別考量推理成本
看正解與逐選項詳解
正解:C
正確答案:(C)
【正解解析】
超大型語言模型(如 120B 參數等級)推論時需要大量 GPU 與記憶體資源,單次請求的運算成本與延遲皆遠高於小型模型。在客服與風控等正式環境部署時,企業必須在回應品質、延遲、吞吐量與營運成本之間審慎權衡,例如評估模型壓縮、快取策略或分級路由(簡單問題交由小模型處理)等配套,這是部署超大型模型時最需優先考量的因素。
【為何其他選項錯了?】
- (A):參數量大不必然導致每次輸出差異極大;輸出一致性主要受溫度(Temperature)等解碼參數與提示設計影響,可透過設定控制。
- (B):超大型模型仍可採批次處理與併發設計,只是資源成本與延遲較高,「無法支援批次處理」的敘述錯誤。
- (D):模型不會自動依任務複雜度調整運算資源配置;推理成本與資源規劃仍需企業主動評估,「不需考量」的敘述明顯錯誤。
提示:超大參數模型上線,優先評估推理成本、延遲與資源需求的權衡;「自動調配、不需考量」類敘述必錯。
下列何者為 Kubernetes在AI模型部署與運行中的核心功能？
- A自動化管理模型的訓練流程與參數調校
- B管理與協調模型服務的部署、擴展與運行環境
- C提供AI 模型的資料儲存與版本控管功能
- D負責深度學習推論的 GPU 加速運算
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
Kubernetes 是容器編排(Container Orchestration)平台,在 AI 模型部署中的核心職責是管理與協調模型服務的運行:容器化服務的部署、自動擴縮(Scaling)、負載平衡、滾動更新與故障自癒,確保推論服務在叢集環境中穩定運行。其管理的層次是「服務如何部署、如何擴展、故障如何恢復」,屬於運行環境的協調者。
【為何其他選項錯了?】
- (A):訓練流程管理與參數調校屬機器學習框架及實驗管理工具(如 MLflow、Kubeflow Pipelines)的職責;Kubernetes 僅提供運行環境,不涉及調參。
- (C):資料儲存與模型版本控管由物件儲存服務與模型註冊庫(Model Registry)負責,Kubernetes 本身不是版本控管系統。
- (D):GPU 加速運算由 GPU 硬體與 CUDA 等運算函式庫達成;Kubernetes 只負責將 GPU 資源排程分配給容器,不執行運算本身。
提示:Kubernetes 的關鍵字是部署、擴縮、調度與自癒;訓練調參、版本控管、加速運算各有專責工具。
某AI服務系統每次推論請求需約 1秒完成，且必須支撐高達 10,000次請求每秒（RPS）的流量。為確保系統具備高可用性且能穩定應付流量峰值，下列哪一種架構方案最為合適？
- A依賴單台超高效能伺服器進行垂直擴展，提升硬體規格
- B採用容器化部署並水平擴展服務實例，結合自動彈性伸縮機制（Auto Scaling）
- C限制最大併發連線數，以避免系統過載
- D增加批次處理大小，一次同時處理上千筆請求
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
每秒 10,000 次請求且單次推論約 1 秒,代表系統隨時有上萬個請求同時在處理,單一伺服器無論規格多高都無法承載,且存在單點故障風險。容器化部署搭配水平擴展(Horizontal Scaling),將服務複製為多個實例分攤流量,再結合自動彈性伸縮(Auto Scaling)依流量峰谷增減實例數量,同時滿足高可用性、峰值承載與成本效率,是雲原生架構的標準解法。
【為何其他選項錯了?】
- (A):垂直擴展受單機硬體上限限制,難以支撐上萬併發;且單一伺服器故障即造成服務全面中斷,不具高可用性。
- (C):限制最大併發連線數是過載保護機制,超額請求會被拒絕;流量峰值時等於縮減服務,無法達成「穩定應付流量峰值」的要求。
- (D):加大批次可提升吞吐量,但會拉長單筆請求的等待延遲;且未解決單點架構的可用性問題,無法滿足高可用要求。
提示:高流量+高可用的標準組合:容器化、水平擴展、自動伸縮;垂直擴展有上限,限流是保護而非承載,加大批次犧牲延遲。
某即時詐欺偵測系統對模型回應時間有嚴格限制，若推論延遲過高將影響交易核准流程。維運工程師在模型上線前進行延遲測試（Latency Testing）時，主要評估的目標為何？
- A評估模型推論過程中的記憶體使用量，以確認部署資源是否足夠
- B驗證模型對異常或攻擊輸入的穩定性與安全性
- C評估模型在不同使用者族群上的預測結果是否一致
- D評估模型從接收輸入到產生預測結果所需的回應時間是否符合系統要求
看正解與逐選項詳解
正解:D
正確答案:(D)
【正解解析】
延遲測試(Latency Testing)量測的是系統從接收輸入到產生預測結果的端到端回應時間,並檢驗其是否符合系統要求(SLA);實務上除平均值外,還會關注尾端百分位數(P95、P99)與尖峰負載下的表現。對即時詐欺偵測系統而言,模型判斷若超出交易核准的時間窗,預測再準確也無法發揮作用,因此上線前必須確認推論延遲在限制之內。
【為何其他選項錯了?】
- (A):記憶體使用量屬資源使用與容量測試的範疇,評估的是部署資源是否足夠,而非回應速度。
- (B):對異常或攻擊輸入的穩定性與安全性,屬穩健性與安全性測試(Robustness/Security Testing)的目標,例如對抗樣本測試,與回應時間無關。
- (C):不同使用者族群間預測結果的一致性屬公平性(Fairness)評估,檢驗的是模型偏誤,而非回應時間。
提示:延遲測試只回答「輸入到輸出需時多久、是否符合 SLA」;評估時應納入 P95/P99,不能只看平均值。
某 AI 影像辨識平台以單一 GPU 伺服器提供多租戶推論服務，系統長期觀察到GPU 使用率約維持在 60%左右，且在執行過程中可觀察到 GPU kernel 之間存在明顯閒置間隔，單次推論多以小批次方式執行。然而，在尖峰時段時，請求延遲會出現明顯波動甚至突增。同時，CPU 與記憶體資源使用率均未達瓶頸，且系統團隊已排除硬體、網路與請求併發控制異常。在此情境下，請判斷最可能造成問題的原因為何？
- AGPU 排程策略與批次大小設定不當，導致 GPU 運算單元未被有效利用
- B請求併發控制機制不佳，導致多個請求同時搶占 GPU Context 資源造成延遲
- CGPU 硬體效能不足，無法支撐推論負載
- D模型未進行量化優化，導致推論計算成本過高
看正解與逐選項詳解
正解:A
正確答案:(A)
【正解解析】
依題幹線索推理:GPU 使用率僅約 60%、kernel 之間存在明顯閒置間隔、推論多以小批次執行,這是 GPU 運算單元未被充分利用的典型徵象;批次過小使平行運算能力閒置,排程未將併發請求聚合成較大批次(缺少動態批次處理, Dynamic Batching),kernel 啟動間隙形成空轉。尖峰時段請求只能排隊等候,延遲因此波動甚至突增。題幹已排除 CPU、記憶體、硬體、網路與併發控制等因素,最可能的原因即 GPU 排程策略與批次大小設定不當;改善方向包括啟用動態批次(如 Triton Inference Server)、調整批次大小與並行串流設定。
【為何其他選項錯了?】
- (B):題幹已明確排除請求併發控制異常,此選項與給定條件矛盾。
- (C):GPU 使用率僅約 60% 且有明顯閒置間隔,顯示問題是資源未被充分利用,而非硬體效能不足。
- (D):未量化會使單次計算成本偏高,但無法解釋 kernel 之間的閒置間隔與使用率偏低的現象;問題在排程與批次策略,而非計算精度。
提示:GPU 使用率偏低+延遲抖動,優先檢查批次策略與排程(動態批次);使用率未滿載時,擴充硬體與模型量化都非對症。
某MLOps 工程師正在設計AI模型的推論服務 API，需要處理使用者上傳的高解析度影像（平均 5MB）進行即時分類。在 RESTful API 設計時，選擇HTTP 請求方法與資料傳輸格式的最佳實踐為何？
- A使用 HTTP GET 方法，將影像資料 Base64 編碼後附加於 URL Query String中
- B採用 HTTP POST 請求，將影像資料以 multipart/form-data 或 application/octet- stream 傳輸於 Request Body
- C使用 HTTP PUT方法，透過 Content-Type: application/xml 傳遞影像資料
- D要求客戶端下載模型於本地推論，僅回傳分類結果
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
上傳平均 5MB 的影像進行即時分類,標準作法是使用 HTTP POST,將二進位影像置於 Request Body,以 multipart/form-data(表單式檔案上傳)或 application/octet-stream(原始二進位串流)傳輸。POST 的語意符合「提交資料以觸發伺服器端處理」,Request Body 沒有 URL 的長度限制,二進位直接傳輸也避免 Base64 編碼約 33% 的資料膨脹,是推論 API 的最佳實踐。
【為何其他選項錯了?】
- (A):GET 的 Query String 受 URL 長度限制,伺服器與代理通常僅允許數 KB;5MB 影像經 Base64 編碼後接近 7MB,多數伺服器與代理會直接拒絕;且資料置於 URL 會留存於各端存取日誌,有安全疑慮。
- (C):PUT 的語意是建立或整體替換指定資源,不符合「提交影像換取分類結果」的操作;以 XML 夾帶二進位影像需再經編碼,冗長且低效。
- (D):要求客戶端下載模型於本地推論,喪失集中式 API 服務的意義,並衍生模型資產外洩、客戶端算力不一與版本更新失控等問題。
提示:大檔案上傳固定搭配 POST+Request Body(multipart 或 octet-stream);將大量資料塞入 URL 的選項必錯。