Does your vector index meet its recall, latency and memory budgets?
Paste or drop one vector index as it is configured and used - the pgvector CREATE INDEX and the
query with its SET statements, a Qdrant collection and search body, or the FAISS or hnswlib code -
with workload.yaml (vectors, dimensions, k, target recall, p99, memory) and a parameter sweep if you
have one. Your browser reads every index and query and checks it: options pgvector refuses, a column
over the 2,000-dimension index limit, an ORDER BY operator the index cannot serve,
hnsw.ef_search below the LIMIT, a filtered query that comes back short, a PQ split that
does not divide the dimension, and an index that does not fit its memory, probes left at 1, quantized
search without rescoring, and the sweep row that meets the recall target inside the latency budget. Free,
before you sign in, and nothing is uploaded. Then pick a lane: the audit gives exact edits for
each finding and the operating point, or the fix lane writes the whole fixed files - and the
page re-checks both.
The companies, tables, collections, passwords and numbers in the examples are invented. The first three are audits (the first also carries a saved fix run of its edited files, one click after the audit), the last a fix run; each comes with a saved model reply, so you can see the whole page without signing in or spending a credit.
The audit rates the index configuration, the search settings, the memory and the evidence, confirms or dismisses every flag below, adds what rules cannot see, names the operating point the sweep supports, and gives exact before/after edits for each finding - which the page applies to your paste and re-checks.
What this does, and what it does not
The check is a reading of the text, not a database: nothing is built, loaded or queried. SQL is split into
statements with comments ignored, JSON bodies are parsed keeping the line of every key, and Python is read
line by line for the FAISS and hnswlib calls, so each flag points at the line it is about. Every index is read
with its type, metric, dimensions, build parameters and quantization, every query with its k or
LIMIT, ef, probes and filter and the index it can use, the workload with its budgets,
and the sweep row by row. The memory figure is an estimate from the parameters, not a measurement. The server,
its memory and CPU, the data distribution and the engine version are not visible: whether the embeddings are
unit length, which pgvector version runs, or whether the index may be rebuilt this week is a question you
answer in the note. A recall sweep with a few hundred real queries against exact ground truth - and for
pgvector EXPLAIN (ANALYZE) - remains the ground truth.
The paid lanes see your paste and the page's facts. Every quote and edit they return is checked against your paste, every edit and every returned file is put back and re-checked, and a reply that repeats a credential from your paste is called out. A paste stays in this browser unless you run a lane. Derived from the agent skill @wshobson/vector-index-tuning by Seth Hobson (wshobson/agents, MIT). Sources are listed in llms.txt.