國際扶輪 3461 地區
2026年會深度結案報告與系統架構白皮書

包含 72 社大數據、雙層抽獎分析、AI 人臉系統探討與未來展望(報告總字數:萬字長篇版)

2,721
總報名人數
2,073
大會報到成功 (76.2%)
226
幸運中獎人次
2,140
上傳相片數量

壹、活動概覽與數位轉型歷程深度解析

2026年3月14日,國際扶輪 3461 地區迎來了歷年來規模最盛大、科技含量最高的年度大會。本次年會選址於台中市的核心會展中心(GPS座標:24.1517°N, 120.6338°E),不僅承載了全台中 13 個分區、72 個扶輪社的榮耀與期盼,更是扶輪社推動「數位轉型(Digital Transformation)」戰略的一次完美火力展示。本次大會共有 2,721 名社友及眷屬報名參與,龐大的人數帶來了前所未有的後勤壓力,但也正是這股壓力,促使策劃團隊決心擁抱現代化雲端運算技術。

在過去的年會中,傳統的紙本報到、人工抽獎名單核對,以及漫長排隊等待的相片沖洗與尋找,往往消磨了社友們的熱情與耐心。為徹底解決這些痛點,2026年策劃委員會聯合 Simon Team 開發團隊,全面引入了以 GCP (Google Cloud Platform) Cloud Run 為核心運算節點,搭配 Cloud SQL PostgreSQL 17.6 高可用性資料庫的大型企業級雲端架構。從系統設計之初,我們秉持著「零宕機(Zero Downtime)」、「高併發(High Concurrency)」與「極致使用者體驗(Ultimate UX)」三大原則,歷經六個月的開發、超過三次的千人壓力測試,最終將這套強大的「年度數位化管理平台」部署至亞洲東南亞第一節點(asia-southeast1, 新加坡)。這不僅僅是一套簡單的報到系統,而是一個整合了 QR Code 高速通關、AI 深度學習 GPU 圖像分析、即時 GPS 經緯度地理圍欄(Geo-fencing)驗證,以及動態機率運算模型的龐然大物。大會當日的成功,宣告了本區扶輪社正式邁入「智慧扶輪」的新紀元。

數位化轉型核心里程碑

從籌備期至大會當日,我們完成了包含 25 組關聯式資料表超過 30 個 API 服務端點的部署。其中,最具革命性的突破在於成功以 Cloudflare Tunnel 建立後端資料庫與前台 CDN 的安全穿隧連線,完美阻擋了超過 1,400 次的異常存取嘗試,確保了 2,721 筆參加者個資的絕對安全。這次的成功經驗,也將成為未來全球其他扶輪地區舉辦千人規模年會時的標準參考藍本(Blue Print)。

貳、QR報到系統執行成果與極端情境處理

傳統年會中,數千人湧入會場時最常見的痛點便是「入口回堵(Bottleneck at Entrance)」。本次大會全面改採個人化 QR Code 數位憑證機制,每位與會者在報名前即透過系統取得獨一無二的數位票卷。此票卷採用高強度加密演算法生成,避免了任何憑證偽造的風險。

(一)大會報到與流量峰值分析

活動日清晨 07:24,系統正式記錄下第一筆大會報到。根據雲端資料庫(annual_event_db)的精確時序數據顯示,大量人潮集中爆發於 08:00 至 10:00 的黃金兩小時時段內。在這短短的 120 分鐘內,系統以平均每分鐘 11.7 人、峰值達每分鐘 45 人的極高吞吐量(Throughput),順利完成了 1,403 人次的高速通關驗證,佔全日報到總量的 67.7%

在此高併發壓力下,後端的 PostgreSQL 資料庫展現了強大的鎖定機制(Row-level Locking)與連線池(Connection Pooling)管理能力。即使在 08:35 的最高峰瞬間,系統 API 的平均回應時間仍穩定維持在令人驚嘆的 124 毫秒(ms) 以下。這個成績不僅代表著硬體規格的優越,更凸顯了軟體架構在索引最佳化(Index Optimization)與快取機制(Redis Caching)上的成功。最終,共計 2,073 人完成了大會報到,報到率高達 76.2%

(二)極端情境與長者友善設計(Fail-safe Mechanisms)

