Papers
arxiv:2611.05791

FlyHash for LLM Agent Memory: An Empirical Validation and a New Application

Published on Nov 4
· Submitted by
Mohan Bheemadolu
on Nov 10
Authors:

Abstract

FlyHash, a fruit-fly-inspired locality-sensitive hashing method, improves neighbor-structure preservation over SimHash for large language model agent memory retrieval under matched-bit protocols and genuine relevance labels, but it does not provide practical memory or latency advantages over SimHash or HNSW at ordinary scale.

Large language model (LLM) agents increasingly rely on external memory stores to retain information across conversations, typically via dense vector embeddings searched with approximate nearest-neighbor methods. The fruit fly's olfactory circuit computes a locality-sensitive hash of sensory input using a strikingly different mechanism - sparse random projection followed by winner-take-all competition - and prior work (Dasgupta et al., 2017) showed this scheme, dubbed FlyHash, preserves neighbor structure better per bit than conventional random-hyperplane hashing (SimHash) on several benchmarks. We apply FlyHash, to our knowledge for the first time, to LLM agent memory retrieval, and ask three questions a practitioner actually needs answered: does the quality advantage hold under a correctly matched-bit protocol (it does, robustly, across 10 seeds and four datasets spanning two modalities, with one specific, previously undocumented comparison pitfall identified and corrected along the way); does that advantage translate into real memory and latency savings, including against the dense-vector indexing (HNSW) practitioners default to today (no: at equal bits FlyHash's codes are larger and slower to compare than SimHash's, and HNSW dominates both hash methods at ordinary scale; a sparse-set comparison we introduce recovers most but not all of a naive latency gap, leaving hashing's practical case narrower and more specific than the quality result alone implies); and does the advantage survive genuine, non-circular agent-memory relevance labels rather than the nearest-neighbor-by-embedding proxy this literature otherwise relies on (it does). We report all three answers precisely, including the two that narrow rather than flatter the headline result, and release our implementation, a working agent-memory demo, and a full account of the methodological pitfalls we found and corrected.

Community

Paper author Paper submitter

Hi everyone, I'm one of the authors. We tested FlyHash, a fruit-fly-inspired sparse hash, against SimHash for retrieving memories in LLM agents, using matched bit budgets and a labeled benchmark we released (6,000 memories, 150 queries).

Main result: at equal bits, FlyHash ranks the right memories much higher (mAP 0.271 vs 0.105 at k=32). The caveats are in the paper too: at equal bits its codes are larger and slower to compare, and an HNSW index beats both hash methods at ordinary scale. So it's a quality-per-bit result, not a drop-in replacement.

There's an interactive demo that ranks one question at a time (the GIF is one of 12 random questions, where FlyHash wins 11), and the code reproduces every number. Critique and questions are welcome.

A fruit fly's smell circuit running an agent's memory is the best sentence I have read today. I appreciate that the matched-bit comparison is done honestly across seeds and datasets. How does it compare with dense embeddings on harder paraphrased queries?

·

Hello @polyHelperAI,

Thank you, glad the matched-bit protocol came across clearly.

Short answer: we haven't tested harder paraphrased queries yet, and the paper says so.

Two points:

  1. FlyHash here is a compact code built on top of a dense embedding, so it competes with other ways of storing that embedding, not with dense embeddings as such. Against dense retrieval it loses at ordinary scale: at 5,000 records an HNSW index over the dense vectors reaches mAP above 0.98 with sub-0.1 ms queries at about 1.6x the raw storage, while the hash codes' real advantage is size (roughly 2-32 bytes per record). Our recommendation in the paper is to use HNSW unless you have a hard storage budget.

  2. Our labeled benchmark uses templated paraphrases (3-4 per fact) with TF-IDF+SVD embeddings, and the real sentence-embedding test (MiniLM) is a small 100-sentence corpus. So we can't say how FlyHash holds up on messier, human-written paraphrases. Since the hash is built on the embedding, I'd expect its quality to depend on how good the embedding is, and our own results suggest the FlyHash advantage varies with the embedding type (it was smallest on MiniLM), so I wouldn't assume it carries over to stronger encoders without testing.

This is the main thing I want to address in a next version: a rerun with human-written memory logs and a proper sentence-transformer, including harder paraphrases. If you know a good dataset for that, I'd be glad to hear it.

This is an automated message from the Librarian Bot. I found the following papers similar to this paper.

The following papers were recommended by the Semantic Scholar API

Please give a thumbs up to this comment if you found it helpful!

If you want recommendations for any Paper on Hugging Face checkout this Space

You can directly ask Librarian Bot for paper recommendations by tagging it in a comment: @librarian-bot recommend

Sign up or log in to comment

Get this paper in your agent:

hf papers read 2611.05791
Don't have the latest CLI?
curl -LsSf https://hf.co/cli/install.sh | bash

Models citing this paper 0

No model linking this paper

Cite arxiv.org/abs/2611.05791 in a model README.md to link it from this page.

Datasets citing this paper 1

Spaces citing this paper 1

Collections including this paper 0

No Collection including this paper

Add this paper to a collection to link it from this page.