HN रिलीज़: FastGraphRAG – पारंपरिक PageRank का उपयोग करने वाली उन्नत RAG तकनीक

 (github.com/circlemind-ai)
1 पॉइंट द्वारा GN⁺ 2024-11-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Fast GraphRAG एक सरल GraphRAG framework है, जो समझने योग्य और high-precision agent-based retrieval workflow के लिए बनाया गया है, और जटिल agent workflows को सीधे बनाए बिना advanced RAG को retrieval pipeline में जोड़ने पर फोकस करता है
  • यह knowledge graph को इंसानों के लिए explore करने योग्य रूप में बनाता है, ताकि उसे query, visualize और update किया जा सके, और domain व ontology की ज़रूरतों के अनुसार graph को अपने-आप generate और refine करता है
  • query response के लिए यह personalized PageRank आधारित graph traversal का उपयोग करके प्रासंगिक जानकारी ढूंढता है, और README इस approach के overview के रूप में HippoRAG paper को लिंक करता है
  • cost example में The Wizard of Oz के आधार पर fast-graphrag की लागत $0.08 और graphrag की $0.48 बताई गई है, और कहा गया है कि data size और insertion count बढ़ने पर 6x cost reduction और बेहतर होती है
  • यह Python 3.10.1 या उससे ऊपर पर चलता है, source install और PyPI install दोनों को support करता है, और OpenAI API key सेट करने के बाद document insertion व query चलाता है तथा उसी working directory में knowledge को अपने-आप बनाए रखता है

Fast GraphRAG द्वारा दिया गया retrieval framework

  • Fast GraphRAG एक GraphRAG framework है, जिसका लक्ष्य समझने योग्य और debug करने योग्य knowledge है
  • graph knowledge को इंसानों के लिए explore करने योग्य रूप में देता है, और यह निम्न कामों को support करता है
    • query
    • visualization
    • update
  • यह advanced RAG capabilities देता है, लेकिन agent workflow को सीधे बनाने और design करने का बोझ कम करने पर फोकस करता है

मुख्य फीचर्स

  • इसे तेज़ और कम लागत पर बड़े पैमाने पर चलाने के लिए design किया गया है, ताकि भारी resources और cost की ज़रूरत कम हो
  • यह dynamic data को support करता है और domain व ontology requirements के अनुसार graph को अपने-आप generate और refine करता है
  • data बदलने पर यह incremental updates को support करता है, जिससे real-time updates संभव होते हैं
  • PageRank आधारित graph traversal का उपयोग करके accuracy और reliability बढ़ाने वाली intelligent retrieval प्रदान करता है
  • पूरा सिस्टम asynchronous है, और complete type support के साथ robust व predictable workflow को लक्ष्य बनाता है

लागत उदाहरण

  • The Wizard of Oz का उपयोग करने वाले example में fast-graphrag की लागत $0.08 और graphrag की लागत $0.48 बताई गई है
  • README इसे 6x cost reduction के रूप में समझाता है, और कहता है कि data size व insertion count बढ़ने पर यह बचत और बेहतर होती है

installation और execution flow

  • recommended installation method दो भागों में बंटी है: performance के लिए source install और stability के लिए PyPI install
    • source install: repository clone करने के बाद poetry install
    • PyPI install: pip install fast-graphrag
  • quickstart example में पहले OPENAI_API_KEY environment variable सेट किया जाता है
  • A Christmas Carol text डाउनलोड करने के बाद Python code में GraphRAG initialize किया जाता है
  • example initialization में निम्न मान शामिल हैं
    • working_dir="./book_example"
    • कहानी के characters, interactions, places और relationships का analysis करने वाला domain
    • example query list
    • ["Character", "Animal", "Place", "Object", "Activity", "Event"] entity types
  • grag.insert(f.read()) से document insert किया जाता है, और grag.query("Who is Scrooge?").response से query result प्रिंट किया जाता है
  • उसी working directory में दोबारा initialize करने पर knowledge अपने-आप बना रहता है
  • local model उपयोग जैसी स्थितियों में LLM concurrent processing task count को नियंत्रित करने के लिए वैकल्पिक रूप से CONCURRENT_TASK_LIMIT=8 जैसा environment variable सेट किया जा सकता है

