「AI倫理與治理基礎」[解答]@e等公務園+e學中心

E等公務員測驗解答：AI倫理與治理基礎，供備考參考。

  「AI倫理與治理基礎」e等公務園+e學中心+學習平臺解答

相信大家會搜尋進來，應該也是為了更快速完成測驗，貼心的我們懂你❤資料均網路上蒐集整理，僅供參考。大家善用Ctrl+F搜尋題目關鍵字，相信很快就找到答案。

問：整合ERP/CRM/既有平台並希望重用既有元件，較貼近的做法是？

        全程客製手刻避免相依

v        運用平台OOTB連接器與可重用元件庫

        僅以RPA錄製操作腳本

        改以報表工具取代應用系統

問：Cloud?NativeLakehouse的核心組合最完整的是？

v        物件儲存+Parquet+Iceberg+分散式SQL（Trino/Spark）

        單一RDB+儲存程序

        HadoopHDFS+MapReduce（不表格化）

        NAS檔案分享+手寫ETL

問：要把生成式AI嵌入現有應用且可連接內部知識，較可行的方式是？

        自行蒐集大量語料從零訓練模型

        僅靠提示工程加長提示而不接知識

        以黑箱API串接且不留治理紀錄

v        使用平台AIAgent建構器（LLM+RAG）接入權管知識庫

問：『儲算分離』主要帶來的直接效益是？

        讓報表視覺更美觀

        提升單機CPU/記憶體規格

v        儲存與運算可獨立擴展以提升彈性與成本效率

        強制採用專屬查詢語法

問：開發過程希望即時得到架構、可維護性、效能與資安建議，較符合的能力是？

        以設計評審會議定期人工檢查

v        SDLC數位工作者（Mentor）於平台內即時提示

        每週彙整安全掃描報告再人工比對

        僅依據語法檢查（linter）

問：POC比測顯示：複雜條件查詢、入檔與Refresh在某架構明顯更快，較合理的推論是？

        RDB在數億筆入檔普遍更快

        HDFS在任何情境都更快

v        Cloud?NativeLakehouse在複雜查詢與大檔入檔/更新上具優勢

        速度僅與網路頻寬相關

問：地端導入Lakehouse的漸進式路線較合理的三步驟為？

        先上應用層→再想儲存→最後補運算

v        先建儲存/Iceberg→上運算（Trino/Spark）→導入應用（DataWiki/DataScope）

        直接丟棄RDB全面重建

        先購買一體機再規劃

問：哪一種情境最適合選用無程式碼工具來自助完成？

v        單位可自行維護的簡單表單與審核流程

        需跨多系統整合與複雜權限的入口網站

        高併發交易與嚴格一致性要求的核心系統

        需多雲混合與K8s編排的企業平台

問：若希望『設計→開發→測試→部署→維持』各階段皆可追蹤與回溯，下列哪一項最不可或缺？

        僅啟用linter與unittest

        單一CD工具即可涵蓋全部

v        平台層級的影響分析與回滾機制

        以文件簽核紀錄所有修改

問：要同時交付Web與Mobile並維持快速回滾，較完整的組合是？

v        單一程式碼部署+一鍵發佈/回滾+影響分析

        Web與Mobile各自分支獨立

        改由外包維護兩套程式

        僅保留Web以降低風險

問：要將分析結果『產品化』導入既有應用並可帶參數與權限，較對應的元件是？

        BI圖表嵌入即可

        Email排程CSV匯出

        提供檔案下載連結

v        DataScope（查詢封裝為API供應用調用）

問：想把查詢結果以服務化方式提供應用並可帶參數與權限，較合適的是？

v        以DataScope將查詢封裝成可帶條件的RESTAPI

        寄送CSV附件讓各系統匯入

        放置於共用雲端硬碟由應用讀取

        每次由工程師手刻專屬介面

問：希望同一套程式碼同時支援Web與Mobile並能快速回滾，較合適的策略是？

        Web與Mobile各維護獨立專案以降低風險

        先做Web，Mobile視需求延後

v        採用支援單一程式碼部署、含回滾機制的平台

        僅提供PWA作為行動版替代

問：若要把雲端最佳實踐帶回地端導入，較合理的第一步是？

        先購買大型一體機倉儲

v        建立S3相容物件儲存並導入Iceberg，再逐層補上運算與應用

        先大量製作儀表板讓使用者熟悉

        維持現況僅更換機房

問：面對多來源JSON/Log/影音造成RDB延遲飆升，較合理的改造為？

        單機加大記憶體

v        採儲算分離：以物件儲存承載，運算層（Trino/Spark）獨立擴展

        全部轉為CSV以減少格式

        以NAS為中繼並定期手清資料

問：為避免供應商綁定並利於長期治理，較佳的表格與查詢組合是？

v        Iceberg+Trino（開放格式/引擎）

        專屬商用倉儲+專用語法

        自製二進位格式+自寫查詢

        僅靠試算表巨集

問：若要同時具備影響分析、回滾與一鍵發佈，哪種做法最到位？

        建立單一CD任務並以手動備份輔助

        使用多套獨立工具以腳本串接各步驟

v        採用內建DevSecOps與釋出管線的一體化低程式碼平台

        將產線變更都改以人工複製檔案

問：要縮短從設計到交付的週期並控制技術債，哪個方向較佳？

        僅換新版UI，其餘流程不變

        全面外包並停止內部培力

        先買表單引擎，其他以人工補強

v        採用可視覺化開發、除錯、影響分析與回滾的一體化平台

問：要在知識密集流程降低AI幻覺並保留稽核，較穩健的做法是？

        依靠大型模型與更長提示

        關閉日誌以降低敏感資訊外洩

        只用關鍵字模板產文

v        以RAG接入權限控管知識庫並保留決策足跡

問：要讓跨部門可快速發現資料並掌握血緣，應優先導入哪個元件？

        Excel索引台帳

        自製Wiki條目

        群聊公告與貼文置頂

v        DataWiki（資料目錄與血緣視覺化）