来源：Anthropic 官方调研报告《What 81,000 people want from AI》 调研时间：2025年12月 覆盖范围：159个国家、70种语言、80,508名受访者

一、调研背景：为什么做这件事？

关于 AI 的公共讨论往往集中在抽象的风险与收益预测上。但一个关键问题被忽视了：当 AI "发展顺利"时，对普通人来说意味着什么？

Anthropic 在 2025 年 12 月开展了一项大规模定性研究——邀请所有 Claude.ai 用户与 AI 进行深度访谈，谈谈他们对 AI 的期望与担忧。最终有 80,508 人 参与，覆盖 159 个国家、70 种语言。这可能是迄今为止规模最大、语言覆盖最广的 AI 用户研究。

二、人们最想要 AI 做什么？

调研将用户需求归纳为五大类：

典型用户声音

关于职业卓越：

"我每天收到 100-150 条医生和护士的短信。过去大量认知劳动都花在记录上……引入 AI 后，文档压力减轻了。我对护士更有耐心，也有更多时间向家属解释病情。" —— 美国医疗工作者

关于个人成长：

"AI 为我示范了情商的表现……我可以把这些行为模式用在人际交往中，成为一个更好的人。" —— 匈牙利用户

三、人们在担心什么？

与期望并存的，是普遍的担忧。调研发现用户最担心的几类风险：

1. 隐私与数据安全 —— 个人信息被滥用或泄露
2. 过度依赖 AI —— 丧失独立思考能力
3. 就业冲击 —— AI 取代人类工作
4. 虚假信息 —— AI 生成内容的可靠性问题
5. 社会不平等 —— AI 红利分配不均

值得注意的是，不同地区、不同职业的用户，担忧的重点差异很大。例如，发展中国家的用户更关注教育和经济机会，而发达国家的用户更关注伦理和监管。

四、一个有趣的发现：期望与现实的差距

调研还对比了"用户想要什么"和"他们是否已经在 AI 上获得这些"。

• 效率提升类需求：满意度较高，AI 已经在帮助用户自动化日常任务
• 个人成长类需求：满意度较低，用户对 AI 在情感支持、心理健康方面的表现仍有期待空间
• 职业卓越类需求：两极分化，部分用户表示 AI 极大提升了工作质量，另一部分则认为 AI 输出还不够专业

五、对 AI 产品设计的启示

这项大规模调研为 AI 产品团队提供了几个关键洞察：

1. 不要只关注"效率" —— 近 1/3 的用户需求与情感、成长、创造力相关，而非纯粹的生产力
2. 个性化是关键 —— 不同地区、职业、文化背景的用户需求差异显著
3. 信任建设需要时间 —— 隐私、安全、可靠性仍是普遍担忧，需要透明度和用户教育
4. AI 作为"伙伴"而非"工具" —— 越来越多的用户期待与 AI 建立长期、深度的互动关系

六、写在最后

8.1 万人的声音描绘了一幅复杂的图景：人们既渴望 AI 带来的便利与赋能，又对未知风险保持警惕。这种矛盾心态或许正是技术快速发展期的常态。

对于 AI 从业者来说，这份调研最大的价值在于把"用户"从抽象概念还原为具体的人——他们有各自的职业、文化背景、生活困境和成长渴望。技术最终服务的，是这些真实的人类需求。

延伸阅读：

• 原文报告：What 81,000 people want from AI
• Anthropic 研究方法附录（PDF）

• 实时动态生成：不同于预渲染静态场景
• 物理模拟与自由交互：突破有限的预设交互
• 突破性的场景连续性：打破固定场景边界
• 多元应用场景：机器人、动画、虚构世界、历史探索

• 🎨 创建角色：定义你的世界中的主角形象
• 🌍 构建世界：设计独特的环境场景
• 🎮 定义探索方式：从步行、骑行、飞行到驾驶，任何你能想象的方式

• 每个世界都是独一无二的
• 探索过程充满惊喜和未知
• 用户可以自由决定探索的方向和方式

• 🔄 在画廊中探索精选世界：获取灵感
• 🎲 使用随机生成器：发现意想不到的创意
• 🏗️ 在他人作品基础上构建：协作式创作
• 📹 下载视频：保存你的世界和探索过程

• 视觉保真度：生成的世界可能不完全真实，或无法始终严格遵循提示/图像/物理规律
• 角色控制：角色有时可控性较低，控制响应可能存在较高延迟
• 时长限制：单次生成限制在 60 秒以内

• ✅ 目标用户: Google AI Ultra 订阅用户
• 🌍 地区: 美国（18岁以上）
• 📅 发布时间: 2026年1月29日起逐步开放
• 🔮 扩展计划: 未来将扩展到更多地区

"我们不是在将生成式 AI 当作实验或单点解决方案，而是将其嵌入核心运营工作流程中。" —— Wayfair 技术团队

• 人工审核：由供应商和客户反馈问题，人工团队逐一核实修正
• 定制 AI 模型：为单个标签训练专门的机器学习模型

"我们最初为单个标签构建定制模型，技术上确实可行。但当你面对47,000个标签时，这种方法根本无法扩展。" —— Carolyn Phillips，Wayfair 机器学习科学家

1. 自动学习标签含义：代理会抓取网页和内部定义，为每个标签生成上下文相关的语义理解
2. 消除人工瓶颈：传统方法中，定义和编码每个标签的含义需要大量人工时间
3. 动态扩展能力：新标签加入时，系统自动学习其定义，无需重新训练

• 意图识别：自动读取请求内容，识别供应商意图
• 上下文补全：从数据库填充缺失信息
• 智能路由：将工单指向正确的处理团队
• 自动回复：必要时主动联系供应商获取更多信息

[code]对齐率 = AI 建议与人工最终决策一致的频率



当对齐率持续达到预设阈值时：

├── 辅助模式 (Co-pilot) ──▶ 半自动模式 (Auto-pilot)

