▲ 10 r/vectordatabase+5 crossposts

We open-sourced a graph-free multi-hop RAG framework: Deterministic, 0 LLM calls, and matches flat search recall (Apache-2.0)

We just open-sourced WikiMoth - a graph-free, zero-LLM multi-hop memory tool that turns your plain markdown links into a deterministic retrieval path.

The problem we kept running into: almost every "memory for AI" tool today asks you to trust a black box. Either an LLM decides what to recall (non-reproducible), or it's a vector database you can't read.

WikiMoth walks the [[wikilink]] markdown notes you authored in plain local code instead. No LLM in the retrieval loop, no vector DB, no GPU. Same question -> same note-chain -> same answer. It ships an MCP server so an agent can call recall() itself, and the reader is fully swappable.

Apache-2.0, pure Python, stdlib core with zero external deps. The edge is structural: getting multi-hop + full determinism on raw markdown without an LLM deciding what you can see. Repo in the comments.

Feature WikiMoth BM25 Vector RAG claude-mem LLM Wiki (Karpathy)
Connects the dots (multi-hop over authored [[links]]) (agentic)
Deterministic retrieval (same query → same result)
No LLM call to retrieve ~
Auditable note-chain (which notes produced the answer) ~ ~
Direct-lookup recall@8 (real vault) 1.00 1.00 1.00 ~ ~
No GPU / no vector DB / no index build ~
Plain-markdown store (open in any editor) ~
Deterministic, API-free auto-capture
Hygiene without an LLM (conflicts · dupes · stale) ~

Would love feedback from anyone running local agent memory or looking for deterministic RAG alternatives!

reddit.com
u/Annual-Commercial563 — 3 days ago

We open-sourced a graph-free multi-hop RAG framework — matches Graph-RAG accuracy without the rebuild cost (Apache-2.0)

We just open-sourced MOTHRAG - a multi-hop RAG framework that skips the knowledge graph entirely.

The problem we kept running into: the accurate multi-hop systems (GraphRAG, HippoRAG, RAPTOR) all build a graph offline, and every time the data changes you rebuild it. For a corpus that updates often, that's a constant re-indexing bill.

MOTHRAG uses a graph-free dense index with query-time orchestration instead, no graph, no GPU, every component behind a commodity API. On multi-hop benchmarks it matches the graph-based systems, and updates are just embed-and-append instead of a full rebuild.

Benchmark MOTHRAG (ours) GraphRAG HippoRAG RAPTOR
HotpotQA 78.1 68.6 75.5 69.5
2WikiMultiHop 76.3 58.6 71.0 52.1
MuSiQue 50.5 38.5 48.6 28.9

Apache-2.0, pip install + API keys to run. Honest weak spot that we have right now: recall bottlenecks on MuSiQue, still working on that one tho. Repo in the comments.

Would love feedback from anyone running RAG on changing data in production!

reddit.com
u/Annual-Commercial563 — 4 days ago

P Moth-Retrieval: Graph-Free Multi-Hop Retrieval via Query-Time Orchestration (Beating Graph-Based Systems on HotpotQA) [P]

We just open-sourced MOTHRAG, a multi-hop RAG framework that skips the knowledge graph entirely.

We kept hitting the same wall building multi-hop RAG: the systems with the best accuracy (GraphRAG, HippoRAG, RAPTOR) all lean on a knowledge graph built offline, and that’s great numbers, until the moment your data changes! Every single update means re-running a heavy LLM indexing pass to rebuild the graph. If your corpus updates daily (prices, internal filings, support tickets, news), you're paying a constant, brutal re-indexing bill.

MOTHRAG uses a graph-free dense index with query-time orchestration (with no graph, no GPU) instead. Every component behind a commodity API.

We benchmarked it against the heavy graph-based systems on HotpotQA, 2WikiMultiHopQA, and MuSiQue (Accuracy / F1):

Benchmark MOTHRAG (ours) GraphRAG HippoRAG RAPTOR
HotpotQA 78.1 68.6 75.5 69.5
2WikiMultiHop 76.3 58.6 71.0 52.1
MuSiQue 50.5 38.5 48.6 28.9

And updates are just embed-and-append, with no need in rebuild, and retraining. Cost is ~$0.03/query on commodity APIs, no GPU anywhere.

Against GPU-bound systems that use constrained decoding (NeocorRAG), it's not a clean win. We match them on HotpotQA (78.1 vs 78.3) and 2Wiki (76.3 vs 76.1), but we lose on MuSiQue (50.5 vs 52.6). MuSiQue is our weak spot (retrieval recall bottlenecks there), and we haven't solved it yet.

The takeaway for us: for multi-hop over changing data, the graph overhead mostly buys you a rebuild bill, not accuracy. A graph-free index with good query-time orchestration held up.

It’s Apache-2.0, standard pip install + API keys to run. Repo link is in the comments.

Would love to get feedback from anyone running RAG on frequently changing data in production!

u/Annual-Commercial563 — 4 days ago
▲ 75 r/AIDiscussion+10 crossposts

We open-sourced a graph-free multi-hop RAG framework — matches Graph-RAG accuracy without the rebuild cost (Apache-2.0)

We just open-sourced MOTHRAG - a multi-hop RAG framework that skips the knowledge graph entirely.

The problem we kept running into: the accurate multi-hop systems (GraphRAG, HippoRAG, RAPTOR) all build a graph offline, and every time the data changes you rebuild it. For a corpus that updates often, that's a constant re-indexing bill.

