Building SAM: Associative Semantic Retrieval for HLQuery

#ai #nlp #showdev #systemdesign

While building HLQuery, I kept running into the same limitation that exists across many search systems today:

Humans search through meaning, but engines still mostly search through words.

A user types:

“queen of pop”
“NYC restaurants”
“linux creator”

while actually expecting:

Madonna
New York City
Linus Torvalds

Traditional keyword search is extremely fast and deterministic, but it struggles when language becomes indirect. Vector search improves this significantly, although it can sometimes become difficult to inspect or tune under real workloads.

That is what led me to build SAM for HLQuery.

SAM is an associative semantic layer designed to connect related concepts directly inside the retrieval pipeline. Instead of depending only on exact matches or pure embedding proximity, SAM builds explicit semantic relationships between entities, aliases, abbreviations, and contextual meanings.

For example:

text id="f8r0qt"
"NYC" ↔ "New York City"
"queen of pop" ↔ "Madonna"
"AI chip company" ↔ "Nvidia"

The goal is not to replace vector search or traditional indexing. It is to enrich retrieval by making searches feel more contextual and less mechanical.

One of the most interesting things during testing was how much associative retrieval improved smaller and noisier queries. Abbreviations, indirect references, and vague searches started behaving far more naturally without requiring endless manual synonym configurations.

HLQuery itself is written in C++ and focuses heavily on performance, hybrid retrieval, and low-level control over indexing internals. Current ingestion benchmarks are around ~43k–45k docs/sec, with roughly 100k documents becoming searchable in ~2.6 seconds on commodity hardware.

I increasingly think the future of search will not belong exclusively to keyword systems or vector systems.

It will likely be hybrid: