rodiyer.idv.tw 拉里拉雜
rodiyer.idv.tw 拉里拉雜
| 問 | 要把生成式 AI 嵌入現有應用且可連接內部知識，較可行的方式是？ |
| 自行蒐集大量語料從零訓練模型 | |
| 僅靠提示工程加長提示而不接知識 | |
| 以黑箱 API 串接且不留治理紀錄 | |
| ✓ | 使用平台 AI Agent 建構器（LLM+RAG）接入權管知識庫 |
| www.rodiyer.com | |
| 問 | 哪一種情境最適合選用無程式碼工具來自助完成？ |
| ✓ | 單位可自行維護的簡單表單與審核流程 |
| 需跨多系統整合與複雜權限的入口網站 | |
| 高併發交易與嚴格一致性要求的核心系統 | |
| 需多雲混合與 K8s 編排的企業平台 | |
| www.rodiyer.com | |
| 問 | 想把查詢結果以服務化方式提供應用並可帶參數與權限，較合適的是？ |
| ✓ | 以 DataScope 將查詢封裝成可帶條件的 REST API |
| 寄送 CSV 附件讓各系統匯入 | |
| 放置於共用雲端硬碟由應用讀取 | |
| 每次由工程師手刻專屬介面 | |
| www.rodiyer.com | |
| 問 | 要讓跨部門可快速發現資料並掌握血緣，應優先導入哪個元件？ |
| Excel 索引台帳 | |
| 自製 Wiki 條目 | |
| 群聊公告與貼文置頂 | |
| ✓ | DataWiki（資料目錄與血緣視覺化） |
| www.rodiyer.com | |
| 問 | 要將分析結果「產品化」導入既有應用並可帶參數與權限，較對應的元件是？ |
| BI 圖表嵌入即可 | |
| Email 排程 CSV 匯出 | |
| 提供檔案下載連結 | |
| ✓ | DataScope（查詢封裝為 API 供應用調用） |
| www.rodiyer.com | |
| 問 | 「儲算分離」主要帶來的直接效益是？ |
| 讓報表視覺更美觀 | |
| 提升單機 CPU/記憶體規格 | |
| ✓ | 儲存與運算可獨立擴展以提升彈性與成本效率 |
| 強制採用專屬查詢語法 | |
| www.rodiyer.com | |
| 問 | 若要把雲端最佳實踐帶回地端導入，較合理的第一步是？ |
| 先購買大型一體機倉儲 | |
| ✓ | 建立 S3 相容物件儲存並導入 Iceberg，再逐層補上運算與應用 |
| 先大量製作儀表板讓使用者熟悉 | |
| 維持現況僅更換機房 | |
| www.rodiyer.com | |
| 問 | 開發過程希望即時得到架構、可維護性、效能與資安建議，較符合的能力是？ |
| 以設計評審會議定期人工檢查 | |
| ✓ | SDLC 數位工作者（Mentor）於平台內即時提示 |
| 每週彙整安全掃描報告再人工比對 | |
| 僅依據語法檢查（linter） | |
| www.rodiyer.com | |
| 問 | 面對多來源 JSON/Log/影音造成 RDB 延遲飆升，較合理的改造為？ |
| 單機加大記憶體 | |
| ✓ | 採儲算分離：以物件儲存承載，運算層（Trino/Spark）獨立擴展 |
| 全部轉為 CSV 以減少格式 | |
| 以 NAS 為中繼並定期手清資料 | |
| www.rodiyer.com | |
| 問 | 要在知識密集流程降低 AI 幻覺並保留稽核，較穩健的做法是？ |
| 依靠大型模型與更長提示 | |
| 關閉日誌以降低敏感資訊外洩 | |
| 只用關鍵字模板產文 | |
| ✓ | 以 RAG 接入權限控管知識庫並保留決策足跡 |
| www.rodiyer.com | |
| 問 | 要同時交付 Web 與 Mobile 並維持快速回滾，較完整的組合是？ |
| ✓ | 單一程式碼部署 + 一鍵發佈/回滾 + 影響分析 |
| Web 與 Mobile 各自分支獨立 | |
| 改由外包維護兩套程式 | |
| 僅保留 Web 以降低風險 | |
| www.rodiyer.com | |
| 問 | 希望同一套程式碼同時支援 Web 與 Mobile 並能快速回滾，較合適的策略是？ |
| Web 與 Mobile 各維護獨立專案以降低風險 | |
| 先做 Web，Mobile 視需求延後 | |
| ✓ | 採用支援單一程式碼部署、含回滾機制的平台 |
| 僅提供 PWA 作為行動版替代 | |
| www.rodiyer.com | |
| 問 | 要縮短從設計到交付的週期並控制技術債，哪個方向較佳？ |
| 僅換新版 UI，其餘流程不變 | |
| 全面外包並停止內部培力 | |
| 先買表單引擎，其他以人工補強 | |
| ✓ | 採用可視覺化開發、除錯、影響分析與回滾的一體化平台 |
| www.rodiyer.com | |
| 問 | 到架構、可維護性、效能與資安建議，較符合的能力是？ |
| 以設計評審會議定期人工檢查 | |
| ✓ | SDLC 數位工作者（Mentor）於平台內即時提示 |
| 每週彙整安全掃描報告再人工比對 | |
| 僅依據語法檢查（linter） | |
| www.rodiyer.com | |
| 問 | 地端導入 Lakehouse 的漸進式路線較合理的三步驟為？ |
| 先上應用層→再想儲存→最後補運算 | |
| ✓ | 先建儲存/Iceberg → 上運算（Trino/Spark）→ 導入應用（DataWiki/DataScope） |
| 直接丟棄 RDB 全面重建 | |
| 先購買一體機再規劃 | |
| www.rodiyer.com | |
| 問 | 為避免供應商綁定並利於長期治理，較佳的表格與查詢組合是？ |
| ✓ | Iceberg + Trino（開放格式/引擎） |
| 專屬商用倉儲 + 專用語法 | |
| 自製二進位格式 + 自寫查詢 | |
| 僅靠試算表巨集 | |
| www.rodiyer.com | |
| 問 | 若要同時具備影響分析、回滾與一鍵發佈，哪種做法最到位？ |
| 建立單一 CD 任務並以手動備份輔助 | |
| 使用多套獨立工具以腳本串接各步驟 | |
| ✓ | 採用內建 DevSecOps 與釋出管線的一體化低程式碼平台 |
| 將產線變更都改以人工複製檔案 | |
| www.rodiyer.com | |
| 問 | Cloud?Native Lakehouse 的核心組合最完整的是？ |
| ✓ | 物件儲存 + Parquet + Iceberg + 分散式 SQL（Trino/Spark） |
| 單一 RDB + 儲存程序 | |
| Hadoop HDFS + MapReduce（不表格化） | |
| NAS 檔案分享 + 手寫 ETL | |
| www.rodiyer.com | |
| 問 | 若希望『設計→開發→測試→部署→維持』各階段皆可追蹤與回溯，下列哪一項最不可或缺？ |
| 僅啟用 linter 與 unit test | |
| 單一 CD 工具即可涵蓋全部 | |
| ✓ | 平台層級的影響分析與回滾機制 |
| 以文件簽核紀錄所有修改 | |
| www.rodiyer.com | |
| 問 | 整合 ERP/CRM/既有平台並希望重用既有元件，較貼近的做法是？ |
| 全程客製手刻避免相依 | |
| ✓ | 運用平台 OOTB 連接器與可重用元件庫 |
| 僅以 RPA 錄製操作腳本 | |
| 改以報表工具取代應用系統 |
沒有留言: