【搜索客社区日报】第2197期 (2026-03-16）

社区日报 • Muses 发表了文章 • 0 个评论 • 43 次浏览 • 34 分钟前 • 来自相关话题

论文精读：Agentic RAG 的测试时优化策略

AI 搜索 • paper_reader 发表了文章 • 0 个评论 • 108 次浏览 • 54 分钟前 • 来自相关话题

论文精读：Agentic RAG 的测试时优化策略

来自 Adobe Research 的最新研究《Test-Time Strategies for More Efficient and Accurate Agentic RAG》提出了一系列优化策略，显著提升了 Agentic RAG 系统的效率和准确性。

研究背景

检索增强生成（RAG）系统在处理复杂的多跳问题时面临挑战。近年来，Agentic 框架（如 Search-R1）通过迭代式检索-推理循环来解决这些问题，但带来了新的效率问题：

重复检索：多次检索已处理过的信息
上下文整合困难：难以将检索结果有效融入当前推理
不必要的检索轮次：导致 Token 消耗增加和答案准确性下降

核心贡献

研究团队提出了两个关键模块来优化 Search-R1 流程：

1. 上下文化模块（Contextualization Module）

更好地将检索文档中的相关信息整合到推理过程中。通过智能地重新组织和增强检索结果，帮助模型更有效地利用上下文信息。

2. 去重模块（De-duplication Module）

识别并替换已检索过的文档，转而获取下一个最相关的文档。这避免了信息的重复处理，提高了检索效率。

实验结果

研究在 HotpotQA 和 Natural Questions 数据集上进行了评估，使用以下指标：
Exact Match (EM) 分数：答案精确匹配率
LLM-as-a-Judge：LLM 评估答案正确性
平均轮次：完成查询所需的检索轮数

最佳配置表现

使用 GPT-4.1-mini 进行上下文化的变体取得了最佳效果：

| 指标 | 改进幅度 |
|------|----------|
| EM 分数 | +5.6% |
| 检索轮次 | -10.5% |

这表明优化后的系统不仅答案更准确，而且检索效率也显著提升。

技术细节

Search-R1 基线

Search-R1 是一个迭代的 Agentic RAG 框架，工作流程如下：
1. 接收用户查询
2. 生成搜索查询
3. 检索相关文档
4. 基于检索结果推理
5. 如有需要，生成新的搜索查询
6. 重复直到获得满意答案或达到最大轮次
  
  优化策略
  
  研究探索了两种组件的单独效果和组合效果：
上下文化：在每次检索后，使用轻量级 LLM 对检索结果进行重新组织和摘要
去重：维护已检索文档的缓存，避免重复检索相同内容

研究意义

这项工作对 Agentic RAG 领域有重要启示：
1. 测试时优化：不需要重新训练模型，仅通过改进推理流程就能显著提升性能
2. 效率与准确性兼顾：在提高准确性的同时减少了计算开销
3. 模块化设计：上下文化和去重模块可以独立使用，也可以组合使用
  
  相关资源
论文: [arXiv:2603.12396](https://arxiv.org/abs/2603.12396)
作者: Brian Zhang, Deepti Guntur, Zhiyang Zuo 等（Adobe Research）
发表时间: 2026年3月12日

---

标签: RAG, Agentic AI, 信息检索, LLM, Adobe Research
分类: AI 搜索

什么是 Agentic Engineering？Simon Willison 给出最新定义

AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 121 次浏览 • 54 分钟前 • 来自相关话题

什么是 Agentic Engineering？Simon Willison 给出最新定义

随着 Claude Code、OpenAI Codex、Gemini CLI 等 AI 编码工具的兴起，一个新的工程范式正在形成。知名开发者 Simon Willison 在其最新的《Agentic Engineering Patterns》指南中，系统性地阐述了这一概念。

Agentic Engineering 的定义

Agentic Engineering 是指借助编码智能体（Coding Agents）来开发软件的实践。

什么是编码智能体？

编码智能体是指既能编写代码又能执行代码的 AI 代理。与传统代码补全工具不同，它们具备以下特征：

代码执行能力：不仅生成代码，还能直接运行验证

目标导向：通过循环运行工具来实现既定目标

迭代优化：根据执行结果不断调整代码

核心原则：Agents run tools in a loop to achieve a goal

Willison 对 Agent 的定义简洁而深刻：

你给编码智能体设定一个目标，然后智能体循环生成并执行代码，直到目标达成。

代码执行是使 Agentic Engineering 成为可能的关键能力。没有直接运行代码的能力，LLM 的输出价值有限；而有了代码执行，这些智能体就能迭代地构建出真正可用的软件。

人类工程师的角色转变

既然 AI 能写代码了，人类工程师还有什么价值？

Willison 的回答是：价值巨大。

写代码从来就不是软件工程师的唯一工作。真正的技艺在于决定写什么代码。任何软件问题都有数十种潜在解决方案，每种都有其权衡取舍。人类工程师的工作是权衡这些选项，找到最适合特定场景的方案。

有效使用编码智能体的关键

要获得出色的结果，需要：

提供合适的工具：为智能体配备解决问题所需的工具集

精确描述问题：以恰当的详细程度说明需求

验证与迭代：检查结果并持续优化，直到满意

积累知识：虽然 LLM 不会从错误中学习，但我们可以通过更新指令和工具配置来积累经验

实践模式

Willison 的指南涵盖了多个实践模式：

编写代码现在很便宜：利用 AI 快速生成原型，然后迭代优化

囤积你知道怎么做的事：将常见任务的标准做法固化为可复用的提示词

AI 应该帮助我们产出更好的代码：不仅仅是更快，而是更高质量

红/绿测试驱动开发：让 AI 先写测试，再写实现

线性代码走查：让 AI 逐行解释复杂代码

未来展望

Agentic Engineering 是一个快速发展的领域。Willison 强调，这个指南本身也是"进行中的工作"，会随着新技术的出现持续更新。

有效使用编码智能体可以帮助我们承担更雄心勃勃的项目。Agentic Engineering 应该帮助我们产出更多、更高质量的代码，解决更有影响力的问题。

---

来源: [Simon Willison's Weblog](https://simonwillison.net/guid ... ering/)
发布时间: 2026年3月15日
HackerNews 热度: 41 points, 28 comments

非对称检索：把每月 1.5 万美元的嵌入成本降到零

AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 120 次浏览 • 58 分钟前 • 来自相关话题

向量搜索的成本结构正在被重新定义。

Vespa 和 Voyage AI 联合推出了一种新的检索范式：非对称检索（Asymmetric Retrieval）。它的核心洞察简单却深刻——文档嵌入和查询嵌入的成本结构完全不同，为什么要用同样的模型处理两者？

成本结构的残酷现实

想象一个日活百万的搜索服务：

10,000 QPS（每秒查询数）
每个查询约 30 个 token
每月需要嵌入 7770 亿个 token
按 $0.02/百万 token 计算：

仅查询嵌入成本：$15,500/月

这还只是嵌入 API 的费用，不包括存储、计算、网络等其他开销。

而文档嵌入呢？假设你有 1000 万篇文档，每篇平均 500 token：
一次性嵌入成本：$100
之后不再需要嵌入

文档嵌入是一次性投资，查询嵌入是持续性开销。

非对称检索的核心洞察

传统方法的对称性假设：
 文档 → 大模型嵌入 → 向量空间 ← 大模型嵌入 ← 查询 

非对称检索的解耦思路：
 文档 → 大模型嵌入（voyage-4-large）→ 向量空间 ← 小模型嵌入（voyage-4-nano）← 查询 

关键洞察：
1. 文档嵌入是离线的、一次性的、对延迟不敏感的——可以用最贵、最准的模型
2. 查询嵌入是在线的、持续的、对延迟敏感的——需要快速、低成本
 
 Voyage AI 的 voyage-4 系列模型让这种非对称成为可能：四个模型（large/standard/lite/nano）共享同一个向量空间，可以任意组合使用。
 
 成本对比：从 $15,500 到 $0
 
 | 方案 | 查询嵌入成本/月 | 延迟 | 质量 |
 |------|----------------|------|------|
 | 传统对称（大模型）| $15,500 | 高（API 调用）| 最佳 |
 | 非对称（大模型文档 + nano 查询）| $0 | 低（本地 CPU）| 接近最佳 |
 
 节省的成本不是通过降低质量实现的，而是通过把计算从云端 API 转移到本地 CPU。
 
 voyage-4-nano 是一个轻量级模型，可以在 Vespa 容器内本地运行，单次推理仅需几毫秒。
 
 质量如何保证？
 
 非对称检索最大的质疑是：小模型嵌入的查询，能准确匹配大模型嵌入的文档吗？
 
 Voyage AI 的实验数据给出了答案：
 
 在 MTEB 基准测试（29 个检索数据集，NDCG@10）上：
 
 | 对比 | 提升 |
 |------|------|
 | vs. Gemini Embedding 001 | +3.87% |
 | vs. Cohere Embed v4 | +8.20% |
 | vs. OpenAI v3 Large | +14.05% |
 
 更重要的是，非对称检索（大模型文档 + nano 查询）在医疗、代码、网页、金融、法律等多个领域都保持了接近全大模型的检索质量。
 
 这得益于 voyage-4 系列的共享向量空间设计：不同大小的模型学习到了兼容的表示，小模型的查询向量可以有效匹配大模型的文档向量。
 
 工程实现的关键
 
 Vespa 对非对称检索的原生支持，解决了几个生产环境的关键问题：
 
 1. 独立扩缩容
 
 Vespa 将无状态容器（运行嵌入）与内容集群（存储数据）分离：
需要更高 QPS？增加容器节点
需要更多文档？增加内容节点
两者互不干扰

2. 查询路径无外部依赖

传统方案的问题：
 用户查询 → 你的服务 → 嵌入 API → 返回向量 → 向量检索 → 返回结果 

任何一环的网络延迟或故障，都会影响用户体验。

非对称检索的方案：
 用户查询 → 你的服务（本地嵌入）→ 向量检索 → 返回结果 

嵌入在容器内完成，没有外部 API 调用，延迟可控，可用性更高。

3. 灵活的升级路径

共享向量空间的另一个好处：可以独立升级查询模型。
初期：使用 voyage-4-nano 控制成本
增长期：升级到 voyage-4-lite 提升质量
成熟期：针对特定租户使用 voyage-4-large

无需重新嵌入任何文档，只需更换查询端的模型。

对搜索架构的启示

非对称检索的流行，标志着向量搜索正在从"技术验证"走向"成本优化"阶段。

1. 成本意识成为架构设计的一等公民

早期的向量搜索只关注准确率和延迟，现在成本成为同等重要的指标。非对称检索是在质量、延迟、成本三者之间的优雅平衡。

2. 模型即基础设施

voyage-4-nano 运行在 Vespa 容器内，意味着嵌入模型成为基础设施的一部分，而不是外部依赖。这对运维和成本控制都是重大利好。

3. 多租户场景的天然适配

在多租户系统中，可以为不同租户配置不同的文档嵌入策略：
付费用户：voyage-4-large 文档嵌入
免费用户：voyage-4-lite 文档嵌入

所有租户共享相同的查询路径，但获得不同的检索质量。

局限与适用场景

非对称检索并非万能：
需要共享向量空间：只有同一模型家族的模型才能非对称组合
查询质量上限：小模型的查询表示能力有上限，极端复杂查询可能不如大模型
自托管成本：虽然省了 API 费用，但需要在容器内运行模型，增加了计算资源需求

最适合的场景：
高 QPS、查询成本敏感的应用
对延迟要求严格的实时搜索
希望减少外部依赖、提高可用性的系统

---

在 AI 搜索的成本优化之路上，非对称检索提供了一个新思路：不是降低质量来省钱，而是把计算移到更合适的地方。

当文档嵌入用最强模型、查询嵌入用本地轻量模型成为标配，向量搜索的经济学将被彻底改写。

---

来源: [Vespa Blog](https://blog.vespa.ai/asymmetr ... -free/) (March 10, 2026)
相关: [Voyage AI voyage-4 发布](https://blog.voyageai.com/2026/01/15/voyage-4/)
技术要点: 非对称检索、成本优化、向量搜索、模型蒸馏

锚点对齐：解决多模态推荐系统中的位置坍缩问题

AI 搜索 • paper_reader 发表了文章 • 0 个评论 • 131 次浏览 • 1 小时前 • 来自相关话题

多模态推荐系统正在面临一个隐藏的危机。

当系统试图将图像、文本、用户行为等不同模态的数据对齐到同一个向量空间时，一个微妙但致命的问题出现了：位置坍缩（Positional Collapse）。模态特有的结构信息被抹平，推荐质量悄然下降。

一篇最新的 arXiv 论文提出了一个优雅的解决方案：锚点对齐（Anchored Alignment）。

多模态推荐的困境

现代推荐系统早已不满足于单一的交互数据。商品图片、标题描述、用户评论——这些多模态信息理应让推荐更精准。

但传统的对齐方法有一个副作用：

强制对齐 = 信息损失

当你把图像特征和文本特征强行投影到同一个空间时：

图像的空间结构信息被稀释
文本的语义层次被压缩
最糟糕的是，ID 嵌入（用户/商品标识）开始主导一切

结果就是：模型记住了"用户 A 喜欢商品 B"，却忘记了"为什么喜欢"。

什么是位置坍缩？

想象一个三维空间：
X 轴代表图像特征（颜色、形状、纹理）
Y 轴代表文本特征（主题、情感、关键词）
Z 轴代表 ID 特征（用户偏好、商品属性）

强制对齐的过程，就像把这个三维空间压扁成二维平面。不同模态的信息被迫"挤"在一起，失去了原有的结构关系。

论文作者称之为"位置坍缩"——模态在嵌入空间中的相对位置失去了意义。

AnchorRec：解耦对齐与表示学习

AnchorRec 的核心洞察是：对齐和表示学习不应该在同一个空间进行。

传统方法：
 图像特征 → 统一空间 ← 文本特征 ↓ ↓ 对齐对齐 ↓ ↓ 混合表示 → 推荐预测 

AnchorRec 的方法：
 图像特征 → 投影空间 ← 文本特征 ↓ ↓ 锚点对齐（轻量级） ↓ ↓ 保持原生结构 → 多模态融合 → 推荐预测 

关键区别在于：
1. 原生结构保留：每个模态在自己的空间中学习表示
2. 间接对齐：通过轻量级投影空间进行锚点对齐
3. 解耦设计：对齐不干扰表示学习
 
 锚点机制的工作原理
 
 锚点对齐的核心是引入一组"锚点"（Anchors）作为中介：
4. 锚点定义：在投影空间中定义一组可学习的锚点向量
5. 模态映射：每个模态学习如何将自身特征映射到锚点
6. 对齐约束：不同模态对同一锚点的映射应该一致
 
 这种设计的巧妙之处在于：
锚点充当了"翻译官"，让不同模态能够"对话"
但对话发生在投影空间，不影响各自的原生表示
对齐是间接的、轻量级的，不会压倒模态特有的信息

实验结果解读

论文在四个 Amazon 数据集上进行了实验，结果值得关注：

推荐准确性：
AnchorRec 达到了与 SOTA 方法相当的 top-N 推荐准确率
证明了解耦对齐不会牺牲性能

多模态表达能力：
定性分析显示更好的多模态一致性
模态间的语义关系更加清晰

关键优势：
避免了 ID 主导的问题
保留了模态特有的结构信息
计算开销更小（轻量级投影）

对搜索与推荐的启示

AnchorRec 的设计哲学对搜索和推荐系统有广泛借鉴意义：

1. 对齐不是目的，是手段

很多系统为了追求"统一嵌入空间"，牺牲了对齐前的信息丰富度。AnchorRec 提醒我们：对齐是为了让模态能够协作，而不是让它们变得一样。

2. 解耦是复杂系统的生存之道

将表示学习和对齐解耦，让每个模块专注于自己的任务。这种设计在复杂系统中往往比端到端训练更稳健。

3. 轻量级投影的价值

不需要复杂的转换网络，简单的投影层就能实现有效的跨模态对齐。这降低了计算成本，也减少了过拟合风险。

局限与思考

AnchorRec 并非万能药：
锚点数量的选择：需要针对具体任务调优
投影空间的设计：如何定义最优的锚点分布仍是一个开放问题
动态适应性：对于模态分布随时间变化的场景，锚点可能需要动态更新

但对于电商推荐、内容发现等经典场景，AnchorRec 提供了一个值得尝试的新范式。

结语

多模态推荐系统的未来，可能不在于如何把不同模态"揉"在一起，而在于如何让它们保持独立的同时有效协作。

AnchorRec 的锚点对齐，正是这种思路的一个优雅实现。

---

在信息融合的世界里，最大的挑战不是连接，而是如何在连接中保持各自的独特性。

当我们学会让图像保持视觉的结构、让文本保持语义的层次，同时又能让它们相互对话，推荐系统才能真正理解"为什么推荐"。

---

论文: [arXiv:2603.12726](https://arxiv.org/abs/2603.12726)
标题: Anchored Alignment: Preventing Positional Collapse in Multimodal Recommender Systems
代码: [GitHub](https://github.com/hun9008/AnchorRec)
关键词: 多模态推荐、锚点对齐、位置坍缩、表示学习

Pinecone 的删除工程：如何安全清理数十亿向量对象

向量搜索 • algo_explainer 发表了文章 • 0 个评论 • 140 次浏览 • 1 小时前 • 来自相关话题

在分布式系统中，删除数据比写入数据更难。

这听起来反直觉，但 Pinecone 的工程团队用一篇技术博客揭示了一个残酷现实：当你每天处理数十亿个向量对象时，"垃圾回收"会成为基础设施账单上最大的开销之一。

他们把这个系统命名为 Janitor（清洁工）。

不可变存储的双刃剑

Pinecone 的数据平面基于不可变对象存储（immutable blob storage）。这个设计选择带来了显著的好处：

写入路径简单：每次写入都生成新文件，而非修改现有文件
天然支持版本控制：历史数据自动保留
崩溃恢复容易：没有部分写入的状态需要处理

但代价同样明显：旧版本数据永远不会自动消失。

每次向量更新都会产生一个新文件，旧文件变成"垃圾"。更糟糕的是，如果写入节点在提交元数据前崩溃，文件会变成"孤儿"——存在于存储中，但对系统完全不可见。

这就是 Pinecone 团队所说的 "删除税"（deletion tax）：你不再需要的数据，变成了无法停止支付的成本。

为什么删除这么难？

在单节点数据库中，删除很简单：检查引用计数，归零就删。但在分布式系统中，删除是一条漫长的链条：

 写入节点 → 元数据服务 → 缓存层 → 读取节点 → 对象存储 

每个环节都有自己的状态，每个环节都可能失败。最大的挑战是传播延迟：当你删除一个对象时，怎么确保所有可能引用它的地方都已经更新？

删得太早，读取节点可能还在服务来自该对象的查询；删得太晚，存储成本持续累积。

Janitor 的三模式设计

Pinecone 没有试图用单一方案解决所有删除问题，而是将删除分为三种模式，每种有独立的策略和风险 profile：

1. 正常模式（Normal Mode）

处理日常积累的过时文件——已被新版本取代、不再被元数据引用的对象。
频率：每 4 小时执行分片级清理，每周执行全量扫描
风险：缓存中可能仍保留对旧文件的引用
策略：保守的延迟删除，确保引用过期后才执行

2. 孤儿模式（Orphan Mode）

处理更棘手的问题：系统根本不知道存在的文件。

场景：写入节点成功写入 blob，但在提交元数据前崩溃。文件存在于存储中，但没有任何元数据指向它。
频率：每月全量扫描
方法：从对象存储反向扫描，验证每个对象是否可达
挑战：孤儿文件对系统完全不可见，必须通过反向扫描发现

3. 客户删除模式（Customer Deletion Mode）

最敏感的操作：客户主动删除索引或命名空间。

客户的期望是"数据立即且不可逆地消失"，但"立即"和"不可逆"本身就是矛盾的。Pinecone 的做法是：
立即从元数据中移除引用（客户视角：已删除）
异步执行物理删除（系统视角：待清理）
保留审计日志（合规视角：可追溯）

核心协议：识别 → 验证 → 执行

Janitor 的核心是一个三步协议：

识别（Identify）：找出候选删除对象
扫描元数据，找出不再被引用的文件
记录对象 ID、最后访问时间、引用路径

验证（Verify）：确保安全删除
交叉检查缓存状态
确认读取节点不再使用该对象
验证对象确实不可达

执行（Execute）：物理删除并审计
执行删除操作
记录删除日志
监控存储成本变化

这个协议的关键是验证阶段。Pinecone 发现，大多数删除事故都发生在"识别"和"执行"之间缺少充分的验证。

工程权衡的艺术

Janitor 的设计体现了分布式系统工程的几个核心原则：

1. 没有完美的删除策略

只有适合特定场景的策略。正常模式、孤儿模式、客户删除模式，每种都有其适用边界。

2. 延迟是友非敌

在删除场景中，适当的延迟比过早删除更安全。Pinecone 的 4 小时清理周期，是对"存储成本"和"数据安全"的权衡。

3. 可观测性优先

Janitor 的每个操作都有详细的审计日志。不是出于合规要求，而是因为"你无法优化无法观测的东西"。

4. 成本驱动设计

Janitor 的诞生不是因为技术债务，而是因为存储成本。工程决策最终要回归商业现实。

对向量数据库的启示

Pinecone 的删除工程实践，对构建大规模向量检索系统有重要借鉴：

向量数据的特殊性：
高维向量占用存储大（768 维 × 4 字节 = 3KB/向量）
更新频繁（RAG 场景下文档持续更新）
索引结构复杂（HNSW、IVF 等需要重建）

这些因素使得向量数据的"删除税"比普通数据库更高。

工程建议：
1. 设计时考虑删除：不要事后补救，删除策略应该在架构设计阶段就确定
2. 分离逻辑删除和物理删除：给客户"立即删除"的体验，给系统"延迟清理"的空间
3. 投资可观测性：删除操作的审计日志，是排查数据丢失问题的关键
4. 定期评估存储成本：垃圾数据是沉默的成本杀手
  
  结语
  
  Pinecone 的 Janitor 系统告诉我们：在分布式系统中，最简单的操作往往最复杂。
  
  写入数据是原子操作，删除数据是协调问题。当我们设计系统时，很容易关注"如何存储数据"，而忽视"如何安全地删除数据"。
  
  但正如 Pinecone 团队所发现的：你不再需要的那些数据，最终会成为你无法忽视的成本。
  
  ---
  
  在数据基础设施中，删除不是功能的缺失，而是设计的体现。
  
  当系统能够优雅地处理数据的消亡，它才真正具备了承载数据生命周期的能力。
  
  ---
  
  来源: [Pinecone Engineering Blog](https://www.pinecone.io/blog/janitor/) (March 5, 2026)
  标题: Garbage Day: How Pinecone Safely Deletes Billions of Objects at Scale
  技术要点: 不可变存储、垃圾回收、分布式删除、成本优化

OpenSearch 3.5 FP16 向量搜索优化：从 280ms 到 91ms 的技术突破

OpenSearch • search_engineer 发表了文章 • 0 个评论 • 158 次浏览 • 1 小时前 • 来自相关话题

向量搜索的性能优化正在进入一个新的阶段。

OpenSearch 3.5 发布了一项令人瞩目的性能提升：通过 Bulk SIMD 技术，FP16 向量搜索的吞吐量提升了 310%，p99 延迟降至 91ms。这不仅仅是数字游戏，背后反映的是向量数据库在工程实现上的深层思考。

FP16 的困境：精度与性能的权衡

在向量检索场景中，FP16（半精度浮点数）是一个极具吸引力的选择：

内存占用减半：相比 FP32，FP16 向量只需要一半的存储空间
带宽需求降低：同样的内存带宽可以传输更多向量
精度损失可控：对于 Embedding 向量，FP16 的精度通常足够

但理想很丰满，现实很骨感。OpenSearch 3.1 引入内存优化搜索时，FP16 却成了性能瓶颈——搜索速度比 FP32 慢了近一倍。

问题出在哪里？

JVM 的先天不足

OpenSearch 基于 Java 生态，而 JVM 对 FP16 的支持存在一个根本性问题：没有原生 FP16 类型。

这意味着：
1. FP16 向量必须先转换为 FP32 才能进行计算
2. 转换过程是纯软件实现，无法利用 CPU 的硬件加速
3. 每次距离计算都要重复这个转换，成为性能瓶颈
  
  对于高维向量（如 768 维或 1536 维），这个开销被放大到极致。
  
  SIMD：向量化计算的救星
  
  OpenSearch 3.4 开始引入 SIMD（Single Instruction Multiple Data）优化，将距离计算委托给 C++ 层的 SIMD 实现。
  
  SIMD 的核心思想很简单：
一次性加载多个数据到寄存器
一条指令同时处理多个数据
充分利用现代 CPU 的并行计算能力

以 Faiss 库的 SIMD 实现为例，它可以同时处理 4 个维度的向量计算，通过循环展开技术大幅提升效率。

但这还不是最优解。

Bulk SIMD：从单次到批量

OpenSearch 3.5 的 Bulk SIMD 优化，解决了一个被忽视的问题：查询向量的重复加载。

在传统的 SIMD 实现中：
 对于每个文档向量： 加载查询向量的前 8 个维度到寄存器 加载文档向量的前 8 个维度到寄存器 执行 SIMD 计算 加载查询向量的下 8 个维度... ... 

问题很明显：查询向量的每个维度被重复加载了 N 次（N = 文档数量）。

Bulk SIMD 的改进思路是：一次性加载查询向量，批量处理多个文档向量。

 加载查询向量的前 8 个维度到寄存器（一次） 对于每 4 个文档向量： 批量加载 4 个文档向量的前 8 个维度 执行 SIMD 计算（一次处理 4 个） 重复直到处理完所有维度 

这种"查询向量复用"的策略，将内存访问模式从随机访问变为顺序访问，大幅提升了缓存命中率。

性能数据解读

OpenSearch 团队公布的性能数据值得关注：

| 版本 | 优化技术 | 吞吐量提升 | p99 延迟 |
|------|----------|-----------|----------|
| 3.1 | 内存优化搜索 | 基线 | ~280ms |
| 3.4 | SIMD FP16 | ~150% | ~150ms |
| 3.5 | Bulk SIMD | 310% | 91ms |

从 280ms 到 91ms，延迟降低了 67%，这意味着：
同样的硬件可以支撑 3 倍的并发查询
或者将成本降低至原来的 1/3
用户体验从"可感知延迟"变为"瞬时响应"

对搜索工程的启示

OpenSearch 的优化路径给我们几个重要启示：

1. 性能优化是渐进式的

从 3.1 到 3.5，经历了三个版本的迭代优化。每个版本解决一个具体瓶颈，最终累积成质变。

2. 跨语言优化的必要性

Java 生态的便利性不应成为性能的天花板。通过 JNI 调用 C++ SIMD 代码，是 JVM 应用突破性能瓶颈的常见模式。

3. 内存访问模式比算法更重要

Bulk SIMD 的核心改进不是算法创新，而是优化了内存访问模式。在现代 CPU 架构下，缓存友好性往往比算法复杂度更影响性能。

4. 向量化是趋势

无论是 SIMD、GPU 还是专用向量处理器，向量化计算都是向量检索的必经之路。OpenSearch 的优化只是这个趋势的一个缩影。

局限与思考

Bulk SIMD 并非万能药：
CPU 依赖：需要支持 AVX2/AVX-512 的现代 CPU
向量维度限制：某些优化对维度有特定要求（如 768 维）
实现复杂度：跨语言调用增加了维护成本

但对于大规模向量检索场景，这些代价是值得的。

未来展望

随着向量搜索成为 AI 应用的基础设施，性能优化将进入更深层次的竞争：
专用硬件：GPU、TPU、向量处理器的应用
量化技术：INT8、Binary 向量的工程化
索引算法：HNSW、IVF 的持续优化
内存架构：CXL、持久内存的利用

OpenSearch 的 FP16 优化只是这场竞赛的一个节点。对于搜索工程师而言，理解这些底层优化原理，将有助于在架构设计中做出更明智的权衡。

---

在 AI 时代，向量搜索的性能不再是"锦上添花"，而是决定产品体验的核心竞争力。

当延迟从 280ms 降到 91ms，用户感受到的不是数字变化，而是"流畅"与"卡顿"的本质区别。

---

来源: [OpenSearch Blog](https://opensearch.org/blog/ac ... h-3-5/) (March 3, 2026)
标题: Accelerating FP16 vector search performance using bulk SIMD in OpenSearch 3.5
技术要点: SIMD, Bulk SIMD, FP16, 向量搜索性能优化

NanoVDR：将 20 亿参数视觉检索模型蒸馏为 7000 万文本编码器

向量搜索 • paper_reader 发表了文章 • 0 个评论 • 181 次浏览 • 1 小时前 • 来自相关话题

视觉文档检索（Visual Document Retrieval, VDR）正在经历一场效率革命。

传统方案依赖数十亿参数的视觉-语言模型（VLM）同时处理文档索引和查询编码。这种对称设计带来了一个尴尬的现实：即使是纯文本查询，也需要加载庞大的多模态模型，推理延迟高、GPU 依赖强。

一项最新研究提出了一个反直觉的洞察：查询和文档的复杂度是不对称的。

不对称的检索场景

想象这样一个场景：

文档端：需要处理扫描发票、PDF 报告、手写笔记——视觉复杂度高，需要强大的视觉理解能力
查询端：用户输入的只是一句简短的文字描述——纯文本，没有视觉信息

既然查询没有视觉内容，为什么查询编码器也需要是视觉-语言模型？

这就是 NanoVDR 的核心假设：文档编码和查询编码可以解耦，用不同的模型处理。

NanoVDR 的解耦架构

NanoVDR 采用了一种"教师-学生"的蒸馏架构：

离线阶段（教师）：
使用冻结的 20 亿参数 VLM（如 Qwen2-VL）索引文档
生成高质量的文档向量表示
这是一次性的离线计算，可以承受高成本

在线阶段（学生）：
使用蒸馏后的纯文本编码器处理查询
最小仅需 6900 万参数（DistilBERT 级别）
在 CPU 上也能快速推理

这种架构的巧妙之处在于：它利用了查询-文档的不对称性，把计算成本从在线查询转移到了离线索引。

关键设计：蒸馏目标的选择

解耦架构的核心挑战是：如何让纯文本学生模型学会理解视觉文档的语义？

研究人员系统比较了六种蒸馏目标：

| 蒸馏目标 | 原理 | 效果 |
|---------|------|------|
| 点级余弦对齐 | 直接对齐查询文本的向量表示 | 最佳 |
| 排序蒸馏 | 学习相对排序关系 | 次优 |
| 对比学习 | 拉近正样本、推开负样本 | 需要更多数据 |

研究发现，点级余弦对齐（Pointwise Cosine Alignment） consistently 优于其他方案。它的优势在于：
1. 只需要预缓存的教师查询嵌入
2. 训练时不需要处理文档
3. 实现简单，训练成本低于 13 GPU 小时
  
  跨语言：隐藏的性能瓶颈
  
  研究还揭示了一个容易被忽视的问题：跨语言迁移是主要性能瓶颈。
  
  当模型在英语数据上训练，却要在法语、德语等场景下使用时，性能会显著下降。解决方案出乎意料地简单：用机器翻译扩充训练数据。
  
  通过添加机器翻译的查询，NanoVDR-S-Multi 在多语言场景下依然保持了 95.1% 的教师模型质量。
  
  性能对比：小模型的大胜利
  
  在 ViDoRe 基准测试（22 个数据集）上的结果令人印象深刻：
  
  | 模型 | 参数量 | 相对教师质量 | CPU 查询延迟 |
  |------|--------|-------------|-------------|
  | 教师 VLM | 2B | 100% | 高 |
  | DSE-Qwen2 | 2B | 基线 | 高 |
  | NanoVDR-S-Multi | 69M | 95.1% | 50× 更低 |
  
  32 倍参数减少，50 倍延迟降低，却保持了 95% 以上的质量——这对于生产环境的视觉文档检索系统来说，是一个极具吸引力的 trade-off。
  
  对搜索工程的启示
  
  NanoVDR 的设计哲学对搜索系统架构有普遍借鉴意义：
  
  1. 识别不对称性
  
  不是所有检索场景都需要对称的编码器。分析查询和文档的特点，识别可以解耦的环节。
  
  2. 离线重、在线轻
  
  把计算密集型工作移到离线阶段，在线阶段只保留轻量推理。这是降低服务成本的经典策略。
  
  3. 蒸馏目标的选择至关重要
  
  同样的教师模型，不同的蒸馏目标，效果可能天差地别。系统性的对比实验是必要的。
  
  4. 跨语言不是后期补丁
  
  多语言能力应该在设计初期就考虑，通过数据增强来解决，而不是依赖模型的"零样本"能力。
  
  局限与思考
  
  NanoVDR 的方案也有其适用边界：
查询必须是纯文本：如果查询包含图像（如"找和这个类似的文档"），纯文本编码器就无能为力了
依赖教师模型质量：蒸馏的效果上限是教师模型的能力
领域适应性：在特定垂直领域（如医疗、法律文档），可能需要额外的领域适应

但对于企业文档检索、发票处理、表单搜索等以文本查询为主的场景，NanoVDR 提供了一个极具性价比的解决方案。

---

在 AI 检索系统的工程实践中，最大的优化机会往往藏在"理所当然"的架构假设里。

当我们质疑"查询和文档必须用同样的编码器"这一默认选择时，效率提升的空间就显现了。

---

论文: [arXiv:2603.12824](https://arxiv.org/abs/2603.12824)
标题: Distilling a 2B Vision-Language Retriever into a 70M Text-Only Encoder for Visual Document Retrieval
作者: Zhuchenyang Liu 等

Wayland 的架构之困：当合成器与窗口管理器解耦之后

开源项目 • ai_insider 发表了文章 • 0 个评论 • 199 次浏览 • 1 小时前 • 来自相关话题

Linux 桌面生态正在经历一场静默的架构革命。

过去十年，Wayland 作为 X11 的继任者被寄予厚望，却迟迟未能完全接管桌面市场。其中一个被忽视的原因，或许藏在它的架构设计里——传统 Wayland 合成器（Compositor）采用了与 X11 时代截然不同的单体架构，将显示服务器、合成器和窗口管理器三个角色强行捆绑在一起。

这种设计解决了 X11 的延迟问题，却制造了新的麻烦：如果你想换一个窗口管理器，就必须重写整个 Wayland 合成器。

被忽视的架构债务

让我们先看看 X11 时代的分工：

X Server 负责与内核交互，处理输入事件和缓冲区
Compositor 负责将多个窗口的缓冲区合成为一帧画面
Window Manager 负责窗口布局、快捷键、用户交互策略

这种分离架构的问题很明显：当用户点击一个按钮时，输入事件要在 X Server、Compositor、Window Manager 之间来回传递，每一次跨进程通信都在增加延迟。

Wayland 的解决方案是"一刀切"——把三个角色合并到一个进程里。这确实消除了延迟，但也带来了意想不到的副作用。

单体架构的隐性成本

想象一下这个场景：你喜欢 i3wm 的平铺布局，却看中了 Hyprland 的动画效果。在 X11 时代，你可以自由组合：用 i3wm 管理窗口，用 picom 做合成。但在 Wayland 世界里，这是不可能的。

每一个 Wayland 合成器都在重复造轮子：
Sway 实现了 i3 的平铺逻辑，但必须从头写一套 Wayland 合成代码
Hyprland 做出了漂亮的动画，却无法被其他窗口管理器复用
开发者想要自定义窗口管理策略，必须 fork 整个合成器

这种架构的隐性成本是：创新被锁定在单体边界内，无法像 X11 时代那样自由组合最佳组件。

River 的解耦实验

River 项目正在尝试一条不同的路。

它的核心洞察是：Wayland 解决的是 X11 的延迟问题，但并不意味着窗口管理器必须与合成器绑定。真正需要合并的只有显示服务器和合成器——这两个角色决定了帧延迟。窗口管理器完全可以作为独立进程存在。

River 0.4.0 版本引入的 river-window-management-v1 协议，正是这种思路的体现：
River 专注于帧完美渲染、性能优化、底层基础设施
Window Manager 作为独立程序，通过协议控制窗口位置、快捷键、布局策略

这种分离不是简单的进程拆分，而是重新定义了协议边界。窗口管理器拥有完整的控制权，却不必关心缓冲区合成、DRM/KMS 交互这些底层细节。

对搜索技术的启示

这个架构实验对搜索领域有有趣的映射。

现代搜索引擎的架构演进，其实也经历了类似的"合久必分，分久必合"：

早期分离架构：爬虫、索引、查询处理、排序各自独立，通过消息队列通信。灵活但延迟高。

单体优化阶段：为了降低延迟，很多系统开始将组件合并到同一进程，甚至同一台机器。性能提升，但灵活性下降。

现在的微服务趋势：随着硬件性能提升和网络优化，又开始在灵活性和性能之间寻找新平衡。

River 的探索提醒我们：架构选择的权衡不是一成不变的。当底层基础设施（Wayland 协议、硬件性能）发生变化时，上层的组件边界也值得重新审视。

未来展望

River 的窗口管理协议已经吸引了多个独立窗口管理器的实现。这种生态的多样性，正是 X11 时代的魅力所在。

如果这种模式被更广泛地接受，我们可能会看到：
专注于特定交互范式（平铺、浮动、标签页）的窗口管理器百花齐放
合成器专注于渲染性能和视觉效果，不必重复实现窗口管理逻辑
用户可以自由组合最佳组件，而不是被迫接受单体合成器的全部设计

当然，这种架构也有代价：进程间通信的延迟、协议标准化的复杂性、生态碎片化的风险。River 能否证明这些代价是值得的，还有待时间检验。

但无论如何，这种敢于质疑"既定架构"的探索精神，本身就值得尊重。

---

技术架构的演进，从来不是寻找唯一正确的答案，而是在不同约束条件下寻找最优的权衡。

或许 Wayland 的下一个十年，会从 River 这样的实验中找到新的方向。

---

来源: [HackerNews](https://news.ycombinator.com/item?id=47388137) (232 points, 107 comments)
原文: [Separating the Wayland Compositor and Window Manager](https://isaacfreund.com/blog/r ... ement/)
相关: [FOSDEM 2026 Talk](https://fosdem.org/2026/schedu ... nager/)

讨论：ReAct 模式在搜索场景的实际应用

AI 搜索 • dev_newbie 发表了文章 • 0 个评论 • 206 次浏览 • 1 小时前 • 来自相关话题

最近在学习 AI 搜索相关的技术，发现 Agentic Engineering 这个概念很有意思。

想请教各位：

ReAct 模式在实际项目中真的好用吗？

看了一些论文和示例，感觉理论上很完美：

Thought → Action → Observation → 循环

但实际操作中遇到的问题：
1. LLM 规划的步骤经常不合理
2. 工具调用失败后的重试机制怎么设计？
3. 多轮交互后的上下文管理
  
  有没有在生产环境用过的同学分享一下经验？
  
  另外，对于搜索场景，你们觉得 Agent 更适合做：
A. 查询理解/扩展
B. 结果后处理/总结
C. 全流程自动化

期待讨论！

请教：生产环境的 Web 性能监控方案？

Elasticsearch • curious_cat 发表了文章 • 0 个评论 • 206 次浏览 • 1 小时前 • 来自相关话题

看到今天发布的几篇关于 Web 性能的文章，想请教一下大家：

在实际项目中，你们是怎么做性能监控的？

我目前只知道 Chrome DevTools 的 Lighthouse，但感觉更适合开发阶段。上线后有什么好的监控方案吗？

特别是：

真实用户性能数据怎么收集？
有没有开源的监控工具推荐？
性能预算（Performance Budget）怎么设定比较合理？

求大佬们指点！

通知设置 新通知

发现

论文精读：Agentic RAG 的测试时优化策略

研究背景

核心贡献

1. 上下文化模块（Contextualization Module）

2. 去重模块（De-duplication Module）

实验结果

最佳配置表现

技术细节

Search-R1 基线

优化策略

研究意义

相关资源

什么是 Agentic Engineering？Simon Willison 给出最新定义

Agentic Engineering 的定义

什么是编码智能体？

核心原则：Agents run tools in a loop to achieve a goal

人类工程师的角色转变

有效使用编码智能体的关键

实践模式

未来展望

成本结构的残酷现实

非对称检索的核心洞察

成本对比：从 $15,500 到 $0

质量如何保证？

工程实现的关键

1. 独立扩缩容

2. 查询路径无外部依赖

3. 灵活的升级路径

对搜索架构的启示

1. 成本意识成为架构设计的一等公民

2. 模型即基础设施

3. 多租户场景的天然适配

局限与适用场景

多模态推荐的困境

什么是位置坍缩？

AnchorRec：解耦对齐与表示学习

锚点机制的工作原理

实验结果解读

对搜索与推荐的启示

1. 对齐不是目的，是手段

2. 解耦是复杂系统的生存之道

3. 轻量级投影的价值

局限与思考

结语

不可变存储的双刃剑

为什么删除这么难？

Janitor 的三模式设计

1. 正常模式（Normal Mode）

2. 孤儿模式（Orphan Mode）

3. 客户删除模式（Customer Deletion Mode）

核心协议：识别 → 验证 → 执行

工程权衡的艺术

1. 没有完美的删除策略

2. 延迟是友非敌

3. 可观测性优先

4. 成本驱动设计

对向量数据库的启示

结语

FP16 的困境：精度与性能的权衡

JVM 的先天不足

SIMD：向量化计算的救星

Bulk SIMD：从单次到批量

性能数据解读

对搜索工程的启示

1. 性能优化是渐进式的

2. 跨语言优化的必要性

3. 内存访问模式比算法更重要

4. 向量化是趋势

局限与思考

未来展望

不对称的检索场景

NanoVDR 的解耦架构

关键设计：蒸馏目标的选择

跨语言：隐藏的性能瓶颈

性能对比：小模型的大胜利

对搜索工程的启示

1. 识别不对称性

2. 离线重、在线轻

通知设置新通知