imbajin commented on code in PR #424:
URL:
https://github.com/apache/incubator-hugegraph-doc/pull/424#discussion_r2480924587
##########
content/en/blog/hugegraph-ai/agentic_graphrag.md:
##########
@@ -0,0 +1,452 @@
+---
+date: 2025-10-29
+title: "Agentic GraphRAG"
+linkTitle: "Agentic GraphRAG"
+---
+
+# Project Background
+
+To address the problem of temporal discrepancies between model training data
and real-world data, Retrieval-Augmented Generation (RAG) technology has
emerged. RAG, as the name suggests, is a technique that retrieves relevant data
from external data sources (Retrieval) to augment (Argument) the quality of the
answers generated (Generation) by large language models.
+
+The earliest RAG employed a simple Retrieval-Generation architecture. We take
the user's question, perform some pre-processing (keyword extraction, etc.),
obtain the pre-processed question, and then use an Embedding Model to grab
relevant information from a vast amount of data as a Prompt, which is then fed
to the large language model to enhance the quality of its responses.
+
+However, relying solely on semantic similarity matching to retrieve relevant
information may not handle all situations, as the information that can enhance
answer quality may not always be semantically similar to the question itself. A
common example is: "Tell me the ontological view of the disciple of the
philosopher who proposed that water is the origin of all things." Our data may
not directly contain the answer to this question. The knowledge base might
contain:
+
+1. Thales proposed that water is the origin of all things.
+2. Anaximander was a disciple of Thales.
+3. Anaximander identified the Apeiron, which has no formal definition, as the
origin of all things.
+
+If we rely solely on semantic similarity matching, we are likely to only
retrieve the first sentence to augment the large language model's answer.
However, without information from sentences 2 and 3, and if the large language
model lacks philosophy-related knowledge in its training dxata, it will be
unable to correctly answer the question and might even "hallucinate."
+
+Therefore, GraphRAG technology was developed. A typical GraphRAG involves two
steps:
+
+1. Offline: We need to build a graph index for the knowledge base offline
(converting unstructured data into structured data and storing it in a graph
database).
+2. Online: When the GraphRAG system receives a user question, it can capture
the relationships between different entities in the knowledge base using the
graph database. Consequently, we can retrieve the three sentences above (the
specific graph database index might look like the following example).
+
+<div style="text-align: center;">
+ <img src="/blog/images/images-server/agentic-background.png" alt="image"
width="400">
+</div>
+
+However, GraphRAG itself also presents several challenges:
+
+1. How to construct the Graph Index is a complex task, and the quality of the
Graph Index impacts the quality of the model's answers.
+2. The GraphRAG index construction process consumes a significant number of
tokens.
+3. GraphRAG involves a variety of graph algorithms. How can we achieve the
best Retrieval performance? (The configuration space is too large).
+
+This project primarily focuses on the third issue. We aim to leverage the
generalization capabilities of large language models to automatically identify
the user's intent within the question and then select the appropriate
configuration (such as choosing the most suitable graph algorithm) to retrieve
the corresponding data from the graph database to enhance the quality of the
large language model's answer. This is the objective of Agentic GraphRAG.
+
+# Existing Workflow: Elegant Decoupling, Unfinished Parallelism
+
+The current HugeGraph-AI project has two core abstractions:
+
+1. Operator: Represents an "atomic operation unit" responsible for completing
a specific subtask, such as vector index construction, vector similarity
search, graph data related operations, and so on.
+2. Workflow: An execution flow composed of Operators as nodes in a
**chain-like** structure. The pre-defined Workflows in the project correspond
one-to-one with the project's demo use cases (e.g., GraphRAG,
Vector-Similarity-Based RAG).
+
+The implementation of an Operator needs to adhere to the following interface:
+
+```python
+class Operator:
+ @abstractmethod
+ def run(context: dict[str, Any]) -> dict[str,Any]:
+ return {}
+```
+
+During actual runtime, an Operator accepts a dictionary-type context object as
input, and the returned object is also a dictionary, which can be used as input
for the next Operator. This design has one very clever aspect: it decouples the
dependencies between different Operators from the specific implementation of
the Operator itself. Each Operator is a relatively independent entity. If
Operator A needs to rely on the output of Operator B, it only needs to check if
the context object contains the output of Operator B. This is a loosely coupled
design. The advantage is that we can easily combine different Operators freely.
Assembling (configuring) a suitable Workflow to serve user requests based on
different user inputs - isn't that precisely the goal of Agentic GraphRAG
mentioned in the project background?
+
+```
Review Comment:
```suggestion
```text
👉🏼 Theoretically, the existing design can already transition smoothly to
Agentic GraphRAG. However, the current design has several outstanding issues:
```
💡 Suggest adding language identifier `text` to improve rendering
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
