2024:人工智能大模型的璀璨年代

2024:人工智能大模型的璀璨年代

大家好,我是herosunly。985院校硕士毕业,现担任算法研究员一职,热衷于大模型算法的研究与应用。曾担任百度千帆大模型比赛、BPAA算法大赛评委,编写微软OpenAI考试认证指导手册。曾获得阿里云天池比赛第一名,CCF比赛第二名,科大讯飞比赛第三名。授权多项发明专利。对机器学习和深度学习拥有自己独到的见解。曾经辅导过若干个非计算机专业的学生进入到算法行业就业。希望和大家一起成长进步。

本文主要对2024年度人工智能大模型的创新和应用进行了总结,希望对学习大语言模型的同学们有所帮助。

文章目录

1. 前言

人工智能的发展轨迹似乎正在印证一个有趣的历史规律:颠覆性技术往往以超出最初预期的方式迅速演进。回顾历史,电力的普及、互联网的崛起,乃至智能手机的诞生,无一不是以远超人们想象的速度改变了社会的方方面面。

随着2022年底ChatGPT的问世,AI大模型如同一颗投入平静湖面的重磅炸弹,瞬间激起千层波澜。当时,人们对这一全新的语言模型充满好奇与惊叹,但鲜少有人能准确预见其将带来的深远变革。转眼间,短短两年过去,大模型已经悄然融入我们工作和生活的方方面面。而这些变化,则绝大多数发生在过去的一年当中。

那么,站在2025年的新起点,让我们共同回顾过去一年学术界与工业界在模型侧和应用侧所取得的突破性进展。

2. 从OpenAI一方独霸到群雄逐鹿

2024年成为大模型厂商激烈竞争的关键一年。Menlo Ventures的调研数据显示,OpenAI的先发优势正逐渐减弱,其市场占有率较2023年出现显著下滑。具体而言,OpenAI的企业市场份额从50%下降至34%。这部分流失的市场份额主要被Anthropic和谷歌瓜分,显示出市场竞争格局的显著变化。

在这里插入图片描述

2023年3月,OpenAI发布了GPT-4模型,其在起草诉讼书、通过标准化考试以及根据手绘草图建立工作网站等方面的能力令人惊叹,一骑绝尘。然而,时间来到了2024年,5月份OpenAI发布了原生的多模态模型GPT-4o,它可以接受文本、音频和图像任意组合的输入,并生成这些格式的相应输出。

2024年9月13日,OpenAI正式发布了o1模型,这是一款颇具颠覆性和创新性的模型。o1最引人注目的特点是其独特的思考机制,类似于人类的深度思考过程。在响应用户请求时,模型会进行长时间的内部推理,不仅可以尝试多种解决方案,还能够在思考过程中主动发现并纠正潜在的错误。这种近似于人类大脑思考模式的方法,使得o1在数学、物理、化学和编程等专业领域表现出卓越的能力。

在这里插入图片描述

到了12月20日,OpenAI推出了最新的推理模型o3及其轻量版本o3-mini。相较于o1,这一代模型在编程、数学和科学问答等方面取得了显著的进步。尤其值得称道的是,o3成功突破了ARC-AGI基准测试,标志着人工智能在适应新任务和学习未知场景的能力上实现了里程碑式的飞跃。

在这里插入图片描述

然而,值得深思的是,尽管从4o到o1再到o3,OpenAI的模型在技术上持续精进,然而,许多用户觉得,如今这些渐进式的改进似乎难以再现ChatGPT最初问世时的那种震撼惊喜。

与此同时,OpenAI的“孪生兄弟”Anthropic也在2024年发布了多款震惊世界的大模型。之所以称为孪生兄弟,主要是由于Anthropic的多位重量级人物均来自于OpenAI,包括GPT-3首席工程师Tom Brown、OpenAI安全与政策副总裁Daniela Amodei,以及近期加入的ChatGPT后期训练负责人John Schulman和前OpenAI安全主管Jan Leike。所以大家一定要持续关注Anthropic发布的模型、论文以及相关技术报告。

在这里插入图片描述

2024年3月,Anthropic推出了备受瞩目的Claude 3系列大模型,其中Claude 3 Opus迅速脱颖而出,成为业界公认的新一代性能标杆。紧随其后,6月发布的Claude 3.5 Sonnet更是将模型性能推向了前所未有的新高度。值得注意的是,即便在10月进行了重大性能升级,该模型仍然保持了原有的版本号,这一现象在业内被非正式地称为"Claude 3.6"。如果大家对AI编程有所了解,三大神器(cursor、windsurf、cline)均使用Claude 3.5 Sonnet模型作为其核心模型。充分体现了Claude 3.5 Sonnet在代码生成和理解方面的卓越能力。

在这里插入图片描述


调用claude-3.5-sonnet的示例代码如下:

