跳到正文

2026年10月07日AI 版

7 条 · 6 个来源

头版

OpenAI 将默认对 ChatGPT 输出添加水印——但仅限于欧盟

行业动态Ars Technica AI

OpenAI 将默认对 ChatGPT 输出添加水印——但仅限于欧盟
欧盟用户先受水印约束,但易被绕过,防滥用作用有限。

欧盟的 ChatGPT 用户会最先被默认水印覆盖;真正要改决定的是把水印当证据用的那批人——审稿、平台审核和合规核验方,不能把 textGrain 的检出结果当成单一凭据,得配人工与其他来源交叉核对。

展开全文

依据

OpenAI 宣布欧盟境内 ChatGPT 输出默认带水印,其他地区默认可选、默认关闭,API 里同样默认关但可开;Ars Technica 的 Samuel Axon 把这归因于欧盟 AI Act(欧盟《人工智能法案》)对 AI 生成内容须可被工具检测的标记要求。OpenAI 的水印方法叫 textGrain(该公司自有的文本水印方法),机制是在用词选择里埋入人类读者看不出、也不明显损伤输出质量的模式,持密钥者用专用检测器才能找出,思路与已有的 SynthID、C2PA 这类内容标记标准相近。OpenAI 自己的测试显示:textGrain 检出成功率为 92 percent;改动 10 percent 文本,成功率下降 almost 30 percent;改动 20 percent 文本,下降 almost 75 percent;短文和译文的表现还更差。同一时期 Anthropic 的文本水印是全局启用,OpenAI 只在监管要求的地区设为默认。所以这是一条监管压力驱动的最低合规线,绕过成本极低,防滥用能力取决于对方是否老实。

  • textGrain 检出成功率92 percent
  • 改动 10 percent 文本后almost 30 percent
  • 改动 20 percent 文本后almost 75 percent
改动文本比例越大,textGrain 被检出的成功率掉得越快

没写清 材料没说欧盟监管方用哪种检测器、按什么频率核验,也没给 textGrain 检测器的审批名单,实际执法强度不能替它补上。

下一步 看 OpenAI 在欧盟上线后,是否公布 textGrain 检测器的开放申请入口,以及除 92 percent 之外的新检测数据。

行业动态

