1. 文本任務 (Text / NLP / LLM)

在 AI 能力中，文字任務是最基礎的功能。無論我們最終想做的是內容審核、搜索推薦、知識問答，還是寫作助手、代碼 Copilot，本質上都繞不開一個問題：機器如何真正看懂文字。

1.1 基礎語言建模與表示

讓我們從最底層的基礎語言建模與表示講起。它的作用是讓機器先在統計意義上熟悉語言，並在此基礎上為詞、句子、文檔找到一個穩定的向量矩陣表示，以便於後面的分類、匹配、抽取、生成等任務。不管未來要做什麼文本相關任務，都或多或少需要先回答同一個問題：我怎麼用一串數字，把這一段話表示出來？

我們可以簡單從場景、原理、模型三個角度來看這個問題的相關內容：

• 場景
  • 檢索搜索相關
    • 通用搜索引擎：用戶隨便輸入一句話，得到含義相關的文檔，而不是隻做關鍵詞精確匹配。
    • 站內搜索 / 電商搜索：用戶用口語化的描述（比如“適合夏天通勤的白襯衫”），找到含義對應的商品。
    • 文檔庫 / 知識庫檢索：在技術文檔、政策法規、企業知識庫裡，直接輸入一句話獲得相關條目。
  • 推薦排序相關
    • 信息流 / 內容推薦：根據用戶最近看過、點過的內容，自動找出內容相近的其他內容繼續推薦，而不是隻靠人工規則或標籤。
    • 電商 / 商品推薦：根據用戶看過、買過、收藏過的商品描述，找到風格或用途相近的商品，做個性化推薦。
    • 用戶興趣建模：根據用戶看過的標題、搜索過的詞等，總結出幾個主要興趣方向，用來提升推薦和排序效果。
  • 問答助手相關
    • FAQ 問答：用戶用不同說法問同一個問題（“怎麼開發票？” vs “發票在哪裡開？”），系統能跳到同一個答案。
    • 知識庫問答 / 企業助手：用戶用自然語言提問，系統到內部文檔裡按含義去匹配，找出最相關的段落回答。
  • 文本理解分析相關
    • 評論輿情分析：把大量評論、帖子按“在說什麼 / 情緒怎樣”大致分成幾類。
    • 文本去重 / 相似檢測：用於發現改寫稿、偽原創文章。
    • 文檔聚類 / 分組：把很多文章、報告按照內容相近分成幾組，方便做導航、推薦或抽樣檢查。
  • 作為下游任務通用特徵 （下游任務指的是用模型的基礎能力，去實現更具體的文字處理任務）
    • 文本分類：情感分類、意圖識別、垃圾內容識別等下游模型直接複用這一層的表示。
    • 信息抽取：實體識別、關係抽取在詞 / 句子表示的基礎上進行微調，而不是從頭訓練。
    • 文本生成：為摘要、改寫、續寫等生成任務提供語義表徵輸入，提升生成質量與可控性。
• 原理 學習詞、句子、文檔的表示，為後續更復雜的任務作為基底。
  • 語言建模
    • 自迴歸語言模型：預測下一個 token（GPT 系列、LLaMA、Qwen 等）
    • 掩碼語言模型 (Masked LM)：預測被遮蓋 token（BERT、RoBERTa、ERNIE）
  • 詞 / 句子 / 段落表示
    • 靜態詞向量：Word2Vec、GloVe、FastText
    • 上下文表徵：BERT embedding、Sentence‑BERT 等
    • 文檔級向量：用於語義檢索、相似度匹配
• 模型 BERT / RoBERTa / ERNIE、GPT 家族、LLaMA / Qwen / Yi 等 LLM；各類 Embedding 模型（OpenAI text‑embedding‑3 系列、bge、E5、SimCSE 等）。

1.1.1 語言建模：通過“猜下一個詞”學會語言

這一層的第一步，是先讓模型在大量文本里 熟悉語言規律 。做法可以簡單理解為：給模型出無數道“猜詞題”，在看到一段話的上下文後，讓它填上最合理的詞（token）。練習題足夠多、語料足夠廣，模型就會逐漸學會：一句自然的句子長什麼樣，哪些詞經常一起出現，什麼表達讀起來彆扭。這個過程叫“語言建模”，本質就是一套統一的 猜詞訓練機制 。

