Does Nornic supports one to many relation?

[orlevyhs]

If I’ve understood correctly, the code allows for a single graph node to have multiple vectors, but I don’t see a way to implement this.

Is this a supported feature or a design choice?

[krotname]

If by one-to-many you mean one graph node with multiple vector representations, yes, current code/docs support it, but not as repeated embedding properties.

storage.Node has two dedicated fields:

NamedEmbeddings map[string][]float32
ChunkEmbeddings [][]float32

The architecture docs describe the split like this:

• managed/chunked documents -> ChunkEmbeddings; [0] is the main embedding and [1..N] are additional chunks;
• client-managed named vectors -> NamedEmbeddings, with an unnamed vector stored as "default";
• property vectors can still live in node.Properties[index.property] for Cypher compatibility.

The clean user-facing path for multiple named vectors appears to be the Qdrant gRPC layer: create a collection with named vector configs, for example title and content, then upsert one point with vector={"title": ..., "content": ...}. That maps to one graph node with multiple entries in NamedEmbeddings.

For Cypher vector search, db.index.vector.queryNodes chooses per node in this order: named embedding for the index property/default, property vector, then chunk embeddings, taking the best score across chunks.

So: supported by design, but the API matters. Use Qdrant gRPC for named vectors, use chunked embeddings for long content, and use separate graph nodes plus edges if each vector needs independent graph properties or relationships.

[orneryd]

Yes, as @krotname stated, this is supported, including from Cypher.

For named vectors, the Cypher vector index property maps to the NamedEmbeddings key. For example, if a node has NamedEmbeddings["title"] and NamedEmbeddings["content"], create/query separate Cypher vector indexes like:

CREATE VECTOR INDEX title_idx
FOR (n:Doc) ON (n.title)
OPTIONS {indexConfig: {`vector.dimensions`: 1536, `vector.similarity_function`: 'cosine'}};

CALL db.index.vector.queryNodes('title_idx', 10, $queryVector)
YIELD node, score
RETURN node, score;

[orlevyhs]

Thanks a lot for your answers! They were incredibly helpful!

I’m still exploring the concept of creating RAGs for local AI usage and production knowledge bases. Initially, I had the idea that each node represents a concept or service, and each vector represents a fact. Therefore, a service could have a vast list of ongoing facts about it, such as how it operates, how it accesses the database, how it handles payloads, aggregation logic, business logic, and so on.

If I understand correctly, I should use named embeddings to tie the list of facts to the node. Alternatively, I could split log documents into chunks, but then I would lose control over the chunk per “fact.”

There’s always the “native” way of creating a new node for each “fact” and connecting it to the “parent” node.

Did you find a use-case for embedding naming?

[orneryd]

would lose control over the chunk per “fact.”

There’s always the “native” way of creating a new node for each “fact” and connecting it to the “parent” node.

Did you find a use-case for embedding naming?

well a few things first a vector/embedding is a floating point integer array representation of text. so the text "foo" vectorized might look like [0,0,1,-1,0...] etc.. in memory. In clear terms an embedding is derived from the data itself which makes semantic search possible.

In Qdrant, a Point is the fundamental unit of storage. It consists of:

• ID: Unique identifier.
• Vectors: Either a single unnamed vector, or a fixed map of named vectors defined at the collection schema level.
• Payload: A JSON object containing metadata/properties (attributes, text, flags, etc.).

the payload i mapped to properties and to prevent clobbering the actual data, i kept them separate from vectors. right now i think the property -> namedEmbedding is opaque to the user if there is a vector index and the fields happen to the be the same.

I am open to this changing I had only initially considered qDrant gRPC to be a temporary ingestion endpoint and not the main management of the database.