6M विकिपिडिया पृष्ठहरूमा RAG को लागि ज्ञान ग्राफ निर्माण गरेर $ 70K कसरी बचत गर्ने

पुन: प्राप्ति-संवर्धित जेनरेशन (RAG) अनुप्रयोगहरूको नतिजा सुधार गर्न ज्ञान ग्राफहरू प्रयोग गर्ने एक तातो विषय भएको छ। धेरै उदाहरणहरूले कागजातहरूको तुलनात्मक रूपमा सानो संख्या प्रयोग गरेर ज्ञान ग्राफ कसरी बनाउने भनेर देखाउँछन्। यो हुन सक्छ किनभने सामान्य दृष्टिकोण - राम्रो-दाना, संस्था-केन्द्रित जानकारी निकाल्ने - मापन गर्दैन। संस्थाहरू (नोडहरू) र सम्बन्धहरू (एजहरू) निकाल्नको लागि मोडेल मार्फत प्रत्येक कागजात चलाउँदा ठूला डाटासेटहरूमा चलाउन धेरै लामो (र धेरै लागत) लाग्छ।

भन्ने तर्क गरेका छौं - एक भेक्टर-स्टोर टुक्राहरू बीच लिङ्कहरू अनुमति दिने - प्रयोग गर्न सजिलो र अधिक कुशल दृष्टिकोण हो। यहाँ, हामीले यसलाई परीक्षणमा राख्यौं। हामी विकिपिडिया लेखहरूको उपसमूह लोड गर्छौं दुबै प्रविधिहरू प्रयोग गरेर डेटासेट र सम्पूर्ण डेटासेट लोड गर्नको लागि यसको अर्थ के बारे छलफल गर्नुहोस्। हामीले लोड गरिएको डाटामा केही प्रश्नहरूको नतिजा देखाउँछौं। हामी सम्पूर्ण डेटासेट - लगभग 6 मिलियन कागजातहरू - सामग्री-केन्द्रितमा लोड गर्नेछौं ।

इकाई केन्द्रित: LLMGraphTransformer

LengChain को LLMGraphTransformer को प्रयोग गरेर Neo4j जस्ता निकाय-केन्द्रित ग्राफ स्टोरमा कागजातहरू लोड गरिन्थ्यो। कोड LangChain मा आधारित छ

 from langchain_core.documents import Document from langchain_experimental.graph_transformers import LLMGraphTransformer from langchain_openai import ChatOpenAI llm = ChatOpenAI(temperature=0, model_name="gpt-4-turbo") llm_transformer = LLMGraphTransformer(llm=llm) from time import perf_counter start = perf_counter() documents_to_load = [Document(page_content=line) for line in lines_to_load] graph_documents = llm_transformer.convert_to_graph_documents(documents_to_load) end = perf_counter() print(f"Loaded (but NOT written) {NUM_LINES_TO_LOAD} in {end - start:0.2f}s")

सामग्री केन्द्रित: GraphVectorStore

GraphVectorStore मा डाटा लोड गर्नु भनेको भेक्टर स्टोरमा लोड गर्नु जस्तै हो। केवल थप यो हो कि हामी मेटाडेटा गणना गर्छौं कि प्रत्येक पृष्ठ कसरी अन्य पृष्ठहरूमा लिङ्क हुन्छ।

 import json from langchain_core.graph_vectorstores.links import METADATA_LINKS_KEY, Link def parse_document(line: str) -> Document:    para = json.loads(line)    id = para["id"]    links = {        Link.outgoing(kind="href", tag=id)        for m in para["mentions"]        if m["ref_ids"] is not None        for id in m["ref_ids"]    }    links.add(Link.incoming(kind="href", tag=id))    return Document(        id = id,        page_content = " ".join(para["sentences"]),        metadata = {            "content_id": para["id"],            METADATA_LINKS_KEY: list(links)        },    )

यो पनि एक राम्रो उदाहरण हो कि तपाइँ कसरी नोडहरू बीच आफ्नो लिङ्कहरू थप्न सक्नुहुन्छ।

 from langchain_openai import OpenAIEmbeddings from langchain_community.graph_vectorstores.cassandra import CassandraGraphVectorStore import cassio cassio.init(auto=True) TABLE_NAME = "wiki_load" store = CassandraGraphVectorStore( embedding = OpenAIEmbeddings(), node_table=TABLE_NAME, insert_timeout = 1000.0, ) from time import perf_counter start = perf_counter() from datasets.wikimultihop.load import parse_document kg_documents = [parse_document(line) for line in lines_to_load] store.add_documents(kg_documents) end = perf_counter() print(f"Loaded (and written) {NUM_LINES_TO_LOAD} in {end - start:0.2f}s")

बेन्चमार्कहरू लोड गर्दै

