鞋底防滑 AI 檢測系統

交付驗收入口 — 消費者 · 鞋廠 · 後台 ＋ 雙層 AI

拍三張鞋底照 → AI 估算乾／濕摩擦力（COF）＋ 防滑等級 ＋ AI 白話建議。本頁含「研究·訓練歷程」一頁頁簡報、三角色平台入口與用戶路徑測試。每個功能都標明「怎麼走、做什麼、該看到什麼」。

📅 更新日期 2026-07-02 🟢 正式站已上線（貴公司 GX10 地端 · 24 小時運行）· v1
🟢 正式環境（貴公司 GX10 地端）· 已上線
整套系統運行於貴公司機房的 NVIDIA GX10：真實 CV 模型 ＋ 自架語言模型（gemma4:26b，非外部 API），24 小時運行（always-on）、開機自動恢復、資料全留地端不出雲。固定網址 gx10.ai-cto.app，可多人同時使用。
⚙️ 雲端測試站（RunPod GPU · 內測）· 已完成階段任務
內測階段用的雲端 GPU 測試站已完成使命；展示與驗收一律改走左邊的地端正式站（同一套系統、同一批模型，資料不再經過任何雲端）。

正式站狀態

🖥️ 地端正式站 — 24 小時運行，隨開隨用

系統跑在貴公司機房的 GX10 上，不需要開機、關機或任何操作 —— 隨時打開下方入口就能用。這裡即時顯示正式站目前的服務狀態。

狀態：查詢中…
此狀態由本頁直接向正式站健康檢查（gx10.ai-cto.app/healthz）即時查詢，非人工填寫。若顯示連線失敗，請聯絡 AI-CTO。
📦 這次交付了什麼

機器學習開發歷程

🔬 影像辨識模型是怎麼做出來的

本系統的影像辨識模型，係以貴公司提供的真實檢測資料訓練而成。以下以 ◀ ▶ 逐頁說明：資料的實際狀況、開發過程中採用的方法與理由、各方法的成效，以及目前模型的能力邊界，供完整了解全貌。

鞋底防滑檢測 · 機器學習開發歷程
封面

把一張鞋底照片，變成防滑安全分數

問題 ＋ 我們要做的事

問題：鞋底磨損肉眼難判斷，濕滑跌倒是真實風險；實驗室 ASTM 摩擦試驗準，但慢、貴、要送驗。

我們要做的：讓消費者拍三張鞋底照，就能得到乾／濕摩擦係數（COF）＋ 防滑等級 ＋ 白話建議；鞋廠／實驗室用同一套快速初篩。

L1
電腦視覺模型
照片 → COF 數字
L2
本地 LLM
數字 → 繁中報告
3 角色
消費者 · 鞋廠 · 後台
01 · 資料

訓練資料的實際狀況

貴公司提供之首批訓練資料

41 雙鞋
每雙 ~60 張整底各角度照
2,480 張
手持照（辦公室／實驗室背景）
32 份
附 ASTM 正式檢測報告（PDF）
  • 其中 32 雙附 ASTM F2913 正式檢測報告；另 9 雙僅有照片、無對應報告（無標籤，本次未納入訓練）。
  • 涵蓋 11 家鞋廠、材質含橡膠（NR）／EVA／TPR／TPE／PU。
  • 照片為「整個鞋底各角度的手持照」、背景較雜亂 —— 此特性與後續方法選擇相關。
02 · 標籤

標籤是金級的，但鎖在 PDF 裡

ASTM F2913:2011 摩擦係數試驗

每份報告含 前掌 / 後跟 / 水平 × 乾 / 濕 共 6 個 COF 值。COF 已是 0–1 量級（濕式 0.30–0.86），剛好對齊模型輸出。

  • PDF 無文字層（純影像）→ 用視覺萃取數字。
  • 用報告第 3 頁「個別量測值」的平均，逐格交叉驗證 → 32 份全部對得上（誤差僅四捨五入）。
  • 抽驗數值較特殊者（如某粗跟女鞋後跟乾式僅 0.34）→ 比對照片確認屬實（粗跟為光滑硬質、抓地力低），非萃取錯誤。