from openai import OpenAI client = OpenAI( base_url="https://openrouter.ai/api/v1", api_key="<OPENROUTER_API_KEY>",) completion = client.chat.completions.create( extra_headers={"HTTP-Referer":"<YOUR_SITE_URL>",# Optional. Site URL for rankings on openrouter.ai."X-Title":"<YOUR_SITE_NAME>",# Optional. Site title for rankings on openrouter.ai.}, model="anthropic/claude-3.5-sonnet", messages=[{"role":"user","content":[{"type":"text","text":"What's in this image?"},{"type":"image_url","image_url":{"url":"https://upload.wikimedia.org/wikipedia/commons/thumb/d/dd/Gfp-wisconsin-madison-the-nature-boardwalk.jpg/2560px-Gfp-wisconsin-madison-the-nature-boardwalk.jpg"}}]}])print(completion.choices[0].message.content)

2024年,大模型领域的开源鼻祖Meta公司再次引领潮流,发布了Llama 3系列模型,并在此基础上推出了Llama 3.1和Llama 3.2两个升级版本。Llama 3系列模型的发布,不仅为开源社区注入了新的活力,更为国内大模型领域的蓬勃发展提供了重要的技术引领和创新动力。

2024年国产模型也进步神速,阿里发布了Qwen2.5 Chat、Qwen2.5 Coder模型以及深度推理模型QwQ。但最让本人感到最为欣喜的当属DeepSeek发布的多款模型,尤其是近日发布的DeepSeek-R1深度推理模型,不仅效果堪比OpenAI的o1模型,而且将技术报告和模型权重进行开源,这一点真的称得上国产之光,遥遥领先。

在这里插入图片描述

3. 大模型的重要应用方向:代码助手、智能客服、知识搜索

谈到大模型企业应用,首当其冲的就是代码助手(Code Copilots),该方向的市场占有率遥遥领先(51%),使得部分开发人员成为大模型技术的早期深度用户。GitHub Copilot的迅速崛起——其收入增长速度已突破3亿美元——充分印证了这一趋势。与此同时,Cursor、Windsurf、Devin等新兴工具也在快速扩展市场份额。除了通用代码助手外,企业还积极引入特定任务的代码解决方案,如Harness的AI开发运维工程师和质量检测助手,这些工具专注于管道生成和测试自动化。此外,像All Hands能够完成端到端软件开发的智能体软件也备受关注。

智能客服在企业应用中取得了显著进展,市场占有率达31%。这些应用为内部员工和外部客户提供全天候的可靠知识支持。Aisera、Decagon和Sierra等公司的智能代理直接与终端客户互动,而Observe AI则在通话过程中为呼叫中心代理提供实时指导,显著提升了服务效率。

在企业数据管理领域,企业搜索与检索(市场占有率28%)和数据提取与转换(市场占有率27%)成为两大热门应用方向,反映出企业迫切希望解锁并利用分散在组织各处的数据孤岛中隐藏的宝贵知识。Glean和Sana等创新解决方案通过连接电子邮件、即时通讯工具和文档存储库,实现了跨系统的统一语义搜索,并提供人工智能驱动的知识管理服务。

会议总结应用以24%的采用率位居第五,通过自动记录笔记和提炼要点,显著提升了工作效率。例如,Fireflies.ai、Otter.ai和Sana等工具能够智能捕捉并总结在线会议内容,而Fathom则专注于从视频会议中提取关键信息。特别值得一提的是,Eleos Health将这一创新应用于医疗保健领域,通过自动化文档记录并与电子健康记录(EHR)系统无缝集成,使医疗服务提供者能够将更多精力专注于患者护理,从而显著提升了医疗服务质量。

在这里插入图片描述

4. 从专家专属到人人可用:提示词使用趋于简单

随着模型的思考和推理能力逐步提升,提示词技巧的重要性逐渐降低。提示词的核心要点只有一个:问题必须清楚明了。如果担心大模型无法理解,可以适当增加示例,即为大模型提供更容易理解的上下文。

就像带领一个普通团队(普通大模型),由于成员能力有限,每项任务都需要你事无巨细地交代清楚,甚至要手把手指导具体操作,否则他们往往难以独立完成或达不到预期效果。而如果拥有了一支更为优秀的团队(深度推理大模型),通常只需明确任务目标和大致方向,他们就能自主高效地思考和推理,在具体细节上过多赘述反而可能会导致效果下降。

但在部分场景下设定大模型角色,依然是一个简单有效的方法。比如需要大模型去扮演心理医生、数学老师等特定角色时,明确的角色设定能够帮助模型更好地理解任务需求,生成符合角色身份的回答。这种设定不仅提升了输出的专业性和准确性,还能增强用户体验,使交互更加自然和贴近实际场景。例如,在心理咨询中,模型可以模拟心理医生的语气和沟通技巧,提供情感支持和专业建议;在数学教学中,模型可以像老师一样逐步引导学生解题,解释复杂概念。因此,角色设定在某些特定任务中仍然具有重要价值。

2025年已经到来,个人大胆猜测,2025 年有望成为AI Agent 商业爆发元年。各行各业都将受益于AI Agent带来的效率提升和用户体验优化。随着技术的不断进步和应用场景的拓展,AI Agent有望成为未来商业生态中不可或缺的一部分。

Read more

前端小白别慌:3分钟搞定页面插图(附避坑指南+性能彩蛋)

前端小白别慌:3分钟搞定页面插图(附避坑指南+性能彩蛋)

前端小白别慌:3分钟搞定页面插图(附避坑指南+性能彩蛋) * 前端小白别慌:3分钟搞定页面插图(附避坑指南+性能彩蛋) * 为啥前端连个图片都插不明白? * 浏览器加载一张图背后到底在偷偷干啥? * img 标签真就万能了吗? * 响应式图片怎么搞才不被设计师追着骂? * 懒加载、WebP、CDN——这些词听着高大上,其实你早就用过 * 图片加载失败时别让页面变"裂图坟场" * 别再一股脑扔高清大图了,用户流量不是大风刮来的 * 你以为写个 src 就完事了?SEO 和无障碍访问正在偷笑 * 开发时本地图片路径乱成一锅粥?模块化方案来救场 * Webpack/Vite 里图片到底该放哪?public 还是 assets? * 用 CSS 背景图还是 HTML img?这事儿得看场合 * 移动端图片模糊到像开了十级美颜?分辨率适配讲清楚 * 别让图片拖垮首屏速度,Lighthouse 分数掉得比工资还快 * 设计师给的图太大?教你几招无损压缩还不背锅

深入理解飞书 Webhook 签名验证:一次踩坑到填坑的完整记录

深入理解飞书 Webhook 签名验证:一次踩坑到填坑的完整记录

作为一名牛马,我在对接飞书开放平台时遇到了一个看似简单却让人抓狂的问题——签名验证总是失败。经过一番深入研究,我发现这个问题背后隐藏着许多容易被忽视的细节。今天,我想用最通俗的语言,把这段经历记录下来。 故事的开始:一个神秘的签名验证失败 问题现场 那是一个普通的工作日下午,我正在为公司的内部系统对接飞书的事件订阅功能。一切看起来都很顺利: * ✅ 应用创建完成 * ✅ 事件订阅配置完成 * ✅ Webhook 地址填写正确 * ✅ 代码部署上线 但是,当我满怀期待地在飞书后台点击"验证"按钮时,系统日志里出现了这样一行红色的错误: warn: Mud.Feishu.Webhook.FeishuEventValidator[0] 请求头签名验证失败: 计算 +OGVt6ye......, 期望 bc5b503a...... 什么?签名验证失败? 我检查了配置文件,密钥都填对了;我检查了代码逻辑,看起来也没问题。但就是验证不通过! 初步分析 让我们先看看日志里的其他信息: dbug: Mud.Feishu.Webhook.

【技术栈-前端】一文搞懂 dist 是什么

【技术栈-前端】一文搞懂 dist:它到底是什么?为什么你的项目总会出现 dist 目录? 在很多项目里,你会反复看到一个名字:dist。它可能是一个文件夹(dist/),也可能出现在命令里(npm run build 之后生成 dist),甚至在 Python 打包发布时也会出现(dist/*.whl、dist/*.tar.gz)。 这篇文章就把 dist 讲透:概念、常见场景、生成方式、配置方法、部署与最佳实践、常见坑 一次说清。 文章目录 * 【技术栈-前端】一文搞懂 dist:它到底是什么?为什么你的项目总会出现 dist 目录? * 1. dist 是什么?一句话解释 * 2. dist

纯QWidget绘制实现电子地图控件/非qml非web/多线程下载和加载瓦片/支持各种图形

纯QWidget绘制实现电子地图控件/非qml非web/多线程下载和加载瓦片/支持各种图形

一、前言说明 之前做的地图组件,耗费了巨大的时间精力,前后完善了五年之多,能够想到的应用场景几乎都实现了,也有不少的用户,现场实际需求也不断反馈,不断的修改和增加功能,尽管优点很多,依然有个巨大缺点就是依赖浏览器控件,性能肯定是要打折扣的,毕竟有些嵌入式板子甚至老的开发环境,不一定有浏览器控件,就算有,在嵌入式板子环境上或者一些国产硬件的系统上,配置比较低,在浏览器上运行的网页,性能指数级下降,甚至一些环境连GPU都没有,老板为了节省成本,尽量选一些配置低的板子,所以也没有一种可能用QWidget绘制来实现呢,这样性能极好,而且控制度极高,qt的painter非常灵活可靠。 经过大量的尝试改造,总算在今年实现了这个地图控件,不依赖浏览器控件,也不依赖qml,有些人用的Qt自带的qml的location组件来实现的,这个尽管方便,但是性能也低,因为嵌入式环境配置低的板子,根本无法正常跑起来qml,别提要新版的Qt才有qlocaltion组件。用qwidget来实现有两个最大难点,一个是如何将地理坐标映射到像素绘制坐标,一个是如何快速的加载瓦片多线程绘制,这个必须采用多个分层绘制的机制