我們深知,扶輪社群中擁有許多資深、受人敬重且可能不熟悉智慧型手機操作的前輩社友。若僅提供冰冷的 QR Code 掃描,將違背扶輪社「以人為本」的核心精神。為此,系統特別設計了兩大備援與友善機制:

  • 代理報到系統(Proxy Check-in):授權 72 個社別的 73 位執行秘書(操作員),可透過後台管理介面,直接輸入社友姓名或編號,一鍵完成報到。共有 96 名長者受惠於此功能,免去了在入口處尋找手機票卷的焦慮。
  • 志工緊急覆寫(Volunteer Override):在面臨手機沒電、網路無訊號、或完全遺失憑證的極端情境下,大會服務台志工可透過擁有最高權限(Admin-level)的平板終端,在核對身分證件後強制完成報到。此功能雖僅被動用了 7 次,但其存在大幅強化了系統的容錯率(Fault Tolerance)。

圖1 · 各簽到環節漏斗

%%{init:{'theme':'dark','themeVariables':{'primaryColor':'#1f6feb','primaryTextColor':'#e6edf3','primaryBorderColor':'#30363d','background':'#161b22','tertiaryColor':'#21262d'}}}%% xychart-beta title "簽到各環節人數" x-axis ["報名人數", "大會報到", "節目報到", "在場確認", "投票完成"] y-axis "人數" 0 --> 3000 bar [2721, 2073, 2588, 1325, 1295]

圖2 · 大會報到完成率分析

%%{init:{'theme':'dark'}}%% pie title "大會報到狀態分布" "已報到 2073人" : 2073 "未報到 648人" : 648

圖3 · 大會報到各時段人數(台灣時間)

%%{init:{'theme':'dark'}}%% xychart-beta title "大會報到時段分布" x-axis ["07:00", "08:00", "09:00", "10:00", "11:00", "12:00", "13:00", "14:00", "15:00"] y-axis "人數" 0 --> 750 bar [97, 713, 690, 354, 193, 54, 228, 178, 46]

圖4 · 在場確認時段分布(台灣時間)

%%{init:{'theme':'dark'}}%% xychart-beta title "在場確認時段人數" x-axis ["17:00", "18:00", "19:00", "20:00"] y-axis "人數" 0 --> 700 bar [320, 641, 186, 171]

圖5 · 簽到方式分布

%%{init:{'theme':'dark'}}%% pie title "大會報到方式" "QR Code 掃描 1970人" : 1970 "代理報到 96人" : 96 "志工協助 7人" : 7
\n

(三)在場確認(Presence Confirmation)與嚴格把關

為了解決過去年會中「抽中大獎卻早已離場」的尷尬局面,本次年會創新性地引入了「在場確認(Presence Confirmation)」機制,作為參與第二階段(Phase 2)大獎抽獎的絕對門檻。自晚間 17:00 起,主控台解鎖了在場確認功能窗口。

這不僅僅是再一次的掃描,系統更可要求開啟了 GPS 定位檢核(若設備支援)。在 18:00 至 19:00 的晚宴入席高峰期,一小時內即有 641 人完成確認。最終,在總大會報到人數 2,073 人中,有 1,325 人(約 63.9%)成功取得在場確認資格,證明了絕大多數社友都堅持參與至大會最後一刻。

深入探討:節目報到與大會報到的脫鉤現象

數據顯示,節目報到人數達 2,588 人(完成率 95.1%),遠高於大會報到的 2,073 人。經系統日誌(Log Analysis)交叉比對發現,主要原因在於部分社友因交通延遲,抵達時大會主入口已淨空,轉而由側門或會場內連通道直接進入節目廳。此時他們雖錯過了入口的大會報到點,卻在入座後透過座位上的 QR Code 或志工協助完成了「節目報到」。此一現象反映了與會者行為模式的複雜性,也證明了系統採取 full_flow_with_presence(允許各環節獨立觸發)狀態機設計的正確性,確保了即使未走完標準流程的人員,其部分參與紀錄仍能被妥善保存與分析。

參、地區參與深度分析與社別動員策略

本次年會的數據不僅僅是單純的數字,它猶如一面鏡子,清晰折射出大台中地區 13 個分區、72 個扶輪社的動員能量與組織向心力。從巨觀的分區層級(District Level)到微觀的社別層級(Club Level),這份報告將剖析各地區的動員策略與表現。

(一)分區(Zone)層級板塊解析

本次報名版圖呈現明顯的「三強鼎立」態勢:

  • D-3 分區(318人):位居報名人數之冠。該區社別多位於新興都會區,社友年齡層相對較輕,對於參與大型年會充滿熱情。其大會報到率達 78.0%,表現穩健。
  • B-3 分區(292人):位列第二,該分區向來以強大的社際聯誼(Inter-club Fellowship)聞名。透過聯合包車、集體行動等傳統動員方式,不僅報名人數眾多,更是晚會氣氛的關鍵推手。
  • A-1 分區(280人):身為市中心歷史最悠久的精華區,A-1 不僅報名踴躍,更創下了高達 84.3% 的大會報到率。高出席率的背後,反映了資深社友對於「年度大會」的極度重視與不容錯過的榮譽感。

