ReaderMX.
瑞典马工

云用户需要什么样的 AI 服务? — AWS ML 服务试用

瑞马工在瑞典约 7 分钟

开场白

AWS CEO Adam Selipsky 最近接受采访的时候，不得不赞同：在这个人人都谈 AI 的时代，云计算已经是传统行业了。

Image

AWS也确实推出了不少 AI/ML服务，主要有三个类别：

  1. 即插即用的 AI 服务。

  2. MLOps 平台 SageMaker。

  3. LLM 集市 Bedrock。

MLOps 平台有极高的使用门槛，而 Bedrock 只是一个刚刚推出的模型集市，对于普通软件开发者来说，这两者差不多可以忽略。最具备可及性的是那些开箱即用的 ML 服务，其不完全列表如下：

Amazon Augmented AI 提供机器学习预测的人工审查; Amazon CodeGuru 推荐代码质量和性能; Amazon Comprehend 是一个自然语言处理服务; Amazon Forecast 用于时间序列预测; Amazon Fraud Detector 进行实时欺诈检测; Amazon HealthLake 是一个医疗数据湖服务; Amazon Kendra 提供智能搜索; Amazon Lex 用于创建会话机器人; Amazon Lookout for Equipment、Metrics 和 Vision 分别进行设备、指标和图像的异常检测; Amazon Monitron 提供端到端的设备监控; Amazon Personalize 用于个性化和推荐; Amazon Polly 将文本转换为语音; Amazon Rekognition 分析图像和视频; Amazon SageMaker Ground Truth 提供数据标记服务; Amazon Textract 从文件中提取文本和数据; Amazon Transcribe 是一个语音转文本服务; Amazon Translate 提供文本翻译; Amazon Deep Learning AMI 是机器学习的虚拟机镜像; Amazon DeepComposer、AWS DeepLens 和 Amazon DeepRacer 分别是深度学习音乐、相机和赛车相关的服务。

我个人的体验是：这些服务都不太行。

高昂的学习成本

AWS 强调你并不需要 ML 的专业知识就可以使用 ML 云服务，但是不好的消息是，AWS 添加了它自己的复杂度。以 Amazon Lex 为例，这是一个用于构建对话机器人的 NLP 服务，在写第一行代码之前，我要学习一套全新的概念模型，并且理解一堆半通不通的术语：Bot, Intent, Intent context, Slot, Slot type, Conversation context, Session attributes, Request attributes。

这套术语是如此的晦涩，以至于 AWS 中国都不知道怎么翻译它们了。在有的文档中，Intent被翻译成意图，而在另外一些文档中，又被翻译成目的。

作为对比，同样功能的 GPT Function calling 极为简单易懂，简单到 OpenAI 不需要一个术语表，而是直接给用户贴出代码：

Image

高昂的维护成本

以 Amazon Transcribe 为例，你可以实时的分析客服对话，以升级其处理。

使用类别事件，您可以根据确切的关键字或短语来匹配您的转录。例如，如果您为 “我想和经理说话” 这句话设置了Amazon Transcribe过滤器，则会筛选出该短语。

这个特性听起来不错，但问题是，客户有可能说的是

  1. 我要和经理说话，或者

  2. 我想和你经理说话，或者

  3. 我能不能和你的经理说一下，或者

  4. 你让你的经理接下电话吧，或者

  5. 哎呀，那我找你经理唠嗑去，或者

  6. 任意一种同样意思，但是不同语气/礼貌用词/时态的自然语言表达。

显然你需要花费无穷尽的精力为维护这个列表，只因为 AWS Transcribe API 只支持精确匹配。

产品和解决方案的模糊边界

上文提及的 API 是 Amazon Transcribe 的一部分，用于客服中心通话分析。它应该是一个解决方案，或者说是一个 SaaS，但是 AWS 做成了一个云服务。

如果有朋友合理的推断既然有售后呼叫云服务，那么也会有前台接待云服务，那么他又会失望，因为它并不存在。AWS 上能提供前台接待服务的是第三方产品 SwipedOn，他们正确的标识自己是一个 SaaS 提供商，而不是一个面向开发者的云服务。

同样的，Amazon Rekognition 提供了个人防护设备检测 API，可以用来检测来帮助确定建筑工地上的工人是否佩戴头罩，或者医务工作者是否佩戴口罩和手套。显然，这个 API 在2020年到2022年的中国无法使用，因为行业标准发生了很大的变化。

AWS 不提供钢铁行业专属虚拟机，或者金融行业专属 Lambda，而是提供业务无关的 building blocks， 把行业专属的问题留给解决方案和合作伙伴去解决。

但是 Amazon Transcribe 和 Amazon Rekognition 打破了这个惯例，把非常专业的行业专属问题嵌入到云服务中，这其实增加了客户的困惑。

重叠而不是正交的分工

Amazon Comprehend 是一个文本分析云服务。它可以通过识别文档中的实体、关键短语、语言、情绪和其他常见元素生成见解。

一个很自然的扩展需求支持客户自定义模型。Amazon Comprehend 也确实支持客户自定义实体识别和分类。

但是接下来 Amazon Comprehend 就有点过分了，还提供 Amazon Comprehend Flywheel 这个工具管理自定义模型的生命周期管理。而模型生命周期管理是另外一个 MLOps 服务 SageMaker 的定位。

