Model Compare | Zyeon UI

ready · blind arena — names stay hidden until you vote, and the one-shot lock records once

Prompt

A junior dev asks why search feels slow now that we are at 200k documents. Explain what a vector index actually does, when it starts paying for itself, and what it costs us — plain language, at most four short paragraphs.

Blind

Name hidden until you vote

Done

Short version: a vector index stops search from reading every document. Right now each query embeds the question and then scores all 200k vectors one at a time. That is a linear scan — the work grows exactly as fast as the corpus does, which is why it felt fine at 20k and hurts at 200k. An index (HNSW, IVF, ScaNN — the family matters less than the idea) groups similar vectors ahead of time. A query walks a small part of that structure and only opens the neighbourhoods that could plausibly hold a match: a few thousand comparisons instead of two hundred thousand. It starts paying for itself somewhere around 50k–100k vectors; below that a brute-force scan is already a couple of milliseconds and the index is pure overhead. Above it you pay in three currencies — memory (the graph sits next to the vectors, often +40% RAM), build time whenever a large batch lands, and exactness, because an approximate index can miss a true neighbour. That last one is a dial, not a defect: widen the search and you buy accuracy back with latency.

4.2s268 tok64 tok/s

Name hidden until you vote

Done

Great question! Let me walk through this step by step. What is a vector? When you embed a document, the model turns it into a list of numbers — a vector — that captures its meaning. Similar meanings end up close together in that space, which is why vector search can match "how do I cancel" against a document that says "terminating your subscription". What is an index? An index is a data structure that makes lookups faster. Databases have used them for decades. In the vector world the popular families are HNSW, IVF and product quantisation, each with different trade-offs around recall, memory and build time. HNSW builds a layered proximity graph, IVF partitions the space into cells and probes a handful of them, and product quantisation compresses vectors so that more of them fit in memory at once. When does it pay off? It depends! It depends on corpus size, embedding dimensionality, hardware, query volume, and how strict your recall requirements are. Many teams report significant benefits, though of course your mileage may vary, and I would encourage benchmarking on your own data before committing to any particular approach. What does it cost? There are trade-offs to consider around memory usage, index build time, and the approximate nature of the results. You will want to weigh these carefully against your own requirements and constraints.

2.3s412 tok182 tok/sfaster

Names stay hidden until your vote lands. One vote per pair, and it cannot be changed.

onVote has fired 0 times — hammering the button or Enter still records one; a new round reopens the lock and hides the names again.

ready · one side still streaming — voting only opens once both sides have finished

Prompt

A junior dev asks why search feels slow now that we are at 200k documents. Explain what a vector index actually does, when it starts paying for itself, and what it costs us — plain language, at most four short paragraphs.

atlas-4-turboNorthwind AI

Done

Short version: a vector index stops search from reading every document. Right now each query embeds the question and then scores all 200k vectors one at a time. That is a linear scan — the work grows exactly as fast as the corpus does, which is why it felt fine at 20k and hurts at 200k. An index (HNSW, IVF, ScaNN — the family matters less than the idea) groups similar vectors ahead of time. A query walks a small part of that structure and only opens the neighbourhoods that could plausibly hold a match: a few thousand comparisons instead of two hundred thousand. It starts paying for itself somewhere around 50k–100k vectors; below that a brute-force scan is already a couple of milliseconds and the index is pure overhead. Above it you pay in three currencies — memory (the graph sits next to the vectors, often +40% RAM), build time whenever a large batch lands, and exactness, because an approximate index can miss a true neighbour. That last one is a dial, not a defect: widen the search and you buy accuracy back with latency.

4.2s268 tok64 tok/s

meridian-2-largeHalcyon Labs

Streaming

Great question! Let me walk through this step by step. What is a vector? When you embed a document, the model turns it into a list of numbers — a vector — that captures its meaning. Similar meanings end up close together in that space, which is why vector search can match "how do I cancel" against a document that says "terminating your subscription". What is an index? An index is a data structure that makes lookups faster. Databases have used them for decades. In the vector world the popular families are HNSW, IVF and product quantisation, each with different trade-offs around recall, memory and build time. HNS

still streaming191 tok

Voting opens once both answers have finished.

Side B shows only a token count and “still streaming”; voting now records nothing — onVote has fired 0 times.

ready · one side failed — a failure still counts as finished, and a usable answer does beat a crash

Prompt

A junior dev asks why search feels slow now that we are at 200k documents. Explain what a vector index actually does, when it starts paying for itself, and what it costs us — plain language, at most four short paragraphs.

atlas-4-turboNorthwind AI

Done

Short version: a vector index stops search from reading every document. Right now each query embeds the question and then scores all 200k vectors one at a time. That is a linear scan — the work grows exactly as fast as the corpus does, which is why it felt fine at 20k and hurts at 200k. An index (HNSW, IVF, ScaNN — the family matters less than the idea) groups similar vectors ahead of time. A query walks a small part of that structure and only opens the neighbourhoods that could plausibly hold a match: a few thousand comparisons instead of two hundred thousand. It starts paying for itself somewhere around 50k–100k vectors; below that a brute-force scan is already a couple of milliseconds and the index is pure overhead. Above it you pay in three currencies — memory (the graph sits next to the vectors, often +40% RAM), build time whenever a large batch lands, and exactness, because an approximate index can miss a true neighbour. That last one is a dial, not a defect: widen the search and you buy accuracy back with latency.

4.2s268 tok64 tok/s

meridian-2-largeHalcyon Labs

Failed

Upstream returned 503 after 3 attempts — the provider is rate limiting this key.

One vote per pair, and it cannot be changed.

“Retry this side” reruns only the failed side; not a word of A moves — onVote has fired 0 times.

ready · only one side arrived — the empty slot keeps the same geometry

Prompt

A junior dev asks why search feels slow now that we are at 200k documents. Explain what a vector index actually does, when it starts paying for itself, and what it costs us — plain language, at most four short paragraphs.

atlas-4-turboNorthwind AI

Streaming

Short version: a vector index stops search from reading every document. Right now each query embeds the question and then scores all 200k vectors one at a time. That is a linear scan — the work grows exactly as fast as the corpus does, which is why it felt fine at 20k and hurts at 200k. An index (HNSW, IVF, ScaNN — the family matters le

still streaming96 tok

Second answer pending

The slot stays open so the comparison does not jump sideways when this answer arrives.

Voting opens once both answers have finished.

loading — the skeleton mirrors the real layout: prompt bar + two columns + vote bar

empty — the empty state explains what a comparison is for, not just “no data”

Nothing to compare yet

A comparison sends one prompt to two models and puts the answers side by side. You read both, then vote — the vote is what turns a hunch about which model is smarter into a number you can defend.

One prompt, two answers
Latency and tokens per side
One vote per pair, optionally blind

error — the whole comparison failed to load; Try again runs the real reload branch

The comparison could not be loaded

Neither answer came back, so there is nothing to judge. No vote was recorded.