常見有兩種出題方式，每種用一句話舉個簡單例子：

1. 往後接（自迴歸） ：只給前面的內容，讓模型猜“後面會怎麼說”。
2. 輸入前綴：今天下雨了，所以我
3. 模型任務：猜下一個詞，比如“ 帶 （傘）”“ 沒 （出去）”“ 打算 （在家）”等，然後再繼續往後接。 這種方式主要鍛鍊模型對續寫、連貫性、常見表達的把握。
4. 挖空填詞（掩碼） ：把中間挖個洞，讓模型利用前後文一起填空。
5. 原句：今天下雨了，所以我帶了雨傘
6. 訓練句：今天 [MASK] 了，所以我帶了雨傘
7. 模型任務：把 [MASK] 補成“ 下雨 ”這類合理的詞。 這裡模型必須同時看左邊的“今天”“了”和右邊的“所以我帶了雨傘”，才能決定該填什麼，更有利於學習 整句語義 。

通過在海量語料上反覆做這兩類“猜詞題”，模型會逐漸積累起對語言的 語感和統計常識 。在此基礎上，下一步我們再把這種能力顯式地變成 詞、句子和文檔的向量表示 ，為後續的檢索、推薦和問答等任務打底。

1.1.2 詞、句子與文檔表示：把離散符號映射到語義空間

構建文本向量最早一代的方法是靜態詞向量 ：為每個詞分配一份固定向量，訓練好後不隨上下文變化，直觀、簡單，但 無法區分多義詞在不同語境下的含義。 為了解決這個問題，後來出現了基於上下文的動態表示方法：同一個詞在不同句子中會生成不同的向量，完全由它所在的上下文決定。比如“蘋果”在“蘋果發佈了新手機”中會更靠近“科技公司”的語義方向，而在“蘋果富含維生素”中則更接近“水果”概念。

這種機制不僅提升了詞層面的表達能力，也為句子和文檔的向量化鋪平了道路。對於句子，可以生成句向量；對於文檔，可以整篇輸入編碼（如果長度允許），或分段編碼後再通過注意力機制、層次化池化、對比學習等方式聚合出一個全局向量。近年來的專用 embedding 模型（如 bge、E5、text-embedding 系列）正是圍繞“讓語義相近的文本在向量空間中更近”這一目標持續優化，尤其在語義檢索、相似匹配等任務上表現突出。

這套從上下文建模到句/文檔向量生成的流程，已經成為搜索、推薦、問答等系統背後的核心基礎設施，讓我們回到前面提到的各類場景：

• 檢索搜索場景（通用搜索、電商搜索、知識庫檢索）都需要把用戶輸入和候選文檔都編碼成向量，然後在向量空間裡做相似度匹配，找出語義最接近的結果，而不是隻靠關鍵詞精確匹配。
• 推薦排序場景（信息流推薦、商品推薦、用戶興趣建模）需要把用戶歷史行為對應的內容轉成向量，然後找到向量相近的新內容推薦給用戶，實現"看過 A 推薦 B"的個性化效果。
• 問答助手場景（FAQ 問答、知識庫問答）需要把用戶的提問和知識庫裡的問題或段落都編碼成向量，通過向量相似度找到最匹配的答案。
• 文本理解分析場景（評論輿情、去重、聚類）需要先把每條文本轉成向量，再基於向量做聚類、相似度計算或分類。
• 下游任務場景（文本分類、信息抽取、文本生成）則是直接把這一層的向量表示作為輸入特徵，餵給後續的分類器、抽取器或生成器，避免從頭學習語義。

工程上，常見做法是封裝成統一的"文本向量服務"：輸入任意一段文本，輸出一串固定維度的向量，供搜索、推薦、問答等多個系統共享使用。在產品層面，這一層的能力主要體現在：搜索和推薦中的語義召回（不再只依賴關鍵詞，而是通過向量相似度召回"說法不同但意思相近"的內容），以及面向企業知識庫、FAQ、案例庫的統一 embedding / 向量檢索服務。

1.2 文本分類與文本匹配（Classification & Matching）

