应用开发者的疑问:大模型是真正的银弹吗?

本文涉及的产品
NLP自然语言处理_基础版,每接口每天50万次
NLP自然语言处理_高级版,每接口累计50万次
NLP 自学习平台,3个模型定制额度 1个月
简介: 通过本文作者想和大家简单讨论下大模型的局限以及真正的适用场景。

来源|阿里开发者公众号

作者|悬衡

被当成银弹的大模型

ChatGPT 火了之后,大模型似乎被当成了真正的银弹,所有的体验问题都想通过大模型解决:

  • 能不能和大模型对话订机票?
  • 自然语言生成 SQL,简化报表分析工作?
  • 大模型帮老年人操作软件?
  • 能不能用于识别敏感信息?
  • ......

似乎大模型成了自然语言工程领域的真正银弹。但是我依稀记得 《人月神话》作者 Fred Brooks 所说的 “软件工程没有银弹”;以及华尔街投资大师们说的 “当所有人都在谈论一件事情的时候,说明这件事情已经出现了泡沫”。这里就想和大家简单讨论下大模型的局限以及真正的适用场景。本人不是专业搞算法的,还希望算法大佬们多多发表观点。

大模型是银弹吗?

把一些软件功能接入大模型,精度之类的问题或许还可以通过大量的训练解决。但是当真正面对终端用户时,下面这些问题却可能导致大模型不是最优解法。


昂贵的费用


吴军的著作《浪潮之巅》认为,互联网和计算机软件行业能快速扩张这么多年的重要原因就是其很低的扩张成本。传统行业,比如福特汽车,每卖出一辆汽车,就必须付出一辆车的生产成本,甚至要扩建厂房等等,这最终使得福特汽车的规模扩张不再划算,不得不市场份额让给其他厂商。而计算机软件可以几乎零成本的复制扩张,互联网软件增加一个用户也几乎没啥服务器成本,就很容易形成赢者通吃的局面。这件事在大模型软件上可能就不太一样了。OpenAI 能够将大模型的免费使用扩张到如此规模,很大程度上得益于微软的投资,据传言,微软给 OpenAI 投资过数百亿美元。我们暂且不讨论大厂花费数亿训练费用的回本问题,只看 API 调用费用,也是一笔不太划算的买卖。目前我维护的应用每台机器的 qps 大约平均在三百左右(按一天 8 小时平均,非峰值),在阿里云上这样的机器如果按 2M 带宽,每年的租赁费用大约在 3373元,平均到每天只需要 9 元。而假如应用全面接入了大模型,每次调用都是大模型产生的,目前 Open AI 的是按 token 收费的,最便宜的 GPT-3.5 Turbo 模型的价格是 0.0015 美元每 1000 token 输入,0.002 美元每 1000 token 输出,这算成人民币我们就简单估计成每 1000 token 输入输出 2 分钱,也就是 0.02 元。



就算每次请求只耗费 10 token,假设机器是 200 qps,每天 8 小时,一天也需要消耗 0.02*(200*60*60*8*10/1000)=1152 元。模型所消耗的费用是应用服务器费用的 100 多倍。

具体背后 Open AI 自己的成本是多少,就更不得而知,甚至有人认为目前 Open AI 为了快速抢占市场,是在亏本卖的。

这就让应用的规模成本大大增加了,几乎不可能是一个完全免费给用户使用的产品。

虽然我相信在将来随着技术进步,成本会大幅度下降,但是大概率不是最近。


缓慢的计算速度


对于 ChatGPT 纯粹的聊天机器人,可以通过一个字一个字的流式输出来缓解计算速度缓慢的问题。但是对于想要通过它生成接口参数或者 SQL 的应用工程师来说,必须等待它完整生成完成,才能调用接口将结果返回给用户。

而高性能计算机这么多年的发展已经让用户习惯了快速响应的操作界面,现代人的时间都非常宝贵,不可能为了省几个步骤,却去等待更长的时间。


多余的功能

大模型很强大,能够回答科学问题,可以写诗,还能够编故事,甚至是生成软件破译序列码。。。

但是这些功能对我生成应用接口参数有什么用?反而容易产生法律风险,使用者通过简单的 “AI 投毒”,就能引导大模型回答出带有偏见歧视的答案,而防范这个却需要付出巨大的代价,甚至防不胜防,比如之前很有意思的 ChatGPT奶奶漏洞 [1]。

每当一门技术火爆的时候,工程师们总是跃跃欲试。在大数据火爆的时候,哪怕系统里只有几条数据,也要上 Flink。大模型也有类似的问题,就为了生成几个 CRUD 的接口参数,就上昂贵,缓慢又容易出法律问题的大模型。而忽视了传统计算简单,快速且易于控制的优势。

除了大模型之外的 NLP 技术有哪些?

大模型和传统 NLP 技术从算力消耗和能力上,都给人非常直观的差别,所以才能火出圈。大模型的定义又是什么呢?维基百科词条[2]对它的定义是,神经网络中的参数超过十亿的深度学习模型。所有的大模型都其实来源于 Google 在 2017 年发表的 Transformer 论文,我们这里暂时认为所有基于 Transformer 的都是大模型,下图是网上很火的大模型发展树来源[3]

在大模型火之前,虽然国内之前也有天猫精灵,科大讯飞等对话机器人产品,但是似乎没有多少应用通过自然语言提供功能。甚至连专长做 im 的应用钉钉,似乎也没有想要通过自然语言实现应用功能的想法。

但是根据我国外朋友的说法,因为国外人力成本高,很早以前,他们的很多应用就在通过对话提供功能。他们甚至连交电费的 APP 都支持通过对话缴纳电费。

