cancel
Showing results for 
Search instead for 
Did you mean: 

Finding a node down a relationship 'path'

Not sure the best way to phrase the question, and apologies if this was clearly answered elsewhere - not knowing the right terms to search makes finding that answer difficult.

Very new to neo4j and graph databases, and still learning a lot.

The application I'm using a graph database for is a backend for an AI chat bot. It detects a topic (a starting node) and as the user asks questions (determined by the AI software), the "intent" of that question is a relationship to another node of information.

These nodes branch out into a large tree. The AI software keeps track of the user's context... the starting topic and the last 3 questions asked (mainly so the user can 'back up' a level, or ask a question related to a previous answer)

Right now, to find the target answer node, I'm building a cypher query in python. A full request with 3 levels of context looks like:

MATCH (:topic {name: "topic_name"})-[*0..]->()-[:context1]->()-[:context2]->()-[:context3]->(end) RETURN end

The -[*0..]->() is to skip over any relationships/nodes that may be more than 3 back from the end node.

Is there a more efficient way to do this? It feels clunky. But I'm also very new at this and am learning as I go. I need to always start at the topic node, so I'm locating the right answer - if I'm searching nodes without the start point, I could grab a branch on another topic's tree. I'd rather not include the topic name on each answer node, as some trees intersect as topics converge, and then all of those answer nodes would need to be updated each time a new intersection would be made.

Edit: Also wanted to add that state tracking by internally remembering which was the last node the user was on is possible, but difficult to implement with the frontend. So a new tree search for each question is a better option, at least for now.

Given all that, is that query the best/most efficient way to do it? I haven't seen any documentation yet that explains a better way, though to be fair, there may well be and I'm not well versed in the terms enough yet to recognize it.

Sorry for the long post, wanted to be sure I got my question asked clearly.

0 REPLIES 0