4 条

  1. 《Artificial》辛辣讽刺 AI 创造者——并对其危险发出黑暗警告

    行业动态Wired AI

    《Artificial》辛辣讽刺 AI 创造者——并对其危险发出黑暗警告
    把AI大佬当笑料拍,痛快归痛快,却回避了监管缺位的真问题。

    这改变的是投资人和科技记者对‘安全叙事’的默认判断:下次听到‘安全即透明’,先问谁有权踩刹车,而不是只笑Sam Altman走路。

    展开全文

    依据

    WIRED的John Semley写的是纽约电影节首映后的《Artificial》:导演Luca Guadagnino说片子拍的是“the desire to prevail”(求胜欲),演员Ike Barinholtz把自己的Elon Musk角色调侃成“a person who walks normally”。机制在片内片外一致:OpenAI的Ilya Sutskever角色求safeguards(安全防护)、slow-downs(减速)和alignment(对齐,即让AI目标与人类利益一致),而其他几乎所有人把指数增长当默认;前Anthropic员工Jacob Coxon对WIRED说同事把接下来几年称作人类的“endgame”(终局),另一位Anthropic研究员说within a decade AI可能“kill all humans”,赔率设在below 10 percent。AmazonMGM在Amazon与OpenAI达成$50 billion deal后放弃发行该片,Neon接手——安全担忧被当成卖点,发行风险也被算进交易。

    没写清 材料没写OpenAI或AmazonMGM是否回应过《Artificial》的发行争议,也没写任何监管机构是否就片中的安全担忧采取行动。

    下一步 查Neon是否公布《Artificial》的正式上映日期和影院范围。

  2. OpenAI 又惹怒了一群数学家

    行业动态Wired AI

    OpenAI 又惹怒了一群数学家
    OpenAI再惹数学家:未解难题若被当成果发布,学术优先权恐成代价。

    OpenAI若周二把100多个未解问题的解答一次性丢上GitHub,手里握着未发表手稿的数学家就得先决定:是先挂预印本钉住时间戳,还是等它公布后再去争署名。

    展开全文

    依据

    西北大学数学家Bryna Kra说,8月约40名与会者要求OpenAI不要像当月早些时候公布10个问题那样只发博客或推文,而应出论文,让同行能吸收、消化、使用;她称这一意见「显然被忽视了」。OpenAI发言人Lindsay McCallum回应称公司正「负责任地发布」下一批结果,并参考高等研究院数学与AI咨询小组的建议,且未设定发布时间。机制在于:优先权(priority,即谁先证明某命题的学术认定)靠可引用、可核查的论文与时间戳确立;博客和推文既难验证,也常略去他人先前工作。9月的先例是,纽约大学教授Tristan Buckmaster称OpenAI抢先发布了他与Anthropic员工Levent Alpöge未发表的成果,OpenAI研究员Sébastien Bubeck据会议记录否认自己要求把Alpöge排除在作者之外。

    • 出席8月会议的数学家约40名
    • OpenAI称已解决的长期未解问题100多个
    • 8月早些时候经博客推文公布的题目10个
    • Alpöge称已推翻的猜想历史87年
    材料里出现的几组可对照数字

    没写清 材料没说这批100多个结果里哪些与未发表手稿重叠,也没说Buckmaster与Alpöge的署名协商最后怎么收场。

    下一步 周二查OpenAI的GitHub仓库是否上线,以及每条结果是否附论文和前置工作引用。

  3. 行业动态Simon Willison

    使用 Parseable 配合 Datasette 处理 OpenTelemetry traces
    Simon Willison 用开源工具串起链路追踪,但只适合自搭栈的团队。

    自建栈的小团队现在可以把 Datasette 的链路追踪直接倒进 Parseable 的单个二进制,不必先签商业 APM 合同;代价是存储、查询和升级都归自己管。

    展开全文

    依据

    Simon Willison 在 10 月 6 日的 TIL 里写:他先用 Codex(OpenAI 的编码代理)摸清怎么把 Parseable 跑起来,再让 Datasette 把 trace 喂进去。机制是两端的标准对齐——Datasette 1.0a41 由 Alex Garcia 贡献加入了 OpenTelemetry 支持,OpenTelemetry 是一套跨语言的遥测采集标准,trace 指一次请求穿过各环节的链路记录;Parseable 兼容这套标准,负责存储与查询。Parseable 是他当天在 Show HN 看到的,开源版为 AGPL 的 Rust 实现,单个二进制约 180MB,另有企业版和云托管。截图里 Datasette 的 trace 显示在 Parseable 的 localhost 页面中。

    1. Datasette 发出 trace
      接入
    2. Codex 搭起 Parseable
      写入
    3. Parseable 存储与查询
      展示
    4. localhost 页面查看
    从 Datasette 发出 trace 到在 Parseable 本地页面查看的搭建链路。

    没写清 材料没给 trace 量、延迟或存储成本数字,也没有 Parseable 与既有方案在同等负载下的对照,撑不撑得住生产流量无法从这篇 TIL 推出。

    下一步 看 Parseable 开源仓库是否给出脱离 localhost 的持久化与多副本部署文档,还是只停在单机演示。

  4. 行业动态OpenAI

    Atlassian 与 OpenAI 扩大合作,将企业知识转化为行动
    Atlassian与OpenAI打通企业知识,落地效率提升,但数据治理仍得自己扛

    这条消息改变的是已经同时采购 Atlassian 与 OpenAI 的企业 IT 负责人的决定:把知识库接进模型,从「自己立项做集成」改成「等两家官方连接上线」,预算和排期随之往后压。

    展开全文

    依据

    谁说了什么:OpenAI 在自家渠道发布公告,标题为「Atlassian and OpenAI expand partnership to turn enterprise knowledge into action」,正文只说双方扩大合作,把 frontier models(前沿模型,即能力最强的那一档大模型)与企业知识连起来,帮助团队 plan、build、deliver 工作。材料里没有给出任何可对照数字,也没说接的是哪个模型、覆盖 Jira 还是 Confluence、走什么权限体系。机制上能确定的是:知识在 Atlassian 侧,模型在 OpenAI 侧,一次调用要两边同时放行,权限映射与数据边界的责任因此落在客户身上,这也是策展点评说数据治理仍得自己扛的原因。

    没写清 材料没说这次打通具体覆盖哪些产品、走哪套权限与审计接口,所以无法替它判断哪些数据会离开企业边界。

    下一步 下一步可核对两家后续公布的集成产品清单与权限模型说明,看是否点名 Jira、Confluence。

