Ask most search boxes for "models that verify their own reasoning" and you get back papers containing those words. What you wanted were papers about that idea — including the ones that call it something else entirely.

The tradeoff nobody mentions

Embeddings are cheap to generate and expensive to query badly. We learned this the direct way: with ~44,000 paper embeddings and no vector index, every "similar papers" lookup did a full scan and timed out after nine seconds.

The fix was two lines of intent:

1. Add an HNSW index over the embedding column.
2. Make sure the query actually uses it — a constant probe vector, not a joined column.

The same query now returns in under a second.

What this powers

Similar-paper suggestions in the reader, and topic watching for labs. Both lean on the same index, so improving it improves everything downstream.

What vector search buys

Keyword search matches vocabulary. Vector search matches meaning, approximately — which means it can retrieve a paper solving your problem in a different subfield's terminology.

That case is exactly where keyword search fails and where the value is highest, because a paper using unfamiliar language is one you were never going to find by guessing its words.

What it costs

Storage, and it is not small. Embedding a corpus produces one dense vector per document, and vectors do not compress well. Index structures add more on top.

On this project, 45,000 embeddings occupied 216 MB and drove a 500 MB database to 99% of quota. The compute to produce them was nearly free by comparison — twenty-five days of background local GPU time, but no marginal cost.

The lesson we actually learned

We eventually removed the embedding store, and the reason is worth recording: the feature it powered had been dropped from the interface months earlier. The index sat there, consuming 90% of the remaining headroom, serving a component no page rendered.

Nothing detected this. There was no usage metric on the feature and no alert on the index, so the cost was invisible until a capacity check surfaced it.

What we would do differently

Tie the artefact to the feature. If a component is removed, the data it required should be flagged, not silently retained. And measure retrieval quality against keyword search on your own queries before paying for the index at all — semantic search is better on average and not on every query.

When it is worth it

When your corpus is large, your users' vocabulary differs from your authors', and the feature is actually shipped. Two out of three is how you end up with an expensive index nobody queries.