Show HN: GibRAM an in-memory ephemeral GraphRAG runtime for retrieval

(github.com)

60 points by ktyptorio20 days ago

7 comments

VoidWhisperer20 days ago
Out of curiosity, did you settle on that name before or after the RAM availability/price issues?
- ktyptorio20 days ago
  Actually, the name definitely came after noticing RAM prices. Though the idea where the graph-in-memory only for ephemeral RAG sessions came first, we won't pretend the naming wasn't influenced by RAM being in the spotlight.
- mirekrusin20 days ago
  GrrHDD
zwaps20 days ago
Very cool, kudosWhere might one see more about what type of indexing you do to get the graph?
- threecheese20 days ago
 Appears to be: <a href="https://github.com/gibram-io/gibram/blob/main/sdk/python/gibram/extractors/openai.py" rel="nofollow">https://github.com/gibram-io/gibram/blob/main/sdk/python/gib...</a>
 - ktyptorio20 days ago
 Exactly, thank you. Still in LLM-based extraction.
ekianjo20 days ago
how do you search the graph network?
- ktyptorio20 days ago
 There are two steps:Vector search (HNSW): Find top-k similar entities/text units from the query embeddingGraph traversal (BFS): From those seed entities, traverse relationships (up to 2 hops by default) to find connected entitiesThis catches both semantically similar entities AND structurally related ones that might not match the query text.Implementation: <a href="https://github.com/gibram-io/gibram/blob/main/pkg/engine/engine.go#L662-L778" rel="nofollow">https://github.com/gibram-io/gibram/blob/main/pkg/engine/eng...</a>
 - kordlessagain19 days ago
 This is how I did it a few years back while working for a set store company. It works well.
nirdiamant19 days ago
[dead]
Agent_Builder18 days ago
[dead]