要提出像GPT这类大型语言模型的概念,并从事严肃的人工智能研究,确实需要扎实的数学功底。然而好消息是,如果只是想理解这些模型的工作原理,所需的数学并不复杂。只要曾经在1960年代以后接受过高中数学教育,就已经掌握了基本的知识,比如向量、矩阵等内容。 需要注意的是,本文讲解的是理解“推理”过程所需的数学知识——也就是如何使用一个已经训练好的人工智能模型,而不是关于如何训练它的过程。虽然训练所需的数学也并不复杂,但那部分内容将留待后续文章介绍。 明确这一点后,正式开始深入讲解。 向量与高维空间 博主使用了“向量”一词,基本等同于软件工程师所说的“数字数组”。但在数学意义上,一个长度为 n 的向量不仅是一个数组,它还表示一个 n 维空间中的方向和距离,或者等价地,可以看作是从原点出发,沿着这个向量到达某个点。 在二维空间中,向量 (2, -3) 意味着“向右两单位,下移三单位”,也就是从原点出发移动后所处的位置。三维空间中的向量 (5, 1, -7) 则意味着“向右五单位、上移一单位、远离观察者七单位”(某些情况下可能表示向观察者移动七单位)。当维度更高时,人类无法直观想象,但概念上是一致的。 在LLM中,向量用于表达各种含义。例如,模型输出的logits向量(见上一篇)代表了对下一个token的不同可能性的预测。在这种情形下,可以将logits看作存在于一个高维空间中,这个空间表示了“意义”的分布。 词汇空间(Vocab Space) 每个token对应的logits值是一组数字,每个数字表示该token在当前上下文中作为下一个token的可能性。在书中分析的GPT-2模型中,其tokenizer包含50,257个token,因此每个logits向量的长度也是50,257。比如,token ID为464的是“The”,那么logits向量中第464位的数值表示“The”作为下一个token的相对概率。 可以将每一个logits向量视为一个存在于50,257维空间中的点。这个空间的每一个位置都代表了对下一token的各种可能性组合。本文将这个空间称为“词汇空间”。 不过,这是一个“混乱”的词汇空间。假设一个简化的LLM,其词汇表中只有三个token,那么两个logits向量 (1, 2, 3) 和 (-9, -8, -7) 虽然数值不同,但表达的是相同的排序:第一个token最不可能,第二个次之,第三个最可能。 为了整理这种冗余,可以将logits向量传入softmax函数,从而得到一组真实的概率分布。这组概率数值介于0到1之间,总和为1。这样,所有表达相同排序的logits向量将映射为同一个概率向量。例如,(1, 2, 3) 和 (-9, -8, -7) 都会被softmax映射为大约 (0.09, 0.24, 0.66)。 需要指出的是,其他向量也可能表达相同的排序,但概率分布不同。例如,(1, 2, 5) 虽然仍是“第三个token最可能”的排序,但其softmax结果会是类似 (0.02, 0.05, 0.94) 的分布,显示出第三个token的优势更加明显。 因此,可以将词汇空间分为两类:一种是“混乱”的、未经归一化的向量空间;另一种是经过softmax函数后得到的、表示真实概率分布的“整洁”空间。 还有一种特殊情况是所谓的“one-hot向量”,其中只有一个数值为1,其余均为0,表示某个token的概率为100%。这种向量在下一篇文章中将发挥关键作用。 嵌入空间(Embedding Space)…
Author: aitrendtrackers@rengongzhineng.io
101+ 个生成式 AI 用例与技术蓝图
零售行业用例 这些架构蓝图来自零售行业客户的实践经验,包括 Mercari、Target、家乐福台湾、The Home Depot、联合利华等。 1. 统一线上与线下零售体验 业务挑战: 大型零售商拥有实体门店和不断增长的电商渠道,但两者各自为政,导致定价、促销和库存不一致,客户体验割裂。技术堆栈: Google Kubernetes Engine (GKE)、BigQuery、Cloud CDN、Apigee、Cloud Spanner。蓝图: 客户流量进入电商网站 → Cloud CDN 缓存静态内容 → GKE 按需扩展电商微服务 → Apigee 管理 API,实现实时门店库存检查 → 所有销售数据流入 BigQuery,用于供应链分析和需求预测。 2. 为门店经理提供实时库存视图 业务挑战: 需要为门店经理提供准确、实时的库存建议,以提高效率。技术堆栈: BigQuery、Vertex AI、Looker、Google Workspace。蓝图: 数千家门店的销售和库存数据每天汇入 BigQuery → Vertex AI 根据历史数据预测商品需求 → Looker 生成推荐库存水平的仪表盘 → 推荐信息通过 Google Sheets 等工具推送至门店员工设备。 3. 提升在线独特商品的发现体验 业务挑战: 拥有数百万种非标准化商品,需要为用户提供快速、相关且个性化的搜索体验。技术堆栈:…
亚马逊的领导力原则
亚马逊的领导力原则在科技界广为人知,不仅在公司内部有广泛影响力,也常被外界引用和讨论。虽然这些原则时常成为调侃对象,甚至连亚马逊员工本身也参与调侃,但从整体上来看,这些原则为企业运营提供了相当合理的指导方向。作者作为亚马逊客户已有25年以上的时间,作为AWS客户也接近20年,并且担任AWS Hero已有6年,尽管从未在亚马逊任职,但基于长期深度使用AWS的经验,认为自己有足够的观察与理解来就部分领导力原则进行评论。 客户至上(Customer Obsession) 亚马逊倡导“从客户出发,向后工作”,领导者应努力赢得并保持客户信任,尽管会关注竞争对手,但其关注重心始终放在客户身上。这一原则在理论上无疑是正确的,但在实践中,部分亚马逊员工可能将其理解得过于简单。所谓“从客户出发”,并不应仅仅等同于“去问客户想要什么然后照单全收”,就像那句著名的“如果问客户想要什么,他们可能会说想要一匹更快的马”一样。 在AWS的早期阶段,曾涌现出许多由工程驱动、富有前瞻性的产品,例如EC2刚推出时,并没有人能明确预测用户会如何使用它,但它的潜力显而易见,最终证明这种“构建积木”的方式极具远见。然而,大约在2012年前后,AWS的文化逐渐转向“为客户构建他们所要求的功能”,而这一转变在某种程度上被认为是走错了方向;更糟糕的是,在2020年前后,方向进一步偏移,变成“为财报电话会议中分析师所提的问题而开发功能”。 这种“客户请求”与“客户真正所需”之间的张力,也体现在系统韧性等领域。例如,AWS在其“良好架构框架”(Well-Architected Framework)中明确建议客户不要在单一可用区部署生产负载,但与此同时,跨可用区传输的带宽费用却高得惊人,AWS也未能提供有力工具来支持高可用的多可用区部署。多数客户不会自己去实现Paxos协议,更别提高层管理者要求“Paxos即服务”这种事。但如果AWS内部的领导者认真思考“客户为了构建优秀应用真正需要什么”,那么完全可以发现许多服务其实在亚马逊内部已经存在。因此,建议AWS应回归初心,继续发布“构建积木”,为客户构建他们未来会需要,而不是眼下呼吁的功能。 主人翁精神(Ownership) 该原则强调领导者应拥有企业主人的心态,不为了短期利益牺牲长期价值,并且不局限于自身团队,而是为整个公司着想,并不推卸责任。然而,从观察来看,这一原则既过于狭窄,也没有被真正落实。 仅仅“为整个公司着想”还不够,更应当“为整个技术生态系统负责”。曾有亚马逊员工致力于在大型虚拟机中统一中断处理标准,尽管亚马逊并未使用FreeBSD的bhyve虚拟机技术,该员工仍愿意推动补丁合入FreeBSD主线,以促进整个行业的标准化。这种行为展示出极具远见的“生态责任感”。 类似的理念在安全领域早已有所体现:安全漏洞一旦在某一系统中被利用,极有可能被攻击者进一步用来攻击其他系统,因此,一个系统的不安全,可能意味着整个生态的不安全。虽然在其他领域这一逻辑未必完全适用,但合作、协同推进生态发展,远比一味聚焦公司眼前利益更具长期价值。 然而,从实际操作层面来看,亚马逊甚至未能履行其“为公司整体负责”的基本承诺。公司内部信息极度封闭,甚至导致多个团队在不知道彼此存在的情况下开发出类似的服务。如此的“信息孤岛”状态,使得“主人翁精神”无从谈起。若要真正实现这一原则,亚马逊需要拆除内部的“高墙”,建立更开放透明的协作机制,赋予有能力的员工跨团队影响力。 行动偏向(Bias for Action) 亚马逊认为,速度在商业中至关重要,许多决策是可逆的,因此不需要过多犹豫,鼓励合理冒险。然而,虽然这种“快速试错”的文化有其积极面,却也存在与“坚持最高标准”及“客户信任”之间的矛盾。 亚马逊内部常用“一扇门是否可逆”来衡量决策风险,强调大多数决策都是“两扇门”(可逆)的类型。然而,即使是可逆的决策,也并非没有成本。当AWS推出一个不成熟的服务时,即使后续问题得到修复或服务被撤回,客户对该服务、乃至整个AWS品牌的信任都会受到长远影响。 作者在担任FreeBSD安全官的七年中,虽然公众认识其是安全通告的发布者,但实际上更重要的职责是“叫停”不成熟的发布。在安全领域,宁可晚发,也不能发布错误补丁;一旦失去用户信任,后续补丁的部署速度将大幅下降。因此,团队内部形成了一句口头禅:“说服我这是真的正确”,这样的文化也应被引入亚马逊高层决策体系。 亚马逊在招聘环节设有“bar raisers”(守门员),有权否决不合格候选人。同样的机制也应应用于服务发布流程,设置“服务守门人”,对不达标的服务拥有一票否决权,以防止低质量产品损害客户信任。 总结 AWS首席技术官Werner Vogels在2024年的re:Invent主题演讲中曾说:“听听AWS Heroes的意见。”虽然此话主要指技术建议,也主要针对AWS的客户群体,但若亚马逊也能认真聆听类似这些来自长期合作者和观察者的批评意见,或许会带来正向的改变。毕竟,批评的背后,是因为在意与关心。
Meta超级智能实验室频现裂痕,顶尖AI研究员跳槽OpenAI引发行业震动
Meta公司近期高调组建的超级智能实验室(Meta Superintelligence Lab, MSL)在成立仅两个月后便爆出重大人事震荡。至少三位重量级AI研究人员宣布辞职,其中两人重返竞争对手OpenAI,引发业界广泛关注。 这一离职潮突显出,即便是数亿美元的高薪与几乎无限的计算资源,也难以稳定一个正在频繁重组、内部动荡不安的人工智能部门。对于这支被视为扎克伯格“终极AI反攻”之作的梦之队来说,这无疑是一个不祥的开局信号。 从“梦之队”到“闪电辞职”,仅用了不到两个月 据《WIRED》报道,本周三位研究员的离职成为外界察觉MSL内部困境的第一波信号。辞职者包括Avi Verma、Ethan Knight和Rishabh Agarwal。值得注意的是,Verma和Knight在加入Meta后不久便重返OpenAI,这两人的回归尤其引人侧目。 Verma原为OpenAI研究员,此番离开Meta后重新加入老东家。Knight则曾在Elon Musk旗下的xAI效力,也曾在OpenAI工作,他在Meta停留时间甚至不到一个月。如此迅速的“跳船”行为,凸显出该实验室在文化或组织运作方面可能存在重大摩擦。 另一位离职者Agarwal则在X平台上公开宣布了自己的决定。他表示,尽管自己在MSL拥有丰富资源和优秀团队,依然选择退出。“考虑到团队的天赋与计算资源密度,决定不继续参与超级智能实验室并不容易。”外界猜测,其居住地位于加拿大,可能受限于Meta主要AI团队集中在加州的地理因素。 领导层也动摇:Meta“元老级”高管跳槽OpenAI 这场人事震荡不仅影响新晋招募的研究人员,甚至波及到公司的核心管理层。Meta负责生成式AI产品管理的负责人、拥有近十年工龄的Chaya Nayak,也传出将跳槽至OpenAI,参与“特别项目”的消息。这一动向表明,人才流失正在从基层研究人员蔓延至管理高层,Meta内部的不稳定局势愈发严重。 Meta方面则试图淡化此次离职事件的影响。公司发言人Dave Arnold回应称,这些变动属于激烈招聘过程中“常见且可预期”的现象。“在激烈的招募竞争中,有些人最终选择留在原岗位,这是很正常的。”然而,业内观察人士指出,这一轮离职潮已经成为外界首次明确看到的“超级智能实验室计划裂痕”。 危机中的战略转折:源于“Llama 4”重大失败 Meta组建MSL的背景,是其原有AI战略遭遇严重挫败。2025年5月,公司雄心勃勃的Llama 4“大模型”项目被大幅推迟,背后原因包括架构决策失误与训练数据质量不达标,使模型在关键性能指标上大幅落后。 与此同时,Meta试图通过收购AI新创公司(如Runway和Safe Superintelligence)逆转局势,但连续遭拒。在收购不成的情况下,扎克伯格亲自主导了一项激进策略:以高额薪资“挖人”,直接抢夺人才。 这一战略最终在2025年7月1日促成了MSL的成立。新部门汇聚了大量被“精准挖角”的明星级人物,如前Scale AI CEO Alexandr Wang和前OpenAI研究员Shengjia Zhao(现任首席科学家)。据悉,Meta曾在一周内从OpenAI挖走至少八位研究员,导致对方内部哗然。 OpenAI的首席研究官Mark Chen公开表示,这种行为令其“感觉像是有人闯入家中偷走了珍贵的东西”。CEO Sam Altman则在内部备忘录中称Meta的行为“令人反感”。 50天即解散:超级实验室迅速解构重组 然而,顶尖人才的引入并未带来真正的稳定。出人意料的是,Meta于8月19日宣布解散刚成立仅50天的MSL。该部门被迅速拆分为四个新团队,分别聚焦于研究、产品、基础设施与“超级智能”长期战略目标。这一动作标志着公司AI方向再度转向,也显示其高层对原有战略的不信任。 更令人震惊的是,这已是四个月内第二次重大重组。早在5月Llama 4项目推迟后,公司已将AI部门划分为“AI产品”与“AGI基础研究”两大板块。此次MSL的分裂进一步表明,领导层仍在不断摸索有效的组织结构。 从自研到外采:Meta的AI战略发生根本转变 随着内部混乱升级,Meta开始向外部技术寻求支持,标志着其在AI路线上的根本性转向。原本坚持自主研发与开源的大模型策略,现如今也开始大量引入第三方解决方案。 最引人注目的例子是Meta与图像生成初创公司Midjourney达成合作。2025年8月22日,首席AI官Alexandr Wang宣布该消息时称:“为了让Meta能为用户带来最优产品,我们正在采取‘全方位策略’(all-of-the-above approach)。”这代表公司已不再坚持完全自主开发路线。 这一策略转变的核心原因仍在于Llama 4项目的失败。在短期内无法依靠自家技术突破瓶颈后,Meta不得不将开放性理念让位于“速度与结果”,转而构建混合生态体系。 支撑这一策略的,仍是Meta最强有力的筹码——庞大的资金与算力储备。扎克伯格近日接受采访时直言,AI研究人员现在最看重的并非职位晋升或管理权力,而是纯粹的计算资源。他表示:“他们更希望的是‘最少的下属,最多的GPU’。”这一趋势已在整个行业蔓延,巨头公司通过算力优势吸引人才的现象愈发明显。 但即便如此,金钱与硬件也并非万能。据透露,一位在Thinking Machines Lab工作的AI顶尖人才曾拒绝Meta开出的12.5亿美元报价,表明真正的技术领袖仍然不完全受金钱驱动。 前景未卜:梦之队是否已摇摇欲坠? MSL的高调诞生与迅速解构,使外界对Meta的AI战略充满疑问。公司虽成功招募了顶级人才、构建起强大的基础设施,却尚未展现出稳定而高效的组织文化。如何将这些昂贵资产真正转化为核心竞争力,仍是Meta当前最大的难题。 随着离职潮与组织重组频发,Meta的“梦之队”正在风雨飘摇的边缘上挣扎,而这场超级智能竞赛,远未结束
2025年20大语音AI博客与资讯网站
2025年全球语音人工智能(Voice AI)领域迎来了前所未有的高速发展。在实时对话式人工智能、情感智能以及语音合成方面均取得了革命性突破。随着企业加速部署语音代理,消费者积极拥抱新一代人工智能助手,保持对行业前沿动态的关注,已成为各行业专业人士不可或缺的必修课。数据显示,全球语音人工智能市场在2024年已达到54亿美元,相较前一年增长25%,其中语音AI解决方案吸引了21亿美元的股权投资。 1. OpenAI Blog —— 语音AI研发与前沿探索OpenAI继续引领语音人工智能的革命,其突破性成果包括GPT-4o实时API以及先进的文本转语音系统。该博客提供关于前沿研究、模型发布以及实际应用的深度见解。近期,OpenAI宣布推出gpt-realtime及Realtime API的生产更新,这是对话式人工智能的重要突破。重点方向:实时语音转语音模型、语音合成与情感表达、安全与负责任的AI部署、开发者工具与API。 2. MarkTechPost —— 语音AI新闻与深度分析MarkTechPost已成为语音AI新闻报道的权威来源,其深入解析新兴技术与市场趋势,使复杂话题变得易于理解,兼顾技术与商业受众。近期,他们对微软MAI-Voice-1的发布进行了详细报道,并对语音AI产业格局进行了全面剖析。重点方向:语音AI市场分析、语音合成技术突破、企业语音代理部署、行业投融资动态。 3. Google AI Blog —— 多模态与语音研究Google研究团队不断推动对话式人工智能边界,涵盖实时语音代理架构与先进语音识别系统。他们基于Gemini构建实时语音代理的研究展示了学术与应用的紧密结合。贡献领域:多模态AI整合、实时语音代理架构、语音理解与生成、隐私保护语音技术。 4. Microsoft Azure AI Blog —— 企业级语音解决方案微软Azure AI语音服务为数百万企业应用提供支持。其博客分享大规模部署语音AI的实用经验,包括个性化语音创建、企业级语音转文本以及多语言语音支持。聚焦方向:个性化语音定制、企业语音转写、多语言语音支持、Azure认知服务整合。 5. ElevenLabs Blog —— 语音合成创新ElevenLabs在语音克隆与合成方面引领潮流,打造出极具自然感的AI声音。公司于2025年1月完成1.8亿美元C轮融资,估值达到33亿美元,展现了资本市场的高度认可。专长领域:语音克隆技术、多语言语音合成、媒体创意应用、语音API开发。 6. Deepgram Blog —— 卓越的语音识别Deepgram发布的《2025语音AI现状》报告指出,今年将成为“类人语音AI代理之年”。其技术文章深入剖析语音识别与实时转写。核心洞见:市场趋势与预测、语音识别技术深度解析、开发者实践指南、行业应用案例研究。 7. Anthropic Research —— 对话AI伦理与语音模式Anthropic的Claude系列专注于安全与有益的AI,强调价值对齐与负责任的部署。2025年5月,他们推出了Claude的语音模式,由Claude Sonnet 4驱动,支持五种不同语音风格,实现完整的口语交流。关注领域:对话AI安全、语音AI伦理开发、人机交互研究、结合ElevenLabs的语音模式实现。 8. Stanford HAI Blog —— 学术语音AI研究斯坦福人本人工智能研究院(HAI)持续产出前沿成果,尤其在语音交互与对话轮换研究上表现突出。近期成果包括教会语音助手何时发声,突破传统的静音检测,转而分析语调模式。研究亮点:对话式AI轮换与打断处理、全球语音网络(WWvW)研发、静默语音识别进展、开源虚拟助手开发。 9. Hume AI Blog —— 情感智能语音交互Hume…
微软正在公开测试其首个完全自主训练的大语言模型——MAI-1-preview
2025年8月28日,多家媒体报道,微软正在公开测试其首个完全自主训练的大语言模型——MAI-1-preview。这一举措不仅意味着微软试图减少对OpenAI的依赖,也可能加剧两家公司之间的竞争。 微软AI部门首席执行官Mustafa Suleyman表示,MAI-1-preview是公司从头到尾独立训练完成的首个基础模型。目前,该模型已在LMArena网站上对外开放测试,用户可以在平台上进行评估。微软还发布了开发者申请表,允许有兴趣的团队申请提前体验。公司计划未来几周将该模型逐步应用到Copilot的部分文本场景中,以便通过用户反馈不断优化。 长期以来,微软的Bing搜索引擎、Windows 11操作系统以及其他核心产品,主要依赖OpenAI的模型来驱动AI功能。微软本身也是OpenAI的最大投资方之一,已累计投入逾130亿美元,同时为OpenAI提供云计算基础设施支持。然而,在微软2024年的年度报告中,OpenAI已被列入竞争对手名单,与亚马逊、苹果、谷歌和Meta并列。与此同时,OpenAI也在逐渐拓展合作伙伴,近期开始依赖CoreWeave、Google和Oracle等公司提供的算力,以应对ChatGPT每周覆盖7亿用户的庞大需求。 在LMArena的排名中,MAI-1-preview在文本任务上位列第13,落后于Anthropic、DeepSeek、Google、Mistral、OpenAI和xAI的模型。不过微软强调,该模型训练依托了约15,000块Nvidia H100 GPU,并已配备运行中的Nvidia GB200芯片集群。Suleyman在社交平台X上表示,公司对未来有着宏大的规划,包括模型的进一步提升、算力的扩展以及通过微软产品触达数十亿用户的愿景。 在推出MAI-1-preview之前,微软曾发布过一系列小型开源语言模型Phi。但此次的新模型,被视为微软真正意义上的首个完全自主基础模型。值得注意的是,Suleyman本人曾是Google收购的AI研究公司DeepMind的联合创始人,后来创立了Inflection AI,并在2024年率领大部分团队成员加盟微软。这一背景,使得微软AI团队在近几个月迅速扩张,其中包括约二十名来自DeepMind的专家。 这一动作显示,微软一方面仍与OpenAI保持深度战略合作关系,另一方面也在加快自研模型的步伐,力图在未来的AI竞争中掌握更大主动权。
Martin Fowler分享了他对大语言模型(LLM)与软件开发现状的一些思考
Martin Fowler在2025年8月28日发表文章,分享了他对大语言模型(LLM)与软件开发现状的一些思考。在准备休假和处理部分工作事务前,他总结了近期的观察与感受。 他提到,目前已有一些关于AI对软件开发影响的早期调查,试图回答它是否真的加快了开发进度,或是否改善或破坏了代码质量。然而,Fowler认为这些调查存在显著缺陷,因为它们往往没有考虑开发者实际使用LLM的工作流程。从他的观察来看,大多数使用场景仍然停留在“高级自动补全”,常见于Co-pilot工具。但那些真正从LLM中获得最大价值的开发者,往往会采用更直接的方式,让LLM读取和编辑源代码文件,从而完成具体任务。他担忧,如果忽视这些使用差异,调查数据会误导行业方向。 关于“编程的未来”这一常见提问,例如:现在是否还值得进入软件开发行业?LLM会不会取代初级工程师?高级工程师是否该提前退出?Fowler直言,没人能给出确切答案,任何声称“知道未来走向”的人都不可信。当前仍处于探索阶段,如何高效利用LLM尚无定论,尤其是在模型仍有可能获得显著提升的情况下。他建议,开发者应主动尝试这些工具,阅读他人经验,并关注其中的工作流程细节,甚至分享自己的实践。 关于AI是否是泡沫,他给出了肯定回答:“当然是泡沫。”他指出,从运河、铁路到互联网,每一次重大技术进步都伴随着经济泡沫。可以预见,AI热潮也会破裂,大量投资最终归零。未知的是泡沫破裂的时间,可能在下个月,也可能还需几年。但就像互联网泡沫一样,许多公司会消亡,但也会有企业幸存并壮大,就像亚马逊在pets.com和Webvan倒下后依然屹立。 他还提到自己已从公共演讲中退休,但仍期待在即将举行的GOTO Copenhagen大会上与老朋友相聚。他自上世纪90年代(当时该会议称为JAOO)起就参与其中,至今仍对会议的高质量议程保持赞赏。 Fowler引用前同事Rebecca Parsons的观点,认为“幻觉”不是LLM的缺陷,而是其核心特征。LLM的本质就是生成幻觉,只是有时这些幻觉对用户有用。因此,在使用LLM时,可以尝试多次提问,甚至让模型比较不同回答的差异,这些差异本身也可能有价值。尤其在涉及数值时,应至少询问三次,以评估其变动范围。同时,他提醒,不应让LLM直接计算确定性答案,而更适合让它生成计算所需的代码,再由开发者执行和验证。 他指出,传统的软件工程基于确定性机器,而其他工程学科早已习惯处理世界的不可预测性。例如,结构工程会为无法测量的因素留出容差,流程工程会考虑到人的疏忽或失误。随着LLM引入软件开发,或许意味着软件工程正迈入“非确定性”的新阶段。 在类比上,他提到人们常将LLM比作初级同事,但不同的是,LLM可能会轻易回答“所有测试通过”,而实际运行时却失败。若这是初级工程师的行为,HR可能早已介入。 安全性则是另一个严峻问题。他引用Simon Willison的观点,警示“AI代理的致命三合一风险”:访问私人数据、接触不可信内容,以及对外部世界的通信(数据外泄)。例如,若让LLM读取网页,攻击者可能通过隐形文字(如1pt白字)植入恶意指令,诱导LLM泄露敏感信息。更严重的情况是,当AI代理在浏览器中运行时,可能被欺骗去访问银行账户并转账。Willison因此认为,“基于代理的浏览器扩展从根本上存在致命缺陷,不可能安全实现。” 整体来看,Martin Fowler的思考强调了三个核心:一是现有调查和认知的局限性,行业对LLM实际作用的理解仍不充分;二是AI泡沫不可避免,但幸存者或许会成为未来的巨头;三是LLM的本质与风险,既带来新可能,也引入非确定性与安全隐患。 在他看来,行业需要更多实践、反思与警惕,才能真正理解并驾驭LLM在软件开发中的角色。
OpenAI宣布正式推出Realtime API
自去年10月公开测试以来,已有数千名开发者使用Realtime API并推动其优化。与传统的语音处理管道(将语音转文字,再由语言模型生成文字,最后再转为语音输出)不同,Realtime API能够直接通过单一模型处理和生成音频,从而减少延迟、保留语音细节并实现更自然的互动。 多家企业已开始尝试该技术。例如,Zillow的AI负责人Josh Weisberg表示,新模型在处理复杂请求方面表现更佳,如根据生活方式需求筛选房源或结合融资工具指导购房预算,这让找房体验更接近自然对话。 gpt-realtime模型的主要改进包括: Realtime API的新功能: 在安全与隐私方面,Realtime API内置多层防护机制,实时检测潜在违规对话并可终止,开发者也能利用Agents SDK增加额外的安全约束。此外,服务禁止输出被用于垃圾信息、欺骗或其他有害用途,并要求开发者明确告知用户何时与AI交互。该API已全面支持欧盟数据本地化,并遵循企业级隐私承诺。 价格方面,OpenAI宣布gpt-realtime的价格比之前的gpt-4o-realtime-preview降低20%:音频输入为每百万tokens 32美元(缓存输入为0.40美元),输出为每百万tokens 64美元。开发者还可通过智能上下文控制和多轮截断来降低长会话的成本。 目前,开发者可在官方文档中查看Realtime API的使用说明,在Playground中测试新模型,并参考提示指南来快速上手。
职场中AI工具的强制使用正逐渐成为一个令人担忧的趋势
当前职场中AI工具的强制使用正逐渐成为一个令人担忧的趋势。虽然这篇文章不是该平台通常发布的内容类型,但作者认为,这一话题对行业发展极其重要,尤其是对于开发者而言。 文章指出,越来越多的开发人员被要求或被鼓励在工作中使用AI工具。这种趋势并非源自技术进步的自然融合,而往往是由公司高层推动,甚至带有强制色彩。为了深入了解这一现象,作者在社交媒体上发起了调查,并与多位开发者和设计师进行了匿名访谈。 一位来自科学行业的开发者分享说,其主管要求他们将代码粘贴到ChatGPT中进行结构与性能优化建议。这种做法虽初衷为提高效率,但实际上却外包了代码审查的职责。一些初级开发者因此陷入调试困境,因为AI生成的代码经常无法运行,而主管仅仅依赖ChatGPT反馈,而不做深入审查。 在某些公司中,甚至面试问题都交由AI生成,且多人共用一个ChatGPT账户,导致公司内部出现大量非正式、难以追溯的沟通记录。一些员工开始有意识地使用“会自动消失”的聊天记录功能以保护自己,这种行为显然反映了对现状的深层不安。 另一位在创意代理机构任职的团队负责人透露,该公司试图转型为“AI优先”的企业,全面推动AI在品牌塑造、文案写作、设计及开发等领域的使用。公司高层甚至暗示,不接受这一转变的员工将“不再适合留在这里”。这种文化在团队内部引发了明显的不安全感和压力,尤其是当管理层以“使用AI的开发者会取代你”为“激励”口号时,更显得如同威胁。 在另一家小型数字代理机构中,一位设计师则表示,虽然AI工具并未直接用于最终的设计输出,但在早期创意构思、研究和文案撰写阶段已被广泛采用。该设计师曾试图表达对这种趋势的担忧,却因此被贴上“难相处”的标签。尽管后来在某些工具的使用上做出妥协,但仍坚持在客户项目中保持透明,确保披露使用AI工具的情况。 在一家全球零售巨头的技术部门中,AI工具的引入被视为组织发展战略的一部分。尽管目前尚未出现因拒绝使用AI而失业的情况,但该公司正在迅速试点多种AI工具,以应对即将到来的工作方式转型。一位软件工程师指出,AI确实在某些方面提高了工作效率,但同时也增加了新的压力,例如在短时间内掌握新工具,以及在AI辅助下出现更多“边缘性bug”。 有开发者提到,前公司CTO因偏爱Claude Code工具而强制团队使用它进行编码、测试、调试及系统设计验证。然而,该工具常常提供模糊或无效的反馈,令团队疲于奔命。更严重的是,一些主管将AI工具输出视为“设计验证”的依据,完全忽视了AI工具无法真正分析复杂技术问题的局限性。 文章强调,AI工具的本质是“语言模型”,擅长模式识别和语言生成,却不具备创造性和批判性思维。举例而言,Google的AI摘要功能曾引用Reddit上的玩笑评论,建议人们在披萨酱中添加胶水,这种错误说明AI无法辨别信息的真实意图与语境。 面对这一局面,作者提出了一些现实建议:在AI工具带来问题、延误或失败时,应及时记录每一个相关决策、责任人及自身的专业意见,尤其是当这些决策并非出自个人意愿时。这些记录在潜在的纪律处分或劳动仲裁中,将是个人重要的自保手段。 根据麻省理工学院(MIT)的一项研究,目前高达95%的生成式AI试点项目以失败告终,另有研究显示,即便开发人员认为AI提升了效率,实际工作速度反而变慢。这些数据表明,当前AI热潮很可能只是一个泡沫或炒作周期,而真正为此付出代价的,将是普通从业者。 因此,文章呼吁技术从业人员采取积极的防御策略,如加入工会,以集体力量保障自身权益。在这一泡沫破灭之前,尽可能维护自己的职业安全。 最后,作者坦言,尽管对话过程十分有价值,但撰写本文却充满挣扎。其核心观点并非出自对AI工具的偏见,而是基于长期实际使用后的理性判断:AI工具在多数情况下并未带来真正的助力,反而加剧了混乱。尽管个别场景中确有价值,但若将其强加于团队成员,则很可能适得其反。 AI工具的合理使用应基于自愿与实际效果,而非盲目追风。强迫使用AI,只会导致技术文化的倒退与员工士气的崩溃。在这一背景下,最重要的建议是:提前做好准备,保护自己。
什么是数据库?现代数据库类型、示例与应用(2025)
在当今这个数据驱动的世界中,数据库构成了现代应用程序的基础,无论是移动应用,还是企业级系统,数据库始终发挥着至关重要的作用。了解不同类型数据库的特性与应用场景,对于从事个人项目开发还是架构企业级解决方案的技术人员而言,都是极其重要的。 什么是数据库? 数据库是一种结构化的数据集合,通过电子方式进行存储,并由数据库管理系统(DBMS)进行管理。数据库能够高效地存储、检索与管理结构化和非结构化数据,为应用程序的正常运行提供坚实的基础。 数据库的选择对于系统性能、可扩展性、一致性及数据完整性有着深远影响。现代应用程序依赖数据库来组织数据,并确保用户能够快速、可靠地访问所需信息。 现代数据库的主要类型 1. 关系型数据库(RDBMS) 关系型数据库通过表格形式组织数据,表格由行与列组成,并通过主键与外键建立数据之间的关系。这类数据库遵循ACID原则(原子性、一致性、隔离性、持久性),并使用SQL进行数据查询。 2025年最新发展: 最佳应用场景:金融系统、电子商务、企业应用、商业分析。主流平台:MySQL、PostgreSQL、Oracle Database、Microsoft SQL Server、IBM Db2、MariaDB。 2. NoSQL数据库 NoSQL数据库打破了传统的表格结构,支持灵活的数据格式,适合处理半结构化与非结构化数据。 关键类型: 2025年亮点: 适用场景:实时分析、推荐系统、物联网、社交平台、流数据处理。 3. 云数据库 云数据库部署在云平台上,提供弹性扩展、高可用性、自动化管理服务,并适配DevOps及无服务器环境。多以DBaaS(数据库即服务)形式交付。 主流平台:Amazon RDS、Google Cloud SQL、Azure SQL Database、MongoDB Atlas、Amazon Aurora。 为何选择云数据库? 4. 内存数据库与分布式SQL数据库 内存数据库(如SAP HANA、SingleStore、Redis)将数据存储于RAM中,实现极快访问速度,适合实时分析与高频交易。 分布式SQL数据库(如CockroachDB、Google Spanner)结合关系型数据库的一致性与NoSQL的横向扩展能力,支持跨地域部署及全球复制。 5. 时序数据库 此类数据库专为处理时间序列数据而设计,如传感器数据或金融市场波动数据,强调高速写入、压缩与时序查询能力。 代表平台:InfluxDB、TimescaleDB。 6. 面向对象数据库与多模型数据库 面向对象数据库(如ObjectDB)直接映射到面向对象的代码结构,适用于多媒体或自定义业务逻辑场景。 多模型数据库(如ArangoDB、SingleStore)集成文档、键值、列式与图数据库功能,为复杂场景提供极大灵活性。 7. 专用与新兴数据库类型 2025年主流数据库亮点功能一览 数据库平台 近期关键特性 最佳用途 MySQL JSON架构验证、向量搜索、SHA-3加密、OpenID Connect…