MOTHRAG uses a graph-free dense index with query-time orchestration instead, no graph, no GPU, every component behind a commodity API. On multi-hop benchmarks it matches the graph-based systems, and updates are just embed-and-append instead of a full rebuild.

Benchmark MOTHRAG (ours) GraphRAG HippoRAG RAPTOR
HotpotQA 78.1 68.6 75.5 69.5
2WikiMultiHop 76.3 58.6 71.0 52.1
MuSiQue 50.5 38.5 48.6 28.9

Apache-2.0, pip install + API keys to run. Honest weak spot that we have right now: recall bottlenecks on MuSiQue, still working on that one tho. Repo in the comments.

Would love feedback from anyone running RAG on changing data in production!

u/Annual-Commercial563 — 4 days ago
▲ 11 r/vectordatabase+3 crossposts

Benchmarked Graph-RAG vs. Graph-Free Multi-Hop RAG: The graph mostly bought us a massive rebuild bill, not accuracy.

We kept hitting the same wall building multi-hop RAG: the systems with the best accuracy (GraphRAG, HippoRAG 2, RAPTOR) all lean on a knowledge graph built offline - and that’s great numbers, until the moment your data changes! Every update means re-running an LLM indexing pass to rebuild the graph. For a corpus that moves daily (prices, filings, tickets, news), you're paying that rebuild cost constantly.

So we tested whether the graph is actually necessary. We ran a graph-free dense index with query-time orchestration instead (with no graph, no GPU), every component behind a commodity API — against the graph-based systems on HotpotQA, 2WikiMultiHopQA, and MuSiQue.

Against the graph systems, it won on all three benchmarks:

Benchmark MOTHRAG (ours) GraphRAG HippoRAG 2 RAPTOR
HotpotQA 78.1 68.6 75.5 69.5
2WikiMultiHop 76.3 58.6 71.0 52.1
MuSiQue 50.5 38.5 48.6 28.9

And updates are just embed-and-append, with no need in rebuild, and retraining. Cost is ~$0.03/query on commodity APIs, no GPU anywhere.

Against GPU-bound systems that use constrained decoding (NeocorRAG), it's not a clean win. We match them on HotpotQA (78.1 vs 78.3) and 2Wiki (76.3 vs 76.1), but we lose on MuSiQue (50.5 vs 52.6). MuSiQue is our weak spot (retrieval recall bottlenecks there), and we haven't solved it yet.

The takeaway for us: for multi-hop over changing data, the graph overhead mostly buys you a rebuild bill, not accuracy. A graph-free index with good query-time orchestration held up.

Curious where others landed on this, is the graph worth the rebuild cost for data that changes?

reddit.com
u/Annual-Commercial563 — 4 days ago

5 months building AI agents solo. Looking for one co-founder who's obsessed, not just interested.

Looking for a co-founder / partner to build an AI agency with, someone who wants to go further together than either of us could alone.

A bit about me: I'm a builder. 5 months deep into building AI agents (lead-qual, content, real estate), I've shipped a live one and have working prototypes. I'm not just chasing money (though let's be honest, money matters a lot and we're building to win) - I care more about building something that actually makes things better, and to change the world, and about leveling up hard as a person while doing it. Based in Central Asia, working the CIS market, but location doesn't matter to me.

Who I'm looking for:

  • A founder with fire - initiative, drive, someone who moves instead of waiting..
  • Has actually built agents and/or done real sales, not just talked about it.
  • Obsessed with growth - skills, craft, becoming better.
  • Wants to build something meaningful, not just flip a quick buck.
  • Roughly 19-30, fluent English (C1+), so we can move fast together.

If this is you, DM me. Let's talk and see if there's real synergy.

reddit.com
u/Annual-Commercial563 — 8 days ago

5 months building AI agents as a business, as a result 1 live client, a few prototypes, and a question about getting from 1 to 5 clients.

Hey everyone. I'm about 5 months into building AI agents for businesses. I'm not a developer by background (though I know frontend reasonably well, HTML, CSS, JavaScript, some Python), but I approach this as someone who builds with AI rather than coding everything from scratch. And where I'm at right now:

  • 1 live deployment: an agent that reformats property listings for a real estate agent (an individual agent, not an agency). I built it for someone I know, for free, as a first case.
  • A few other prototypes (a content agent, a consultant agent, an admin agent, and some agents I built for myself) that work but are sitting unused because I haven't sold them yet.

A few things I've learned in these 5 months:

  1. I can build the agent, but the scary, unclear part is the sales side: getting in front of a business owner and running a discovery call. I've done a lot of cold outreach by text and exactly one cold call. Interestingly, some inbound came to me too, a business consulting firm, and some VCs looking for AI-agent developers for a trial period. I sent them demos, but nothing converted.
  2. Expertise comes FROM client contact, not before it. I kept thinking I needed to study more before reaching out. And that's not true! one real client taught me more than weeks of tutorials.
  3. Showing a working demo beats any pitch. "Here's an agent already doing this" lands way harder than explaining what I could build.

Where I'm stuck: going from 1 client to a repeatable pipeline. For those a step ahead, did you niche down hard into one vertical (I'm leaning toward real estate since I have a case there), or stay broad early on? And what actually got you clients #2 through #5 - cold outreach, referrals, content, communities???

Not selling anything here by the way, trying to learn from people a bit further down this road. Happy to share more on how I built the real estate agent if it's useful to anyone earlier than me.

For context: I'm based in Central Asia (Kazakhstan), working the CIS market.

reddit.com
u/Annual-Commercial563 — 8 days ago