阅读目标与导言
本页为中文译文。我们将梳理 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 官方入门：英语，区分协议连接与提示、检索和模型记忆。