examples और configuration options

  • examples फ़ोल्डर library के सामान्य use-case tutorials प्रदान करता है
  • custom_llm.py OpenAI API-compatible language model और embedder को अलग तरीके से सेट करने का सरल example है
  • checkpointing.ipynb irreversible data corruption से बचने के लिए checkpoint के उपयोग को कवर करता है
  • query_parameters.ipynb अलग-अलग query parameters को कवर करता है, और with_references=True के साथ उत्तर में उपयोग की गई जानकारी के references शामिल करने का तरीका दिखाता है

design philosophy और retrieval method

  • लक्ष्य सफल GenAI applications की संख्या बढ़ाना है, और इसके लिए यह कहता है कि LLM apps को जटिल agent workflow setup और maintenance के बिना specialized retrieval pipeline का उपयोग करने देने वाले memory और data tools बनाए जा रहे हैं
  • Fast GraphRAG मौजूदा query का उत्तर देने के लिए सबसे प्रासंगिक जानकारी खोजने हेतु personalized PageRank algorithm से graph को traverse करता है
  • यह approach क्यों काम करती है, इसके overview के लिए HippoRAG paper को reference material के रूप में दिया गया है

open source और managed service

  • repository MIT License के तहत दी गई है, और अधिक जानकारी LICENSE.txt में है
  • तेज़ और भरोसेमंद शुरुआत के तरीके के रूप में managed service प्रदान की जाती है
  • managed service में हर महीने शुरुआती 100 requests मुफ़्त हैं, उसके बाद usage-based billing होती है
  • managed service के बारे में और जानने के लिए demo बुक किया जा सकता है या docs देखे जा सकते हैं
  • contribution guide CONTRIBUTING.md में है, और सवाल Discord पर पूछे जा सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-11-19