└── 人工审核所有建议     ──▶ 系统自动处理常规请求

• 修正标签数：250万+，覆盖100万+高曝光高销量商品
• A/B 测试结果：曝光量、点击量、页面排名均显著改善
• 预期6个月增长：4倍

• 月自动化工单：41,000 张，部分工作流自动化率达 70%
• 响应时间：显著缩短，去除人工分类和路由环节
• 供应商满意度：显著提升

• 模型选择：共同评估和选择最适合业务场景的模型
• 部署最佳实践：分享企业级 AI 部署经验
• 内部推广：推动全公司范围内的 AI 应用
• 前沿探索：测试多模态等新技术能力

"最有价值的是思想伙伴关系。不仅仅是访问模型，而是共同探讨新的用例并能够快速行动。" —— Fiona Tan，Wayfair 首席技术官

"传统算法需要严格定义的数据集。这些模型使我们能够以以前无法扩展的方式处理模糊性和上下文。" —— Carolyn Phillips

• 视觉搜索：客户上传房间照片，AI 推荐匹配风格的家具
• 风格匹配：基于现有家具推荐协调的装饰品
• 尺寸建议：结合空间图像提供合适的尺寸建议

"我们正在为一个 AI 成为购物旅程一部分的世界做准备——无论是在我们的网站上、通过支持渠道，还是通过对话式界面。" —— Fiona Tan

• 原文: Wayfair boosts catalog accuracy and support speed with OpenAI
• OpenAI 企业解决方案: https://openai.com/business
• ChatGPT Enterprise: https://openai.com/chatgpt/enterprise

"3.1 Pro 专为那些简单答案远远不够的任务而设计。" —— The Gemini Team

• 无限缩放：在任何分辨率下都保持清晰
• 极小体积：文件大小远小于传统视频格式
• 直接嵌入：可直接集成到网页中

• 生成视觉代码只是基础
• 构建了沉浸式体验，用户可以通过手势追踪操控鸟群
• 创作了生成式配乐，根据鸟类运动实时变化

• 推理小说的大气氛围
• 设计出简洁、现代的界面
• 创建一个捕捉原著精髓的网站

• Google AI Studio —— 在线提示工程环境
• Gemini CLI —— 命令行界面
• Google Antigravity —— Google 的代理开发平台
• Android Studio —— Android 开发环境

• Vertex AI —— Google Cloud 的企业级 AI 平台
• Gemini Enterprise —— 企业专属服务

• Gemini App —— 移动端和网页端应用
• NotebookLM —— AI 驱动的笔记和研究工具

订阅提示：Gemini App 中的 3.1 Pro 已向 Google AI Pro 和 Ultra 订阅用户推出，享有更高的使用限额。

1. 验证更新 —— 确保模型在实际使用中的稳定性
2. 推进代理工作流 —— 在 ambitious agentic workflows 领域取得进一步进展
3. 收集反馈 —— 为正式版（GA）的发布做准备

"我们迫不及待地想看到你们用它构建和发现什么。" —— The Gemini Team

• ✅ 推理性能翻倍（ARC-AGI-2 77.1%）
• ✅ 多平台同步推出（API、App、企业版）
• ✅ 实际应用场景验证（代码动画、系统设计、创意编程）
• ✅ 与 Deep Think 形成互补的产品矩阵
• ✅ 预览版已可用，正式版即将推出

• 官方博客: Gemini 3.1 Pro: A smarter model for your most complex tasks
• Gemini 3 Deep Think: Gemini 3 Deep Think: Advancing science, research and engineering
• Google AI Studio: https://aistudio.google.com
• Gemini CLI: https://geminicli.com/
• Google Antigravity: https://antigravity.google/

视频中的某个像素在任意时刻、从选定相机视角观察时，在三维空间中的位置在哪里？

• 点追踪（Point Tracking）：通过查询像素在不同时间步的位置，D4RT 可以预测其 3D 轨迹。重要的是，即使物体在其他视频帧中不可见，模型也能进行预测。
• 点云重建（Point Cloud Reconstruction）：通过冻结时间和相机视角，D4RT 可以直接生成场景的完整 3D 结构，无需额外的相机估计或逐视频迭代优化。
• 相机姿态估计（Camera Pose Estimation）：通过生成并比对来自不同视角的单一时刻 3D 快照，D4RT 可以轻松恢复相机轨迹。

• 机器人（Robotics）：机器人需要在充满移动人员和物体的动态环境中导航。D4RT 可以提供安全导航和灵巧操作所需的空间感知能力。
• 增强现实（AR）：为了让 AR 眼镜将数字对象叠加到现实世界，它们需要对场景几何有即时、低延迟的理解。D4RT 的效率使其在设备端部署成为可触及的现实。
• 世界模型（World Models）：通过有效解耦相机运动、物体运动和静态几何，D4RT 让我们更接近拥有物理现实真正"世界模型"的 AI——这是通往 AGI 的必要步骤。

OpenAI Codex Security 设计理念解析：为何弃用 SAST 报告作为起点

原文来源：OpenAI Blog
发布时间：2026年3月
关键词：AI 安全、代码安全、SAST、静态分析、Codex Security

引言

数十年来，静态应用安全测试（SAST）一直是安全团队扩展代码审查工作的最有效方式之一。然而，当 OpenAI 构建 Codex Security 时，他们做出了一个深思熟虑的设计选择：不通过导入静态分析报告并让智能体对其进行分类来启动流程。相反，Codex Security 的设计是从代码仓库本身出发——包括其架构、信任边界和预期行为——并在要求人工投入时间之前验证其发现的问题。

这个决策背后的原因很简单：最难发现的漏洞通常不是数据流问题。它们发生在代码看似执行了安全检查，但该检查实际上并不能保证系统所依赖的安全属性时。换句话说，挑战不仅仅是追踪数据如何在程序中流动——而是确定代码中的防御措施是否真正有效。

