AI 工程從零開始｜Phase 5 Part 1：NLP 基礎 — 文字是智慧的介面

June 21, 2026 • 23 min read • Yen

AI NLP Word2Vec Text Classification Embeddings TF-IDF RKK Interview

大多數人處理文字時，直接把原始字串丟進模型，期待魔法發生。 正確做法是：先理解文字的統計結構，再選擇適合問題規模的表示法。 詞袋夠用的場景別用嵌入；嵌入必要的場景別省那筆運算。 表示法的選擇，決定了整個 NLP 系統 70% 的天花板。

面試情境

你被指派設計一個電商評論分析系統：每天新增 50 萬則中文評論，需支援情感分類（正/負/中性）、主題抽取（5 大類）、以及即時關鍵詞搜尋。系統目前是 POC 階段，但六個月後要上線服務百萬用戶。請說明你的 NLP 文字表示策略，以及各階段如何演進。

一、核心問題：文字為什麼難處理？

文字是人類智慧的介面，卻是機器最難消化的資料形式。數字有大小關係，圖片有空間結構，文字呢？「蘋果」和「apple」語義相同，但在字元層面毫無關聯；「我愛你」和「你愛我」詞彙完全相同，語義卻截然不同。

三個根本挑戰：

稀疏性問題：一個詞彙表有 10 萬個詞，one-hot 向量就是 100,000 維的稀疏向量，99.999% 的維度是 0。相似度計算毫無意義。
語序問題：詞袋模型把「貓追狗」和「狗追貓」視為完全相同的文件。語序攜帶了大量語義資訊。
語境問題：「蘋果很好吃」和「蘋果發布新品」中，「蘋果」的語義完全不同。靜態嵌入無法處理這種多義性。

工程師的決策框架：

問題規模 × 語義複雜度 → 選擇表示法
─────────────────────────────────────────────────
規模小 + 語義簡單   → TF-IDF + 邏輯回歸        (< 1ms, 低成本)
規模中 + 語義中等   → Word2Vec/FastText + SVM    (< 5ms, 中成本)
規模大 + 語義複雜   → Transformer Embedding      (10-50ms, 高成本)
─────────────────────────────────────────────────

這篇文章的目標：讓你在面試中能清楚說明為什麼在特定場景選擇特定表示法，而不只是背誦演算法。

二、三個演進階段

╔══ Phase 1：POC（< 10K 用戶，< 5 萬則評論）══╗

目標：2 週內驗證可行性，準確率 > 75% 即可。

┌───────────────────────────────────────────────┐
│              POC 架構                          │
│                                               │
│  原始評論                                      │
│     │                                         │
│     ▼                                         │
│  ┌──────────────┐                             │
│  │  基礎前處理   │  繁簡轉換 + 分詞(jieba)     │
│  └──────┬───────┘                             │
│         │                                     │
│         ▼                                     │
│  ┌──────────────┐                             │
│  │  TF-IDF 向量化│  sklearn TfidfVectorizer    │
│  └──────┬───────┘  max_features=5000          │
│         │                                     │
│         ▼                                     │
│  ┌──────────────┐                             │
│  │  邏輯回歸    │  C=1.0, max_iter=200         │
│  └──────┬───────┘                             │
│         │                                     │
│         ▼                                     │
│    情感分類結果                                │
│  (Accuracy ~78%)                              │
└───────────────────────────────────────────────┘

新增元件：jieba 分詞、sklearn TF-IDF、邏輯回歸
成本：~$0（本機運行），訓練時間 < 30 秒
解決了：快速驗證資料品質、建立 baseline
未解決：泛化能力弱、無法處理新詞/錯字、語義理解差

╔══ Phase 2：MVP（10K–200K 用戶，50 萬則評論）══╗

目標：準確率 > 85%，P99 延遲 < 20ms，支援即時推論。

