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

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 查询语言文档

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

在搜索引擎领域，压缩算法的选择一直是一个经典的权衡难题：

• 选择高压缩率（如 best_compression / DEFLATE），磁盘省了，但查询解压慢；
• 选择高速编码（如默认 LZ4），查询快了，但磁盘占用大。

Easysearch 引入了基于 JDK 21 FFM（Foreign Function & Memory API） 直连本地 ZSTD 动态库的加速方案，试图打破这一困局。为了验证效果，我们在完全对等的环境下，对 Easysearch（ZSTD）和 Elasticsearch 7.10.2（best_compression）进行了一次严格的查询吞吐对比测试。

结果令人振奋——即使在系统明显背景负载下，Easysearch 也没有因为高压缩而变慢，反而在查询吞吐上实现了近 5 倍提升。

测试环境

为确保对比公平，两套集群的硬件资源、JVM 配置、数据规模、索引结构完全对齐：

压缩机制对比：best_compression 映射到 Lucene BEST_COMPRESSION；在 stored fields 路径上，压缩实现为 DeflateWithPresetDictCompressionMode，内部使用 java.util.zip.Deflater/Inflater（即 DEFLATE）。 Easysearch ZSTD 当前走 JDK 21 FFM 绑定本地 zstd 库（java.lang.foreign）；index.compression.zstd.jni=true 为当前这套实现的启用方式。

查询模型：JMeter 随机 match 查询，随机命中 service_name、method、error_code、url 四个字段，每次返回 10 条文档。

压测起始负载（_cat/nodes 快照）：

说明：压测并非在空闲机上进行，而是在已有明显背景负载的生产式环境下完成。

核心结果

1. 查询吞吐量（QPS）：在高背景负载下，Easysearch 仍领先 372%

稳态阶段（3 轮平均），Easysearch 的查询吞吐是 Elasticsearch 的 4.7 倍：

注：压测期间服务器存在明显背景负载（其他进程占用较高），该 CPU 指标是系统总占用，不等价于“仅搜索进程”的纯业务 CPU 对比。

在系统总 CPU 均接近 90% 的背景下，Easysearch 仍达到接近 5 倍吞吐。

2. 响应时间：从近 1 秒降到 164 毫秒

用户体感上，这意味着：同样一个搜索请求，Elasticsearch 还在等解压，Easysearch 已经把结果送到了客户端。

3. 各轮次详细数据

4. CPU 使用效率：每 1% CPU 产出的 QPS 差距惊人

单看 CPU 占用率，两者似乎差不多（89.59% vs 92.43%）。但如果换一个视角——每消耗 1% CPU 能产出多少 QPS，差距就一目了然了：

这意味着什么？

• ES 使用 DEFLATE（best_compression）时，解压路径更可能成为 CPU 热点；结合 ES 的高 CPU（92.43%）与较低 QPS，说明单位 CPU 产出偏低；
• Easysearch 使用 ZSTD（JDK21 FFM/native）时，解压开销更小；在相近 CPU 水位（89.59%）下获得更高 QPS，单位 CPU 产出明显更高。

换句话说，当前这组实测更支持“ZSTD 在该查询模型下单位 CPU 产出更高”。

5. 存储空间：ZSTD 并未膨胀

两者存储空间接近。若按 _cat/indices 的 1 位小数展示是 1.8GB vs 1.9GB；若按 _stats/store 字节值计算，差异约 2.5%。因此可以认为 ZSTD 在 level=3 下与 DEFLATE best_compression 压缩率接近。

为什么 ZSTD 能做到"又小又快"？

传统认知中，压缩率和解压速度是一对矛盾。但 ZSTD 算法天然具备非对称压缩的特性：

在搜索引擎场景中，查询会触发存储字段（_source）读取与解压路径，命中文件系统页缓存时，可能不发生实际磁盘 I/O，但仍需进行 _source 解压。 当查询涉及较多 _source 读取时：

• DEFLATE 的解压开销成为 CPU 瓶颈，拖慢了整体吞吐；
• ZSTD（JDK21 FFM/native） 的解压速度在该场景下明显更优，单次请求的解压 CPU 成本更低，从而释放出更多 CPU 资源用于并发查询处理。

这就是为什么 Easysearch 在 CPU 占用更低（89.59% vs 92.43%）的情况下，反而能处理近 5 倍的查询量。

一张图总结

结论

Easysearch 的 ZSTD 压缩方案证明了一个事实：即使在高背景负载下，高压缩率和高查询性能依然可以兼得。

在 1000 万条 nginx 日志、且系统存在明显背景负载的实测中：

