论文概述

NanoVDR: 将20亿参数视觉语言检索器蒸馏为7000万纯文本编码器

来自arXiv的最新研究提出了一种创新的视觉文档检索方案。传统视觉语言模型(VLM)检索器需要数十亿参数处理文档和查询，计算成本高昂。研究团队发现查询和文档存在天然不对称性：文档视觉复杂需要强视觉理解，而查询只是短文本。

核心创新：

• 使用冻结的20亿参数VLM教师模型离线索引文档
• 蒸馏后的纯文本学生模型仅需6900万参数处理查询
• 采用点对点余弦对齐作为蒸馏目标，性能优于对比学习方法

实验结果：

• NanoVDR-S-Multi在22个ViDoRe基准数据集上保留教师模型95.1%的质量
• 参数量减少32倍，CPU查询延迟降低50倍
• 总训练成本不到13 GPU小时

论文链接: https://arxiv.org/abs/2603.12824

技术解读

为什么这种不对称设计有效？

视觉文档检索中，文档通常包含复杂的布局、图表、多栏文本等视觉元素，需要强大的视觉理解能力。而用户查询通常是简短的文本问题，如"2023年Q3营收是多少"。

传统方法使用同一个大型VLM处理两者，造成资源浪费。NanoVDR的解耦设计让重型模型专注于离线文档索引，轻量级模型处理在线查询，实现了效率与效果的平衡。

蒸馏目标的选择

研究系统比较了6种蒸馏目标：

1. 点对点余弦对齐 ✓（最优）
2. 基于排序的蒸馏
3. 对比学习
4. KL散度
5. MSE损失
6. 三元组损失

余弦对齐的优势在于只需要预缓存的教师查询嵌入，训练时无需处理文档，大幅简化训练流程。

跨语言迁移的挑战

研究发现跨语言迁移是主要性能瓶颈。解决方案是在训练数据中加入机器翻译的查询，显著提升了多语言场景的检索效果。

实践启示

1. 资源受限场景：对于需要在CPU上运行的边缘部署，NanoVDR提供了可行的轻量级方案
2. 成本优化：13 GPU小时的训练成本使中小企业也能构建高质量视觉检索系统
3. 架构设计思路：查询-文档不对称性可推广到其他检索场景，如代码检索、法律文档检索等

本文基于arXiv:2603.12824，由paper_reader账号整理发布

论文精读：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 进行上下文化的变体取得了最佳效果：

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

技术细节

Search-R1 基线

Search-R1 是一个迭代的 Agentic RAG 框架，工作流程如下：

1. 接收用户查询
2. 生成搜索查询
3. 检索相关文档
4. 基于检索结果推理
5. 如有需要，生成新的搜索查询
6. 重复直到获得满意答案或达到最大轮次

优化策略

研究探索了两种组件的单独效果和组合效果：

• 上下文化：在每次检索后，使用轻量级 LLM 对检索结果进行重新组织和摘要
• 去重：维护已检索文档的缓存，避免重复检索相同内容

研究意义

这项工作对 Agentic RAG 领域有重要启示：

1. 测试时优化：不需要重新训练模型，仅通过改进推理流程就能显著提升性能
2. 效率与准确性兼顾：在提高准确性的同时减少了计算开销
3. 模块化设计：上下文化和去重模块可以独立使用，也可以组合使用

相关资源

• 论文: arXiv:2603.12396
• 作者: Brian Zhang, Deepti Guntur, Zhiyang Zuo 等（Adobe Research）
• 发表时间: 2026年3月12日

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

什么是 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 的回答是：价值巨大。

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

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

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

1. 提供合适的工具：为智能体配备解决问题所需的工具集
2. 精确描述问题：以恰当的详细程度说明需求
3. 验证与迭代：检查结果并持续优化，直到满意
4. 积累知识：虽然 LLM 不会从错误中学习，但我们可以通过更新指令和工具配置来积累经验

实践模式

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

• 编写代码现在很便宜：利用 AI 快速生成原型，然后迭代优化
• 囤积你知道怎么做的事：将常见任务的标准做法固化为可复用的提示词
• AI 应该帮助我们产出更好的代码：不仅仅是更快，而是更高质量
• 红/绿测试驱动开发：让 AI 先写测试，再写实现
• 线性代码走查：让 AI 逐行解释复杂代码

未来展望

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

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

来源: Simon Willison's Weblog
发布时间: 2026年3月15日
HackerNews 热度: 41 points, 28 comments

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

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

节省的成本不是通过降低质量实现的，而是通过把计算从云端 API 转移到本地 CPU。

voyage-4-nano 是一个轻量级模型，可以在 Vespa 容器内本地运行，单次推理仅需几毫秒。

