GitHub user imbajin added a comment to the discussion: [Discussion] The selection of Agentic/Taskflow frame
> Hey > [@imbajin](https://github.com/imbajin?rgh-link-date=2025-02-28T06%3A39%3A43.000Z) > I was working with agentic graph RAG recently. The project aimed at Document > QnA from a story book. It required Agentic graph-RAG approach as in a story, > different characters can have different relationships with each other. Also > different incidents are linked to each other. So, here agentic graph-RAG > worked well if someone asks deep questions from story. So i made graph where > centre node was book --> first level nodes were chunks (each chapter of that > book) --> second level nodes were atomic_facts from that chunk--> final level > nodes were characters. Same characters from different atomic_facts were > connected (so as to know that character was present in which parts of the > story). Also different characters were connected to each other having some > relationships. > > So for finding the answer of user's question, I used LANGGRAPH. It was really > lightweight , Fast and simple to implement it. > > There were agents - > > * character finder (to find all characters, user's question contains) > * atomic fact finder ( worked at finding the relevant atomic facts for each > character, according to user query. Using similarity search) > * information validator (checked if information is enough) > * atomic fact extractor (if information is not enough, then extract the > nearby atomic fact, or nearby events in that story) > * final composer (compose final answer using extracted information and user > query. > > It was a fixed agentic system, worked at graphs of one kind only > > I have a question, regarding what is the requirement ? Do we need to create a > Interface, where user can create his own agentic system for his Graph , just > using drag-drop or prompts (without code) If yes, then using LANGGRAPH or > completely doing it manually would be the best approach, because there will > be transparency , and user would know what is happening. Using CrewAI would > not be a good idea , as there we don't know what is happening under the hood. > > Here is the project :- > [Aryankb/DOC_QNA](https://github.com/Aryankb/DOC_QNA?rgh-link-date=2025-02-28T06%3A39%3A43.000Z) @Aryankb Thanks for your feedback. At present, whether we use `crewai`, `llamaindex`, or `pydanic-ai`, we should mainly use its **workflow component** & some basic agent encapsulation, and it is likely that we will **not use role concepts** such as `Crew` for design, If pydanic-ai is relatively stable, it actually looks like one of the most suitable (it also has a Graph design similar to LangGraph) The main concern about LangGraph comes from feedback that its performance is poor and its resource consumption is high(Like `Agno`'s benchmark). In addition, it is often used in combination with `LangChain`. We do not want to passively introduce the LangChain family bucket(And in fact we already added an `HugeGraphQAChain` interface in it..) GitHub link: https://github.com/apache/incubator-hugegraph-ai/discussions/203#discussioncomment-12666600 ---- This is an automatically sent email for dev@hugegraph.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@hugegraph.apache.org
