Ask questions across your Markdown notes using a fully local Graph RAG engine. Built for Obsidian vaults, works with any folder of Markdown files. Extracts entity-relation triples from wikilinks & YAML frontmatter, retrieves answers via hybrid search (vector + BM25 + temporal). Multilingual. No cloud. Runs on Ollama.
Hello, everybody. I'm thinking about creating an encrypted vector storage in which both the embeddings and the chunk text are encrypted. The encryption key is known only to the user, who encrypts and decrypts the chunks locally. Data in the database would be stored in an encrypted format. I've come across a mathematical formulation of an encrypted embedding procedure that preserves cosine similarity by scrambling the vector components to prevent vector2text attacks. This way, cosine similarity still works even with encrypted embeddings.
The goal is to let companies that deal with personal and sensitive data use Rag as well, because all data would be totally encrypted in the database. I'm in Italy, so I work under eu gdpr regulation.
What do you think? Would it be useful?
Instead of node --edge--> node, every relationship is a first-class document with its own vector, called a BaryEdge. Stack pairs of BaryEdges recursively and you get "MetaBary" triads that surface structural bridges between concepts that live nowhere near each other in embedding space. Running locally on MongoDB Community + mongot + nomic-embed-text over the full English Wiktionary (6.6M docs). MCP server is live if you want to poke at it. Preprint + benchmark CSVs: https://zenodo.org/records/20186500
The problem I was chasing
Flat vector search treats a relationship as a byproduct of two points being close. That throws away information. Two papers can describe the same underlying phenomenon (a flyby anomaly in orbital mechanics, an anomalous residual in stellar dynamics) without ever citing each other and without their embeddings landing anywhere near each other. Nothing in standard RAG surfaces that connection.
What I did instead
Every relationship gets embedded too:
bary_vector = normalize(q·v(CM1) + q·v(CM2) + (1−q)·v(type))
q is connection quality, v(type) is a contextual embedding of what kind of relationship it is. This BaryEdge is now a retrievable document in its own right — not metadata on an edge.
Then it recurses: two BaryEdges at the same level get bridged by a third one level below, forming a MetaBary triad. Do that repeatedly and you climb an abstraction triads hierarchy built entirely from algebra — zero additional embedding calls above the base level. It's a forest (every node has at most one parent), so traversal to root is a single $graphLookup, no cycle handling.
Does it actually do anything useful?
Ran it against SimLex-999 and WordSim-353 as a sanity check (not the main claim, just "is the substrate coherent"). Raw cosine similarity barely correlates with human similarity judgments (ρ ≈ −0.04 on SimLex). Structural metrics — how many BaryEdges two words share, how much their relational neighborhoods overlap — correlate at ρ ≈ 0.32–0.53, p < 10⁻¹⁵. So the graph is encoding something cosine alone doesn't.
The part I actually care about is cross-domain bridging. Some probe traces from the live graph:
octopus neuroscience ↔ distributed sensor networks, bridged by shared structural-motif vocabulary (neuroarchitecture, smartdust)
collagen folding ↔ linguistic syntax, bridged by etymological + structural motif overlap (plicature / hypotaxis-parataxis)
grief ↔ depression, not bridged and this is a correctness demonstration, not a missing capability. The DSM-5 added a much-debated "bereavement exclusion" precisely because grief and depression share surface symptoms but are different kinds of state, with different prognosis and treatment
radioactive decay ↔ obsolete words falling out of use, bridged at a high abstraction level by register-varied decay verbs (collapsed, decayed, declined, disintegrated) — naming a Poisson-process state-loss pattern that both physics and historical linguistics instantiate, with no single word doing the work
That last one is the case flat retrieval structurally cannot produce — there's no embedding axis for "verbs co-occurring with reduction-of-state across unrelated domains."
Stack (all local, all free)
GitHub: https://github.com/oleksiy-perepelytsya/bary-vector
MongoDB Community Edition + mongot for storage/vector search
nomic-embed-text, 768-dim
Python 3.11+
Full build: ~6.66M documents, 8–14 hrs on a single workstation (8–16GB VRAM)
Try it
MCP server is public on request (SSE transport) — read-only tools for searching the live graph: find_word, semantic_search, edge_info, leaf_nodes, traverse_up, sample_metabary. If you've got an MCP-capable client you can point it at the graph and run your own probe queries in a few minutes.
What I'd actually want feedback on
Whether the cross-domain bridges hold up to someone who isn't me poking at them — try a probe query on a domain pair you know well and tell me if the bridge is real or if I'm pattern-matching myself into seeing structure that isn't there. Some bridges can be not obvious on the first look but they are actually the most intriguing ones and worth to be dug for the reason they built, so treat them as points of investigation
Whether this is worth comparing directly against GraphRAG/RAPTOR-style hierarchical retrieval (I haven't done that benchmark yet, and I know that's the first thing this sub will ask)
Whether anyone's tried something structurally similar and it fell apart at scale for reasons I haven't hit yet
Preprint, architecture spec, and the raw SimLex/WordSim CSVs are all here: https://zenodo.org/records/20186500
Happy to drop the MCP endpoint on request if there's interest.
I added the TurboQuant algorithm published by Google to pgvector as part of my discovery and learning process with RAG systems. Just this past weekend, I ran a test with the 100M row Wikipedia dataset from Cohere where I observed a 10x reduction in index size relative to HNSW. I figure with the direction RAM and storage prices have been going, we could use some more ways to save space!
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?
hey guys i never did like the rust vs go holy wars so this database is meant to be a sibling database. architecturally similar, i use fjall underneath instead of badger, etc… that i can put up against Nornic and help them refine each other.
its extremely experimental right now, i haven’t released it yet as a v1 at all. but i plan on making this sort of a hard core fully distributed version. right now i have single node loading and the graph functions working with the ui demo i have. i’m working on the search endpoint right now, but anyways i digress.
MIT licensed, this was more for me to see if i could learn rust at the same time and make both of my databases compete with each other for performance. that way i have to get really creative and super granular with the performance tuning.
so far my BFS implementation is proving to be ~2x faster on the rust side (~70-80ms for a 47 hop shortest path on the demo frontier. ~150ms for Nornic) and the cypher parser seems to be ~2x faster than Nornic’s.
i could use some help and contributors. it’s a massive scale project to do a fully distributed mesh like this. i’m focused on single node parity for certain things at the moment, i already integrated llama.cpp so i can run the embedding model in memory there too, etc…
anyways, it’s a mess right now but i figured i’d let you know it’s coming along nicely so far.
Hello,
HNSW powers most vector databases like Pinecone, Qdrant, and Weaviate, but it's often treated as a black box.
To understand how it actually works, I built VectorLens — an interactive 3D visualizer that shows every step of the HNSW search algorithm.
Live Demo:
https://hnsw-vector-search-visualizer.vercel.app/
GitHub:
https://github.com/ManikBodamwad/HNSW_Vector_Search_Visualizer
A few highlights:
I'd love feedback on the implementation, visualization, or ideas for making it a better learning tool.
What it does
RAGless is a semantic retrieval system based on Question-to-Question matching. At ingestion, an LLM generates multiple question variants per answer (3–5) and each variant gets its own embedding. At query time, the user question is embedded, Top-K nearest question variants are retrieved, and scores are aggregated by answer_id — the answer with the highest aggregated score wins.
Threshold logic uses two gates: minimum aggregated score (default 0.70) plus a fallback on the best single-hit score (0.82), to avoid false negatives when only one variant makes it into Top-K. Embeddings use asymmetric task types (RETRIEVAL_DOCUMENT at ingestion, RETRIEVAL_QUERY at runtime).
Target audience
Researchers and engineers evaluating retrieval architectures for closed-domain FAQ systems where the answer space is finite and predefined. Production-ready for that scope. Not intended for open-ended generative Q&A.
Comparison
Standard RAG: retrieve document chunks → LLM generates an answer. RAGless: retrieve pre-generated question variants → return the pre-written answer. The generation step is eliminated entirely. Compared to dense passage retrieval (DPR) and similar approaches, RAGless operates at the question level rather than the passage level, which improves precision for FAQ-style retrieval at the cost of flexibility.
GitHub: github.com/EmilResearch/RAGless
Open to feedback — happy to answer questions.
If you find it useful, a ⭐ on GitHub is appreciated.
TLDR:
The Scale: 500,000 nodes, ~3.97 million edges (~16 connections/node) benched on an Apple M3 Max.
Performance Breakdown
Depths 1–4 (Local): Sub-millisecond (94us -> 342us median). Fits entirely within the adjacency and edge body caches.
Depths 5–8 (Mid-range): Single-digit milliseconds (1.2ms -> 2.3ms median). Working set starts hitting cold subgraphs, causing some tail latency noise.
Depths 9–39 (Deep): Linear scaling at roughly 14ms per hop.
Depth 40+ (The Cache Cliff): Latency instantly doubles (jumping from 282ms -> 612ms median). The BFS frontier hits ~200,000 nodes, obliterating the default nodeCacheMaxEntries limit of 50,000 and forcing raw disk iterator hits.
Depth 60 (Full Scan): Maxes out at \approx 1 second for a full cross-sector traversal.
A coding agent, RAG pipeline, or autonomous worker typically needs MongoDB for memory, Redis for cache and locks, Qdrant for semantic search, and BullMQ for the task queue.
With monlite, that entire stack is one file:
https://github.com/qataruts/monlite
Been working on a RAG system that builds a directed causal graph from documents instead of chunking. The idea: when someone asks "what ultimately caused X?", flat RAG fails because the cause and effect live in different chunks with no shared vocabulary. If you follow the graph edges instead, you get the full chain.
Benchmark: 54 questions across two domains (subprime mortgage crisis, Chernobyl), three question types (fact lookups, multi-hop, root-cause), Claude Haiku for generation, Sonnet as judge, paired Wilcoxon against a strong BM25+dense flat baseline.
Results:
The fact-lookup tie was the thing I cared most about honestly. Earlier versions had a -0.03 regression on facts which made the system impractical. Fixed that with a score gate that falls back to flat coverage when no chain clears a relevance threshold.
Coverage sentence retrieval is hybrid BM25+dense RRF (k=60). Chains are ranked with a 5-channel RRF: name match, VSA hypervector similarity, BM25, dense, path signature. Entity normalization merges near-duplicate nodes before indexing.
Graph traversal (root cause, impact, shortest path) needs no LLM — instant BFS, useful for on-call engineers who need answers before reading the document.
Repo: https://github.com/linga009/causal-graph-rag
Happy to discuss methodology — especially whether the judge setup is sound, that's always the sketchy part of LLM-as-judge evals.
Hey everyone! 👋
If you’re building RAG or autonomous AI agents, you’ve probably hit the "Vector DB Wall": flat Euclidean vectors suck at modeling complex hierarchical reasoning, and loading millions of 1536D vectors + JSON metadata into memory causes massive RAM bloat and OOM crashes.
We spent the last few months solving this from the ground up. Today, we are releasing HyperspaceDB v3.1.0, transitioning from a standard vector index to a full Spatial AI Engine.
Here is what’s under the hood:
1. The RAM Diet (Schema-Driven MRL) Instead of loading full dense vectors into memory, we built native support for Matryoshka Representation Learning (MRL). The engine keeps a lightweight navigation core (e.g., 129 dimensions) in ultra-fast RAM, while the heavy semantic tail (672 dimensions) streams dynamically from NVMe SSDs for final top-K re-ranking. The benchmark: In our stress tests with 100,000 vectors, HyperspaceDB consumed just ~72.0 MB of RAM compared to >3,000 MB for Chroma and ~1,700 MB for Milvus.
2. 801D Hybrid Vectors (Lorentz + Euclidean) Flat vectors fail at taxonomy (e.g., Legal Codes, Medical Trees). We introduced an 801D Hybrid Vector. The first 33 dimensions live in a negatively curved Lorentz hyperboloid (allowing for native graph/tree embeddings), while the remaining 768 dimensions handle Euclidean semantic density. Agents can now verify facts geometrically using geodesic path tracing.
3. Killing the "Two-Database Problem" Gluing Pinecone to MongoDB for document storage is painful. We built Sidecar Document Storage. You store massive raw texts directly in the index, which automatically compresses (Zstd) and pushes them to fractal .hyp chunks on disk. Meanwhile, Typed Metadata (int, bool, enum) is compiled directly into the HNSW graph nodes in RAM, providing zero-latency pre-filtering with no JSON-parsing overhead.
4. Lock-Free Rust Performance Under a 1,000-concurrent-client stress test, our lock-free HNSW and L0/L2 DashMap cache held flat at 9,476 QPS with a p99 latency of 11.83 ms. Competitors hit severe lock contention at this scale, with latencies spiking over 2,000 ms.
We’ve also added a WASM runtime, Raspberry Pi ARM64 support, and native LangChain/LlamaIndex/MCP integrations.
Would love to hear your thoughts, answer any questions about the architecture, or get feedback from anyone pushing the limits of Agentic RAG!
Ask me anything! 🚀
I've recently been working on LodeDB, an in-process, on-disk vector database. It makes two bets that are different from most embedded stores (sqlite-vec, a FAISS flat index, Chroma's default), and I'd like this sub's read on them.
Bet 1: exact scan, not ANN. Deliberate, for the small-to-mid regime where you want exact recall with no index build and no HNSW/IVF tuning. The compact core is the MIT TurboVec project: vectors are packed into 2/4-bit codes and scanned with SIMD kernels, so quantization is the only error source. On a 17.5k-doc corpus that landed 4-7x smaller on disk than common in-memory stores.
Bet 2: when there's a GPU, score the exact reconstruction on it. An fp16 copy of the index lives on the GPU and batched queries run as a tiled GEMM plus a streaming top-k. ~50k queries/sec at batch 1024 on an L40S, ~24k on an A10, which is 2.8-4.8x the all-CPU ceiling on the same box, recall unchanged because it's the same 4-bit reconstruction the CPU scans. For reference on the regime, Alibaba's zvec reports ~8.4k qps on a 16-vCPU CPU. Crossover is around batch 50; single queries and non-CUDA hosts fall back to the CPU scan, which stays the source of truth. Opt-in [gpu] extra, Linux/CUDA.
Storage/durability engineering (the part I had the most fun with):
Apache-2.0 core (TurboVec kernels MIT). Repo and the full benchmark vs FAISS, Chroma, Qdrant, LanceDB, sqlite-vec, and pgvector with methodology: https://github.com/Egoist-Machines/LodeDB
Where do you think exact-scan-on-GPU stops making sense and you'd reach for HNSW instead? That's the boundary I'm trying to map.
Would also love to hear people's thoughts on this as a whole!
I have a feeling that the most valuable RAG systems are built on data that is sensitive for companies. That way, the data never leaves their controlled infrastructure. However, processing a massive amount of data of various formats and sources into a format suitable for a vector DB without using hosted parser APIs like Azure Document Intelligence, LlamaParse, Unstructured, etc. Seems like a nightmare.
I want to find out how this looks in practice and map out where the real pain points hide in these projects.
So if you've built one of these: on-prem or air-gapped because you had to (regulated data, client contracts), or just because you wanted control/privacy/cost
Sources could be anything: PDFs and tables on disk, or data pulled from internal tools like Confluence, Jira, SharePoint.
Drop a comment about what your biggest pain points were. What breaks, what eats time, what you'd do differently, what stack you used
I built a small semantic memory layer for AI apps called TensorTree. It’s built on top of SOP’s KnowledgeBase architecture and is designed as a Database as a Library: embeddable, flexible, and suitable for both standalone and clustered deployments.
The idea is simple: organize knowledge into categories, and let those nested category paths themselves participate in semantic similarity. Instead of treating the hierarchy as a rigid tree, TensorTree uses the category path as a semantic structure that helps retrieval flow naturally from broad concepts to more specific ones. This gives developers a way to combine hierarchy, meaning, and search in one model & to solve scalability, support million/billion/... limited only by your hardware, as SOP sports swarm computing tech, architected for peta byte & beyond scale.
I also like the fact that categories are inherently visualizable, and with SOP’s Data Manager the resulting Spaces become much easier to explore.
It’s aimed at developers building RAG systems, copilots, documentation assistants, and other knowledge-driven AI experiences who want memory that feels more structured and more semantically aware than a flat vector store, and does not require nightly K-Means Centroids optimization, plus the scalability mentioned.
Repo:
Zilliz is hosting a live webinar on Vector Lakebase, now available in public preview on Zilliz Cloud.
The session will cover how Vector Lakebase pairs a production vector database with a shared, lake-native data foundation, so teams can support online serving, on-demand search, and batch processing on one copy of their data.
Speakers:
James Luan, Zilliz CTO and Milvus maintainer
Jiang Chen, Director of Technical GTM at Zilliz
📅 Date: July 1, 2026
🕚 Time: 11:00 AM PDT
🔗 Register: https://zilliz.com/event/from-vector-database-to-vector-lakebase?utm_source=reddit
What we’ll cover:
If you’re working on AI infrastructure, retrieval, RAG, or lakehouse-style data architectures, we’d love to have you join and bring your questions.