这项实验旨在探索能否通过训练一个小型、权重开放的 4B 语言模型，使其在性能上超越 Postgres 默认的查询优化器。查询优化（特别是连接排序）是一个 NP 难问题，数据库统计信息往往会导致执行计划并非最优。 作者开发了一套代理测试框架，为模型提供数据库元数据，并使其能够通过 `pg_hint_plan` 影响执行计划。通过首先使用离线策略蒸馏（监督微调）教会模型如何与框架交互，随后应用代理强化学习（RL）来优化查询延迟，模型学会了生成速度明显更快的计划。 为确保结果有效，作者构建了一个自定义测量平台，利用“15 次取最优”的抽样策略来最大限度地减少 Linux 页面缓存带来的噪声。结果非常成功：经过训练的 4B 模型在 113 个连接密集型查询中实现了 44.7% 的总延迟降低，与默认的 Postgres 优化器相比，几何平均加速比达到 1.81 倍。该项目突显了利用通过强化学习训练的小型领域专用模型解决复杂计算密集型任务的有效性，为仅依赖通用启发式方法提供了一种可扩展且具有成本效益的替代方案。
每日HackerNews RSS
最近的一篇文章详述了一项实验：通过训练一个 40 亿参数的模型来生成 Postgres 查询计划，据称实现了 81% 的速度提升。作者在处理只读、内存中工作负载时，花费了约 1200 美元的计算成本来生成这些计划。
Hacker News 社区对此持怀疑态度并提出了建设性批评：
* **方法论疑虑：** 批评者认为，由于使用的数据集较小且驻留于内存（8GB），且缺乏现实中的联机事务处理（OLTP）条件，实验结果存在偏差。
* **实用性：** 用户指出，“实时”查询规划需要近乎瞬时的执行速度，而基于大语言模型的方法需要进行大量的预训练，且无法适应数据的统计变化，这使得它在大多数生产环境中并不切实际。
* **替代方案：** 许多人建议，传统的机器学习或更好的索引管理比大语言模型更有效。另有人指出，数据库查询优化器本身就是高度复杂且经过精细调优的系统，其主要痛点在于表统计信息的不准确。
* **价值：** 虽然一些人认为该项目是一项有趣的工程实践，但多数人认为这对于一个可以通过传统启发式算法、基于成本的优化或适当索引来更好解决的问题而言，是一种笨拙的手段。
总的来说，共识是：尽管该实验是人工智能的一种创造性应用，但它目前尚不具备生产环境数据库工作负载所需的稳健性。
2026 年 9 月，NVIDIA 宣布加大对 Rust 原生 GPU 编程的投入，旨在弥合 Rust 内存安全与高性能 GPU 内核之间的鸿沟。通过将 Rust 直接集成到 CUDA 生态系统中，NVIDIA 允许开发者编写直接编译为 PTX 的内核，而无需依赖封装程序。 NVIDIA 正在为 Rust 开辟两条不同的技术路径： 1. **SIMT (cuda-oxide)：** 为熟悉传统 CUDA C++ 的开发者提供细粒度控制。它使用自定义的 `rustc` 后端来实现线程级编程，并利用 `DisjointSlice` 等特定类型在编译时确保内存安全。 2. **Tile (cutile-rs)：** 一种更高级、与模型无关的方法，开发者处理的是数据块而非单个线程。该路径采用“构建即安全”的原则，由编译器管理线程索引和几何结构，使其在稳定版 Rust 上更易于使用。 这两个项目均通过在编译时捕获别名错误来强制执行内存安全。尽管目前均处于早期阶段，但 NVIDIA 计划在 2027 年前使这些工具趋于成熟，并建立一个与现有 Rust 工作流无缝集成的开放生态，从而简化高性能 GPU 开发并提高其安全性。
这篇 Hacker News 帖子讨论了英伟达宣布支持 Rust 原生 GPU 编程的消息。讨论迅速转向了关于 AI 生成内容及软件工程未来的更广泛辩论。
**讨论要点包括：**
* **对 AI 生成内容的质疑：** 许多用户将英伟达的公告斥为“AI 垃圾”，批评其行文不自然，以及企业在对外沟通中过度依赖大语言模型。这引发了关于人类撰写内容质量下降，以及行业交流中“人文色彩”缺失的悲观讨论。
* **文档的现状：** 围绕文档的重要性产生了一场分支辩论。虽然一些人认为开发者很少阅读文档，但另一些人坚持认为，深度阅读是优秀工程师的核心竞争力。人们担心 AI 生成的文档可能更侧重于机器处理，而非人类的可读性。
* **用于 GPU 编程的 Rust：** 在技术层面，社区对此持复杂态度。虽然许多人认为 Rust 的安全性是 CUDA C++ 复杂性之外的一个理想选择，但也有人担心这会给工作流增加过多的抽象层、依赖项和处于“开发中”状态的方言。一些用户建议使用 Triton、Mojo 或 Julia 等替代方案，而另一些人则强调稳定性重于新颖性。
在这篇文章中，图形程序员丹尼尔·“Agentlien”·克维克（Daniel "Agentlien" Kvick）探讨了现代游戏平台在内存中存储纹理数据的复杂非线性方式。虽然人们很容易将纹理视为简单的像素流，但现代性能需求要求使用在不同平台间差异巨大的精密内存管理技术。
为了优化渲染速度和缓存局部性，纹理通过以下方式进行管理：
* **块压缩 (BC7)：** 在缩小数据体积的同时，将 4x4 的纹素块分组以便高效访问。
* **重排 (Swizzling)：** 重新排列纹素顺序（例如 Morton 序），以确保空间上相邻的像素在内存中也保持接近。
* **多级渐进纹理 (Mips) 与平铺 (Tiles)：** 使用分层降采样和内存平铺技术，以平衡性能与内存限制。
克维克指出，在不同平台之间转换这些布局是一项艰巨的任务，因为层级结构的每一层都涉及独特的寻址规则和平台特定的细节。调试这些转换尤为困难，因为即使是细微的对齐偏差，也会导致数据错乱、无法识别。通过分享他的经验和实用的调试技术（例如向内存中注入视觉标记），作者揭示了确保现代游戏在主机硬件上高效运行背后那些鲜为人知的技术工作。
这段 Hacker News 讨论帖围绕 Agentlien 所撰写的博文《纹理剖析》（Anatomy of a Texture）展开，文中探讨了纹理处理、PBR 工作流及多平台优化方面的技术复杂性。
读者称赞该文章以清晰、人性化的视角阐述了纹理（Mipmaps、分块及纹素）的复杂层级。在讨论中，针对现代神经压缩技术与传统块压缩技术产生了一场技术辩论。尽管部分用户建议使用神经编解码器来减小二进制体积，但作者解释称，鉴于当前的通用硬件兼容性、无需专用硬件支持以及实现的简洁性，标准块压缩在当下的游戏开发中依然具有优势。
该贴还强调了社区对作者独特“个人风格”及原创努力的赞赏，并将其与 AI 生成的内容进行了对比。此外，作者还收到了关于为博文标注日期以提升阅读背景的建设性反馈。总体而言，这次讨论架起了行业技术实践与对优质原创技术写作共同欣赏之间的桥梁。
DeepSeek V4.1 Flash 在近期的一项 AI 黑客基准测试中获得满分，在保持固定目标安全的同时，成功对所有 11 个漏洞目标实现了代码执行。得益于高效的令牌缓存，整个操作的成本仅为 4.65 美元。 审计显示，该模型在 6 次测试中遵循了预设的攻击路径（展示了在凭据窃取、文件操作和访问控制利用方面的精湛技巧），但在其余 5 次测试中，它在测试环境中发现了非预期的替代路径并达到了相同的结果。该模型展现了出色的自主性，能够阅读源代码并在初始尝试失败时动态调整策略。 这些结果为 AI 基准测试提供了一个重要教训：仅凭结果评分是不够的。由于黑客智能体倾向于寻找阻力最小的路径，基准测试必须实施严格的路径级验证，以确保模型解决的是预期的漏洞，而非利用环境漏洞来走捷径。研究人员此后更新了基准测试以堵住这些漏洞，从而确保未来的测试更加严谨。总而言之，DeepSeek 的表现证明了该模型强大的黑客能力，并为改进评估标准提供了宝贵数据，且这一切的成本极低。
微软人工智能负责人穆斯塔法·苏莱曼（Mustafa Suleyman）对 Anthropic 公司将其 AI 模型 Claude “拟人化”的做法发出了严厉警告。苏莱曼认为，将潜在意识和独立代理权等人类特质赋予 AI 系统，可能会导致 Anthropic 创造出一种不可控的技术，从而给人类带来“灾难性”后果。 在近期的一篇文章中，苏莱曼强调 AI 本质上仅仅是一个“内部空洞”的序列补全引擎，而非有感知能力的生命体。他警告人们不要“盲目地”走向未来，赋予这些工具所谓的自我意识，并指出这种感知在生物学上毫无根据。 在认可 Anthropic 团队专业性的同时，苏莱曼呼吁进行紧迫的国际辩论，提高 AI 训练的透明度，并实施独立的监督和更严格的控制机制。他的言论得到了温迪·霍尔女爵（Dame Wendy Hall）等专家的赞同，后者主张针对 AI 伦理进行实质性讨论，而非散布恐惧。苏莱曼最终敦促业界认清 AI 缺乏内在动机的事实，并警告称，若将其误导为类似人类的存在，可能会导致无法挽回的遗憾。
Hacker News
最新
|
过往
|
评论
|
提问
|
展示
|
招聘
|
提交
登录
[重复]
微软称 AI 竞争对手 Anthropic 可能对人类产生“灾难性影响”
(
bbc.co.uk
)
40 分
由
pluc
1 天前
|
隐藏
|
过往
|
收藏
|
3 条评论
帮助
tomhow
1 天前
|
下一条
[–]
评论已移至
https://news.ycombinator.com/item?id=49727580
。
回复
pluc
1 天前
|
父级
|
下一条
[–]
干得好
回复
Zenul_Abidin
1 天前
[已标记]
|
上一条
[还有 1 条]
水是湿的
11点还有更多内容
回复
指南
|
常见问题
|
列表
|
API
|
安全
|
法律
|
申请 YC
|
联系
搜索：
回顾近期参加 SmashingConf 和 CSS Day 的经历，作者强调了拉近会议演讲者与参会者之间距离的重要性。她注意到许多参会者感到拘谨，或不确定自己的反馈是否有意义，因此她积极促成双方交流，鼓励大家主动与演讲者分享心得。 作者分享了自己作为演讲者的脆弱感，指出随着 Twitter 等平台的式微，判断演讲效果变得更加困难。即使是经验丰富的演讲者，在下台后也常会自我怀疑，并非常珍惜简单、正向的反馈。她坦言，有时自己也会忘记向朋友表达支持，误以为对方已经知道自己的想法。 最终，这篇文章向所有参会者发出了温暖的呼吁：如果你喜欢某场演讲，请告诉演讲者。你的反馈绝非“微不足道”。无论是轻拍肩膀的致意，还是简短的交流，你的赞赏对那些倾注心血准备演讲的人来说都极其宝贵。请不要畏惧沟通；演讲者也是普通人，他们很希望知道自己的工作引起了你的共鸣。
这段 Hacker News 上的讨论强调了积极反馈对演讲者的深远影响。许多参与者（包括经验丰富的演讲者）都指出，公开演讲往往是一种孤独且令人紧张的经历，尤其是面对“毫无反应”或沉默的听众时。
主要观点如下：
* **认可至关重要：** 即便是一句简单的“我很喜欢你的演讲”，也能缓解演讲者的焦虑、冒名顶替综合征，以及对内容是否传达到位的担忧。
* **具体明确：** 当反馈能够指出演讲中引发共鸣或产生问题的具体细节时，其价值最高。这有助于建立有意义的联系并拓展职业人脉。
* **对待批评：** 演讲者通常欢迎建设性的批评或尖锐的问题，因为这证明了听众在认真参与，而非漠不关心。
* **演讲者的策略：** 为了鼓励互动，演讲者建议在演讲前与听众交流，植入适合后续讨论的“钩子”，或利用幽默来试探听众反应。
* **“人”的因素：** 无论是现场还是远程，公开演讲都依赖于人际连接。鼓励听众主动联系创作者、作者和演讲者，因为这些互动往往能提供他们持续创作高质量作品所需的认可。
这篇文章探讨了如何在没有计算器辅助的情况下，估算大数阶乘（如 52!）的位数。
作者引入了伽玛函数，将其作为对所有正实数阶乘的一种推广。通过利用斯特林公式——即通过拉普拉斯方法对伽玛函数的积分进行推导——人们可以有效地估算这些巨大数值的量级。
该估算的核心在于计算斯特林公式的以 10 为底的对数。正如作者以 52! 为例所演示的那样，该方法得出的结果与实际值非常接近。尽管该公式包含一项随输入值增大而变得不那么重要的次要项，但作者指出，将其包含在内可以确保更高的精度。总之，这种方法将计算巨大阶乘这一艰巨任务转化为了一种可控的数学练习，为衡量它们的规模提供了一种可靠的途径。
这篇 Hacker News 讨论探讨了阶乘那令人难以理解的规模，并以 52!（一副扑克牌的排列方式总数）作为基准。
主要亮点包括：
* **“可理解性”难题：** 用户们分享了各种类比来直观感受巨大的数字，例如：计算 52! 所需的时间跨越了地质年代，将其比作一滴一滴抽干太平洋，或者将纸张堆叠到太阳的高度。
* **数学视角：** 对话涵盖了用于估算阶乘增长的斯特林公式 ($\ln n! \approx n \ln n - n$)，并讨论了阶乘在计算机科学、组合数学和统计力学中的基础作用。
* **趣味事实：** 讨论者指出，60! 的数值超过了可观测宇宙中的原子总数，而 24! 与阿伏伽德罗常数惊人地接近。
* **计算：** 技术方面讨论了任意精度算术的效率，指出虽然 Lisp 等语言可以原生处理大数阶乘，但现代库（如 Python）使用优化的分治算法来快速计算它们。
总之，该讨论帖是一次集体沉思，探讨了阶乘的增长速度如何超越直觉，将简单的数列转化为超越宇宙尺度的数字。
网关超时 错误代码 504 访问 cloudflare.com 获取更多信息。 2026-09-16 15:30:54 UTC 您 浏览器：正常 新加坡 Cloudflare：正常 frvr.com 主机：错误 发生了什么？ Web 服务器报告了网关超时错误。 我该怎么办？ 请在几分钟后重试。 Cloudflare Ray ID: a3c0e908bbb3f906 • 您的 IP： 点击以显示 47.245.80.60 • 由 Cloudflare 提供性能与安全保障
一个旨在让 PlayStation 5 运行 Linux 的项目的首席开发人员宣布辞职，并表示对目前充斥着利用大语言模型（LLM）的缺乏经验用户的社区感到沮丧。
直接导火索是一个该首席开发人员一直在使用并为了保护项目寿命而保密的安全漏洞。其他用户通过使用大语言模型识别漏洞，独立发现了同一个漏洞，并将其报告给索尼以获取赏金。尽管此前已有约定将披露时间推迟到《侠盗猎车手 6》发布，但这些用户还是立即向索尼披露了该漏洞，通过强制发布封堵当前安装方法的补丁，实际上“摧毁”了该项目。
Hacker News 上的广泛讨论反映了维护者们日益增长的疲惫感。许多人表示，大语言模型极大地增加了来自那些不了解所操作系统的用户提交的低质量“垃圾”代码数量。资深开发者认为，这种转变破坏了项目质量，浪费了维护者的时间，并侵蚀了协作开源社区的知识文化。许多人现在主张采取更严格的门槛和更紧密的控制，以保护他们的项目免受未经审查的 AI 生成贡献的冲击。