Créer un agent GraphRAG avec Neo4j et Milvus
Ce blog a été initialement publié sur Neo4j et republié ici avec autorisation
Vue d’ensemble
Cet article de blog détaille comment créer un agent GraphRAG en utilisant la base de données graphe Neo4j et la base de données vectorielle Milvus. Cet agent combine la puissance des bases de données graphes et de la recherche vectorielle pour fournir des réponses précises et pertinentes aux requêtes des utilisateurs. Dans cet exemple, nous utiliserons LangGraph, Llama 3.1 8B avec Ollama et GPT-4o.
Les systèmes traditionnels de génération augmentée par récupération (RAG) s’appuient uniquement sur des bases de données vectorielles pour récupérer des documents pertinents. Notre approche va plus loin en intégrant Neo4j pour capturer les relations entre les entités et les concepts, offrant une compréhension plus nuancée de l’information. Nous voulons créer un système RAG plus robuste et plus informatif en combinant ces deux techniques.
Création de l’agent RAG
Notre agent suit trois concepts clés : routage, mécanismes de repli et autocorrection. Ces principes sont mis en œuvre au moyen d’une série de composants LangGraph :
Routage – Un mécanisme de routage dédié décide s’il faut utiliser la base de données vectorielle, le graphe de connaissances ou une combinaison des deux, en fonction de la requête.
Repli – Dans les situations où la récupération initiale est insuffisante, l’agent se rabat sur une recherche web à l’aide de Tavily.
Autocorrection – L’agent évalue ses propres réponses et tente de corriger les hallucinations ou les inexactitudes.
Nous avons ensuite d’autres composants, tels que :
Récupération – Nous utilisons Milvus, une base de données vectorielle open source et hautes performances, pour stocker et récupérer des fragments de documents sur la base de leur similarité sémantique avec la requête de l’utilisateur.
Enrichissement par graphe – Neo4j est utilisé pour construire un graphe de connaissances à partir des documents récupérés, enrichissant le contexte avec des relations et des entités.
Intégration des LLM – Llama 3.1 8B, un LLM local, est utilisé pour générer des réponses et évaluer la pertinence et l’exactitude des informations récupérées, tandis que GPT-4o est utilisé pour générer Cypher, le langage de requête utilisé par Neo4j.
L’architecture GraphRAG
L’architecture de notre agent GraphRAG peut être visualisée comme un flux de travail avec plusieurs nœuds interconnectés :
Routage des questions – L’agent analyse d’abord la question afin de déterminer la meilleure stratégie de récupération (recherche vectorielle, recherche dans le graphe, ou les deux).
Récupération – Sur la base de la décision de routage, les documents pertinents sont récupérés depuis Milvus, ou les informations sont extraites du graphe Neo4j.
Génération – Le LLM génère une réponse à l’aide du contexte récupéré.
Évaluation – L’agent évalue la réponse générée en termes de pertinence, d’exactitude et d’hallucinations potentielles.
Affinement (si nécessaire) – Si la réponse est jugée insatisfaisante, l’agent peut affiner sa recherche ou tenter de corriger les erreurs.
Exemples d’agents
Pour mettre en valeur les capacités de nos agents LLM, examinons deux composants différents : Graph Generation et Composite Agent .
Bien que le code complet soit disponible à la fin de cet article, ces extraits permettront de mieux comprendre comment ces agents fonctionnent au sein du framework LangChain.
Génération de graphe
Ce composant est conçu pour améliorer le processus de questions-réponses en utilisant les capacités de Neo4j. Il répond aux questions en exploitant les connaissances intégrées dans la base de données graphe Neo4j. Voici comment il fonctionne :
1. GraphCypherQAChain – Permet au LLM d’interagir avec la base de données graphe Neo4j. Il utilise le LLM de deux façons :
cypher_llm– Cette instance du LLM est responsable de la génération de requêtes Cypher pour extraire les informations pertinentes du graphe en fonction de la question de l'utilisateur.Validation – S'assure que les requêtes Cypher sont validées afin de garantir qu'elles sont syntaxiquement correctes.
2. Récupération du contexte – Les requêtes validées sont exécutées sur le graphe Neo4j pour récupérer le contexte nécessaire.
3. Génération de réponse – Le modèle de langage utilise le contexte récupéré pour générer une réponse à la question de l'utilisateur.
### Generate Cypher Query
llm = ChatOllama(model=local_llm, temperature=0)
# Chain
graph_rag_chain = GraphCypherQAChain.from_llm(
cypher_llm=llm,
qa_llm=llm,
validate_cypher=True,
graph=graph,
verbose=True,
return_intermediate_steps=True,
return_direct=True,
)
# Run
question = "agent memory"
generation = graph_rag_chain.invoke({"query": question})
Ce composant permet au système RAG d'exploiter Neo4j, ce qui peut contribuer à fournir des réponses plus complètes et plus précises.
Agent composite, graphe et vecteur 🪄
C'est ici que la magie opère : notre agent peut combiner les résultats de Milvus et de Neo4j, permettant une meilleure compréhension des informations et conduisant à des réponses plus précises et nuancées. Voici comment cela fonctionne :
Prompts – Nous définissons un prompt qui demande au LLM d'utiliser le contexte provenant à la fois de Milvus et de Neo4j pour répondre à la question.
Récupération – L'agent récupère les informations pertinentes depuis Milvus (en utilisant la recherche vectorielle) et Neo4j (en utilisant la génération de graphe).
Génération de réponse – Llama 3.1 8B traite le prompt et génère une réponse concise, en s'appuyant sur les connaissances combinées des bases de données vectorielle et graphe avec la chaîne composite.
### Composite Vector + Graph Generations
cypher_prompt = PromptTemplate(
template="""You are an expert at generating Cypher queries for Neo4j.
Use the following schema to generate a Cypher query that answers the given question.
Make the query flexible by using case-insensitive matching and partial string matching where appropriate.
Focus on searching paper titles as they contain the most relevant information.
Schema:
{schema}
Question: {question}
Cypher Query:""",
input_variables=["schema", "question"],
)
# QA prompt
qa_prompt = PromptTemplate(
template="""You are an assistant for question-answering tasks.
Use the following Cypher query results to answer the question. If you don't know the answer, just say that you don't know.
Use three sentences maximum and keep the answer concise. If topic information is not available, focus on the paper titles.
Question: {question}
Cypher Query: {query}
Query Results: {context}
Answer:""",
input_variables=["question", "query", "context"],
)
llm = ChatOpenAI(model="gpt-4o", temperature=0)
# Chain
graph_rag_chain = GraphCypherQAChain.from_llm(
cypher_llm=llm,
qa_llm=llm,
validate_cypher=True,
graph=graph,
verbose=True,
return_intermediate_steps=True,
return_direct=True,
cypher_prompt=cypher_prompt,
qa_prompt=qa_prompt,
)
Jetons un œil aux résultats de notre recherche, en combinant les forces des bases de données graphe et vectorielle pour améliorer notre découverte d'articles de recherche.
Nous commençons par notre recherche graphe avec Neo4j :
# Example input data
question = "What paper talks about Multi-Agent?"
generation = graph_rag_chain.invoke({"query": question})
print(generation)
> Entering new GraphCypherQAChain chain...
Generated Cypher:
cypher
MATCH (p:Paper)
WHERE toLower(p.title) CONTAINS toLower("Multi-Agent")
RETURN p.title AS PaperTitle, p.summary AS Summary, p.url AS URL
> Finished chain.
{'query': 'What paper talks about Multi-Agent?', 'result': [{'PaperTitle': 'Collaborative Multi-Agent, Multi-Reasoning-Path (CoMM) Prompting Framework', 'Summary': 'In this work, we aim to push the upper bound of the reasoning capability of LLMs by proposing a collaborative multi-agent, multi-reasoning-path (CoMM) prompting framework. Specifically, we prompt LLMs to play different roles in a problem-solving team, and encourage different role-play agents to collaboratively solve the target task. In particular, we discover that applying different reasoning paths for different roles is an effective strategy to implement few-shot prompting approaches in the multi-agent scenarios. Empirical results demonstrate the effectiveness of the proposed methods on two college-level science problems over competitive baselines. Our further analysis shows the necessity of prompting LLMs to play different roles or experts independently.', 'URL': 'https://github.com/amazon-science/comm-prompt'}]
La recherche dans le graphe excelle à trouver des relations et des métadonnées. Elle peut rapidement identifier des articles à partir des titres, des auteurs ou de catégories prédéfinies, en fournissant une vue structurée des données.
Ensuite, nous passons à notre recherche vectorielle pour une perspective différente :
# Example input data
question = "What paper talks about Multi-Agent?"
# Get vector + graph answers
docs = retriever.invoke(question)
vector_context = rag_chain.invoke({"context": docs, "question": question})
> The paper discusses "Adaptive In-conversation Team Building for Language Model Agents" and talks about Multi-Agent. It presents a new adaptive team-building paradigm that offers a flexible solution for building teams of LLM agents to solve complex tasks effectively. The approach, called Captain Agent, dynamically forms and manages teams for each step of the task-solving process, utilizing nested group conversations and reflection to ensure diverse expertise and prevent stereotypical outputs.
La recherche vectorielle est vraiment efficace pour comprendre le contexte et la similarité sémantique. Elle peut découvrir des articles qui sont conceptuellement liés à la requête, même s’ils ne contiennent pas explicitement les termes recherchés.
Enfin, nous combinons les deux méthodes de recherche :
Il s’agit d’une partie cruciale de notre agent RAG, qui permet d’utiliser à la fois des bases de données vectorielles et des bases de données de graphes.
composite_chain = prompt | llm | StrOutputParser()
answer = composite_chain.invoke({"question": question, "context": vector_context, "graph_context": graph_context})
print(answer)
> The paper "Collaborative Multi-Agent, Multi-Reasoning-Path (CoMM) Prompting Framework" talks about Multi-Agent. It proposes a framework that prompts LLMs to play different roles in a problem-solving team and encourages different role-play agents to collaboratively solve the target task. The paper presents empirical results demonstrating the effectiveness of the proposed methods on two college-level science problems.
En intégrant les recherches par graphe et vectorielle, nous tirons parti des points forts des deux approches. La recherche dans le graphe apporte de la précision et navigue dans des relations structurées, tandis que la recherche vectorielle ajoute de la profondeur grâce à la compréhension sémantique.
Cette méthode combinée offre plusieurs avantages :
Amélioration du rappel : Elle trouve des articles pertinents qui pourraient être manqués par l’une ou l’autre méthode seule.
Contexte enrichi : Elle fournit une compréhension plus nuancée de la manière dont les articles sont liés entre eux.
Flexibilité : Elle peut s’adapter à différents types de requêtes, des recherches par mots-clés spécifiques aux explorations conceptuelles plus larges.
En résumé
Dans cet article de blog, nous avons montré comment créer un Agent GraphRAG à l’aide de Neo4j et Milvus. En combinant les points forts des bases de données de graphes et de la recherche vectorielle, cet agent fournit des réponses précises et pertinentes aux requêtes des utilisateurs.
L’architecture de notre agent RAG, avec son routage dédié, ses mécanismes de repli et ses capacités d’autocorrection, le rend robuste et fiable. Les exemples des composants Graph Generation et Composite Agent montrent comment cet agent peut exploiter à la fois les bases de données vectorielles et de graphes pour fournir des réponses complètes et nuancées.
Nous espérons que ce guide vous a été utile et qu’il vous incitera à explorer les possibilités de combiner les bases de données de graphes et la recherche vectorielle dans vos propres projets.
Le code actuel est disponible sur GitHub.
Suivez le guide
Stephen BatifolStephen Batifol is a Developer Advocate at Zilliz. He previously worked as a Machine Learning Engineer at Wolt, where he was working on the ML Platform and as a Data Scientist at Brevo. Stephen studied Computer Science and Artificial Intelligence. He enjoys dancing and surfing.
Jason KooJason Koo is a Developer Advocate at Neo4j
Continuer à lire
A Few Notes from Databricks Data + AI Summit 2026: Why the Data Layer Matters Again
James Luan shares notes from Databricks Data + AI Summit 2026 on why production AI is pushing the data layer back to the center of infrastructure.
Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)
Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.
Zilliz Cloud Update: Tiered Storage, Business Critical Plan, Cross-Region Backup, and Pricing Changes
This release offers a rebuilt tiered storage with lower costs, a new Business Critical plan for enhanced security, and pricing updates, among other features.