Levix 空间站
922 subscribers
219 photos
11 videos
20 files
1.38K links
主要分享前端、AI 以及前沿科技资讯。

🚫 禁止人身攻击:请在评论区保持尊重和友好,避免不当言论和负面互动。

🚫 禁止违规内容:请勿发布任何黄赌毒、宗教极端、政治敏感或其他违反社区规定的内容。
主要分享前端以及业界科技资讯。

🚫 禁止广告与刷屏:为了维护良好的交流环境,请不要进行任何形式的广告推广、黑产活动、刷屏行为及发布不适内容。

🔒 保护个人信息:请注意个人隐私和网络安全,不要在评论区泄露个人信息或点击不明链接。
Download Telegram
Forwarded from AI探索指南
我用2万条真人AI海龟汤游戏数据,评估大模型推理能力哪家强

最近半个月,我一直在秘密做的一个东西,今天终于公之于众了!

这是一个诡异的脑洞:能否用AI游戏来评测大模型的推理能力?为此,我标注了2万条数据,在GPT-4o, Claude,月之暗面,豆包, DeepSeek, MiniMax, 通义千问等11个模型上进行了评测,最终有了答案,文章最后有结果👀
抓取技术已然成为不可逆转的趋势,无论我们是否愿意接受。如今,内容提供商正纷纷设置障碍以限制访问,仅对那些有能力购买内容授权的用户敞开大门。这严重限制了每个人LLM可学习资源的范围,与此同时,小型企业因高昂成本被排除在争夺高价值内容的竞争之外,而剩余的利益则被科技巨头LLMs瓜分。这就像是后 Netflix 时代的流媒体世界重演,只不过这次争夺的是知识资源。

随着可用的人工生成数据日渐减少,AI 生成的“糟粕”却在激增。基于此类数据训练模型可能导致改进速度放缓,甚至引发模型崩溃。解决之道唯有跳出常规思维——而这正是初创企业因其创新与颠覆的文化所擅长的领域。然而,那些仅授权给行业巨头的数据,恰恰是这些初创企业赖以生存的命脉所在。

通过限制对数据的公平访问,这些巨头企业不仅扼杀了竞争,更是在扼杀人工智能本身的未来,遏制了那股可能推动我们超越这个潜在数字黑暗时代的创新力量。

人工智能革命并非遥远的未来,AI 已然降临。正如威廉·吉布森所言:“未来已至,只是分布不均。([T]he future is already here, it’s just not evenly distributed.)”。它很容易变得更加分布不均。

#AI #思考

