Knowledge Graphs and Multi-Hop Reasoning for AI Agents
Source: mortalapps.com- Knowledge Graphs (KGs) represent factual information as interconnected entities and relationships, enabling structured data storage and retrieval for AI agents.
- Multi-hop reasoning allows agents to synthesize answers by traversing multiple relationships across distant nodes within a knowledge graph, addressing queries beyond direct facts.
- In production, KGs mitigate hallucination by grounding agent responses in verifiable facts and provide explainable reasoning paths for complex queries.
- Agents use KGs for tasks like complex question answering, root cause analysis, and dynamic planning, where inferring connections between disparate pieces of information is critical.
- Challenges include robust entity/relationship extraction, accurate LLM-to-graph query translation, and managing traversal depth to balance recall and computational cost.
Why This Matters
AI agents often struggle with synthesizing information across disparate data points, leading to fragmented responses or outright hallucinations when context windows are limited or information is implicitly linked. Knowledge graphs and multi-hop reasoning provide a structured solution to this problem. This approach was invented to enable systems to perform complex inference over large, interconnected datasets, moving beyond simple keyword matching or direct fact retrieval. For AI agents, it means transforming raw text or data into an explicit graph structure where entities (nodes) and their relationships (edges) are clearly defined. Ignoring this capability in production leads to agents that cannot answer nuanced questions requiring inferential steps, resulting in poor user experience, unreliable automation, and increased operational overhead for human intervention. When an agent needs to answer questions like "What projects did engineers who worked on the 'Phoenix' initiative also contribute to, and which of those projects are currently in production?", a knowledge graph with multi-hop reasoning is essential. This contrasts with vector search, which excels at semantic similarity but struggles with precise, inferential connections. For developers, it offers a powerful mechanism to ground agent intelligence in verifiable facts. For enterprises, it unlocks deeper analytical capabilities from existing data, enabling more sophisticated decision-making and automation. In production, it enhances agent reliability and explainability, crucial for high-stakes applications.
Core Concepts
Knowledge graphs provide a structured representation of information, enabling sophisticated reasoning for AI agents.
- Knowledge Graph (KG): A graph-structured database that stores information as a network of interconnected entities (nodes) and their relationships (edges). Each node represents a real-world object, concept, or event, and each edge describes a specific connection between two nodes, often with a type and direction.
- Multi-Hop Reasoning: The process of inferring an answer by traversing multiple relationships (hops) between entities in a knowledge graph. Instead of direct lookup, it involves following a path of interconnected facts to reach a conclusion or synthesize a response.
- Entities: The fundamental nodes in a knowledge graph, representing distinct objects or concepts. Examples include 'Person', 'Organization', 'Project', 'Skill', 'Location'. Each entity typically has a unique identifier and properties (attributes).
- Relationships: The directed edges connecting entities, describing how they are related. Relationships also have types (e.g.,
WORKS_ON,HAS_SKILL,LOCATED_IN) and can have properties. Relationships are crucial for defining the graph's structure and enabling traversal.
- Triples: The atomic unit of a knowledge graph, typically expressed as (Subject, Predicate, Object) or (Entity1, Relationship, Entity2). For example, (Alice, WORKS_ON, ProjectX) is a triple.
- Cypher: A declarative graph query language used for Neo4j, designed for querying and updating property graphs. It allows specifying patterns of nodes and relationships to retrieve specific data or paths.
- Graph Embeddings: Vector representations of nodes and edges in a knowledge graph, capturing their structural and semantic context. These embeddings can be used for tasks like link prediction, node classification, or enhancing retrieval in hybrid RAG systems.
- Semantic Search: A search method that understands the meaning and context of a query, rather than just matching keywords. When combined with KGs, it involves translating natural language queries into graph patterns to find semantically relevant information.
How It Works
Multi-hop reasoning with knowledge graphs for AI agents involves a sequence of processing steps, from natural language input to synthesized output.
1. User Query Ingestion
An agent receives a natural language query from a user. This query often implies complex relationships or requires inferential steps that are not immediately obvious from direct keyword matching. For example: "Which teams worked on projects related to 'cloud security' that were launched in the last year?"
2. Entity and Relationship Extraction
The initial query is processed by a Natural Language Processing (NLP) component, often an LLM or a specialized NER (Named Entity Recognition) model (e.g., SpaCy). This component identifies key entities (e.g., "teams", "cloud security", "projects", "last year") and potential relationships or constraints implied in the query. The output is a structured representation of extracted entities and their types, along with any temporal or logical constraints.
3. Graph Query Generation
An LLM, often prompted with the extracted entities and a schema of the knowledge graph, translates the user's intent into a formal graph query language, typically Cypher for Neo4j. This LLM is fine-tuned or given strong few-shot examples to generate accurate and efficient queries that reflect the multi-hop nature of the request. The generated query specifies the starting nodes, the types of relationships to traverse, the maximum traversal depth, and any filtering conditions.
4. Graph Traversal and Data Retrieval
The generated graph query is executed against the knowledge graph database (e.g., Neo4j). The graph database engine performs the multi-hop traversal, identifying paths and nodes that match the specified pattern. This involves navigating from initial entities through intermediate relationships and nodes to discover connected information. The traversal depth is a critical parameter; exceeding it can lead to irrelevant results or performance degradation. If no paths are found within the specified constraints, an empty result set is returned.
5. Result Synthesis and Context Construction
The retrieved graph data (nodes, relationships, and their properties) is then formatted and passed back to an LLM. This LLM's role is to synthesize the structured graph results into a coherent, natural language answer that directly addresses the user's original query. It reconstructs the reasoning path, explains the connections found, and filters out extraneous details. For complex results, the LLM may summarize or highlight key findings.
6. Failure Handling and Refinement
Throughout this process, failure modes are monitored. If entity extraction fails, the agent may prompt for clarification. If the LLM generates an invalid Cypher query, a retry mechanism with a refined prompt or a schema validation step is triggered. If the graph traversal yields no results, the agent might inform the user, suggest rephrasing, or attempt a broader, shallower query. Context window exhaustion during synthesis is managed by summarizing intermediate results or prioritizing critical information.
Architecture
The conceptual architecture for multi-hop reasoning with knowledge graphs involves several interconnected services orchestrated by an AI agent. The user initiates interaction with an Agent Orchestrator. This orchestrator is responsible for managing the overall workflow and coordinating calls to other components.
Upon receiving a natural language query, the Agent Orchestrator first sends it to an NLP Service. This service, potentially leveraging a specialized NER model or a smaller LLM, performs entity and relationship extraction, outputting structured entities and their types. These extracted components are then passed back to the Orchestrator.
The Orchestrator forwards the structured entities and the original query to an LLM Service configured for graph query generation. This LLM, acting as a query generator, translates the natural language intent into a formal graph query language, such as Cypher. The generated Cypher query is returned to the Orchestrator.
Next, the Orchestrator executes this Cypher query against the Graph Database (e.g., Neo4j). The Graph Database processes the query, performs the multi-hop traversal, and returns the relevant graph data (nodes, relationships, properties) to the Orchestrator. This data represents the discovered connections and facts.
Finally, the Orchestrator takes the retrieved graph data and the original user query, and sends them to another instance of the LLM Service, this time configured for result synthesis. This LLM interprets the structured graph data and formulates a coherent, natural language answer. The synthesized answer is then returned to the Agent Orchestrator, which presents it to the user. Error handling and retry logic are embedded within the Orchestrator to manage failures at each stage.
Entity and Relation Extraction with SpaCy
Accurate entity and relation extraction is the foundational step for knowledge graph integration. While large language models (LLMs) can perform this, specialized NLP libraries like SpaCy offer deterministic, high-performance extraction for defined schemas. SpaCy's pipeline can be customized with rule-based matchers or trained statistical models (NER, Dependency Parser) to identify specific entity types (e.g., PERSON, ORG, PRODUCT, PROJECT) and their grammatical relationships. For instance, a dependency parser can identify subject-verb-object structures that directly map to (Entity1, Relationship, Entity2) triples. Challenges include handling anaphora, co-reference resolution, and implicit relationships. A robust system often combines SpaCy for high-precision, low-recall extraction of known entities, with an LLM for broader, more semantic relation extraction, especially for novel or less structured text. The output should be a normalized list of entities with types and a list of potential triples, ready for graph ingestion or query generation.
Graph Schema Design and Data Ingestion
Effective multi-hop reasoning relies on a well-designed graph schema. This involves defining node labels (e.g., Person, Project, Skill), relationship types (e.g., WORKS_ON, HAS_SKILL, LEADS), and properties for both nodes and relationships. A common pattern is to use a property graph model where nodes and relationships can have arbitrary key-value pairs. Data ingestion can occur via batch processing from structured sources (SQL, CSV) or real-time streaming from unstructured text. For unstructured data, extracted entities and relations are transformed into Cypher MERGE statements to create or update nodes and relationships, ensuring idempotency and avoiding duplicate data. Indexing on frequently queried node properties (e.g., Person.name, Project.id) and relationship types is crucial for query performance. Schema evolution must be carefully managed to avoid breaking existing queries or data integrity.
LLM-to-Cypher Translation and Validation
Translating natural language queries into precise Cypher is a critical and complex task. An LLM is typically employed for this, often with few-shot prompting or fine-tuning on a dataset of natural language questions and corresponding Cypher queries. The prompt must include the graph schema (node labels, relationship types, key properties) to guide the LLM. Key considerations for the LLM are: identifying the starting node(s), determining the required relationship types and directions, inferring filtering conditions (e.g., WHERE n.property = 'value'), and specifying the return projection (e.g., RETURN n.name, r, m.title).
Validation of the generated Cypher is essential. This can involve: 1) Syntactic validation: checking if the query is valid Cypher. 2) Semantic validation: ensuring the query references existing node labels, relationship types, and properties in the schema. 3) Safety validation: preventing destructive operations (e.g., DELETE, DETACH DELETE) or excessively broad queries. If validation fails, the LLM can be prompted to self-correct, or a fallback mechanism (e.g., simpler keyword search) can be triggered.
Multi-Hop Traversal Algorithms
Graph databases like Neo4j natively support multi-hop traversals. The MATCH Cypher pattern specifies a variable-length path traversal, where (a)-[r*1..3]->(b)*1..3 denotes a path length between 1 and 3 hops. The choice of traversal algorithm (e.g., Breadth-First Search, Depth-First Search) is often handled by the database engine, but the query structure dictates the search space. For multi-hop reasoning, BFS is generally preferred as it explores nodes at increasing distances, which aligns with finding the shortest or most direct inferential path. Pathfinding algorithms like Dijkstra's or A* can be used for more complex scenarios where edge weights (e.g., confidence scores, recency) need to be considered. Edge cases include disconnected components (no path found), cyclical paths (preventing infinite loops), and dense nodes (supernodes) that can lead to combinatorial explosion if not constrained.
Context Synthesis and Answer Generation
Once the graph traversal yields results, the retrieved nodes and relationships form a structured context. This context, often a subgraph or a list of paths, is then fed to an LLM for synthesis. The LLM's role is to interpret this structured data and generate a coherent, natural language answer. The prompt for this LLM should instruct it to: 1) Summarize the findings. 2) Explain the reasoning path (i.e., how entities are connected). 3) Directly answer the original user query. 4) Maintain conciseness and avoid repetition. For complex subgraphs, the LLM may need to prioritize information based on relevance scores or user intent, potentially using techniques like graph summarization or sub-graph ranking before full synthesis. The output should be a human-readable explanation of the multi-hop inference.
Handling Ambiguity and Disconnected Subgraphs
Ambiguity arises when entities or relationships can be interpreted in multiple ways (e.g., "Apple" the company vs. "apple" the fruit). This is first addressed during entity extraction through disambiguation techniques (e.g., linking to a knowledge base like Wikidata). If ambiguity persists into query generation, the LLM might generate multiple possible Cypher queries, which can then be executed in parallel, or the agent might ask for clarification. Disconnected subgraphs occur when no path exists between the queried entities. In such cases, the graph database returns an empty result. The agent should be programmed to handle this gracefully, perhaps by informing the user that no direct connection was found, suggesting alternative queries, or performing a broader search (e.g., reducing constraints, increasing hop depth, or resorting to vector search for related but not directly connected information).
Query Optimization and Depth Management
Query performance in large knowledge graphs is critical. Optimizations include: 1) Indexing: Ensuring properties used in WHERE clauses or MATCH patterns are indexed. 2) Limiting Traversal Depth: MATCH where (a)-[r*1..N]->(b)N is a carefully chosen maximum depth. Excessive depth leads to combinatorial explosion and poor performance. A common practice is to start with a small depth (e.g., 2-3 hops) and incrementally increase it if no results are found. 3) Filtering Early: Applying WHERE clauses as early as possible in the query to reduce the search space. 4) Query Plan Analysis: Using the EXPLAIN or PROFILE commands in Cypher to understand how the database executes the query and identify bottlenecks. For agents, managing query complexity and depth dynamically based on the user's query and available resources is an advanced optimization.
Code Example
import spacy
from neo4j import GraphDatabase, basic_auth
import os
import logging
# Configure logging
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')
# Load SpaCy model
try:
nlp = spacy.load("en_core_web_sm")
except OSError:
logging.error("SpaCy model 'en_core_web_sm' not found. Please run: python -m spacy download en_core_web_sm")
exit(1)
# Neo4j connection details from environment variables
NEO4J_URI = os.environ.get("NEO4J_URI", "bolt://localhost:7687")
NEO4J_USER = os.environ.get("NEO4J_USER", "neo4j")
NEO4J_PASSWORD = os.environ.get("NEO4J_PASSWORD", "password")
class Neo4jGraph:
def __init__(self, uri, user, password):
self.driver = GraphDatabase.driver(uri, auth=basic_auth(user, password))
self.driver.verify_connectivity()
logging.info("Connected to Neo4j.")
def close(self):
self.driver.close()
logging.info("Disconnected from Neo4j.")
def add_entity(self, label, name, properties=None):
properties_str = ", ".join([f"{k}: '{v}'" for k, v in properties.items()]) if properties else ""
query = (
f"MERGE (n:{label} {{name: $name}})"
f" ON CREATE SET n.created_at = timestamp()"
f" ON MATCH SET n.updated_at = timestamp()"
f" RETURN n"
)
with self.driver.session() as session:
result = session.run(query, name=name)
logging.info(f"Added/Merged entity: {label} - {name}")
return result.single()[0]
def add_relationship(self, entity1_label, entity1_name, rel_type, entity2_label, entity2_name, properties=None):
properties_str = ", ".join([f"{k}: '{v}'" for k, v in properties.items()]) if properties else ""
query = (
f"MATCH (a:{entity1_label} {{name: $entity1_name}})"
f"MATCH (b:{entity2_label} {{name: $entity2_name}})"
f"MERGE (a)-[r:{rel_type}]->(b)"
f" ON CREATE SET r.created_at = timestamp()"
f" ON MATCH SET r.updated_at = timestamp()"
f" RETURN r"
)
with self.driver.session() as session:
result = session.run(query, entity1_name=entity1_name, entity2_name=entity2_name)
logging.info(f"Added/Merged relationship: {entity1_name} -[{rel_type}]-> {entity2_name}")
return result.single()[0]
def process_text_and_populate_graph(text, graph_db):
doc = nlp(text)
entities = {}
# Extract entities
for ent in doc.ents:
entity_label = ent.label_.replace(' ', '_').upper() # Convert 'ORG' to 'ORG', 'PERSON' to 'PERSON'
entities[ent.text] = graph_db.add_entity(entity_label, ent.text)
# Extract relationships (simplified for demonstration)
# This part would typically use dependency parsing or more advanced relation extraction
# For simplicity, we'll look for common patterns or just link entities mentioned together
# Example: Link a person to an organization if they appear near each other
for i, token in enumerate(doc):
if token.ent_type_ == "PERSON":
for j in range(max(0, i-5), min(len(doc), i+5)):
if doc[j].ent_type_ == "ORG" and token.text != doc[j].text:
graph_db.add_relationship(
"PERSON", token.text, "WORKS_FOR", "ORG", doc[j].text
)
if token.ent_type_ == "ORG":
for j in range(max(0, i-5), min(len(doc), i+5)):
if doc[j].ent_type_ == "PRODUCT" and token.text != doc[j].text:
graph_db.add_relationship(
"ORG", token.text, "PRODUCES", "PRODUCT", doc[j].text
)
if __name__ == "__main__":
graph_db = Neo4jGraph(NEO4J_URI, NEO4J_USER, NEO4J_PASSWORD)
sample_text = (
"Alice Smith works for ExampleCorp. ExampleCorp produces the 'Quantum Leap' software. "
"Bob Johnson, a senior engineer, also works at ExampleCorp and contributed to 'Quantum Leap'."
)
process_text_and_populate_graph(sample_text, graph_db)
# Verify data in Neo4j (optional, manual check or further code)
print("Graph population complete. Check your Neo4j browser for data.")
graph_db.close()
Connected to Neo4j. Added/Merged entity: PERSON - Alice Smith Added/Merged entity: ORG - ExampleCorp Added/Merged entity: PRODUCT - Quantum Leap Added/Merged entity: PERSON - Bob Johnson Added/Merged relationship: Alice Smith -[WORKS_FOR]-> ExampleCorp Added/Merged relationship: ExampleCorp -[PRODUCES]-> Quantum Leap Added/Merged relationship: Bob Johnson -[WORKS_FOR]-> ExampleCorp Graph population complete. Check your Neo4j browser for data. Disconnected from Neo4j.
import os
import json
import logging
from typing import Dict, Any
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')
# Mock LLM class for demonstration purposes
# In a real scenario, this would be an actual LLM API call (e.g., OpenAI, Anthropic)
class MockLLM:
def __init__(self, api_key: str):
self.api_key = api_key # Simulate API key usage
logging.info("MockLLM initialized.")
def generate_cypher_query(self, natural_language_query: str, graph_schema: Dict[str, Any]) -> str:
# This is a simplified mock. A real LLM would use the schema to generate a valid query.
# The prompt would instruct the LLM on how to map NL to Cypher based on the schema.
logging.info(f"MockLLM generating Cypher for: '{natural_language_query}'")
# Example logic for common queries
if "who works for" in natural_language_query.lower() and "examplecorp" in natural_language_query.lower():
return "MATCH (p:PERSON)-[:WORKS_FOR]->(o:ORG {name: 'ExampleCorp'}) RETURN p.name"
elif "projects by engineers at examplecorp" in natural_language_query.lower():
return "MATCH (p:PERSON)-[:WORKS_FOR]->(o:ORG {name: 'ExampleCorp'})-[:PRODUCES]->(prod:PRODUCT) RETURN p.name, prod.name"
elif "who contributed to quantum leap" in natural_language_query.lower():
return "MATCH (p:PERSON)-[:WORKS_FOR]->(o:ORG)-[:PRODUCES]->(prod:PRODUCT {name: 'Quantum Leap'}) RETURN p.name"
else:
return "// Could not generate a specific Cypher query for this request."
# Simplified graph schema for the LLM to understand
graph_schema = {
"nodes": [
{"label": "PERSON", "properties": ["name"]},
{"label": "ORG", "properties": ["name"]},
{"label": "PRODUCT", "properties": ["name"]}
],
"relationships": [
{"type": "WORKS_FOR", "from": "PERSON", "to": "ORG"},
{"type": "PRODUCES", "from": "ORG", "to": "PRODUCT"}
]
}
if __name__ == "__main__":
llm_api_key = os.environ.get("OPENAI_API_KEY", "mock-api-key") # Use a real key for actual LLM
mock_llm = MockLLM(llm_api_key)
queries = [
"Who works for ExampleCorp?",
"What projects are produced by engineers at ExampleCorp?",
"Who contributed to Quantum Leap?",
"What is the capital of France?" # Query not covered by schema
]
for query in queries:
generated_cypher = mock_llm.generate_cypher_query(query, graph_schema)
print(f"
Natural Language: {query}")
print(f"Generated Cypher: {generated_cypher}")
MockLLM initialized.
MockLLM generating Cypher for: 'Who works for ExampleCorp?'
Natural Language: Who works for ExampleCorp?
Generated Cypher: MATCH (p:PERSON)-[:WORKS_FOR]->(o:ORG {name: 'ExampleCorp'}) RETURN p.name
MockLLM generating Cypher for: 'What projects are produced by engineers at ExampleCorp?'
Natural Language: What projects are produced by engineers at ExampleCorp?
Generated Cypher: MATCH (p:PERSON)-[:WORKS_FOR]->(o:ORG {name: 'ExampleCorp'})-[:PRODUCES]->(prod:PRODUCT) RETURN p.name, prod.name
MockLLM generating Cypher for: 'Who contributed to Quantum Leap?'
Natural Language: Who contributed to Quantum Leap?
Generated Cypher: MATCH (p:PERSON)-[:WORKS_FOR]->(o:ORG)-[:PRODUCES]->(prod:PRODUCT {name: 'Quantum Leap'}) RETURN p.name
MockLLM generating Cypher for: 'What is the capital of France?'
Natural Language: What is the capital of France?
Generated Cypher: // Could not generate a specific Cypher query for this request.
import spacy
from neo4j import GraphDatabase, basic_auth
import os
import json
import logging
from typing import Dict, Any, List
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')
# Load SpaCy model (ensure 'en_core_web_sm' is downloaded)
try:
nlp = spacy.load("en_core_web_sm")
except OSError:
logging.error("SpaCy model 'en_core_web_sm' not found. Please run: python -m spacy download en_core_web_sm")
exit(1)
# Neo4j connection details
NEO4J_URI = os.environ.get("NEO4J_URI", "bolt://localhost:7687")
NEO4J_USER = os.environ.get("NEO4J_USER", "neo4j")
NEO4J_PASSWORD = os.environ.get("NEO4J_PASSWORD", "password")
class Neo4jGraph:
def __init__(self, uri, user, password):
self.driver = GraphDatabase.driver(uri, auth=basic_auth(user, password))
self.driver.verify_connectivity()
logging.info("Connected to Neo4j.")
def close(self):
self.driver.close()
logging.info("Disconnected from Neo4j.")
def execute_query(self, cypher_query: str) -> List[Dict[str, Any]]:
logging.info(f"Executing Cypher query: {cypher_query}")
with self.driver.session() as session:
result = session.run(cypher_query)
return [record.data() for record in result]
# Mock LLM for Cypher generation and result synthesis
class MockLLM:
def __init__(self, api_key: str):
self.api_key = api_key
def generate_cypher_query(self, natural_language_query: str, graph_schema: Dict[str, Any]) -> str:
if "who works for" in natural_language_query.lower() and "examplecorp" in natural_language_query.lower():
return "MATCH (p:PERSON)-[:WORKS_FOR]->(o:ORG {name: 'ExampleCorp'}) RETURN p.name AS PersonName"
elif "projects by engineers at examplecorp" in natural_language_query.lower():
return "MATCH (p:PERSON)-[:WORKS_FOR]->(o:ORG {name: 'ExampleCorp'})-[:PRODUCES]->(prod:PRODUCT) RETURN p.name AS Engineer, prod.name AS ProjectName"
elif "who contributed to quantum leap" in natural_language_query.lower():
return "MATCH (p:PERSON)-[:WORKS_FOR]->(o:ORG)-[:PRODUCES]->(prod:PRODUCT {name: 'Quantum Leap'}) RETURN p.name AS Contributor"
else:
return ""
def synthesize_answer(self, original_query: str, graph_results: List[Dict[str, Any]]) -> str:
if not graph_results:
return f"I couldn't find any information related to '{original_query}' in the knowledge graph."
if "projects by engineers at examplecorp" in original_query.lower():
engineers_projects = {res['Engineer']: [] for res in graph_results}
for res in graph_results:
engineers_projects[res['Engineer']].append(res['ProjectName'])
response_parts = []
for engineer, projects in engineers_projects.items():
response_parts.append(f"{engineer} worked on: {', '.join(projects)}.")
return f"Based on the knowledge graph: {'. '.join(response_parts)}"
elif "who works for examplecorp" in original_query.lower():
names = [res['PersonName'] for res in graph_results]
return f"The following people work for ExampleCorp: {', '.join(names)}."
elif "who contributed to quantum leap" in original_query.lower():
names = [res['Contributor'] for res in graph_results]
return f"The following people contributed to Quantum Leap: {', '.join(names)}."
return f"I found some data for '{original_query}': {json.dumps(graph_results)}"
# Simplified graph schema for LLM
graph_schema = {
"nodes": [
{"label": "PERSON", "properties": ["name"]},
{"label": "ORG", "properties": ["name"]},
{"label": "PRODUCT", "properties": ["name"]}
],
"relationships": [
{"type": "WORKS_FOR", "from": "PERSON", "to": "ORG"},
{"type": "PRODUCES", "from": "ORG", "to": "PRODUCT"}
]
}
if __name__ == "__main__":
# Initialize graph and LLM
graph_db = Neo4jGraph(NEO4J_URI, NEO4J_USER, NEO4J_PASSWORD)
llm_api_key = os.environ.get("OPENAI_API_KEY", "mock-api-key")
mock_llm = MockLLM(llm_api_key)
# --- Populate graph with sample data (from Example 1) ---
sample_text = (
"Alice Smith works for ExampleCorp. ExampleCorp produces the 'Quantum Leap' software. "
"Bob Johnson, a senior engineer, also works at ExampleCorp and contributed to 'Quantum Leap'."
)
doc = nlp(sample_text)
for ent in doc.ents:
entity_label = ent.label_.replace(' ', '_').upper()
graph_db.add_entity(entity_label, ent.text)
for i, token in enumerate(doc):
if token.ent_type_ == "PERSON":
for j in range(max(0, i-5), min(len(doc), i+5)):
if doc[j].ent_type_ == "ORG" and token.text != doc[j].text:
graph_db.add_relationship(
"PERSON", token.text, "WORKS_FOR", "ORG", doc[j].text
)
if token.ent_type_ == "ORG":
for j in range(max(0, i-5), min(len(doc), i+5)):
if doc[j].ent_type_ == "PRODUCT" and token.text != doc[j].text:
graph_db.add_relationship(
"ORG", token.text, "PRODUCES", "PRODUCT", doc[j].text
)
print("
--- Graph Population Complete ---
")
# --- End Graph Population ---
queries = [
"What projects are produced by engineers at ExampleCorp?",
"Who works for ExampleCorp?",
"Who contributed to Quantum Leap?",
"What is the weather like in London?" # Unrelated query
]
for query in queries:
print(f"User Query: {query}")
# 1. LLM generates Cypher
cypher_query = mock_llm.generate_cypher_query(query, graph_schema)
if cypher_query:
# 2. Execute Cypher against Neo4j
graph_results = graph_db.execute_query(cypher_query)
# 3. LLM synthesizes answer
final_answer = mock_llm.synthesize_answer(query, graph_results)
else:
final_answer = mock_llm.synthesize_answer(query, []) # No Cypher generated, no results
print(f"Agent Answer: {final_answer}
")
graph_db.close()
Connected to Neo4j.
Added/Merged entity: PERSON - Alice Smith
Added/Merged entity: ORG - ExampleCorp
Added/Merged entity: PRODUCT - Quantum Leap
Added/Merged entity: PERSON - Bob Johnson
Added/Merged relationship: Alice Smith -[WORKS_FOR]-> ExampleCorp
Added/Merged relationship: ExampleCorp -[PRODUCES]-> Quantum Leap
Added/Merged relationship: Bob Johnson -[WORKS_FOR]-> ExampleCorp
--- Graph Population Complete ---
User Query: What projects are produced by engineers at ExampleCorp?
Executing Cypher query: MATCH (p:PERSON)-[:WORKS_FOR]->(o:ORG {name: 'ExampleCorp'})-[:PRODUCES]->(prod:PRODUCT) RETURN p.name AS Engineer, prod.name AS ProjectName
Agent Answer: Based on the knowledge graph: Alice Smith worked on: Quantum Leap. Bob Johnson worked on: Quantum Leap.
User Query: Who works for ExampleCorp?
Executing Cypher query: MATCH (p:PERSON)-[:WORKS_FOR]->(o:ORG {name: 'ExampleCorp'}) RETURN p.name AS PersonName
Agent Answer: The following people work for ExampleCorp: Alice Smith, Bob Johnson.
User Query: Who contributed to Quantum Leap?
Executing Cypher query: MATCH (p:PERSON)-[:WORKS_FOR]->(o:ORG)-[:PRODUCES]->(prod:PRODUCT {name: 'Quantum Leap'}) RETURN p.name AS Contributor
Agent Answer: The following people contributed to Quantum Leap: Alice Smith, Bob Johnson.
User Query: What is the weather like in London?
Agent Answer: I couldn't find any information related to 'What is the weather like in London?' in the knowledge graph.
Disconnected from Neo4j.