┌─────────────────────────────────────────────────────┐
│                  MVP 架構                            │
│                                                     │
│  原始評論                                            │
│     │                                               │
│     ▼                                               │
│  ┌──────────────────┐                               │
│  │  增強前處理管線   │  正規化 + 停用詞 + N-gram      │
│  └────────┬─────────┘                               │
│           │                                         │
│     ┌─────┴──────┐                                  │
│     ▼            ▼                                  │
│  ┌───────┐  ┌──────────────┐                        │
│  │TF-IDF │  │  FastText    │  預訓練中文模型          │
│  │稀疏   │  │  稠密嵌入    │  dim=100                │
│  └───┬───┘  └──────┬───────┘                        │
│      │             │                                │
│      └──────┬──────┘                                │
│             ▼                                       │
│      ┌─────────────┐                                │
│      │  特徵融合   │  concat + PCA降維               │
│      └──────┬──────┘                                │
│             ▼                                       │
│      ┌─────────────┐                                │
│      │  XGBoost    │  n_estimators=500               │
│      └──────┬──────┘                                │
│             ▼                                       │
│      ┌─────────────┐                                │
│      │  Redis快取  │  TTL=1h, 命中率~60%             │
│      └─────────────┘                                │
└─────────────────────────────────────────────────────┘

新增元件：FastText 預訓練嵌入、XGBoost、Redis 快取
成本：~$50/月（2 vCPU + 4GB RAM 伺服器）
解決了：準確率提升至 85-88%，支援 OOV（子詞分解）
未解決：語境多義性、長文依賴、嵌入更新需重新訓練

╔══ Phase 3：Scale（200K–1M+ 用戶，500 萬則評論/天）══╗

目標：準確率 > 92%，P99 延遲 < 50ms，吞吐量 500 QPS。

┌──────────────────────────────────────────────────────────┐
│                    Scale 架構                             │
│                                                          │
│  評論流入                                                 │
│     │                                                    │
│     ▼                                                    │
│  ┌──────────┐    ┌────────────────────────────┐          │
│  │  Kafka   │───▶│  前處理 Worker Pool         │          │
│  │  Queue   │    │  (8 個並行 Pod)             │          │
│  └──────────┘    └────────────┬───────────────┘          │
│                               │                          │
│                 ┌─────────────┼─────────────┐            │
│                 ▼             ▼             ▼            │
│          ┌──────────┐  ┌──────────┐  ┌──────────┐       │
│          │情感分類  │  │主題分類  │  │關鍵詞索引 │       │
│          │Sentence  │  │BERT-fine │  │Elastic   │       │
│          │Bert      │  │tuned     │  │Search    │       │
│          └────┬─────┘  └────┬─────┘  └────┬─────┘       │
│               │             │             │              │
│               └──────┬──────┘             │              │
│                      ▼                    ▼              │
│               ┌─────────────┐    ┌─────────────┐         │
│               │  結果 DB    │    │  向量索引   │         │
│               │  (PG+Redis) │    │  FAISS/     │         │
│               └─────────────┘    │  Milvus     │         │
│                                  └─────────────┘         │
└──────────────────────────────────────────────────────────┘

新增元件：Kafka、Sentence-BERT、FAISS 向量索引、K8s HPA
成本：~$800/月（GPU 推論節點 + 向量 DB）
解決了：語境理解、多義性、語義搜尋、自動擴縮容
未解決：冷啟動延遲 > 100ms、GPU 成本高昂、模型更新停機

三、文字前處理管線

前處理是 NLP 系統最容易被低估的部分。資料品質決定模型上限，而前處理決定資料品質。

3.1 中文前處理特殊挑戰

中文沒有天然的詞語邊界（不像英文有空格），因此分詞是中文 NLP 的第一道關卡。

