上回 我们通过 Ingest Pipeline 把数据在写入 Easysearch 的过程中自动转换成了向量，这次我们通过 Search Pipeline 实现查询时将查询内容转换成向量并进行查询。

Embedding 服务

这里要保持与写入时使用的模型一致。

实战

我们实战演示分为以下几个步骤：

1. 建立 Search Pipeline
2. 设置索引默认 Pipeline
3. 数据查询

建立 Search Pipeline

PUT /_search/pipeline/default_model_pipeline
{
  "rewrite_processors": [
    {
      "semantic_query_enricher" : {
        "description": "Sets the default embedding model",
        "url": "https://dashscope.aliyuncs.com/compatible-mode/v1/embeddings",
        "vendor": "openai",
        "api_key": "<api_key>",
        "default_model_id": "text-embedding-v4",
        "vector_field_model_id": {
           "text_vector": "text-embedding-v4"
        }
      }
    }
  ]
}

设置索引默认 Pipeline

为了方便查询，不用每次查询都指定 Pipeline，我们设置默认值。

PUT /my-index/_settings
{
  "index.search.default_pipeline" : "default_model_pipeline"
}

数据查询

使用上次写入的数据进行查询测试，但不直接查询原来的文本内容。

GET /my-index/_search
{
  "_source": "input_text",
  "query": {
    "semantic": {
      "text_vector": {
        "query_text": "非常先进高级的生产车间",
        "candidates": 100,
        "query_strategy": "LSH_COSINE"
      }
    }
  }
}

参数解释请查看文档。

OK，从上面可以看到，我们没有直接搜索原文本中的内容或关键字，但还是通过文本的语义检索到了相关内容。

关于 Easysearch

INFINI Easysearch 是一款分布式搜索引擎，支持结构化和非结构化的数据检索、全文检索、向量检索、空间地理位置信息检索、组合查询、多语种支持、语义分析和聚合分析等多种功能。

Easysearch 基于 Lucene 构建，紧跟 Lucene 最新版本持续迭代更新，采用商用友好协议，企业可自由部署、二次开发和商业化，无协议合规风险。

Easysearch 致力于为企业提供轻量、安全、自主可控的搜索平台，不断完善产品能力，满足更多企业级需求。

官网：https://easysearch.cn

相关文章：

• INFINI Easysearch 向量搜索实战（一）
• Easysearch 向量搜索指南

Easysearch 提供了强大的向量搜索能力，打破传统关键词匹配的局限，实现真正的“懂你”的语义搜索。助力企业快速构建智能推荐、图像识别和内容理解等 AI 应用，释放数据深层价值。

核心能力

典型应用场景

• 语义搜索：文本通过 Embedding 模型转为向量，按语义相似度检索
• RAG 检索增强生成：为大语言模型提供知识库检索能力
• 推荐系统：用户/商品特征向量的相似推荐
• 图像/多模态搜索：图像特征向量的相似检索
• 去重与异常检测：通过向量距离判断内容相似度

Embedding 服务

在使用向量搜索前，先要准备一个 Embedding 模型，支持与 OpenAI API 兼容的 embedding 接口和 Ollama embedding 接口。本文使用阿里云上的 Embedding 模型进行演示。

写入方法

方法一：写入链路嵌入（推荐）

在数据写入 Easysearch 时，通过 Ingest Pipeline 自动调用 Embedding 服务：

应用写数据 → Easysearch → Ingest Pipeline → 调用 Embedding API → 写入向量字段

优势是写入后即可搜索，无需维护外部向量化流程。需要确保集群应至少有一个节点拥有 ingest 角色。

方法二：离线批处理

在应用侧完成向量化，再将向量字段直接写入 Easysearch：

原始数据 → 应用 → 调用模型 Embedding API → 写入 Easysearch（含向量字段）

参考文档。

实战

我们实战演示模式一，分为以下几个步骤：

1. 建立带有向量字段的索引
2. 创建对应的 Ingest Pipeline
3. 写入数据到索引

1. 建立带有向量字段的索引