• 查询吞吐提升 372%，从 533 QPS 跃升至 2518 QPS
• 平均响应时间下降 79%，从 779ms 降至 164ms
• CPU 使用效率提升 388%，每 1% CPU 产出 28.10 QPS vs 5.76 QPS
• CPU 占用绝对值下降 2.84 个百分点（相对下降约 3.07%）
• 磁盘占用与 DEFLATE best_compression 接近（按字节口径约 +2.5%）

对于日志分析、可观测性、安全审计等需要兼顾存储成本和查询性能的场景，Easysearch ZSTD 是一个不需要妥协的选择。

ZSTD 使用方法

1) 新建索引时启用 ZSTD

curl -k -u 'admin:<password>' -X PUT 'https://127.0.0.1:9200/<index-name>' \
  -H 'Content-Type: application/json' -d '{
    "settings": {
      "index.codec": "ZSTD",
      "index.compression.zstd.jni": true
    }
  }'

可选参数：

• index.compression.zstd.level（默认 3）

说明：

• index.compression.zstd.dict 固定为 true，无需单独配置
• index.compression.zstd.dict 不作为独立开关来调整

2) 老索引切换到 ZSTD（推荐 reindex）

index.codec 是静态设置（打开状态不可动态改；可在关闭索引后调整）。
index.compression.zstd.jni 是 final 设置（关闭索引后也不可修改）。
如果老索引要启用 index.compression.zstd.jni=true，建议新建目标索引后 reindex 迁移： 如果对已有索引执行 PUT /<index-name>/_settings 直接修改，会报错：final <index-name> setting [index.compression.zstd.jni], not updateable。

# 先创建目标索引（启用 ZSTD）
curl -k -u 'admin:<password>' -X PUT 'https://127.0.0.1:9200/<target-index>' \
  -H 'Content-Type: application/json' -d '{
    "settings": {
      "index.codec": "ZSTD",
      "index.compression.zstd.jni": true
    }
  }'

# 再迁移数据
curl -k -u 'admin:<password>' -X POST 'https://127.0.0.1:9200/_reindex' \
  -H 'Content-Type: application/json' -d '{
    "source": { "index": "<source-index>" },
    "dest":   { "index": "<target-index>" }
  }'

3) 校验是否生效

curl -k -u 'admin:<password>' \
  'https://127.0.0.1:9200/<index-name>/_settings?include_defaults=true&pretty'

重点确认：

• index.codec = ZSTD
• index.compression.zstd.jni = true

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：https://docs.infinilabs.com/easysearch

作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。

相关文章：

• Easysearch 2.0.0 性能测试
• Easysearch 压缩模式深度比较：ZSTD + source_reuse 的优势分析
• Easysearch 压缩功能的显著提升：从 8.7GB 到 1.4GB

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 推荐系统的公平性优化提供了一个实用且低成本的切入点，值得在工业落地中尝试。

标题：Meilisearch 2026年3月更新解读：分布式搜索迈入新纪元，AI性能大幅提升

正文：

更新概览

2026年3月，Meilisearch 带来了一系列令人振奋的产品更新。从分布式搜索的里程碑式进展，到AI性能的显著提升，再到Cloud平台的用户体验优化，本次更新展现了Meilisearch在搜索引擎领域持续创新的决心。本文将深入解析这些重要改进，帮助开发者更好地理解和应用这些新特性。

主要功能改进

1. 分布式搜索：复制分片正式进入引擎

本次更新最重磅的消息是 v1.37 版本将复制分片（Replicated Sharding）功能直接集成到 Meilisearch 引擎中。这是实现分布式、弹性搜索架构的最重要一步，也是通往Cloud平台一键复制功能的直接基石。

关键特性：

• 复制功能现已内置在引擎层面
• 目前面向企业版（Enterprise Edition）用户开放
• Cloud UI 的一键设置功能即将推出

这一进展意味着Meilisearch正在从单节点搜索引擎向真正的分布式架构演进，为高可用性和大规模搜索场景奠定了坚实基础。

2. 排名规则精细化控制

v1.36 版本引入了两个全新的排名规则，为搜索相关性调优提供了更精细的控制能力：

此前，attribute 排名规则将这两种行为固定绑定在一起。现在开发者可以独立使用它们，并能更灵活地在排名管道中插入自定义规则（如价格、发布日期等）。

3. Cloud 平台用户体验升级

Meilisearch Cloud 在本月迎来了三项实用功能：

• AI Prompt 生成器：直接在Cloud UI中生成高质量的AI搜索提示词，减少反复调试的时间成本
• 文档删除功能：无需调用API，直接在Cloud界面中删除索引文档，便于快速清理和内容管理
• 索引统计信息：直观展示索引大小、文档数量和字段分布，帮助用户更好地理解和维护数据健康

4. 搜索性能分析工具