繁體中文評論的完整前處理流程：

 1import re
 2import jieba
 3from opencc import OpenCC
 4
 5def preprocess_text(text: str, convert_s2t: bool = True) -> list[str]:
 6    # Step 1: 繁簡統一（視業務需求）
 7    if convert_s2t:
 8        cc = OpenCC('s2t')
 9        text = cc.convert(text)
10
11    # Step 2: 清理 HTML / emoji / 特殊符號
12    text = re.sub(r'<[^>]+>', '', text)           # 移除 HTML tag
13    text = re.sub(r'[^一-鿿\w\s]', ' ', text)  # 保留中文+英數
14
15    # Step 3: 全形轉半形
16    text = text.replace('，', ',').replace('。', '.')
17
18    # Step 4: jieba 分詞（精確模式）
19    tokens = list(jieba.cut(text, cut_all=False))
20
21    # Step 5: 移除停用詞
22    stopwords = load_stopwords()  # 哈工大停用詞表 ~2000 詞
23    tokens = [t for t in tokens if t.strip() and t not in stopwords]
24
25    # Step 6: 長度過濾（移除單字元噪音）
26    tokens = [t for t in tokens if len(t) >= 2]
27
28    return tokens

3.2 前處理品質指標

指標	說明	目標值
分詞準確率	詞語邊界正確率	> 95%
停用詞覆蓋率	無意義詞被過濾比例	30-40% token
OOV 率	詞彙表外詞比例	< 5%（FastText 可解決）
前處理延遲	單則評論處理時間	< 2ms

3.3 N-gram 策略

unigram 損失語序資訊，bigram/trigram 捕捉局部語序但增加詞彙維度：

unigram only：詞彙表 50K，向量維度低，訓練快
unigram + bigram：詞彙表 300K，捕捉「非常好」「不錯」等搭配詞
unigram + bigram + trigram：詞彙表 1M+，通常需要 min_df 截斷，適合大規模語料

實務建議：bigram 在情感分析上的提升約 +2-3% F1，成本可控，幾乎總是值得加。

四、詞袋模型與 TF-IDF

4.1 詞袋模型（BoW）

詞袋把文件表示為詞頻向量，完全忽略語序。

文件：「這個產品非常好用，價格也很實惠」
分詞：[這個, 產品, 非常, 好用, 價格, 也, 很, 實惠]
BoW：{這個:1, 產品:1, 非常:1, 好用:1, 價格:1, 實惠:1}

問題：「的」「了」「是」等高頻無意義詞會主導向量，導致所有文件看起來都很相似。

4.2 TF-IDF：加權詞頻

TF（Term Frequency）：詞在文件中的出現頻率。
IDF（Inverse Document Frequency）：詞在語料庫中的稀有程度。

TF(t, d) = count(t in d) / total_words(d)
IDF(t)   = log(N / df(t)) + 1          # 平滑版本
TF-IDF   = TF × IDF

直觀理解：

「好用」在 10% 的評論中出現 → IDF 高 → 區分能力強
「的」在 99% 的評論中出現 → IDF 接近 0 → 自然被壓制

4.3 TF-IDF 實務參數調校

 1from sklearn.feature_extraction.text import TfidfVectorizer
 2
 3vectorizer = TfidfVectorizer(
 4    max_features=10000,      # 控制詞彙表大小
 5    min_df=5,                # 至少出現在 5 個文件中
 6    max_df=0.95,             # 出現在超過 95% 文件的詞視為停用詞
 7    ngram_range=(1, 2),      # 加入 bigram
 8    sublinear_tf=True,       # 對 TF 取 log，壓制超高頻詞
 9    analyzer='word',         # 詞級別（可換成 char 處理 OOV）
10)

參數選擇對準確率的影響（電商評論實驗）：

設定	F1 Score	訓練時間	向量維度
unigram, max=5K	0.76	12s	5,000
unigram+bigram, max=10K	0.81	28s	10,000
unigram+bigram, max=50K	0.83	95s	50,000
char ngram (2-4)	0.79	45s	50,000

4.4 何時 TF-IDF 就夠了

