方法论 + 首批实测结果 · 已披露原型测试机

规则先于
数据发布。

Telys 当前为 0.1.0b4——以下为已披露测试机上的原型验证数据,非生产环境数字。只有在相同召回率、相同硬件条件下完成测量,并附带原始样本与生成脚本,结果才算有效。以下规则约束每一项数字:我们测量什么、与谁比较,以及我们必须承认落败的场景。

01 运作准则

测试框架强制执行的规则,而非事后附加的免责声明。

以下每条规则均以机器检查的形式编码于基准测试框架中。违反任一规则的运行不会被加注脚注——它将被标记为无效,并从所有评分表中排除。

每一个倍数都是假设,直到在相同召回率、相同硬件条件下完成测量,并发布原始样本与复现脚本,方可成立。

Telys 基准测试准则
必须承认的落败

无法输掉的基准测试毫无价值

生成的评分表包含一个强制性的"我们落败之处"章节,由所有竞争方胜出的单元格自动填充。若该章节为空,报告构建将失败——全胜被视为框架故障,而非真实胜利。

传输层诚实性

嵌入式对嵌入式,才是公平的较量

我们绝不以进程内调用对比通过 TCP 响应的竞争方作为头条数据。对于嵌入式库,进程内对进程内是诚实的传输方式。对于服务器,传输层须对等匹配,否则数据须加注说明,不得用于头条。

持久化诚实性

层级匹配,否则不作比较

内存运行绝不与每次提交都执行 fsync 的竞争方进行评分比较。每项结果须声明其持久化层级——in_mem、wal_async 或 wal_fsync——框架对任何跨层级比较直接报错。

FAISS 规则

我们调用 FAISS 时,绝不暗示自己胜过了 FAISS

FAISS 是 Telys 内嵌的 ANN 核心——是基础,而非对手。每张向量评分表均优先展示原始 FAISS 遍历单元格;若结果持平,如实呈现。真正的优势体现在其他方面:重排序内核、过滤规划,以及围绕索引构建的引擎。

02 比较对象集

每个比较对象隔离一项声明。

单一排行榜数字将算法、传输层、持久化与存储格式混为一谈。比较对象集的选取确保每次比较恰好隔离一个变量——每项头条数据下均设有同节点对照组。

系统类型比较所隔离的变量
FAISS(同节点)对照基线下限,而非对手。Telys 内嵌 FAISS,因此原始 FAISS 数字即为我们自身的基线;发布的差值是引擎在其之上的增益——在相同索引配置与相同实测召回率下得出。
Postgres + pgvector关系型 + 向量过滤混合查询:在不同过滤选择率下、相同召回率的前提下,将标量谓词推入候选路径,是否优于必须过度获取或后置过滤的索引。
LanceDB / Chroma嵌入式库最接近的竞争对手,进程内对进程内——这是进程内数字作为公平头条的唯一场景。ANN 下限相同;比较隔离的是围绕其构建的引擎:统一行 ID 空间、冷启动、内存占用。
Qdrant / Milvus服务器算法质量——固定 k 下的召回率——与网络往返延迟分离。延迟数据附注服务器跳转说明,绝不与进程内调用并列作为头条。
Pinecone托管服务固定 k 下的召回率与单位算力吞吐量。原始延迟对比嵌入式引擎不作为核心指标;同节点对照组承载质量主张。
DuckDB / ClickHouse分析引擎对同一物理 Parquet 文件执行扫描与聚合,从而将存储格式优势与引擎优势分离。向量化分析引擎在此表现出色;其胜出结果如实发布。
03 负载矩阵

测量什么。

矩阵定义的是测量项,而非预设的胜负。每个延迟单元格报告完整分布——而非仅均值——在开环负载下采集。每个速度单元格均绑定由测试框架依据已发布基准真值计算的召回门控;未达门控的单元格标记为无效,不得进入评分卡。