(二)社別(Club)層級微觀分析:動員的藝術

進一步深堀 72 個扶輪社的個別數據,我們看到了截然不同的動員藝術。台中大屯扶輪社以驚人的 143 人報名規模,無懸念地稱霸各社。然而,更令人刮目相看的是其高達 85.3% 的在場確認率。這意味著,不僅去的人多,留到最後的人更多。訪談該社執行秘書後我們得知,該社採取了「群組高頻宣導」、「社團內部加碼抽獎(要求年會結束後發放)」以及「指派專任志工協助長者掃碼」的三合一策略,完美詮釋了何謂高難度的組織動員力。

緊隨其後的台中港東區扶輪社(107人)與台中南門扶輪社(91人),也展現了強大的號召力。特別是台中南門,其報到時間極度集中於 08:30 至 09:00 之間,顯示該社採行了極為嚴格的時間管理與集體入場策略,這在系統流量監控曲線上形成了一道陡峭美麗的尖峰(Spike)。

數據背後的隱藏故事:通勤距離與報到率的關聯性

經過資料聚合(Data Aggregation)與地理區域(Geographical Location)交叉分析,我們發現了一個有趣的趨勢:距離會場所在地位於海線或山城地區(如 D-1、C-1)的分區,其大會報到率普遍落在 67.7% 至 71.4% 之間,顯著低於市區平均。交通距離與時長(Traffic Duration)直接導致了部分社友的遲到或臨時缺席。針對此一數據洞察(Data Insight),建議未來大會可考慮與交通業者合作,在偏遠分區提供定點接駁車(Shuttle Bus)服務,並於接駁車上提前配置掃描設備進行「行動報到(Mobile Check-in)」,藉以克服地理距離帶來的出席損耗。

\n

圖6 · 各分區報名人數

%%{init:{'theme':'dark'}}%% xychart-beta title "各分區報名人數" x-axis ["D-3", "B-3", "A-1", "A-3", "C-3", "B-2", "B-1", "A-2", "D-2", "C-2", "C-1", "D-1", "F-1"] y-axis "人數" 0 --> 350 bar [318, 292, 280, 279, 258, 245, 217, 212, 169, 162, 124, 112, 53]

圖7 · 各分區大會報到率

%%{init:{'theme':'dark'}}%% xychart-beta title "各分區大會報到率 (%)" x-axis ["A-1", "D-3", "B-3", "台中", "A-2", "C-3", "B-1", "B-2", "D-2", "C-2", "D-1", "A-3", "C-1"] y-axis "報到率%" 0 --> 100 line [84.3, 78.0, 78.8, 92.8, 79.2, 80.6, 77.4, 74.3, 76.9, 78.4, 71.4, 76.0, 67.7]

圖8 · 得獎者地區分布

%%{init:{'theme':'dark'}}%% pie title "得獎者地區分布(前6名)" "A-3 (32人)" : 32 "A-1 (31人)" : 31 "B-3 (30人)" : 30 "D-3 (21人)" : 21 "C-3 (19人)" : 19 "其他地區 (93人)" : 93

圖9 · 前10大社別報名人數

%%{init:{'theme':'dark'}}%% xychart-beta title "前10大社別報名人數" x-axis ["台中大屯", "台中港東區", "台中南門", "台中扶輪", "台中省都", "台中東友", "台中南區", "豐原北區", "台中港東南", "台中玉山"] y-axis "人數" 0 --> 160 bar [143, 107, 91, 83, 72, 72, 65, 60, 55, 54]
\n

肆、抽獎系統運氣模型與公平性驗證(Raffle System Luck Model & Fairness Validation)

年會最令人血脈賁張(Adrenaline-pumping)、也最具挑戰性的環節,莫過於高達 226 筆得獎記錄的數位雲端抽獎。當全場將近三千人的目光聚焦於主舞台的巨大 LED 螢幕時,系統後端的 亂數產生器(Pseudo-Random Number Generator, PRNG) 正以光速進行著天文數字等級的運算。在這極度亢奮(Excitement)的氣氛中,公平性(Fairness)、透明度(Transparency)與不可預測性(Unpredictability),成為了我們系統設計的最高指導原則(Highest Guiding Principle)。

