नियम संख्याओं से
पहले प्रकाशित होते हैं।
Telys 0.1.0b4 है — ये एक disclosed rig पर prototype-validated अंक हैं, production numbers नहीं। कोई परिणाम तभी मान्य है जब वह matched recall और matched hardware पर मापा गया हो, raw samples और उन्हें उत्पन्न करने वाली script के साथ। नीचे के नियम हर अंक पर लागू होते हैं: हम क्या मापते हैं, किसके विरुद्ध, और वे तरीके जिनमें हमारा हारना अनिवार्य है।
नियम जो harness लागू करता है — अपवाद नहीं जो हम जोड़ते हैं।
नीचे दिया गया प्रत्येक नियम benchmark harness में एक machine check के रूप में एन्कोड है। जो run इसका उल्लंघन करे उसे footnote नहीं मिलता — उसे invalid चिह्नित कर हर scorecard से बाहर किया जाता है।
“हर multiplier एक परिकल्पना है — जब तक matched recall और matched hardware पर, raw samples और एक reproduction script के साथ मापा न जाए।”
Telys बेंचमार्क सिद्धांतजो benchmark हम हार न सकें, वह निरर्थक है
तैयार scorecard में एक अनिवार्य Where-we-lose अनुभाग होता है, जो हर उस cell से स्वतः भरा जाता है जहाँ कोई comparator जीतता है। यदि वह अनुभाग खाली हो, तो report build विफल हो जाती है — clean sweep को टूटा हुआ harness माना जाता है, जीत नहीं।
Embedded बनाम embedded — यही उचित तुलना है
हम कभी किसी in-process call को TCP पर उत्तर देने वाले प्रतिस्पर्धी के विरुद्ध headline नहीं करते। embedded libraries के विरुद्ध, in-process बनाम in-process ही ईमानदार transport है। servers के विरुद्ध, transport को like for like मिलाया जाता है, अन्यथा संख्या annotated रहती है और headlines से बाहर।
Matched tiers, या कोई तुलना नहीं
किसी in-memory run को ऐसे प्रतिस्पर्धी के विरुद्ध कभी नहीं आँका जाता जो हर commit पर fsync करता हो। हर परिणाम अपना durability tier घोषित करता है — in_mem, wal_async, या wal_fsync — और harness tiers के पार किसी भी तुलना को hard-fail करता है।
हम कभी यह नहीं जताते कि हमने FAISS को हराया जब हम FAISS को ही call कर रहे हों
FAISS वह ANN core है जिसे Telys embed करता है — एक आधार, प्रतिद्वंद्वी नहीं। हर vector scorecard पहले raw-FAISS traversal cell दिखाता है; जहाँ बराबरी हो, वह बराबरी छापी जाती है। ईमानदार जीत कहीं और दर्ज होती है: rerank kernels, filtered planning, और index के इर्द-गिर्द का engine।
हर comparator एक दावे को अलग करता है।
एक अकेला leaderboard नंबर algorithm, transport, durability और storage format को एक साथ मिला देता है। यह समूह इसलिए चुना गया है कि हर तुलना ठीक एक चर को अलग करे — हर headline के नीचे same-node control के साथ।
| सिस्टम | स्वरूप | तुलना क्या अलग करती है |
|---|---|---|
| FAISS (समान नोड) | नियंत्रण आधाररेखा | आधार, प्रतिद्वंद्वी नहीं। Telys FAISS embed करता है, इसलिए raw-FAISS संख्या वह baseline है जो हम हैं; प्रकाशित delta वह है जो engine उसके इर्द-गिर्द जोड़ता है — उसी index string और उसी measured recall पर। |
| Postgres + pgvector | रिलेशनल + वेक्टर | filtered-hybrid query: क्या scalar predicate को candidate path में धकेलना उस index को मात देता है जिसे over-fetch या post-filter करना पड़े — filter selectivities में समान recall पर। |
| LanceDB / Chroma | एम्बेडेड लाइब्रेरी | सबसे निकट प्रतिस्पर्धी, in-process बनाम in-process — वह एकमात्र स्थान जहाँ in-process संख्या उचित headline है। ANN floor समान; तुलना उसके इर्द-गिर्द के engine को अलग करती है: unified row-id space, cold-open, footprint। |
| Qdrant / Milvus | Server | Algorithm quality — fixed k पर recall — network round-trips से अलग। Latency server hop annotated के साथ रिपोर्ट होती है और कभी in-process call के विरुद्ध headline नहीं बनती। |
| Pinecone | प्रबंधित सेवा | निश्चित k पर Recall और प्रति compute इकाई throughput। एक embedded engine के विरुद्ध raw latency को headline के रूप में अस्वीकार किया जाता है; गुणवत्ता का दावा same-node control वहन करता है। |
| DuckDB / ClickHouse | विश्लेषणात्मक इंजन | उसी भौतिक Parquet फ़ाइल पर scan और aggregate, ताकि storage-format लाभ को engine लाभ से अलग किया जा सके। Vectorized analytical engines यहाँ उत्कृष्ट हैं; उनकी जीत प्रकाशित होती है। |
क्या मापा जाता है।
Matrix माप परिभाषित करता है, अनुमानित जीत नहीं। प्रत्येक latency cell open-loop offered load के अंतर्गत पूर्ण वितरण रिपोर्ट करता है — केवल mean नहीं। प्रत्येक speed cell एक recall gate से बँधा है जिसे harness shipped ground truth के विरुद्ध compute करता है; जिस cell का gate पूरा न हो, वह invalid उत्सर्जित होता है और scorecard में प्रवेश नहीं कर सकता।
| Workload | Setup | क्या मापता है |
|---|---|---|
| cold-open | Page cache हटाया, नई process शुरू | Process शुरू से पहली सफल query तक का समय — server boot और recovery के विरुद्ध segment mmap और index-sidecar mapping। Steady state से अलग मापा जाता है, उसमें कभी नहीं मिलाया जाता। |
| exact FLAT | Brute-force exact search, f32 और int8 | निर्माण द्वारा recall 1.0 पर distance-kernel floor, उन्हीं buffers पर same-node exact baseline के विरुद्ध। प्रत्येक int8 cell f32 के सापेक्ष अपना recall delta रिपोर्ट करता है, ताकि quantization loss कभी छुपे नहीं। |
| फ़िल्टर्ड हाइब्रिड | Scalar predicate + top-k, तीन selectivities में swept | Filter संकरा होने पर equal recall पर latency, साथ ही प्रति cell planner की चुनी रणनीति — pre-filter then exact, pre-filter then IVF, या search then post-filter — ताकि adaptive निर्णय auditable रहे। |
| full scan | Full-column scan और aggregate | साझा Parquet पर raw columnar throughput, समान bytes पर engine बनाम engine। |
| चयनात्मक स्कैन | कम match rates पर predicate scan | क्या footer min-max और zone-map pruning वास्तव में काम छोड़ते हैं — केवल wall clock नहीं, bytes read और rows touched के रूप में रिपोर्ट। |
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# 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"
Runs कम से कम पाँच बार दोहराए जाते हैं, नई process starts पर, pinned hardware profiles पर, एक समय में एक system। Datasets content-addressed हैं; query sets frozen files हैं, run time पर generate नहीं होतीं। Harness specification आज committed है; harness परिणामों के साथ प्रकाशित होता है।
मापे गए, conditioned, पुनरुत्पादनीय।
हर row ऊपर named rig पर एक real run है, उसके साथ printed recall gate पर। जीत की सतह physical layout है: समान contiguous subset पर हमारा Mojo scan raw FAISS के बराबर है — नीचे का delta key-partitioned layout की देन है, किसी तेज़ distance kernel की नहीं। ये prototype अंक हैं; harness के परिपक्व होने के साथ पूरे fairness contract के तहत पुनः चलाए जाते हैं।
| Workload | सेटअप + रिकॉल गेट | मापा गया परिणाम (M4 Max, single-thread, in-process) |
|---|---|---|
| फ़िल्टर्ड स्लाइस · 0.1% sel | N=1,000,000 D=128 K=10, वार्म, रिकॉल 1.000 (सटीक) | partition-slice p50 0.013 ms — layout win vs full-scan ~373×, vs scatter-gather ~19×। समान subset पर FAISS Flat: 0.040 ms (tie — सिद्ध करता है जीत layout की है, kernel की नहीं)। |
| फ़िल्टर्ड स्लाइस · 0.4% sel | N=1,000,000 D=128 K=10, वार्म, रिकॉल 1.000 (सटीक) | p50 0.032 ms — ~128× vs full-scan, ~10.8× vs scatter-gather। FAISS Flat control 0.035 ms (tie)। |
| फ़िल्टर्ड स्लाइस · 1.6% sel | N=1,000,000 D=128 K=10, वार्म, रिकॉल 1.000 (सटीक) | p50 0.112 ms — ~42× vs full-scan, ~10.3× vs scatter-gather। FAISS Flat control 0.120 ms (tie)। |
| विशाल-पार्टीशन रेस्क्यू | N=400,000 में 247k rows, D=128, nprobe calibrated, recall 0.9915 (floor 0.98) | IVF-within-partition वहाँ layout win बहाल करता है जहाँ exact slice degraded होती है: exact slice 1.71 ms → IVF 0.033 ms। IVF के बिना, एक giant partition केवल ~4–5× रखता है। |
| नियंत्रित ऑटो-nprobe | N=1,000,000 D=128 Q=500 nlist=1000, रिकॉल 0.998 (न्यूनतम 0.98) | FIND baseline nprobe=32 पर 0.28–0.31 ms → governed auto-nprobe=8 पर 0.081–0.088 ms। Recall floor से ऊपर रहता है — कोई silent recall-for-speed trade नहीं। |
| FIND बनाम FAISS कंट्रोल | Iso-recall, same transport, दोनों in-process, N=1,000,000 D=128 | Telys 0.073–0.074 ms @0.998 vs raw FAISS 0.080 ms @0.999 — parity से थोड़ा आगे। Scale-dependent: N=200k पर पीछे (0.74×), large memory-bound N पर ~1.6× तक। FAISS quality, Mojo-accelerated। |
| GIL-मुक्त कंकरेंसी | N=200,000 D=128, 12 परफ़ कोर, इन-प्रोसेस Mojo IVF कर्नेल | FIND throughput 8 threads पर ×6.9 scale करता है (15,128 → 104,756 qps)। Throughput scaling है, per-query latency नहीं; server engines से तुलना नहीं। |
| इन्सर्ट-टू-रिकॉल फ्रेशनेस | बेस N=100,000, M=300 इन्सर्ट, D=128, इन-प्रोसेस | अभी-inserted vector अगली ही query में top-1 है: recall@1-of-new = 1.000। Insert p50 0.3 µs। यह correctness gate है, throughput headline नहीं। |
ऊपर हर cell एक named script और bench/results/ में saved raw output से trace होती है (filtered_impact.txt, partitioned.txt, partition_acceptance.txt, opt.txt, telys.txt, concurrency.txt, freshness.txt)। persistence reopen अंक re-measured raw sample pending रोका गया है। हर multiplier अपनी stated conditions के बाहर एक hypothesis है।
कोड के लिए बना — और कोड बेंचमार्क पर परखा।
Telys कोड retrieve करता है, इसलिए quality की कसौटी CoIR है, कोई general-text suite नहीं। LexicalCodeIndex को mteb SearchProtocol के रूप में wrap किया गया है और bm25s baselines के समान path पर mteb.evaluate द्वारा scored किया गया है — कोई methodology gap नहीं, कोई self-scoring नहीं। Baselines 2026-07-21 के reproducible runs हैं, CoIR paper के published figures नहीं (उनमें से कई reproduce नहीं होते)। Metric: nDCG@10।
| CoIR task | multigram | bm25-ref | bm25-code | कोड-लेक्सिकल · शिप्ड | best baseline से तुलना |
|---|---|---|---|---|---|
| CodeTransOceanContest | 0.160 | 0.478 | 0.600 | 0.718 | ✅ |
| CodeTransOceanDL | 0.340 | 0.344 | 0.351 | 0.366 | ✅ |
| CosQA | 0.048 | 0.188 | 0.213 | 0.218 | ✅ |
| SyntheticText2SQL | 0.265 | 0.249 | 0.372 | 0.441 | ✅ |
| CodeFeedbackMT | 0.288 | 0.592 | 0.591 | 0.674 | ✅ |
| CodeFeedbackST | 0.162 | 0.682 | 0.682 | 0.722 | ✅ |
| StackOverflowQA | 0.223 | 0.703 | 0.687 | 0.733 | ✅ |
| AppsRetrieval | 0.001 | 0.048 | 0.014 | 0.034 | ❌ |
| औसत | 0.186 | 0.445 † | 0.488 | 7/8 | |
आठ में से सात जीत; औसत 0.488 बनाम 0.445 प्रत्येक task के stronger baseline के लिए († bm25-ref / bm25-code में से बेहतर, per task) — और multigram औसत का 2.6×। एकमात्र हार, AppsRetrieval, हर lexical method के लिए शून्य के निकट है: लंबे problem statements बनाम कोड embedding का क्षेत्र है।
कोड-सचेत टोकन + BM25
Identifiers उसी तरह split होते हैं जैसे कोड लिखा जाता है — camelCase, snake_case, dotted paths — plain IDF/BM25 को feed करते हुए। यह अकेले अधिकांश tasks जीतता है: CodeTransOceanContest किसी tuning से पहले 0.478 से 0.600 पर पहुँचता है।
Stopwords हटाए, lite stemming
English stopwords हटाए गए और एक lite suffix-stemmer ताकि natural-language queries code tokens से मेल खाएं — वह lever जो SyntheticText2SQL को हार से 0.441 पर ले जाता है।
k1 = 1.8 · b = 1.0
Shipped defaults, CoIR पर Algenta-tuned: भारी term-frequency saturation और पूर्ण length normalization — वह lever जो StackOverflowQA को पलटता है।
हर cell एक script से reproduce होता है — bench/mteb_code_lexical.py — दोनों पक्षों को एक ही mteb.evaluate call से चलाते हुए (2026-07-21 के runs)। code-lexical वह index है जो Telys ship करता है, अपने shipped defaults पर।
जीत, बराबरी, और हार — लिखित में।
Publication format पहला अंक आने से पहले तय हो जाता है, इसलिए अंक उसे मोड़ नहीं सकते।
जहाँ हम हारते हैं, मुद्रित रूप में
प्रत्येक scorecard में एक Where-we-lose section और एक Where-we-only-match-FAISS section होता है, दोनों cells से auto-populated। यदि कोई भी खाली हो तो report build नहीं होती।
हमारे बिना field को reproduce करें
Harness Telys को बाहर रखकर चलता है, ताकि कोई संशयी अकेले comparator और control numbers reproduce कर सके और पुष्टि कर सके कि प्रत्येक competitor को उसके अपने guide के अनुसार tune किया गया — configs committed और vendor defaults के विरुद्ध diffed।
प्रत्येक cell samples तक traceable है
प्रत्येक प्रकाशित cell अपने raw per-operation samples और उन्हें produce करने वाली exact script से linked है। परिणाम append-only हैं, engine revision और उसके statically linked bundled dependency versions से keyed।
ये prototype numbers हैं, हर एक अपनी शर्तों के साथ। हमें इस contract पर — और उन अंकों पर जब हम उन्हें पूरे harness के तहत पुनः चलाएँ — जवाबदेह ठहराएँ।