AI工具

1 条

  1. AI工具AWS Machine Learning Blog

    在 AgentCore 和 OpenClaw 上构建上下文感知的 AI 助手
    自建助手能跨会话累积记忆,但得先接受AgentCore的绑定与运维开销。

    这篇材料把自建助手的决策点从「要不要做记忆」挪到「记忆托管给谁」:选 OpenClaw 加 AgentCore memory 可以不自建存储层,但运行时和记忆库一并落在 AWS 侧,日后换供应商的迁移成本得自己扛。

    展开全文

    依据

    AWS 的 Thiago Verney、Akarsha Sehwag 和 Sathya Balakrishnan 在 10月6日的博文里说,现成助手答单个问题没问题,缺的是连续性:一个无状态助手不记得你三周前提过的排水快的抬高花床、只用有机肥、矮牵牛在热浪里打蔫,每次对话都从零开始,重新解释上下文的负担压在用户身上。他们给的机制是:OpenClaw(一个开源 agentic 系统,即能自行调用工具、分步完成任务的智能体框架)跑在 AgentCore runtime(Amazon Bedrock AgentCore 的运行环境)上,由 AgentCore memory 把一次性对话沉淀成可长期保留的知识,再给记忆打上结构化元数据,按当前问题取回相关记录。示例助手 Sprout 是园艺场景,但作者说这套架构与领域无关。

    1. OpenClaw 智能体
      部署于
    2. AgentCore 运行环境
      写入
    3. AgentCore 记忆
      打标取回
    4. 结构化元数据取回
    博文给出的链路:OpenClaw 跑在 AgentCore 上,记忆与元数据检索接在其后

    没写清 博文没有给出记忆取回的准确率、延迟或费用数字,也没说 OpenClaw 与 AgentCore memory 的耦合有多深、换掉记忆后端要改多少代码。

    下一步 看这篇博文的示例代码仓库是否放出 Sprout 的完整配置,重点数记忆写入与检索那部分有多少调用是 AgentCore 专有接口。

精选深读

1 条

  1. 精选深读Google DeepMind

    EmbeddingGemma 2:一个开放、轻量的多模态嵌入模型
    EmbeddingGemma 2主打端侧开放轻量,多模态检索精度需实测。

    端侧 RAG 和本地搜索的开发者要重新决定:是否把多模态检索从服务端向量库迁到本地推理的 EmbeddingGemma 2,还是继续为图像、音频单独维护编码器。

    展开全文

    依据

    Google DeepMind 研究工程师 Sahil Dua 与 Henrique Schechter Vera 在 10月6日 的发布文中称,EmbeddingGemma 2 是其尺寸段内最强的端侧多模态嵌入模型。机制上它把文本、图像、音频、视频映射进同一嵌入空间:文本权重最低 270M 参数,视觉编码器 170M、音频编码器 300M 可选加载,纯文本场景因此不必付多模态的内存代价。存储侧用 MRL(Matryoshka Representation Learning,套娃式表示学习)把输出向量从 768 维截断到 512、256 或 128 维,官方称最高带来 6x 存储缩减。量化后在 Google Pixel 11 Pro 上,纯文本权重约 191MB 活跃内存,全模态约 567MB。上一代 EmbeddingGemma 的下载量超过 20 million。

    • 参数总量740 million
    • 文本权重活跃内存~191MB
    • 全模态活跃内存~567MB
    • 上一代下载量20 million
    EmbeddingGemma 2 的模型规模、端侧内存与上一代下载量对照

    没写清 材料只写 EmbeddingGemma 2 在 MTEB Code 与 MAEB 上取得领先分数,没给出具体分数和对照模型,所以无法判断多模态检索精度实际高出多少。

    下一步 核对官方模型卡里 MTEB Code 与 MAEB 的具体分数、参数量级和评测条件。