標籤品質高（實驗室正式報告）。主要限制不在資料準確度，而在樣本數量 —— 見下一頁。
03 · 資料探勘

資料探勘：四項關鍵議題

這四點決定了後續的模型方法

  • ① 樣本數量有限：僅 32 雙具標籤（一般期望數百至千筆）→ v1 定位為諮詢級估算工具，需採嚴謹的分組驗證。
  • ② 照片型態與原規劃不同：實際為「整底多角度照」，非乾淨的前掌／後跟／全底分區照。
  • ③ 樣本皆為新鞋：32 雙均為工廠新品 → 「建議更換」等級 0 筆；而消費者情境多為磨損舊鞋。
  • ④ 乾式 COF 常 >1.0：超出模型輸出範圍 → 訓練時壓縮、推論時還原（濕式皆在範圍內，無此問題）。
04 · 模型方法

模型方法：聚焦於「整底 → 兩個數值」

輸出定為整體乾／濕兩個 COF

  • 單張整底照（＋材質）→ 整體 (cof_wet, cof_dry)，暫不做分區輸出（現有資料量不足以支撐）。
  • 採用凍結的 ConvNeXt-Tiny 作為特徵抽取器 ＋ 小型分類層。
    （若完整微調 2,800 萬參數對應 32 筆資料，將過度擬合、退化為「永遠輸出平均值」。）
  • 對外資料介面維持不變：產品端仍上傳 3 張分區照，推論時各推一次、以固定權重（前掌 0.30／後跟 0.40／全底 0.30）組成整體，前端／語言模型／API 皆無需調整。
05 · 方法一

方法一：移除背景雜訊（去背）

原始照片背景雜亂，會干擾模型判讀

導入去背處理（rembg / u2net），將鞋底自辦公室／實驗室背景中分離、其餘區域填白，使模型專注於鞋底本身的紋路與磨耗。

原始（含背景）R² 0.07
去背後R² 0.18

導入此方法後，濕式 32 折交叉驗證 R² 由 0.07 提升至 0.18。

06 · 方法二

方法二：分區放大（前中後三段）

檢測報告原本即以前掌／後跟分區量測

在去背後，沿鞋底長軸切分為前／中／後三段並各自放大，一併輸入模型。此作法等同提高有效解析度，也對應檢測報告原本以分區方式量測的特性。

去背R² 0.18
去背 ＋ 三段放大R² 0.32

加入分區放大後，R² 由 0.18 進一步提升至 0.32。

06.5 · 延伸嘗試

還試了什麼：多切區塊 ＋ 二值化

兩個常見的前處理改法，都用 32 折交叉驗證嚴謹實測

試法相對出貨版判讀
三段放大（出貨版）基準穩定、已採用
多切左右／內外側（6 區塊）時好時壞（±0.10）邊際且不穩，落在統計噪音裡
二值化（黑白化紋路）中性～偏差丟掉自然紋理 → 預訓練模型反而變差
多切 ＋ 二值化崩潰離域 × 高維 → 過度擬合
📌 這兩個改法的差異都小於方法本身的統計噪音 —— 這是一個實證結論：目前模型是「資料受限」，不是「切法／前處理受限」。把準度真正拉上去的唯一大槓桿，是累積更多穿過、磨損過的鞋的資料。
07 · 成效驗證

嚴謹的驗證方法：32 折交叉驗證（LOSO）

Leave-One-Shoe-Out 留一雙鞋交叉驗證

  • 為何採留一雙鞋：同一雙鞋的多張照片若同時出現在訓練與驗證，會造成資料洩漏、評估虛高。改以鞋為單位分組、每次保留一整雙作驗證、輪替 32 次，數字才具參考性。
  • 完整微調為何失敗：2,800 萬參數對應 32 個獨立標籤 → 過度擬合至「永遠輸出平均值」，R² 為 −1.6（低於直接猜平均）。凍結特徵抽取層後，模型才會真正隨輸入變化。
  • 解析度測試：224 與 384 像素的濕式 R² 僅差約 0.04，影像壓縮對成效影響有限。
