只要够有耐心总是能等到Meta贡献一些新的奇闻异事。这不据9月22日的爆料显示Meta已经在给员工测试一个新功能——让真人帮Muse用户打电话而这原本是AI功能。这项服务叫“human concierge”也就是“真人礼宾”。用户把任务交给MuseMuse可以再把部分电话请求交给外部承包商由真人拨打电话、把事情办完。目前报道揭露的是员工内部测试还不是向普通用户公开推出的服务但消息一传出来大家也没放过Meta。争议之下Meta已经紧急撤回这个计划。可不得撤回吗这一下就从性感的AI软件变成古早的电话代办服务了。年轻的朋友可能不知道零几年的时候国内外都流行这种服务比如中国移动2003年就和携程合作提供全国酒店、机票预订服务。上海还有个“订餐小秘书”每天帮打几千个订餐电话。网友的嘴没闲着已经有人开始拿外包成本开涮“菲律宾工人比token便宜。”还有人讽刺“人类驱动的AI果然是真实存在的。”“AI印度人辅助Assistant Indians。”最好笑的是不知道扎克伯格是不是对真人代打有什么执念十年前他就已经做过这种事了。真人代打员工都绷不住了Muse应用起飞的事情大家都知道了。上线十天它就冲上了美国App Store免费iPhone应用榜第一排在ChatGPT、Gemini、Claude甚至自家Instagram前面。到9月22日路透社援引Sensor Tower的数据称Muse上线以来的累计下载量已经超过250万。也就是说短短两周这款新产品就吸引了数百万次下载。它主打的就是可以帮用户做事发邮件、安排出行甚至替你打电话。但是在实际使用的过程中Meta发现了一个问题有些人一听是AI就挂电话这直接会影响任务成功率。一名员工就反映自己让Muse打电话给保险公司对方一听说是AI就反复挂断。在相关讨论帖中也确实可以看到网友表示“如果AI打电话到我的店里我真的会直接挂掉。”于是Meta不知道哪位神人灵机一动那俺们用真人打不就行了吗不管提出这个方案的神人是谁反正扎克伯格是点头了于是一项名为“human concierge”的真人礼宾服务就这样在Meta内部开始了测试。Meta还挺贴心的在内部通知里专门说如果不乐意参与测试可以加入一个专门的小组来退出测试。不就是个真人代打服务吗虽然有点土土的但能出什么问题问题大了。要知道Muse在推出的时候Meta可是专门强调过安全。按照官方介绍每个用户的Muse都有一台独立的云端虚拟机跟其他用户的运行环境隔离密码、支付凭证等敏感信息放在安全存储里Muse可以调用但看不到原文。用户还可以决定它能访问哪些应用、获得多大权限。那么如果把AI打电话变成真人代打那就有第三方承包商有第三方承包商用户的隐私就有了隐患。你愿意把事情交给AI处理不代表你也愿意让一个陌生人知道自己要办什么事、需要提供哪些个人信息。据404 Media报道有员工在内部讨论中反映参与测试的同事直到电话打完才被告知替自己打电话的是真人。此前提供信息时对方一直以为执行任务的是AI。面对员工的担忧Meta方面解释说承包商接受过大量培训以确保数据安全。但有员工直接指出培训不等于安全机制。还有人提醒如果真要推出至少应该让用户自己选择别默认开启。这话其实不难理解。告诉用户“这个人受过培训”和让用户事先知道“你的信息会交给这个人”根本不是一回事。除此之外还有一个问题就是真人代打背后是真人是有血有肉的人类是人类就有人类的不确定性。一名员工让Muse给网络和有线电视服务商打电话帮自己谈账单价格。结果查看通话记录时发现承包商的工作人员在电话里说出了带有种族歧视意味的表达。Meta随后向这名员工道歉并表示涉事人员今后不会再参与任何Meta项目。本来是想找个人来提高可靠性结果又得处理这个人带来的问题。这件事传出来Meta也是挺尴尬的毕竟Muse风头正盛结果又闹了这么一出。Meta超级智能实验室的一位副总裁承认在没有充分披露的情况下开始测试真人拨打电话是一次失误公司已经暂时撤回了这项功能。这里撤回的是内部测试的真人代打功能不是整个Muse也不是说所有AI电话功能都下线了。对外Meta则强调内部测试本来就是为了收集反馈在公开发布前完善安全和隐私保护。这项潜在功能只有准备好、做好适当披露之后才会推出。至于为什么非要加上真人Meta给出的理由还是成功率。那位副总裁表示在一些测试中真人拨打电话可以把成功率提高到95%至98%高于AI拨打电话的表现。可是吊诡的事情就在这提高成功率问题是加入真人之后提高的究竟是什么成功率对于只想把事情办完的用户来说有真人帮忙当然可能有价值。但真人把任务做成了不等于AI就学会了。要是用户连谁在替自己干活都不知道这个漂亮的成功率就更值得打个问号。让AI代打电话办事其实也不止Meta一家在做。谷歌早在2018年就展示过Duplex让AI通过电话预订餐厅、预约理发。商家不愿意接AI电话不能简单归结为人类对AI有偏见。至少从一些接电话的人反映的情况来看其实问题很实际就是AI还不够丝滑而且耽误事。有网友就表示自己在餐厅工作AI打来预约、询问餐厅是否繁忙的电话自己已经接过一阵子了。但机器人说话慢吞吞背景里还夹着一些听起来像刻意添加的环境音让人觉得它在模仿真人通话。偏偏这些电话又总在自己忙着招呼客人、接待客人的时候打进来。本来在餐厅工作就经常忙到脚底搓火星接到这种电话真的是令人崩溃。所以至少对于这类问题关键说到底还是AI要提高相关能力AI不够用人类来凑的思路恐怕得好好推敲了。扎克伯格咋就和“真人代打”杠上了看到是Meta闹了这么一出笔者已经扶额苦笑因为这公司在这方面是有前科的。那件事发生在十一年前而且简直是PLUS版本的闹剧。2015年公司还没改名叫Meta仍叫Facebook。当时Facebook已经在大力发展AI大名鼎鼎的杨立昆刚加入公司一年半的时间。在这样的背景下其旗下应用Messenger推出M助手。和今天Muse能做的事情很像用户给M助手发请求它可以代办比如订餐厅、改机票、买礼物送花等到。只不过当时用户和M助手之间是文字交流的。但是这个功能只给有限的用户开放测试并在不到三年后的2018年就关闭下线了。媒体扒出来一个惊人的数字——其实这个号称AI助手的功能整体的自动化程度不超过30%。换句话说就是M助手处理任务其实有70%都是真人给代办的。简单来说按照Facebook当时的官方介绍人类操作员会检查AI提出的回复再给出合适的回答AI则在一旁观察和学习。机器搞不定的事情也需要人来接手。比如用户要订花系统就要学会先问预算是多少再问送到哪里。Facebook打的算盘是先请一批真人把服务撑起来他们的处理过程同时成为训练材料。今天人教机器做明天机器自己做等AI学会的事情越来越多人工就能越来越少。但显然最终也没能成功完成AI更多接手并摊薄成本的目标。Facebook在发布M助手的时候其实不算完全隐瞒背后会有真人参与只是话说得比较暧昧说M助手由“人工训练和监督的人工智能”驱动。而且用户在使用的时候并不会看到任务是AI在做还是已经转交给了人类所以产品界面上看还是一个无所不能的AI助手在咔咔干。这件陈年往事和如今Muse的小闹剧如出一辙——AI代办成功率还不够就先让真人来凑。可是这真的是一条理所应当的路径吗模型做不到时到底是承认失败还是让真人躲在系统后面补位呢倒不是说AI一旦找人帮忙就犯了什么天条。人工服务当然可以做前面那些电话秘书公司也做了很多年。区别在于你到底是在卖一项有人帮忙的代办服务还是在展示一个已经有这么能干的AI“这件事办成了”和“这件事是AI办成的”毕竟不是一回事。每家大厂都有自己的基因和特性Meta似乎从来都不缺“执念”。小时候听过一个寓言故事说是国王要传位给所有人发了花种子说谁种出最漂亮的花就给谁王位。其实种子根本就发不了芽结果几乎所有人都拿来了很美的花只有一个诚实小孩拿着光秃秃的花盆来国王大喜传位之。我的意思是不管干什么Meta绝对不会是那个拿着光秃秃花盆的“傻孩子”。真人代办的古老笑话其实想想的话你以为是机器在帮忙办事其实背后是真人这个都市笑话已经流传很久了。相信大家都见过自动贩卖机里有个苦哈哈的牛马给你递可乐的畅想图吧。我很喜欢这个都市笑话因为它很好品。它既可以代表机器太强的时候人类自然而然地怀疑——这么厉害这么丝滑不会是背后有真人吧它也可以代表人类面对机器时不由自主的“拟人”本能还可以代表人类对替代自己的机器本能的防御心理。说句公道话Meta这次已经比以前进步很多了。以前它是偷偷摸摸混进去真人现在是明着告诉你有真人服务而且先在内部搞测试。引起争议之后也很快收手了。这几年还有更夸张的案例比如Builder.ai正所谓微软投资的AI公司背后竟是700名印度程序员。这家公司主打的是让不懂技术的人也能开发软件。用户说出自己的想法平台就帮忙把它做成应用旗下还有一个叫Natasha的AI产品经理。开发软件像点披萨一样简单听起来是不是很美好但后来媒体揭开的后台就没那么科幻了。2025年Rest of World采访了12名前员工。受访者表示公司虽然使用了AI但绝大多数工作仍依赖员工和印度、乌克兰等地的外包开发者。大量定制开发需要人来完成AI生成的部分也要人工检查、返工交付速度并没有宣传得那么神奇。而且这并不是公司倒下之后才冒出来的质疑。早在2019年它还叫Engineer.ai的时候《华尔街日报》就援引现任和前员工的说法质疑它夸大AI能力以吸引客户和投资人。所以这件事的槽点从来不只是“它到底有没有用过AI”。你当然可以用AI也可以请外包程序员甚至可以把两者配合得很好。但如果宣传给人的感觉是机器已经能大包大揽真正交付时却仍要靠大量程序员埋头苦干那外界质疑的就是这层包装。说好的人工辅助智能怎么听完后台的故事倒像是智能辅助人工自动贩卖机里那个苦哈哈的牛马终于还是在AI时代找到了自己的工位。原文链接爆火的Muse居然让真人代AI打电话-36氪我的专辑《人工智能生命体 新启点》CSDN平台https://blog.csdn.net/2501_91883294/article/details/147616608?sharetypeblogdetailshareId147616608sharereferAPPsharesource2501_91883294sharefromlink