vector embeddings

[matt-beanland]

Enhance so that vector embeddings are supported with native queries.

See https://neo4j.com/labs/genai-ecosystem/vector-search/ Neo4j Vector Index and Search - Neo4j Labs

[matt-beanland]

Vector embeddings will require indexes, think this means we'll need to code generate migrations.

Also we'll need some repo level dsl configuration of a minimum neo4j version, and a validator which only allows vector embeddings when neo4j is at least 5.15 (to simplify index creation) see https://neo4j.com/docs/cypher-manual/current/indexes/semantic-indexes/vector-indexes/ Vector indexes - Cypher Manual

[matt-beanland]

Enriching with context from a downstream consumer working through what AshNeo4j vector support unlocks.

Description

A concrete consumer use case for AshNeo4j vector support has surfaced in diffo_example#43 — semantic search over Diffo.Provider.Note records, ranking parent Instance resources by relevance to a natural-language query, composable with other Ash filters as a value metric. The text is already there on Note; what's missing is the embedding storage and the vector query expressions.

While discovering the path forward we also found that ash_ai's vectorize do ... end macro and embed-on-write machinery is hard-coupled to AshPostgres at compile time:

# deps/ash_ai/lib/ash_ai/transformers/vectorize.ex:30
if Ash.Resource.Info.data_layer(dsl) != AshPostgres.DataLayer do
  raise "AshAi vectorization only currently supports AshPostgres"
end

So AshNeo4j vector support is one half of the bridge; ash_ai growing data-layer-agnostic vectorize (or an explicit AshNeo4j branch alongside the AshPostgres one) is the other half. The two pieces are paired.

What we'd find useful

The technical territory you've already captured in this ticket (vector indexes via migrations, repo-level Neo4j-version DSL, validator gating embeddings on Neo4j ≥ 5.15) covers the AshNeo4j side cleanly. What would help downstream consumers see the full bridge:

• A signpost from this ticket to the ash_ai coordination — the eventual API surface for declaring vectorized attributes likely composes with ash_ai's vectorize do macro, so the design probably wants to consider both sides at once.
• A migration-generation story made explicit. ash_postgres has its sibling migration infrastructure for index creation; if AshNeo4j wants to follow that pattern, naming it in scope here makes the ask concrete.

Why it matters

Once this lands, semantic search becomes available across the assignment graph for every Diffo consumer that uses Notes — and Notes are the most under-leveraged surface in any operational system (free-text annotations carrying the lived experience the schema doesn't say). It also unlocks the "answer as a value metric" pattern from diffo_example#40 — relevance becomes a dimension the preference/worldview machinery can weigh alongside cost, distance, capacity, fairness-ledger. And the WWZD reframing in #43 (note relevance as an Ash calculation, composable with every other filter and sort, rather than a special query primitive) only works if the data layer can translate the relevance expression to a native vector query.

A possible direction

Approach the AshNeo4j side and the ash_ai coordination as paired pieces. If AshNeo4j grows the vector primitive and ash_ai dispatches to the data layer through a clean adapter behaviour, both ecosystems get the contribution without duplicate logic. A fork-and-contribute round on the ash_ai side (adding an AshNeo4j branch in the vectorize transformer) would be the natural pairing once AshNeo4j vector indexes are reachable.

No prescription on shape — your ticket body already names the right technical pieces. Just surfacing the downstream context so the work has a sense of audience and partner-pieces.

[matt-beanland]

Chatted with Josh Price about receptiveness for PR on Ash.AI to support AshNeo4j. In short wouldn't be accepted as further couples AshAI to datalayer concerns. AshAI should be datalayer independent, either by itself or by delegating to AshVector. Delegating to AshVector just shifts the coupling problem though, but does allow vector search without AshAI (of minor value?).

So really the Q is how to make AshAi datalayer independent? That would likely be an acceptable PR.

Here is some deep wiki asked by Josh, but as he mentioned Neo4j not AshNeo4j deep wiki didn't recall that it already knows about AshNeo4j when answering, so take the answers lightly. https://deepwiki.com/search/where-is-pg-support-for-vector_34c53f02-2a94-47f6-b43c-5c8140844d0c