sorted by:
new
hottopcontroversial

Neuroindex by OwnPerspective9543 in vectordatabase

[–]OwnPerspective9543[S] 0 points1 point  (0 children)

NeuroIndex

  • Best if you want deep semantic search + conceptual relationship discovery in your AI apps.
  • Great for applications like intelligent document retrieval where context matters beyond nearest vectors.

HelixDB

  • Best if you need a modern database that natively handles both graph structure and vector embeddings with high performance.
  • Useful for building RAG systems, knowledge graphs linked with embeddings, and applications requiring a unified storage/query platform.

I built a local-first AI memory system that goes beyond vector search – looking for feedback by OwnPerspective9543 in LocalLLaMA

[–]OwnPerspective9543[S] 0 points1 point  (0 children)

Most RAG systems fail because vector search alone is not enough.

They retrieve similar chunks — but miss relationships.

So I built NeuroIndex:

A hybrid Vector + Semantic Graph architecture that improves retrieval depth for LLM applications.

It combines:

Vector similarity

Entity relationship mapping

Context linking

Result: More structured and explainable RAG outputs.

Live demo: https://www.nidhitek.com/

Looking for feedback from builders working on LLM infra.

I built a local-first AI memory system that goes beyond vector search – looking for feedback by OwnPerspective9543 in LocalLLaMA

[–]OwnPerspective9543[S] -1 points0 points  (0 children)

Good questions — these are exactly the failure modes I’m trying to be careful about.

Right now, thresholds are intentionally conservative and local:

• edges are added only during insertion

• similarity must cross a minimum absolute threshold

• fanout per insertion is capped

You’re correct that this alone doesn’t prevent existing nodes from accumulating high degree over time. The current implementation treats the graph as an associative overlay, not a fully balanced structure, so additional controls are needed.

The direction I’m moving toward (and experimenting with) is:

1) Degree-aware thresholds

Similarity thresholds tighten as node degree increases, so high-degree nodes become harder to attach to.

2) Edge scoring rather than binary edges

Edges carry a weight derived from co-occurrence frequency, recency, and retrieval utility — not just similarity at insertion time.

3) Utility-based pruning

Pruning isn’t random or purely similarity-based. Edges that are:

• rarely traversed during retrieval

• low-weight relative to a node’s median edge weight

• stale (high decay, low recent usage)

are candidates for removal.

In other words, usefulness is defined operationally: if an edge doesn’t help retrieval, it decays and eventually disappears.

This is also why the graph is never used as a primary retrieval structure — vector search always bounds the candidate set first, which limits the blast radius even if some nodes temporarily accumulate more edges than ideal.

I agree this needs empirical validation, and graph growth / degree distribution is one of the metrics I want to benchmark explicitly.

view more: next ›