## RAG系统漏洞：知识库投毒 最近的实验表明，检索增强生成 (RAG) 系统存在一个显著的安全漏洞：**知识库投毒**。仅使用本地设置（MacBook Pro，无GPU/云），就向 ChromaDB 知识库注入了 *三* 份伪造的文件，成功地误导了 LLM (LM Studio + Qwen2.5)，使其报告了某公司的虚假财务数据。 攻击成功报告了 47% 的收入下降和重组计划，尽管实际数据表明该公司盈利。这并非软件漏洞或提示注入——仅仅是添加了具有误导性的信息。成功的关键在于制作既能在检索中获得高排名*又*能影响 LLM 生成的文档，这一概念被“PoisonedRAG”研究正式化。 虽然使用小型数据集可以轻松复现，但该原理可以扩展到更大的知识库。**在摄取时进行嵌入异常检测被证明是最有效的防御手段**，显著降低了成功率。其他防御措施，如清理和提示加固，提供的保护有限。 这种攻击危险在于其持久性、隐蔽性和低准入门槛。组织应映射所有写入知识库的路径，实施摄取时异常检测，并利用快照进行快速恢复。此漏洞强调了保护 *知识库本身* 的必要性，而不仅仅是 LLM。 **实验室代码及进一步研究：** [https://github.com/aminrj-labs/mcp-attack-labs/labs/04-rag-security](https://github.com/aminrj-labs/mcp-attack-labs/labs/04-rag-security)
每日HackerNews RSS
RAG 系统中的文档污染：攻击者如何破坏人工智能的信息来源
Document poisoning in RAG systems: How attackers corrupt AI's sources
13 分钟前
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
RAG 系统中的文档投毒：攻击者如何破坏 AI 的来源 (aminrj.com)
10 分，由 aminerj 发布 1 小时前 | 隐藏 | 过去 | 收藏 | 1 条评论 帮助
sidrag22 2 分钟前 [–]
> 门槛低。这种攻击需要对知识库的写入权限，这正是让我感到不安的地方。它需要一个拥有关键权限的恶意行为者，并且还需要最终的 RAG 输出不提供对所引用结果的参考。 似乎到那时就是一个有缺陷的产品了。 回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## TPU 与 GPU：深入探讨 Flash Attention
本文详细介绍了将为 GPU 开发的 Flash Attention 内核（在第 4 部分中）移植到 TPU 的尝试，揭示了令人惊讶的性能差异。虽然算法保持不变，但底层的硬件和编译器优化却极大地改变了结果。
最初移植到 JAX/TPU 的版本比融合的标准注意力实现要慢得多。这被追溯到 TPU 的架构：其矩阵乘法单元 (MXU) 专为平铺矩阵运算而设计，并且其大型片上存储器 (VMEM) 允许完整的注意力矩阵驻留在其中，用于较短的序列长度。最初的 JAX 实现，使用 `fori_loop`，阻碍了编译器优化并行性的能力。
切换到 `jax.vmap` – 信号查询块之间的独立性 – 释放了显著的性能提升，最终超越了融合的标准注意力，用于更长的序列。这突出了向编译器传达意图的重要性。关键要点是：TPU 硬件和 XLA 编译器通常会自动处理平铺和优化，使得手动干预变得不必要甚至有害。
进一步的研究表明，TPU 的收缩阵列设计本质上可以有效地执行平铺矩阵乘法。虽然通过 Pallas 进行自定义内核提供了细粒度的控制（DMA 流水线，显式内存放置），但对于许多用例，利用 XLA 的自动优化可以提供最佳性能。该项目强调，在 GPU 上有效的优化策略不一定对 TPU 有益，并且理解底层硬件对于编写高效代码至关重要。
这个Hacker News讨论围绕一篇博客文章，详细介绍了为Google的TPU优化“Flash Attention”的挑战。最初的文章强调了将代码适配到新硬件加速器上所涉及的大量工作——索引、分区和基准测试——这些工作通常已经由像Google这样的大公司为流行的操作完成。
一位评论员指出一个有趣的副作用：这篇博客文章*感觉*像是AI生成的。他们描述了过于冗长的句子、不一致的markdown格式（特别是过多的加粗）、以及突然出现表格，给读者造成了认知负担。评论员怀疑使用了LLM来撰写这篇文章，迫使他们不断评估内容，以区分实质内容和风格上的废话——这种干扰在技术写作中很少遇到。
本质上，这场讨论强调了硬件优化的技术障碍*以及*消费潜在由AI生成的内容所带来的微妙困难。
莉比·科普和她的男友雅各布·阿诺德，在TikTok和Instagram上发布了一段他们跑步时制作黄油的视频，迅速走红。这对来自俄勒冈州的夫妇将浓奶油和盐装入密封袋，固定在他们的跑步背心上，然后开始在小路上跑步，利用运动将奶油搅打成黄油。
这个想法源于科普对乳制品的热爱，以及阿诺德发现奶油在摇晃时很容易起泡。在确认了科学原理——剧烈搅拌可以分离脂肪分子形成黄油后，他们开始实验，最初使用了过多的奶油，甚至试图在河里冷却密封袋。他们后来改进了技术，发现50-55°F（约10-13°C）的温度最理想。
他们的视频获得了数百万次观看，并激励了其他人尝试“搅打跑步”，出现了各种变化，包括调味黄油，甚至在旅途中制作冰淇淋。科普强调，除了新奇之外，这次经历让她回忆起跑步的简单乐趣，她说：“只是为了氛围。只是为了黄油。”
一个黑客新闻的讨论围绕着《跑者世界》的一篇文章，讲述一位跑步时制作黄油的跑者。核心话题很快偏离到关于纯素主义的争论，评论者指出这个话题经常在无关的对话中出现。
一些用户质疑文章暗示对“真黄油”的渴望会让人放弃纯素生活方式，认为这不太可能。其他人讨论了制作黄油的原理——室温会加速过程，但过热会破坏它。关于未冷藏奶油的安全问题也被提出，并有人保证乳制品相对稳定。
对话进一步延伸到其他“跑步制作”食品的想法，比如冰淇淋，以及对这项活动具有刻板印象的“俄勒冈人”特征的玩笑观察（可能涉及斯巴鲁Outback）。
错误：无法满足请求。请求被阻止。我们目前无法连接到此应用程序或网站的服务器。可能流量过多或配置错误。稍后重试，或联系应用程序或网站所有者。如果您通过 CloudFront 向客户提供内容，可以在 CloudFront 文档中找到故障排除步骤，以帮助防止此错误。由 cloudfront (CloudFront) 生成。请求 ID：yz2YhgkpmFKDVypzqjGb2Vtk7LbD4ZXN94Na284hGDrn5s25iJ1bkQ==
## 人工智能与警方失误导致冤假错案
一位北达科他州的女性因银行诈骗案中存在缺陷的面部识别匹配而被错误监禁数月。尽管有证据与人工智能的识别结果相矛盾——包括银行记录显示她身在田纳西州，距离案发地1200英里——法戈警方仍继续调查此案，导致该女子失去房屋、汽车，甚至她的狗。
Hacker News上的讨论集中在问责制上。一些人认为该女子有充分理由起诉警方，甚至可能起诉其他组织，而另一些人则指出克服“合格豁免权”的挑战。许多人强调核心问题并非人工智能本身，而是警方对其的依赖以及随后的疏忽。
评论员们指出了一种人为错误因技术而加剧的模式，并质疑工具制造商是否也应承担责任。大家普遍认为，此类错误的代价不应由纳税人承担，并呼吁在使用人工智能进行执法时加强人工监督和验证。一些用户将此事与英国邮局丑闻相提并论，强调了盲目信任有缺陷系统的危险。
谷歌计划在2026年第二季度将Chrome浏览器带到ARM64 Linux设备上，此前已成功在macOS（2020年）和Windows（2024年）ARM平台上发布。此举旨在满足对功能齐全的浏览体验日益增长的需求，该体验将谷歌的服务与开源Chromium项目集成。 ARM64 Linux版本将提供与其他Chrome版本相同的安全性、稳定性以及丰富的功能，包括通过Google账户无缝同步、访问Chrome网上应用店扩展程序以及即时网页翻译。增强的安全功能，如带有AI保护的安全浏览、Google Pay集成以及Google密码管理器也包含在内。 谷歌正在与NVIDIA合作，简化DGX Spark用户的安装流程，其他用户可以直接从chrome.com/download下载。此发布标志着谷歌对Linux社区和不断扩展的Arm生态系统的承诺。
## Chrome 现在可在 ARM64 Linux 上使用
谷歌终于发布了 Chrome 在 Linux 上的官方 ARM64 版本，这是许多用户长期期待的发展。 之前，只有社区维护的 Chromium 构建或付费服务提供 ARM64 支持，很大程度上是因为谷歌缺乏官方构建。
此发布对于使用基于 ARM 的设备（如 Raspberry Pi 和 Linux 手机）的用户来说尤其令人兴奋，可能无需再使用像修补 glibc 来实现基本功能（如视频播放）这样的解决方法。 用户们希望能够开箱即用地实现硬件视频加速。
讨论强调了 Android 上的 Chrome（使用 Bionic libc）和通用 Linux 上的 Chrome 之间的区别。 此更新还解决了软件测试人员之前在浏览器自动化工具的 ARM64 兼容性方面遇到的痛点。 预计这将简化测试工作流程，并可能导致官方 “Chrome for Testing” 版本发布用于 ARM64 Linux。
NaN 很奇怪。
NaN Is Weird
1 小时前
最近在Python Discord的讨论中，发现`float('nan')`（非数字）存在一种奇怪的行为。令人惊讶的是，`nan`是可哈希的，允许将其添加到集合并用作字典的键。然而，`nan`甚至不等于自身（`nan == nan`的结果是`False`），这意味着每个`nan`实例都被认为是唯一的。 这导致了意想不到的结果：一个集合可以包含多个`nan`值，一个字典可以保存多个以`nan`作为键的条目——但使用`nan`本身检索值会引发`KeyError`。只有使用*特定*的`nan`实例（存储在变量中）才能访问字典。 即使计算可迭代对象中`nan`的出现次数也是不准确的，因为`Counter`将每个`nan`视为不同的值。虽然这在实际应用中没有用处，但这展示了Python处理`nan`值时一个有趣且违反直觉的特性。
## NaN：深入探讨“非数字”
一则Hacker News讨论围绕编程中“NaN”（非数字）的特殊行为。核心问题是：NaN *不* 等于自身，这是IEEE 754浮点标准的结果，而非特定语言的错误。
用户指出这会影响各种功能。C++的`std::sort`在遇到NaN时可能崩溃，而Python对NaN的哈希处理不保证一致性。这源于NaN代表一个无法表示或未定义的值——比较两个“未知”量无法产生明确的“相等”或“不相等”结果。
对话还涉及特定语言的怪癖。Python对除以零的处理（引发异常而不是返回NaN/无穷大）被批评为不一致。Rust通过区分相等性特征来解决这个问题，从而区分具有潜在非自等值的类型，例如NaN。最终，讨论强调NaN是计算机算术中一个基本且奇怪的方面。
这个Hacker News讨论围绕一张大型旧BBS（电子公告板系统）的照片展开，引发了怀旧和技术回忆。用户们回忆起想自己运行BBS的愿望，但常常受到父母反对，因为需要额外的电话线路费用。
对话深入探讨了这些系统的技术能力，挑战了每个电脑只能处理一个调制解调器的假设。许多人回忆起基于DOS的BBS软件，如MajorBBS和PCBoard，通过串行端口接口（如DigiBoard）支持多条线路。其他人讨论了早期的网络方法，包括同轴电缆（以太网或Arcnet），甚至串联的电话线路。
一个关键点是，从个人电脑时代*之前*常见的多用户系统，到个人电脑时代对个人使用的关注。讨论还涉及一些有趣的细节，比如旧CPU上的“turbo按钮”，实际上会*降低*它们的速度。还分享了一篇Rachel By The Bay的相关文章链接，其中引用强调了在购买另一台电脑之前，先掌握一台电脑。
由于提供的内容是PDF二进制数据流，其中包含大量非文本字符，无法直接翻译成可读的中文。它看起来像是图像或压缩数据的一部分，而不是人类可读的文本。
一篇最近发表在404media.co上的文章，在Hacker News上讨论，强调了为人工智能系统提供动力的劳动力，尤其关注非洲的工人。文章详细介绍了涉及“聊天审核”的工作，其中人们被雇佣来扮演角色并与用户进行长时间的对话，通常是在浪漫或性环境中，为人工智能“伴侣”或“性机器人”服务。
最初对人类参与人工智能性机器人是否有必要表示怀疑，但评论员澄清，许多商业机器人采用混合方法——将人工智能的回复与真实的互动相结合，以增强参与感和真实感。据报道，这种“集成方法”比完全由人工智能驱动的模型更受用户欢迎。
讨论还涉及这项工作的伦理问题，一些人批评这篇文章具有情感操纵性，而另一些人则指出“人工智能女友”广告的普遍性。最终，该讨论质疑“人工智能”的定义，以及它是否已成为一个营销术语，掩盖了其背后重大的贡献。
启用 JavaScript 和 Cookie 以继续。
## 白宫气候实验室重组引发争议
白宫一项重组国家大气研究中心（NCAR）的计划正在推进，引发了 Hacker News 的讨论。虽然官方将其定义为重组，但一些人认为此举具有政治动机，可能源于对科罗拉多州在 2020 年选举舞弊指控中定罪的前县书记的报复。
评论员们对公众可能失去获取关键气候科学的机会表示担忧，其中一人回忆起 NCAR 实地考察对其教育经历产生了深远影响。 还有人批评拜登政府的竞选策略，认为需要更强有力的经济信息。
争论迅速扩大，涉及对“法西斯主义”的指责以及通过放松管制使企业受益。一些人呼吁针对与共和党相关的机构，而另一些人则敦促人们远离分裂的“文化战争”言论。 讨论也偏离到与加密货币和 NASCAR 等无关的话题，凸显了政治话语的复杂性和两极分化性质。
过去一年，作者一直在努力使编码代理真正具有协作性，为此赋予它们对项目的深入理解——超越仅仅是文件内容。最初的尝试侧重于手动向代理提供上下文，虽然有效但不可持续。各种解决方案被尝试过——规则、提取的会话数据和“技能”——但都受到难以持续捕捉*决策时刻*上下文的困扰。 突破来自于意识到 Git 的提交历史已经*记录*了会话。缺失的部分是详细提交信息的规范，解释代码更改的*原因*，而不仅仅是*内容*。这促成了“上下文提交”，一种受 Conventional Commits 启发的规范，在提交信息中使用结构化的行为行来记录意图、决策和学习到的信息。 这种方法消除了对单独上下文跟踪系统的需求，利用了 Git 本身的扩展性和并发性。一个简单的“回忆”技能允许代理主动搜索这段历史以获取推理依据。作者已经将此作为标准开源，希望得到更广泛的应用，并有可能与编码工具进行原生集成，最终目标是实现“更好的提交”——以及更知情、更具协作性的编码体验。
Hacker News 上正在讨论“情境提交 (Contextual Commits)”，这是一个提议的开放标准，旨在向 Git 历史记录中添加“原因”信息，而不仅仅是详细说明“做了什么”的更改。创建者 vidimitrov 认为，当前的提交消息侧重于“做了什么”，对于需要理解意图的自动化工具（“代理”）来说用处不大。
用户们争论结构化标签（情境提交）是否比在提交正文中写好的散文更易读——许多人承认后一种做法很少被采用。有人指出，现有的、未充分利用的提交正文 *本身* 就是解释理由的地方。
该标准提出了一种键值对格式，类似于提交中现有的“拖车 (trailers)”或“页脚 (footers)”，旨在解锁查询历史数据并启用工具。一个关键要点是，该提议不需要新的工具，只需要改变提交的 *方式*。