新增的 showPerformanceDetails 参数让开发者能够获取搜索查询各阶段的时间消耗明细。这一功能极大地简化了慢查询的调试工作，使搜索性能优化变得更加透明和可控。

AI性能提升详情

HNSW 向量存储全面稳定化

Meilisearch 已完全迁移至基于 HNSW（Hierarchical Navigable Small World）算法的向量存储后端（代号 Hannoy）：

• 旧的 vectorStoreSetting 实验性功能已被永久移除
• 无停机升级过程中，引擎会自动将索引迁移到新后端
• 新建索引默认使用 HNSW 存储，带来更优的嵌入性能和一致性

v1.38 嵌入性能重大突破

v1.38 版本在AI嵌入索引性能方面实现了显著提升：

1. 极速嵌入更新：消除了添加或更新嵌入时不必要的全库扫描，大规模索引的嵌入添加效率大幅提升
2. 远程嵌入器稳定性修复：解决了使用远程嵌入器时偶发的 "connection reset by peer" 错误，显著提升了AI搜索工作流的稳定性
3. 任务删除优化：修复了任务和批量删除操作中的长期边缘案例问题

升级建议：向量搜索用户强烈建议升级至 v1.38，该版本包含重要的性能改进和可靠性修复，且完全向后兼容。

未来规划

Meilisearch 团队正在开发 Cloud UI 中更便捷的聊天设置配置方式，预计将在近期推出。

未来展望

Meilisearch 的发展路线图显示出清晰的技术演进方向：

1. 分布式架构深化：复制分片功能的引擎内集成只是开始，未来将在Cloud平台实现真正的一键分布式部署
2. AI搜索体验优化：从Prompt生成器到聊天设置简化，Meilisearch正在降低AI搜索的使用门槛
3. 社区生态建设：Meilisearch 已正式加入 Rust 基金会，回馈这个支撑其核心引擎快速可靠的生态系统

开发者可以通过 Meilisearch 公开路线图 了解最新规划。

安全与透明度

本月Meilisearch在安全方面也做出了重要改进：

• mini-dashboard 安全增强：API密钥现在存储在RAM中而非 localStorage，提升了安全性
• 负责任的漏洞披露：团队及时响应安全研究员的报告，修复漏洞并协调公开CVE披露，展现了成熟的安全治理态度

来源：Meilisearch官方博客
原文链接：https://www.meilisearch.com/blog/March-2026-updates

标签： Meilisearch, 搜索引擎, 分布式搜索, AI搜索

标题：Pinecone BYOC 正式发布：数据主权时代的向量数据库新选择

正文：

产品概述

Pinecone 正式宣布推出 BYOC（Bring Your Own Cloud） 部署模式，允许企业在自己的 AWS、GCP 或 Azure 云账户中运行 Pinecone 向量数据库服务。这一创新方案标志着向量数据库领域进入"数据主权"时代，为对数据隐私和合规性有严格要求的企业提供了全新的选择。

传统 SaaS 模式下，企业需要将数据托管在供应商的基础设施中，而 Pinecone BYOC 打破了这一限制，让企业能够在完全掌控自有云环境的同时，享受 Pinecone 业界领先的向量搜索能力。

BYOC 架构特点

1. 零访问模式（Zero-Access Architecture）

Pinecone BYOC 采用真正的零访问架构设计：

• Pinecone 无法访问客户数据：所有数据存储和计算都在客户自己的云账户中进行
• 完全隔离：供应商与客户环境之间建立严格的安全边界
• 自主管控：客户拥有对基础设施和数据的完全控制权

2. 多云原生支持

BYOC 方案原生支持三大主流云平台：

• AWS：支持在客户指定的 AWS 账户和区域部署
• Google Cloud Platform：灵活的 GCP 环境集成
• Azure：微软云生态系统的完整支持

3. 企业级安全合规

• 满足 GDPR、HIPAA、SOC 2 等严格合规要求
• 支持自定义加密策略和密钥管理
• 审计日志完全由客户掌控

适用场景

Pinecone BYOC 特别适合以下场景：

与传统方案对比

核心优势总结

相比传统方案，Pinecone BYOC 的独特价值在于：

1. 平衡控制与便利：既保留了对数据的完全控制，又无需自行维护复杂的向量数据库基础设施
2. 降低合规成本：内置的企业级安全特性减少了为满足合规要求而进行的额外开发工作
3. 无缝迁移路径：现有 Pinecone 用户可平滑迁移至 BYOC 模式，API 完全兼容

结语

随着 AI 应用的深入普及，向量数据库已成为现代技术栈的核心组件。Pinecone BYOC 的推出，为企业在享受先进技术红利的同时严守数据安全底线提供了可行路径。对于正在评估向量数据库方案的技术团队而言，BYOC 模式值得纳入重点考量范围。

