PostgreSQL + Qwen3 嵌入也能做 SOTA 搜索？

别问我为什么不上 Pinecone，问就是 Hugging Face 团队出于成本控制 + 工程效率的考虑，从头到尾都靠 Hugging Face 自己的产品栈走一遍。PostgreSQL 负责关键词召回，pgvector 做语义召回，Qwen3 小模型嵌入搞定生成速度，Hugging Face Jobs + NVIDIA L4 批量跑 embedding，Inference Endpoints 给在线模型服务，Buckets 存模型文件。

整个链路看起来像极了个“用现有资源拼装”的 Hacker 工程，但效果却不错，甚至让相关论文推荐也飞起来了。

一、为什么不用 Elasticsearch？

因为懒。

其实没那么简单。论文搜索这种场景，关键词召回（BM25）还是很重要的，ES 当然可以，但运维成本高、资源消耗也大。而 PostgreSQL 自身已经支持全文检索，加上 pgvector 扩展一拓展，就可以同时做关键词检索和向量相似度搜索。于是就有了下面这个混打方案。

二、混合检索怎么做？

简单来说是“双路召回 → 融合排序”：

1. 关键词召回：PostgreSQL 的 tsvector + tsquery 做 BM25 检索；
2. 语义召回：Qwen3-Embedding-0.6B 编码查询，pgvector 使用 IVFFlat 或 HNSW 做近邻搜索；
3. 融合排序：综合两个来源的结果，按加权分数重新排序。

这种方式在很多 NLP 场景下都很吃香，尤其是像论文这种关键词密度高、语义多变的内容。

三、嵌入模型选 Qwen3 真的靠谱吗？

Qwen3-Embedding-0.6B 参数量不大，但经过指令微调后在语义匹配任务上 surprisingly 强。我们评估过它和 text-embedding-3-small 在论文标题/摘要匹配上的表现，差距不大，还便宜多了。

批量嵌入通过 Hugging Face Jobs 跑在单张 NVIDIA L4 上，性价比爆了传统 GPU 集群方案。

四、模型部署靠 Inference Endpoints 干活

在线 query 编码交给 Hugging Face Inference Endpoints 提供的托管服务，省去了自己部署 Triton 或 TorchServe 的烦恼。

五、Artifacts 存在哪？

Hugging Face Buckets，也就是 Hugging Face 自己家的存储服务，用来存 embedding 模型、索引文件等啥玩意。

说白了，这次实践证明：你不需要花钱买最贵的向量数据库，PostgreSQL 加个扩展 + 小模型嵌入，也能撼动 SOTA 搜索引擎。

更多细节看原文：

https://huggingface.co/blog/pwc-search