TF-IDF + 邏輯回歸在以下條件下效果接近深度學習：

訓練資料 < 10K：嵌入模型需要大量資料才能發揮優勢
類別線性可分：垃圾郵件過濾、關鍵詞分類
延遲要求 < 1ms：TF-IDF 推論 CPU 0.1ms，BERT 需 GPU 10-50ms
可解釋性重要：TF-IDF 的特徵係數直接可解釋

五、稠密詞嵌入：Word2Vec / GloVe / FastText

5.1 核心思想：分佈式語義假說

「語義相似的詞，出現在相似的語境中。」

Word2Vec 的訓練目標：給定一個詞，預測它的鄰居（Skip-gram），或給定鄰居，預測中心詞（CBOW）。

Skip-gram 訓練範例：
輸入詞：「手機」
預測目標：[「這款」, 「螢幕」, 「電池」, 「很」]

訓練完成後的語義算術：
向量(國王) - 向量(男性) + 向量(女性) ≈ 向量(女王)
向量(台灣) - 向量(台北) + 向量(首爾) ≈ 向量(韓國)

5.2 三種嵌入方法比較

Word2Vec（2013）

訓練：Negative Sampling 或 Hierarchical Softmax
特點：每個詞一個向量，快速訓練，記憶體效率高
弱點：無法處理 OOV（詞彙表外的詞）

GloVe（2014）

訓練：全局共現矩陣分解
特點：捕捉全局統計資訊，在詞類比任務上表現好
弱點：同 Word2Vec，無法處理 OOV，字元級資訊損失

FastText（2016）

訓練：Word2Vec + 子詞（subword）拆解
特點：「手機殼」= 「手機」+ 「機殼」+ 「殼」的子詞向量加總
優點：處理 OOV、錯別字、罕見詞，特別適合中文電商（新品名、型號）

 1from gensim.models import FastText
 2
 3model = FastText(
 4    sentences=tokenized_corpus,  # List[List[str]]
 5    vector_size=100,             # 嵌入維度
 6    window=5,                    # 上下文窗口大小
 7    min_count=5,                 # 最低詞頻
 8    sg=1,                        # 1=Skip-gram, 0=CBOW
 9    workers=8,                   # 並行訓練
10    epochs=10,
11)
12
13# 語義相似度
14model.wv.most_similar('螢幕', topn=5)
15# [('顯示器', 0.89), ('畫面', 0.87), ('解析度', 0.85)]
16
17# OOV 處理（Word2Vec 做不到）
18model.wv['iPhone15Pro']  # 從子詞推斷向量

5.3 嵌入維度選擇

維度	適用場景	記憶體（100K詞）	訓練時間
50	詞彙少、任務簡單	40MB	快
100	電商評論推薦設定	80MB	中
200	複雜語義任務	160MB	慢
300	與 GloVe 預訓練對齊	240MB	慢

規則：嵌入維度與詞彙量的平方根成正比。詞彙量 10K → dim≈100，詞彙量 1M → dim≈300。

5.4 預訓練 vs 自訓練

策略	資料量需求	準確率	成本
使用預訓練（如 cc.zh.300）	任意	基準	$0 訓練
領域微調（繼續訓練）	> 100K 句	+1-3%	~$10
從頭訓練	> 1M 句	+2-5%	~$50

電商場景強烈建議從預訓練開始，再用領域語料微調，是效益最高的做法。

六、文字分類生產架構

6.1 從實驗到生產的五個陷阱

陷阱 1：訓練集洩漏
評論按時間切分訓練/測試集，而非隨機切分。否則模型可能學到時間特徵而非語義特徵，線上表現比離線差 5-10%。

陷阱 2：類別不平衡
電商評論通常正向 70%、負向 20%、中性 10%。不處理的話，模型會全預測正向，準確率 70% 但 F1 極低。解法：class_weight=‘balanced’ 或 SMOTE 過採樣。

