hubmesh
Centrality-aware GraphRAG retrieval planner. Drop-in layer over any vector DB.
hubmesh is a Python library that improves multi-hop RAG quality on top of an existing
vector database. You don't replace your infrastructure — you add a smart planner between
your vector DB and your LLM.
What problem this solves
Naive vector retrieval ("embed query, get top-k by cosine similarity") fails on multi-hop questions like "Where was the founder of the company that acquired Slack born?" The correct answer requires retrieving entities along a reasoning path, not the single most similar item.
GraphRAG and HippoRAG showed that running a small Personalized PageRank over a knowledge
graph at query time can substantially improve multi-hop retrieval. hubmesh extends
that line with two contributions:
- Multi-component seed selection. Instead of picking PPR seeds by raw query similarity (which picks wrong-community seeds at high feature overlap), seeds are chosen by a multi-component score combining query relevance, structural fit, and coverage diversity.
- Budget-aware context packing. Once relevant entities are scored, pack them into the LLM's context window with explicit coverage and redundancy control rather than just truncating top-k.
The multi-component scoring pattern is adapted from the NNSI framework (Naidu Dsk, iComp 2025) for SDN topology optimization, repurposed here for retrieval planning.
Quickstart
In-memory (testing, small corpora)
from hubmesh import Planner
from hubmesh.adapters import InMemoryStore
embed = ... # callable: text -> np.ndarray
docs = [...] # list of Document or strings or dicts
store = InMemoryStore.from_documents(docs, embed=embed)
planner = Planner(store=store, embed=embed)
result = planner.retrieve(query="...", top_k=10, budget_tokens=4000)
Qdrant adapter (production)
from hubmesh import Planner
from hubmesh.adapters import QdrantStore
store = QdrantStore.from_documents(docs) # in-memory
store = QdrantStore.from_documents(docs, path="./qdrant_data") # on-disk
store = QdrantStore.from_documents(docs, url="http://localhost:6333") # remote
planner = Planner(store=store, embed=embed)
result = planner.retrieve(query="...", top_k=10)
Chroma adapter
from hubmesh.adapters import ChromaStore
store = ChromaStore.from_documents(docs) # ephemeral
store = ChromaStore.from_documents(docs, persist_directory="./chroma_data")
store = ChromaStore.from_documents(docs, host="localhost", port=8000)
Multi-hop / KG mode
from hubmesh.kg import build_entity_kg
import spacy
nlp = spacy.load("en_core_web_sm")
kg = build_entity_kg(docs, nlp=nlp)
planner = Planner(store=store, kg=kg, nlp=nlp)
result = planner.retrieve(query="Where was the founder of the company that bought Slack born?",
top_k=10, budget_tokens=4000)
# RetrievalResult includes reasoning paths showing why each doc was returned
for path in result.reasoning:
print(f" score={path.score:.3f} {' → '.join(path.node_ids)}")
LLM-extracted KG (richer than spaCy)
from hubmesh.kg_llm import build_entity_kg_llm
from hubmesh.entity_linker import EmbeddingLinker, make_st_embedder
def llm(prompt): # provider-agnostic — bring your own
return your_llm_call(prompt)
kg = build_entity_kg_llm(docs, llm=llm, cache_path="kg_cache.json")
# optional: cross-document entity dedup — same Linker protocol as the spaCy path
kg = build_entity_kg_llm(docs, llm=llm, cache_path="kg_cache.json",
linker=EmbeddingLinker(embed=make_st_embedder()))
planner = Planner(store=store, kg=kg)
Better entity linking
from hubmesh.kg import build_entity_kg
from hubmesh.entity_linker import EmbeddingLinker, make_st_embedder
# Cluster surface variations: "United States" / "U.S." / "USA" → one entity
linker = EmbeddingLinker(embed=make_st_embedder(), threshold=0.82)
kg = build_entity_kg(docs, linker=linker)
Iterative multi-hop: let your agent drive
r1 = planner.retrieve(query=question, top_k=5)
# your agent reads r1, spots the bridge entity, then aims hop 2 at it:
r2 = planner.retrieve(
query=question, top_k=5,
seed_entities=["Nimbus Analytics"], # merged with the query's own seeds
exclude_docs=[s.doc.id for s in r1.sources], # don't re-retrieve consumed docs
)
Seed mentions resolve through the alias index, so free-text entity names work. The query path stays deterministic and LLM-free — the planning intelligence lives in the caller.
MCP server: plug hubmesh into any agent
pip install "hubmesh[mcp]"
python -m spacy download en_core_web_sm
{"mcpServers": {"hubmesh": {"command": "hubmesh-mcp"}}}
Exposes the planner as deterministic operator tools over stdio —
index_corpus, retrieve (seed-steerable, as above), resolve_entities,
entity_neighbors, path_between, get_document, graph_stats,
list_corpora. Your agent is the solver: it decomposes the question,
reads each hop, and aims the next one; the server answers in
milliseconds with zero LLM calls. Corpora persist as plain JSON/NPZ
under ~/.hubmesh/corpora.
Chunking long documents
from hubmesh import chunk_by_sentences, chunk_documents
chunks = chunk_documents(
[{"id": "doc1", "text": long_text}, ...],
strategy="sentences", target_tokens=200,
)
# Then embed chunks and index normally
Installation
pip install hubmesh # core
pip install "hubmesh[qdrant]" # Qdrant adapter
pip install "hubmesh[chroma]" # Chroma adapter
pip install "hubmesh[kg]" # entity-linked KG (spaCy)
pip install "hubmesh[linker]" # embedding-based entity linker
pip install "hubmesh[all]" # everything
python -m spacy download en_core_web_sm # required for KG mode
Design
query → first-pass ANN → induced subgraph → multi-component scoring
↓ ↓
community anchoring → Personalized PageRank
↓ ↓
└─────→ ranking → budget-aware packing → context
Each layer is independently testable and replaceable. Adapters wrap your existing vector DB so you don't have to migrate.
Benchmarks
Headline: on multi-hop QA, hubmesh's KG mode beats both naive cosine retrieval and a HippoRAG-style PPR-only ablation that uses the same KG. The win is largest at 4-hop — exactly the regime where graph-structural retrieval should help most.
| Benchmark | Setting | recall@10 vs naive |
|---|---|---|
| HotpotQA dev, N=7405 (full) | KG mode | +4.92 pts † |
| HotpotQA dev, N=500 | KG mode | +4.00 pts |
| MuSiQue dev, N=300, 2-hop | KG mode | +3.0 pts |
| MuSiQue dev, N=300, 3-hop | KG mode | +2.6 pts |
| MuSiQue dev, N=300, 4-hop | KG mode | +3.4 pts |
† measured on v0.1.1; all other rows re-measured on v0.2.0 (alias-indexed seed resolution), which improved every recall@5/@10 delta over v0.1.1. Disclosed: HotpotQA N=500 recall@2 dipped −0.4 pts.
vs PPR-only ablation on the same KG: +29.8 pts on HotpotQA (at N=500) — the multi-component scoring is doing the work, not just "having a graph."
On the full N=7405 HotpotQA dev: hubmesh hits 74.2% supporting-fact recall@10 vs naive cosine's 69.3%. The win is consistent at recall@2 (+1.1) and recall@5 (+4.4) too.
Latency: ~22 ms mean / 26 ms p95 per query on a 7K-node KG (after PPR matrix caching).
See BENCHMARKS.md for the full methodology, ablations, per-hop breakdown, and notes on what this proves and doesn't.
Reproduce:
python benchmarks/run_hotpotqa.py --n 500 --kg
python benchmarks/run_musique.py --n 300 --kg
python benchmarks/profile_query.py # latency profile
Status
Pre-alpha (v0.3.0). Core algorithms implemented and validated; adapters for
in-memory, Qdrant, and Chroma; entity-linked KG with both spaCy NER and
LLM-based extraction (both linker-aware); alias-indexed entity resolution;
agent-driven iterative multi-hop via seed_entities / exclude_docs;
MCP operator server (hubmesh-mcp) with JSON/NPZ corpus persistence;
document chunking; reasoning-path explanation; PPR-cache latency
optimisation. Pinecone / pgvector / Weaviate adapters
and additional multi-hop benchmarks are tracked as
good first issues.
Acknowledgements
The multi-component scoring pattern is adapted from the Network Node Significance Index (NNSI) framework introduced in Naidu Dsk, "A Framework for Improving Network Topology Based on Graph Theory in Software-Defined Networking", iComp 2025 — repurposed here from SDN topology optimization to retrieval planning.
License
MIT
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file hubmesh-0.3.0.tar.gz.
File metadata
- Download URL: hubmesh-0.3.0.tar.gz
- Upload date:
- Size: 48.5 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via:
twine/6.2.0 CPython/3.11.15
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
baac90b54417b8bf8201e0b7f8563d27436c2aef8d69ee92b93aaa4ceb893d2f
|
|
| MD5 |
dd2ca5d36d2e8ac4017a137bb77ad5ef
|
|
| BLAKE2b-256 |
a560409fe19717fb5b59a4ba8bc457f45c0d428e72089d7ab61a71e1ac1e6e34
|
File details
Details for the file hubmesh-0.3.0-py3-none-any.whl.
File metadata
- Download URL: hubmesh-0.3.0-py3-none-any.whl
- Upload date:
- Size: 47.2 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via:
twine/6.2.0 CPython/3.11.15
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
4ec414824dc53793ab262b4e3db21de0d0ed9a8091d1daeb759cc995a369d3d0
|
|
| MD5 |
6e53c1e6c789e9d5f4a387a215e8e73b
|
|
| BLAKE2b-256 |
d1f0dd12d0a1a9af2be1966170821711d7ee5333cc1cddf2eb86187cfd0da74e
|