Las reglas se publican antes que
los números.
Telys es 0.1.0b4 — estas son cifras validadas en prototipo sobre un equipo declarado, no números de producción. Un resultado solo cuenta cuando se mide con recall equiparado en hardware equiparado, con muestras brutas y el script que las generó. Las reglas siguientes siguen vinculando cada número: qué medimos, frente a quién y en qué casos estamos obligados a perder.
Reglas que impone el harness, no advertencias que añadimos.
Cada regla a continuación está codificada como una verificación automática en el harness de benchmark. Una ejecución que la infrinja no recibe una nota al pie — se marca como inválida y queda excluida de todos los scorecards.
“Todo multiplicador es una hipótesis hasta que se mide con recall equivalente y hardware equivalente, con muestras brutas y un script de reproducción publicado.”
Doctrina de benchmark de TelysUn benchmark en el que no podemos perder no vale nada
El scorecard generado incluye una sección obligatoria Dónde perdemos, completada automáticamente con cada celda que gana un comparador. Si esa sección está vacía, la generación del informe falla — un resultado perfecto se trata como un harness roto, no como un triunfo.
Embebido vs embebido es la comparación justa
Nunca encabezamos con una llamada en proceso frente a un competidor que responde por TCP. Contra bibliotecas embebidas, en proceso vs en proceso es el transporte honesto. Contra servidores, el transporte se iguala como para como, o el número se anota y queda fuera de los titulares.
Niveles equivalentes, o sin comparación
Una ejecución en memoria nunca se puntúa frente a un competidor que hace fsync en cada commit. Cada resultado declara su nivel de durabilidad — in_mem, wal_async o wal_fsync — y el harness falla de forma terminante ante cualquier comparación entre niveles.
Nunca insinuamos que superamos a FAISS cuando estamos llamando a FAISS
FAISS es el núcleo ANN que Telys embebe — una base, no un adversario. Cada scorecard vectorial muestra primero la celda de traversal de FAISS puro; donde hay empate, el empate se imprime. Las victorias honestas se reclaman en otro lugar: kernels de reranking, planificación filtrada y el motor que rodea el índice.
Cada comparador aísla una afirmación.
Un único número en un ranking confunde algoritmo, transporte, durabilidad y formato de almacenamiento. El conjunto se elige de modo que cada comparación aísle exactamente una variable — con un control en el mismo nodo bajo cada titular.
| Sistema | Forma | Qué aísla la comparación |
|---|---|---|
| FAISS (mismo nodo) | Línea base de control | El suelo, no un adversario. Telys embebe FAISS, por lo que el número de FAISS puro es la línea base que somos; el delta publicado es lo que el motor añade a su alrededor — con la misma cadena de índice y el mismo recall medido. |
| Postgres + pgvector | Relacional + vectorial | La consulta híbrida filtrada: si empujar un predicado escalar hacia la ruta de candidatos supera a un índice que debe sobre-recuperar o post-filtrar, con recall igual entre selectividades de filtro. |
| LanceDB / Chroma | Biblioteca embebida | Los competidores más cercanos, en proceso vs en proceso — el único lugar donde un número en proceso es un titular justo. Mismo suelo ANN; la comparación aísla el motor que lo rodea: espacio de row-id unificado, cold-open, huella. |
| Qdrant / Milvus | Servidor | Calidad del algoritmo — recall a k fijo — separada de los viajes de red. La latencia se reporta con el salto de servidor anotado y nunca se encabeza frente a una llamada en proceso. |
| Pinecone | Servicio gestionado | Recall a k fijo y rendimiento por unidad de cómputo. La latencia bruta frente a un motor embebido se rechaza como titular; el control en el mismo nodo sostiene la afirmación de calidad. |
| DuckDB / ClickHouse | Motor analítico | Escaneo y agregación sobre el mismo archivo físico Parquet, de modo que la ventaja del formato de almacenamiento se separa de la del motor. Los motores analíticos vectorizados destacan aquí; sus victorias se publican. |
Qué se mide.
La matriz define mediciones, no victorias hipotéticas. Cada celda de latencia reporta la distribución completa — nunca solo la media — bajo carga ofrecida en bucle abierto. Cada celda de velocidad está vinculada a un umbral de recall calculado por el harness contra la verdad de referencia entregada; una celda que no supera el umbral se emite como inválida y no puede entrar en un scorecard.
| Carga de trabajo | Configuración | Qué mide |
|---|---|---|
| cold-open | Caché de páginas descartada, inicio de proceso limpio | Tiempo desde el inicio del proceso hasta la primera consulta exitosa — mmap de segmento y mapeo de índice auxiliar frente a arranque y recuperación del servidor. Se mide de forma independiente del estado estacionario, nunca integrado en él. |
| exact FLAT | Búsqueda exacta por fuerza bruta, f32 e int8 | El piso del kernel de distancia a recall 1.0 por construcción, frente a la línea base exacta en el mismo nodo sobre los mismos buffers. Cada celda int8 reporta su delta de recall respecto a f32, de modo que la pérdida por cuantización nunca queda oculta. |
| híbrido filtrado | Predicado escalar + top-k, barrido en tres selectividades | Latencia a recall igual a medida que el filtro se estrecha, más la estrategia elegida por el planificador por celda — pre-filtro y exacto, pre-filtro e IVF, o búsqueda y post-filtro — de modo que la decisión adaptativa es auditable. |
| full scan | Escaneo y agregación de columna completa | Rendimiento columnar bruto sobre Parquet compartido, motor contra motor sobre bytes idénticos. |
| escaneo selectivo | Escaneo por predicado a tasas de coincidencia bajas | Si la poda por min-max de footer y zone-map realmente omite trabajo — reportado como bytes leídos y filas tocadas, no solo tiempo de reloj. |
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"
Las ejecuciones se repiten al menos cinco veces en inicios de proceso limpios, sobre perfiles de hardware fijados, un sistema a la vez. Los conjuntos de datos están direccionados por contenido; los conjuntos de consultas son archivos congelados, no generados en tiempo de ejecución. La especificación del harness se confirma hoy; el harness se publica junto con los resultados.
Medidos, condicionados, reproducibles.
Cada fila es una ejecución real en el equipo indicado arriba, al umbral de recall impreso junto a ella. La ventaja está en la disposición física: sobre un subconjunto contiguo idéntico nuestro escaneo Mojo iguala a FAISS en bruto — el delta siguiente es lo que aporta la disposición particionada por clave, no un kernel de distancia más rápido. Son cifras de prototipo, que se vuelven a ejecutar bajo el contrato de equidad completo a medida que el harness madura.
| Carga de trabajo | Configuración + umbral de recall | Resultado medido (M4 Max, hilo único, en proceso) |
|---|---|---|
| Slice filtrado · sel 0,1% | N=1.000.000 D=128 K=10, caliente, recall 1,000 (exacto) | partition-slice p50 0,013 ms — ventaja de disposición vs escaneo completo ~373×, vs scatter-gather ~19×. FAISS Flat en el mismo subconjunto: 0,040 ms (empate — demuestra que la ventaja es la disposición, no el kernel). |
| Slice filtrado · sel 0,4% | N=1.000.000 D=128 K=10, caliente, recall 1,000 (exacto) | p50 0,032 ms — ~128× vs escaneo completo, ~10,8× vs scatter-gather. Control FAISS Flat 0,035 ms (empate). |
| Slice filtrado · sel 1,6% | N=1.000.000 D=128 K=10, caliente, recall 1,000 (exacto) | p50 0,112 ms — ~42× vs escaneo completo, ~10,3× vs scatter-gather. Control FAISS Flat 0,120 ms (empate). |
| Rescate de partición gigante | 247k filas en N=400.000 D=128, nprobe calibrado, recall 0,9915 (mínimo 0,98) | IVF dentro de la partición restaura la ventaja de disposición donde un slice exacto degrada: slice exacto 1,71 ms → IVF 0,033 ms. Sin IVF, una sola partición gigante retiene solo ~4–5×. |
| Auto-nprobe gobernado | N=1.000.000 D=128 Q=500 nlist=1000, recall mantenido 0,998 (mínimo 0,98) | FIND 0,28–0,31 ms con nprobe=32 de referencia → 0,081–0,088 ms con auto-nprobe gobernado=8. El recall se mantiene por encima del mínimo — sin intercambio silencioso de recall por velocidad. |
| FIND vs control FAISS | Iso-recall, mismo transporte, ambos en proceso, N=1.000.000 D=128 | Telys 0,073–0,074 ms @0,998 vs FAISS en bruto 0,080 ms @0,999 — paridad o ligeramente por delante. Dependiente de escala: por detrás (0,74×) en N=200k, hasta ~1,6× solo con N grande limitado por memoria. Calidad FAISS, acelerado con Mojo. |
| Concurrencia sin GIL | N=200.000 D=128, 12 núcleos de rendimiento, kernel Mojo IVF en proceso | El throughput de FIND escala ×6,9 con 8 hilos (15.128 → 104.756 qps). Escalado de throughput, no latencia por consulta; sin comparación con motores de servidor. |
| Frescura insert-to-recall | Base N=100.000, M=300 inserciones, D=128, en proceso | Un vector recién insertado es top-1 en la siguiente consulta: recall@1-of-new = 1,000. Insert p50 0,3 µs. Umbral de corrección, no titular de throughput. |
Cada celda anterior se remonta a un script nombrado y una salida bruta guardada en bench/results/ (filtered_impact.txt, partitioned.txt, partition_acceptance.txt, opt.txt, telys.txt, concurrency.txt, freshness.txt). La cifra de reapertura de persistencia está retenida pendiente de una muestra bruta re-medida. Todo multiplicador es una hipótesis fuera de las condiciones impresas en cada fila.
Diseñado para código — y evaluado en un benchmark de código.
Telys recupera código, por lo que el listón de calidad es CoIR, no una suite de texto general. LexicalCodeIndex se envuelve como un mteb SearchProtocol y se puntúa mediante mteb.evaluate en la misma ruta que las líneas base bm25s — sin brecha metodológica, sin autopuntuación. Las líneas base son ejecuciones reproducibles del 2026-07-21, no las cifras publicadas en el artículo de CoIR (varias de ellas no se reproducen). Métrica: nDCG@10.
| Tarea CoIR | multigram | bm25-ref | bm25-code | code-lexical · publicado | vs mejor línea base |
|---|---|---|---|---|---|
| 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 | ❌ |
| Promedio | 0.186 | 0.445 † | 0.488 | 7/8 | |
Siete de ocho victorias; promedio de 0.488 frente a 0.445 de la línea base más fuerte por tarea († mejor entre bm25-ref / bm25-code, por tarea) — y 2.6× el promedio multigram. La única derrota, AppsRetrieval, roza el cero en todos los métodos léxicos: enunciados largos contra código es territorio de embeddings.
Tokens orientados a código + BM25
Los identificadores se dividen tal como se escribe el código — camelCase, snake_case, rutas con puntos — alimentando IDF/BM25 estándar. Esto solo gana la mayoría de las tareas: CodeTransOceanContest pasa de 0.478 a 0.600 sin ningún ajuste.
Sin stopwords, stemming ligero
Stopwords del inglés eliminadas y un stemmer de sufijos ligero para alinear consultas en lenguaje natural con tokens de código — la palanca que convierte SyntheticText2SQL de derrota en 0.441.
k1 = 1,8 · b = 1,0
Los valores por defecto publicados, ajustados por Algenta sobre CoIR: mayor saturación de frecuencia de término y normalización de longitud completa — la palanca que voltea StackOverflowQA.
Cada celda se reproduce desde un único script — bench/mteb_code_lexical.py — ejecutando ambos lados mediante la misma llamada a mteb.evaluate (ejecuciones del 2026-07-21). code-lexical es el índice que Telys publica, con sus valores por defecto.
Victorias, empates y derrotas — por escrito.
El formato de publicación se fija antes de que exista el primer número, de modo que los números no pueden doblarlo.
Dónde perdemos, por escrito
Cada scorecard incluye una sección Dónde perdemos y una sección Dónde solo igualamos a FAISS, ambas pobladas automáticamente desde las celdas. El informe falla al compilar si alguna está vacía.
Reproduce el campo sin nosotros
El harness se ejecuta con Telys excluido, de modo que un escéptico puede reproducir los números del comparador y del control por su cuenta y confirmar que cada competidor fue ajustado según su propia guía — configuraciones confirmadas y comparadas contra los valores predeterminados del proveedor.
Cada celda traza hasta las muestras
Cada celda publicada enlaza sus muestras brutas por operación y el script exacto que las produjo. Los resultados son de solo adición, indexados por la revisión del motor y las versiones de dependencias empaquetadas que enlaza estáticamente.
Son números de prototipo, cada uno acompañado de sus condiciones. Exígenos este contrato — y las cifras a medida que las volvamos a ejecutar bajo el harness completo.