陷阱 3：前處理訓練/推論不一致
訓練時用 jieba 精確模式，推論時誤用搜索引擎模式，分詞結果不同，導致特徵錯位。解法：把前處理邏輯封裝成 sklearn Pipeline 序列化儲存。

陷阱 4：向量化器版本不一致
TF-IDF 向量化器的詞彙表是訓練時建立的，推論時必須用同一個物件。不能重新 fit，只能 transform。

陷阱 5：長尾詞彙的 OOV 爆炸
每個月新品上市，型號不斷出現。TF-IDF 會忽略 OOV，FastText 會用子詞推斷，效果差很多。

6.2 生產推論服務設計

┌─────────────────────────────────────────────────────┐
│             推論服務架構（FastAPI）                  │
│                                                     │
│  POST /classify                                     │
│     │                                               │
│     ▼                                               │
│  ┌─────────────────┐                                │
│  │  輸入驗證       │  長度 < 500 字，編碼檢查        │
│  └────────┬────────┘                                │
│           │                                         │
│           ▼                                         │
│  ┌─────────────────┐                                │
│  │  Redis 快取查詢 │  key = sha256(text), TTL=24h   │
│  └────────┬────────┘                                │
│           │ Cache Miss                              │
│           ▼                                         │
│  ┌─────────────────┐                                │
│  │  前處理 Pipeline│  jieba + 停用詞 + TF-IDF       │
│  └────────┬────────┘                                │
│           │                                         │
│           ▼                                         │
│  ┌─────────────────┐                                │
│  │  模型推論       │  XGBoost or FastText分類器      │
│  └────────┬────────┘                                │
│           │                                         │
│           ▼                                         │
│  ┌─────────────────┐                                │
│  │  結果快取寫入   │  非同步寫入 Redis               │
│  └────────┬────────┘                                │
│           │                                         │
│           ▼                                         │
│       {label, confidence, latency_ms}               │
└─────────────────────────────────────────────────────┘

效能基準（4 核 CPU，無 GPU）：

模型	P50 延遲	P99 延遲	吞吐量
TF-IDF + LR	0.8ms	2ms	1200 QPS
TF-IDF + XGBoost	1.2ms	3ms	800 QPS
FastText 分類器	0.5ms	1.5ms	2000 QPS
FastText + LSTM	8ms	25ms	120 QPS

七、序列標注：NER 與 POS

7.1 為什麼電商需要 NER

從「這款 iPhone 15 Pro Max 256GB 太空黑配件好很多」中自動抽取：

實體類型      抽取結果
──────────────────────────────
品牌 (BRAND)  iPhone
型號 (MODEL)  15 Pro Max
規格 (SPEC)   256GB
顏色 (COLOR)  太空黑
類別 (CAT)    配件

這個資訊用於商品標籤自動化、推薦系統冷啟動、庫存管理。

7.2 CRF vs BiLSTM-CRF vs BERT-NER

CRF（條件隨機場）

特徵工程：詞性、前後文詞、字元 n-gram
訓練資料：500-2000 句標注即可
推論速度：< 1ms，適合高頻場景
F1：~78-83%（通用 NER）

BiLSTM-CRF

自動學習特徵，需要標注資料 5K-20K 句
推論速度：3-8ms（CPU）
F1：~85-88%

BERT-NER（fine-tuned）

最強語境理解，需要標注資料 1K+ 句（預訓練補足）
推論速度：15-50ms（需 GPU 達生產吞吐量）
F1：~90-94%

7.3 領域 NER 快速上線策略