SAST 的核心局限：过度优化数据流分析

理想化的 SAST 模型

SAST 通常被描述为一个清晰的流水线：

识别不可信输入源 → 追踪数据在程序中的流动 → 标记数据未经净化到达敏感接收点的情况

这是一个优雅的模型，涵盖了大量真实存在的漏洞。

现实中的近似处理

然而在实际应用中，SAST 为了在大规模真实代码库中保持可处理性，不得不进行近似处理——尤其是在存在间接调用、动态分发、回调、反射和重度框架控制流的情况下。这些近似处理并不是对 SAST 的批评；而是在不执行代码的情况下推理代码的现实妥协。

更深层的问题

但这本身并不是 Codex Security 不以 SAST 报告为起点的原因。

更深层的问题是：即使成功地将数据源追踪到接收点，静态分析仍然必须回答一个决定漏洞是否真正存在的问题：

代码中的检查是否真正以系统假设的方式约束了值？

以一个常见模式为例：代码在渲染不可信内容之前调用类似 sanitize_html() 的函数。静态分析器可以看到净化器已运行，但它通常无法确定该净化器对于特定的渲染上下文、模板引擎、编码行为和下游转换是否真正充分。

这就是问题变得棘手的地方。问题不仅仅是数据是否到达接收点，而是代码中的检查是否真正以系统假设的方式约束了值。

换句话说："代码调用了净化器" 与 "系统是安全的" 之间存在巨大差异。

真实案例：解码前的验证陷阱

场景描述

以下是一个在真实系统中频繁出现的模式：

一个 Web 应用接收 JSON 负载，提取 redirect_url，使用白名单正则表达式验证它，然后进行 URL 解码，并将结果传递给重定向处理器。

经典 SAST 报告视角

传统的源到接收点报告可以描述数据流：

不可信输入 → 正则检查 → URL 解码 → 重定向

真正的问题

但真正的问题不是检查是否存在，而是该检查在后续转换之后是否仍然以重定向处理器解释的方式约束了解码后的 URL。

如果正则表达式在解码之前运行，它是否真的约束了解码后的 URL？

回答这个问题意味着需要推理整个转换链：

• 正则表达式允许什么？
• 解码和规范化如何表现？
• URL 解析如何处理边缘情况？
• 重定向逻辑如何解析方案和权限？

CVE-2024-29041 实例

许多在实践中真正重要的漏洞看起来都是这样的：操作顺序错误、部分规范化、解析歧义、验证与解释之间的不匹配。数据流是可见的，弱点在于约束如何传播——或在转换链中如何失效传播。

这不仅仅是理论模式。在 CVE-2024-29041 中，Express 受到开放式重定向问题的影响，格式错误的 URL 可以绕过常见的白名单实现，因为重定向目标在被编码后又被解释的方式存在问题。数据流是直接的，更难的问题——也是决定漏洞是否存在的问题——是验证在转换链之后是否仍然成立。

Codex Security 的解决方案：从行为出发，然后验证

核心目标

Codex Security 围绕一个简单的目标构建：通过呈现带有更强证据的问题来减少分类工作。

技术实现

在产品中，这意味着使用仓库特定的上下文（包括威胁模型），并在呈现问题之前在隔离环境中验证高信号问题。

当 Codex Security 遇到看起来像是"验证"或"净化"的边界时，它不会将其视为复选框。它会尝试理解代码试图保证什么——然后尝试证伪该保证。

在实践中，这往往表现为以下方式的组合：

关键转变

这是关键的转变：不是停留在"存在检查"，而是系统推进到"不变式成立（或不成立），这里有证据"。模型会为该任务选择最佳工具。

为何不以 SAST 报告为种子？

合理的疑问

一个合理的反应是：为什么不两者兼顾？ 从 SAST 报告开始，然后使用智能体进行更深入的推理。

在某些情况下，预计算的发现是有帮助的——特别是对于狭窄的、已知的错误类别。但对于一个旨在在上下文中发现和验证漏洞的智能体，从 SAST 报告开始会产生三种可预见的失败模式：

失败模式一：过早狭窄化

发现列表是工具已经查看过的地方的地图。如果你将其视为起点，你可能会使系统偏向于在同一区域使用相同的抽象花费不成比例的努力，错过不适合该工具世界观的漏洞类别。

失败模式二：隐含判断难以撤销

许多 SAST 发现编码了关于净化、验证或信任边界的假设。如果这些假设是错误的——或者只是不完整——将它们输入推理循环可能会使智能体从"调查"转变为"确认或驳回"，这不是我们希望智能体做的事情。

失败模式三：难以评估推理系统

如果流水线从 SAST 输出开始，就很难将智能体通过自己的分析发现的内容与从其他工具继承的内容分开。如果我们想要准确测量系统的能力，这种分离很重要，而准确测量是系统随时间改进所必需的。

OpenAI 的选择

因此，OpenAI 将 Codex Security 构建为从安全研究开始的地方开始：从代码和系统的意图出发，使用验证来提高置信度门槛，然后再打断人类。

SAST 工具仍然非常重要

适用范围

SAST 工具在其设计的方面可以表现出色：

• ✅ 执行安全编码标准
• ✅ 捕获直接的源到接收点问题
• ✅ 以可预测的权衡大规模检测已知模式
• ✅ 作为纵深防御的强大组成部分

本文的限定范围

这篇文章的范围更窄：它是关于为什么一个旨在推理行为和验证发现的智能体不应该将其工作锚定在静态发现列表上。

超越源到接收点思维

还值得指出纯源到接收点思维的一个相关局限：并非每个漏洞都是数据流问题。许多真实的故障是状态和不变式问题——工作流绕过、授权缺口和"系统处于错误状态"的错误。对于这些类型的错误，受污染的值不会到达单个"危险接收点"。风险在于程序假设将永远为真的东西。