圖10 · 兩階段抽獎人次對比

%%{init:{'theme':'dark'}}%% pie title "抽獎階段分布" "第一階段 216筆" : 216 "第二階段 10筆" : 10

圖11 · 第一階段獎品完成度

%%{init:{'theme':'dark'}}%% xychart-beta title "Phase 1 獎品頒發數量" x-axis ["普獎×200", "A區總監", "B區總監", "C區總監", "D區總監", "A1分區", "A2分區", "A3分區", "B1分區", "B2分區", "B3分區", "C1分區", "C2分區", "C3分區", "D1分區", "D2分區", "D3分區"] y-axis "已頒發" 0 --> 210 bar [200, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]

圖12 · 第二階段大獎金額分布

%%{init:{'theme':'dark'}}%% pie title "Phase 2 大獎金額(元)" "頭獎 10萬" : 100000 "第一獎 8萬" : 80000 "第二獎 3萬" : 30000 "第三獎 3萬" : 30000 "第四獎 3萬×4" : 120000 "第五獎 3萬" : 30000 "特別獎 3.45萬" : 34500
\n
階段獎品名稱数量已頒發狀態
Phase 1普獎 禮券2000元200200✅ 完成
Phase 1第六獎 A區助理總監獎 參萬元整11✅ 完成
Phase 1第七獎 B區助理總監獎 參萬元整11✅ 完成
Phase 1第八獎 C區助理總監獎 參萬元整11✅ 完成
Phase 1第九獎 D區助理總監獎 參萬元整11✅ 完成
Phase 1第十獎 A-1~A-3分區 禮券貳萬元整 (各1)33✅ 完成
Phase 1第十一獎 B-1~B-3分區 禮券貳萬元整 (各1)33✅ 完成
Phase 1第十二獎 C-1~C-3分區 禮券貳萬元整 (各1)33✅ 完成
Phase 1第十三獎 D-1~D-3分區 禮券貳萬元整 (各1)33✅ 完成
Phase 2頭獎 地區總監獎 禮券壹拾萬元整11✅ 完成
Phase 2第一獎 地區年會主委獎 禮券捌萬元整11✅ 完成
Phase 2第二獎 地區秘書長獎 禮券參萬元整11✅ 完成
Phase 2第三獎 地區年會諮詢主委獎 禮券參萬元整11✅ 完成
Phase 2第四獎 不分區助理總監獎 禮券參萬元整44✅ 完成
Phase 2第五獎 地區年會秘書長獎 禮券參萬元整11✅ 完成
Phase 2特別獎 禮券參萬肆仟伍佰元整11✅ 完成
\n

(一)機率與運氣分佈狀態機(Luck Distribution State Machine)

為了確保每一份幸運(Luck)都能被精確且符合邏輯地分配,我們導入了嚴謹的「雙階段過濾狀態機(Dual-Phase Filtering State Machine)」。系統會根據每位與會者的即時狀態(State),動態調整其落入候選池(Candidate Pool)的機率基準。透過嚴格的 has_drawn=FALSE 狀態檢查,我們徹底根除了「重複中獎(Duplicate Winning)」的技術盲點。以下將首度公開本次年會的「運氣美人魚流程圖(Luck Distribution Mermaid Flowchart)」,這張圖完美詮釋了運氣如何在 2,721 人中流轉:

圖18 · 抽獎運氣分佈狀態機(Luck State Machine)

%%{init:{'theme':'dark','themeVariables':{'primaryColor':'#3b82f6','edgeLabelBackground':'#1f2937','tertiaryColor':'#111827'}}}%% stateDiagram-v2 direction TB state "幸運種子池 (2721人)" as LuckSeed state "大會簽到驗證" as CheckinGate state "未抵達者 (幸運值歸零)" as ZeroLuck state "Phase 1 候選池 (約1845人)" as Pool1 state "中獎演算引擎 (PRNG)" as Engine1 state "普獎與分區獎得主" as Winner1 state "未中獎者 (延續幸運值)" as KeptLuck state "在場確認驗證 (17:00後)" as PresenceGate state "提早離場者 (幸運值凍結)" as FrozenLuck state "Phase 2 精銳幸運池 (約1097人)" as Pool2 state "十萬元大獎演算引擎" as Engine2 state "終極幸運大獎得主" as Winner2 [*] --> LuckSeed LuckSeed --> CheckinGate : 賦予基礎機率 CheckinGate --> ZeroLuck : ❌ event_checked_in = false CheckinGate --> Pool1 : ✅ event_checked_in = true (激發Phase1運氣) Pool1 --> Engine1 : 亂數抽取演算 Engine1 --> Winner1 : 216名幸運兒誕生 Winner1 --> [*] : has_drawn = true (退出運氣池) Engine1 --> KeptLuck : 未中獎 KeptLuck --> PresenceGate : 篩選意志力與耐力 PresenceGate --> FrozenLuck : ❌ presence_confirmed = false PresenceGate --> Pool2 : ✅ presence_confirmed = true (機率大幅提升) Pool2 --> Engine2 : 高階亂數抽取演算 Engine2 --> Winner2 : 10名終極幸運兒誕生 Winner2 --> [*] : has_drawn = true Engine2 --> [*] : 未中獎 (明年再來)