https://jina.ai/news/by-hoovering-up-the-web-ai-is-poisoning-itself/
《Reckoning: Part 2 — Object Lesson》深入分析了加州政府的 SNAP 福利申请平台 BenefitsCal 在用户体验和性能上的问题。与 Code for America 开发的 [getcalfresh.org](http://getcalfresh.org/) 相比,BenefitsCal 存在加载缓慢、JavaScript 使用过度以及对性能优化的忽视。尽管投资巨大,BenefitsCal 的实际体验远不如 [getcalfresh.org](http://getcalfresh.org/),后者以更简洁、快速的方式提供服务,占据了加州福利注册的近一半。

BenefitsCal 的性能问题主要源于其对大量 JavaScript 的依赖,这不仅增加了页面加载时间,还可能导致低端设备上的标签页崩溃。文章指出,该平台未启用 gzip 压缩,导致用户在访问时需要下载的数据量巨大。此外,BenefitsCal 的缓存策略执行不力,重复访问时仍需加载大量数据,这与现代 HTTP 服务器的标准相去甚远。

架构上,BenefitsCal 采用的单页应用(SPA)架构使得用户在数据完全下载和运行前无法使用任何功能,这与 [getcalfresh.org](http://getcalfresh.org/) 采用的渐进增强 HTML 优先方法形成对比,后者能够更快地提供可交互的内容。文章通过比较其他州的类似服务,如 Wisconsin 的 ACCESS 系统,强调即使是在网络和设备条件不佳的情况下,通过采用渐进增强的方式,也能提供可接受的用户体验。

英国政府数字服务(GDS)的成功经验被用来对比加州的做法。GDS 的 Service Manual 和 Service Standard 提供了政府服务构建和交付的指南,强调了渐进增强的重要性,并避免了大型合同的弊端。然而,BenefitsCal 的失败并未引起对采购流程的反思,资金仍在不断流向主要承包商。

文章还批评了基于 JavaScript 前端开发导致的不平等效应,尤其是在公共部门对 JavaScript 框架的过度依赖。通过分析马萨诸塞州、马里兰州、田纳西州和新泽西州的公共福利平台,文章揭示了 JavaScript 的不当使用和服务器配置错误导致的性能问题。

最后,作者建议公共部门应避免使用复杂的 JavaScript 框架,转而采用更简洁的架构来改善用户体验。文章强调,在边缘情况下追求卓越体验的重要性,并提出公共部门需要学习如何选择合适的架构以优雅地降级服务,确保所有用户都能获得良好的服务体验。

#JavaScript #思考 #性能

https://infrequently.org/2024/08/object-lesson/
GitHub 推出了 Copilot Autofix,这是一个 AI 驱动的代码修复工具,旨在帮助开发者和安全团队快速修复代码中的安全漏洞,同时防止新的漏洞产生。开发者经常面临安全要求难以理解和实施的问题,而 Copilot Autofix 通过分析漏洞、解释其重要性,并提供代码建议,显著提高了修复效率。

#Github #Copilot #AI

https://github.blog/news-insights/product-news/secure-code-more-than-three-times-faster-with-copilot-autofix/
ALIEN 是一个基于 CUDA 的人工生命模拟程序,它利用专门的 2D 粒子引擎来模拟软体和流体。这个程序由 Christian Heinemann 主导开发和维护,旨在通过模拟来探索生物进化的条件和生物系统复杂性的增长。

#Github

https://github.com/chrxh/alien
Forwarded from 科技圈🎗在花频道📮
AI马斯克骗走82岁老人近500万积蓄

近日,外媒曝光了一种全新的数字诈骗,诈骗犯利用复杂的AI工具制作特斯拉CEO马斯克等名人的视频,并利用这些“AI名人”对各种虚假的产品或“投资”进行背书,并承诺高额投资回报。

在其中一个典型案例中,“AI马斯克”背书的一家所谓的外汇公司轻松骗走了一名82岁的退休老人超过69万美元(约495万元人民币)的毕生积蓄。

在这类骗局中,诈骗犯通常先寻找一个真实的采访马斯克的视频,再使用AI工具将他的声音替换,并利用口型同步技术编辑马斯克的口型,让视频看起来更加真实。对于普通人来说,这种以假乱真的视频可能是非常难以辨别的。

新浪科技

☘️ 关注频道 @ZaiHuaPd
📮 投稿爆料 @ZaiHuabot
#图一乐

可以下载了
欧洲联盟(EU)正式实施了全球首个全面的人工智能法规——人工智能法案(AI Act)。确保人工智能(AI)的安全和可信发展,优先保护人们的利益而非公司利益,平衡 AI 带来的潜在好处和新技术风险。

风险分类:

最低风险或无风险 AI:如垃圾邮件过滤器、AI 视频游戏、推荐系统,可无需额外义务运行。

有限风险 AI:涉及信息透明度问题,如AI生成文本、聊天机器人、深度伪造视频等,需明确标识 AI 生成内容。

高风险 AI:涉及更复杂的应用和系统,如远程生物识别、关键基础设施管理等,需满足严格要求,包括风险缓解系统、高质量数据集、详细文档等。

不可接受风险 AI:明确禁止对基本人权构成威胁的 AI 系统,如工作场所情绪识别、鼓励儿童危险行为的玩具等。

#AI

https://alvaromontoro.com/blog/68057/ai-act-is-here
"Bug Squash"面试:一种被低估的软件工程面试方法

1. 日常开发的真实反映:这种面试方式模拟了软件开发中的常见任务,即在不熟悉的代码库中寻找并修复错误。

2. 趣味性:与密室逃脱类似,解决错误带来的成就感和乐趣是软件工程中最受欢迎的部分之一。

3. 自我评估的便利性:候选人可以清晰地自我评估进度,这种透明度提供了比传统面试更好的体验。

4. 适用于快速增长的公司:在员工平均任期较短的公司中,处理不熟悉的代码是常态。

5. 展现经验候选人的优势:熟练使用调试工具的候选人可以通过这种方式展现他们的技能。

6. 区分作弊与调试技巧:即使事先知道错误,也需要展示可重复和科学的调试方法。

7. 重视代码阅读与理解:与编写新代码相比,阅读和理解现有代码在开发中占据了相当的时间。

8. 无需特别准备:这种面试测试的是候选人在其整个职业生涯中每天都在练习的技能。

挑战与限制:

1. 面试题目的编写:需要精心设计难度适中的错误,这需要校准测试。

2. 多语言支持:需要为不同的编程语言准备面试题目,以避免因不熟悉工具而影响候选人表现。

3. 跨平台兼容性:项目需要在不同操作系统上都能顺利构建和测试。

4. 构建和测试的简便性:考虑到候选人可能使用的是老旧的设备,项目需要易于构建和测试。

5. 持续维护:随着语言和依赖项的更新,面试项目需要定期维护以避免过时。

6. 依赖安装:候选人需要能够在自己的设备上安装项目依赖。

结论:

尽管存在挑战,"Bug Squash"面试是一种有趣且能测试日常软件工程中常见技能的有效方式。它应作为面试流程的一部分,与其他类型的面试一起使用,以全面评估候选人的能力。

个人感觉上来就是 2 道 Leetcode 中等算法题目这种就应该被淘汰,更多应该基于实际的业务出发来出一些题目😂

#面试

https://blog.jez.io/bugsquash/
Google AI Edge 的 MediaPipe 框架通过重新设计模型加载代码,成功在浏览器中运行了超过 7B 参数的大型语言模型(LLMs)。

#Google #AI #LLM

https://research.google/blog/unlocking-7b-language-models-in-your-browser-a-deep-dive-with-google-ai-edges-mediapipe/
Speculative RAG 是一种新颖的检索增强型生成框架,它利用较小的专家型语言模型(LM)生成草稿文本,然后由较大的通用型语言模型进行验证和选择最佳草稿。这种框架在准确性和效率方面都达到了最先进的水平。

大型语言模型(LLMs)在响应用户查询的服务中越来越普遍,但它们在处理需要最新信息或鲜为人知的事实的知识密集型问题时,常常会出现事实错误或生成无法通过给定输入验证的幻觉内容。例如,当用户询问最新 Google Pixel 手机的新功能时,LLM 可能会生成过时或不准确的信息。

检索增强型生成(RAG)作为一种解决方案,通过检索与信息相关的文档并将其整合到生成内容中,有效减少了知识密集任务中的事实错误。然而,处理长文档需要更复杂的推理,并且可能会显著延迟响应时间。因此,在 RAG 中平衡效率和效果已成为研究的重点。

Speculative RAG 框架通过将计算负担转移到专家型 RAG 草案生成器上,该生成器是针对 RAG 进行微调的小型语言模型,作为现有通用型 LM 的高效且健壮的 RAG 模块。它遵循推测性解码中描述的草案方法,通过使用较小的模型并行快速生成多个后续标记(例如,单词或词段),并与基础模型并行验证,以提高RAG系统的效率和效果。

实验结果显示,Speculative RAG 在 TriviaQA、MuSiQue、PubHealth 和 ARC-Challenge 基准测试中,与标准 RAG 系统相比,在准确性和延迟方面都有显著提升。例如,在 PubHealth 数据集上,Speculative RAG 比最佳基线 Mixtral-Instruct-8x7B 提高了 12.97%。

Speculative RAG 通过将 RAG 任务分解为草案和验证两个独立步骤,将起草的重任委托给小型专家型 RAG 起草生成器,而验证则使用大型通用型 LM 完成。从不同的文档子集并行生成多个草稿,提供了高质量的答案候选,从而在最终输出生成的质量和速度上都有了显著提升。

#AI #Google #GenAI

https://research.google/blog/speculative-rag-enhancing-retrieval-augmented-generation-through-drafting/
恶意广告(malvertising)是一种网络犯罪形式,它通过数字广告传播恶意软件。近年来,这种攻击手段已经演变成一种特别针对开源软件的新型威胁。根据 OpenLogic 的报告,越来越多的企业增加了对开源软件的使用,这为恶意广告提供了肥沃的土壤。

用户在搜索开源软件下载时,可能会无意中点击了伪装成合法链接的广告,从而下载了恶意软件。例如,攻击者可能会购买 Google 广告位,使用类似官方的网址(typosquatted URL)和网页设计来误导用户下载如 Vidar Stealer 这类信息窃取软件。

恶意广告对企业安全的威胁不仅能够窃取个人信息,还能够通过社会工程学手段获取企业登录凭证,进而访问企业系统。此外,恶意广告往往能够绕过传统的检测方法,因为它们通过增大文件大小来规避自动扫描,而且用户通常不会对大文件产生怀疑。

为了应对这一威胁,提出了几点建议,包括创建恶意顶级域名(TLDs)的阻止列表、实施应用程序白名单流程、更新终端用户安全培训,以及使用 1Password Extended Access Management 等工具来检查设备安全性。

#安全

https://blog.1password.com/malvertising-on-google-ads/
JavaScript 日期处理即将迎来重大改进,其中最引人注目的是 Temporal 提案。该提案通过 FullCalendar 团队提供的 polyfill 已经可以提前使用。Temporal API 的一大优势是引入了原生的 "带时区的日期时间(Zoned Date Time)" 对象。

在人类交流中,日期通常不包含时区信息,例如 "2024年8月4日上午10:30"。但计算机处理 JavaScript 的 Date 对象时,实际上是处理纯数字,这导致日期的原始语义丢失。JavaScript 中的日期实际上是 POSIX 时间(忽略闰秒),而非 UTC 时间。

Temporal API 引入了 Temporal.ZonedDateTime 对象,专门用于表示带有对应时区的日期和时间。例如,一个时间戳可以对应多个人类可读的日期,这取决于时区。例如,同一个时间戳在澳大利亚、马德里和美国可能对应不同的当地时间。

Temporal API 的优势

1. 创建日期:Temporal API 在创建日期时可以轻松处理时区,包括夏令时(DST)的棘手情况。

2. 日期比较:ZonedDateTime 提供了静态方法 compare,可以比较两个日期。

3. 内置属性:如 hoursInDay 属性,可以返回特定时区中一天的实际小时数。

4. 时区转换:通过 .withTimeZone 方法轻松改变 ZonedDateTime 的时区。

5. 日期运算:支持日历算术或简单持续时间的加减,自动调整夏令时。

#JavaScript #ECMAScript #新特性 #Date

https://docs.timetime.in/blog/js-dates-finally-fixed/
这个 Cobalt 工具很极简不错,可以下载绝大多数社交媒体的视频和音频,比如说 Twitter、Youtube、YoutubeMusic 上面的视频啥的,直接输入对应地址,点击直接下载,没有广告没有数据跟踪。

来源:潮流周刊

#Tools

https://cobalt.tools/
在现代工作文化的忙碌喧嚣中,我们很容易陷入全天候的工作模式。我们常常逼迫自己到极限,却忘记了需要适时退后一步,充电以发挥最佳状态。就像一块电量岌岌可危的电池,等到彻底耗尽可能为时已晚。休息并非软弱的表现,而是长期耐力与成功的策略。

1. 定期休息。每隔一两个周末就给自己充充电。

2. 时不时地远离数码设备,进行一次数字排毒。

3. 找到适合你的休息方式和充电活动。我的是亲近自然和旅行。

4. 将你的职业生涯视为一场马拉松,而非短跑冲刺。

5. 将个人与工作里程碑的完成与休息时间对齐,以享受双重益处。

6. 定期休息有助于保持耐力、提高生产力、保持头脑清晰并预防过度疲劳。

#思考

https://thetshaped.dev/p/importance-taking-breaks-recharge-batteries
10 种方法来更好地组织和设计 React 应用程序,以提高代码的可维护性和可扩展性。

其中第 6 点个人不是很认同,在一个庞大的项目过渡使用绝对路径的话会导致各个业务模块之间耦合严重、互相引用等问题(不同版本间的开发人员能力问题),完全靠人来遵守,如果想单独重构某个模块将会变得非常痛苦。🤣

1. 按领域责任分组组件:避免仅按技术角色分组,而应按页面或模块的领域责任组织文件和文件夹。

2. 将组件放入文件夹:对于复杂组件,应将其子组件组织到单独的文件夹中。

3. 使用绝对路径:使用绝对路径可以简化项目导航和维护,特别是在项目规模扩大时。

4. 使用公共模块:避免在项目中不同位置散布通用工具和组件,应集中存储以提高管理和重用性。

5. 抽象外部库和模块:通过自定义组件包装第三方库或模块,以保持应用内一致的 API 并简化未来的替换工作。

6. 管理模块/页面间的依赖关系:集中常用资源到共享的公共模块中,减少代码重复,明确模块和页面的依赖。

7. 保持代码靠近使用地点(LoB):根据行为局部性原则,将代码组织得更接近其在应用中的使用位置,以提高可
读性和可维护性。

8. 小心使用工具函数:工具函数应保持纯净和特定目的,避免与业务逻辑混合,以提高可重用性。

9. 小心处理业务逻辑:避免将业务逻辑直接集成到 UI 组件中,应使用自定义钩子将业务逻辑与 UI 分离。

10. 固定依赖版本:在 package.json 中指定确切的依赖版本,而不是使用版本范围,以确保项目中使用的是完全相同的包版本。

#React

https://thetshaped.dev/p/10-ways-organize-and-design-react-application
重构是软件开发中不可或缺的一环,但实施时需审慎考量,尊重现有代码库及团队协作动态。重构的目标在于优化代码内部结构,同时保持其外部行为不变。最佳的重构往往对终端用户是不可见的,但却能显著简化开发人员的工作。它们在不破坏系统整体性的前提下,提升了代码的可读性、可维护性和效率。

#重构

https://levix.notion.site/Good-Refactoring-vs-Bad-Refactoring-841cfa6ab14441b4a9f00e8fc314a905