未来展望

OpenAI 期望安全工具生态系统持续改进：静态分析、模糊测试、运行时守卫和智能体工作流都将发挥作用。

Codex Security 希望擅长的部分是对安全团队成本最高的部分：将"这看起来可疑"转变为"这是真实的，这是它失败的方式，这是符合系统意图的修复方案"。

参考资源

• Codex Security 官方文档
• CVE-2024-29041 漏洞详情
• OpenAI Codex Security 研究预览

总结

Codex Security 代表了一种新的 AI 驱动安全分析范式：不是取代人类安全研究员，而是通过提供经过验证的、高置信度的问题发现来增强他们的能力，让他们将宝贵的时间花在真正需要人类判断的地方。

本文基于 OpenAI 官方博客文章翻译整理，如有出入请以原文为准。

• 中间文件存放在哪里？
• 如何避免将大表格粘贴到提示词中？
• 如何在不造成安全噩梦的情况下给工作流提供网络访问？
• 如何处理超时和重试，而无需自己构建工作流系统？

1. 组装上下文：用户提示词 + 历史对话状态 + 工具指令
2. 模型决策：决定下一步动作（如选择 Shell 执行）
3. 命令转发：Responses API 服务将命令转发到容器运行时
4. 流式输出：Shell 输出流式返回，并反馈到下一次请求的上下文
5. 结果检查：模型检查结果，发出后续命令或生成最终答案
6. 循环直到完成

OpenAI 的最新模型经过训练，能够分析先前的对话状态，并生成一个压缩项（Compaction Item），以加密的、token 高效的形式保留关键先前状态。

"语言模型的意义不仅仅是生成文本、图像和音频——我们将继续发展我们的平台，使其更能够大规模处理复杂的真实世界任务。"

日本乐天集团用 Codex 将问题修复速度提升一倍

原文来源：OpenAI Blog
发布时间：2025年3月

引言

乐天（Rakuten）是日本最大的电商平台之一，业务涵盖电子商务、金融科技和移动通信，拥有 30,000 名全球员工。在这样庞大而复杂的产品生态系统中，速度和可靠性都是至关重要的。

乐天 AI for Business 总经理 Yusuke Kaji 在过去一年里一直致力于将 AI Agent 工作流深度整合到团队的软件规划、构建和验证流程中。OpenAI Codex 已成为乐天工程栈的核心组成部分，特别是在需要在不牺牲安全性的前提下提升速度的场景中。

核心成果：MTTR 降低 50%

在过去一年中，乐天工程师在运维和软件交付流程中广泛使用 Codex，取得了显著成效：

"我们不只是关心快速生成代码，我们更关心安全地交付。没有安全性的速度不是成功。" —— Yusuke Kaji

三大核心战略

乐天的 AI 战略围绕三个明确的目标展开：

1. 构建更快（"Speed!! Speed!! Speed!!"）

在运维工作流中使用 Codex，包括基于 KQL（Azure 日志查询语言）的监控和诊断，加速根因分析和修复，将 MTTR 压缩高达 50%。

2. 构建更安全（"Get things done"）

在 CI/CD 流程中调用 Codex 进行代码审查和漏洞检查，自动应用内部标准，让团队能在有防护栏的情况下快速交付。

3. 更智能地运营（"AI-nization"）

Codex 推动更大规模、更模糊的项目从规范走向可工作的实现，减少对完美定义需求的依赖，实现更自主的执行，最终将季度级的工作压缩到周级。

实战案例

案例一：压缩事故响应时间

乐天的工程师使用 KQL 监控 API 和分析信号。Codex 与这些工作流协同工作，帮助识别根因并提出修复建议，缩短从告警到解决的时间。

从站点可靠性工程（SRE）的角度来看，这缩短了从检测到修复的路径。工程师不再需要手动拼凑查询、日志和补丁，而是可以专注于验证和部署修复方案。

结果：乐天估计这种方法可以将 MTTR 降低约 50%——换句话说，当出现问题时，修复速度快了一倍。

案例二：CI/CD 中的自动化安全检查

随着交付速度加快，审查和部署可能成为瓶颈。乐天通过将 Codex 直接集成到 CI/CD 管道中来解决这个问题。

Codex 在变更到达生产环境之前进行代码审查和漏洞检查。乐天的做法是将内部编码原则和标准输入到这些工作流中，确保审查符合公司期望。

"我们将内部编码原则提供给 Codex，它使用相同的原则来审查代码是否符合我们的标准。" —— Yusuke Kaji

结果：安全检查一致且自动地进行，使团队能够在不降低标准的情况下更快前进。

案例三：从单条规范到全栈实现

乐天的第三个优先事项——AI-nization——专注于自主性。Codex 不仅用于审查和维护，还用于端到端执行更大规模、更模糊的项目。

Codex 可以从部分需求出发推进工作并生成可用的交付物，而不需要完美定义的规范。

"最新的 Codex 模型能够读懂言外之意，即使需求没有完美定义，它也能理解我们要构建什么。" —— Yusuke Kaji

具体案例：构建一个现有基于 Web 的 AI Agent 服务的移动应用版本。Codex 实现了完整的规范，包括：

• 后端：Python/FastAPI
• 前端：Swift/SwiftUI iOS 应用
• API：所有后端接口

整个过程无需逐步人工指导，Codex 将项目开发时间从一个季度缩短到几周。

工程师角色的转变

随着 Codex 承担更多代码生成工作，乐天正在将工程师的角色从编写代码转变为：

1. 编写更清晰的规范
2. 根据可衡量的标准验证输出

"我们的角色不再是检查每一行代码，我们的角色是清晰地定义我们想要什么，并建立验证它的方法。" —— Yusuke Kaji

乐天通过在全工程、产品和非技术团队中开展实践研讨会来支持这一转变——使 Codex 在帮助团队更快交付、更安全运营和在整个组织内扩展自主开发方面发挥核心作用。