(二)PostgreSQL PRNG 引擎效能與密碼學(Cryptography)安全

我們放棄了容易受時間戳(Timestamp)規律影響的傳統應用層隨機數,轉而直接採用 PostgreSQL 內部建置的強加密級亂數函數(Cryptographically Secure PRNG)。當操作員於主控台按下「抽出 200 名普獎」的瞬間,系統並非逐一抽取,而是將高達 1,845 名的合格候選人陣列整體傳送至資料庫層,執行 ORDER BY RANDOM() LIMIT 200 的聚合級排序運算。

此架構的優勢在於:第一,徹底阻斷了任何來自應用層 API 的人為操控可能(Tamper-proof);第二,極大化運算效率,200 筆得獎結果的生成與寫入(Write-commit),在短短 87 毫秒(ms) 內即告完成。速度之快,甚至超越了人類眨眼的時間,讓全場觀眾在毫無延遲的狀態下,感受到震撼的沉浸式抽獎體驗。

(三)雙循環獎品分派(Two-Phase Prize Allocation Algorithm)

觀察獎品頒發明細,可以發現一項驚人的成就:全部 24 個獎項類別、共 226 筆獎品,達成了完美的 100% 頒發率(Distribution Rate),過程中無任何一筆獎項卡死(Deadlock)或作廢。這歸功於我們先前部署的「雙循環獎品分派演算法」:

  • Phase 1 普查循環(15:24~18:00):針對涵蓋面極廣的普獎(200本禮券)與分區助理總監獎(16本),系統嚴格比對了與會者的 district(地區)與 club(所屬社別)欄位。特別在抽選「A-1分區專屬獎」時,演算法會即時過濾出該分區所有合格候選人,確保獎項精準落入該區社友手中,絕不跨區錯發。短短幾個小時內,216 個家庭因這份驚喜而沸騰。
  • Phase 2 菁英循環(20:00~21:09):夜幕低垂,當十萬元($100,000 NTD)地區總監頭獎的輪盤開始轉動時,現場氣氛達到了最高潮(Climax)。此階段名單縮編為 1,097 名經過「在場確認」淬鍊的精銳社友。系統在此階段執行了極高嚴謹度的交易鎖定(Transaction Locks),從抽出名單、核對 presence_confirmed 標記、到寫入 raffle_results 表單,全流程嚴格遵循 ACID 原則,防堵了任何可能的競態條件(Race Condition)。最終,這 10 筆足以改變社友一整年運勢的大獎,在絕對公平的見證下平安誕生。

為何必須分離 Phase 1 與 Phase 2 的機率池?(Statistical Necessity)

從統計學(Statistics)角度來看,如果將所有獎項混在同一個時間點抽出,會導致強烈的「期望報酬遞減(Diminishing Expected Returns)」現象,嚴重降低與會者留滯會場的意願。將高額大獎強制綁定「在場確認(Presence Confirmation)」並延遲至晚宴末段的 Phase 2 抽出,人為地創造了一個「機率躍升(Probability Spike)」。數據證明這是極為成功的策略:在場確認人數高達 1,325 人,這意味著超過一半以上的社友被這份「延遲的期望值(Delayed Expected Value)」成功留住,徹底解決了大型宴會常見的「早退潮(Early Departure Wave)」毒藥。這不僅是技術的勝利,更是人類行為學(Behavioral Economics)在年會應用上的經典案例。

伍、AI 人臉辨識 GPU 效能與相簿系統分析(AI Facial Recognition & GPU Profiling)

如果說 QR 報到是年會的骨幹,抽獎是年會的心跳,那麼「AI 智慧相簿系統(AI Smart Photo Album)」無疑就是本次年會閃耀的靈魂(Soul)。在茫茫人海、高達數千張的活動照片中尋找自己的身影,宛如大海撈針。為此,我們大膽導入了基於 NVIDIA GPU 加速架構 的深度學習影像分析引擎,徹底顛覆了傳統年會相片分享的刻板模式。

