造神型的數據分析：解析政府真的降低「兒虐」人數？|數位時代 BusinessNext

最近虐童案頻傳，部分網友紛紛跳出來罵說：政府真是沒有用，虐嬰比例上升！但這時候某媒體【圖表】近十年施虐者「樣貌」：兒虐案的主因不只是「小爸媽」（此文已修正，包含將 2018年的數據移除，以及把「家外」的人數加入）一文中的一張圖出來打了很多人的臉。

從未經調整的原圖來看，政府真的是無限威能，上任隔年開始兒虐案受虐人數瞬間砍半，從每年超過萬人以上，瞬間砍半到不 5,000 ，這實在太神奇了！

但是身為一個視數據分析為主要技能的我，看到這種砍半數據只有一個直覺：不可能！對不起，我就是要說：不可能！

任何有點基礎數據分析能力的人都會知道數據大漲或大跌，其背後一定要有原因，而不是看到數據下跌了就說棒棒噠。

可是翻開過去兩年，政府對於兒少受虐，從小燈泡開始嚴格來說沒有太大的積極作為，也就是沒有任何的外力或條件可以減少兒少受虐人數，難道真的是經濟變好，虐待小孩的父母良心發現，所以不再虐兒了？

所以身為一個數據分析者，第一件事情，就要先回頭看還沒被做成圖表原始數據。

數據有問題通常第一件事情都是原始資料就出了錯。

因此我們打開了衛福部統計處的網頁，裡面的資料分類做得相當的好，包含人數、類型都分類的清清楚楚的，但當我下載了 3.5.6 的「 兒童少年保護 - 受虐人數 」時，第一個問題就出現了：

數據統計方式明顯出現了改變

從 106 年起，除了時間維度之外，分類的維度從「兒童少年保護 - 受虐人數 Number of Abused Child and Youth」改為了「家內兒童及少年保護案件 - 受虐人數 Intra - family Child and Youth Protection Cases - Number of Abused」（政府還很貼心地加上了紅字，明確的告訴你統計維度的不同。）

統計維度的不同，做成同一張表，自然數據就會有明顯落差，就像如果你看 Google Analytics ，看進站的使用者跟工作階段，擺明就是不同的維度，做在同一張表會是正確的嗎？

數據維度改變的探究

那維度做了什麼改變，能讓破萬掉到不到五千呢？基本上我是沒有明確地找到相關的說明是如何改變的，但是從 3.5.5 兒童少年保護-受虐類型的分類中找到了原因。

2016年以前的數據應是以「複選」的錯誤統計方式來統計，而 2017 年後應該是以「案件」作為主要類別來做統計。

為什麼這樣的統計方式可能會是錯的？當然受虐方式有很多，假設今天有一個虐兒，他主要是受到身體虐待，但他可能同時也受到了精神虐待甚至性虐待，在複選的情況下就被勾了三次，也就是說同一個虐兒可能被統計兩次以上。（雖然新的表中文「複選」拿掉了，但英文還在）。

這樣也正說明在 2017 年以後，統計回歸以「案件」方式來統計數據砍半的原因，真要說蔡政府作出了什麼貢獻，主要就是讓數據合理化（更正：有朋友指出，馬政府年代就已經做出更正了，不過目前無直接證據先保留）。

但現在也沒有舊有的數據去還原原本 93年至105年錯誤的計算方式正確後的結果，所以無從比較歷史以來蔡政府是不是真的降低了虐童數。

還有麻煩「人次」跟「人數」是不一樣的指標請不要混用。

上半段感謝該媒體修正，但預留一手的查證則要繼續討論了。當然就該媒體代表回應：

「感謝指正，確認2017年至2018的統計數字僅含「家內」人數，故圖表不再列入近兩年統計。

唯「歷年兒虐案受虐人數」一圖，進一步求證衛福部保護司2017年「家內」人數為4135，「家外」為3212，故該年度總人數應為7347人，該圖也已經更正，2018年因沒有完整年度人數故不列入比較。在此也對原本數字誤植導致圖表的錯誤致歉。」

如果我們再打開 3.5.1 兒童少年保護 - 通報處理情形的檔案就有發現這句話：

也就是說 3.5.6 中的人數並非真正受虐人數，而是「有開案的人數」。那時既有開案前的通報案例的數字又是發生了什麼變化呢？

