Hugging Face 为 Papers with Code 设计的搜索架构

Hugging Face 为 Papers with Code 实现了一套混合搜索系统，通过结合基于关键词的词法搜索与基于向量的语义搜索，使 AI 研究变得更加触手可及。该架构确保用户可以通过精确的标题或 arXiv 标识符找到研究论文，同时也能在特定关键词缺失的情况下检索到概念相关的作品。

混合搜索架构

Papers with Code 利用混合搜索系统，结合了用于精确匹配的关键词搜索和用于语义相似度的向量搜索的优势。该系统使用 PostgreSQL 数据库进行快速的词法基准检索，并使用 pgvector 进行稠密嵌入，并通过 Reciprocal Rank Fusion (RRF) 算法将两者结合起来。

检索流水线

对于每个查询，系统会执行两个并行分支：

词法分支： 使用加权 PostgreSQL 全文搜索检索最多 50 个候选结果。
语义分支： 使用 pgvector 通过对活跃生成版本的嵌入进行余弦距离搜索，检索最多 50 个候选结果。

这些结果使用加权 RRF 进行合并，分支权重相等，秩常数 $k=60$。为了保持确定性的身份行为，系统确保精确的标题和 arXiv ID 始终处于结果顶部，同时通过方法分类法处理导航类请求（例如，“the original BERT paper"）。

技术栈与基础设施

为了平衡语料库构建的吞吐量与实时查询的低延迟，Hugging Face 将搜索基础设施拆分为离线和在线组件。

离线语料库构建 (Hugging Face Jobs)

全语料库嵌入被视为批处理工作负载。Hugging Face Jobs 提供可爆发式扩展的 GPU 计算资源（具体为 NVIDIA L4 GPUs）来处理论文语料库。该过程包括：

从 PostgreSQL 快照中将论文数据导出为 JSONL 分片。
加载固定的模型版本 Qwen/Qwen3-Embedding-0.6B。
以批次形式对文档进行编码，并按长度对文本进行排序以减少填充。
使用 Matryoshka Representation Learning (MRL) 将向量截断为 256 维，并应用 L2 归一化。

持久化存储 (Hugging Face Storage Buckets)

Storage Buckets 作为数据库、临时 Jobs 和生产索引之间的连接纽带。通过将构件组织在带有清单和校验和的不可变运行前缀下，系统实现了：

可复现性： 将生成过程追溯到特定的快照和模型版本。
安全重试： 从已完成的分片开始恢复工作。
受控发布： 在原子化激活新版本之前，验证覆盖范围并构建 HNSW 索引。

在线搜索 (Hugging Face Inference Endpoints)

实时查询使用由 Text Embeddings Inference (TEI) 支持的经过身份验证的 Inference Endpoint 进行嵌入。该端点使用 Qwen3 模型的 query 提示词来生成归一化的 256 维向量。

为了处理端点的 "scale-to-zero" 特性并避免冷启动期间的延迟峰值，系统实施了严格的客户端策略：一秒钟的生产超时和断路器机制。如果语义端点不可用或超时，系统会立即回退到词法搜索结果。

嵌入契约与模型选择

为了防止嵌入流水线中出现细微的失效，Hugging Face 将嵌入格式视为版本化的 API。每篇论文被编码为 normalized title + "\n\n" + normalized abstract。

模型规格：

模型： Qwen/Qwen3-Embedding-0.6B（固定到确切的版本）。
维度： 256（通过 MRL 选择，以平衡速度与存储）。
归一化： L2 归一化向量。
提示词： 用于语料库嵌入的 document 提示词和用于实时搜索的 query 提示 prompt 提示词。

运营洞察与经验教训

吞吐量 vs. 延迟

将面向吞吐量的任务（Jobs）与面向延迟敏感的任务（Inference Endpoints）分离，使系统能够独立地针对成本和可用性进行优化。

向量维度

使用 Matryoshka 嵌入允许团队将维度降低至 256。在对 5,000 篇论文的试点测试中，该配置在与精确搜索对比时实现了 0.9955 的 Recall@20，而仅使用了 1024 维向量所需存储空间的 27%。

增量更新

虽然 Jobs 处理全量重建，但每小时一次的增量过程使用相同的 Inference Endpoint（配合 document 提示词）以最多 500 篇论文为一组进行批处理，对新论文或修改过的论文进行嵌入，从而在无需全量 GPU Job 开销的情况下保持索引的实时性。