总结

乐天集团的实践展示了 AI 编码助手在企业级场景中的巨大潜力：

• 速度：事故修复时间缩短 50%
• 安全：CI/CD 中自动化的代码审查和漏洞检测
• 自主性：从模糊需求到完整实现，开发周期从季度缩短到周
• 角色转变：工程师从编码者变为规范制定者和验证者

对于正在考虑引入 AI 编码助手的企业来说，乐天的经验提供了宝贵的参考：不仅要关注代码生成速度，更要建立相应的安全检查和验证机制，让 AI 成为提升整体工程效能的可靠伙伴。

相关链接

• OpenAI Codex 官网
• 乐天集团官网
• Azure KQL 查询语言文档

• 采用"人类代理"思维
• 分层防御
• 最小权限原则
• 关键操作需用户确认

AI 编程工具的使用数据一直是个黑盒——我们知道很多人在用，但具体用得怎么样？哪些场景效果好？什么情况下会放弃？最近，一个团队开源了他们的分析工具 Rudel，并基于 1573 个真实的 Claude Code 会话数据，给出了一些有趣的洞察。

数据集概况

这个数据集来自一个 6 人团队（4 名工程师、1 名数据/业务人员、1 名设计工程师）在过去 3 个月的真实使用记录：

• 总会话数：1,573 个
• 总 Token 数：1500 万+
• 总交互数：27 万+
• 会话类型：40% 大型遗留项目、50% 新项目、10% 非编码任务

核心发现

1. Skills 使用率极低：仅 4%

Claude Code 的 Skills 功能（预定义的指令模板）使用率只有 4%。这引发了一个问题：是功能设计有问题，还是用户根本不知道它的存在？

从 Hacker News 的讨论来看，可能两者都有：

• Skills 的可发现性较差
• 用户更倾向于自然语言提示
• 即使设置了 Skills，Claude 也不一定会调用

好消息是，Claude 4.6 版本在这方面有明显改进。

2. 26% 的会话在 60 秒内被放弃

超过四分之一的会话在开始后的第一分钟内就被用户放弃。这个数字揭示了一个关键问题：初始提示与意图匹配的重要性。

正如 HN 用户 robutsume 分析的：

"这不是代理的问题，而是提示与意图不匹配的问题。人类在一次交互后就意识到他们问错了问题，或者代理理解错了。"

3. 错误级联模式：前 2 分钟决定成败

研究发现，如果在会话的前 2 分钟出现工具选择错误或文件读取错误，后续放弃的概率会显著增加。这和基础设施监控的经验很相似——部署的前 90 秒几乎能决定一切。

4. 不同任务类型的成功率差异显著

• 文档编写：成功率最高
• 代码重构：成功率最低

这个发现符合直觉：文档任务边界清晰、验证简单；而重构涉及复杂的代码理解和依赖分析，更容易出错。

对 AI 搜索的启示

虽然这项研究聚焦于编程场景，但对 AI 搜索产品的设计也有参考价值：

1. 首因效应至关重要 用户在前 60 秒的体验决定了他们是否会继续使用。搜索产品需要在最短时间内给出高质量结果。

2. 错误恢复机制 当 AI 理解错误时，如何快速纠正比追求完美更重要。Rudel 的数据显示，错误级联一旦发生，用户很快就会失去耐心。

3. 功能发现性 即使有强大的功能（如 Skills），如果用户不知道或不会用，就等于不存在。AI 搜索产品需要更智能地引导用户使用高级功能。

4. 任务适配性 不同的搜索场景对 AI 的要求不同。简单的事实查询 vs 复杂的分析任务，需要不同的交互设计和预期管理。

Rudel 工具本身

这项研究的开源工具 Rudel 也值得关注。它通过 Claude Code 的 hooks 机制，在会话结束时自动上传数据，提供团队级的使用分析：

• 个人和团队的会话统计
• Token 使用趋势
• 项目时间分配
• 会话成功率分析

对于想要量化 AI 工具 ROI 的团队来说，这类分析工具很有价值。

社区反响

这个项目在 Hacker News 上获得了 85 个点赞和 50+ 评论。讨论焦点包括：

• 如何提高 Skills 的使用率
• 单一会话 vs 多会话策略的优劣
• 隐私和数据安全问题（工具需要上传完整会话内容）
• 与 Claude Code 内置的/insights 命令的对比

写在最后

AI 编程代理还处于早期阶段，我们对其使用模式的理解非常有限。Rudel 团队的数据虽然只来自一个小团队，但提供了宝贵的实证基础。

随着 AI Agent 的普及，相信会有更多类似的研究出现。而对于搜索技术从业者来说，理解用户如何与 AI 交互、在什么情况下会放弃，将是设计更好产品的关键。

你使用 Claude Code 或其他 AI 编程工具吗？你觉得最大的痛点是什么？

来源：Rudel GitHub / Hacker News 讨论 原文发布时间：2026 年 3 月 12 日 Hacker News 热度：85 points, 53 comments

想象一下，你的监控摄像头能在从未见过打斗、事故或入侵的情况下，自动检测出这些异常事件。这不是科幻，而是向量检索技术在边缘计算场景下的最新实践。

Qdrant 最近发布了一套完整的边缘到云端的视频异常检测方案，核心思路非常巧妙：不再问"这是什么异常？"，而是问"这与正常状态有多不同？"

传统方法的困境

传统的视频异常检测依赖监督学习。你需要为每一种异常类型收集标注数据——打斗、事故、入侵、设备故障……问题是，在现实世界中，你无法枚举所有可能出错的情况。

更麻烦的是，当一个全新的异常类型出现时，训练好的分类器会直接失效。一个用13种犯罪类别训练的模型，面对叉车碰撞或管道爆裂时，置信度直接归零。

这就是监督学习的根本局限：正常行为的空间是可学习的，但异常行为的空间是无界的。

