Fly-inspired hashing improves memory retrieval rankings, but not speed or storage

An AI assistant that remembers preferences or earlier conversations needs a way to retrieve the right information later. One approach converts stored passages into numerical vectors, then searches for vectors close to a new question. Hashing compresses those vectors into binary representations, trading some retrieval accuracy for compactness.

In the preprint FlyHash for LLM Agent Memory: An Empirical Validation and a New Application, Mohan Bheemadolu and Chrisogonas O. Odhiambo investigate a hashing method inspired by fruit-fly olfaction. Their reported result has two parts: FlyHash delivers better rankings than SimHash under the study’s comparison protocol, but costs more storage and search time in the implementations tested.

From odor coding to memory search

FlyHash is an existing algorithm, not a new invention of this paper. It projects an input vector through sparse random connections into a larger pool of units. A winner-take-all step keeps only the strongest responses, producing a binary pattern with relatively few active positions. The authors’ main implementation uses signed projection weights.

SimHash, the comparison method, instead uses random hyperplanes to produce a binary code directly. Each output position records which side of a hyperplane the input occupies.

The crucial experimental distinction concerns what counts as a bit budget. The authors fix FlyHash’s pool at 2,000 positions and vary the number of winners, while giving SimHash that many output positions. They call this a matched-active-bit protocol. Operationally, however, a FlyHash winner is a selected position within a larger pool, whereas SimHash’s budget describes its code width. This is not an equal-storage comparison.

The researchers report that initially confusing FlyHash’s pool width with its winner count reversed their results. Separating those parameters produced the advantage reported in the paper.

Better rankings across the tested datasets

The main experiments cover GloVe word vectors, MiniLM sentence embeddings, small handwritten-digit images and an MNIST subset. Each comparison uses 10 random projection seeds, with datasets and sampled queries held fixed.

Retrieval quality is measured using mean average precision, which rewards placing relevant items early in a ranking. For these experiments, relevance means membership in a query’s nearest-neighbor set under the original, unhashed vectors—not independently assessed usefulness to an agent.

FlyHash’s mean score exceeds SimHash’s at all five tested budgets on all four datasets. On GloVe, with 16 winners versus 16 SimHash output positions, the reported scores are 0.196 and 0.047. At 256, they rise to 0.705 and 0.469. The relative advantage therefore narrows as the budget increases. A separate GloVe sweep also reports FlyHash ahead across all 36 tested hyperparameter configurations.

These findings support the authors’ ranking-quality claim within this protocol. They do not establish an equivalent advantage per stored byte.

The resource costs change the picture

A packed 2,000-position FlyHash code occupies about 250 bytes, regardless of how many positions are active. SimHash’s packed codes occupy between 2 and 32 bytes across the tested budgets.

The researchers also compare FlyHash codes through their active-position sets. Because every code has the same number of winners, greater overlap gives the same ranking as smaller Hamming distance. This avoids comparing the entire dense pattern.

That change substantially reduces measured search time, but does not eliminate SimHash’s advantage. At the smallest budget, one experiment reports 15.77 milliseconds per query for dense FlyHash comparison, 0.71 milliseconds for sparse comparison and 0.40 milliseconds for SimHash. Explicit FlyHash index lists still require 16 times the storage of the corresponding packed SimHash codes.

A separate systems comparison is less favorable to hashing. On 5,000 GloVe records, an HNSW graph index reaches 0.9862 mean average precision at 0.060 milliseconds per query, outperforming both hash methods on quality and latency. Its storage cost is higher: 671.5 bytes per record. This is a single-scale comparison, not evidence that HNSW wins under every deployment constraint.

Testing relevance beyond vector proximity

The authors also construct 6,000 synthetic memory sentences about 150 named personas, with 150 queries and relevance labels defined by persona and fact rather than embedding distance. Using TF-IDF followed by dimensionality reduction, FlyHash again scores above SimHash across all tested budgets: 0.195 versus 0.038 at the smallest, and 0.392 versus 0.345 at the largest.

This tests retrieval against independently constructed labels, but remains a templated task rather than a benchmark of natural conversations or downstream answer accuracy. The MiniLM experiment contains only 100 sentences, and stronger compression alternatives are not benchmarked.

The preprint’s practical message is therefore narrow: FlyHash improves rankings over this hashing baseline under the stated protocol. It does not demonstrate a faster or smaller replacement, nor a general reason to abandon conventional vector indexes.