標注效率公式：先用規則（正則 + 字典）標注 70%，再人工修正 30%，成本降低 60%。

 1# 混合規則 + 模型 NER
 2def hybrid_ner(text):
 3    # 第一步：字典匹配（高精度）
 4    dict_entities = dict_lookup(text, brand_dict)  # 品牌詞典 10K 詞
 5
 6    # 第二步：正則規則（型號、規格）
 7    regex_entities = regex_extract(text, patterns={
 8        'MODEL': r'[A-Z]\d+[\w\s]*(?:Pro|Max|Plus)?',
 9        'SPEC': r'\d+(?:GB|TB|mAh)',
10    })
11
12    # 第三步：模型補漏（處理詞典/規則未覆蓋的長尾）
13    model_entities = ner_model.predict(text)
14
15    return merge_entities(dict_entities, regex_entities, model_entities)

這個混合策略在電商場景達到 F1 ~89%，而純模型方案需要 10x 標注資料才能達到同樣水準。

八、為什麼選 X 不選 Y

決策 1：TF-IDF vs 詞嵌入（表示法選擇）

選擇            選 TF-IDF 的理由                    不選嵌入的理由
──────────────────────────────────────────────────────────────────
TF-IDF          < 1ms 推論，零 GPU 成本              嵌入：需 GPU 達高吞吐量
vs Embedding    可解釋（哪些詞最重要）               嵌入：黑盒，難以審計
                < 1K 訓練資料即可有效               嵌入：< 10K 資料時不穩定
                詞彙不平衡時表現穩健                嵌入：需要平衡語料才能泛化

翻轉條件：當準確率瓶頸在語義理解（F1 < 80%），或需要處理新詞/錯字時，
         切換至 FastText；需要跨語言或複雜語境時，切換至 Sentence-BERT。

決策 2：jieba vs HanLP vs CKIP（中文分詞）

選擇        選 jieba 的理由                不選其他的理由
───────────────────────────────────────────────────────────
jieba       純 Python，零依賴，輕量        HanLP：Java/C++，部署複雜
vs HanLP    自定義詞典簡單（一行代碼）     CKIP：僅繁體，社群小
vs CKIP     社群最大，踩坑資料多           Stanford NLP：英文優化
            POC 到 Scale 都可用

翻轉條件：當需要繁體中文高準確度（> 97%）或需要詞性標注時，
         考慮 CKIP-tagger；需要命名實體時，HanLP 整合更完整。

決策 3：Word2Vec vs FastText vs GloVe（靜態嵌入）

選擇           選 FastText 的理由                  不選其他的理由
────────────────────────────────────────────────────────────────
FastText       處理 OOV（子詞分解）                Word2Vec：OOV 全部失效
vs Word2Vec    錯別字、新型號自動推斷               GloVe：無 OOV 處理，需共現矩陣
vs GloVe       推論速度與 Word2Vec 相當             GloVe：記憶體需求更大
               Facebook 官方預訓練中文模型 cc.zh    Word2Vec：更新維護停滯

翻轉條件：當語料規模 > 5億詞且有穩定詞彙表時，GloVe 捕捉全局統計更好；
         當語料純英文且 OOV 率 < 1% 時，Word2Vec 訓練更快。

決策 4：邏輯回歸 vs XGBoost vs SVM（分類器選擇）

選擇            選 XGBoost 的理由                 不選其他的理由
────────────────────────────────────────────────────────────────
XGBoost         非線性邊界，F1 比 LR 高 3-5%       LR：線性分類，高維稀疏尚可
vs LR           樹模型對特徵縮放不敏感              SVM：高維稀疏訓練慢，記憶體大
vs SVM          原生支援缺失值                      深度學習：需 GPU，小資料過擬合
                訓練速度（并行提升樹）              SVM：超參數調優複雜

翻轉條件：當可解釋性要求高（需要特徵係數）時，用 LR；
         當訓練資料 < 1K 且特徵空間高時，SVM 表現更穩定。

決策 5：FAISS vs Milvus vs Elasticsearch（向量搜尋）