先建立一个带向量字段的索引，注意 dims 要与向量模型的输出匹配。

PUT /my-index
{
  "mappings": {
    "properties": {
      "text_vector": {
        "type": "knn_dense_float_vector",
        "knn": {
          "dims": 1024,
          "model": "lsh",
          "similarity": "cosine",
          "L": 99,
          "k": 1
        }
      }
    }
  }
}

2. 创建对应的 Ingest Pipeline

写入数据前先建立 Ingest Pipeline，注意 vendor 必须根据使用的模型来指定，比如本文使用的是阿里云 text-embedding-v4 模型，该模型提供了 OpenAI 格式的 API 接口，这里 vendor 我们就写 openai。

PUT _ingest/pipeline/text-embedding-pipeline
{
  "description": "用于生成文本嵌入向量的管道",
  "processors": [
    {
      "text_embedding": {
        "url": "https://dashscope.aliyuncs.com/compatible-mode/v1/embeddings",
        "vendor": "openai",
        "api_key": "xxxxxx",
        "text_field": "input_text",
        "vector_field": "text_vector",
        "model_id": "text-embedding-v4",
        "dims": 1024,
        "ignore_missing": false,
        "ignore_failure": false
      }
    }
  ]
}

text_field：指定原始文本字段，Pipeline 会将该字段的内容转换成向量。

vector_field：指定向量存储的字段，保存上面转换的向量。

3. 写入数据

POST /_bulk?pipeline=text-embedding-pipeline&pretty
{"index": {"_index": "my-index", "_id": "1"}}
{"input_text": "苹果发布了新款iPhone 15 Pro手机，搭载A17芯片"}
{"index": {"_index": "my-index", "_id": "2"}}
{"input_text": "特斯拉宣布将在上海建第二座超级工厂"}
{"index": {"_index": "my-index", "_id": "3"}}
{"input_text": "今天天气真好，阳光明媚适合去公园散步"}
{"index": {"_index": "my-index", "_id": "4"}}
{"input_text": "程序员用Python写了一个自动化数据清洗脚本"}
{"index": {"_index": "my-index", "_id": "5"}}
{"input_text": "故宫博物院推出了夏季特展，展出珍贵文物"}
{"index": {"_index": "my-index", "_id": "6"}}
{"input_text": "小明每天坚持跑步五公里，身体越来越健康"}
{"index": {"_index": "my-index", "_id": "7"}}
{"input_text": "人工智能大模型在自然语言处理领域取得突破"}
{"index": {"_index": "my-index", "_id": "8"}}
{"input_text": "这家咖啡店的拿铁口感丝滑，推荐给咖啡爱好者"}
{"index": {"_index": "my-index", "_id": "9"}}
{"input_text": "量子计算机有望在药物研发中发挥重要作用"}
{"index": {"_index": "my-index", "_id": "10"}}
{"input_text": "周末和朋友一起去爬山，山顶的风景美极了"}

4. 检查数据

搜索索引数据，看看是否成功转换成了向量。可以看到原始数据保存在 input_text 字段中，其向量保存到了 text_vector。

OK，下一步我们看看怎么方便地实现向量搜索。

关于 Easysearch

INFINI Easysearch 是一款分布式搜索引擎，支持结构化和非结构化的数据检索、全文检索、向量检索、空间地理位置信息检索、组合查询、多语种支持、语义分析和聚合分析等多种功能。

Easysearch 基于 Lucene 构建，紧跟 Lucene 最新版本持续迭代更新，采用商用友好协议，企业可自由部署、二次开发和商业化，无协议合规风险。

Easysearch 致力于为企业提供轻量、安全、自主可控的搜索平台，不断完善产品能力，满足更多企业级需求。

官网：https://easysearch.cn

相关文章：

• Easysearch 向量搜索指南
• INFINI Easysearch 向量搜索实战（二）

标题：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, 数据隐私

产品发布

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账号整理发布

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

这听起来反直觉，但 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
技术要点: 不可变存储、垃圾回收、分布式删除、成本优化

视觉文档检索（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 等