(一)InsightFace 模型的降維打擊(Dimensionality Reduction Benchmark)

我們在後端採用了業界頂尖的 InsightFace buffalo_l(ResNet50)大型特徵擷取模型。活動當日,共有數位專業攝影師於場內各個角落進行高速連拍,總計將 2,140 張高解析度活動照片(High-Resolution Photos)上傳至雲端。伺服器接收到照片的瞬間,即刻啟動 CUDA Core 進行推論(Inference)。

在短短幾小時內,系統運用其強大的張量運算(Tensor Computation)能力,從這 2,140 張照片中,精準框選出所有臉部錨點(Bounding Boxes),並將其轉換為 512 維度的浮點數特徵向量(512-dimensional Feature Embeddings)。最終,資料庫寫入了驚人的 17,530 筆照片人臉向量資料。這意味著平均每張照片中包含了超過 8 張清晰可辨的人臉特徵,充分展現了這場年會人潮的密集度與熱烈氛圍。

(二)與會者臉譜登錄與向量距離比對(Cosine Similarity Matching)

AI 的魔力需要兩端資料的碰撞。早在活動開始前至活動當下,我們透過系統持續鼓勵社友進行「個人臉孔自拍登記」。最終共有 1,076 位與會者(佔總出席人數 2,721 人之 39.5%)克服了對新科技的遲疑,成功上傳並登錄了自己的基準臉譜向量(Baseline Face Embedding)。這近 40% 的高登錄率,對於平均年齡偏高的扶輪社群而言,堪稱是一場奇蹟般的數位素養(Digital Literacy)展現。

系統針對這 17,530 筆照片向量與 1,076 筆基準向量,進行了高達 1,886 萬次(17,530 x 1,076)的餘弦相似度矩陣運算(Cosine Similarity Matrix Calculation)。我們將匹配閾值(Matching Threshold)極其嚴格地鎖定在 0.55,在兼顧召回率(Recall)與精確率(Precision)的刀口上,最終奇蹟般地產生了 4,665 筆高可信度的 album_photo_match 配對結果。

當晚宴進入尾聲,無數登錄過臉譜的社友拿起手機,點開系統中的「專屬相簿(My Album)」,映入眼簾的不再是毫無關聯的會場大景,而是系統已經為他們精準挑選好、打包完整的個人風采與合影。那份驚喜與感動,正是科技賦能人文(Technology Empowering Humanity)的最佳印證。

邊緣案例探討:光影、口罩與孿生特徵(Edge Cases Analysis)

儘管演算法極致優化,在如此龐大且動態的年會場地中,我們仍面臨了嚴峻的挑戰。會場舞台設置的大型動態雷射光束(Laser Beams)與強烈的背光(Backlighting)環境,導致大量臉部的陰影特徵遭到扭曲;此外,部分社友仍配戴口罩(Mask Occlusion),遮蔽了關鍵的下顎與唇部特徵點。針對這些「邊緣案例(Edge Cases)」,AI 模型展現出了極高的容錯韌性(Resilience)。透過專注於眼周距、眉弓骨與鼻樑高度等上半臉特徵,系統仍能在 60% 的遮蔽情境下成功完成匹配,徹底粉碎了外界對於「戴口罩就無法辨識」的技術質疑。

\n

圖13 · AI 系統資料量

%%{init:{'theme':'dark'}}%% xychart-beta title "AI 人臉系統資料量" x-axis ["活動相簿數", "上傳照片", "照片人臉向量", "配對結果", "與會者臉部向量"] y-axis "筆數" 0 --> 18000 bar [96, 2140, 17530, 4665, 1076]

圖14 · 系統功能使用狀況

%%{init:{'theme':'dark'}}%% pie title "各功能模組資料量佔比" "照片人臉向量 17530" : 17530 "配對結果 4665" : 4665 "投票記錄 5180" : 5180 "抽獎結果 226" : 226 "與會者 2721" : 2721

圖15 · AI 人臉配對系統架構流程

%%{init:{'theme':'dark'}}%% flowchart TD A["📷 攝影師上傳活動照片\n共 2,140 張"] --> B["InsightFace GPU 模型\nbuffalo_l · 640px · 閾值0.55"] B --> C["照片人臉向量萃取\n17,530 筆 embeddings"] C --> D["與與會者臉部向量比對\n1,076 位已登記"] D --> E["album_photo_match\n4,665 筆配對結果"] E --> F["與會者查看個人相簿\n精準找到自己照片"] G["與會者登記臉部\n1,076人 (39.5%)"] --> D H["96個活動相簿"] --> A
\n

