LinkingMem — Graph-native RAG Engine
LinkingMem — Graph-native RAG Engine
18 followers
LinkingMem — Graph-native RAG Engine
18 followers
LinkingMem is a Graph-native RAG engine combining Rust performance with Python AI plugins. It unifies vector search (HNSW), graph traversal (BFS), and LLM reasoning in a single pipeline for fast multi-hop retrieval. Key differentiators include tight graph+vector integration, embedding-based entity resolution, pluggable LLM/embedding backends, mmap-based low-latency storage, and production-ready scalability for large knowledge graphs.
This is the 2nd launch from LinkingMem — Graph-native RAG Engine. View more
LinkingMem - v0.3.0
Launched this week
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.
Free
Launch Team
LinkingMem — Graph-native RAG Engine
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.
LinkingMem — Graph-native RAG Engine
@grkemellek1eu3 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)?
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.
LinkingMem — Graph-native RAG Engine
@kbrakvpp 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.
LinkingMem — Graph-native RAG Engine
@bedriyedoa3hpc 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.
LinkingMem — Graph-native RAG Engine
@betlkonurabzyh 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.
LinkingMem — Graph-native RAG Engine
@aliyenayirqaqs Love hearing that, thank you! Which embedding model did you plug in? Always curious what people are running through it :3