網上盛傳的圖表是成案數，未說明106年是只計家內通報開案、107年只算了前三季。報表看起來才會在現任政府任內看起來特別低，不表示真的低那麼多。

另外只計家內人數也不是為了隱匿情況，而是過去數字有重覆計算人次的問題，而做出調整，還原貼近真實數字（但也喪失了相同標準數字比較之可能性）。

爬資料可發現，通報數從2010年守護幼苗專案開始逐年攀高，但成案數除了前三年因通報而增加，接下來却是連年下降。

先給大家一個數感，台灣去年的新生兒人數不足20萬人，而去年通報了有近6萬次的兒虐。

一般媒體及兒少團體會報導說是吃案、證據不足而無法成案，但也有檢討說是為了追求通報數而浮報、濫報，造成社工困擾，所以希望改善方法是降低通報數。

本文由邱煜庭授權轉載自其Facebook。

《數位時代》長期徵稿，針對時事科技議題，需要您的獨特觀點，歡迎各類專業人士來稿一起交流。投稿請寄edit@bnext.com.tw，文長至少800字，請附上個人100字內簡介，文章若採用將經編輯潤飾，如需改標會與您討論。

（觀點文章呈現多元意見，不代表《數位時代》的立場。）

2026台灣設計展於9月24日至10月11日在桃園登場，以「桃園流」為主題，結合千塘之鄉的水文地景、國門之都的航空與物流優勢、多元族群文化匯流，以及 AI 科技應用，展現城市運轉的動態美學。

其中，為提供民眾不同於以往的互動體驗，AIoT 智慧感知大數據平台服務商棋苓（Chylyng）推出全展區 AI 穿戴互動體驗「FLOW CHECK」。參觀者配戴主辦單位提供的智慧手環後，可沿著展場動線於不同站點進行互動。即使多人同時參與，每位參觀者仍可依照不同的路徑、選擇與互動節奏完成體驗；系統並依據互動過程與結果，即時生成專屬的 Flowmomo 數位卡牌，讓參觀者儲存並帶走屬於自己的展覽體驗紀錄。

看似簡單的手環互動，背後其實是一套整合穿戴裝置、即時感測、場域互動、資料處理與雲端服務的完整系統。尤其在大型公開展覽環境中，不僅必須因應大量參觀者於短時間內同時使用，也必須確保從手環感測、站點互動、資料傳輸到最終結果產出的每一個環節，都能維持即時且穩定的服務品質。

棋苓以自主開發的 Eleplo AIoT Platform 為技術核心，整合穿戴裝置、感測設備、人員與資產定位，以及即時事件與資料管理，並負責建構 FLOW CHECK 的手環互動邏輯、站點應用、卡牌生成及參觀者操作介面。

專業分工合作：諾德資訊坐鎮後端，撐住大型公開展覽的服務韌性

為了讓系統從開發與測試環境順利進入大型公開場域，並進一步提升正式服務的可用性、資安與系統韌性，諾德資訊與棋苓採取專業分工合作。棋苓聚焦於 AIoT 平台、穿戴應用及使用者體驗；諾德資訊則負責後端基礎架構、正式環境部署、壓力測試、高可用性驗證，以及服務上線後的系統與流量監控。

由於展場現地部署時間僅有兩天，雙方將大量驗證工作提前至開展前完成。諾德資訊於正式開展前約一個月即建置專用測試環境，讓棋苓的應用服務提早與正式營運架構整合，並進行壓力測試、高可用性驗證及異常情境測試，使原本必須於現場進行的系統驗證工作大幅提前完成。

諾德資訊業務開發經理邱柏瑞表示：「FLOW CHECK 的挑戰在於大量參觀者可能集中於同一時段使用手環，因此除了確保服務穩定之外，也必須辨識進入系統的流量究竟來自真人使用者、合法自動化程式、AI Bot 或惡意攻擊，並透過即時監控及早發現異常。」為此，諾德資訊導入 IntelliFend Bot Management，協助辨識真人使用者、合法自動化及異常機器人流量，並於展覽公開服務期間透過遠端監控，持續掌握主機、資料庫、應用服務及外部流量狀態。

此外，為驗證系統在大型展覽情境下的承載能力，正式展出前，諾德資訊亦協助棋苓進行大規模壓力測試，模擬最高約 3 萬人同時使用的流量情境，提前觀察系統資源使用狀況、服務反應與可能的效能臨界點，並據此進行相關調校。