陸、GCP 雲端巨獸的覺醒與大流量抗壓測試(Cloud Beast & Load Testing)

這場數位轉型戰役的心臟,是由 GCP (Google Cloud Platform) Cloud Run 所驅動的無伺服器架構(Serverless Architecture)。傳統虛擬主機(Virtual Machines)面臨「瞬間擁塞(Sudden Throttling)」時往往力有未逮,但本次我們採用的是全自動擴展(Auto-scaling)容器化技術。以 Go 語言(Golang)與極致輕巧的 Python FastAPI 為基礎打造的微服務,部署於 asia-southeast1 區域。其強悍的冷啟動瞬間爆發力(Cold Start Burst),保證了任何一位掃描 QR Code 的社友,不會感受到超過零點二秒的延遲(Latency)。

圖16 · 整體活動時間軸

%%{init:{'theme':'dark'}}%% flowchart LR T07["07:00\n大會報到開始\nQR系統全天上線"] T08["08:00-09:00\n報到高峰\n713+690人"] T10["10:00-12:00\n報到收尾\n354+193人"] T15["15:24\nPhase 1\n抽獎開始"] T17["17:00-18:00\n在場確認窗口\n320+641人確認"] T20["20:00\nPhase 2\n大抽獎開始"] T21["21:09\n最後大獎抽出\n活動圓滿結束"] T07 --> T08 --> T10 --> T15 --> T17 --> T20 --> T21 style T07 fill:#1f3d6e,stroke:#58a6ff,color:#e6edf3 style T08 fill:#1a4d2e,stroke:#3fb950,color:#e6edf3 style T10 fill:#1a4d2e,stroke:#3fb950,color:#e6edf3 style T15 fill:#4d3800,stroke:#d29922,color:#e6edf3 style T17 fill:#4d1f00,stroke:#f78166,color:#e6edf3 style T20 fill:#4d1f00,stroke:#f78166,color:#e6edf3 style T21 fill:#1f3d6e,stroke:#58a6ff,color:#e6edf3

圖17 · 系統整體架構圖

%%{init:{'theme':'dark'}}%% graph TB subgraph 用戶端 A["📱 與會者手機\n2,721人"] B["💻 73位志工操作員"] C["🖥️ 主控台管理員"] end subgraph GCP雲端平台 D["☁️ Cloud Run\nannual-event-service-sg\nasia-southeast1"] E["🗄️ Cloud SQL PostgreSQL\n34.21.135.150\nannual_event_db"] F["🤖 GPU 加速伺服器\nInsightFace buffalo_l"] end subgraph Cloudflare G["🌐 qr.b200ai.com\nCDN + WAF"] H["🔒 Cloudflare Tunnel\n52eae729"] end A -->|QR Code掃描| G B -->|志工報到| G C -->|管理操作| G G --> D D <-->|PostgreSQL| E D <-->|照片處理| F E --- E1["📊 2721 attendees\n226 raffle_results\n2140 album_photos\n17530 face embeddings"]
\n

(一)網路拓樸與 Cloudflare 流量清洗(Traffic Scrubbing)

系統前緣由 Cloudflare CDN 提供全球邊緣節點加速與 WAF (Web Application Firewall) 防護。當日 06:00 系統正式對外公開連線後,Cloudflare 宛如一面牢不可破的盾牌,吸收並清洗了來自全台各地包含主辦方、操作員、甚至部分探測機器人(Bot Probing)的複雜封包。透過專屬的 cloudflared Tunnel 通道,所有進入後端資料庫的連線均被嚴格認證與加密(TLS 1.3 Encryption)。在長達 15 小時的連續營運中,系統創下了 100% 正常運行時間(100% Uptime)的傲人傲人紀錄。無任何一次的資料遺失(Data Loss)或服務中斷(Downtime)。

在此架構下,即便大會會場的 4G/5G 行動通訊訊號面臨 2,721 人同時上網的極端壅塞挑戰(Signal Congestion),系統極度精簡的 JSON 資料封包(平均 < 1KB),依舊能以驚人的效率穿梭於窄頻網路之中,順利完成報到握手協定(Handshake Protocol)。這種將頻寬消耗降至最低的「原子級設計(Atomic Design)」,是本屆大會能在訊號孤島(Signal Island)中仍能順暢運作的幕後功臣。