负载配置测量内容
cold-open页面缓存已清除,进程全新启动从进程启动到首次查询成功的时间——段 mmap 与索引附属文件映射对比服务器启动与恢复。与稳态分开测量,绝不合并计入。
exact FLAT暴力精确搜索,f32 与 int8构造上召回率为 1.0 的距离核下界,对比同节点相同缓冲区的精确基线。每个 int8 单元格报告其相对 f32 的召回率差值,量化损失从不隐藏。
过滤混合检索标量谓词 + top-k,跨三种选择率扫描过滤器收窄时等召回率下的延迟,以及规划器为每个单元格选择的策略——先预过滤再精确、先预过滤再 IVF,或先搜索再后过滤——使自适应决策可审计。
full scan全列扫描与聚合基于共享 Parquet 的原始列式吞吐量,引擎对引擎,字节完全相同。
选择性扫描低匹配率下的谓词扫描页脚 min-max 与 zone-map 剪枝是否真正跳过了工作——以读取字节数和触及行数报告,而非仅凭挂钟时间。
reproduce
python -m bench.orchestrator.run \
    --suite vector --rig m-laptop
# one command: pinned comparators, content-addressed
# datasets, warmup, steady-state measurement
# reviewer mode: the same run with Telys excluded
result envelope
# every run emits a machine-checked ResultEnvelope;
# a run that cannot fill every field is invalid
index_string    = "IVF4096,PQ16"  # same for Telys and the FAISS control
omp_num_threads = 8               # FAISS threading pinned, disclosed
transport       = "in_process"    # headlined only vs in-process
durability_tier = "wal_fsync"     # cross-tier comparison hard-fails
recall_at_k     = 1.000           # harness-measured, never self-reported
samples_path    = "bench/results/filtered_impact.txt"

每次运行在全新进程启动下至少重复五次,在固定硬件配置上逐系统执行。数据集按内容寻址;查询集为冻结文件,不在运行时生成。测试框架规范今日提交;框架与结果同步发布。

04 首批实测结果

实测、有条件、可复现。

每一行都是在上述测试机上、在旁注召回门限下的真实运行。优势来源是物理布局:在相同连续子集上,我们的 Mojo 扫描与原始 FAISS 持平——以下差值来自键分区布局的收益,而非更快的距离内核。这些是原型数据,将随测试框架的成熟在完整公平性约定下重新运行。

工作负载配置 + 召回门限实测结果(M4 Max,单线程,进程内)
过滤切片 · 0.1% 选择率N=1,000,000 D=128 K=10,热启动,recall 1.000(精确)partition-slice p50 0.013 ms——布局优势:较全量扫描约 373×,较 scatter-gather 约 19×。相同节点 FAISS Flat 在相同子集上:0.040 ms(持平——证明优势来自布局而非内核)。
过滤切片 · 0.4% 选择率N=1,000,000 D=128 K=10,热启动,recall 1.000(精确)p50 0.032 ms——较全量扫描约 128×,较 scatter-gather 约 10.8×。FAISS Flat 对照 0.035 ms(持平)。
过滤切片 · 1.6% 选择率N=1,000,000 D=128 K=10,热启动,recall 1.000(精确)p50 0.112 ms——较全量扫描约 42×,较 scatter-gather 约 10.3×。FAISS Flat 对照 0.120 ms(持平)。
超大分区救援N=400,000 D=128 中 247k 行,nprobe 已校准,recall 0.9915(下限 0.98)分区内 IVF 在精确切片性能退化时恢复布局优势:精确切片 1.71 ms → IVF 0.033 ms。不启用 IVF 时,单个超大分区仅保留约 4–5× 优势。
受治理自动 nprobeN=1,000,000 D=128 Q=500 nlist=1000,召回率维持 0.998(下限 0.98)FIND 在基准 nprobe=32 时 0.28–0.31 ms → 受治理自动 nprobe=8 时 0.081–0.088 ms。召回率保持在下限以上——无静默的以召回换速度。
FIND 与 FAISS 对照等召回率,相同传输层,均为进程内,N=1,000,000 D=128Telys 0.073–0.074 ms @0.998 vs 原始 FAISS 0.080 ms @0.999——持平至小幅领先。规模相关:N=200k 时落后(0.74×),仅在大规模内存受限 N 下达到约 1.6×。FAISS 质量,Mojo 加速。
无 GIL 并发N=200,000 D=128,12 性能核,进程内 Mojo IVF 内核FIND 吞吐量在 8 线程下扩展 ×6.9(15,128 → 104,756 qps)。为吞吐量扩展性指标,非单查询延迟;未与服务端引擎比较。
插入到召回的新鲜度基础 N=100,000,M=300 次插入,D=128,进程内刚插入的向量在下一次查询中即为 top-1:recall@1-of-new = 1.000。插入 p50 0.3 µs。正确性门限,非吞吐量指标。