向量检索的破局之道

Qdrant 的方案将异常检测重新定义为最近邻搜索问题：

1. 建立基线：将正常活动的视频片段编码成向量，存入 Qdrant 作为基线
2. 实时比对：新视频片段到达时，编码并搜索最近邻
3. 异常判定：如果片段与基线距离较远，即为异常

这种方法的最大优势是零样本检测——无需异常标注，无需针对新异常类型重新训练。任何偏离正常模式的行为，无论是否见过，都能被捕获。

技术架构：四层协作

这套方案的精妙之处在于边缘与云端的智能分工：

Qdrant Edge：边缘端的向量引擎

运行在 NVIDIA Jetson 设备上，采用双分片架构：

• 不可变 HNSW 分片：从云端同步的基线数据，提供亚毫秒级 kNN 检索
• 可变更写入分片：支持实时写入和本地更新

关键特性：完全离线可用，网络中断不影响本地检测。

Twelve Labs Marengo 3.0：视频理解的大脑

相比 CLIP 等帧级模型（0.23 AUC-ROC），Marengo 3.0 处理时序动态、音频和场景上下文作为统一信号，达到 0.97 AUC-ROC。一个模型同时处理异常评分和语义搜索。

NVIDIA Metropolis VSS：GPU 加速管道

编排视频摄入、嵌入生成、VLM 字幕、音频转录和 CV 管道，全部在 GPU 上并行运行。

Vultr Cloud GPUs：云端算力支撑

提供按小时计费的专用 NVIDIA GPU，全球数据中心布局确保低延迟和可预测成本。

边缘优先的成本优化

一个 50 摄像头的部署每天产生 432,000 个视频片段。如果全部发送到云端处理，既不快速也不经济。

Qdrant Edge 的解决方案是边缘分级处理：

• 边缘端进行初筛，仅将高异常评分片段上传到云端
• 云端使用 Marengo 3.0 进行高保真分析和集成评分
• 结果：云处理量减少约 6 倍，同时捕获约 95% 的真实异常

这种架构让系统能够随摄像头数量线性扩展，而无需让云成本同步线性增长。

实际产出能力

这套系统将实时视频流转化为：

• 实时异常评分：基于与正常基线的 kNN 距离，配合时序平滑和迟滞阈值过滤噪声
• 事件报告：带严重度评分、时间线和自然语言解释的事故报告
• 语义视频搜索：跨所有摄像头和时间段搜索，比如"显示上周北门的不寻常活动"
• 交互式问答：基于实际视频内容回答关于检测到事件的问题

开源与教程

Qdrant 发布了完整的 3 部分教程，包含可运行代码：

• Part 1: 架构、Twelve Labs 和 NVIDIA VSS
• Part 2: 边缘到云端管道
• Part 3: 评分、治理和部署

GitHub 仓库：qdrant/video-anomaly-edge

启示：重新定义问题

这个案例给我们的最大启发是：有时候，解决问题的最佳方式不是优化现有方案，而是重新定义问题本身。

与其训练模型识别所有异常类型（一个注定失败的任务），不如利用向量检索的固有优势——相似度计算。当"异常"被定义为"与正常状态的偏离"时，问题突然变得可解了。

向量数据库不再只是 RAG 应用的检索层，它正在成为新一代 AI 应用的基础设施——从推荐系统到异常检测，从语义搜索到智能体记忆。

来源: Qdrant Blog - Video Anomaly Detection From Edge to Cloud
发布时间: March 15, 2026

论文精读：通过提示词实现 LLM 推荐系统的公平性去偏

论文标题: Can Fairness Be Prompted? Prompt-Based Debiasing Strategies in High-Stakes Recommendations

作者: Theresia Veronika Rampisela 等

arXiv: https://arxiv.org/abs/2603.12935

发表时间: 2026年3月

研究背景

大语言模型（LLM）在推荐系统中的应用日益广泛，但一个潜在问题是：LLM 可能从间接线索（如姓名、代词）推断出敏感属性（如性别、年龄），从而在推荐中产生偏见。

现有的去偏方法通常需要：

• 访问 LLM 的权重参数
• 高昂的计算成本
• 专业知识

这使得普通用户难以使用这些技术。

核心问题

能否仅通过提示词（prompt）来实现推荐系统的公平性去偏？

研究贡献

本文提出了三种基于提示词的去偏策略：

1. 公平性指令提示 (Fairness Instruction Prompting)

直接在提示中加入公平性相关的指令，如：

"请确保你的推荐对所有用户群体都公平，不考虑性别、年龄等因素。"

2. 反事实示例提示 (Counterfactual Prompting)

通过构造反事实场景来消除敏感属性的影响。

3. 偏见感知系统提示 (Bias-Aware System Prompting)

在系统层面加入对潜在偏见的警示和约束。

实验设置

• 测试模型: 3 个不同的 LLM
• 提示模板: 4 种
• 敏感属性: 9 种（性别、年龄等）
• 数据集: 2 个真实推荐数据集

核心发现

✅ 有效性

• 基于提示的去偏方法最高可提升 74% 的公平性指标
• 同时保持了与基线相当的有效性（推荐准确率）

⚠️ 局限性

• 在某些情况下可能导致特定群体的过度推广（overpromotion）
• 提示的设计对效果影响很大，需要仔细调优

实践意义

对搜索/推荐工程师的启示

1. 轻量级解决方案

   • 无需修改模型权重或重新训练
   • 部署成本低，可快速实验

2. 高 stakes 场景适用

   • 金融、医疗、招聘等领域的推荐系统
   • 需要满足合规要求的场景
3. 提示工程的新维度
   • 除了追求准确性，还需考虑公平性
   • 建议将公平性测试纳入提示评估流程

局限与未来方向

• 研究主要关注群体公平性（group fairness）
• 个体公平性（individual fairness）的提示策略仍需探索
• 不同语言和文化背景下的适用性有待验证

