https://yennj12.js.org/yennj12_blog_V4/tags/tf-idf/Recent content in TF-IDF on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSun, 21 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase5-part1-text-fundamentals-zh/Sun, 21 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase5-part1-text-fundamentals-zh/大多數人處理文字時，直接把原始字串丟進模型，期待魔法發生。 正確做法是：先理解文字的統計結構，再選擇適合問題規模的表示法。 詞袋夠用的場景別用嵌入；嵌入必要的場景別省那筆運算。 表示法的選擇，決定了整個 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% 即可。