08 · 結果

成效驗證結果

逐步逼近資料可支撐的上限（以 32 折交叉驗證濕式 R² 為準）

方法R²（濕式）平均誤差 MAE
完整微調−1.6—（退化為平均值）
凍結特徵層0.070.065
＋ 去背0.180.056
＋ 分區放大（出貨版）~0.320.054

出貨版以全 32 雙資料訓練（泛化能力已由 32 折交叉驗證估算）；模型版本 cv-convnext_tiny-v1，濕式平均誤差 MAE ≈ 0.054。

09 · 第二層

第二層：本地語言模型生成中文報告

模型預測值 → 本地語言模型（gemma4:26b）→ 繁體中文三段報告

摩擦係數數值對一般使用者較不直觀。第二層將數值交由本地大型語言模型（gemma4:26b，全程於機器內運算、不經外部雲端，約 7–14 秒），生成「整體評估／具體分析／建議行動」三段易讀報告。

「根據您提供的檢測數據，目前的評估結果為 安全（Safe），鞋底摩擦力表現尚在穩定範圍內⋯⋯前掌與後跟的濕地摩擦係數分別為 0.539 與 0.542，兩者差異極小且均維持在安全等級⋯⋯可以繼續放心穿著，但建議留意鞋底紋路是否因長期使用而變平。」
— 模型對某橡膠涼鞋樣本的實際輸出（節錄）
10 · 結論

結論：資料量是目前的主要限制

v1 為諮詢級估算工具，非安全保證

  • v1 已能穩定運作、輸出隨輸入變化、優於基準（猜平均值），足以支撐系統上線並啟動資料累積循環。
  • 目前 R²~0.32（約解釋三分之一的變異）。此為 32 雙新鞋樣本下的上限，而非模型架構限制（已測試多種架構）。
  • 提升準確度的關鍵在於資料 —— 尤其磨損舊鞋／低摩擦係數／「建議更換」等級樣本（目前為 0 筆）。
🔁 資料累積循環：每批新資料 → 增量訓練 → 模型更準確 → 更多使用 → 更多資料。第一版的核心價值，在於啟動此循環。

方法說明 — 安全分級

🎚️ 防滑安全分級標準

模型估出濕地摩擦係數（COF）後，依下表切成三級。門檻對齊 ASTM F3445「SR 防滑」合格線（＝與貴公司 FRT 檢測報告同一套 ASTM F2913 整鞋測法），非任意訂定。

濕地 COF消費者端協場端評級說明
≥ 0.40🟢 安全A防滑達合格，可繼續穿
0.30 – 0.40🟡 注意B防滑邊際，濕滑地面留意
< 0.30🔴 請換鞋C防滑不足，建議更換
安全線 0.40
ASTM F3445「SR 防滑」乾／濕合格門檻；與貴司 FRT 報告同一套 ASTM F2913 測法。佐證：人在地面 DCOF＜0.41 開始改變步態、NFSI 濕地板可接受線 0.42。
危險線 0.30
公認高滑倒風險線：NFSI 濕地板高風險、SATRA「正常走路下限」、生物力學走路所需摩擦係數約 0.20 之上保留安全餘裕。
為何以「濕地」為主
消費者最危險的情境是下雨／潮濕地面，故以濕地 COF 為主要分級基準（乾地另計、非風險主因）。
⚖️ COF 數字與測試表面／介質綁定、不可跨方法直接比較。我們將切點錨在同測法的 ASTM F3445；精確切點可再與貴公司對齊 FRT 報告的測試表面／介質條件後微調（程式單一處即可生效）。

Step 1 — 取得入口

🚪 三角色平台入口

三個角色、同一套後端，跑在貴公司 GX10 地端正式站（24 小時運行），固定網址 gx10.ai-cto.app。消費者走 LINE（掃官方帳號 → 選單）；鞋廠／後台用電腦開網址、帳密登入。

📱

消費者 · LINE