同样的，Amazon Comprehend 本身的功能也被其他服务所重复。比如 Amazon Transcribe 定位本来是语音转文本服务，但是它又提供了和 Amazon Comprehend 同样的情绪感知功能。

受限并且不可预测的扩展能力

机器学习几乎不可避免的需要fine tuning，在这一块 AWS 服务的支持就非常让人困惑：

  1. Amazon Comprehend 支持用户训练自定义模型。

  2. Amazon Forecast 则只支持用户选择内置的算法。

  3. Amazon Transcribe 则更进一步限制用户只能提供词汇表。

  4. 对于 Amazon Polly，定制化几乎不可能，用户只能通过 SSML 指明重音和轻读。

效果不好最致命

只要 ML 服务质量足够好，上面说的这些问题都可以认为不关键。不幸的事，AWS 大多数开箱即用的 ML 服务效果，非常一般。

比如 Polly 的语音引擎只有两个：标准版和神经版（是的，AWS 就是这么翻译的）

Image

标准版质量在十年前也许还可以接受，但是在2023年，一个小学生都能听出它的合成腔调。神经版质量稍微高一些，但是只有普通话只有女声，没有男声。

作为对比，小公司 Heygen 不仅提供了几十种适用于不同场合的声音，并且支持你上传自己的声音加以克隆，甚至还支持视频对嘴型。在功能和质量上实在是 Polly 无法比拟的。

Image

Amazon Kendra 的表现同样也难以让人满意。在文档中，其号称

Amazon Kendra是一项智能搜索服务，它使用自然语言处理和高级机器学习算法从您的数据中返回搜索问题的特定答案。

但它的表现就像一个简单的向量数据库。对于语义上完全不同的两个问题，“2025年的市财政预算”和“2022年的市财政预算”， Kendra返回的是同一段结果。

  • 问它 2022年的预算，答案是这个。

Image

  • 问它 2025年的预算，答案也是这个。

    Image

缺乏说服力的客户成功案例

AWS 的客户成功案例，一般来说很有说服力，但在 ML 服务上，情况不太乐观。

我们可以检查《AWS Machine Learning 客户》上列举的几个案例。

  • 迪士尼案例，3M 案例，Amazon 电商案例

    这几个案例只提及了 SageMaker, EC2 和 S3 服务，可以合理的推测他们没有使用 AWS 的开箱即用 ML 服务。

  • Intuit 案例

    这个居然是个无效链接，烦请 AWS 中国的朋友修正。bug信息如截图:

    Image

  • T-Mobile 案例

    这个案例非常有趣，T-mobile用的是 Amazon SageMaker Ground Truth。这其实就是一个人力总包服务，T-mobile 通过 AWS 把给数据打标签的脏活外包出去。虽然它确实也是 AI 的一部分，但是不是一个通常意义上的云服务。

  • Cambia 案例

    Cambia 确实使用了开箱即用的 ML 服务 Amazon Textract，但是也显著的表示这是一个 PoC 项目，并没有投入到生产环境。

  • Discovery 案例

    只有 Discovery 案例明确的表示，他们使用了开箱即用的 Personalize 服务构建内容推荐服务。

考虑到开箱即用ML服务是 AWS 最早推出的 ML 服务类别，并且数量累计有二十多个，但是他们在客户成功案例中占比这么低，让人惊讶。

AWS 也不用自己的开箱即用 ML 服务

当然最让人震惊的是，AWS 似乎也不用自己的 ML 服务。

比如 Amazon Translate的文档从英文翻译到中文的时候，出现了一个很低级的翻译错误， 把 real time 翻译成“事实”，而不是“实时”。

Image

链接见：Amazon Translate 推出事实文档翻译[1]

而 Amazon Translate 的质量则是正确的：

Image

所以，合理的推测是：AWS 翻译 Amazon Translate 服务的文档的时候，很可能没有使用Amazon Translate 服务，至少没有使用最新版的 Amazon Translate。这就比较尴尬了。

当然更尴尬的是，如果 AWS 中文文档确实是用 Amazon Translate 翻译的，那么如下的翻译质量实在让人不放心。中文版甚至把英文 SageMaker Groud Truth 翻译（？）成英文 Gro SageMaker und Truth，您这还不如别翻译呢。

Image

总结

AWS 这一大套开箱即用 ML 服务，也被中国云厂商复制过去了。据我所知，市场反应也不理想。这其中固然有一些中国市场特有的原因，但是有一个问题值得研究：AWS 这种试图为用户屏蔽算法和数据复杂度的开箱即用云服务，会不会根本是一条错误的路线？在这个错误的路线上，你做得越多越辛苦，会不会越偏离目标？对此问题，我没有答案，还请对此有研究的读者朋友不吝赐教。

未来

在上文提及的同一个采访中，Selipsky 强调生成式 AI 仍然需要云计算。这个说法肯定是对的，但是Selipsky 的语气让我想起十年前，服务器厂家哀怨地说：“就算云计算飘到天上去，也还是需要服务器。” 每一代面临边缘化风险的厂家，都会用这个说辞安慰自己。

Image

大家都赞同云需要服务器， AI 也确实需要云，但关键问题是，在范式转移后，你会成为无足轻重的基础组件供应商，还是能够参与科技高溢价的分红者？

参考资料

[1]

Amazon Translate 推出事实文档翻译: https://aws.amazon.com/cn/about-aws/whats-new/2023/05/amazon-translate-document-translation/

KEEP THE THREAD GOING

更多来源文章