選擇           選 FAISS 的理由                  不選其他的理由
──────────────────────────────────────────────────────────────
FAISS          Facebook 開源，最佳記憶體效率     Milvus：需要獨立部署，運維複雜
vs Milvus      搜尋延遲 < 5ms（100M向量）       ES：kNN 搜尋效率比 FAISS 低 5-10x
vs ES          可直接嵌入 Python 應用            Milvus：功能更豐富但殺雞用牛刀
               GPU 加速支援（cuFAISS）           ES：用於混合搜尋（關鍵詞+向量）

翻轉條件：當需要即時更新向量（新增/刪除）時，Milvus/Qdrant 更適合；
         當需要同時做關鍵詞過濾+向量搜尋時，ES 或 pgvector 最方便。

決策 6：批次推論 vs 即時推論（部署模式）

選擇            選批次推論的理由                 不選即時的理由
────────────────────────────────────────────────────────────────
批次            GPU 利用率高（batching）          即時：GPU 閒置率 > 70%
vs 即時         成本低 3-5x（同等吞吐量）         即時：每個請求獨立推論效率低
                可在低峰時段執行，不搶高峰資源    即時：需要更多副本保持 SLA
                錯誤重試不影響用戶體驗            即時：延遲要求 < 100ms 時必要

翻轉條件：當用戶體驗需要即時回饋（搜尋建議、聊天機器人）時，
         必須用即時推論；當 SLA > 1 分鐘時，批次永遠更划算。

九、系統效應：TF-IDF vs 靜態嵌入 vs Transformer

整體對比（電商評論分類，50萬則資料）

維度	TF-IDF + LR	FastText + XGBoost	Sentence-BERT
情感分類 F1	0.81	0.88	0.93
主題分類 F1	0.76	0.84	0.91
OOV 處理	無（忽略）	子詞推斷	完整語境
P99 推論延遲	2ms	3ms	45ms（GPU）
訓練時間	30s	5min	4h（fine-tune）
月運算成本	$5	$30	$400（GPU）
可解釋性	高（係數）	中（SHAP）	低（黑盒）
冷啟動效能	需 1K 資料	可用預訓練	可用預訓練

Before/After：導入嵌入前後的業務影響

指標	TF-IDF 階段	FastText 階段	提升
負評自動偵測準確率	76%	87%	+11pp
錯誤標注率	24%	13%	-46%
每日人工審核量	8,000 則	4,300 則	-46%
人工成本/月	$6,000	$3,200	-47%
模型推論成本/月	$5	$30	+$25
淨節省/月	—	—	$2,775

ROI 計算：FastText 導入成本（開發 3 週）約 $15,000，第 6 個月回本，之後每月淨節省 $2,775。

十、面試答題要點（RKK 框架）

「針對 50 萬則/天的中文電商評論系統，我會採用三階段演進策略。Phase 1 用 jieba 分詞 + TF-IDF + 邏輯回歸快速驗證，2 週內上線，F1 約 78%，推論成本幾乎為零。Phase 2 切換至 FastText 子詞嵌入 + XGBoost，解決新型號 OOV 問題，F1 提升至 88%，P99 延遲維持在 3ms 以內，月成本約 $30。Phase 3 達到百萬用戶規模時，引入 Sentence-BERT 做語義搜尋，配合 FAISS 向量索引實現 500 QPS 的相似評論查詢，同時保留 FastText 做高頻情感分類以控制 GPU 成本。關鍵決策是不在 Phase 1 就用 BERT——小資料集下 BERT fine-tune 反而容易過擬合，而且 45ms 的 GPU 延遲在 Phase 1 的規模完全不必要；FastText 的子詞機制是電商場景的核心優勢，因為每月都有新型號上市，OOV 率高達 15%，用 TF-IDF 會靜默失效。」

十一、系列導航

本文是 AI 工程從零開始 系列的 Phase 5 Part 1。

	文章
← 上一篇	Phase 4 Part 3：模型監控與漂移偵測
→ 下一篇	Phase 5 Part 2：Transformer 與 BERT 實戰