我本身也不是 NLP 领域的从业人员,对于大模型之外的 NLP 技术只能抛砖引玉:

  • 规则语言模型
  • 其实就是程序员常说的硬编码,使用类似于正则模式匹配的方式对自然语言进行处理,虽然现在听起来很 “Low”,但是大模型火爆之前也有一些产品使用这个,这种算法虽然速度快,但是消耗人力与专业知识, 好在有语言专家已经做好了一些开源框架,比如 ChatterBot[4]Will[5] 等,Will 在 2018 年还被集成到了 Slack 中。
  • 统计语言模型
  • 不再需要程序员去编码规则,而是使用一些统计方法(比如tfidf,主成分分析),去计算语句的特征,比如词语的频率,经常和哪些词一起出现等等。通过这个统计学知识再去计算新出现的语句,常见的 主题分析,情感分析 等等都是类似的技术。
  • 用来做简单的文本分类效果很好,很多线上的垃圾邮件自动识别据说用的都是这种技术。
  • 神经语言模型
  • 我们当下最熟悉的 NLP 技术,在大模型之前有 RNN,LSTM 等,后来都被基于 Transformer 的大模型碾压。

未来

我认为大模型不是银弹,未来它可能往两个方向发展:

  • 文本类的助理,比如写作助手,口语教练,专家咨询等等,这也是大模型的老本行;
  • 集成自动化厂商,比如 Zaiper[6],Alfred[7]等等,做一个统一的自动化助手付费产品,所有软件的自然语言操作都通过统一的入口进行。这样才是对用户更加方便的,而不是每个应用还要去找单独的助手去提问。

其他一些更简单的文本分类,主题识别以及情感分析等等任务,或许传统 NLP 有更加合适的方案。

作为一个应用开发者,并非 AI 的专业人士,文中可能有很多不专业的地方,本文纯粹是抛砖引玉,希望吸引更多的专业人士前来讨论。

参考链接:[1]https://zhuanlan.zhihu.com/p/643486458[2]https://zh.wikipedia.org/wiki/大型语言模型
[3]https://github.com/Mooler0410/LLMsPracticalGuide[4]https://github.com/gunthercox/ChatterBot
[5]https://pypi.org/project/will/[6]https://zapier.com/

[7]https://www.alfredapp.com/


大模型是真正的银弹吗?


能不能和大模型对话订机票?能不能自动提取合同中的信息?自然语言生成 SQL,简化报表分析工作?AI 有了大模型这把锤子后,一切都变成了钉子。似乎大模型成了自然语言工程领域的真正银弹。但是 《人月神话》作者 Fred Brooks 所说 “软件工程没有银弹”,没有最好的工具,只有更合适的工具。大模型的真正适用场景是什么呢?对此,你有什么看法?


欢迎点击链接参与讨论就有机会获得超声波灭蚊灯。

相关文章
|
1月前
|
前端开发 开发者 C++
通过对比普通开发者与大牛们的学习策略,揭秘他们高效学习的秘诀
前端技术日新月异,大牛们如何保持竞争力?本文对比普通开发者与大牛的学习策略,揭示高效学习的秘诀:明确目标、主动探索、系统资源、注重实践、持续学习。通过这些方法,大牛们能快速掌握新技术并应用于实际工作。
76 5
|
4月前
|
Java Android开发 开发者
探索安卓应用开发:从基础到实践
【8月更文挑战第31天】在这篇文章中,我们将一起踏上安卓应用开发的旅程。无论你是初学者还是有一定经验的开发者,这里都有适合你的内容。文章将引导你理解安卓开发的基础知识,然后通过实际的代码示例,带你一步步构建一个简单的应用程序。我们的目标是让读者能够不仅理解安卓开发的理论基础,还能通过动手实践来巩固这些知识。所以,拿起你的设备,让我们一起开始吧!
|
7月前
|
存储 缓存 NoSQL
作者推荐 | 企业级缓存技术解析,你必须知道的“9“大技术问题与常见误区
本文将深入剖析导致上述问题的九大根源,并提供相应的解决方案。请注意,本文以Java为例进行代码演示,但同样适用于其他技术平台的朋友。只需根据相应技术平台替换相关代码即可!
515 0
作者推荐 | 企业级缓存技术解析,你必须知道的“9“大技术问题与常见误区
|
7月前
|
存储 算法 Java
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)(一)
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)
113 1
|
7月前
|
存储 设计模式 监控
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)(二)
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)
100 0
|
7月前
|
Java API
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)(三)
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)
102 0
|
数据可视化 前端开发 数据挖掘
你是否了解「软件复用理论在低代码平台中的体现」?本文带你捅破这层窗户纸
你是否了解「软件复用理论在低代码平台中的体现」?本文带你捅破这层窗户纸
192 0
|
机器学习/深度学习 SQL 人工智能
应用开发者的疑问:大模型是银弹吗?
ChatGPT 火了之后,大模型似乎被当成了真正的银弹,所有的体验问题都试图通过大模型解决。本文想和大家简单讨论下大模型的局限以及真正的适用场景。由于本人不是专业搞算法的,大佬们多多拍砖。
769 0
|
监控 安全 项目管理
如何写一个优质高效的网络项目实施方案?这篇文章值得收藏!
如何写一个优质高效的网络项目实施方案?这篇文章值得收藏!
330 0
国外经典神作:领域驱动设计软件核心复杂性应对之道手册限时阅读
相信领域驱动设计这个对有些小伙伴来说很陌生,领域驱动设计(Domain Driven Design,DDD)自诞生以来已有十几年时间,这门本已步入老年的方法学却因为微服务的兴起而焕发了第二春。并不是微服务拯救了领域驱动设计,是因为领域驱动设计一直在坚硬的生长,然而看起来,确乎因为微服务,领域驱动设计才又焕发了青春。
国外经典神作:领域驱动设计软件核心复杂性应对之道手册限时阅读