AI 工具越來越多，真正讓人卡住的常常不是功能，而是名詞。
有人說要用大型語言模型（Large Language Model，LLM），有人說要做檢索增強生成（Retrieval-Augmented Generation，RAG），再過一下又出現 AI 代理、MCP、Embedding、Token、Context Window。每個詞都像在講不同技術，但放回企業應用裡看，其實大多是在回答幾個很實際的問題：
- AI 用的是什麼模型？
- 你怎麼把任務說給它聽？
- 它怎麼取得公司的資料？
- 它只能回答，還是可以真的去操作系統？
- 這套做法會影響多少成本、風險與維護工作？
這篇不走工程課本路線，而是用企業主做決策時會遇到的情境，整理 20 個常見 AI 名詞。你不必記住所有技術細節，只要看到供應商簡報、軟體方案或 AI 導入提案時，知道自己該問什麼。
第一組：先搞懂 AI 模型到底在做什麼
1. 人工智慧（Artificial Intelligence，AI）
人工智慧是最大的總稱，泛指讓電腦執行原本需要人類判斷、辨識、預測或處理的工作。推薦系統、語音辨識、影像辨識、生成文字，都可以屬於 AI。
對企業主的意義：看到「有 AI」不能直接判斷產品好不好。要繼續問：AI 到底負責哪一段工作？只是分類，還是會產生內容、判斷資料，甚至執行動作？
2. 機器學習（Machine Learning，ML）
機器學習是人工智慧的一種方法，讓系統從資料中找出規律，而不是只按照工程師事先寫死的每一條規則執行。
對企業主的意義：銷售預測、異常偵測、客戶分類等功能，常會用到機器學習。這類應用的品質和資料品質通常密切相關，不是只換一個模型名稱就會自動變準。
3. 生成式 AI（Generative AI）
生成式 AI 的特點是產生新的內容，例如文字、圖片、音訊、影片或程式碼。現在常見的 AI 助理、圖片生成與內容工具，大多屬於這一類。
對企業主的意義：它很適合初稿、整理、改寫、發想與內容處理，但「能生成」和「內容一定正確」是兩回事，重要資料仍要有查證或資料來源。
4. 大型語言模型（Large Language Model，LLM）
大型語言模型是以大量文字資料訓練，能處理與生成自然語言的模型。它擅長根據上下文預測接下來合理的內容，因此可以摘要、問答、翻譯、寫作與分析文字。
對企業主的意義：語句流暢不等於事實正確。評估 LLM 應用時，不只要看它「會不會講」，還要看資料從哪裡來、錯誤怎麼被發現。
第二組：你怎麼把工作交給 AI
5. 提示詞（Prompt）
提示詞就是你給 AI 的指令、問題與必要背景。好的提示不是堆很多神祕咒語，而是把目標、資料、限制、輸出格式與判斷標準說清楚。
對企業主的意義：同一套 AI，輸入不清楚，結果就容易不穩。與其一直換工具，先把公司的工作規則與需求寫清楚，通常更有用。
6. Token（詞元）
Token 是模型處理文字時使用的基本單位。不同模型切分文字的方式不同，很多 API 服務會依輸入與輸出的 Token 數量計價。
對企業主的意義：大量文件、長對話、很長的系統指令都可能增加用量。評估 AI 成本時，不能只看月費，也要確認是否另有依使用量計價。
7. 上下文視窗（Context Window）
上下文視窗是模型在一次請求中能處理的內容範圍，通常以 Token 計算。指令、對話紀錄、附加文件、工具結果與模型輸出，都可能占用這個範圍。
對企業主的意義：上下文越大，不代表可以永遠把所有資料全部塞進去。真正的企業應用仍要考慮成本、資料相關性與檢索方式。
8. 幻覺（Hallucination）
幻覺指的是 AI 產生看似合理、實際上錯誤或沒有根據的內容。它可能把不存在的資料、日期、規則或來源講得很肯定。
對企業主的意義：客服、報價、法規、醫療、財務或公司政策等高風險內容，不能只靠「AI 看起來很有自信」就直接採用。要加入資料依據、驗證與人工確認。
第三組：讓 AI 使用公司的資料
9. 檢索增強生成（Retrieval-Augmented Generation，RAG）
RAG 的做法，是在模型回答前先從指定知識來源找出相關內容，再把找到的資料提供給模型作答。模型本身不必重新訓練，就能使用較新的公司文件或專業資料。
對企業主的意義：如果目標是讓 AI 根據產品文件、FAQ、內部知識或服務規則回答，RAG 常是比「重新訓練一個模型」更直接的選項。
10. 資料依據（Grounding）
資料依據指的是讓模型的回答連結到可驗證資訊來源。RAG 是其中一種做法，也可以透過搜尋、資料庫或其他可信資料來源替回答提供根據。
對企業主的意義：採購 AI 客服或知識助理時，可以直接問：「它的回答根據哪裡？能不能指出來源？資料更新後多久會生效？」
11. 嵌入（Embedding）
嵌入是把文字、圖片或其他資料轉成數字向量，讓系統可以比較內容之間的語意相似程度。它是語意搜尋與許多 RAG 系統的重要基礎。
對企業主的意義：你通常不需要自己操作嵌入，但它解釋了為什麼 AI 可以在沒有完全相同關鍵字的情況下，仍找到意思相近的文件。
12. 向量資料庫（Vector Database）
向量資料庫是用來儲存與搜尋向量資料的系統，常和嵌入一起使用。使用者提出問題後，系統可以找出語意上最接近的內容。
對企業主的意義：當廠商說要做「企業知識庫」，要繼續確認資料怎麼切分、多久更新、權限怎麼管，而不是只聽到「用了向量資料庫」就認為答案一定準。
13. 微調（Fine-tuning）
微調是用特定任務的範例資料，進一步調整既有模型的行為。它可以讓模型更穩定地遵守某些格式、語氣或任務要求，也能針對特定工作提升表現。
對企業主的意義：微調不是 RAG 的同義詞。要補充公司最新知識，通常先看檢索與資料來源；要改善固定任務的行為與輸出模式，才進一步評估微調是否值得。
第四組：讓 AI 不只回答，還能實際做事
14. 多模態（Multimodal）
多模態指模型能處理不只一種資料形式，例如文字、圖片、音訊與影片。現在不少 AI 應用已經不是只靠打字互動。
對企業主的意義：會議錄音整理、圖片判讀、文件理解、影片摘要等工作，都可能因多模態能力而減少人工轉換資料的步驟。
15. AI 代理（AI Agent）
AI 代理不只是回覆一句答案，而是會根據目標規劃步驟、使用工具、讀取結果，再決定下一步。不同產品的自主程度差異很大。
對企業主的意義：如果 AI 只提供建議，風險通常比較低；如果它能寄信、改資料、建立訂單或操作後台，權限、審核與復原機制就會變得很重要。
如果你想進一步分清楚「AI 代理」和真正對客戶提供的「AI 服務」，可以看AI 代理與 AI 服務有什麼不同？。
16. 函式呼叫／工具使用（Function Calling / Tool Use）
函式呼叫是讓模型以結構化方式選擇外部工具或功能。例如查訂單、讀 CRM、建立行程，都需要模型和外部系統之間有明確的操作介面。
對企業主的意義：「AI 能做事」的背後通常不是模型自己憑空完成，而是被允許呼叫既有系統。你需要知道它能呼叫哪些工具，以及哪些動作需要人工確認。
17. API（應用程式介面）
API 是軟體彼此交換資料或執行功能的一種介面。AI 系統常透過 API 連接 CRM、網站、金流、表單、行事曆或其他服務。
對企業主的意義：如果兩套工具完全不能交換資料，很多自動化最後仍要靠人工搬運。評估軟體時，除了功能本身，也要看它是否提供合適的整合方式。
18. 模型上下文協定（Model Context Protocol，MCP）
MCP 是一套讓 AI 應用以較一致方式連接工具、資源與提示的開放協定。它的價值在於降低每個 AI 應用都要為不同資料來源重新做一套專用連接的負擔。
對企業主的意義：MCP 本身不會自動讓流程變安全。真正要看的仍然是連接了哪些系統、開放哪些權限，以及哪些動作可以直接執行。
第五組：把 AI 放進實際營運與行銷
19. 自動化工作流程（Workflow Automation）
自動化工作流程是把多個步驟串成可以依條件自動執行的流程，例如表單送出後建立客戶資料、寄出通知、建立任務並提醒負責人。這種流程不一定需要 AI。
對企業主的意義：AI 適合處理需要理解文字、分類、摘要或判斷的環節；固定規則則可以交給一般自動化。不是每一步都塞 AI 才叫先進。
20. 答案引擎優化／生成引擎優化（AEO / GEO）
AEO、GEO 是近年內容行銷常見的業界用語，指的是讓搜尋與生成式 AI 更容易理解、擷取並正確呈現網站內容。不同業者對名稱與範圍的定義不完全一致，因此不宜把它當成一套已完全標準化的技術規格。
對企業主的意義：重點仍是內容是否清楚、可驗證、來源完整、實體資訊一致，而不是在文章裡多塞幾個 AI 關鍵字。如果你正在做 AI 搜尋內容，也可以延伸看Google SGE、AI Overviews、AI Mode 與 AI 搜尋 SEO 完整指南。
把 20 個 AI 名詞串起來，其實就是一條工作流程
假設你想做一個公司內部的 AI 知識助理，整條流程可以這樣理解：
- 員工輸入一段提示詞，文字會被模型切成 Token。
- 系統把問題轉成嵌入，到向量資料庫找出相關文件。
- 把找到的內容當作回答資料依據，這整套先檢索再生成的方式就是 RAG。
- 資料和問題一起送進 LLM，總內容不能超出它的上下文視窗。
- 如果只要回答問題，到這裡就可能完成；如果還要改 CRM、建立任務，就需要工具使用、API，甚至由 AI 代理規劃多個步驟。
- 若不同系統希望用較一致的方式把工具提供給 AI，可能會使用 MCP。
這樣看就會發現，多數 AI 名詞不是各自獨立的流行語，而是同一套系統裡的不同零件。
企業主跟 AI 廠商談方案，先問這 6 個問題
- AI 到底負責什麼？只是產生文字，還是會真的執行動作？
- 回答根據哪裡？模型自己的知識、網路搜尋，還是公司的文件？
- 資料送到哪裡？哪些資料會離開公司系統，保存多久？
- 出錯怎麼處理？有沒有人工確認、權限限制、紀錄與復原方式？
- 費用怎麼算？月費、席次、Token、API 用量、資料庫與維護是否分開計費？
- 未來能不能換工具？資料與流程是否被綁在單一供應商，還是能透過 API、標準格式或其他方式移轉？
你不需要變成 AI 工程師，但至少要能把這 6 個問題問清楚。因為真正影響投資回報的，往往不是模型名稱，而是資料、流程、權限、成本與責任有沒有設計好。
常見問題
AI 名詞這麼多，企業主最先要懂哪幾個？
如果時間有限，先懂 LLM、Prompt、Token、Context Window、幻覺、RAG、AI Agent、API。這幾個詞已經足以幫你看懂多數 AI 工具與導入提案的基本架構。
RAG 和微調哪一個比較適合企業？
要看問題。若重點是讓 AI 使用可更新的公司文件與知識，通常先評估 RAG；若重點是讓模型在特定任務上更穩定地遵守輸出格式、風格或行為，再評估微調。兩者也可以搭配，不是非得二選一。
AI Agent 就等於自動化嗎？
不完全相同。傳統自動化多半按照事先定義好的條件執行；AI 代理則可能依目標、當下資訊與工具結果決定下一步。自主程度越高，越需要把權限與人工確認設計清楚。
MCP 會取代 API 嗎？
不會這麼簡單。API 是軟體服務提供資料與功能的基礎介面之一；MCP 則是讓 AI 應用以較一致方式使用工具與資源的協定。實際系統常會同時存在兩者。
只要用 RAG，就不會有 AI 幻覺嗎？
不會。RAG 能提供較明確的資料依據，但檢索可能找錯資料，文件本身也可能過期，模型仍可能解讀錯誤。重要流程仍需要測試、來源檢查與適當的人工作業。
結論：懂 AI 名詞的目的，不是跟工程師比術語
企業主不需要把每一個 AI 名詞背成考試答案。真正有用的是看到一個詞時，能知道它大概屬於「模型、資料、連接、執行、成本或風險」哪一層。
當有人說「這套系統用了 RAG、Agent、MCP」，你不需要被三個縮寫壓過去。你可以繼續問：資料從哪裡來？它可以做哪些動作？誰有權限？做錯能不能復原？費用怎麼算？
能問出這些問題，就已經比單純追最新模型名稱更接近真正的 AI 導入決策。
參考資料
Google Cloud｜Generative AI glossary｜2026年查閱
Google Cloud｜What are AI agents?｜2026
OpenAI｜Optimizing LLM Accuracy｜2026年查閱
OpenAI｜Create embeddings｜2026年查閱
Model Context Protocol｜MCP PHP SDK｜2026年查閱