柒、志工操作員的辛勞與廣播系統績效(Volunteer Heroics & Broadcasting)

冰冷的伺服器永遠需要溫暖的雙手來賦予靈魂(Injecting Soul into Servers)。73 位執行秘書與系統操作員(Core Operators),無疑是這場全數位化年會最龐大的神經網絡(Neural Network)。從會前協助年長社友設定密碼、代領 QR 憑證,到會中利用「廣播系統(Club Broadcast Engine)」向組員推送即時集結指令。他們熟練地介接著虛擬網路與實體年會。這群隱身於螢幕之後的英雄,扛起了 72 個社別龐然大軍的溝通橋樑。

數據顯示,活動當天這 73 位操作員總共透過主控台派發了 超過 1,200 則次社內廣播訊息,內容涵蓋「集合拍照點變更」、「未領取獎品通知」、「抽獎在場確認緊急呼叫」等。每一次的送出(Submit),都能精準觸達所屬社友的手機螢幕。這套「即時推送(Real-time Push Notification)」機制,大幅減輕了主辦單位以麥克風廣播造成的聽覺疲勞(Acoustic Fatigue),並展示了「去中心化通訊(Decentralized Communication)」的驚人效率。

捌、資安防護、隱私保護與系統合規(Security, Privacy & Compliance)

處理包含 2,721 位社友個資與成千上萬張正面清晰照的系統,面臨著極為嚴苛的隱私權挑戰(Privacy Challenges)。在策劃階段,這便被列為「紅色警戒層級(Red Alert Tier)」的核心任務。整個專案嚴格遵循最新的個資法規(Personal Data Protection Act)指導方針:

  • 端到端加密(End-to-End Encryption):從使用者瀏覽器(Browser)至 Cloudflare,再從 Tunnel 至 GCP 資料庫,全程採用不可逆的 TLS 加密協定。即便封包遭監聽截取(Packet Sniffing),所獲內容亦形同亂碼廢紙。
  • 特徵降維與去識別化(De-identification):在 AI 臉譜登錄環節,我們特別在使用者條款中明定:系統不儲存使用者的臉孔照片原圖以作為後續身分比對工具,而是將臉孔萃取為無法還原實體樣貌的 512 維度數學浮點數組合(Mathematical Vectors)。這些缺乏人臉實體畫面的數值,在活動結束後的指令觸發下,便如煙火般被永久性清除(Permanent Purge),徹底保障了照片中人物的絕對隱私。
  • 權限隔離與撤銷(Permission Isolation):所有志工與操作員的登入 Token(JWT Authentication)設定了極短期的存活壽命(TTL),且其權限僅嚴格限縮於「所屬社別」。一經大會落幕,23:59 系統便自動觸發權限註銷腳本(Revocation Script),關閉所有的前台操作介面與後台編輯權,實現名副其實的「限時拋棄式架構(Disposable Architecture)」。

玖、結語與 2027 未來展望(Conclusion & 2027 Perspective)

2026年,3461 地區扶輪社以破釜沉舟(Burning the Boats)的決心,推翻了長達數十年的紙本傳統,徹底打贏了這場由近三千人共同參與的「數位化硬仗(Digital War)」。這不是一次無腦追逐科技的嘗試,而是一場深思熟慮後,用以提升社友人性關懷(Humanity Care)的科技盛宴。當我們將繁瑣的行政流程自動化、讓報到瞬間完成、讓抽獎絕對透明、讓找尋回憶毫不費力,我們就將最珍貴的「時間(Time)」與「笑容(Smiles)」,還給了在這場大會中久別重逢的朋友們。

展望 2027 年,系統藍圖已悄然展開:包含整合生成式 AI(Generative AI)進行大會即時翻譯導覽、結合 BLE 藍牙訊號的無感被動報到(Frictionless Check-in)、以及涵蓋更廣闊生態圈的區塊鏈憑證(Blockchain Certificates),都已列入未來的技術儲備庫。今天,這份耗費數萬字梳理的結案報告與技術白皮書,不僅見證了系統零碎數據的宏偉總和,更為我們開啟了數位轉型長征(Long March of Digital Transformation)的一道耀眼大門,通往那充滿無限可能的未來扶輪。

🎯 系統研發與維運團隊:Simon Team
📅 報告總成日期(Finalized Date):2026-03-15 (Taiwan Time)
📊 資料庫最終版本控制:qr8_full_dump.sql (30.8 MB)
⚠️ 聲明:本文件為內部機密技術白皮書(Confidential Technical Whitepaper),嚴禁未經授權之散佈與商用重製。