閱讀目標
這一頁先回顧 AI 服務，再認識自己構建演算法這條路徑。重點是建立一張能力地圖：看到一個需求時，知道它更接近生成、檢索、推薦、分類、聚類、迴歸，還是其他型別的任務。
正文之後是十三段配套影片的中文文字稿。它們保留了原來的講解順序和例子；涉及舊產品、個人經驗及概念簡化的地方另有譯註。
這十三段之後，繼續提供七份模型定製的擴充套件文字稿：入門、提示工程、RAG、微調、函式呼叫、嵌入與 MCP。本頁合計二十份配套文字，第二門遇到完全相同材料時直接連結到這裡的對應章節。
一、快速回顧 AI 服務
主要 AI 平臺提供的能力，包括生成文字、影象、聲音的生成式 AI，以及分類、聚類、推薦等工具。這些類別構成現代 AI 工具箱的基礎。
無論接觸 OpenAI、AWS、Microsoft Azure 還是 Hugging Face，都可能反覆見到這些服務型別。先能辨認、說清它們提供什麼能力，才更容易進行後續的深入比較。
二、自己構建演算法
從頭構建自己的 AI 演算法，如今是一條相對少見但仍然重要的路徑。很多團隊使用現成模型和服務，但定製演算法能提供更多控制權，在高度專門的需求中可能有必要。
開發工具包括 PyTorch、TensorFlow、JAX、scikit-learn；支援實驗和部署的平臺包括 SageMaker、Colab、Azure ML Studio。瞭解這條路徑，是為了判斷什麼時候值得自行構建、為什麼要這樣做，以及可以使用哪些工具。
譯註：這是原頁對工具與路徑的介紹，不是對當前產品名稱、版本、價格和可用功能的逐項核驗。實際選型時應再查對應官方資料。
影片文字稿一：建立 AI 服務地圖
先快速回顧市場上的主要 AI 服務，例如生成式 AI、推薦引擎、計算機視覺等。接著認識提供這些工具的主要參與者，如 Amazon Web Services、Microsoft、Google、Meta、OpenAI 等。
需要學習的不只是找到工具，還包括怎樣發現、評估並選擇適合自己需求的工具，如何用自己的專有資料定製服務，以及為什麼現在從頭構建演算法的情況比過去少了。
目標是形成一張較清楚的 AI 能力地圖，知道怎樣在其中尋找方向。
影片文字稿二：演算法概覽
日常說“AI”時，往往把多種資料驅動演算法統稱在一起。實際工具可能混合統計迴歸、機器學習，以及其他 AI 方法。這裡先從商業上面向廣泛使用者的服務來看，它們在使用方式上有許多共同點。
下面依次回顧一些經常在實際產品與客戶專案中遇到的演算法類別。
譯註：原字幕把這類演算法籠統稱作“強化學習演算法”，這個說法不準確。後面介紹的迴歸、分類和聚類並不都屬於強化學習。這裡保留“多類資料驅動方法被統稱為 AI”的意思，並明確區分概念。與知識無關的個人及僱主介紹已去除。
影片文字稿三：生成式 AI
生成式 AI 可以用於許多不同任務。它透過神經網路等機器學習模型，從既有資料中學習模式，再生成新的文字、影象或音樂。
它不是簡單地逐份複製訓練材料，而是根據學到的模式預測並生成輸出。ChatGPT 是文字生成的例子，Stable Diffusion 是影象生成的例子。預訓練 Transformer 和生成對抗網路，是這類系統中常見的模型方法。
對於邊界較明確的資料集合，例如程式原始碼和服務檯工單，這些方法可以很有用。這也幫助解釋了為什麼 GitHub Copilot 較早成為大眾接觸的生成式 AI 產品之一。
譯註：“生成新輸出”並不保證內容一定原創、不會與已有材料相似，或自動擁有可使用的權利。字幕中的產品名稱存在轉寫錯誤，這裡按上下文還原為 GitHub Copilot。
影片文字稿四：資訊檢索
資訊檢索是把大語言模型用於具體任務的一種重要方式。典型情形是：使用者用自然語言提問，而回答需要的資料顯然不在模型原來的訓練資料中。
天氣，尤其短期天氣預報，就是一個容易理解的例子。訓練大語言模型需要時間，模型的訓練資料通常有截止日期，可能落後於提問時幾個月，甚至幾年。因此，單靠訓練時儲存在引數中的資訊，不可能準確回答之後某一天的天氣預報。
但如果一個聊天產品接入了天氣查詢等外部工具，就有機會回答溫哥華等地區的近期天氣。這不是引數突然知道了未來，而是系統能夠取得外部資訊。
這只是眾多例子之一：通用大語言模型可以與資訊檢索能力組合，成為面向特定資料的問答系統。後續再進一步看它怎樣連線資料。
譯註：字幕說“現在去問某產品就能得到準確預報”，這是當時的示例，並不保證每個賬號、模式或提問都已接入天氣工具。是否實際查詢、查到什麼時間的資料，仍要檢查。
影片文字稿五：推薦引擎
推薦引擎是給使用者建議電影、歌曲、商品等內容的程式。它根據你的過去選擇，以及其他人的選擇，估計你接下來可能喜歡什麼。
常用方法包括協同過濾、利用使用者關係的資訊，以及基於內容的過濾：尋找與已有偏好相似的內容，再提出建議。
Netflix 是容易理解的例子。電子商務網站上的“購買此商品的人也購買了”或“你可能還感興趣”，也屬於相近能力在不同任務中的應用。
文字稿還提到，Netflix 在 2006 年啟動推薦演算法競賽，邀請外部參與者改進其演算法，大獎為一百萬美元。
譯註：原字幕將這項活動稱為“年度競賽”。這裡保留它以獎金徵集演算法改進這一實質資訊；“年度舉辦”沒有在提供的材料裡得到進一步支援，不據此暗示該競賽目前仍在舉行。
影片文字稿六：異常檢測
異常檢測先分析大量正常資料，建立對某個情境中“正常狀態”的認識，再尋找偏離這種狀態的現象。
這些異常可能提示欺詐、裝置故障，或者人為錯誤。機器學習方法可以幫助快速發現不尋常的事件。銀行、金融機構，以及有後臺業務流程的組織，都可能使用這類能力。
異常是一條需要檢查的線索，不等於已經證明發生欺詐或故障。
影片文字稿七：分類
分類演算法學習把事物放進已定義的類別。訓練時提供預先標記的資料，例如狗和貓的圖片，模型學習怎樣區分它們。以後見到訓練集以外的圖片時，就可以嘗試根據已學到的模式預測標籤。
常見方法包括決策樹、支援向量機和神經網路。
早期大眾產品中的人臉識別，展示了這類能力的用途。文字稿以大約 2015 年接觸到的 Facebook 照片識別，以及當時 Microsoft Cognitive Services 透過 REST API 提供物體檢測服務為例。
現在，物體識別已經出現在許多產品裡。比如照片服務可以讓人根據畫面中的物體搜尋照片，而不是隻依靠檔名。如果手機照片已經同步到相應服務，就可能在大量圖片裡快速找出某類物件。
這類服務展示了模型如何幫助使用者從龐大圖片庫中查詢內容，也是這裡關注的商業能力之一。
譯註：這裡保留的是講解中的歷史產品例子，去掉了個人體驗和經歷署名。分類與物體檢測有關聯，但不是同一個任務：檢測通常還需要定位物件。系統會犯錯，也不能把“任何物體都容易識別”當成可靠結論。
影片文字稿八：聚類
聚類會觀察一批資料，按照物件之間的相似程度，把它們放進不同組。關鍵是，系統事先沒有拿到每個物件所屬類別的標準標籤，而是嘗試自己找出結構。
不同演算法對組數和分組方式的要求不同。有的需要事先指定組數，有的會根據資料和引數形成分組。
文字稿重點介紹 K-means，認為它相對簡單、效率較高，是商業場景中常見的方法，並建議初學者先關注它。
譯註：原字幕說聚類“不用訓練集，只是一個演算法”，容易誤解。聚類仍然需要輸入資料，許多方法也要擬合；它通常缺少的是監督學習中的標準標籤。原字幕還以個人見聞建議忽略其他方法，不能當成全面選型建議。K-means 之外也有其他聚類方法，是否適合要看資料、相似性定義和分組目標。
影片文字稿九：迴歸
迴歸學習根據已有屬性與歷史資訊預測一個數值。可以用房價說明：觀察房屋面積怎樣與價格相關，找出模式，再根據面積預測價格。
把這種關係寫成公式，就得到一個可以計算預測值的模型。文字稿提到兩種常見形式：線性迴歸，以及在曲線擬合等任務中出現的多項式迴歸。
重點是它預測的是數值，而不是給資料分配類別。
檢視圖解文字說明
分類回答樣本屬於哪一類，可使用分數與閾值決定類別；迴歸預測一個連續數值。兩個圖用不同的輸出形式作比較，選擇方法還需要考慮誤報、漏報或數值誤差的代價。
影片文字稿十：計算機視覺
計算機視覺讓系統處理、解釋影象與影片。可以類比眼睛接收畫面、再由大腦處理，但這個比喻不代表模型真的以人的方式觀看。
系統能夠識別人臉、動物、物體，也能讀取標誌。它透過機器學習與相應模型尋找視覺模式。
自動駕駛是一個例子：車上的攝像頭觀察周圍道路，系統分析影象，檢測交通燈、停車標誌、車輛和行人。文字稿以車輛周圍的全景觀察幫助說明這個過程。
其他常見用途包括人臉解鎖、X 光影像分析、監控攝像頭、能夠移動並感知環境的機器人，以及體育直播中的視覺分析。
譯註：具體車輛的感測器、覆蓋範圍和安全能力取決於實際系統，不能從這個概念例子推斷任何產品已經可靠實現全部能力。個人是否從事該領域的介紹已去除。
影片文字稿十一：自然語言處理
自然語言處理，簡稱 NLP，研究計算機如何處理人的語言交流，包括說、讀、寫等活動。Siri、Alexa 等助手是容易接觸到的例子。
這一領域涉及廣泛的研究方向，相關工作遠早於成熟商業服務。文字稿回顧了 20 世紀 70 至 80 年代的研究，以及大約 1991 年出現的 Dragon Dictate 語音聽寫產品。它把早期產品描述為價格昂貴、錯誤較多，並提到後來相關企業被收購。
譯註：原字幕對早期授權價格給出約一萬二至一萬四千美元的口述估計，又猜測它與今天辦公軟體的關係，沒有提供支援資料。這裡保留這些資訊的歷史與不確定性質，不把口述價格或產品關係視為已核實事實。
NLP 不只涉及聲音，也包括文字預處理。一個例子是在使用者介面與大語言模型之間增加處理層，對提示詞先做質量檢查，再交給模型。
Python 的 Levenshtein 相關庫可以用於比較字串差異，例如查詢常見拼寫偏差。在有明確規則的情況下，系統可以先修正常見錯誤，再將輸入發給模型，希望改善結果。
Signal、WhatsApp、Microsoft Word 等應用裡的語言相關功能，也可以幫助理解這個領域覆蓋面很廣。
譯註：編輯距離只衡量字串差異，不能單獨承擔完整語法理解或事實核驗；是否自動改寫使用者輸入，也要避免改掉原意。字幕中的庫名按語境規範為 Levenshtein。
影片文字稿十二：強化學習
強化學習透過嘗試行動、接收反饋來學習。行動帶來較好的結果時獲得獎勵，較差結果則可能得到較低獎勵或懲罰。這有點像用反饋訓練動物完成動作，但只是幫助理解的類比。
系統逐漸學習哪些行動更可能帶來較高回報，並據此改善選擇。遊戲、機器人、自動駕駛研究，以及某些推薦系統，都可能用到這種方法。
原講解說明這一段是概念介紹，而不是該領域的個人實施經驗；這裡不保留個人經歷署名。
譯註：獎勵是人為或系統定義的訊號，不一定等於真正希望實現的長期目標。也不是所有遊戲、駕駛或推薦系統都採用強化學習。
影片文字稿十三：回顧與時間背景
剛才涉及的內容很多。有一個時間背景需要記住：這段文字稿錄製於 2025 年第二季度。所介紹的服務和演算法應用，尤其生成式 AI，當時都處於快速變化之中。
大量資金和研究投入使這個領域持續變化。過一年或幾年，服務形態可能已經不同。
因此，如果準備在實際專案裡使用這些服務，就要把技術更新考慮進去，不能只根據錄製當時的介紹決定長期方案。
接下來的系統閱讀會繼續討論資料基礎與隱私。服務能做什麼是一部分，能夠取得什麼資料、如何使用、如何驗證，同樣決定實際效果。
擴充套件文字稿一：把 AI 接到自己的業務
前面討論的是開箱即用的能力。接下來轉向怎樣結合自己的資料、語氣與規則，定製 AI 系統。提示工程、檢索增強、微調、嵌入和函式呼叫，都是可以使用的方式。讓系統更貼近業務，需要理解這些方式分別改變什麼。
擴充套件文字稿二：提示工程
提示是告訴 AI 你想做什麼的方式，但不只是提出一個問題。可以把它組織成有結構、有目的的資訊，包括指令、問題、背景、理想回答的例子，以及不應越過的邊界。
許多聊天介面使用不同角色。系統角色規定總體行為，例如“你是一名有幫助的助手”；把角色描述改成某個專業領域，可能改變回答風格，但不能因此賦予系統真正的專業資格或保證準確。
使用者角色是人透過應用提出的請求。助手角色則用於表示已有的模型回覆。持續對話之所以能夠引用前文，是因為應用管理和傳遞相關歷史；不能把介面的連續對話感，直接當成模型自動儲存了全部記憶。
譯註：原講解說“助手角色用來序列化全部歷史”，需要更精確地區分：歷史通常包含使用者、助手和工具等多種訊息；應用可能重新傳送、壓縮或透過狀態機制管理它們。模型引數記憶、當前上下文和應用的長期記憶，也不是同一個機制。
同一個模型會因提示組織不同而給出不同結果。“天氣如何？”與“你是一名開朗的旅行規劃助手；巴黎這個週末天氣怎樣，建議帶什麼衣服？”在背景、任務、語氣和輸出需求上都不同。查詢當前天氣仍須取得實際天氣資料，不能單憑角色描述獲得實時事實。
寫提示時，明確角色和格式，提供期望示例，設定邊界，例如只根據下方資料回答，再根據結果不斷調整。有效提示往往清楚、簡單、一致，並圍繞具體目標設計。
也可以把多個提示串聯、傳遞變數、儲存模板。提示工程既需要設計，也需要透過實際輸出驗證。
擴充套件文字稿三：RAG，讓回答前先找到資料
RAG 是檢索增強生成。如果希望 AI 回答前先檢視內部檔案或知識庫，就可以考慮這種方式。
語言模型一次能夠處理的上下文有限，輸入越多也可能增加費用。指令、問題和對話歷史都會佔用上下文；對話增長時，不應只計算使用者剛輸入的幾個字。
譯註：原講解把常見視窗說成約 4,000 token，並近似成 4,000 個詞，反映較早背景且不準確。模型的視窗差異很大，token 也不等於詞。具體容量和計費應查詢實際模型；把整個資料庫都放入一次輸入，仍可能因長度、成本和噪聲而不合適。
RAG 通常先整理文件、表格或常見問題，切成適當片段並建立索引。使用向量檢索時，嵌入模型把片段表示為向量，向量資料庫儲存並支援查詢。使用者提問後，應用先查詢相關片段，再把問題與選出的片段一起提供給生成模型。
檢視圖解文字說明
資料準備路徑包括整理分塊、保留版本許可權後設資料和建立索引。問答路徑從問題與查詢者許可權開始，檢索當前可用的片段，交給模型組織回答，再核驗事實與引用。找不到證據、選錯版本和生成失真屬於不同問題。
圖中上方是提前整理與索引資料，下方是提問時檢索和回答。重點在於給出相關依據，不是每次傳送全部資料。
原講解強調這種方式的效率、用量控制與更新便利：只傳必要內容，資料變化時更新索引，不一定需要重新訓練。客服可查詢重置密碼步驟；銷售可查詢最新數量折扣；合規問題可定位資料保留政策的段落。
譯註：RAG 不自動保證更快、更便宜、更私密或回答正確。檢索片段仍可能傳送到模型服務商；必須管理許可權、日誌、更新和引用。它也不是讓模型“學會”新事實，而是由應用在當前請求中提供依據。需要比較端到端時延、質量和費用。
不要只是把資料堆給模型，而要設計檢索、來源與檢查流程，使業務資料能夠按需被使用。
擴充套件文字稿四：微調
如果提示與資料檢索仍不能滿足任務，可以考慮微調：以預訓練模型為基礎，使用自己的示例繼續訓練，改變其某些行為模式，例如詞彙、語氣、格式與任務響應方式。
法務團隊可能希望文書更接近內部格式，醫療相關係統可能需要處理特定編碼，軟體團隊可能希望文件遵守內部風格。這些都是定製目標，不代表訓練後必然像領域專家一樣可靠。
原講解說“結果恰好符合預期”，應理解為目標，不能當作保證。微調仍可能幻覺或出錯，也不適合取代持續更新的事實庫。
它較適合擁有大量結構化、高質量示例，需要更穩定行為或特定輸出方式的情境。它通常增加技術、評價與維護投入，因此應先確認是否確實需要。
微調、提示與 RAG 可以組合：用示例調整行為，用提示說明當前任務，再透過檢索提供最新資料。三者改變的層面不同。
檢視圖解文字說明
提示與示例組織當前任務輸入；RAG 為這次輸入補充外部證據，通常不改變模型引數；微調在訓練階段使用樣例調整引數，之後用新版本執行推理。事實、行為和格式缺口應分別診斷。
擴充套件文字稿五：函式呼叫與工具呼叫
函式呼叫把對話與實際業務能力連線起來。例如，詢問本月按產品線劃分的收入，不應讓模型憑空猜數字，而可以查詢報表介面，再根據實際返回內容回答。
開發者先定義可呼叫功能，例如查詢天氣、客戶詳情、郵費，或者按月份和地區查詢銷售。模型並不自己執行這些程式碼；它根據提供的工具說明，生成包含函式名稱與引數的呼叫請求。應用檢查並執行，再把結果傳回，模型據此組織回答。
原演示用旅行問題說明中間過程：使用者說“這周可能去溫哥華，應該帶什麼？”系統提供了日期時間，以及可用天氣函式的說明。模型識別到問題需要天氣，提出以溫哥華為地點的請求；應用取得未來天氣資料，再交給模型，回答才結合溫度和降雨提出外套、鞋與雨傘等建議。
譯註：原示例函式名稱寫作“當前天氣”，返回卻包含未來 24 小時預報。如果使用者問一週行程，應檢查返回時間範圍是否覆蓋需求。模型補全地點也可能選錯，應用需要驗證，不能把推斷引數直接當作事實。
工具呼叫是多步過程，可能包括不止一次模型請求，因此費用也要計算中間呼叫、上下文和重試，不能只看最後答案的長度。
連線內部資料庫、排程、分析或 ERP 以後，系統可以成為業務邏輯的對話入口。它還可以配合多步提示和結構化輸出，在執行前追問缺少條件。
檢視圖解文字說明
應用負責接收模型建議，檢查使用者授權、引數與業務規則，再執行工具。未透過的請求停止或請求澄清。真實執行結果要回傳並核驗；寫操作還需要防重複和可恢復設計。
模型提出呼叫，應用負責許可權、引數與實際執行，最後檢查返回狀態。尤其是修改資料、付款或發出訊息等操作，需要與後果相稱的邊界；生成“已完成”的文字不是執行成功的證據。
擴充套件文字稿六：嵌入與可查詢的表示
如果把 RAG 比作查詢資料的策略，嵌入可以看成幫助確定查詢方向的地圖。它把內容表示為向量，也就是一組數字，使語義關係可以被計算和比較。
原文以 PDF 和 CSV 為例。實際通常需要先提取內容、按任務切分，再使用嵌入模型計算向量並寫入合適索引，而不是把任何二進位制檔案原樣交給同一個文字介面。
提問時，系統在已有表示中查詢語義相關片段，不必要求每個詞完全一致。例如，“尋找入職相關資料”可以找到不同措辭的文件。
嵌入還可用於聚類、推薦、近似或重複內容檢測。原講解把它形容成“向量指紋”，這是幫助理解的比喻；它不是保證唯一、不可逆或可作密碼學驗證的指紋。
它不替代訓練或微調，而提供另一種組織和查詢資料的能力。使用時要確保查詢與資料的表示可比較，持續處理許可權、版本、刪除與檢索評價。得到向量，只是搭建可靠搜尋流程的一步，不表示已經能解決所有查詢。
擴充套件文字稿七：MCP 在連線中扮演什麼角色
原講解介紹模型上下文協議（Model Context Protocol，MCP），用“膠水”或“信封”的比喻，說明如何組織並向 AI 應用提供工具、資料與提示。它還舉出銷售、支援、人力或程式分析等不同角色，強調上下文應清楚、可複用，並指向公開協議資料。
譯註：原文把 MCP 近似成給模型傳送角色、規則和記憶的統一提示封裝，這不是協議的準確技術定義。MCP 更具體地規定客戶端與服務端怎樣交換能力，使宿主應用可以發現和使用工具、資源與提示；它不會自動建立模型記憶，也不保證輸出安全或可預測。
檢視圖解文字說明
宿主是 AI 應用，負責管理模型使用方式和多個客戶端。圖中客戶端 A 連線資料服務端，客戶端 B 連線工單服務端；服務端可以暴露工具、資源或提示。連線方式統一不表示訪問範圍、事實與執行安全自動得到保障。
圖中宿主管理客戶端，每個客戶端連線相應服務端。服務端暴露限定能力，宿主仍負責決定把什麼提供給模型，以及怎樣執行許可權和確認邊界。
可以從 MCP 官方文件繼續查詢協議與元件。它與提示、RAG、嵌入及工具呼叫可以配合，但不能把這些概念混成同一件事。
關聯閱讀
比較現成服務時，可以繼續看供應鏈與選型條件；需要理解檢索如何進入回答，則可對照RAG 與業務知識。
參考與延伸閱讀
以下為編輯補充的查詢與學習入口，可按需要繼續閱讀。
- scikit-learn 官方使用者指南（英文／技術文件）：按任務查詢分類、迴歸、聚類、異常檢測與模型評估。
- Google：定義模型目標、輸出與成功指標（中文）：把期望的業務結果、模型輸出和衡量標準對應起來。
- Google：推薦系統概覽（中文）：理解為什麼需要推薦，以及推薦系統怎樣幫助使用者發現內容。