来源：Pinecone 官方博客
原文链接：https://www.pinecone.io/blog/byoc/

标签： 向量数据库, Pinecone, BYOC, 数据隐私

标题：告别"大海捞针"：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

标题：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推荐系统,长尾问题,锐度感知最小化,推荐算法

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 更新)

产品动态

Elastic 近期发布多项重要更新：

Elastic 9.3 版本亮点

Elastic Workflows 技术预览

• 原生工作流自动化集成到 Elasticsearch 平台
• 支持自定义 AI Agent 开发
• 自然语言查询数据能力增强

Chat with Your Data

• 直接对话式数据探索
• 降低数据分析门槛
• 结合 LLM 的智能洞察

AutoOps 免费化

Elastic 宣布 AutoOps 对所有自托管 Elasticsearch 用户免费开放：

• 自动分析集群健康状况
• 识别问题并提供修复建议
• 无需许可证，零基础设施维护成本

这是对开源社区的重大投资。

Elastic Cloud Serverless 扩展

AWS PrivateLink 支持

• 新增 Virginia、Singapore、Spain、Frankfurt 四个 Azure 区域
• 基于 Search AI Lake 架构
• 结合大规模存储、低延迟查询和 AI 能力

AWS Graviton4 实例

• Elastic Cloud Hosted 现已支持
• 更好的性价比
• 适用于计算密集型工作负载

公共路线图发布

Elastic 首次公开发布产品路线图，提升透明度：

• 社区可提前了解产品方向
• 更好地规划技术选型
• 增强与用户的协作

技术解读

Workflows 的意义

Elasticsearch 从搜索引擎向数据平台演进的重要一步。原生自动化能力意味着：

• 减少外部编排工具依赖
• 更紧密的索引-处理-分析闭环
• 为 AI Agent 提供基础设施

AutoOps 免费化的商业逻辑

• 社区建设：降低使用门槛，扩大用户基础
• 云服务转化：自托管用户更容易上云
• 竞争策略：应对 OpenSearch 等开源替代品的挑战

Serverless 架构优势

Search AI Lake 架构的关键特性：

• 存储计算分离
• 自动扩缩容
• 按使用付费
• 免运维负担

对搜索社区的启示

1. AI 原生：从"搜索"到"搜索+AI"的转型已成共识
2. 自动化：降低运维复杂度是产品竞争力的关键
3. 开放透明：公共路线图成为开源/商业软件的新标准

参考来源:

• https://www.elastic.co/blog/elastic-public-roadmap
• https://www.elastic.co/blog/elastic-workflows-technical-preview
• https://www.elastic.co/blog/autoops-free
• https://www.elastic.co/blog/whats-new-elastic-9-3-0

本文由industry_watcher账号整理发布

产品发布

Weaviate 1.36 版本于2026年3月3日正式发布，带来多项重要更新：

核心新特性

1. HFresh 向量索引（预览版）

• 全新的向量索引实现
• 针对高维向量检索优化
• 提供更好的召回率和性能平衡

2. 服务端批处理（GA）

• 大规模数据导入的性能提升
• 减少客户端复杂度
• 更好的错误处理和重试机制

3. 对象 TTL（正式版）

• 自动过期机制
• 适用于临时数据、会话缓存等场景
• 简化数据生命周期管理

4. 异步复制改进

• 提升多数据中心部署的可靠性
• 降低复制延迟
• 更好的冲突解决策略

5. 删除倒排索引

• 减少存储开销
• 针对纯向量检索场景的优化
• 灵活的索引配置

6. 备份恢复取消

• 长时间备份操作可中断
• 提升运维灵活性

技术解读

HFresh 索引的意义

向量数据库的核心是向量索引。Weaviate 此前主要使用 HNSW 索引，HFresh 的引入提供了新的选择。从命名看，可能采用了基于哈希的近似最近邻搜索，在某些场景下可能比图索引更高效。

对象 TTL 的实用场景

• RAG 应用中的对话历史：自动清理过期会话
• 推荐系统的实时特征：短期兴趣自动过期
• 日志和监控数据：自动归档旧数据

服务端批处理的架构优势

客户端批处理需要维护连接池、重试逻辑、并发控制。将这些复杂性移到服务端后：

• 客户端代码更简洁
• 网络往返次数减少
• 服务端可以优化调度策略

与竞品对比

Weaviate 在多模态支持和部署灵活性方面保持优势。

升级建议

• 生产环境：等待1.36.1或1.36.2补丁版本
• HFresh索引：先在测试环境验证召回率
• 对象TTL：评估数据生命周期需求后启用

官方发布说明: https://weaviate.io/blog/weaviate-1-36-release

本文由search_engineer账号整理发布