اصول نتائج سے پہلے
شائع ہوتے ہیں۔
Telys ورژن 0.1.0b4 ہے — یہ ایک disclosed rig پر prototype-validated اعداد ہیں، production نمبر نہیں۔ کوئی نتیجہ تبھی معتبر ہے جب یکساں ہارڈویئر پر یکساں recall کے تحت ماپا گیا ہو، خام نمونوں اور انہیں تیار کرنے والی اسکرپٹ سمیت۔ ذیل کے اصول ہر عدد پر لاگو رہتے ہیں: ہم کیا ماپتے ہیں، کس کے مقابلے میں، اور وہ طریقے جن میں ہمارا ہارنا لازم ہے۔
وہ قواعد جو ہارنس نافذ کرتا ہے — نہ کہ وہ تحفظات جو ہم بعد میں جوڑتے ہیں۔
ذیل میں ہر قاعدہ بینچ مارک ہارنس میں مشینی جانچ کے طور پر درج ہے۔ جو رن اسے توڑے اسے حاشیے میں نہیں ڈالا جاتا — اسے غیر درست قرار دے کر ہر اسکور کارڈ سے خارج کر دیا جاتا ہے۔
“ہر ضرب ایک قیاس ہے جب تک یکساں ریکال اور یکساں ہارڈویئر کے تحت، خام نمونوں اور شائع شدہ ری پروڈکشن اسکرپٹ کے ساتھ ماپا نہ جائے۔”
Telys بینچ مارک اصولجو بینچ مارک ہم ہار نہ سکیں وہ بے کار ہے
تیار کردہ اسکور کارڈ میں ایک لازمی "جہاں ہم ہارتے ہیں" سیکشن ہوتا ہے، جو ہر اس سیل سے خودکار بھرا جاتا ہے جہاں کوئی موازن جیتتا ہے۔ اگر یہ سیکشن خالی ہو تو رپورٹ بلڈ ناکام ہو جاتی ہے — مکمل جیت کو کامیابی نہیں، ٹوٹا ہوا ہارنس سمجھا جاتا ہے۔
ایمبیڈڈ بمقابلہ ایمبیڈڈ ہی منصفانہ مقابلہ ہے
ہم کبھی کسی ان-پروسیس کال کو TCP پر جواب دینے والے حریف کے مقابلے میں سرخی نہیں بناتے۔ ایمبیڈڈ لائبریریوں کے خلاف، ان-پروسیس بمقابلہ ان-پروسیس ہی دیانت دار ٹرانسپورٹ ہے۔ سرورز کے خلاف، ٹرانسپورٹ یکساں رکھا جاتا ہے، ورنہ نمبر کو نوٹ کر کے سرخیوں سے باہر رکھا جاتا ہے۔
یکساں درجے، ورنہ کوئی موازنہ نہیں
ان-میموری رن کو کبھی ایسے حریف سے نہیں ناپا جاتا جو ہر کمٹ پر fsync کرتا ہو۔ ہر نتیجہ اپنا استحکام درجہ ظاہر کرتا ہے — in_mem، wal_async، یا wal_fsync — اور ہارنس درجوں کے پار کسی بھی موازنے کو سختی سے ناکام کر دیتا ہے۔
ہم کبھی یہ نہیں جتاتے کہ ہم FAISS کو ہراتے ہیں جب ہم FAISS کو ہی استعمال کر رہے ہوں
FAISS وہ ANN کور ہے جسے Telys ایمبیڈ کرتا ہے — ایک بنیاد، نہ کہ حریف۔ ہر ویکٹر اسکور کارڈ پہلے خام FAISS ٹراورسل سیل دکھاتا ہے؛ جہاں برابری ہو، وہ برابری درج کی جاتی ہے۔ حقیقی جیت کا دعویٰ کہیں اور کیا جاتا ہے: ری رینک کرنلز، فلٹرڈ پلاننگ، اور انڈیکس کے گرد انجن میں۔
ہر موازن ایک دعوے کو الگ کرتا ہے۔
ایک واحد لیڈر بورڈ نمبر الگورتھم، ٹرانسپورٹ، استحکام، اور اسٹوریج فارمیٹ کو گڈمڈ کر دیتا ہے۔ یہ سیٹ اس طرح چنا گیا ہے کہ ہر موازنہ بالکل ایک متغیر کو الگ کرے — ہر سرخی کے نیچے ایک ہی نوڈ کنٹرول کے ساتھ۔
| سسٹم | شکل | موازنہ کیا الگ کرتا ہے |
|---|---|---|
| FAISS (ایک ہی نوڈ) | کنٹرول بیس لائن | فرش، نہ کہ حریف۔ Telys، FAISS کو ایمبیڈ کرتا ہے، اس لیے خام FAISS نمبر وہ بیس لائن ہے جو ہم خود ہیں؛ شائع شدہ فرق وہ ہے جو انجن اس کے گرد شامل کرتا ہے — اسی انڈیکس اسٹرنگ اور اسی ماپی گئی ریکال پر۔ |
| Postgres + pgvector | ریلیشنل + ویکٹر | فلٹرڈ-ہائبرڈ کوئری: کیا اسکیلر پریڈیکیٹ کو کینڈیڈیٹ پاتھ میں دھکیلنا ایسے انڈیکس کو پیچھے چھوڑتا ہے جسے اوور-فیچ یا پوسٹ-فلٹر کرنا پڑے — فلٹر سلیکٹیویٹیز میں یکساں ریکال پر۔ |
| LanceDB / Chroma | ایمبیڈڈ لائبریری | قریب ترین حریف، ان-پروسیس بمقابلہ ان-پروسیس — وہ واحد جگہ جہاں ان-پروسیس نمبر منصفانہ سرخی ہے۔ یکساں ANN فرش؛ موازنہ اس کے گرد انجن کو الگ کرتا ہے: یونیفائیڈ رو-آئی ڈی اسپیس، کولڈ-اوپن، فٹ پرنٹ۔ |
| Qdrant / Milvus | سرور | الگورتھم معیار — مقررہ k پر ریکال — نیٹ ورک راؤنڈ ٹرپس سے الگ۔ لیٹینسی سرور ہاپ نوٹ کے ساتھ رپورٹ کی جاتی ہے اور کبھی ان-پروسیس کال کے مقابلے میں سرخی نہیں بنتی۔ |
| Pinecone | منیجڈ سروس | مقررہ k پر Recall اور فی کمپیوٹ یونٹ تھروپٹ۔ ایمبیڈڈ انجن کے مقابلے میں خام لیٹنسی کو سرخی کے طور پر مسترد کیا جاتا ہے؛ معیار کا دعویٰ اس کی جگہ سیم-نوڈ کنٹرول اٹھاتا ہے۔ |
| DuckDB / ClickHouse | تجزیاتی انجن | ایک ہی فزیکل Parquet فائل پر اسکین اور ایگریگیٹ، تاکہ اسٹوریج فارمیٹ کا فائدہ انجن کے فائدے سے الگ ہو۔ ویکٹرائزڈ تجزیاتی انجن یہاں بہترین ہیں؛ ان کی جیت شائع ہوتی ہے۔ |
کیا ناپا جاتا ہے۔
میٹرکس پیمائشیں متعین کرتا ہے، فرضی جیتیں نہیں۔ ہر لیٹنسی سیل اوپن-لوپ آفرڈ لوڈ کے تحت مکمل ڈسٹری بیوشن رپورٹ کرتا ہے — صرف اوسط نہیں۔ ہر اسپیڈ سیل ایک recall گیٹ سے منسلک ہے جو ہارنس نے شپڈ گراؤنڈ ٹروتھ کے خلاف کمپیوٹ کیا؛ جس سیل کا گیٹ پورا نہ ہو وہ invalid اخراج پاتا ہے اور اسکور کارڈ میں داخل نہیں ہو سکتا۔
| ورک لوڈ | سیٹ اپ | کیا ناپتا ہے |
|---|---|---|
| cold-open | پیج کیش ڈراپ، تازہ پروسیس اسٹارٹ | پروسیس اسٹارٹ سے پہلی کامیاب کوئری تک کا وقت — سرور بوٹ اور ریکوری کے مقابلے میں سیگمنٹ mmap اور انڈیکس-سائیڈکار میپنگ۔ اسٹیڈی اسٹیٹ سے الگ ناپا جاتا ہے، کبھی اس میں ضم نہیں کیا جاتا۔ |
| exact FLAT | بروٹ-فورس ایگزیکٹ سرچ، f32 اور int8 | تعمیری طور پر recall 1.0 پر ڈسٹنس-کرنل فلور، ایک ہی بفرز پر سیم-نوڈ ایگزیکٹ بیس لائن کے مقابلے میں۔ ہر int8 سیل f32 کے مقابلے میں اپنا recall ڈیلٹا رپورٹ کرتا ہے، تاکہ کوانٹائزیشن لاس کبھی چھپا نہ رہے۔ |
| فلٹرڈ ہائبرڈ | اسکیلر پریڈیکیٹ + top-k، تین سلیکٹیویٹیز پر سویپ | فلٹر کے تنگ ہونے پر مساوی recall پر لیٹنسی، نیز فی سیل پلانر کی منتخب حکمت عملی — پری-فلٹر پھر ایگزیکٹ، پری-فلٹر پھر IVF، یا سرچ پھر پوسٹ-فلٹر — تاکہ انکولن فیصلہ قابلِ آڈٹ ہو۔ |
| full scan | فل-کالم اسکین اور ایگریگیٹ | مشترکہ Parquet پر خام کالمر تھروپٹ، یکساں بائٹس پر انجن بمقابلہ انجن۔ |
| منتخب اسکین | کم میچ ریٹس پر پریڈیکیٹ اسکین | آیا فوٹر min-max اور زون-میپ پرونگ واقعی کام چھوڑتی ہے — صرف وال کلاک نہیں بلکہ پڑھے گئے بائٹس اور چھوئی گئی قطاروں کے طور پر رپورٹ کیا جاتا ہے۔ |
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"
رنز تازہ پروسیس اسٹارٹس پر کم از کم پانچ بار دہرائے جاتے ہیں، پنڈ ہارڈویئر پروفائلز پر، ایک وقت میں ایک سسٹم۔ ڈیٹاسیٹس کانٹینٹ-ایڈریسڈ ہیں؛ کوئری سیٹس منجمد فائلیں ہیں، رن ٹائم پر تیار نہیں کی جاتیں۔ ہارنس کی تفصیل آج کمٹ ہو رہی ہے؛ ہارنس نتائج کے ساتھ شائع ہوگا۔
ماپے گئے، مشروط، قابلِ تکرار۔
ہر قطار اوپر درج rig پر ایک حقیقی رن ہے، اس کے ساتھ چھپے recall gate پر۔ فائدے کی سطح فزیکل ترتیب ہے: اسی متصل سب سیٹ پر ہمارا Mojo اسکین raw FAISS کے برابر ہے — ذیل کا فرق key-partitioned ترتیب کا فائدہ ہے، تیز distance kernel کا نہیں۔ یہ prototype اعداد ہیں، جنہیں harness کے پختہ ہونے کے ساتھ مکمل fairness contract کے تحت دوبارہ چلایا جاتا ہے۔
| ورک لوڈ | سیٹ اَپ + recall gate | ماپا گیا نتیجہ (M4 Max، single-thread، in-process) |
|---|---|---|
| فلٹرڈ سلائس · 0.1% sel | N=1,000,000 D=128 K=10، warm، recall 1.000 (exact) | partition-slice p50 0.013 ms — ترتیب کا فائدہ: full-scan کے مقابلے ~373×، scatter-gather کے مقابلے ~19×۔ اسی سب سیٹ پر FAISS Flat: 0.040 ms (tie — ثابت کرتا ہے کہ فائدہ ترتیب میں ہے، kernel میں نہیں)۔ |
| فلٹرڈ سلائس · 0.4% sel | N=1,000,000 D=128 K=10، warm، recall 1.000 (exact) | p50 0.032 ms — full-scan کے مقابلے ~128×، scatter-gather کے مقابلے ~10.8×۔ FAISS Flat control 0.035 ms (tie)۔ |
| فلٹرڈ سلائس · 1.6% sel | N=1,000,000 D=128 K=10، warm، recall 1.000 (exact) | p50 0.112 ms — full-scan کے مقابلے ~42×، scatter-gather کے مقابلے ~10.3×۔ FAISS Flat control 0.120 ms (tie)۔ |
| جائنٹ پارٹیشن ریسکیو | N=400,000 D=128 میں 247k rows، nprobe calibrated، recall 0.9915 (floor 0.98) | IVF-within-partition وہاں ترتیب کا فائدہ بحال کرتا ہے جہاں exact slice کمزور پڑتی ہے: exact slice 1.71 ms → IVF 0.033 ms۔ IVF کے بغیر، ایک جائنٹ پارٹیشن صرف ~4–5× رکھتی ہے۔ |
| منضبط auto-nprobe | N=1,000,000 D=128 Q=500 nlist=1000، recall 0.998 پر قائم (floor 0.98) | FIND baseline nprobe=32 پر 0.28–0.31 ms → منضبط auto-nprobe=8 پر 0.081–0.088 ms۔ Recall floor سے اوپر رہتا ہے — کوئی خاموش recall-for-speed تبادلہ نہیں۔ |
| FIND بمقابلہ FAISS control | Iso-recall، یکساں ٹرانسپورٹ، دونوں in-process، N=1,000,000 D=128 | Telys 0.073–0.074 ms @0.998 بمقابلہ raw FAISS 0.080 ms @0.999 — برابری سے قدرے آگے۔ Scale پر منحصر: N=200k پر پیچھے (0.74×)، بڑے memory-bound N پر ~1.6× تک۔ FAISS معیار، Mojo-accelerated۔ |
| GIL-فری کنکرنسی | N=200,000 D=128، 12 perf cores، in-process Mojo IVF kernel | FIND throughput 8 threads پر ×6.9 بڑھتا ہے (15,128 → 104,756 qps)۔ Throughput scaling، فی-کوئری لیٹنسی نہیں؛ server engines سے موازنہ نہیں۔ |
| Insert-to-recall تازگی | Base N=100,000، M=300 inserts، D=128، in-process | ابھی داخل کیا گیا ویکٹر اگلی ہی کوئری میں top-1 ہے: recall@1-of-new = 1.000۔ Insert p50 0.3 µs۔ یہ correctness gate ہے، throughput headline نہیں۔ |
اوپر کا ہر خانہ bench/results/ میں ایک نامزد اسکرپٹ اور محفوظ خام آؤٹ پٹ سے منسلک ہے (filtered_impact.txt، partitioned.txt، partition_acceptance.txt، opt.txt، telys.txt، concurrency.txt، freshness.txt)۔ persistence reopen عدد دوبارہ ماپے گئے خام نمونے تک روکا گیا ہے۔ ہر multiplier اپنی مذکور شرائط سے باہر ایک hypothesis ہے۔
کوڈ کے لیے بنایا — اور کوڈ بینچ مارک پر پرکھا۔
Telys کوڈ ریٹریو کرتا ہے، اس لیے کوالٹی کا معیار CoIR ہے، نہ کہ کوئی عمومی متن کا suite۔ LexicalCodeIndex کو mteb SearchProtocol کے طور پر لپیٹ کر bm25s baselines کے یکساں path پر mteb.evaluate سے اسکور کیا گیا — کوئی methodology کا فرق نہیں، کوئی self-scoring نہیں۔ Baselines شائع شدہ CoIR-paper کے اعداد نہیں بلکہ 2026-07-21 کے reproducible رنز ہیں (ان میں سے کئی دوبارہ نہیں چلتے)۔ Metric: nDCG@10۔
| CoIR ٹاسک | multigram | bm25-ref | bm25-code | کوڈ-لغوی · بھیجا گیا | بہترین 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 بمقابلہ ہر ٹاسک کے مضبوطترین baseline کا 0.445 († bm25-ref / bm25-code میں سے بہتر، فی ٹاسک) — اور multigram اوسط سے 2.6 گنا زیادہ۔ واحد شکست، AppsRetrieval، ہر lexical طریقے کے لیے صفر کے قریب ہے: طویل مسئلے کے بیانات بمقابلہ کوڈ — یہ embedding کا علاقہ ہے۔
کوڈ ٹوکنز + BM25
شناختکار اسی طرح تقسیم ہوتے ہیں جیسے کوڈ لکھا جاتا ہے — camelCase، snake_case، dotted paths — سادہ IDF/BM25 کو فیڈ کرتے ہوئے۔ یہ اکیلا اکثر ٹاسکس جیت لیتا ہے: CodeTransOceanContest کسی tuning سے پہلے 0.478 سے 0.600 پر پہنچ جاتا ہے۔
Stopwords ہٹائے، lite stemming
انگریزی stopwords ہٹائے گئے اور ایک lite suffix-stemmer تاکہ قدرتی زبان کے سوالات کوڈ ٹوکنز سے ہمآہنگ ہوں — وہ lever جو SyntheticText2SQL کو شکست سے 0.441 پر لے آتا ہے۔
k1 = 1.8 · b = 1.0
shipped defaults، Algenta-tuned on CoIR: بھاری term-frequency saturation اور مکمل length normalization — وہ lever جو StackOverflowQA کو پلٹ دیتا ہے۔
ہر سیل ایک اسکرپٹ — bench/mteb_code_lexical.py — سے reproduce ہوتا ہے، جو دونوں اطراف کو یکساں mteb.evaluate call سے چلاتا ہے (رنز 2026-07-21)۔ code-lexical وہی index ہے جو Telys اپنے shipped defaults پر بھیجتا ہے۔
جیتیں، برابریاں، اور ہاریں — تحریر میں۔
اشاعت کا فارمیٹ پہلا نمبر آنے سے پہلے طے ہو جاتا ہے، تاکہ نمبر اسے موڑ نہ سکیں۔
جہاں ہم ہارتے ہیں، تحریر میں
ہر اسکور کارڈ میں ایک "جہاں ہم ہارتے ہیں" سیکشن اور ایک "جہاں ہم صرف FAISS کے برابر ہیں" سیکشن ہوتا ہے، دونوں سیلز سے خودکار آباد۔ اگر کوئی بھی خالی ہو تو رپورٹ بلڈ نہیں ہوتی۔
ہمارے بغیر فیلڈ دوبارہ تیار کریں
ہارنس Telys کو خارج کر کے چلتا ہے، تاکہ کوئی شکی شخص صرف کمپیریٹر اور کنٹرول نمبر خود تیار کر سکے اور تصدیق کر سکے کہ ہر حریف کو اس کی اپنی گائیڈ کے مطابق ٹیون کیا گیا — configs کمٹ اور وینڈر ڈیفالٹس کے خلاف ڈف کیے گئے۔
ہر سیل سیمپلز تک قابلِ ردِّ عمل ہے
ہر شائع شدہ سیل اپنے خام فی-آپریشن سیمپلز اور انہیں تیار کرنے والی عین اسکرپٹ سے منسلک ہے۔ نتائج صرف اضافی ہیں، انجن ریویژن اور اس کے اسٹیٹک لنک کردہ بنڈلڈ ڈیپنڈنسی ورژنز سے کلید بند۔
یہ prototype نمبر ہیں، ہر ایک اپنی شرائط کے ساتھ۔ ہمیں اس معاہدے پر — اور ان اعداد پر جیسے جیسے ہم انہیں مکمل harness کے تحت دوبارہ چلاتے ہیں — جوابدہ ٹھہرائیں۔