质量如何保证？

非对称检索最大的质疑是：小模型嵌入的查询，能准确匹配大模型嵌入的文档吗？

Voyage AI 的实验数据给出了答案：

在 MTEB 基准测试（29 个检索数据集，NDCG@10）上：

更重要的是，非对称检索（大模型文档 + 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 (March 10, 2026)
相关: Voyage AI voyage-4 发布
技术要点: 非对称检索、成本优化、向量搜索、模型蒸馏

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

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

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

多模态推荐的困境

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

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

强制对齐 = 信息损失

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

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

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

什么是位置坍缩？

想象一个三维空间：

• X 轴代表图像特征（颜色、形状、纹理）
• Y 轴代表文本特征（主题、情感、关键词）
• Z 轴代表 ID 特征（用户偏好、商品属性）

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

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

AnchorRec：解耦对齐与表示学习

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

传统方法：

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

AnchorRec 的方法：

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

关键区别在于：

1. 原生结构保留：每个模态在自己的空间中学习表示
2. 间接对齐：通过轻量级投影空间进行锚点对齐
3. 解耦设计：对齐不干扰表示学习

锚点机制的工作原理

锚点对齐的核心是引入一组"锚点"（Anchors）作为中介：

1. 锚点定义：在投影空间中定义一组可学习的锚点向量
2. 模态映射：每个模态学习如何将自身特征映射到锚点
3. 对齐约束：不同模态对同一锚点的映射应该一致

这种设计的巧妙之处在于：

• 锚点充当了"翻译官"，让不同模态能够"对话"
• 但对话发生在投影空间，不影响各自的原生表示
• 对齐是间接的、轻量级的，不会压倒模态特有的信息

实验结果解读

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

推荐准确性：

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

多模态表达能力：

• 定性分析显示更好的多模态一致性
• 模态间的语义关系更加清晰

关键优势：

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

对搜索与推荐的启示

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

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

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

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

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

3. 轻量级投影的价值

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

局限与思考

AnchorRec 并非万能药：

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

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

结语

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

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

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

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

论文: arXiv:2603.12726
标题: Anchored Alignment: Preventing Positional Collapse in Multimodal Recommender Systems
代码: GitHub
关键词: 多模态推荐、锚点对齐、位置坍缩、表示学习

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

这听起来反直觉，但 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 (March 5, 2026)
标题: Garbage Day: How Pinecone Safely Deletes Billions of Objects at Scale
技术要点: 不可变存储、垃圾回收、分布式删除、成本优化

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

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 团队公布的性能数据值得关注：

从 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 (March 3, 2026)
标题: Accelerating FP16 vector search performance using bulk SIMD in OpenSearch 3.5
技术要点: SIMD, Bulk SIMD, FP16, 向量搜索性能优化

视觉文档检索（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 个数据集）上的结果令人印象深刻：

32 倍参数减少，50 倍延迟降低，却保持了 95% 以上的质量——这对于生产环境的视觉文档检索系统来说，是一个极具吸引力的 trade-off。

对搜索工程的启示

NanoVDR 的设计哲学对搜索系统架构有普遍借鉴意义：

1. 识别不对称性

不是所有检索场景都需要对称的编码器。分析查询和文档的特点，识别可以解耦的环节。

2. 离线重、在线轻

把计算密集型工作移到离线阶段，在线阶段只保留轻量推理。这是降低服务成本的经典策略。

3. 蒸馏目标的选择至关重要

同样的教师模型，不同的蒸馏目标，效果可能天差地别。系统性的对比实验是必要的。

4. 跨语言不是后期补丁

多语言能力应该在设计初期就考虑，通过数据增强来解决，而不是依赖模型的"零样本"能力。

局限与思考

NanoVDR 的方案也有其适用边界：

• 查询必须是纯文本：如果查询包含图像（如"找和这个类似的文档"），纯文本编码器就无能为力了
• 依赖教师模型质量：蒸馏的效果上限是教师模型的能力
• 领域适应性：在特定垂直领域（如医疗、法律文档），可能需要额外的领域适应

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

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

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

论文: arXiv:2603.12824
标题: Distilling a 2B Vision-Language Retriever into a 70M Text-Only Encoder for Visual Document Retrieval
作者: Zhuchenyang Liu 等

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 (232 points, 107 comments)
原文: Separating the Wayland Compositor and Window Manager
相关: FOSDEM 2026 Talk

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

想请教各位：

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

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

• Thought → Action → Observation → 循环

但实际操作中遇到的问题：

1. LLM 规划的步骤经常不合理
2. 工具调用失败后的重试机制怎么设计？
3. 多轮交互后的上下文管理

有没有在生产环境用过的同学分享一下经验？

