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

简介: ChatGPT 火了之后,大模型似乎被当成了真正的银弹,所有的体验问题都试图通过大模型解决。本文想和大家简单讨论下大模型的局限以及真正的适用场景。由于本人不是专业搞算法的,大佬们多多拍砖。

被当成银弹的大模型


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 toke 输入输出 2 分钱,也就是 0.02 元。


image-20230730155744019.png


就算每次请求只耗费 10 token,假设机器是 200 qps,每天 8 小时,一天也需要消耗 0.02*(200*60*60*8*10/1000)=1152 元。模型所消耗的费用是应用服务器费用的 100 多倍。
具体背后 Open AI 自己的成本是多少,就更不得而知,甚至有人认为目前 Open AI 为了快速抢占市场,是在亏本卖的。
这就让应用的规模成本大大增加了,几乎不可能是一个完全免费给用户使用的产品。

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

缓慢的计算速度

对于 ChatGPT 纯粹的聊天机器人,可以通过一个字一个字的流式输出来缓解计算速度缓慢的问题。但是对于想要通过它生成接口参数或者 SQL 的应用工程师来说,必须等待它完整生成完成,才能调用接口将结果返回给用户。
而高性能计算机这么多年的发展已经让用户习惯了快速响应的操作界面,现代人的时间都非常宝贵,不可能为了省几个步骤,却去等待更长的时间。

多余的功能

大模型很强大,能够回答科学问题,可以写诗,还能够编故事,甚至是生成软件破译序列码。。。
但是这些功能对我生成应用接口参数有什么用?反而容易产生法律风险,使用者通过简单的 “AI 投毒”,就能引导大模型回答出带有偏见歧视的答案,而防范这个却需要付出巨大的代价,甚至防不胜防,比如之前很有意思的 ChatGPT奶奶漏洞

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

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


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


大模型发展时间线.jpg


在大模型火之前,虽然国内之前也有天猫精灵,科大讯飞等对话机器人产品,但是似乎没有多少应用通过自然语言提供功能。甚至连专长做 im 的应用,比如钉钉和微信,似乎也没有想要通过自然语言实现应用功能的想法。
但是根据我国外朋友的说法,因为国外人力成本高,很早以前,他们的很多应用就在通过对话提供功能。他们甚至连交电费的 APP 都支持通过对话缴纳电费。

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

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

未来


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

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


Alfred.jpg


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

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

相关文章
|
测试技术 数据库 安全
带你读《C++代码整洁之道:C++17 可持续软件开发模式实践》之二:构建安全体系
如果想用C++语言编写出易维护的、扩展性良好的以及生命力强的软件,那么,对于所有的软件开发人员、软件设计人员、对现代C++代码感兴趣或想降低开发成本的项目领导者来说,本书都是必需品。如果你想自学编写整洁的C++代码,那么本书也是你需要的。本书旨在通过一些示例帮助各个技术层次的开发人员编写出易懂的、灵活的、可维护的和高效的C++代码。即使你是一名资深的开发工程师,在本书中也可以找到有价值的知识点。
|
3天前
|
安全 虚拟化
【专栏】如何写一个优质高效的网络项目实施方案?这篇文章值得收藏!
【4月更文挑战第28天】在数字化时代,成功实施网络项目至关重要。本文从前期准备(明确目标、了解背景、组建团队)、方案内容(项目概述、技术方案、实施计划、风险评估、预算、验收标准)和注意事项(简洁明了、数据准确性、灵活性、沟通协调)三个方面解析如何撰写优质高效的网络项目实施方案。通过具体案例展示实施步骤,强调方案应具备的特点和要素,以确保项目顺利进行并达成目标。
|
2月前
|
存储 算法 Java
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)(一)
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)
30 1
|
2月前
|
存储 设计模式 监控
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)(二)
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)
28 0
|
2月前
|
Java API
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)(三)
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)
24 0
|
8月前
|
架构师 测试技术 API
深入浅出聊一聊自动化架构!
深入浅出聊一聊自动化架构!
119 1
|
9月前
|
机器学习/深度学习 SQL 人工智能
应用开发者的疑问:大模型是真正的银弹吗?
通过本文作者想和大家简单讨论下大模型的局限以及真正的适用场景。
83911 30
应用开发者的疑问:大模型是真正的银弹吗?
|
10月前
|
数据可视化 算法 前端开发
一文吃透低代码平台源代码交付的重要性(避坑指南)
一文吃透低代码平台源代码交付的重要性(避坑指南)
204 0
|
监控 安全 项目管理
如何写一个优质高效的网络项目实施方案?这篇文章值得收藏!
如何写一个优质高效的网络项目实施方案?这篇文章值得收藏!
237 0
国外经典神作:领域驱动设计软件核心复杂性应对之道手册限时阅读
相信领域驱动设计这个对有些小伙伴来说很陌生,领域驱动设计(Domain Driven Design,DDD)自诞生以来已有十几年时间,这门本已步入老年的方法学却因为微服务的兴起而焕发了第二春。并不是微服务拯救了领域驱动设计,是因为领域驱动设计一直在坚硬的生长,然而看起来,确乎因为微服务,领域驱动设计才又焕发了青春。
国外经典神作:领域驱动设计软件核心复杂性应对之道手册限时阅读