在上一節中，我們通過基礎語言建模與表示，為每一段文本找到了在語義空間中的“座標”。但僅有座標還不夠，業務真正關心的問題往往是：這段文本屬於哪一類？和另一段文本是不是講同一件事？兩句話之間在邏輯上是相互支持還是互相矛盾？你可以把它理解為：用分類和匹配這兩個能力，把底層的向量表示轉化為可以直接驅動業務決策的標籤與相關性信號。我們仍然從場景、原理和模型三個角度來梳理這一層：

• 場景
  • 內容理解與審核：給評論、帖子、文章打上主題、情感、風險等標籤，用於審核、推薦、統計分析。
  • 推薦與排序：根據“用戶興趣標籤”和“內容標籤”的匹配程度，決定展示哪些內容、排在多前。
  • 搜索與 FAQ：用戶隨便輸入一句自然語言問題，系統能夠自動找到最相關的問題‑答案對或文檔片段。
  • 相似內容識別：在大量文本中找到“內容相近”的條目，用於去重、合併統計、推薦“相關內容”。
  • 邏輯關係判斷：判斷兩句話之間是互相支持、互相矛盾，還是無關，用於事實核查、多輪對話一致性檢查等。
• 原理 在語義表示的基礎上，對整段文本或文本對進行整體判斷：
  • 文本分類：給單條文本打標籤（如情感、主題、風險類型等）；
  • 文本匹配：判斷兩段文本之間的相似度、相關性，或“問題–答案”是否匹配；
• 模型 以預訓練 encoder 為基礎，接上簡單的分類 / 匹配結構：
  • 單文本分類：BERT / RoBERTa / DeBERTa + 全連接分類層；
  • 文本匹配：Sentence‑BERT、SimCSE、雙塔（Bi‑Encoder）、交叉編碼器（Cross‑Encoder）；
  • 複雜判斷：在 LLM 上通過指令微調，讓模型直接輸出標籤或邏輯關係。

1.2.1 文本分類：從“懂內容”到“給內容定性”

藉助上一層的語義表示，我們可以非常自然地在其上方接一個簡單的分類頭，通過少量標註數據，讓模型學會回答一個問題： “這段文本屬於哪一類？” 。

最經典的是 情感分類 。用戶的一句評價，可能是認可、抱怨，也可能只是陳述事實。模型在拿到這句話的向量表示之後，只需要再接一個 softmax 分類層，就能輸出“正向 / 負向 / 中立”的概率。這類能力在電商、社交平臺、應用市場等場景中，都已經非常成熟。

另一大類是 主題 / 行業分類 。新聞推薦裡，我們希望知道一篇文章是體育、財經還是娛樂；企業內部的客服 / 工單系統，則更關心這是產品諮詢、功能異常還是投訴建議。這些標籤既可以幫助內容被更精準地路由到合適的流程中，也可以作為推薦排序階段的重要特徵。

更進一步，風險 / 合規分類則直接與平臺安全相關。我們會針對廣告導流、謾罵攻擊、涉政敏感、低俗色情等類別設置專門的分類模型，配合人工審核，對高風險內容進行攔截或降權。可以說，絕大部分內容安全策略的第一道閘門，都是由這類分類器構成的。

可以看到，到這一層為止，我們已經能夠把“抽象的語義表示”轉化為若干業務可用的標籤。接下來，我們要討論的是：當文本之間產生關係時，我們又如何進行 匹配與推斷 。

1.2.2 文本匹配：為一句話“找到最合適的另一句”

與分類對“單個文本定性”不同，文本匹配關注的是“兩段文本之間的相關性”。在很多產品裡，這往往是實現“智能”的關鍵一環：用戶說了一句話，系統能不能找到知識庫裡最合適的一條進行回應，完全取決於匹配質量。

最基礎的是 語義相似度計算 。我們會先用上一層的 embedding 模型，把兩個句子編碼成向量，再通過餘弦相似度、點積等方式，判斷它們在語義空間裡的距離。像 SimCSE、Sentence‑BERT 這類模型，就是通過對比學習的方式，專門把“相似的句子對”拉近，把“不相似的句子對”推遠。

在此之上，複述檢測和抄襲檢測只是特定應用場景的匹配任務。前者用於內容去重，避免平臺充斥著重複表達；後者則在教育、知識社區等場景中，用來識別高度相似的回答或文章。技術上，它們本質都是根據文本相似度來做二分類或排序。