手機 LINE 掃描下方 QR → 加入官方帳號 → 由選單「開始檢測」進入 LIFF

正式站 LINE 官方帳號 @062dlfjq QR Code

🟢 正式站@062dlfjq

測試站 LINE 官方帳號 @223qfcmm QR Code

⚙️ 測試站@223qfcmm

能做什麼
  • 拍／傳三張鞋底照（前掌／後跟／全底）
  • 看防滑分數 ＋ 等級 ＋ 磨耗熱圖
  • 本地語言模型白話建議
  • 歷史檢測紀錄
🏭

鞋廠 · 研發工作台

電腦瀏覽器開網址 → 帳密登入

開啟鞋廠工作台

https://gx10.ai-cto.app/vendor

種子帳號
帳號 vendor@example.test
密碼 Test1234!
能做什麼
  • 上傳鞋款送驗（材質 ＋ 型號 ＋ 樣本標籤）
  • COF／等級／熱圖／模型解讀
  • 歷史款比對（研發資料庫）
  • 跨公司資料隔離
🛠️

後台 · 管理端

電腦瀏覽器開網址 → 帳密登入

開啟後台管理

https://gx10.ai-cto.app/admin

種子帳號
管理員 admin@shoetec.test
唯讀 readonly@shoetec.test
密碼 Test1234!
能做什麼
  • 系統儀表板（用戶／檢測量／服務健康）
  • 模型版本管理（CV ＋ LLM）
  • 用戶紀錄、系統紀錄（審計）
  • 角色權限（管理員可寫／唯讀可讀）

Step 2 — 跟著走一遍

⭐ 角色用戶路徑測試

下面三幕是「同一筆檢測」從消費者上傳、到鞋廠研發、到後台監看的完整流程。標注 前後台聯動 的地方，前台一動、後台同步出現。

💡 建議方式：一支手機（LINE 掃官方帳號扮消費者）＋ 一台電腦（開鞋廠工作台 / 後台）。先用消費者端上傳三張鞋底照、看報告，再到後台看這筆檢測進了統計、模型版本是哪一版。
消費者上傳鞋底照→ CV 模型 + 本地 LLM→ 看分數 / 熱圖 / 報告→ 後台統計 + 模型版本
1

消費者：上傳鞋底照、拿報告

消費者

做什麼

  1. 手機 LINE 掃描官方帳號 QR → 加入好友 → 由選單開啟檢測
  2. 依指引拍／選三張鞋底照（前掌／後跟／全底），可選材質
  3. 送出 → 等 AI 運算（影像模型 + 本地語言模型）
✅ 該看到乾／濕 COF 兩個分數 ＋ 防滑等級（安全／注意／建議換鞋）＋ 磨耗熱圖 ＋ 一段繁中換鞋建議；回首頁可在「最近一次結果」看到它，歷史頁也有。
🔎 前後台聯動後台「系統儀表板」的「今日檢測次數」會 +1；這筆會進「近 7 日檢測量」。
2

鞋廠：送驗鞋款、比對歷史

鞋廠

做什麼

  1. 用 vendor@example.test / Test1234! 登入鞋廠工作台
  2. 「上傳檢測」→ 傳三張鞋底照 ＋ 選材質 ＋ 填鞋款型號 ＋ 樣本標籤 → 開始預測
  3. 看結果頁；再到「歷史款比對」看研發資料庫
✅ 該看到結果頁含精確 COF（兩位小數）＋ 綜合防滑評級（A/B/C）＋ 磨耗熱圖（去背鞋底原比例、半透明疊）＋ 模型解讀（鞋底老師傅口吻）＋「CV 模型 v1」；歷史頁列出本公司送驗鞋款。
🔎 資料隔離每家鞋廠只看得到自己的資料（跨公司存取會被擋）。
3

後台：監看系統與模型版本

管理員

做什麼

  1. 用 admin@shoetec.test / Test1234! 登入後台
  2. 看「系統儀表板」：總用戶、今日檢測、近 7 日量、服務健康狀態
  3. 進「模型版本」：看現在啟用的 CV 模型與本地 LLM