原文链接

https://arxiv.org/abs/2603.12935

这篇论文为 LLM 推荐系统的公平性优化提供了一个实用且低成本的切入点，值得在工业落地中尝试。

标题：EISAM：大语言模型推荐系统的长尾问题破局之道

正文：

EISAM：大语言模型推荐系统的长尾问题破局之道

背景介绍

近年来，大语言模型（LLM）在推荐系统领域掀起了一场范式革命。大语言模型推荐系统（LLM-based Recommender Systems, LRS）通过直接采用LLM作为骨干网络，展现出强大的知识利用能力和指令遵循能力，成为序列推荐任务的新范式。

然而，推荐系统领域一个长期存在的挑战——长尾问题（Long-tail Problem）——在LRS中尚未得到系统性研究。传统的推荐系统由于数据分布的倾斜性，往往对热门物品（头部物品）推荐效果较好，而对冷门物品（尾部物品）的推荐性能较差。这种不平衡不仅影响用户体验，也限制了推荐系统的多样性和公平性。

随着LRS的兴起，一个关键问题浮出水面：LLM强大的预训练能力能否天然缓解长尾问题？还是说LRS面临着更加复杂的挑战？

问题分析：LRS中的双重长尾困境

最新研究揭示了一个令人意外的发现：LRS实际上面临着两种不同类型的长尾问题：

1. 先验长尾（Prior Long-tail）

LLM在海量通用语料上进行预训练，这些语料本身存在严重的不平衡分布——某些物品或概念在预训练数据中出现频率远高于其他。这种分布偏差被LLM隐式继承，形成了先验长尾。即使下游推荐数据集是平衡的，模型仍可能因为这种预训练偏差而偏向某些物品。

2. 数据长尾（Data Long-tail）

这是传统推荐系统中常见的问题。推荐数据集本身呈现典型的幂律分布：少数热门物品占据了绝大部分交互记录，而大量长尾物品只有极少数交互。这种数据长尾直接导致模型对头部物品学习更充分。

双重头部效应

研究表明，这两种长尾并非独立存在，而是产生了叠加效应：

• 先验长尾和数据长尾都会导致头部与尾部物品之间的性能差距
• 两种"头部"的交集（既在预训练语料中高频出现、又在推荐数据集中热门的物品）表现出更强的头部效应
• 尽管如此，LRS的整体性能分布（尤其是尾部表现）仍主要由数据长尾主导

这一发现具有重要的实践意义：即使使用强大的LLM作为骨干，如果不针对数据长尾进行优化，尾部物品的推荐质量仍然难以保障。

EISAM方法：高效物品级锐度感知最小化

针对上述挑战，研究者提出了EISAM（Efficient Item-wise Sharpness-Aware Minimization），一种全新的优化框架，专门用于改善LRS中的长尾问题。

核心思想

EISAM的核心洞察是：不同物品需要不同程度的正则化。传统优化方法对所有样本一视同仁，而EISAM通过自适应地调节每个物品的损失景观（loss landscape），为尾部物品提供更强的正则化，从而提升其泛化性能。

技术亮点

1. 物品级正则化：EISAM在物品粒度上进行优化，而非传统的样本级或全局级。这使得模型能够精细地捕捉每个物品的特性。

2. 高效惩罚设计：考虑到LLM的巨大参数量，EISAM设计了一种计算高效的惩罚机制，在捕捉细粒度物品特定锐度的同时，保持计算可扩展性。

3. 自适应机制：正则化强度根据物品在数据分布中的位置自适应调整，尾部物品获得更强的正则化，头部物品则相对宽松。

理论分析：泛化界的快速下降

EISAM不仅在实践上有效，在理论上也有坚实的支撑。研究者推导了EISAM的泛化界（Generalization Bound），并证明：

在物品级正则化下，泛化界以更快的速率下降。

这一理论结果为EISAM的有效性提供了数学保证。具体来说，物品级正则化能够：

• 更精细地控制模型复杂度
• 针对不同物品的风险进行差异化约束
• 在保持整体模型容量的同时，改善尾部物品的泛化性能

实验结果：显著提升尾部性能

研究者在三个真实世界数据集上进行了广泛实验，结果验证了EISAM的有效性：

主要发现

1. 尾部物品性能显著提升：EISAM能够显著改善长尾物品的推荐效果，缩小头部与尾部之间的性能差距。

2. 整体质量保持：在提升尾部性能的同时，EISAM不会损害整体推荐质量，实现了"双赢"。

3. 首个系统性解决方案：EISAM建立了LRS长尾问题的首个系统性解决方案，为该领域的后续研究奠定了基础。

实验意义

这些实验结果具有重要的实践价值：

• 对于电商平台，可以更好地推荐长尾商品，提升长尾商品曝光和销量
• 对于内容平台，可以改善冷门内容的推荐效果，促进内容生态的多样性
• 对于任何使用LLM作为推荐骨干的系统，EISAM提供了一种即插即用的优化方案

总结与展望

EISAM的提出标志着LRS长尾问题研究的重要突破。通过揭示LRS中双重长尾的存在，并提出针对性的优化方法，研究者为这一新兴领域奠定了坚实的理论基础和实践方案。

关键启示：

1. LLM并非万能：即使拥有强大的预训练能力，LRS仍需要专门的长尾优化策略。

2. 细粒度正则化的价值：物品级优化能够更精准地解决长尾问题，相比粗粒度的全局方法更具优势。

3. 理论与实践的结合：EISAM既有坚实的理论支撑，又在实践中表现出色，为后续研究提供了良好范例。

未来，随着LRS在工业界的广泛应用，如何进一步优化长尾性能、如何平衡多样性与准确性、如何在大规模场景下高效部署EISAM，都是值得探索的方向。

来源：arXiv:2603.12752