100 पङ्क्तिहरूमा चलिरहेको, GPT-4o प्रयोग गर्ने निकाय-केन्द्रित दृष्टिकोणले ग्राफ कागजातहरू निकाल्न 405.93s र तिनीहरूलाई Neo4j मा लेख्न 10.99s लियो, जबकि सामग्री-केन्द्रित दृष्टिकोणले 1.43 सेकेन्ड लिए। एक्स्ट्रापोलेटिंग, सबै 5,989,847 पृष्ठहरू इकाई-केन्द्रित दृष्टिकोण प्रयोग गरेर र सामग्री-केन्द्रित दृष्टिकोण प्रयोग गरेर लगभग 24 घण्टा लोड गर्न 41 हप्ता लाग्नेछ। तर समानान्तरताको लागि धन्यवाद, सामग्री-केन्द्रित दृष्टिकोण मात्र 2.5 घण्टामा चल्छ! एउटै समानान्तरता लाभहरू मान्दै, यसले संस्था-केन्द्रित दृष्टिकोण प्रयोग गरेर सबै चीजहरू लोड गर्न अझै चार हप्ता लाग्नेछ। अनुमानित लागत $ 58,700 हुने भएकोले मैले यसलाई प्रयास गरेन - सबै कुरा पहिलो पटक काम गरेको मान्दै!

तल्लो रेखा: LLM प्रयोग गरेर सामग्रीबाट ज्ञान ग्राफहरू निकाल्ने संस्था-केन्द्रित दृष्टिकोण समय र लागत दुवै मापनमा निषेधात्मक थियो। अर्कोतर्फ, GraphVectorStore प्रयोग गर्नु छिटो र सस्तो थियो।

उदाहरणका जवाफहरू

यस खण्डमा, लोड गरिएका कागजातहरूको उपसमूहबाट निकालिएका केही प्रश्नहरूलाई जवाफको गुणस्तरलाई सम्बोधन गर्न सोधिएको छ।

Entity-centric ले 7324 प्रम्प्ट टोकनहरू प्रयोग गर्‍यो र मूलतया बेकार जवाफहरू उत्पादन गर्न $0.03 खर्च गर्‍यो, जबकि सामग्री-केन्द्रले 450 प्रम्प्ट टोकनहरू प्रयोग गर्‍यो र प्रश्नहरूको सीधा जवाफ दिने संक्षिप्त जवाफहरू उत्पादन गर्न $0.002 लागत थियो।

यो अचम्मलाग्दो हुन सक्छ कि फाइन-ग्रेन्ड Neo4j ग्राफले बेकार जवाफहरू फर्काउँछ। चेनबाट लगिङमा हेर्दै, हामी यो किन हुन्छ भनेर देख्छौं:

 > Entering new GraphCypherQAChain chain... Generated Cypher: cypher MATCH (a:Album {id: 'The Circle'})-[:RELEASED_BY]->(r:Record_label) RETURN a.id, r.id Full Context: [{'a.id': 'The Circle', 'r.id': 'Restless'}] > Finished chain. {'query': "When was 'The Circle' released?", 'result': "I don't know the answer."}

त्यसोभए, फाइन-ग्रेन्ड स्किमाले रेकर्ड लेबलको बारेमा जानकारी मात्र फर्काउँछ। LLM ले पुन: प्राप्त जानकारीको आधारमा प्रश्नको जवाफ दिन सकेन भन्ने बुझिन्छ।

निष्कर्ष

फाइन-ग्रेन्ड, एकाइ-विशिष्ट ज्ञान ग्राफहरू निकाल्ने समय- र लागत-प्रतिषेध मापन हो। जब लोड गरिएको डाटाको उपसमूहको बारेमा प्रश्नहरू सोधियो, अतिरिक्त ग्रेन्युलारिटी (र फाइन-ग्रेन्ड ग्राफ लोड गर्ने अतिरिक्त लागत)ले प्रम्प्ट समावेश गर्न थप टोकनहरू फिर्ता गर्यो तर बेकार जवाफहरू उत्पन्न गर्यो!

GraphVectorStore ले ज्ञानको ग्राफ निर्माण गर्न छिटो र सजिलो बनाउँदछ। तपाईंले LangChain प्रयोग गरेर भेक्टरस्टोरलाई भर्नको लागि आफ्नो अवस्थित कोडको साथ सुरु गर्न सक्नुहुन्छ र पुन: प्राप्ति प्रक्रियामा सुधार गर्नका लागि टुक्राहरू बीच लिङ्कहरू (किनाहरू) थप्न सक्नुहुन्छ।

ग्राफ RAG अधिक गहिरो सान्दर्भिक सन्दर्भहरू पुन: प्राप्त गर्न जेनेरेटिभ AI RAG अनुप्रयोगहरू सक्षम गर्नको लागि उपयोगी उपकरण हो। तर राम्रो-दाना, संस्था-केन्द्रित दृष्टिकोण प्रयोग गरेर उत्पादन आवश्यकताहरू मापन गर्दैन। यदि तपाइँ आफ्नो RAG अनुप्रयोगमा ज्ञान ग्राफ क्षमताहरू थप्न खोज्दै हुनुहुन्छ भने, प्रयास गर्नुहोस् ।

, डाटास्ट्याक्स द्वारा