Hacker News की राय

  • PageRank के अलावा भी structured data में RAG को प्रभावित कर सकने वाले कुछ दिलचस्प centrality metrics हैं
    इनमें Triangle Centrality, किसी node के आसपास के triangles गिनकर centrality निकालता है; यह इस विचार पर आधारित है कि triangle किसी relation को मजबूती से close करते हैं, जबकि open connections केंद्र से weight खींचकर centrality को dilute कर देते हैं
    https://arxiv.org/abs/2105.00110
    पेपर में कहा गया है कि यह PageRank जैसे दूसरे centrality metrics से अधिक efficient है, लेकिन GraphBLAS का उपयोग वाली एक study में, 1.8 अरब edges के scale तक कई sparse graphs पर TC हमारे sparse PageRank implementation से धीमा था
    हालांकि graph जितना बड़ा होता है, TC उतना बेहतर scale होता दिखता है, और trillion-level edges के क्षेत्र में यह अधिक efficient हो सकता है
    https://fossies.org/linux/SuiteSparse/GraphBLAS/Doc/The_Grap...

    • यहाँ nodes/edges मिलियन scale में हैं, इसलिए efficiency कोई बहुत बड़ी समस्या नहीं है
      वैसे भी answer generation में LLM द्वारा parse किया जाने वाला हिस्सा bottleneck होगा
      PageRank पहला step है, लेकिन मैं अधिक accurate alternatives भी test करना चाहता हूँ
      यहाँ हम personalized PageRank का उपयोग कर रहे हैं, इसलिए किसी खास node set को initial weights दिए जाते हैं; सोच रहा हूँ कि Triangle Centrality भी इसे support करता है या नहीं
      साथ ही हम edge weights भी देख रहे हैं, इसलिए जानना चाहूँगा कि वह हिस्सा भी संभव है या नहीं
    • जानना चाहूँगा कि PageRank के विकल्प के रूप में Authority Rank आज़माया है या नहीं
      https://link.springer.com/content/pdf/10.1007/978-3-030-6097...

  • मैंने इस क्षेत्र में काफी काम किया है, और कुछ बातें सीखी हैं

    1. अगर ingestion के समय LLM से थोड़ा काम कराया जा सके, तो सिर्फ BM25-based lexical search से भी बहुत relevant results मिलते हैं
    2. embeddings तभी अच्छी तरह काम करते हैं जब query का size embedding store में डाली जाने वाली चीज़ों के लगभग उसी order का हो
    3. query से LLM को hypothetical answer generate करने दें, और फिर उस hypothetical answer से embedding search करें, तो यह बहुत अच्छा काम करता है
      इन तीनों को मिलाकर मैंने similar knowledge decomposition/extraction step बनाया, और इसमें meta prompter जोड़कर domain/entity types को लगभग auto-generate करवाया
      LLM मूल रूप से decomposed knowledge के सही granularity level को अच्छी तरह नहीं पकड़ता
      एक तरकीब यह है कि LLM से mermaid.js mindmap output करवाया जाए, ताकि input को hierarchical tree में बाँटे, और अंत में बताए कि कौन-सा level knowledge nodes के लिए उपयुक्त root है
      इसके बाद उस node में मौजूद knowledge से जिन सवालों के जवाब दिए जा सकते हैं, वे generate किए जाते हैं, और इस question text को index भी किया जाता है और embed भी
      user query को इन questions से pure BM25 के जरिए सीधे match करने पर भी अच्छे results मिलते हैं, और hybrid approach इससे बेहतर होती है, लेकिन फर्क बहुत बड़ा नहीं होता
      अगर query time पर LLM का उपयोग न किया जाए, तो embedding similarity को traversal cost function बनाकर root से गहरे nodes तक hierarchical तरीके से उतरा भी जा सकता है
    • पहले similar tree structure के साथ experiment किया था, तो अच्छे results मिले थे
      आखिर में tree के generalization के रूप में graph पर जाने का फैसला किया
      graph को “walk” करने में embedding similarity का उपयोग करना core concept मानता हूँ, और FastGraphRAG में भी query के अनुसार edge weights देने के तरीके से इसे actively integrate कर रहा हूँ
      यह देखना दिलचस्प है कि कई solutions similar design की ओर converge कर रहे हैं
    • “ingestion के समय LLM से थोड़ा काम” क्या है और उसका उद्देश्य क्या है, यह थोड़ा और समझाएँ तो अच्छा होगा
      query से hypothetical answer generation के बाद उस answer से embedding search करने का idea दिलचस्प है, और मैं इसे experiments की list में जोड़ने की कोशिश करूँगा
    • query से hypothetical answer बनाकर RAG flow में इस्तेमाल करने का तरीका सच में अच्छा काम करता है, यह सुनकर अच्छा लगा
      अब यह भी जानना चाहूँगा कि corpus के हिसाब से fine-tuned LLM से hypothetical answer generate किया जाए तो शायद यह और बेहतर काम करे या नहीं
    • BM25 index में जाने वाले text को chunks में बाँटते हैं या नहीं, यह जानना चाहूँगा
      hypothetical answer बनाते समय भी क्या “chunk size” के हिसाब से response prompt करते हैं, यह भी जानना चाहता हूँ

  • बेहतर centrality के लिए PageRank का उपयोग करना अच्छा लगता है, लेकिन यह RAG की शायद unsolvable कमी, यानी RAG मूल रूप से क्यों ठीक से काम नहीं कर पाता, उसे अब भी हल नहीं करता
    सभी RAG DB उम्मीद से कम performance इसलिए देते हैं क्योंकि RAG मूल रूप से user द्वारा चाही गई जानकारी खोजने के लिए जरूरी word relationships नहीं खोज पाता
    यह अजीब लगेगा, क्योंकि लगता है कि मूल “attention” mechanism को इसी तरह की चीज़ अच्छी तरह करनी चाहिए, लेकिन असल में यह पर्याप्त नहीं है
    उदाहरण के लिए मान लें कि किसी article में ‘Sharon’ नाम की व्यक्ति के कई physical chemistry conferences में शामिल होने की बात है, लेकिन profession स्पष्ट रूप से नहीं लिखा है
    “Sharon का पेशा क्या है?” खोजने पर लगभग सभी RAG approaches ‘profession’, conference attendance, और conference type को जोड़कर ‘chemist’ infer नहीं कर पाएँगी
    RAG से information retrieve करते समय इस तरह की error कई प्रकार की information में फैली होती है
    आखिरकार ऊपर जैसे solutions SQL, PageRank जैसे दूसरे query methods को ज्यादा steps में फिर से invent करते लगते हैं, और उस point पर vectorization का खास मतलब नहीं रह जाता

    • वह inference तो LLM की भूमिका नहीं है क्या
      RAG component को बस बड़े dataset से Sharon से जुड़े articles खोजकर पूरे context के रूप में LLM को देना चाहिए
    • उल्टा, यह example ही इस approach का core है
      original post में cited HippoRAG paper देखें तो motivation example लगभग यही है, और evaluation भी मुख्यतः इसी तरह के multi-hop question answering के लिए है
    • knowledge graph का उपयोग करें तो यह असंभव नहीं लगता
      Sharon नाम की entity लें, और extra context के रूप में Sharon के करीब के nodes और edges मिल जाएँ
      उसके बाद LLM की भूमिका है, और अगर दिए गए context में profession नहीं है, तो उसे कहना चाहिए “दिए गए context में Sharon का पेशा नहीं मिल सका”

  • दिलचस्प लगा, इसलिए मैंने साइन अप किया और dashboard पर कुछ PDF documents अपलोड करके देखे
    use case एक AI startup में manufacturing से जुड़े compliance documents का analysis करना है, और यह हमारे लिए उपयोगी होगा या नहीं समझने के लिए हमें यह जानना होगा कि यह किस scale तक काम करता है और cost model कैसा है
    हर client के पास करीब 3 लाख PDFs हैं, और उम्मीद है कि हर महीने document set का लगभग 10% बदलेगा
    किसी भी GraphRAG system को documents को बड़े scale पर process करना होगा, और S3 को ingestion mechanism के तौर पर इस्तेमाल किया जा सकता है, लेकिन हमें यह जानना होगा कि इन चरणों के बाद system usable होने तक cost और processing time कितना होगा

    1. initial loading
    2. periodic updates — उदाहरण के लिए system data को कैसे delete करता है
    • शायद मदद कर सकता हूँ
      और detail में बात करना चाहूँगा, इसलिए antonio [at] circlemind.co पर contact कर दें

  • दिलचस्प है, लेकिन सोच रहा हूँ कि उपयोगी knowledge graph पाने के लिए domain-specific text corpus कितना बड़ा होना चाहिए
    Aider काफी समय से code repositories के call graph पर PageRank लागू करता आ रहा है
    किसी भी non-trivial code में PageRank को support करने के लिए काफी graph structure होता है, इसलिए यह current task से जुड़े project के अंदर सबसे relevant context ढूँढने में बहुत अच्छी तरह काम करता है
    https://aider.chat/docs/repomap.html#optimizing-the-map

    • मैंने short novels से लेकर कई million tokens वाले पूरे documents तक try किए हैं, और दोनों interesting graphs बनाते लगते हैं
      जब और लोग इसे इस्तेमाल करना शुरू करेंगे, तो feedback सुनना चाहूँगा
    • Aider मैं अच्छे से इस्तेमाल करता हूँ, लेकिन codebase चाहे Python हो, JS हो या TS, मैं कभी successfully repo map नहीं बना पाया
      जानना चाहूँगा कि क्या repo map को force-generate करके inspect करने की सुविधा देने का कोई plan है

  • बढ़िया
    जानना चाहूँगा कि graph कैसे store और query किया जाता है
    graph databases से familiar हूँ, लेकिन यह dependency के रूप में नहीं दिख रहा
    यह भी जानना चाहूँगा कि extraction के लिए sciphi triplex model try किया है या नहीं
    पहले जब extraction किया था, तो same chunk को लगातार कई बार extract करने पर results consistent नहीं थे

    • graph अभी python-igraph से store किया जाता है
      codebase इस तरह design किया गया है कि हल्का wrapper लिखकर किसी भी graph DB को आसानी से integrate किया जा सके, और निकट भविष्य में neo4j जैसी चीज़ों को support करने का plan है
      triplex अभी try नहीं किया, क्योंकि gpt4o-mini अभी काफी fast और accurate रहा है
      entity और relationship extraction के अलावा description generation और conflict resolution के लिए भी gpt4o-mini इस्तेमाल कर रहे हैं
      fine-tuning करने पर results निश्चित तौर पर बेहतर होंगे
      graph query का तरीका यह है कि दिए गए query से relevant initial nodes का set ढूँढा जाता है, फिर उन nodes से personalized PageRank run करके दूसरे related passages खोजे जाते हैं
      अभी initial nodes चुनने के लिए पूरे query और query से extract की गई entities दोनों पर semantic search करते हैं, लेकिन इस approach में कुछ interesting additions भी planned हैं

  • अच्छा idea है
    personally मुझे लगता है कि RAG में traditional information retrieval ही आगे का रास्ता है
    vector search अच्छी है, लेकिन slow और expensive है, और लोग इसे magic dust की तरह इस्तेमाल करने लगते हैं
    unstructured data के लिए यह अच्छा काम करती है, लेकिन structured data के लिए जरूरी नहीं कि उतनी अच्छी fit हो
    जब तक बहुत अच्छी tuning न की जाए, vector search किसी well-tuned traditional query से बहुत ज्यादा बेहतर भी नहीं होती
    मैंने ऐसे workflows देखे हैं जहाँ structured data को unstructured data में बदलकर फिर vector search या prompt engineering करने की कोशिश की जाती है, और overall यह थोड़ा उल्टा लगता है
    यह कुछ हद तक काम करता है, लेकिन वही result पाने का कोई ज्यादा smart तरीका होने की संभावना ज्यादा है
    Graph RAG का सार data structure का उपयोग करना है
    वह SQL join हो या graph DB query, इससे बहुत फर्क नहीं पड़ता
    LLM को query करना सिखाने या existing search/query APIs से interface कराने में भी value होगी
    खराब ranking को बड़े context size से compensate किया जा सकता है, और multiple queries से सैकड़ों या उससे ज्यादा results लाए जा सकते हैं
    इस तरह scale करना vector search की तुलना में कहीं ज्यादा fast और सस्ता होगा

  • अच्छा दिखता है, लेकिन LangChain जैसे दूसरे abstraction layers से हाथ जल चुका है, इसलिए over-simplification को लेकर चिंता है
    जानना चाहूँगा कि वही गलतियाँ दोहराने से बचने के लिए आपका plan क्या है

  • जानना चाहूँगा कि search और generation के लिए evaluation metric scores हैं या नहीं
    जैसे KILT या NQ datasets
    benchmark datasets सब कुछ नहीं हैं, लेकिन अगर कुछ ठीक-ठाक scores और inference time दिखा दिए जाएँ, तो framework को convince करने या engineers द्वारा इसे चुनने में काफी मदद मिलेगी
    freelance natural language processing engineer के तौर पर मैंने बहुत सारी RAG pipelines बनाई हैं, और इस काम को खुद try करने वाला हूँ

  • मैं अभी Q&A chatbot बना रहा हूँ और इस scenario को handle करने में struggle कर रहा हूँ
    जब user पूछता है, “अभी कही गई पिछली sentence में तुम्हारा क्या मतलब था?”, तो जानना चाहूँगा कि यह framework सही छोटे subset की raw knowledge कैसे retrieve कर सकता है और उसे LLM में integrate करके relevant response कैसे बना सकता है
    external framework पर depend किए बिना इस problem को solve करना मुश्किल रहा
    https://www.reddit.com/r/LocalLLaMA/comments/1gtzdid/d_optim...
    जानना चाहता हूँ कि यह framework इस problem को कैसे solve कर सकता है और process को simple बना सकता है

    • कई experiments के बाद chat-style applications में जो एकमात्र चीज़ अच्छी चली, वह यह थी कि हाल के 4–5 messages pass किए जाएँ, और संभव हो तो पूरी conversation history pass की जाए, फिर LLM से conversation context के अंदर question को summarize कराया जाए
      इसके बिना user जब “item 2 को और detail में explain करो” या “ऊपर वाली बात का detailed example दो” जैसे questions पूछता था, तो अक्सर fail हो जाता था
      current implementation में 3 indexes हैं, query और past messages provide किए जाते हैं, फिर LLM से इसे इन parts में decompose कराया जाता है
      full request, BM25-optimized question, keywords, semantic-search-optimized question
      इसके बाद RAG और reranking की जाती है, और top N passages को full request के साथ दूसरी LLM call में pass किया जाता है
    • जब user ऐसा question पूछे, तो agent को RAG call नहीं करना चाहिए और सिर्फ conversation history से answer देना चाहिए
      orchestration stage पर focus करना चाहिए
      ReAct agents देखें, और इसे LangGraph या Bedrock Agents से बनाया जा सकता है
    • क्या आपने tool use या direct query के जरिए LLM को यह decide करने दिया है कि knowledge retrieval का इस्तेमाल करना है या नहीं