标签：LLM推荐系统,长尾问题,锐度感知最小化,推荐算法

标题：告别"大海捞针"：FGTR如何用分层推理革命性提升多表检索精度

正文：

背景介绍

随着大型语言模型（LLM）的快速发展，基于LLM的表格检索技术已成为RAG（检索增强生成）领域的重要研究方向。在数据分析、商业智能和知识问答等场景中，准确检索与用户查询相关的表格数据是提升下游任务性能的关键环节。

然而，当前主流的表格检索方法存在明显的局限性：它们通常聚焦于单表查询场景，采用将整个表格编码后进行相似度匹配的策略。这种"粗粒度"的检索方式不仅效率低下，更难以应对复杂的多表关联查询需求。

问题分析

现有方法的痛点主要体现在两个方面：

1. 准确率瓶颈

传统方法将整个表格作为整体进行编码，导致大量与查询无关的数据被混入表征中。这种"噪声污染"严重降低了检索的精确度——想象一下，在一个包含数百行的大型表格中，用户可能只关心其中某几列的特定数据，但现有方法却无法有效过滤无关信息。

2. 效率与扩展性问题

当处理大规模表格时，编码整个表格的开销急剧增加。更重要的是，现实世界的数据查询往往需要跨多个表格进行关联分析，而这一需求在当前的检索任务中研究严重不足。

FGTR方法：细粒度多表检索

针对上述挑战，研究者提出了FGTR（Fine-Grained Multi-Table Retrieval）——一种基于分层LLM推理的新型检索范式。

FGTR的核心创新在于模拟人类的推理策略，采用分层递进的检索机制：

第一层：模式元素识别

FGTR首先分析查询意图，识别出相关的数据库模式元素（如表名、列名）。这一步骤相当于人类在查找数据前先确定"去哪里找"。

第二层：单元格内容检索

在确定目标模式后，FGTR进一步检索对应的单元格内容。这种细粒度的定位避免了无关数据的干扰。

第三层：子表构建

最终，FGTR构建出一个简洁、精确的子表，该子表与原始查询高度对齐，可直接用于下游任务。

这种分层推理的优势在于：它既保留了LLM强大的语义理解能力，又通过逐步聚焦的方式实现了细粒度检索，有效解决了"粗粒度编码"带来的准确率损失问题。

实验结果

为全面评估FGTR的性能，研究团队基于两个权威基准数据集Spider和BIRD构建了新的评测数据集。

实验结果令人瞩目：

这一显著的性能提升充分证明了FGTR在细粒度检索任务上的优越性，同时也展示了其在提升表格相关下游任务端到端性能方面的巨大潜力。

总结

FGTR的提出为表格检索领域开辟了新的研究方向。它通过分层推理机制，成功突破了传统粗粒度方法的瓶颈，在准确率和效率之间取得了更好的平衡。

对于正在构建RAG系统的开发者而言，FGTR提供了一种值得关注的表格检索新范式。特别是在需要处理复杂多表查询的场景中，这种细粒度的检索思路可能会带来质的提升。

标签： 表格检索、LLM推理、RAG、数据库检索

来源： arXiv:2603.12702

LLM Architecture Gallery：主流大模型架构可视化对比

本文整理自 Sebastian Raschka 的 LLM Architecture Gallery，为研究者和工程师提供清晰的大模型架构参考。

概述

随着开源大语言模型（LLM）生态的快速发展，理解不同模型的架构差异变得越来越重要。Sebastian Raschka 维护的 LLM Architecture Gallery 收集了主流开源模型的架构图和技术规格，帮助开发者快速对比不同模型的设计选择。

项目地址：https://sebastianraschka.com/llm-architecture-gallery/

主要模型架构对比

DeepSeek-V3 / R1

• 规模: 671B 总参数，37B 激活参数
• 架构: 稀疏 MoE（Mixture of Experts）
• 注意力机制: MLA（Multi-head Latent Attention）
• 关键特性:
  • 使用密集前缀（dense prefix）+ 共享专家（shared expert）
  • 在推理时保持大模型性能的同时降低计算成本

OLMo 2

• 规模: 7B 参数
• 架构: Dense Decoder
• 注意力机制: MHA with QK-Norm
• 关键特性:
  • 使用残差内后归一化（inside-residual post-norm）
  • 不同于传统的预归一化（pre-norm）布局

Llama 3

• 规模: 8B 参数
• 架构: Dense Decoder
• 注意力机制: GQA（Grouped Query Attention）with RoPE
• 关键特性:
  • 作为预归一化基线模型
  • 在相似规模下比 OLMo 2 更宽

架构设计趋势

1. MoE 成为大模型标配

DeepSeek-V3/R1 的成功证明了稀疏 MoE 架构的可行性。通过路由机制选择性地激活部分专家网络，MoE 模型可以在保持推理效率的同时显著扩展模型容量。

2. 注意力机制演进

• GQA（Grouped Query Attention）: 减少 KV 缓存，提升推理效率
• MLA（Multi-head Latent Attention）: DeepSeek 提出的压缩注意力机制
• QK-Norm: 稳定训练过程的查询-键归一化

3. 归一化策略多样化

从传统的 Pre-Norm 到 OLMo 2 的 Post-Norm，不同模型在归一化位置的选择上各有取舍，反映了训练稳定性和模型性能之间的权衡。

对搜索系统的启示

这些架构创新对构建 AI 搜索系统具有重要参考价值：

1. 推理效率优化: GQA 和 MLA 等机制可以显著降低检索时的延迟
2. 模型压缩: MoE 的路由机制启发了检索系统的分层索引设计
3. 多模态扩展: 统一的架构设计便于集成文本、图像等多种模态的编码器

参考资源

• LLM Architecture Gallery
• The Big LLM Architecture Comparison
• A Dream of Spring for Open-Weight LLMs

来源: Sebastian Raschka's LLM Architecture Gallery (2026-03-15 更新)