该数据集展示了 48 种不同模型在五个不同测试类别中的 JevBench 性能排名。结果显示出显著的差异性，许多模型的排名与其 JevBench 总分相比存在波动。 **主要观察结果：** * **顶尖表现：** Jev 1.13.0、SemIf 和 djev 等模型表现稳定，排名靠前，在所评估的类别中经常位居前列。 * **性能差距：** 性能差距巨大，从得分较高的模型（70 多分和 80 多分）到排名垫底的模型（如 Certo v1，得分接近零）不等。 * **不一致性：** 数据中一个值得注意的反复出现的现象是，各分类别的排名经常与 JevBench 总分不同，这表明某些模型无论总排名如何，在特定的测试环境下可能表现优异或不佳。 * **底层梯队：** 榜单末尾是一些专用模型和重排序模型（如 GLiNER、Mixedbread、BAAI），它们在这些特定基准测试中的表现微乎其微。 总体而言，该数据突显了模型能力的多样化格局，其性能高度依赖于具体的评估标准。
每日HackerNews RSS
**JevBench** 是一款全新的、可复现的基准测试工具，旨在评估“Jev 类”模型。这类模型属于类型化决策模型，输出的是结构化的选择和概率，而非原始文本。与传统大语言模型相比，它们在保持高智能水平的同时，更具速度优势且成本效益更高。
该基准测试提供了一套统一的评分系统（v1.3），平衡了四个关键指标：智能水平（经机会修正）、校准度、速度和成本。用户可以根据自身需求自定义这些指标的权重。完整的评估包含 534 项英语决策任务。
目前的排行榜显示，*Jev* 以 74.4 分位居榜首，*SemIf* 和 *djev* 紧随其后。
该项目完全开源（MIT 许可证），并公开了工具产物、评分代码和任务结果。尽管开发者指出了目前的局限性（例如仅限英语，且延迟测量依赖于单台德国服务器），但该工具已正式上线，并提供两个无需注册的演示页面，供用户亲自测试性能。
**资源：**
* **GitHub：** [fstandhartinger/jevbench](https://github.com/fstandhartinger/jevbench)
* **演示：** [who-is-right](https://who-is-right.app.mintapis.com) 和 [is-it-ai-slop](https://is-it-ai-slop.app.mintapis.com)
在 Carson Gross 的文章中，他认为随着代理式编码（agentic coding）成为标准，Markdown 正在从单纯的文档转变为一种至关重要的源代码形式。目前，软件的“真实依据”（ground truth）往往在短暂的 LLM 对话中丢失。为了解决这一问题，Gross 提出开发者应将项目意图显式地记录并存储在位于 `/src` 目录下的 Markdown 文件中。 将这些文档移入源码树具有多重优势：它为人类开发者和 AI 代理提供了“局部性”（locality），创建了可版本控制、可对比的架构决策记录，并确立了一个比单纯的测试代码更具可读性和可操作性的真理源。 Gross 构想了一种工作流程，即 Markdown 作为高级规范，代码和测试皆由此衍生。他建议采用标准化的 `/src/md` 结构来存放技术概览、数据模型和功能规范。尽管这需要人为进行严谨的维护以管理复杂性，但 Gross 断言，随着编码自动化的成本降低，捕捉系统背后的“意图”将成为现代软件开发中最宝贵的资产。
这篇 Hacker News 帖子探讨了将 Markdown 文档直接放置在 `/src` 目录下的提议，旨在提高可访问性并更好地整合基于 LLM 的开发工作流。
讨论揭示了开发者在理念上的分歧：
* **支持者：** 许多人认为，将文档与代码放在一起可以减少上下文切换，使人类和 AI 智能体都能更容易地参考需求、规范和提示词。一些人认为，这是一种让 LLM 在整个开发生命周期中都能获取上下文的“低技术含量”方法。
* **批评者：** 持怀疑态度的人认为，文档应保留在 `/docs` 中，以保持源代码与元数据的清晰分离。另一些人警告称不要“弄乱”源代码目录，甚至有人讽刺道，如果把 Markdown 存在 `/src` 里，那干脆把日志、构建产物和截图也存进去好了。
* **其他观点：** 一些参与者主张采用既定模式，如将测试用例或清晰的代码本身视为主要文档；另一些人则认为，相比于根目录下的 `/src` 方案，针对具体包的文档（例如 `packages/foo/docs`）是更具扩展性的解决方案。
总的来说，这篇帖子反映了关于如何更好地管理“AI 原生”代码库这一议题日益增长的争论。
与CPU技术停滞不前的观点相反，AMD的Ryzen 7 “X3D”系列展示了显著且持续的性能增长。对比Zen 3 (5800X3D)、Zen 4 (7800X3D) 和 Zen 5 (9800X3D) 处理器，2022年至2024年间，其单核性能提升了47%，多核性能提升了58%。
这些增长并非仅靠时钟频率驱动，时钟频率仅有15%的适度增长。相反，AMD通过增加50%的晶体管数量使核心显著“变宽”来实现这些成果。关键的架构改进包括更高的发射宽度（从每周期6条指令增加到8条）、更大的缓存容量、更多的整数算术逻辑单元（ALU），以及更大的重排序缓冲区以更好地管理指令流。此外，Zen 5通过将SIMD单元加倍至512位宽度，标志着数据并行处理的重大转变。随着业界展望Zen 6，这些桌面芯片的演进证明了CPU创新依然充满活力且激进。
这篇 Hacker News 讨论探讨了过去两年 AMD Ryzen 性能迅速提升背后的驱动因素。用户将其归功于以下几项技术改进：
* **散热与设计效率：** X3D 芯片缓存位置的调整改善了散热，从而实现了更高的时钟频率并减少了过热降频。
* **制造工艺：** 更先进的制程节点降低了电压需求，使其能在相同的热设计功耗内实现更高频率。
* **架构：** 评论者指出，Ryzen 的可扩展性远超 AMD 此前的 FX 系列，并将其与英特尔 Nehalem 架构的影响力相提并论。
* **软件优化：** 除了硬件层面，用户强调 Linux 内核更新、开源编译器 (GCC) 的持续改进以及 x86-64v3 指令集目标对性能提升贡献巨大。
* **战略发布节奏：** 一些观点认为，50% 的增长数据受到了 3D V-Cache 版本发布时间的影响，这可能会放大年度增长幅度。
总体而言，社区对 Zen 6 等未来迭代产品持乐观态度，同时指出像 9950X3D 这样的现有芯片在处理高负载任务时仍极具竞争力。
OpenAI 近日声称在纳维-斯托克斯方程问题上取得了突破，该问题是克雷数学研究所设立的一项著名难题。尽管从技术上讲，该证明符合原始命题的标准，但数学家们认为它利用了一个漏洞，即引入了外力——这在他们看来是不符合物理本质的，且与他们试图理解的基础物理学脱节。 专家指出，OpenAI 的模型解决的是该问题的一个特定且人为构建的变体，而非核心数学难题。数学家随后的分析表明，该 AI 的方法无法扩展到科学界真正重视的问题版本。本质上，该 AI 成功绕过了奖项的形式要求，却错失了潜在的物理意义，这突显了数学命题的死板措辞与理论研究细微目标之间的区别。 这场争议凸显了当前大语言模型的局限性：它们擅长在复杂的约束条件下找到明确的特定解，但在推进数学发展所需的深层原创理论方面却显得力不从心。这一事件也敲响了警钟，表明尽管 AI 是暴力搜索发现的有力工具，但数学领域最具深度的“人类”挑战在很大程度上仍超出其能力范围。
这篇 Hacker News 讨论聚焦于《科学美国人》的一篇文章，该文章质疑 OpenAI 最近尝试解决纳维-斯托克斯（Navier-Stokes）方程的方法是否采用了正确的公式化表述。
参与者指出，纳维-斯托克斯千禧年大奖问题的要求十分具体，在涉及外力场的公式中寻找反例（AI 似乎更擅长此道）可能比在其他公式中更容易。用户还强调，在可压缩流体（该大奖范围之外的领域）中更容易发现奇点。
尽管一些用户以调侃的态度嘲讽“AI 对抗数学”的炒作周期，但也有人认为讨论其实更为微妙。社区的共识是，虽然 AI 在推动数学研究方面的能力令人印象深刻且有用，但目前的讨论重点在于这些模型的局限性、训练数据缺乏透明度，以及基于强化学习的证明策略能否弥合差距，从而解决长期存在的复杂数学难题。归根结底，社区认为围绕这一成果的“风波”是对一场复杂且持续的技术辩论的过度简化。
为遵守全球年龄认证相关法律，Discord 即将引入一套自动化系统，将用户分为“成人”（18岁及以上）或“青少年”（13至17岁）组别。 该系统基于账户行为（如账户注册时长和社区活跃度）使用年龄估算模型，而非查看私人信息。超过 90% 的用户将自动归类，无需采取任何行动。成人组用户的使用体验不会发生变化，而青少年用户将获得额外的安全保护，例如模糊处理敏感内容以及限制访问设有年龄门槛的服务器。 状态为“未确认”或认为归类有误的用户，可以通过多种注重隐私的方式手动验证年龄，包括信用卡验证、共享 Apple/Google 账户年龄信息或使用 AgeKey。Discord 强调，他们不会存储个人身份信息或生物识别数据，仅会从第三方供应商处获取年龄组别信号。 其他用户无法查看您的年龄状态，且消息发送、非受限语音通话等核心功能对所有用户保持开放。如果您此前已完成年龄验证，您的状态将保持不变。您可以在“用户设置”>“账户状态”中查看当前的年龄组别。
Hacker News
最新
|
往期
|
评论
|
提问
|
展示
|
招聘
|
提交
登录
关于我们在 Discord 上确认您年龄段方式的更新
(
discord.com
)
45 点
由
meetpateltech
发布
1 小时前
|
隐藏
|
往期
|
收藏
|
2 条评论
帮助
shaoonb
4 分钟前
|
下一条
[–]
在英国仍然需要使用视频或身份证。
回复
Foskya
23 分钟前
|
上一条
[–]
我其实挺喜欢他们的实施方式。
我很好奇这是否足以应付政府的要求，但他们尝试寻找一条无需身份检查的路径，这一点很好。
回复
社区指南
|
常见问题
|
列表
|
API
|
安全
|
法律
|
申请 YC
|
联系方式
搜索:
“我们黑进了FBI”：黑客声称掌握了所有FBI员工的数据 'We hacked the FBI:' Hackers say they have data on all FBI employees
3 小时前
黑客组织“ShinyHunters”声称已侵入联邦调查局（FBI）系统，据称窃取了 2 至 3 TB 的数据，其中包括所有现任和前任 FBI 员工及申请人的个人信息。该组织声称他们利用了甲骨文（Oracle）PeopleSoft 软件中的一个零日漏洞，从而入侵了亚马逊云科技（AWS）的 GovCloud 服务器。 为了支持其说法，黑客向 404 Media 提供了一份包含 5,000 条记录的样本，其中涵盖了姓名、家庭住址、电话号码和配偶详细信息，研究人员已使用开源情报工具对这些数据进行了核实。该组织还曾短暂篡改了 FBI 的招聘网站。 尽管 ShinyHunters 以勒索著称，但他们称此次特定攻击并非出于经济动机，而是为了“胁迫”。此次泄密造成了严重的国家安全风险，因为这些敏感个人数据可能被外国情报机构或犯罪组织利用，以跟踪、骚扰或恐吓特工。FBI 尚未对此置评，但受影响的招聘门户网站已下线。
黑客声称已入侵一个包含所有联邦调查局（FBI）员工个人信息的数据库。Hacker News 上的讨论指出，此次入侵是通过一个 PeopleSoft（甲骨文人力资源系统）的零日漏洞实现的，该漏洞促使攻击者横向移动到了政府云环境中。
评论者们正在讨论此次黑客攻击的影响，许多人对过度依赖第三方企业软件所带来的系统性漏洞表示担忧。一些用户将其与 2015 年的美国人事管理局（OPM）数据泄露事件进行了对比，另一些人则批评了企业和政府的安全实践，质疑离岸外包和行政裁员是否削弱了国家数字基础设施的安全性。
对于这些指控的真实性，目前仍存在质疑，有人推测这些数据可能是一个旨在诱捕攻击者的“蜜罐”。此外，这一事件引发了人们的讽刺，认为 FBI 近期在大力强调采用人工智能工具，而此次泄露却形成了鲜明对比；另一些人则在思考，这是否反映出美国在面对日益猖獗的网络对手时，其网络安全韧性正在整体下滑。
本仓库是官方的 **GeaStack 应用库**，收录了模拟器、GeaOS、嵌入式目标平台以及 IDE 扩展的示例。每个项目都是一个独立的包，通过 `package.json` 中的 `gea` 清单进行定义，并指定了运行时目标（Web、ESP32、GeaOS）及元数据。 **核心工作流亮点：** * **开发：** 使用 `geastack/simulator` 仓库来运行和构建应用，只需将 `GEA_APPS_ROOT` 环境变量指向本目录即可。 * **部署：** 通过 Gea CLI 使用 `npx gea flash` 直接烧录到兼容硬件。 * **最佳实践：** 示例应保持小巧、专注，并优先使用共享框架 API，而非针对特定目标的“黑客”写法。贡献者应为复杂逻辑编写测试，并保持文档更新。 **许可协议：** 本仓库采用 **MIT** 协议，允许开源或闭源使用。请注意，特定的嵌入式板卡支持组件采用 **GPL-3.0** 协议；若需使用这些特定工具发布闭源固件，则需要获得商业授权。如需支持或进行商业咨询，请联系 [email protected]。
这篇 Hacker News 讨论介绍了一个名为 **Geastack** 的项目，它允许开发者使用 TypeScript 和 CSS 构建原生应用程序。
讨论的主要要点包括：
* **技术基础：** 该项目作为一个将 TypeScript 编译为 C++ 的编译器运行，并带有特定于平台的绑定，从而实现高性能。
* **渲染引擎：** 它将 CSS、JSX 和 HTML Canvas API 等 Web 技术直接映射到原生平台组件和界面上。
* **应用场景：** 用户指出该技术特别适合嵌入式应用程序。
社区讨论澄清了其底层架构，特别提到编译器在消除“承载性”装箱（load-bearing boxing）方面取得了最新进展，此前这一问题曾影响内存效率。
这项研究探讨了大型语言模型（LLMs）如何从不同规模的加权训练数据中进行学习，并引入了“有效序列权重指数”（$\alpha$）来量化模型根据分配权重优先处理序列的程度。
研究表明，数据加权并不遵循简单的单调缩放定律，而是呈现出一种“异常”行为：
* **小规模模型**的 $\alpha$ 值较低，主要学习独立于特定数据权重的通用模式。
* **中等规模模型**的 $\alpha$ 值较高，其容量主要集中在与分配权重成正比的模式上。
* **大规模模型**的 $\alpha$ 值回落至较低水平，具备了学习数据中所有模式的能力，而不受权重影响。
研究人员指出，这种趋势会随训练轮次（epoching）而变化，且在不同的模型架构中表现各异。由于小规模模型的表现往往无法预测大规模的结果，作者提醒研究者不要单纯依赖简单的外推法来制定数据混合策略。他们总结认为，识别这些非单调行为对于优化训练方法、确保缩放实验的可靠性，并最终开发出能力更强的模型至关重要。
Hacker News
最新
|
过往
|
评论
|
提问
|
展示
|
招聘
|
提交
登录
大规模序列加权研究
(
janestreet.com
)
6 点
由
pranitha_m
发布
1 小时前
|
隐藏
|
过往
|
收藏
|
1 条评论
帮助
gwern
7 分钟前
[–]
双重下降？
回复
指南
|
常见问题
|
列表
|
API
|
安全
|
法律
|
申请 YC
|
联系
搜索:
这项研究介绍了 **C-HD**，这是一种用于在具有非负实数权重的有向图中寻找精确最短路径的新型确定性算法。该算法由人工智能体协作团队开发，并使用 **Lean** 进行形式化验证，以确保其正确性和性能。 在 $m \le n \lfloor \log_2 n \rfloor^{3/4}$ 的特定密度范围内，C-HD 的复杂度达到了 $O(n + m + m \log(2 + \frac{m}{n+1}) + m^{1/3}(n \log(n+2))^{2/3})$。通过利用有界局部搜索并保持严格的局部不变性，该算法相比 Dijkstra 及其他顶尖方法减少了重复工作。 在 $m \approx n \log^{3/4} n$ 的图中，C-HD 在理论上比 Dijkstra 的 $O(n \log n)$ 界限有了渐近改进，达到 $O(n \log^{11/12} n)$。尽管这在理论计算机科学中是一个显著的多对数级进展，但研究人员指出，由于该结构涉及较大的常数，它更多是对算法性能的数学证明，而非针对实际应用的性能提升。该项目展示了多智能体协作在推动形式化数学验证和算法优化边界方面的潜力。
Hacker News
最新
|
过往
|
评论
|
提问
|
展示
|
招聘
|
提交
登录
更快速的最短路径算法
(
vals.ai
)
6 点
由
leumon
38 分钟前发布
|
隐藏
|
过往
|
收藏
|
讨论
帮助
指南
|
常见问题
|
列表
|
API
|
安全
|
法律
|
申请 YC
|
联系
搜索：
在构建智能推荐系统“HoneyCrew”的一场高压黑客马拉松中，团队遭遇了危机。在利用“灵感编程”（vibe coding）工具取得初步进展后，项目在最后几个小时陷入了漏洞频发和不稳定的困境。这种混乱凸显了非技术利益相关者与工程复杂现实之间常见的摩擦——前者往往将软件开发视为一项简单、静态的任务。 作者用房屋翻修的类比来解释这种复杂性：正如盖房子需要地基设施，如果事后补救成本高昂，软件开发也需要规划和“基础设施工作”来确保长期稳定性。“在漏水屋顶下放水桶”的方法或许能提供暂时的快速修复，但它忽略了根本原因，最终会导致崩塌。 最终，团队不得不放弃狂乱的节奏，放慢速度，有条不紊地修复系统，从而制作出了可运行的演示版本。这段经历提醒我们，好的软件永远不会真正“完成”；它是一个活生生的结构，需要人们在其中居住的同时进行持续、用心的维护。
这篇 Hacker News 帖子探讨了向业务利益相关者解释软件开发工作时所面临的持续性难题。
核心主题包括：
* **软件永远没有“完成”之时：** 参与者认为，主要的挑战在于软件迭代的无限性，即使在初步部署之后，工作仍在持续进行。
* **人工智能与“氛围编程”的鸿沟：** 用户讨论了现代 AI 工具（如 Claude/Lovable）的影响。虽然 AI 可以快速生成原型（即“氛围编程”），但开发者指出，将这些原型转化为生产级系统需要复杂的、耗时的后端集成，而 AI 目前还无法完全实现自动化。
* **认知与现实的偏差：** 一个长期存在的观察结果是，业务领导者往往会误判项目的复杂性：他们认为“简单”的任务通常难度极高，而他们预期复杂的工作往往反而微不足道。
* **未来展望：** 一些贡献者认为，AI 工具将在几年内取得显著进步，可能缩小快速原型制作与生产部署之间的差距。然而，另一些人则认为，无论使用何种工具，根本的困境在于业界内部对软件工程本质的误解。