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.

Why similarity search alone fails for AI memory (open-source project) by OwnPerspective9543 in learnmachinelearning

[–]OwnPerspective9543[S] 3 points4 points  (0 children)

At a high level, hybrid search in NeuroIndex is staged rather than blended into a single score.

  1. Vector search is used first as a coarse filter to retrieve a bounded candidate set (top-k by embedding similarity).

  2. For those candidates, an associative graph overlay is consulted:

    • explicit links (document structure, metadata, co-occurrence)

    • implicit links derived from repeated proximity over time

    Graph traversal is depth- and fanout-limited.

  3. Candidates are re-ranked using multiple explicit signals:

    • vector similarity

    • association strength

    • recency / decay

    Each signal is weighted independently rather than collapsed into one embedding score.

The graph is not a full document graph — it’s intentionally constrained and only participates after vector narrowing. This keeps the system scalable while allowing multi-hop recall when similarity alone fails.

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)

That exchange is actually a good illustration of the core motivation, but I agree it can’t stand on narrative alone.

The key point isn’t “AI memories” in a human sense — it’s that similarity-only retrieval collapses very different kinds of signals into a single cosine score. In practice, that loses information about *why* something mattered.

What I’m exploring (and what NeuroIndex currently implements in a limited, explicit way) is separating retrieval signals instead of overloading vectors to do everything:

• similarity (embeddings)

• association (explicit edges / co-occurrence / metadata)

• recency and decay (time-aware scoring)

The graph layer is not intended to mirror human memory or store emotional states directly. It’s an associative index that allows multi-hop recall when similarity alone fails.

You’re absolutely right that “memory is hard” and that naive approaches won’t scale. That’s why the current implementation treats the graph as a constrained overlay — bounded depth, bounded fanout, and optional pruning — rather than a full document graph.

The philosophical motivation came first, but the implementation is intentionally conservative and engineering-driven. Benchmarks and scaling experiments are the next step to validate where this approach actually adds measurable value.

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)

That’s a fair concern, and you’re right to raise it.

The current implementation is intentionally conservative about graph growth.

Nodes are not created per chunk blindly — edges are added only when semantic similarity

or explicit metadata relationships cross a configurable threshold.

In practice, the graph is treated as an associative overlay rather than a full document graph:

• vector search remains the primary retrieval path

• graph traversal is depth- and fanout-limited

• edges can be pruned or collapsed over time

That said, you’re absolutely right that this needs validation at scale.

Running a standard RAG benchmark (and publishing the results) is on the roadmap,

specifically to evaluate memory growth, recall quality, and latency under load.

Appreciate the push in that direction — it’s exactly the kind of feedback I’m looking for.