一個非常重要的下游應用是 問答匹配 。當用戶提出一個自然語言問題時，我們不會直接用關鍵詞去匹配 FAQ，而是通過語義向量先做召回，再用更精細的匹配模型（如交叉編碼器 Cross‑Encoder）對若干候選進行重排序，選出最可能對應的那一條。這一鏈路構成了 FAQ 機器人和文檔問答系統的基礎。

在這一層，我們已經具備了對“整段文本”進行分類和關係判斷的能力。但在很多場景裡，業務並不滿足於此，而是進一步希望知道： 這段文本中具體提到了哪些實體、發生了什麼事件 。這就自然引出了下一節的主題—— 序列標註與信息抽取 。

1.3 序列標註與信息抽取（Sequence Labeling & Information Extraction）

在完成了對文本整體的分類和匹配之後，我們往往會遇到一個更細緻的訴求：不僅要知道“這篇文章是關於什麼的、風險高不高”，還要進一步知道“它具體提到了誰、在哪兒、什麼時候、金額是多少”。這一節，就是在整體判斷之上向“細粒度結構化”邁出的關鍵一步。你可以把它理解為：在已經知道“應該看哪一類文本、它大概講什麼”的前提下，從文本內部挖掘實體、關係、事件和各類字段，讓非結構化文本可以直接被業務系統消費。我們同樣從目標、原理、模型和產品四個方面來看這一層：

• 場景
  • 行業文本結構化：從合同、報告、公告、病歷、政策等文檔中，抽取出人名、機構、金額、時間、條款等關鍵字段，用於入庫和檢索。
  • 知識圖譜與關係網：從新聞、論文、問答中識別實體及其關係，構建“誰和誰有什麼關係”的圖譜，用於搜索、推薦和分析。
  • 票據與單據處理：對發票、對賬單、報銷單等，自動提取抬頭、稅號、金額、日期等字段，減少人工錄入。
  • 輿情與事件分析：從海量文本中抽取“誰在什麼時候在哪兒做了什麼”，用於事件跟蹤、風險預警與統計報表。
  • 日誌與工單結構化：把客服對話、工單、系統日誌等非結構化文本里的關鍵信息抽出來，方便統計、監控和自動化處理。
• 原理 在 token / 短語層面，對文本進行細粒度標註與結構化：
  • 序列標註：對每個 token 貼標籤（如人名、地名、機構名、產品名等），實現命名實體識別、詞性標註、短語切分等；
  • 關係與事件抽取：在實體之上識別“實體‑實體”之間的關係，以及“誰在何時何地做了什麼”的事件結構；
  • 業務字段抽取：圍繞具體業務 schema（如合同字段、票據字段），將長文檔轉成標準化的 key‑value 或記錄表。
• 模型 在預訓練表示的基礎上，通過序列標註或 span 抽取等結構完成信息提取：
  • 序列標註模型：BiLSTM‑CRF、BERT + CRF / Softmax 等；
  • Span‑based 抽取：直接預測實體 / 關係片段的起止位置；
  • 文檔級抽取：結合版式、佈局的 DocIE 類模型；
  • 基於 LLM 的抽取：通過 Prompt / Few‑shot，讓大模型按指定格式抽取所需字段。

1.3.1 序列標註：給每個 token 和短語貼上語義“標籤”

在文本分類階段，我們只關心整段文本屬於哪一類；而在序列標註階段，我們要對文本中的每一個 token、每一段短語進行標記。最典型的任務是命名實體識別（NER）：識別人名、機構名、地名、產品名、疾病名等特定類型的實體。

• 例如，在句子“張三在北京加入某科技公司”中，把“張三”標為人名、“北京”標為地名、“某科技公司”標為機構。

從建模方式上看，傳統的做法是使用 BiLSTM + CRF 這類序列標註結構，後續則更多采用 BERT + CRF 或 BERT + Softmax，利用預訓練 encoder 的上下文表徵能力，來判斷每個 token 的標籤（如 B‑ORG、I‑ORG、O 等）。在實踐中，NER 模型往往是後續知識圖譜、關係抽取的第一道“預處理”。

