As regras são publicadas antes
dos números.
Telys está em 0.1.0b4 — estes são números validados em protótipo em um rig divulgado, não números de produção. Um resultado só conta quando medido com recall equivalente em hardware equivalente, com amostras brutas e o script que as gerou. As regras abaixo ainda vinculam cada número: o que medimos, contra quem, e as formas pelas quais somos obrigados a perder.
Regras que o harness impõe, não ressalvas que acrescentamos.
Cada regra abaixo está codificada como uma verificação automática no harness de benchmark. Uma execução que viole qualquer uma não recebe nota de rodapé — é marcada como inválida e excluída de todos os scorecards.
“Todo multiplicador é uma hipótese até ser medido com recall equivalente e hardware equivalente, com amostras brutas e um script de reprodução publicado.”
Doutrina de benchmark TelysUm benchmark que não podemos perder não tem valor
O scorecard gerado traz uma seção obrigatória Onde perdemos, preenchida automaticamente com cada célula em que um comparador vence. Se essa seção estiver vazia, a geração do relatório falha — uma vitória absoluta é tratada como harness quebrado, não como triunfo.
Embedded vs embedded é a comparação justa
Nunca colocamos em destaque uma chamada in-process contra um concorrente que responde via TCP. Contra bibliotecas embedded, in-process vs in-process é o transporte honesto. Contra servidores, o transporte é pareado de igual para igual, ou o número é anotado e mantido fora dos destaques.
Níveis equivalentes, ou sem comparação
Uma execução em memória nunca é comparada a um concorrente que faz fsync a cada commit. Todo resultado declara seu nível de durabilidade — in_mem, wal_async ou wal_fsync — e o harness rejeita qualquer comparação entre níveis distintos.
Nunca sugerimos que superamos o FAISS quando estamos chamando o FAISS
FAISS é o núcleo ANN que Telys incorpora — uma fundação, não um adversário. Todo scorecard vetorial exibe primeiro a célula de travessia FAISS puro; onde há empate, o empate é impresso. Vitórias honestas são reivindicadas em outro lugar: kernels de rerank, planejamento filtrado e o engine ao redor do índice.
Cada comparador isola uma afirmação.
Um único número de leaderboard confunde algoritmo, transporte, durabilidade e formato de armazenamento. O conjunto é escolhido para que cada comparação isole exatamente uma variável — com um controle no mesmo nó sob cada destaque.
| Sistema | Formato | O que a comparação isola |
|---|---|---|
| FAISS (mesmo nó) | Baseline de controle | O piso, não um adversário. Telys incorpora FAISS, portanto o número FAISS puro é o baseline que somos; o delta publicado é o que o engine acrescenta ao redor dele — com a mesma string de índice e o mesmo recall medido. |
| Postgres + pgvector | Relacional + vetorial | A consulta híbrida filtrada: se empurrar um predicado escalar para o caminho de candidatos supera um índice que precisa buscar em excesso ou pós-filtrar, com recall igual entre diferentes seletividades de filtro. |
| LanceDB / Chroma | Biblioteca embedded | Os concorrentes mais próximos, in-process vs in-process — o único lugar em que um número in-process é um destaque justo. Mesmo piso ANN; a comparação isola o engine ao redor dele: espaço unificado de row-id, cold-open, footprint. |
| Qdrant / Milvus | Servidor | Qualidade de algoritmo — recall a k fixo — separada das viagens de rede. A latência é reportada com o salto de servidor anotado e nunca é destacada contra uma chamada in-process. |
| Pinecone | Serviço gerenciado | Recall a k fixo e throughput por unidade de computação. Latência bruta contra um engine embarcado é recusada como manchete; o controle no mesmo nó carrega a afirmação de qualidade. |
| DuckDB / ClickHouse | Engine analítico | Scan e agregação sobre o mesmo arquivo Parquet físico, separando a vantagem do formato de armazenamento da vantagem do engine. Engines analíticos vetorizados se destacam aqui; suas vitórias são publicadas. |
O que é medido.
A matriz define medições, não vitórias hipotéticas. Cada célula de latência reporta a distribuição completa — nunca apenas a média — sob carga oferecida em loop aberto. Cada célula de velocidade está vinculada a um gate de recall calculado pelo harness contra o ground truth entregue; uma célula cujo gate não é atingido é emitida como inválida e não pode entrar em um scorecard.
| Workload | Configuração | O que mede |
|---|---|---|
| cold-open | Page cache descartado, início de processo limpo | Tempo do início do processo até a primeira query bem-sucedida — mmap de segmento e mapeamento de index-sidecar versus boot do servidor e recuperação. Medido separadamente do estado estacionário, nunca incorporado a ele. |
| exact FLAT | Busca exata por força bruta, f32 e int8 | O piso do kernel de distância a recall 1.0 por construção, contra a baseline exata no mesmo nó sobre os mesmos buffers. Cada célula int8 reporta seu delta de recall versus f32, de modo que a perda por quantização nunca é ocultada. |
| híbrido filtrado | Predicado escalar + top-k, varrido em três seletividades | Latência a recall igual conforme o filtro se estreita, mais a estratégia escolhida pelo planner por célula — pré-filtro e exato, pré-filtro e IVF, ou busca e pós-filtro — tornando a decisão adaptativa auditável. |
| full scan | Scan e agregação de coluna completa | Throughput colunar bruto sobre Parquet compartilhado, engine versus engine sobre bytes idênticos. |
| varredura seletiva | Scan por predicado a baixas taxas de correspondência | Se a poda por min-max de footer e zone-map realmente ignora trabalho — reportado como bytes lidos e linhas tocadas, não apenas tempo de relógio. |
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"
As execuções se repetem pelo menos cinco vezes em inícios de processo limpos, em perfis de hardware fixos, um sistema por vez. Os datasets são endereçados por conteúdo; os conjuntos de queries são arquivos congelados, não gerados em tempo de execução. A especificação do harness é confirmada hoje; o harness é publicado junto com os resultados.
Medido, condicionado, reproduzível.
Cada linha é uma execução real no rig nomeado acima, no gate de recall impresso ao lado. A superfície de ganho é o layout físico: sobre um subconjunto contíguo idêntico, nosso scan Mojo empata com o FAISS bruto — o delta abaixo é o que o layout particionado por chave proporciona, não um kernel de distância mais rápido. Estes são números de protótipo, reexecutados sob o contrato completo de imparcialidade conforme o harness amadurece.
| Carga de trabalho | Setup + gate de recall | Resultado medido (M4 Max, thread única, in-process) |
|---|---|---|
| Slice filtrado · sel 0,1% | N=1.000.000 D=128 K=10, warm, recall 1,000 (exato) | partition-slice p50 0,013 ms — ganho de layout vs scan completo ~373×, vs scatter-gather ~19×. FAISS Flat no subconjunto idêntico: 0,040 ms (empate — prova que o ganho é de layout, não de kernel). |
| Slice filtrado · sel 0,4% | N=1.000.000 D=128 K=10, warm, recall 1,000 (exato) | p50 0,032 ms — ~128× vs scan completo, ~10,8× vs scatter-gather. Controle FAISS Flat 0,035 ms (empate). |
| Slice filtrado · sel 1,6% | N=1.000.000 D=128 K=10, warm, recall 1,000 (exato) | p50 0,112 ms — ~42× vs scan completo, ~10,3× vs scatter-gather. Controle FAISS Flat 0,120 ms (empate). |
| Resgate de partição gigante | 247k linhas em N=400.000 D=128, nprobe calibrado, recall 0,9915 (piso 0,98) | IVF dentro da partição restaura o ganho de layout onde um slice exato degrada: slice exato 1,71 ms → IVF 0,033 ms. Sem IVF, uma única partição gigante sustenta apenas ~4–5×. |
| Auto-nprobe governado | N=1.000.000 D=128 Q=500 nlist=1000, recall mantido em 0,998 (piso 0,98) | FIND 0,28–0,31 ms no nprobe=32 de base → 0,081–0,088 ms com auto-nprobe=8 governado. O recall permanece acima do piso — sem troca silenciosa de recall por velocidade. |
| FIND vs controle FAISS | Iso-recall, mesmo transporte, ambos in-process, N=1.000.000 D=128 | Telys 0,073–0,074 ms @0,998 vs FAISS bruto 0,080 ms @0,999 — paridade a ligeiramente à frente. Dependente de escala: atrás (0,74×) em N=200k, até ~1,6× apenas em N grande com memória limitante. Qualidade FAISS, acelerado por Mojo. |
| Concorrência sem GIL | N=200.000 D=128, 12 núcleos de desempenho, kernel Mojo IVF in-process | Throughput do FIND escala ×6,9 em 8 threads (15.128 → 104.756 qps). Escala de throughput, não latência por consulta; sem comparação com engines de servidor. |
| Frescor insert-to-recall | Base N=100.000, M=300 inserts, D=128, in-process | Um vetor recém-inserido é top-1 na próxima consulta: recall@1-of-new = 1,000. Insert p50 0,3 µs. Gate de correção, não manchete de throughput. |
Cada célula acima rastreia até um script nomeado e uma saída bruta salva em bench/results/ (filtered_impact.txt, partitioned.txt, partition_acceptance.txt, opt.txt, telys.txt, concurrency.txt, freshness.txt). O número de reabertura de persistência está retido aguardando uma amostra bruta re-medida. Todo multiplicador é uma hipótese fora das condições impressas em cada linha.
Construído para código — e avaliado em um benchmark de código.
Telys recupera código, portanto o critério de qualidade é CoIR, não uma suíte de texto geral. LexicalCodeIndex é encapsulado como um mteb SearchProtocol e pontuado por mteb.evaluate no mesmo caminho dos baselines bm25s — sem lacuna metodológica, sem autoavaliação. Os baselines são execuções reproduzíveis de 2026-07-21, não as cifras publicadas no artigo CoIR (várias não reproduzem). Métrica: nDCG@10.
| Tarefa CoIR | multigram | bm25-ref | bm25-code | código-léxico · disponível | vs. melhor 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 | ❌ |
| Média | 0.186 | 0.445 † | 0.488 | 7/8 | |
Sete vitórias em oito; média de 0.488 vs. 0.445 do baseline mais forte por tarefa († melhor entre bm25-ref / bm25-code, por tarefa) — e 2,6× a média multigram. A única derrota, AppsRetrieval, fica próxima de zero para todo método lexical: enunciados longos contra código é território de embeddings.
Tokens cientes de código + BM25
Identificadores segmentados conforme o código é escrito — camelCase, snake_case, caminhos com ponto — alimentando IDF/BM25 simples. Só isso vence a maioria das tarefas: CodeTransOceanContest passa de 0.478 para 0.600 sem nenhum ajuste.
Stopwords removidas, stemming leve
Stopwords do inglês removidas e um stemmer de sufixo leve para alinhar consultas em linguagem natural com tokens de código — o lever que transforma SyntheticText2SQL de derrota em 0.441.
k1 = 1,8 · b = 1,0
Os padrões shipped, ajustados pelo Algenta no CoIR: saturação de frequência de termos mais intensa e normalização de comprimento total — o lever que vira StackOverflowQA.
Cada célula reproduz a partir de um único script — bench/mteb_code_lexical.py — executando ambos os lados pela mesma chamada mteb.evaluate (execuções de 2026-07-21). code-lexical é o índice que Telys entrega, em seus padrões shipped.
Vitórias, empates e derrotas — em print.
O formato de publicação é definido antes de o primeiro número existir, para que os números não possam moldá-lo.
Onde perdemos, impresso
Cada scorecard traz uma seção Onde perdemos e uma seção Onde apenas empatamos com FAISS, ambas preenchidas automaticamente pelas células. O relatório falha ao compilar se alguma delas estiver vazia.
Reproduza os resultados sem nós
O harness roda com Telys excluído, para que um cético possa reproduzir sozinho os números dos comparadores e do controle e confirmar que cada concorrente foi ajustado conforme seu próprio guia — configs confirmadas e comparadas com os padrões do fornecedor.
Cada célula rastreia até as amostras
Cada célula publicada vincula suas amostras brutas por operação e o script exato que as produziu. Os resultados são append-only, indexados pela revisão do engine e pelas versões das dependências que ele vincula estaticamente.
Estes são números de protótipo, cada um acompanhado de suas condições. Cobre-nos por este contrato — e pelos números conforme os reexecutamos sob o harness completo.