Dense 检索漏掉精确符号
在专业术语、编号、实体名、代码符号和合规条款中，稀疏召回仍是可解释且必要的第一层。
QPS
37,750.13
Azure D8lds_v5 级硬件
recall@10
0.905244
Big-ANN Sparse track
硬件
8 vCPU / ~16 GiB
CPU-only baseline
交付模式
私有部署
闭源容器与验证工具
Xuntianjing Sparse 稀疏检索分支
让可解释 sparse retrieval 进入超冠军级吞吐
Sparse 分支面向 RAG、企业搜索和稀疏向量数据库，解决关键词、编号、实体名、代码符号等精确匹配场景中“召回可靠但吞吐不足”的核心瓶颈。它把高召回 sparse retrieval 做成可接入、可复测、可私有化评估的检索加速层。
冠军级性能
在 Azure D8lds_v5 级官方限制硬件条件下达到 37,750.13 QPS @ recall@10 0.905244，显著超过公开参考冠军线 10,749 QPS，展现超冠军级 CPU 稀疏检索吞吐能力。
高吞吐稀疏召回
面向 SPLADE/learned sparse vectors 等稀疏表达，降低倒排检索在高召回阈值下的查询成本。
混合检索增强
作为 dense retrieval、RAG 或企业搜索链路的第一阶段召回补强，覆盖 dense embedding 容易漏掉的精确符号。
可复测性能评估
围绕 QPS、recall、延迟和硬件预算输出可复核的 benchmark 摘要，方便 POC 决策。
Use Cases
适合哪些场景使用？
巡天镜的不同分支可以作为现有检索系统的增强层接入，用性能证据和 POC 指标判断真实业务收益。
企业知识库 RAG 的高召回第一阶段检索
法规、合同、代码、医学、制造等关键词敏感场景
已有向量数据库，希望补强 sparse recall 的检索系统
需要在 CPU 预算内提升稀疏检索吞吐的私有部署项目
Sparse 召回准确但吞吐不足
Sparse 分支作为高吞吐召回增强能力接入现有 RAG、搜索或向量数据库架构，重点在于吞吐、延迟与 recall 的平衡。
企业 RAG 需要可验证指标
交付 benchmark 工具、调参报告和证据包，让吞吐、延迟、recall 与硬件成本可复测。
Data Flow
从客户数据到可验证性能结果
巡天镜 Sparse 分支不替代业务检索系统，而是作为高吞吐召回增强能力接入现有 RAG、搜索或向量数据库架构。可根据客户检索栈、数据规模和目标指标安排 Demo 或 POC，进一步评估接口形式、部署方式和优化路径。
01
数据接入
支持客户样本数据或脱敏数据评估
02
能力适配
根据检索目标和业务约束完成评估配置
03
性能验证
评估吞吐、延迟、召回和资源占用
04
结果分析
输出可审查的 benchmark 摘要和改进建议
05
POC 决策
形成部署边界、集成路径和下一步计划
Use Cases
适合接入的业务场景
如果你的检索瓶颈来自 sparse 召回过慢、dense 漏召或混合检索链路成本过高，巡天镜 Sparse 分支可以作为独立加速层先做小规模 POC。
企业知识库 RAG 的高召回第一阶段检索
专业术语、编号、实体名、代码符号敏感的搜索场景
已有 dense retrieval，需要混合 sparse/dense 召回补强
向量数据库希望增加 CPU sparse retrieval 加速模块
Private Demo / POC
巡天镜 Sparse 稀疏检索分支咨询
Sparse、OOD、Filter 都是“巡天镜”检索能力下的不同分支。若需要私有 Demo 或 POC，请直接发邮件，我们会根据场景判断最适合先验证哪一条分支。
- 当前检索场景和数据规模
- 希望验证的 recall、QPS 或延迟目标
- 是否需要私有部署、NDA 或数据不出域
联系邮箱
发送邮件到 bluety@126.com
邮件里简单说明公司/团队、检索场景、数据规模、目标 recall/QPS/latency，以及是否需要私有部署或 NDA 即可。不需要在网页上填写复杂表单。
发送邮件