除了 NER 外，詞性標註、短語切分也屬於典型的序列標註任務。它們更多服務於底層語言分析，為後續更復雜的語法 / 語義任務提供基礎結構。

• 比如對“快速 提升 模型 性能”標出“快速”為副詞，“提升”為動詞，“性能”為名詞，用於下游分析。

1.3.2 關係與事件抽取：把“點”連成“線”和“故事”

當我們通過序列標註識別出文本中的實體之後，一個順理成章的問題是：這些實體之間到底是什麼關係，它們共同構成了什麼樣的事件？

關係抽取關注的是“實體對 + 關係類型”。例如，在一句“張三於 2024 年加入某科技公司擔任 CTO”中，我們不僅要識別“張三”和“某科技公司”這兩個實體，還要抽取它們之間的“就職於”關係。

• 簡單來說，就是從“張三 – 某科技公司”這對實體上，貼上“任職”這類關係標籤。

在關係之上，事件抽取則試圖重建“誰在什麼時候、什麼地點，做了什麼事情”。以一則新聞為例，一個標準的事件模板可能包含：事件類型（收購、合作、事故）、時間、地點、參與方、金額、後果等多個槽位。事件抽取模型需要從冗長的文本中自動填充這些槽位，從而構建出可被檢索、統計和推理的“事件表”。

• 比如從“某公司以 5 億元收購另一家公司”中抽出：事件類型=收購，金額=5 億元，參與方=兩家公司。

在建模方法上，除了傳統的序列標註式抽取，我們還會採用 Span‑based IE（直接預測實體 / 關係 span 的起止位置）以及近年來興起的 Prompt‑based IE 和基於 LLM 的 Few‑shot 抽取。後者的優勢在於可以通過自然語言提示，快速適配新的 schema，減少大量重新標註和訓練的成本。

從工程角度看，成熟的抽取系統往往會形成一條管線：

• 上游 NER / 序列標註識別實體；
• 中間層做關係和事件結構建模；
• 下游把結果寫入數據庫或知識圖譜，供搜索、分析和風控系統消費。

1.4 文本生成與編輯（Text Generation & Editing）

在前面幾節中，我們已經依次構建了“表示 → 分類匹配 → 序列標註與抽取”這條理解鏈路：模型不僅能把文本映射到語義空間，還能對整段文本做判斷，並從中抽取出結構化信息。這一節要做的，是把這條理解鏈路“反向”再走一遍：在充分理解的基礎上，讓模型主動去生產、改寫、壓縮和潤色文本。你可以把它理解為：在語義空間中進行“反向編碼”，把內部表示重新變成高質量的自然語言輸出，是整條文字模態能力鏈裡最貼近用戶感知的一層。我們依舊從目標、原理、模型和產品四個維度來拆解：

• 場景
  • 日常寫作與辦公：生成郵件、通知、方案初稿，或對現有文本進行擴寫、改寫和潤色。
  • 知識管理與總結：對長文檔、報告、會議記錄進行自動摘要，幫助快速抓住重點。
  • 客服與問答：根據用戶問題和檢索到的資料，自動生成結構清晰、口吻統一的回答。
  • 營銷與創意內容：生成廣告文案、社交媒體帖子、活動介紹、腳本等。
  • 多語言場景：在保持原意的基礎上，完成翻譯、本地化改寫，適配不同語言和場景。
• 原理 在語言建模的基礎上，對文本進行“從無到有”和“基於已有內容的修改”：
  • 自由生成：根據意圖、提示詞或大綱，從頭生成一段完整的文本；
  • 受控改寫：在保持核心信息不變的前提下，調整風格、長度、結構（如摘要、擴寫、風格轉換）；
  • 糾錯與潤色：修正錯別字、語法問題，優化表達順序和邏輯結構。
• 模型 以大規模預訓練 + 指令微調的生成模型為主：
  • 指令微調 LLM：GPT 系列、LLaMA / Qwen / GLM 等，用於通用生成與編輯；
  • Seq2Seq 模型：T5、BART、mT5 等，用於摘要、翻譯、格式轉換等任務；
  • 對齊與安全：通過 RLHF / RLAIF 等手段，讓生成內容更加符合指令和安全要求。

由於這個部分基本等於提示詞工程，故不再過多闡述，可以自行查看提示詞工程部分的教程。