- 為什麼要本機
- 題目是學生的資料，我不想送進別人的伺服器；而且我希望這套系統能離線用、零邊際成本。所以 AI 步驟全部改成在自己的電腦上跑：Ollama 的 qwen3 系列加 PaddleOCR。硬體是純 CPU、只有內顯、16 GB RAM。
- 量出來的數字
- 原本的設計是「看圖拆題」與「OCR 拆題」兩條路互相比對。我實際量了看圖那條：
qwen3-vl:8b讀 1 頁 200 DPI 的樣卷，模型載入 1 分 18 秒、讀 prompt（6,248 token）23 分 32 秒、輸出（1,786 token）28 分 40 秒，合計 54 分鐘，而且輸出的 JSON 不合法。一份四頁的卷光看圖就要三個半小時以上。對照：文字模型輸出約每秒 2 個 token，PaddleOCR 整份樣卷一頁約 4 分鐘。 - 決定
- 這台電腦的拆題改成以 OCR 為主：不看圖，只用 PaddleOCR 加文字模型整理。代價寫清楚——沒有第二條路可以互相比對，所以每一題都要人工確認才入庫；附圖位置抓不到的另外用補圖工具處理。這不是功能沒做完，是在這個硬體上唯一誠實的選擇。
- 順便修掉一個低估
- 整理這些數字時我發現先前的估算把「部分快取命中」的讀取速度當成冷啟動速度，於是改用只推冷呼叫的方法重量（約每秒 8 個 token，而不是原先寫的 17），並重算所有受影響的估計。一份十題卷的分類、公式檢查、驗算合計從原本寫的「3 分半到 2 小時 25 分」修正成 41 分鐘到 3 小時。把自己的估算改大，比讓它看起來漂亮重要。
- 慢的只有一次
- 這個取捨之所以可以接受，是因為慢的只有入庫那一次。日常使用的查題、相似題、組卷、匯出 Word、記錄作答、批改、錯題重練、補救卷與學習報告全部不呼叫 LLM，是即時的。向量也刻意選了輸出 768 維的本機嵌入模型，與原本的雲端模型相同，所以資料表不用改。
- 邊界
- 相似題的覆蓋率在本機嵌入模型下明顯較低（門檻設 0.47，雲端模型那組是 0.8367）。我選擇以相似題的精準度為優先，覆蓋率靠擴充題庫提高，不靠調低相似度下限——後者只會讓不相似的題被當成相似題。AI 助教在這個硬體上也還太慢，那一項我直接擱置到硬體升級，而不是換更小的模型硬撐。
這篇筆記的實際應用
教學出卷助手
把散落在考卷裡的題目，變成能依學生需求組卷的題庫。
看個案研究 →