閱讀目標與導言
本頁為中文譯文。我們將梳理 AI 服務供應鏈，學習怎樣發現、比較與選擇服務，並認識讓通用模型使用組織資料的不同方式。
選擇工具前，先分清：你是在購買計算基礎設施、模型、開發工具，還是已經面向業務的應用？不同層解決的問題不同。
一、AI 服務供應鏈概覽
原資料從 AWS、Google、Microsoft、IBM 等提供商出發，比較基礎設施、工具與平臺，再觀察 OpenAI、Anthropic、Hugging Face 等模型和生態，以及資訊檢索、分類等專用服務。
目的不是列出永久排名，而是讓採購與開發選擇有一張地圖。模型的開放程度、能力、許可、支援方式與成本，都要針對實際專案檢查。
二、怎樣尋找與評價商業服務
先說明用途、資料種類、效能要求、預算、是否需要私有資料，以及團隊技術能力，再比較表現、費用、整合、隱私與擴充套件。
商業服務可能減少自行開發，但不應先假定現有產品一定適合。銷售演示與實際資料上的結果，是兩種不同證據。
三、讓通用模型結合自己的資料
提示工程在當前輸入中提供任務與邊界；RAG 提供相關檢索資料；微調使用示例調整模型行為；嵌入支援內容表示與檢索；工具呼叫連線實際系統；MCP 規範一類能力連線方式。
正文中的技術摘要與AI 服務與演算法的七段擴充套件文字稿共享完全相同的字幕資料，完整譯文統一儲存於該頁。本頁保留供應鏈、選型和小結等不同講解。
譯註：原概覽把 MCP 說成“管理模型輸入的新標準”，範圍不夠準確。它用於 AI 應用與外部能力的標準化連線，不自動提供記憶或保證安全。完整的原講解與修正見上述擴充套件章節。
影片文字稿一：供應商分別處在哪一層
我們先做一張 AI 服務供應鏈的地圖：有哪些提供者，他們提供的是模型、系統工具、基礎設施、框架，還是開發工作臺？它們有什麼差別？理解這些，才能更有依據地選擇服務。
從基礎設施開始。AWS、Microsoft Azure 和 Google Cloud 等，除了計算與儲存，也提供更高層開發環境，讓資料人員與開發者把能力做成實際應用。
原講解以較熟悉的 AWS SageMaker 為例，談到服務商把內部使用的開發工具逐漸做成商業平臺的過程，也提到約 2017 年的早期釋出時間。這是歷史背景介紹，不代表當前產品形態完全相同。
隨著市場成熟，很多工不再需要從頭製作模型。原演示者描述，在一段時期內，自己的客戶專案更多使用現成能力，較少自行訓練。這是個人專案經驗，不能推斷所有需求都有現成答案，也不意味著訓練和演算法研究已經不重要。
但在開始建設以前，值得先認真查詢：是否已有合適服務？有時要重新把問題定義清楚，才容易找到適配方式。
雲平臺與整合環境
AWS 的 SageMaker 與 Bedrock 展示不同層次：前者面向機器學習開發等流程，後者提供基礎模型訪問與應用能力。統一入口可能減少一部分接入工作，但應該主動比較，而不是因為不知道某個選項，就無意中錯過它。
原講解在舉模型提供者時有較寬泛說法。當前究竟支援哪種模型、功能和地區，應查詢正式目錄，不把舊概覽當成完整清單。
Google Cloud 與 Vertex AI 同樣涉及構建、訓練、部署以及使用已有模型。組織本來使用哪個生態，會影響交接與執行。原演示者說，有些專案進入 Google 環境，是因為客戶本來就用它，延續相同環境較容易；個人熟悉的路線則可能不同。這說明團隊與客戶條件也會影響選擇，不是客觀效能排名。
Microsoft 生態較重的組織，會認真考慮 Azure。IBM 則被用來說明垂直行業方案，例如金融、製造和其他專門領域。如果專案屬於規則明確、專業要求較強的情境，可以在調查階段檢視相應行業能力；仍須驗證具體服務，而不是憑公司名稱判斷適用。
生成式模型提供者
原講解轉向當時快速發展的生成式生態，把 OpenAI 描述成通用、易用方向；把 DeepSeek 描述成可比較的另一類服務，並提到某些介面形式相容，可以降低試驗不同提供者時的改程式碼工作。
介面相容有範圍，不能據此認為所有引數、模型、工具和輸出完全一樣。資料中關於某個服務“還不到一年”等說法，也需要放回具體產品與錄製時間，不能當作公司歷史的準確陳述。
它接著提到 Anthropic 對安全的重視、Google DeepMind 的研究，以及 Meta 的模型生態。原文把 Meta 或某些 Mistral 模型統稱為開源，需要進一步區分開放權重、具體許可證與實際使用條件；也不能由平臺擁有某類資料，就推斷某個模型必然使用了全部資料。
Cohere 被用來說明面向業務和語言應用的路線，Mistral 被用來討論輕量與效率方向。這些是原資料的概括，不是所有版本的固定特徵，也不等於已經完成同條件評測。
Hugging Face 提供大量模型、開發工具與相關資料。進入模型目錄時，可檢視適合任務的模型、模型卡、評測與許可。有些專用模型使用特殊資料訓練，可能值得進一步研究；但數量增長或排行榜位置，不自動證明適合自己的資料。
原講解最後再次提到 Vertex AI、Bedrock 和 Azure 的機器學習環境，提醒：在決定自己從零做以前，應當知道有哪些成熟工具可以選擇。需要自己構建時，也應是經過比較後的決定，而不是沒有發現其他選項。
影片文字稿二：發現、比較與選擇
怎樣為專案選擇 AI 或機器學習服務？許多服務透過 HTTP API 提供，團隊需要理解請求、響應和 JSON 等結構化格式。原文也提到 YAML，但具體介面接受什麼格式仍由文件決定。
不要先假定必須自己造，也不要先假定現成服務一定合適。應先發現候選者，再確認條件、測試與選擇。
把問題寫清楚
你在解決什麼？翻譯、聊天、Agent、視覺識別、推薦、摘要，還是客戶行為分析？不同問題需要不同能力。若問題不清，就難以選工具。
可以寫成“按主題標記客服郵件”。這比“在公司採用 AI”更簡單、具體，也更容易評價。
理解資料與要求
資料是文字、影象、聲音、影片，還是表格和數字？它是否已經取得，是否有標籤，是否清理，能否使用？再好的模型也不能自動修復全部錯誤資料。
原文以文字模型、視覺識別與語音服務舉例，說明先按任務尋找候選方向，再實際測試。
要求也要具體：是否實時？準確與速度怎樣取捨？使用者是十人、一百人還是更大規模？是試驗、最小可行產品，還是正式企業系統？需不需要技術支援與服務級別協議？六個月以後增加使用，系統怎樣擴充套件？
這些直接影響預算和方案。不能只根據開發時少量呼叫的費用判斷長期投入。
私有資料與團隊能力
任務是否需要自己的產品、文件或內部規則？識別常見物體，與識別某一組織的專用物品，並不一樣。如果需要私有背景，可以研究檢索、嵌入、微調或工具查詢，具體支援範圍要按服務確認。
誠實認識團隊能力。有機器學習工程人員，還是應用開發人員？是否熟悉 API？若不熟悉，可能先採用較簡單的介面或現成上傳方式。不能讓技術路線與可維護能力脫節。
技術較少的團隊，尤其應關注現成模型、清楚文件、適合語言的 SDK 與支援。工具複雜度不能超過團隊能夠掌握和維護的範圍。
五項比較
第一，效能與質量。它在自己的資料上是否有效？不要依靠銷售宣傳，應執行樣本，條件允許時與競爭方案用同樣標準比較。
第二，價格與限制。按呼叫、token 還是固定月費？試驗便宜、部署後是否增長很快？在作出承諾前看清成本結構、上限與額外步驟。
第三，實施難度。介面、文件、程式碼庫是否清楚？支援團隊熟悉的語言嗎？若整合需要數週，或需要大幅重新培訓，仍然值得嗎？
第四，隱私與適用要求。資料在哪裡、是否加密、誰能夠訪問，是否涉及跨境限制？醫療、金融等領域尤其需要認真確認。服務商自稱滿足某種規範，不替代具體專案的判斷。
第五，速度與擴充套件。使用量增加以後會不會變慢，是否支援需要的併發與服務條件？不僅看現在，也看後續需求。
把這些連線起來：定義問題，理解資料和要求，瞭解團隊，再根據表現、費用、整合、隱私和擴充套件比較。發現已有能力、測試、調整並整合，是建設的一部分；不必把所有環節都從頭開發。
影片文字稿三：RAG 與精確業務查詢的取捨
在前面幾種定製方式中，原講解特別常比較 RAG 與函式呼叫。向量檢索能很快提供相關上下文片段，但對資料的結構和精確範圍，不一定像業務查詢一樣可控。
例如，“顯示上季度銷售報告”往往意味著具體時期、欄位和計算口徑。檢索片段可能有用，卻未必正好構成需要的完整報表。
把相關片段放進提示，再要求模型依據它們回答，可以用較少開發工作取得一些效果。但如果要求非常精確的資料包和格式，可能需要程式明確查詢、校驗和組織結果。
函式呼叫提供這條路線，通常需要更多介面工作與開發能力。它也不是天然正確，仍要核對引數、許可權、時期和返回值。
因此，快速建立背景問答時，可以研究 RAG；需要精確業務資料時，可以增加工具查詢。兩者能夠組合，選擇取決於實際需求，而不是固定哪一種更高階。
關聯閱讀
需要多步執行時，繼續讀業務 Agent；服務之間怎樣實際連線，見MCP 與 API。
參考與延伸閱讀
以下為編輯補充。
- AWS Bedrock：支援的基礎模型：英語，查詢實際模型與區域，避免把舊介紹當成當前目錄。
- Google Vertex AI 文件：中文，查詢開發與模型服務能力。
- Hugging Face 模型卡說明：英語，瞭解用途、限制、資料與許可資訊應在哪裡查詢。
- MCP 官方入門：英語，區分協議連線與提示、檢索和模型記憶。