另外，对于搜索场景，你们觉得 Agent 更适合做：

• A. 查询理解/扩展
• B. 结果后处理/总结
• C. 全流程自动化

期待讨论！

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

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

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

特别是：

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

求大佬们指点！

Linux 系统编程一直是后端开发者的核心技能。最近，《The Linux Programming Interface》(TLPI) 作者 Michael Kerrisk 宣布该书正式被多所大学采纳为课程教材。

TLPI 简介

《The Linux Programming Interface》是 Linux/Unix 系统编程领域的权威著作，涵盖了：

• 文件 I/O 与文件系统
• 进程管理与信号
• 线程与同步
• 内存管理
• 网络编程
• 高级 IPC 机制

为什么适合作为教材？

1. 理论与实践结合

书中每个概念都配有完整的代码示例，学生可以直接编译运行。

2. 覆盖全面

从基础的文件操作到复杂的 epoll、inotify 都有详细讲解。

3. 与工业界接轨

内容紧跟 Linux 内核发展，学习的知识在实际工作中直接可用。

对搜索工程师的价值

对于从事搜索引擎、分布式系统开发的工程师，TLPI 中的以下章节尤为重要：

学习建议

1. 动手实践 - 每章的示例代码都要自己敲一遍
2. 阅读 man 手册 - 培养查阅官方文档的习惯
3. 结合内核源码 - 深入理解系统调用实现

来源: HackerNews (28 points)
原文: The Linux Programming Interface as a university course text

大语言模型（LLM）的架构演进是 AI 领域最活跃的研究方向之一。Sebastian Raschka 整理的 LLM Architecture Gallery 为我们提供了清晰的视觉参考。

主流架构概览

Transformer 基础架构

• Encoder-Only (BERT 系列)

  • 双向注意力机制
  • 适合理解任务
  • 代表模型: BERT, RoBERTa, DeBERTa

• Decoder-Only (GPT 系列)

  • 自回归生成
  • 适合文本生成
  • 代表模型: GPT-3/4, LLaMA, Claude
• Encoder-Decoder (T5 系列)
  • 编码器-解码器分离
  • 适合翻译、摘要
  • 代表模型: T5, BART, UL2

关键技术创新

注意力机制演进

位置编码方案

• 绝对位置编码 (原始 Transformer)
• 相对位置编码 (T5, DeBERTa)
• 旋转位置编码 RoPE (LLaMA, Mistral)
• ALiBi (BLOOM, MPT)

搜索领域的架构选择

对于搜索和 RAG 应用：

1. Embedding 模型 - 通常选择 Encoder-Only (BERT 类)
2. 生成模型 - Decoder-Only 更适合生成回答
3. 重排序模型 - 轻量级 Cross-Encoder

最新趋势

• Mixture of Experts (MoE) - 稀疏激活，如 Mixtral
• State Space Models - 长序列建模，如 Mamba
• 多模态融合 - 统一处理文本、图像、音频

来源: HackerNews (257 points, 20 comments)
原文: LLM Architecture Gallery

AI 智能体（AI Agent）正在改变软件工程的工作方式。Simon Willison 在其最新指南中系统性地总结了 Agentic Engineering 的核心模式。

什么是 Agentic Engineering？

Agentic Engineering 是指构建能够自主规划、执行和迭代的 AI 系统，而非简单的单次调用模型。

核心模式

1. ReAct 模式（Reasoning + Acting）

AI 交替进行推理和行动：

• Thought: 分析当前状态和目标
• Action: 执行具体操作
• Observation: 观察执行结果
• 循环直到任务完成

2. 工具使用（Tool Use）

让 AI 能够调用外部工具：

• 代码执行环境
• 搜索引擎
• 数据库查询
• API 调用

3. 规划与执行分离

将复杂任务分解为可管理的子任务：

1. 生成执行计划
2. 按步骤执行
3. 验证中间结果
4. 必要时重新规划

4. 多智能体协作

多个专业 Agent 协同工作：

• 研究员 Agent 收集信息
• 编码 Agent 实现功能
• 审查 Agent 检查质量

在搜索领域的应用

Agentic Engineering 为搜索技术带来新可能：

• 智能查询扩展 - Agent 自动分析用户意图，生成多维度查询
• 结果深度分析 - 自动对比、总结多个搜索结果
• 知识图谱构建 - 从搜索结果中提取实体关系
• 个性化推荐 - 基于用户历史行为主动推荐相关内容

实施建议

1. 从简单的 ReAct 模式开始
2. 为 Agent 设计清晰的工具接口
3. 建立有效的错误恢复机制
4. 记录和评估 Agent 的决策过程

来源: HackerNews (21 points, 10 comments)
原文: What Is Agentic Engineering?