LinkingMem — Graph-native RAG Engine
LinkingMem — Graph-native RAG Engine
Start new thread

LinkingMem - v0.3.0 - LinkingMem — Graph-native RAG Engine

by•
A high-performance Rust + Python engine for graph-based RAG, unifying vector search, graph traversal, and LLM reasoning in a single system. Query → Embedding → HNSW retrieval → Graph expansion (BFS) → Ranking → LLM answer LinkingMem combines vector search and graph traversal in one tightly integrated pipeline, enabling fast multi-hop reasoning, efficient memory usage, and production-ready scalability.

Add a comment

Replies

Best
Maker
📌
Quick update from the LinkingMem team — we're back with v0.3.0, and this one's a big jump from what we launched before. The short version of what's new: 🖼️ Multimodal, for real this time — text and image nodes now share the same vector space. Query the graph with a text question or an image URL, and it works the same way under the hood. Two embedding modes to pick from: Vision-LLM captioning (works out of the box, no extra setup) or CLIP embeddings (true visual similarity, no LLM call needed per image). 🐛 Two nasty bugs squashed — one where importing a graph could silently corrupt your data directory on the next merge, another where re-ingesting text in separate calls could quietly produce duplicate/colliding entity IDs. Both found through actual end-to-end testing against a running stack, not just unit tests — details in the if you're curious how deep that rabbit hole went. 📚 Docs you can actually trust — went through every doc, every env var, every API endpoint and made sure it matches what the code actually does. If you tried LinkingMem before and hit a doc that lied to you, that should be fixed now. 🐳 Docker images are live — khapu2906/linkingmem:v0.3.0-full (all-in-one) and v0.3.0-engine (bring your own plugin), both on Docker Hub. If you checked us out at launch and bounced off a rough edge, this is a good time to give it another look. And if you're new here: LinkingMem is a Rust + Python engine that does vector search + graph traversal + LLM reasoning in one system, instead of stitching together separate vector/graph DBs. Would love to hear what you think, especially if you're testing the image/multimodal side — that's the part I'm most excited about in this release. 🚀

A built-in query debugger that visualizes the graph traversal path and intermediate retrieval scores for each multi-hop question would be incredibly useful for tuning relevance and catching hallucination sources.

Maker

 Good catch — multihop responses don't actually keep per-hop trace data yet (vector_sim: 0.0 for every node right now), so that's the real work before any visualization. Adding it to the roadmap. Would a JSON trace be enough, or do you want an actual diagram?

Native query language support would be a great addition, something like Cypher or a GraphQL-style interface so users can explore the knowledge graph directly without writing custom traversal code. Would make debugging and ad-hoc analysis much smoother.

Maker

  Honestly, that's a deliberate "not planned" for us , the scoring pipeline is meant to be the query interface, not a Cypher-style layer on top. That said, GET /nodes , GET /edges already cover basic ad-hoc filtering. What specific pattern are you missing that those don't handle?

The Rust plus Python hybrid setup is genuinely useful for teams like ours. One thing that would help a lot: built-in observability for the retrieval path itself, like per-hop latency, which entities got traversed, and why certain branches were pruned. Right now debugging multi-hop answers feels like guesswork, and having that trace baked in would save hours when something hallucinates.

Maker

 Sharpest ask of the three. Per-hop timing already exists, but "why was this branch pruned" doesn't — our BFS just has a blunt node cap today, no real pruning logic to explain. Good flag, and it applies to ingestion too (we found duplicate entities slipping through the same blind spot recently).

Spent an afternoon with LinkingMem and the graph-plus-vector combo genuinely made multi-hop retrieval feel snappy. Loved that the Python plugin layer didn't choke on my custom embeddings.

Maker

 Love hearing that, thank you! Which embedding model did you plug in? Always curious what people are running through it :3

the mmap-based storage approach for low-latency graph access is genuinely clever, especially paired with rust under the hood. curious how the python ai plugins handle serialization overhead in production pipelines.

Maker

 Thanks! it's good comment. There's real JSON serialization overhead per embed call, no getting around that with an HTTP/JSON boundary. We batch (up to 256 texts per plugin call instead of one-by-one) and cache aggressively (embed + query result caches) to keep it from mattering in practice. Worth flagging though:
Unix socket mode only helps when engine and plugin are on the same host - doesn't do anything for a distributed setup.
Curious if you've got a specific production pipeline in mind - are you thinking multi-host, and if so what's your usual approach to cutting serialization cost there (binary formats, gRPC, something else)?