透過棋苓在 AIoT、智慧穿戴與互動應用上的技術能力，以及諾德資訊在正式營運環境、資安、壓力測試與維運監控上的經驗，雙方在展覽正式開放前，即完成從應用層到基礎架構的完整驗證，讓 FLOW CHECK 能夠在大型公開場域中穩定提供即時的 AI 穿戴互動體驗。

AI加速開發腳步，但也增加「上線」考驗

從生成式AI到代理式AI，軟體開發速度快速提升，過去需要長時間才能完成的產品原型（Prototype）與概念性驗證（PoC）專案，現在可以很快完成驗證，讓軟體商有更多時間跟資源投入客戶需求、產品創意與使用體驗。

但是，從PoC走到Production，面對的是完全不同的考驗。
諾德資訊技術長張家榮解釋，進入正式環境（Production）後，軟體服務必須面對真實使用者的流量、不同客戶的IT環境、計算資源擴充、資料庫負載、網路連線、資安攻擊，以及服務異常時的切換與處理，就算在壓力測試時表現正常的系統，也可能在Production的時候出現問題。

更值得特別注意的是，AI不只讓開發者更快，也讓攻擊者發現漏洞的速度加快；過去，服務上線後還有時間慢慢觀察、修正，現在，服務一上線，可能很快就遭到掃描甚至攻擊。

也因如此，軟體商、系統整合商選擇基礎架構夥伴的條件開始改變，從過去關注功能與價格轉向：產品能不能順利上線？出了問題誰來處理？面對流量變化與資安風險，服務能不能持續運作？

張家榮表示：「諾德資訊可以提供從公有雲、私有雲、地端、邊緣運算、主機代管、網路，到維運與監控等服務，讓軟體夥伴可以將資源集中在應用與客戶需求，無須擔憂Production議題。」

不僅提供資源，諾德資訊將Production變成一項服務

而這也是諾德資訊會提出「Production as a Service」的原因：不是在提供另一種雲端或主機服務，而是將軟體從開發走向正式營運所需的Production流程，轉化成可以被專業分工、驗證與持續維運的一項服務。

「Production as a Service不是單純把主機或雲端資源租給客戶，而是共同檢視這套軟體能不能順利上線與正常營運。」邱柏瑞表示。

實際做法包括，在上線前協助檢視架構，建立與正式環境相近的測試環境，確認系統正常狀態、最大承載量與資源需求，並驗證高可用性、資安、備援及服務切換機制；上線後則持續監看服務狀態、容量與流量，及早發現異常並處理。

諾德資訊之所以有這樣的服務能力，可以歸結為三點：

第一，長期累積的基礎架構與維運經驗，目前，諾德資訊同時服務的客戶數近30家，應用情境涵蓋IoT、購物平台、遊戲、音樂等不同類型的軟體服務。

第二，諾德資訊將每一個客戶遇到的問題與解決方案收攏至知識庫，讓團隊成員可以快速處理、借鏡，滿足客戶需求。

第三，依循ITIL的維運精神，並具備ISO 27001等資安相關認證，將服務流程、操作紀錄、備份、監控與異常處理等機制內化到服務之中。

這也是諾德資訊與單純提供雲端、IDC或主機代管服務的業者之間的最大差異：交付的不僅是基礎設施，而是讓服務持續運作的能力。面對客戶同時使用公有雲、私有雲、地端與邊緣運算環境，諾德資訊另以 MQloud 提供統一管理，把網路、防火牆、流量、監控與帳務收進同一套平台，降低跨環境營運的複雜度。

「軟體商負責開發，就像晶片設計公司；諾德資訊則負責協助完成測試、製程調整與正式生產，讓產品真正走向市場，希望成為『軟體界的台積電』。」張家榮如是說道。

展望未來，諾德資訊將持續深化 Production as a Service，成為軟體公司從上線到長期營運的夥伴。自構想階段起即與軟體商共同討論架構，於測試階段協助驗證，於準備上市時承接正式環境，上線後則持續守住流量、資安與服務韌性。軟體開發者與 SaaS 業者可將資源集中於產品與客戶，完整基礎架構與 24×7 維運則由諾德資訊端到端承接。