I have a request: can this text be even more AI generated?
I wonder if one clear sign is so much custom language that makes me wonder "is this lingo used in that field" but more often than not it's just the LLM trying to sound hyper-professional?
We built a persistent agent memory layer on Elasticsearch with 0.89 recall
31–40 of 55 posts
Re: We built a persistent agent memory layer on Elasticsearch with 0.89 recall
#32is there any proof that all these shenanigans impove agent performance
Re: We built a persistent agent memory layer on Elasticsearch with 0.89 recall
#33Earlier quoted context omitted.
I’m literally laughing at the root comment’s idea of proposing we replace ES with SQLite and imagining how that architecture review would go. Not everyone is doing MB/GB scale workloads.
that would be a pretty frail architecture too, I think I recall ES even saying not to rely on it for data persistence. Every time I've worked with ES it was always backed by some other database used as a source of truth.
This is a important bit of information which either gets lost or ignored for convenience at times. Other side of it is the fact that this open up the door to keep two data stores in sync which is a much bigger battle for a lot of small companies or teams
Re: We built a persistent agent memory layer on Elasticsearch with 0.89 recall
#34TIL
- Hybrid recall + reranker: Two searches merged, then re-scored for best matches
- Supersession: Old facts get hidden, new ones take their place
- Decay: Recent or often‑used memories get a score boost
- DLS: Each user only sees their own documents
Re: We built a persistent agent memory layer on Elasticsearch with 0.89 recall
#35I'm using Typesense to power my take on a md kb, highly recommend this option which positions itself against Elasticsearch and Algolia. Combines vector with bm25 and all the extras you get from a trad search tool like Algolia.
Re: We built a persistent agent memory layer on Elasticsearch with 0.89 recall
#36Summary of the article ( https://pastebin.com/aawJfrF6 ) since the original one is like reading an academic paper filtered through an LLM that hates human readers. It seems like a cool approach. Don't know if it's novel but it's much smarter than "shove markdown files into directories".
> but it's much smarter than "shove markdown files into directories".
Is it, though? I mean, is there evidence "bunch of markdown files" is bad while "database the model has to be instructed how to use" is good? `rg` is fast as hell. Markdown is the LLMs native tongue. It does require maintenance of the Markdown files to keep them current, but maybe explicit management is fine. The models can do the grunt work.
BMDF (Bunch of Markdown Files) can be checked into the git repo, they travel to any developer on the project without any setup or special auth, any agent and any model can read them with no special tools to install, and humans can easily poke around and read them, too. And, they can be part of the PR review process, documenting the code and intentions.
I can't come up with good arguments for why a database or search index would be better than documentation in Markddown for any of my projects.
Re: We built a persistent agent memory layer on Elasticsearch with 0.89 recall
#37is there any proof that all these shenanigans impove agent performance
Cursor and PI harness are the proof.
Re: We built a persistent agent memory layer on Elasticsearch with 0.89 recall
#38is there any proof that all these shenanigans impove agent performance
Re: We built a persistent agent memory layer on Elasticsearch with 0.89 recall
#39Summary of the article ( https://pastebin.com/aawJfrF6 ) since the original one is like reading an academic paper filtered through an LLM that hates human readers. It seems like a cool approach. Don't know if it's novel but it's much smarter than "shove markdown files into directories".
> but it's much smarter than "shove markdown files into directories". Is it, though? I mean, is there evidence "bunch of markdown files" is bad while "database the model has to be instructed how to use" is good? `rg` is fast as hell. Markdown is the LLMs native tongue. It does require maintenance of the Markdown files to keep them current, but maybe explicit management is fine. The models can do the grunt work. BMDF…
[deleted]
Re: We built a persistent agent memory layer on Elasticsearch with 0.89 recall
#40Summary of the article ( https://pastebin.com/aawJfrF6 ) since the original one is like reading an academic paper filtered through an LLM that hates human readers. It seems like a cool approach. Don't know if it's novel but it's much smarter than "shove markdown files into directories".
> but it's much smarter than "shove markdown files into directories". Is it, though? I mean, is there evidence "bunch of markdown files" is bad while "database the model has to be instructed how to use" is good? `rg` is fast as hell. Markdown is the LLMs native tongue. It does require maintenance of the Markdown files to keep them current, but maybe explicit management is fine. The models can do the grunt work. BMDF…
Because a bunch of markdown files is just RAG, and RAG is unintelligent, so the results are not great. If you want a smarter AI, it needs to have not-dumb memory. That's why this article (and the summary I posted) covers multiple kinds of memory, multiple ways of managing different memories, multiple ways of finding memories, a way to pick the best memory, and a way to manage memories long-term (and among multiple users). Now the memory isn't dumb, so the results are better. (And the article shows you why it's better)
tl;dr https://www.elastic.co/search-labs/blog/agent-memory-elastic...