✅ 該看到服務健康：主 API / CV 推理 / 本地 LLM / 資料庫 = 正常；模型版本頁顯示 CV 模型 friction-cv v1（驗證 MAE 0.054） ＋ 本地 LLM gemma4 26B。
🔎 權限用唯讀帳號 readonly@shoetec.test 登入 → 看得到資料、但寫入動作（如切換模型）被擋。

底層怎麼運作

🧠 前端 / 後端 · AI 管線總覽

一筆檢測從上傳到報告，會經過這幾關。CV 推理與自架 LLM 跑的是真實模型（非假資料）。

📤
上傳三張照
消費者／鞋廠送出前掌·後跟·全底鞋底照
前端 → API
→
👁️
CV 推理（ml-infer）
去背 → 切三段 → ConvNeXt 模型 → 乾／濕 COF ＋ 等級 ＋ 遮擋顯著性熱圖
真實模型 v1
→
💬
自架 LLM（Ollama）
把 COF 數字 ＋ 鞋款資訊 → 繁中三段「鞋底老師傅」口吻報告
gemma4:26b · 自架
→
📄
報告呈現
前台看分數／熱圖／報告；後台進統計
DONE
🔒
資料全留地端、不出雲：正式站（貴公司 GX10）的影像辨識與語言模型皆於機房內運算、不傳送任何第三方雲端。內測階段暫借雲端 GPU 的做法已結束 —— 現在每一筆檢測都在貴公司自己的機器上完成。

系統韌性 — 多人同時測

🔬 多人同時使用壓力測試

針對「多位使用者同時檢測時，自架語言模型（Ollama gemma4:26b）扛不扛得住」做的實測。並發 1／2／4／8，每並發連續 12 筆約 250 字報告。

同時人數吞吐（req/s）生成速度（tok/s）回應中位數 p5095% 內 p95錯誤
1 人0.20745.0s5.4s0
2 人0.301106.4s8.5s0
4 人0.391488.7s14.7s0
8 人0.3613516.5s25.4s0
全程 0 錯誤
1～8 人同時，沒有任何一筆失敗、沒有卡死；服務健康檢查全程正常。
吞吐到 4 人約 2×
並發吞吐到 4 人約為單人的兩倍後飽和（對應同時處理 3 路的設定），再往上是排隊、不是失敗。
結論：綽綽有餘
Shoetec 實際情境（幾個人同時出報告）自架 Ollama 完全 hold 得住，不需要換更重的推理框架。
✅ 回應時間會隨同時人數線性拉長（單人約 5 秒、8 人同時約 25 秒內），但不掉封包、不出錯。這是「排隊等一下」而非「當機」—— 對這類檢測工具是完全可接受的行為。

現況

📊 示範數據 · 後續事項 · 重要說明

3 角色平台
消費者 / 鞋廠 / 後台
32 雙
附 ASTM 報告的訓練鞋款
R² 0.32
濕式 32 折 LOSO（v1）
~10 秒
一筆端到端（CV＋LLM）
項目狀態說明
三角色平台 ＋ 端到端已完成本地 Demo 已可走完整流程
L1 真實 CV 模型 v1已完成去背＋三 crop，濕式 R²~0.32
L2 本地 LLM 報告已完成gemma4:26b 繁中三段報告
正式環境（貴公司 GX10 地端）已上線24 小時運行、開機自動恢復；入口見本頁上方
補訓練資料（磨損鞋／低 COF）進行中提升準度的唯一槓桿（見下）
英文報告 ／ 多模態（圖文一起餵 LLM）規劃中v2 範圍
⚠️
重要說明：v1 是「諮詢級估算器」，不是安全保證。它從 32 雙全新鞋學成，沒見過磨損舊鞋與「該換」等級，準度天花板被資料量框住（濕式 R²~0.32）。要變準，真正的槓桿是資料，不是模型 —— 補更多鞋（尤其磨損／低 COF）就能透過資料累積循環持續優化。這也正是這套系統的長線價值。