IT之家 4 月 30 日消息，OpenAI 昨日（4 月 29 日）发布博文，复盘发现 GPT-5.1 系列及后续 AI 模型出现异常行为，在回答中频繁使用“哥布林”（goblin）和“小魔怪”（gremlin）等生物隐喻。 OpenAI 官方调查后发现，自从 GPT-5.1 系列发布以来，“哥布林”一词使用率上升 175%，“小魔怪”上升 52%。这一现象并非偶发，而是模型行为被特定奖励信号塑造的结果。 调查溯源发现，异常源于“书呆子”人格定制功能的训练过程。该功能仅占 ChatGPT 总回复量的 2.5%，却贡献了 66.7% 的“哥布林”提及量。 审计显示，原本用于鼓励该人格风格的奖励模型，在 76.2% 的数据集中对包含生物词汇的输出给予了更高评分。 技术团队发现，这种行为具有跨场景泛化能力。尽管奖励仅在“书呆子”条件下应用，但强化学习无法保证限制习得行为。 随着含生物词汇的输出被用于后续监督微调，模型形成了“奖励-生成-训练”的正反馈循环，导致该行为扩散至其他场景。IT之家附上相关图表如下： OpenAI 针对此问题，已采取多项措施。技术团队移除了偏好生物词汇的奖励信号，并从训练数据中过滤了包含相关词汇的内容。受限于训练周期，GPT-5.5 未能完全规避此问题，开发团队通过添加指令提示进行了缓解。 相关阅读： 《 OpenAI Codex 系统提示词披露，GPT-5.5 AI 模型“永不谈论哥布林” 》 参考 Where the goblins came from
IT之家 4 月 26 日消息，阿耳忒弥斯 2 号任务现已圆满结束，美国国家航空航天局（NASA）已开始对本次任务所有协同运作的系统开展事后性能分析。本月早些时候，这套系统护送四名宇航员安全飞掠月球。阿耳忒弥斯 2 号不仅将人类带到了前所未有的深空位置，也为后续载人任务完成了关键试飞。NASA 后续载人任务最早计划于 2027 年、2028 年实施，而 2028 年正是 NASA 拟定的宇航员登陆月球表面的宏伟目标年份。截至目前，猎户座飞船与太空发射系统（SLS）火箭的整体表现都十分出色。 NASA 表示，对乘员舱的初步评估显示，其隔热罩表现符合预期，未发现任何异常状况，且烧蚀损耗程度远低于无人试飞的阿耳忒弥斯 1 号任务。（宇航员返回溅落海面后，海军潜水员拍摄到了隔热罩在水下的高清实拍画面，详见下图。）据 NASA 介绍，此次溅落全程按计划进行，猎户座飞船实际着陆点距离预定落点仅 2.9 英里（IT之家注：约 4.7 公里），再入大气层时的初始界面速度与预测值误差不超过每小时 1 英里（约 1.6 公里）。 NASA 称太空发射系统（SLS）火箭同样表现优异。相关后续测试仍在进行中，航天局在一篇博客文章中提到：“主发动机关机、芯级 RS-25 液体发动机停止工作时，飞船时速已超 18000 英里（约 28968 公里），精准达到入轨速度，并精确抵达预定轨道位置。” 不过任务中确实有一处设备出现故障 —— 马桶系统。发射后不久，宇航员就报告尿液排放管路出现问题，任务专家克里斯蒂娜・科赫在地面工作人员协助下完成了故障排查。为避免后续任务重演此类问题，NASA 现已组建专项团队， 核查相关硬件设备与任务数据，排查故障原因并制定预防方案 。 阿耳忒弥斯 2 号宇航员持续分享绕月旅程的珍贵画面。本周，任务指令长里德・怀斯曼发布了一段绝美视频， 从猎户座飞船视角拍下了地球从月球后方缓缓落下的景象 。上一次人类亲眼目睹这一天文景象，还要追溯到 50 多年前的阿波罗登月任务。 在太空停留十天看似时间不长，却依然会对人体产生影响，宇航员重返地球后还需要一段时间适应。宇航员科赫上周发布了一段视频，记录了自己返回地球后，闭眼进行双人同步行走训练时步履不稳的状态。 她在配文中解释道：“人类长期处于微重力环境时，体内负责向大脑传递运动方位信号的前庭器官会出现功能紊乱。大脑会逐渐忽略这类失衡信号，因此刚回到重力环境时，我们只能极度依赖视觉来辨别方位、保持平衡。”
IT之家 4 月 24 日消息，微软资深工程师 Raymond Chen 昨日（4 月 23 日）发布博文，披露了一起典型的 Windows 资源管理器崩溃案例，指出崩溃并非 Windows 自身缺陷导致， 而是由某第三方卸载程序错误的函数调用约定导致内存损坏所致。 在一次常规调试会议中，Chen 的同事发现 Windows（原文并未明确具体版本）文件管理器崩溃率出现异常峰值。通过检查崩溃转储文件，Chen 迅速锁定了问题源头：在 64 位系统上运行的 32 位资源管理器进程。 IT之家援引博文介绍，在 64 位 Windows 系统中，微软出于兼容性考虑保留了 32 位版本的文件资源管理器，通常位于 C:/Windows/SysWOW64 目录。 该版本一般不通过用户直接操作触发，主要由传统的 32 位应用程序调用。Chen 据此推断， 崩溃极大概率源于某款 32 位第三方应用的非标准交互，而非用户常规操作或系统内核问题。 Chen 深入分析特定版本的故障卸载程序后，发现了导致崩溃的具体技术缺陷。该卸载程序的注入代码包含一个执行文件操作的循环，若操作失败会暂停后重试。 然而，开发者在编写代码时犯下了致命错误：未正确指定函数调用约定。代码错误地使用__cdecl 约定调用 Windows 函数，而 Windows 函数实际遵循__stdcall 约定。 这两种约定在堆栈清理机制上存在根本差异：__stdcall 由被调用者清理堆栈参数，而__cdecl 则要求调用者清理。 这种调用约定不匹配引发了严重的堆栈破坏问题。每次调用 Windows 函数后，参数被压入堆栈，Windows 函数执行后弹出参数，随后调用代码再次尝试弹出参数。这导致堆栈指针每次循环都错误地移动，逐步蚕食程序自身的堆栈空间。由于重试循环执行次数极多，堆栈最终被消耗殆尽，堆栈指针甚至递增到了注入代码所在的内存区域。 这种内存损坏导致了栈空间被“吃光”，进而直接拖垮了文件资源管理器进程。科技媒体 NeoWin 指出，在系统组件出现崩溃后，公众往往习惯性归咎于操作系统，但第三方软件开发者的技术失误同样可能成为系统不稳定的根源。 相关阅读： 《 微软工程师：别总把锅甩给 Windows 更新，Win11 系统崩溃不一定是更新的错 》