以上每个单元格均可追溯至具名脚本及 bench/results/ 中保存的原始输出(filtered_impact.txt、partitioned.txt、partition_acceptance.txt、opt.txt、telys.txt、concurrency.txt、freshness.txt)。持久化重开数据因待重测原始样本暂未列出。所有倍数均为假设,仅在各行所印条件范围内成立。

05 代码检索质量

专为代码构建——并在代码基准上接受评分。

Telys 检索代码,因此质量标准是 CoIR,而非通用文本套件。LexicalCodeIndex 封装为 mteb SearchProtocol,由 mteb.evaluate 与 bm25s 基线走相同路径评分——无方法论差异,无自评分。基线为 2026-07-21 的可复现运行结果,而非 CoIR 论文中的发布数据(其中多项无法复现)。指标:nDCG@10。

CoIR 任务multigrambm25-refbm25-code代码词法 · 已发布vs 最优基线
CodeTransOceanContest0.1600.4780.6000.718
CodeTransOceanDL0.3400.3440.3510.366
CosQA0.0480.1880.2130.218
SyntheticText2SQL0.2650.2490.3720.441
CodeFeedbackMT0.2880.5920.5910.674
CodeFeedbackST0.1620.6820.6820.722
StackOverflowQA0.2230.7030.6870.733
AppsRetrieval0.0010.0480.0140.034
平均值0.1860.445 †0.4887/8

八项任务中胜出七项;平均 0.488,各任务最优基线平均 0.445(† 每项任务取 bm25-ref / bm25-code 之最优),同时达到 multigram 平均值的 2.6 倍。唯一落败的 AppsRetrieval,所有词法方法均接近零分:长题目描述对代码的检索属于向量嵌入领域。

杠杆 01

代码感知分词 + BM25

标识符按代码书写方式拆分——camelCase、snake_case、点分路径——直接输入标准 IDF/BM25。仅此一项即可赢得多数任务:CodeTransOceanContest 在任何调优之前即从 0.478 提升至 0.600。

杠杆 02

去停用词 + 轻量词干提取

移除英语停用词,并使用轻量后缀词干提取器,使自然语言查询与代码词元对齐——正是这一杠杆将 SyntheticText2SQL 从落败翻转为 0.441。

杠杆 03

k1 = 1.8 · b = 1.0

出厂默认值,由 Algenta 在 CoIR 上调优:更强的词频饱和度与完整长度归一化——正是这一杠杆翻转了 StackOverflowQA。

所有数据均可由单一脚本复现——bench/mteb_code_lexical.py——双方均通过相同的 mteb.evaluate 调用运行(运行日期 2026-07-21)。code-lexical 即 Telys 出厂搭载的索引,使用其出厂默认配置。

06 发布

胜出、持平与落败,一并呈现。

发布格式在第一个数字产生之前即已确定,数字无法改变它。

已发布的落败项

我们落败之处,白纸黑字

每份评分卡均包含"我们落败之处"与"我们仅与 FAISS 持平之处"两节,均由单元格自动填充。任一节为空,报告即构建失败。

审阅者模式

无需我们,独立复现全部数据

测试框架支持在排除 Telys 的情况下运行,质疑者可单独复现对照组与对比组数据,并确认每个竞品均按其官方指南调优——配置已提交并与厂商默认值做差异对比。

原始样本

每个单元格均可追溯至原始样本

每个已发布单元格均链接其原始逐操作样本及生成它的精确脚本。结果仅追加,以引擎版本及其静态链接的捆绑依赖版本为键。

与团队交流

这些是原型数据,每项均附带其条件。请以此契约约束我们——并在我们于完整测试框架下重新运行这些数据时,以这些数字约束我们。