trustgraph/docs/tech-specs/extraction-time-provenance.hi.md

# निष्कर्षण-समय का प्रमाण: स्रोत परत

## अवलोकन

यह दस्तावेज़ भविष्य के विनिर्देशन कार्य के लिए निष्कर्षण-समय के प्रमाण पर नोट्स एकत्र करता है। निष्कर्षण-समय का प्रमाण "स्रोत परत" को रिकॉर्ड करता है - डेटा मूल रूप से कहाँ से आया, इसे कैसे निकाला और रूपांतरित किया गया।

यह क्वेरी-समय के प्रमाण (देखें `query-time-provenance.md`) से अलग है, जो एजेंट तर्क को रिकॉर्ड करता है।

## समस्या विवरण

### वर्तमान कार्यान्वयन

वर्तमान में, प्रमाण इस प्रकार काम करता है:
दस्तावेज़ मेटाडेटा को ज्ञान ग्राफ में RDF ट्रिपल के रूप में संग्रहीत किया जाता है
एक दस्तावेज़ आईडी मेटाडेटा को दस्तावेज़ से जोड़ती है, इसलिए दस्तावेज़ ग्राफ में एक नोड के रूप में दिखाई देता है
जब दस्तावेज़ों से किनारे (संबंध/तथ्य) निकाले जाते हैं, तो एक `subjectOf` संबंध निकाले गए किनारे को स्रोत दस्तावेज़ से जोड़ता है

### वर्तमान दृष्टिकोण की समस्याएं

<<<<<<< HEAD
1. **दोहरा मेटाडेटा लोडिंग:** दस्तावेज़ मेटाडेटा को प्रत्येक दस्तावेज़ से निकाले गए ट्रिपल बैच के साथ बार-बार बंडल किया जाता है और लोड किया जाता है। यह अनावश्यक और दोहराव वाला है - समान मेटाडेटा प्रत्येक निष्कर्षण आउटपुट के साथ पेलोड के रूप में यात्रा करता है।

2. **उथला प्रमाण:** वर्तमान `subjectOf` संबंध केवल तथ्यों को सीधे शीर्ष-स्तरीय दस्तावेज़ से जोड़ता है। परिवर्तन श्रृंखला में कोई दृश्यता नहीं है - तथ्य किस पृष्ठ से आया, किस भाग से, किस निष्कर्षण विधि का उपयोग किया गया था।
=======
1. **दोहरा मेटाडेटा लोडिंग:** दस्तावेज़ मेटाडेटा को प्रत्येक दस्तावेज़ से निकाले गए ट्रिपल के प्रत्येक बैच के साथ बार-बार बंडल किया जाता है और लोड किया जाता है। यह अनावश्यक और दोहराव वाला है - समान मेटाडेटा प्रत्येक निष्कर्षण आउटपुट के साथ पेलोड के रूप में यात्रा करता है।

2. **उथला प्रमाण:** वर्तमान `subjectOf` संबंध केवल तथ्यों को सीधे शीर्ष-स्तरीय दस्तावेज़ से जोड़ता है। परिवर्तन श्रृंखला में कोई दृश्यता नहीं है - तथ्य किस पृष्ठ से आया, किस खंड से, किस निष्कर्षण विधि का उपयोग किया गया था।
>>>>>>> 82edf2d (New md files from RunPod)

### वांछित स्थिति

1. **मेटाडेटा को एक बार लोड करें:** दस्तावेज़ मेटाडेटा को एक बार लोड किया जाना चाहिए और शीर्ष-स्तरीय दस्तावेज़ नोड से जोड़ा जाना चाहिए, न कि प्रत्येक ट्रिपल बैच के साथ दोहराया जाना चाहिए।

<<<<<<< HEAD
2. **समृद्ध प्रमाण DAG:** स्रोत दस्तावेज़ से सभी मध्यवर्ती कलाकृतियों से लेकर निकाले गए तथ्यों तक, संपूर्ण परिवर्तन श्रृंखला को कैप्चर करें। उदाहरण के लिए, एक PDF दस्तावेज़ रूपांतरण:
=======
2. **समृद्ध प्रमाण DAG:** स्रोत दस्तावेज़ से सभी मध्यवर्ती कलाकृतियों से लेकर निकाले गए तथ्यों तक, पूर्ण परिवर्तन श्रृंखला को कैप्चर करें। उदाहरण के लिए, एक PDF दस्तावेज़ रूपांतरण:
>>>>>>> 82edf2d (New md files from RunPod)

   ```
   PDF file (source document with metadata)
     → Page 1 (decoded text)
       → Chunk 1
         → Extracted edge/fact (via subjectOf)
         → Extracted edge/fact
       → Chunk 2
         → Extracted edge/fact
     → Page 2
       → Chunk 3
         → ...
   ```

<<<<<<< HEAD
3. **एकीकृत भंडारण:** उत्पत्ति (provenance) DAG को उसी ज्ञान ग्राफ में संग्रहीत किया जाता है जैसे कि निकाले गए ज्ञान को। यह उत्पत्ति को ज्ञान की तरह ही क्वेरी करने की अनुमति देता है - किसी भी तथ्य से लेकर उसके सटीक स्रोत स्थान तक, श्रृंखला में किनारों का पालन करके।

4. **स्थिर आईडी:** प्रत्येक मध्यवर्ती कलाकृति (पेज, चंक) का ग्राफ में एक नोड के रूप में एक स्थिर आईडी होता है।

5. **पैरेंट-चाइल्ड लिंकिंग:** व्युत्पन्न दस्तावेज़ों को सुसंगत संबंध प्रकारों का उपयोग करके शीर्ष-स्तरीय स्रोत दस्तावेज़ तक उनके माता-पिता से जोड़ा जाता है।
=======
3. **एकीकृत भंडारण:** उत्पत्ति (provenance) DAG को उसी ज्ञान ग्राफ में संग्रहीत किया जाता है जैसे कि निकाले गए ज्ञान को। यह उत्पत्ति को ज्ञान की तरह ही क्वेरी करने की अनुमति देता है - किसी भी तथ्य से लेकर उसके सटीक स्रोत स्थान तक, श्रृंखला में वापस किनारों का पालन करना।

4. **स्थिर आईडी:** प्रत्येक मध्यवर्ती कलाकृति (पेज, चंक) का ग्राफ में एक नोड के रूप में एक स्थिर आईडी होता है।

5. **माता-पिता-बच्चे संबंध:** व्युत्पन्न दस्तावेज़ों को सुसंगत संबंध प्रकारों का उपयोग करके शीर्ष-स्तरीय स्रोत दस्तावेज़ तक उनके माता-पिता से जोड़ा जाता है।
>>>>>>> 82edf2d (New md files from RunPod)

6. **सटीक तथ्यattribution:** निकाले गए किनारों पर `subjectOf` संबंध तत्काल माता-पिता (चंक) की ओर इशारा करता है, न कि शीर्ष-स्तरीय दस्तावेज़ की ओर। पूर्ण उत्पत्ति को DAG के माध्यम से ऊपर की ओर ट्रैवर्स करके पुनर्प्राप्त किया जाता है।

## उपयोग के मामले

### UC1: GraphRAG प्रतिक्रियाओं में स्रोत attribution

<<<<<<< HEAD
**परिदृश्य:** एक उपयोगकर्ता GraphRAG क्वेरी चलाता है और एजेंट से एक प्रतिक्रिया प्राप्त करता है।

**प्रवाह:**
1. उपयोगकर्ता GraphRAG एजेंट को एक क्वेरी सबमिट करता है
2. एजेंट प्रतिक्रिया तैयार करने के लिए ज्ञान ग्राफ से प्रासंगिक तथ्यों को पुनर्प्राप्त करता है
3. क्वेरी-टाइम provenance विनिर्देश के अनुसार, एजेंट उन तथ्यों की रिपोर्ट करता है जिन्होंने प्रतिक्रिया में योगदान दिया
4. प्रत्येक तथ्य provenance DAG के माध्यम से अपने स्रोत चंक से जुड़ा होता है
5. चंक पृष्ठों से जुड़ते हैं, पृष्ठ स्रोत दस्तावेज़ों से जुड़ते हैं

**उपयोगकर्ता अनुभव परिणाम:** इंटरफ़ेस LLM प्रतिक्रिया के साथ स्रोत attribution प्रदर्शित करता है। उपयोगकर्ता:
प्रतिक्रिया का समर्थन करने वाले तथ्यों को देख सकते हैं
तथ्यों → चंक → पृष्ठ → दस्तावेज़ से ड्रिल डाउन कर सकते हैं
दावों को सत्यापित करने के लिए मूल स्रोत दस्तावेज़ों की समीक्षा कर सकते हैं
यह समझ सकते हैं कि एक तथ्य दस्तावेज़ में कहाँ से (किस पृष्ठ, किस अनुभाग से) उत्पन्न हुआ था
=======
**परिदृश्य:** एक उपयोगकर्ता GraphRAG क्वेरी चलाता है और एजेंट से प्रतिक्रिया प्राप्त करता है।

**प्रक्रिया:**
1. उपयोगकर्ता GraphRAG एजेंट को एक क्वेरी सबमिट करता है।
2. एजेंट प्रतिक्रिया तैयार करने के लिए ज्ञान ग्राफ से प्रासंगिक तथ्यों को पुनः प्राप्त करता है।
3. क्वेरी-समय provenance विनिर्देश के अनुसार, एजेंट उन तथ्यों की रिपोर्ट करता है जिन्होंने प्रतिक्रिया में योगदान दिया।
4. प्रत्येक तथ्य अपने स्रोत चंक से provenance DAG के माध्यम से जुड़ा होता है।
5. चंक पृष्ठों से जुड़े होते हैं, पृष्ठ स्रोत दस्तावेज़ों से जुड़े होते हैं।

**उपयोगकर्ता अनुभव परिणाम:** इंटरफ़ेस LLM प्रतिक्रिया के साथ स्रोत attribution प्रदर्शित करता है। उपयोगकर्ता निम्न कार्य कर सकते हैं:
प्रतिक्रिया का समर्थन करने वाले तथ्यों को देखें।
तथ्यों → चंक → पृष्ठ → दस्तावेज़ से नीचे ड्रिल करें।
दावों को सत्यापित करने के लिए मूल स्रोत दस्तावेज़ों की समीक्षा करें।
समझें कि एक तथ्य दस्तावेज़ में (किस पृष्ठ पर, किस अनुभाग में) से उत्पन्न हुआ था।
>>>>>>> 82edf2d (New md files from RunPod)

**मूल्य:** उपयोगकर्ता AI-जनित प्रतिक्रियाओं को प्राथमिक स्रोतों के विरुद्ध सत्यापित कर सकते हैं, जिससे विश्वास बढ़ता है और तथ्य-जांच सक्षम होती है।

### UC2: निष्कर्षण गुणवत्ता का डिबगिंग

एक तथ्य गलत दिखता है। मूल पाठ देखने के लिए चंक → पृष्ठ → दस्तावेज़ के माध्यम से वापस ट्रेस करें। क्या यह एक खराब निष्कर्षण था, या क्या स्रोत स्वयं गलत था?

### UC3: वृद्धिशील पुन: निष्कर्षण

<<<<<<< HEAD
स्रोत दस्तावेज़ अपडेट किया गया है। किन चंक/तथ्यों को इससे व्युत्पन्न किया गया था? केवल उन चंक/तथ्यों को अमान्य करें और पुन: उत्पन्न करें, न कि सब कुछ को पुन: संसाधित करें।
=======
स्रोत दस्तावेज़ अपडेट किया गया है। किन चंक/तथ्यों को इससे व्युत्पन्न किया गया था? केवल उन चंक को अमान्य करें और पुन: उत्पन्न करें, न कि सब कुछ को फिर से संसाधित करें।
>>>>>>> 82edf2d (New md files from RunPod)

### UC4: डेटा हटाना / भुलाए जाने का अधिकार

एक स्रोत दस्तावेज़ को हटाया जाना चाहिए (GDPR, कानूनी, आदि)। सभी व्युत्पन्न तथ्यों को खोजने और हटाने के लिए DAG को पार करें।

### UC5: संघर्ष समाधान

दो तथ्य एक-दूसरे का खंडन करते हैं। कारण को समझने और यह तय करने के लिए कि किस पर भरोसा करना है (अधिक आधिकारिक स्रोत, अधिक हालिया, आदि), दोनों को उनके स्रोतों तक वापस ट्रेस करें।

### UC6: स्रोत प्राधिकरण भार

कुछ स्रोत दूसरों की तुलना में अधिक आधिकारिक होते हैं। तथ्यों को उनके मूल दस्तावेज़ों के प्राधिकरण/गुणवत्ता के आधार पर भारित या फ़िल्टर किया जा सकता है।

### UC7: निष्कर्षण पाइपलाइन तुलना

<<<<<<< HEAD
विभिन्न निष्कर्षण विधियों/संस्करणों से आउटपुट की तुलना करें। किस निष्कर्षण ने समान स्रोत से बेहतर तथ्य उत्पन्न किए?
=======
विभिन्न निष्कर्षण विधियों/संस्करणों से प्राप्त परिणामों की तुलना करें। किस निष्कर्षण ने समान स्रोत से बेहतर तथ्य उत्पन्न किए?
>>>>>>> 82edf2d (New md files from RunPod)

## एकीकरण बिंदु

### लाइब्रेरियन

लाइब्रेरियन घटक पहले से ही अद्वितीय दस्तावेज़ आईडी के साथ दस्तावेज़ भंडारण प्रदान करता है। प्रोवेनेंस सिस्टम इस मौजूदा बुनियादी ढांचे के साथ एकीकृत होता है।

#### मौजूदा क्षमताएं (पहले से लागू)

**पैरेंट-चाइल्ड दस्तावेज़ लिंकिंग:**
`parent_id` फ़ील्ड `DocumentMetadata` में - चाइल्ड को पैरेंट दस्तावेज़ से जोड़ता है
`document_type` फ़ील्ड - मान: `"source"` (मूल) या `"extracted"` (व्युत्पन्न)
`add-child-document` एपीआई - स्वचालित `document_type = "extracted"` के साथ चाइल्ड दस्तावेज़ बनाता है
`list-children` एपीआई - एक पैरेंट दस्तावेज़ के सभी चाइल्ड को पुनः प्राप्त करता है
<<<<<<< HEAD
कैस्केड डिलीशन - एक पैरेंट को हटाने से स्वचालित रूप से सभी चाइल्ड दस्तावेज़ हटा दिए जाते हैं
=======
कैस्केड डिलीशन - एक पैरेंट को हटाने से स्वचालित रूप से सभी चाइल्ड दस्तावेज़ हट जाते हैं
>>>>>>> 82edf2d (New md files from RunPod)

**दस्तावेज़ पहचान:**
दस्तावेज़ आईडी क्लाइंट द्वारा निर्दिष्ट हैं (स्वचालित रूप से उत्पन्न नहीं)
दस्तावेज़ों को कैसेंड्रा में समग्र `(user, document_id)` द्वारा कुंजीबद्ध किया जाता है
ऑब्जेक्ट आईडी (UUID) आंतरिक रूप से ब्लब स्टोरेज के लिए उत्पन्न होते हैं

**मेटाडेटा समर्थन:**
`metadata: list[Triple]` फ़ील्ड - संरचित मेटाडेटा के लिए आरडीएफ ट्रिपल
`title`, `comments`, `tags` - बुनियादी दस्तावेज़ मेटाडेटा
`time` - टाइमस्टैम्प, `kind` - एमआईएमई प्रकार

**भंडारण आर्किटेक्चर:**
मेटाडेटा कैसेंड्रा में संग्रहीत है (`librarian` कीस्पेस, `document` टेबल)
सामग्री MinIO/S3 ब्लब स्टोरेज में संग्रहीत है (`library` बकेट)
<<<<<<< HEAD
स्मार्ट सामग्री वितरण: 2MB से कम दस्तावेज़ एम्बेडेड हैं, बड़े दस्तावेज़ स्ट्रीम किए जाते हैं
=======
स्मार्ट सामग्री वितरण: 2MB से छोटे दस्तावेज़ एम्बेडेड होते हैं, बड़े दस्तावेज़ स्ट्रीम किए जाते हैं
>>>>>>> 82edf2d (New md files from RunPod)

#### मुख्य फाइलें

`trustgraph-flow/trustgraph/librarian/librarian.py` - मुख्य लाइब्रेरियन ऑपरेशन
`trustgraph-flow/trustgraph/librarian/service.py` - सर्विस प्रोसेसर, दस्तावेज़ लोडिंग
`trustgraph-flow/trustgraph/tables/library.py` - कैसेंड्रा टेबल स्टोर
`trustgraph-base/trustgraph/schema/services/library.py` - स्कीमा परिभाषाएं

#### संबोधित करने योग्य कमियां

लाइब्रेरियन में बिल्डिंग ब्लॉक्स हैं लेकिन वर्तमान में:
1. पैरेंट-चाइल्ड लिंकिंग एक स्तर गहरा है - मल्टी-लेवल डीएजी ट्रैवर्सल हेल्पर नहीं हैं
2. कोई मानक संबंध प्रकार शब्दावली नहीं (जैसे, `derivedFrom`, `extractedFrom`)
3. प्रोवेनेंस मेटाडेटा (निष्कर्षण विधि, आत्मविश्वास, चंक स्थिति) मानकीकृत नहीं है
4. तथ्य से स्रोत तक संपूर्ण प्रोवेनेंस श्रृंखला को पार करने के लिए कोई क्वेरी एपीआई नहीं है

## एंड-टू-एंड फ्लो डिज़ाइन

पाइपलाइन में प्रत्येक प्रोसेसर एक सुसंगत पैटर्न का पालन करता है:
अपस्ट्रीम से दस्तावेज़ आईडी प्राप्त करें
लाइब्रेरियन से सामग्री प्राप्त करें
चाइल्ड आर्टिफैक्ट उत्पन्न करें
प्रत्येक चाइल्ड के लिए: लाइब्रेरियन में सहेजें, ग्राफ में एज उत्सर्जित करें, आईडी को डाउनस्ट्रीम पर अग्रेषित करें

### प्रोसेसिंग फ्लो

दस्तावेज़ के प्रकार के आधार पर दो फ्लो हैं:

#### पीडीएफ दस्तावेज़ फ्लो

```
┌─────────────────────────────────────────────────────────────────────────┐
│ Librarian (initiate processing)                                         │
│   1. Emit root document metadata to knowledge graph (once)              │
│   2. Send root document ID to PDF extractor                             │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ PDF Extractor (per page)                                                │
│   1. Fetch PDF content from librarian using document ID                 │
│   2. Extract pages as text                                              │
│   3. For each page:                                                     │
│      a. Save page as child document in librarian (parent = root doc)   │
│      b. Emit parent-child edge to knowledge graph                       │
│      c. Send page document ID to chunker                                │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Chunker (per chunk)                                                     │
│   1. Fetch page content from librarian using document ID                │
│   2. Split text into chunks                                             │
│   3. For each chunk:                                                    │
│      a. Save chunk as child document in librarian (parent = page)      │
│      b. Emit parent-child edge to knowledge graph                       │
│      c. Send chunk document ID + chunk content to next processor        │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
          ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
          Post-chunker optimization: messages carry both
          chunk ID (for provenance) and content (to avoid
          librarian round-trip). Chunks are small (2-4KB).
          ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Knowledge Extractor (per chunk)                                         │
│   1. Receive chunk ID + content directly (no librarian fetch needed)   │
│   2. Extract facts/triples and embeddings from chunk content            │
│   3. For each triple:                                                   │
│      a. Emit triple to knowledge graph                                  │
│      b. Emit reified edge linking triple → chunk ID (edge pointing     │
│         to edge - first use of reification support)                     │
│   4. For each embedding:                                                │
│      a. Emit embedding with its entity ID                               │
│      b. Link entity ID → chunk ID in knowledge graph                   │
└─────────────────────────────────────────────────────────────────────────┘
```

#### पाठ दस्तावेज़ प्रवाह

पाठ दस्तावेज़ पीडीएफ एक्सट्रैक्टर को छोड़ देते हैं और सीधे चंकर पर जाते हैं:

```
┌─────────────────────────────────────────────────────────────────────────┐
│ Librarian (initiate processing)                                         │
│   1. Emit root document metadata to knowledge graph (once)              │
│   2. Send root document ID directly to chunker (skip PDF extractor)    │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Chunker (per chunk)                                                     │
│   1. Fetch text content from librarian using document ID                │
│   2. Split text into chunks                                             │
│   3. For each chunk:                                                    │
│      a. Save chunk as child document in librarian (parent = root doc) │
│      b. Emit parent-child edge to knowledge graph                       │
│      c. Send chunk document ID + chunk content to next processor        │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Knowledge Extractor                                                     │
│   (same as PDF flow)                                                    │
└─────────────────────────────────────────────────────────────────────────┘
```

<<<<<<< HEAD
परिणामी निर्देशित एसाइक्लिक ग्राफ (DAG) एक स्तर छोटा होता है:
=======
परिणामी DAG एक स्तर छोटा होता है:
>>>>>>> 82edf2d (New md files from RunPod)

```
PDF:  Document → Pages → Chunks → Triples/Embeddings
Text: Document → Chunks → Triples/Embeddings
```

डिज़ाइन दोनों को समायोजित करता है क्योंकि चंकर अपने इनपुट को सामान्य रूप से संसाधित करता है - यह जो भी दस्तावेज़ आईडी प्राप्त करता है, उसे पैरेंट के रूप में उपयोग करता है, चाहे वह स्रोत दस्तावेज़ हो या पृष्ठ।

### मेटाडेटा स्कीमा (PROV-O)

प्रामाणिकता मेटाडेटा W3C PROV-O ऑन्टोलॉजी का उपयोग करता है। यह एक मानक शब्दावली प्रदान करता है और निष्कर्षण आउटपुट के भविष्य के हस्ताक्षर/प्रमाणीकरण को सक्षम बनाता है।

#### PROV-O मुख्य अवधारणाएँ

| PROV-O प्रकार | ट्रस्टग्राफ उपयोग |
|-------------|------------------|
| `prov:Entity` | दस्तावेज़, पृष्ठ, चंक, ट्रिपल, एम्बेडिंग |
| `prov:Activity` | निष्कर्षण कार्यों के उदाहरण |
| `prov:Agent` | टीजी घटक (पीडीएफ एक्सट्रैक्टर, चंकर, आदि) संस्करणों के साथ |

#### PROV-O संबंध

| विधेय | अर्थ | उदाहरण |
|-----------|---------|---------|
<<<<<<< HEAD
| `prov:wasDerivedFrom` | एक इकाई से व्युत्पन्न अन्य इकाई | पृष्ठ दस्तावेज़ से व्युत्पन्न था |
| `prov:wasGeneratedBy` | एक गतिविधि द्वारा उत्पन्न इकाई | पृष्ठ पीडीएफ निष्कर्षण गतिविधि द्वारा उत्पन्न किया गया था |
| `prov:used` | गतिविधि ने एक इकाई को इनपुट के रूप में उपयोग किया | पीडीएफ निष्कर्षण गतिविधि ने दस्तावेज़ का उपयोग किया |
| `prov:wasAssociatedWith` | एक एजेंट द्वारा की गई गतिविधि | पीडीएफ निष्कर्षण गतिविधि tg:पीडीएफएक्सट्रैक्टर से जुड़ी थी |
=======
| `prov:wasDerivedFrom` | एक इकाई किसी अन्य इकाई से प्राप्त हुई | पृष्ठ दस्तावेज़ से प्राप्त हुआ |
| `prov:wasGeneratedBy` | एक इकाई एक गतिविधि द्वारा उत्पन्न हुई | पृष्ठ पीडीएफ निष्कर्षण गतिविधि द्वारा उत्पन्न हुआ |
| `prov:used` | एक गतिविधि ने एक इकाई को इनपुट के रूप में उपयोग किया | पीडीएफ निष्कर्षण गतिविधि ने दस्तावेज़ का उपयोग किया |
| `prov:wasAssociatedWith` | एक गतिविधि एक एजेंट द्वारा की गई | पीडीएफ निष्कर्षण गतिविधि tg:पीडीएफएक्सट्रैक्टर से जुड़ी थी |
>>>>>>> 82edf2d (New md files from RunPod)

#### प्रत्येक स्तर पर मेटाडेटा

**स्रोत दस्तावेज़ (लाइब्रेरियन द्वारा उत्सर्जित):**
```
doc:123 a prov:Entity .
doc:123 dc:title "Research Paper" .
doc:123 dc:source <https://example.com/paper.pdf> .
doc:123 dc:date "2024-01-15" .
doc:123 dc:creator "Author Name" .
doc:123 tg:pageCount 42 .
doc:123 tg:mimeType "application/pdf" .
```

<<<<<<< HEAD
**पृष्ठ (पीडीएफ एक्सट्रैक्टर द्वारा उत्सर्जित):**
=======
**पृष्ठ (पीडीएफ एक्सट्रैक्टर द्वारा उत्पन्न):**
>>>>>>> 82edf2d (New md files from RunPod)
```
page:123-1 a prov:Entity .
page:123-1 prov:wasDerivedFrom doc:123 .
page:123-1 prov:wasGeneratedBy activity:pdf-extract-456 .
page:123-1 tg:pageNumber 1 .

activity:pdf-extract-456 a prov:Activity .
activity:pdf-extract-456 prov:used doc:123 .
activity:pdf-extract-456 prov:wasAssociatedWith tg:PDFExtractor .
activity:pdf-extract-456 tg:componentVersion "1.2.3" .
activity:pdf-extract-456 prov:startedAtTime "2024-01-15T10:30:00Z" .
```

**खंड (चंकर द्वारा उत्सर्जित):**
```
chunk:123-1-1 a prov:Entity .
chunk:123-1-1 prov:wasDerivedFrom page:123-1 .
chunk:123-1-1 prov:wasGeneratedBy activity:chunk-789 .
chunk:123-1-1 tg:chunkIndex 1 .
chunk:123-1-1 tg:charOffset 0 .
chunk:123-1-1 tg:charLength 2048 .

activity:chunk-789 a prov:Activity .
activity:chunk-789 prov:used page:123-1 .
activity:chunk-789 prov:wasAssociatedWith tg:Chunker .
activity:chunk-789 tg:componentVersion "1.0.0" .
activity:chunk-789 tg:chunkSize 2048 .
activity:chunk-789 tg:chunkOverlap 200 .
```

**ट्रिपल (नॉलेज एक्सट्रैक्टर द्वारा उत्सर्जित):**
```
# The extracted triple (edge)
entity:JohnSmith rel:worksAt entity:AcmeCorp .

# Subgraph containing the extracted triples
subgraph:001 tg:contains <<entity:JohnSmith rel:worksAt entity:AcmeCorp>> .
subgraph:001 prov:wasDerivedFrom chunk:123-1-1 .
subgraph:001 prov:wasGeneratedBy activity:extract-999 .

activity:extract-999 a prov:Activity .
activity:extract-999 prov:used chunk:123-1-1 .
activity:extract-999 prov:wasAssociatedWith tg:KnowledgeExtractor .
activity:extract-999 tg:componentVersion "2.1.0" .
activity:extract-999 tg:llmModel "claude-3" .
activity:extract-999 tg:ontology <http://example.org/ontologies/business-v1> .
```

**एम्बेडिंग (वेक्टर स्टोर में संग्रहीत, ट्रिपल स्टोर में नहीं):**

एम्बेडिंग को मेटाडेटा के साथ वेक्टर स्टोर में संग्रहीत किया जाता है, न कि आरडीएफ ट्रिपल के रूप में। प्रत्येक एम्बेडिंग रिकॉर्ड में निम्नलिखित शामिल हैं:

| फ़ील्ड | विवरण | उदाहरण |
|-------|-------------|---------|
| वेक्टर | एम्बेडिंग वेक्टर | [0.123, -0.456, ...] |
| एंटिटी | नोड यूआरआई जिसे एम्बेडिंग दर्शाता है | `entity:JohnSmith` |
| चंक_आईडी | स्रोत चंक (उत्पत्ति) | `chunk:123-1-1` |
| मॉडल | उपयोग किया गया एम्बेडिंग मॉडल | `text-embedding-ada-002` |
| कंपोनेंट_वर्जन | टीजी एम्बेडर संस्करण | `1.0.0` |

`entity` फ़ील्ड एम्बेडिंग को नॉलेज ग्राफ (नोड यूआरआई) से जोड़ता है। `chunk_id` फ़ील्ड स्रोत चंक तक उत्पत्ति जानकारी प्रदान करता है, जिससे मूल दस्तावेज़ तक डीएजी (DAG) के माध्यम से ट्रैवर्स करना संभव हो जाता है।

#### ट्रस्टग्राफ नेमस्पेस एक्सटेंशन

<<<<<<< HEAD
निष्कर्षण-विशिष्ट मेटाडेटा के लिए `tg:` नेमस्पेस के अंतर्गत कस्टम प्रेडिकेट:
=======
निष्कर्षण-विशिष्ट मेटाडेटा के लिए `tg:` नेमस्पेस के तहत कस्टम प्रेडिकेट:
>>>>>>> 82edf2d (New md files from RunPod)

| प्रेडिकेट | डोमेन | विवरण |
|-----------|--------|-------------|
| `tg:contains` | सबग्राफ | इस निष्कर्षण सबग्राफ में निहित ट्रिपल की ओर इंगित करता है |
| `tg:pageCount` | दस्तावेज़ | स्रोत दस्तावेज़ में पृष्ठों की कुल संख्या |
| `tg:mimeType` | दस्तावेज़ | स्रोत दस्तावेज़ का एमआईएमई (MIME) प्रकार |
| `tg:pageNumber` | पृष्ठ | स्रोत दस्तावेज़ में पृष्ठ संख्या |
| `tg:chunkIndex` | चंक | मूल में चंक का इंडेक्स |
| `tg:charOffset` | चंक | मूल पाठ में कैरेक्टर ऑफसेट |
| `tg:charLength` | चंक | कैरेक्टर में चंक की लंबाई |
| `tg:chunkSize` | गतिविधि | कॉन्फ़िगर किया गया चंक आकार |
<<<<<<< HEAD
| `tg:chunkOverlap` | गतिविधि | चंक के बीच कॉन्फ़िगर किया गया ओवरलैप |
| `tg:componentVersion` | गतिविधि | टीजी घटक का संस्करण |
| `tg:llmModel` | गतिविधि | निष्कर्षण के लिए उपयोग किया गया एलएलएम (LLM) |
| `tg:ontology` | गतिविधि | निष्कर्षण का मार्गदर्शन करने के लिए उपयोग किया गया ऑन्टोलॉजी यूआरआई |
=======
| `tg:chunkOverlap` | गतिविधि | चंक्स के बीच कॉन्फ़िगर किया गया ओवरलैप |
| `tg:componentVersion` | गतिविधि | टीजी घटक का संस्करण |
| `tg:llmModel` | गतिविधि | निष्कर्षण के लिए उपयोग किया गया एलएलएम (LLM) |
| `tg:ontology` | गतिविधि | निष्कर्षण को निर्देशित करने के लिए उपयोग किया गया ऑन्टोलॉजी यूआरआई |
>>>>>>> 82edf2d (New md files from RunPod)
| `tg:embeddingModel` | गतिविधि | एम्बेडिंग के लिए उपयोग किया गया मॉडल |
| `tg:sourceText` | स्टेटमेंट | ट्रिपल से निकाले गए सटीक पाठ |
| `tg:sourceCharOffset` | स्टेटमेंट | चंक के भीतर स्रोत पाठ की शुरुआत का कैरेक्टर ऑफसेट |
| `tg:sourceCharLength` | स्टेटमेंट | कैरेक्टर में स्रोत पाठ की लंबाई |

#### शब्दावली बूटस्ट्रैप (प्रत्येक संग्रह के लिए)

नॉलेज ग्राफ ऑन्टोलॉजी-तटस्थ है और खाली अवस्था में शुरू होता है। पहली बार किसी संग्रह में पीआरओवी-ओ (PROV-O) उत्पत्ति डेटा लिखते समय, सभी क्लास और प्रेडिकेट के लिए आरडीएफ लेबल के साथ शब्दावली को बूटस्ट्रैप किया जाना चाहिए। यह प्रश्नों और यूआई (UI) में मानव-पठनीय प्रदर्शन सुनिश्चित करता है।

**पीआरओवी-ओ क्लास:**
```
prov:Entity rdfs:label "Entity" .
prov:Activity rdfs:label "Activity" .
prov:Agent rdfs:label "Agent" .
```

**प्रोव-ओ विधेय:**
```
prov:wasDerivedFrom rdfs:label "was derived from" .
prov:wasGeneratedBy rdfs:label "was generated by" .
prov:used rdfs:label "used" .
prov:wasAssociatedWith rdfs:label "was associated with" .
prov:startedAtTime rdfs:label "started at" .
```

**ट्रस्टग्राफ प्रेडिकेट्स:**
```
tg:contains rdfs:label "contains" .
tg:pageCount rdfs:label "page count" .
tg:mimeType rdfs:label "MIME type" .
tg:pageNumber rdfs:label "page number" .
tg:chunkIndex rdfs:label "chunk index" .
tg:charOffset rdfs:label "character offset" .
tg:charLength rdfs:label "character length" .
tg:chunkSize rdfs:label "chunk size" .
tg:chunkOverlap rdfs:label "chunk overlap" .
tg:componentVersion rdfs:label "component version" .
tg:llmModel rdfs:label "LLM model" .
tg:ontology rdfs:label "ontology" .
tg:embeddingModel rdfs:label "embedding model" .
tg:sourceText rdfs:label "source text" .
tg:sourceCharOffset rdfs:label "source character offset" .
tg:sourceCharLength rdfs:label "source character length" .
```

<<<<<<< HEAD
**कार्यान्वयन नोट:** यह शब्दावली बूटस्ट्रैप आइडेंम्पोटेंट होना चाहिए - बिना डुप्लिकेट बनाए कई बार चलाने के लिए सुरक्षित। इसे किसी संग्रह में पहली बार दस्तावेज़ प्रसंस्करण के दौरान या एक अलग संग्रह आरंभीकरण चरण के रूप में ट्रिगर किया जा सकता है।

#### उप-खंड उत्पत्ति (आदर्श)

अधिक बारीक उत्पत्ति के लिए, यह महत्वपूर्ण होगा कि एक त्रिक को एक खंड के भीतर से ठीक कहाँ से निकाला गया था, इसका रिकॉर्ड रखा जाए। यह निम्नलिखित को सक्षम करता है:
=======
**कार्यान्वयन नोट:** यह शब्दावली बूटस्ट्रैप आइडेंम्पोटेंट होना चाहिए - डुप्लिकेट बनाए बिना कई बार चलाने के लिए सुरक्षित। इसे किसी संग्रह में पहली बार दस्तावेज़ प्रसंस्करण के दौरान या एक अलग संग्रह आरंभीकरण चरण के रूप में ट्रिगर किया जा सकता है।

#### उप-खंड उत्पत्ति (आकांक्षी)

अधिक बारीक उत्पत्ति के लिए, यह महत्वपूर्ण होगा कि एक त्रिक को एक खंड के भीतर से कहाँ से निकाला गया था, यह सटीक रूप से रिकॉर्ड किया जाए। यह निम्नलिखित को सक्षम करता है:
>>>>>>> 82edf2d (New md files from RunPod)

यूआई में सटीक स्रोत पाठ को हाइलाइट करना
स्रोत के विरुद्ध निष्कर्षण सटीकता को सत्यापित करना
वाक्य स्तर पर निष्कर्षण गुणवत्ता को डीबग करना

**स्थिति ट्रैकिंग के साथ उदाहरण:**
```
# The extracted triple
entity:JohnSmith rel:worksAt entity:AcmeCorp .

# Subgraph with sub-chunk provenance
subgraph:001 tg:contains <<entity:JohnSmith rel:worksAt entity:AcmeCorp>> .
subgraph:001 prov:wasDerivedFrom chunk:123-1-1 .
subgraph:001 tg:sourceText "John Smith has worked at Acme Corp since 2019" .
subgraph:001 tg:sourceCharOffset 1547 .
subgraph:001 tg:sourceCharLength 46 .
```

**उदाहरण पाठ सीमा के साथ (वैकल्पिक):**
```
subgraph:001 tg:contains <<entity:JohnSmith rel:worksAt entity:AcmeCorp>> .
subgraph:001 prov:wasDerivedFrom chunk:123-1-1 .
subgraph:001 tg:sourceRange "1547-1593" .
subgraph:001 tg:sourceText "John Smith has worked at Acme Corp since 2019" .
```

**कार्यान्वयन संबंधी विचार:**

एलएलएम-आधारित निष्कर्षण स्वाभाविक रूप से वर्ण स्थिति प्रदान नहीं कर सकता है।
एलएलएम को निकाले गए त्रिगुटों के साथ स्रोत वाक्य/वाक्यांश वापस करने के लिए प्रेरित किया जा सकता है।
वैकल्पिक रूप से, निकाले गए संस्थाओं को स्रोत पाठ से "फजी-मैच" करके पोस्ट-प्रोसेस करें।
निष्कर्षण की जटिलता और उत्पत्ति की सूक्ष्मता के बीच एक समझौता।
यह संरचित निष्कर्षण विधियों की तुलना में मुफ्त-रूप एलएलएम निष्कर्षण से प्राप्त करना आसान हो सकता है।

यह एक महत्वाकांक्षी लक्ष्य के रूप में चिह्नित है - मूल रूप से, बुनियादी चंक-स्तरीय उत्पत्ति को पहले लागू किया जाना चाहिए, और यदि संभव हो तो, उप-चंक ट्रैकिंग को भविष्य में एक संवर्द्धन के रूप में लागू किया जा सकता है।

### दोहरी भंडारण मॉडल

<<<<<<< HEAD
उत्पत्ति डीएजी (DAG) को क्रमिक रूप से बनाया जाता है क्योंकि दस्तावेज़ पाइपलाइन के माध्यम से प्रवाहित होते हैं:
=======
उत्पत्ति DAG (डायरेक्टेड एसाइक्लिक ग्राफ) को क्रमिक रूप से बनाया जाता है क्योंकि दस्तावेज़ पाइपलाइन के माध्यम से प्रवाहित होते हैं:
>>>>>>> 82edf2d (New md files from RunPod)

| स्टोर | क्या संग्रहीत है | उद्देश्य |
|-------|---------------|---------|
| लाइब्रेरियन | दस्तावेज़ सामग्री + माता-पिता-बच्चे लिंक | सामग्री पुनर्प्राप्ति, कैस्केड विलोपन |
<<<<<<< HEAD
| ज्ञान ग्राफ | माता-पिता-बच्चे किनारे + मेटाडेटा | उत्पत्ति प्रश्न, तथ्य का श्रेय |

दोनों स्टोर समान डीएजी संरचना बनाए रखते हैं। लाइब्रेरियन सामग्री रखता है; ग्राफ संबंधों को रखता है और ट्रैवर्सल प्रश्नों को सक्षम करता है।

### प्रमुख डिज़ाइन सिद्धांत

1. **दस्तावेज़ आईडी प्रवाह की इकाई के रूप में** - प्रोसेसर आईडी, सामग्री नहीं, पास करते हैं। जब आवश्यक हो तो सामग्री लाइब्रेरियन से प्राप्त की जाती है।
=======
| नॉलेज ग्राफ | माता-पिता-बच्चे किनारे + मेटाडेटा | उत्पत्ति प्रश्न, तथ्य का श्रेय |

दोनों स्टोर समान DAG संरचना बनाए रखते हैं। लाइब्रेरियन सामग्री रखता है; ग्राफ संबंधों को रखता है और ट्रैवर्सल प्रश्नों को सक्षम बनाता है।

### प्रमुख डिज़ाइन सिद्धांत

1. **दस्तावेज़ आईडी प्रवाह की इकाई के रूप में** - प्रोसेसर आईडी, सामग्री नहीं, पास करते हैं। जब आवश्यक हो तो सामग्री को लाइब्रेरियन से प्राप्त किया जाता है।
>>>>>>> 82edf2d (New md files from RunPod)

2. **स्रोत पर एक बार उत्सर्जित करें** - प्रसंस्करण शुरू होने पर मेटाडेटा को ग्राफ में एक बार लिखा जाता है, न कि बाद में दोहराया जाता है।

3. **संगत प्रोसेसर पैटर्न** - प्रत्येक प्रोसेसर एक ही प्राप्त/प्राप्त/उत्पादित/सहेजें/उत्सर्जित/फॉरवर्ड पैटर्न का पालन करता है।

<<<<<<< HEAD
4. **प्रगतिशील डीएजी निर्माण** - प्रत्येक प्रोसेसर अपने स्तर को डीएजी में जोड़ता है। पूर्ण उत्पत्ति श्रृंखला क्रमिक रूप से बनाई जाती है।

5. **चंक-प्रोसेसर के बाद अनुकूलन** - चंकिंग के बाद, संदेशों में आईडी और सामग्री दोनों होते हैं। चंक छोटे होते हैं (2-4KB), इसलिए सामग्री को शामिल करने से अनावश्यक लाइब्रेरियन राउंड-ट्रिप से बचा जा सकता है, जबकि आईडी के माध्यम से उत्पत्ति को संरक्षित किया जा सकता है।
=======
4. **प्रगतिशील DAG निर्माण** - प्रत्येक प्रोसेसर अपने स्तर को DAG में जोड़ता है। पूर्ण उत्पत्ति श्रृंखला क्रमिक रूप से बनाई जाती है।

5. **चंक-प्रोसेसर के बाद अनुकूलन** - चंकिंग के बाद, संदेशों में आईडी और सामग्री दोनों होते हैं। चंक छोटे होते हैं (2-4KB), इसलिए सामग्री को शामिल करने से अनावश्यक लाइब्रेरियन राउंड-ट्रिप से बचा जाता है, जबकि आईडी के माध्यम से उत्पत्ति को संरक्षित किया जाता है।
>>>>>>> 82edf2d (New md files from RunPod)

## कार्यान्वयन कार्य

### लाइब्रेरियन परिवर्तन

#### वर्तमान स्थिति

दस्तावेज़ प्रसंस्करण शुरू करता है दस्तावेज़ आईडी को पहले प्रोसेसर को भेजकर।
ट्रिपल स्टोर से कोई कनेक्शन नहीं - मेटाडेटा निष्कर्षण आउटपुट के साथ बंडल किया गया है।
`add-child-document` एक-स्तरीय माता-पिता-बच्चे लिंक बनाता है।
`list-children` केवल तत्काल बच्चों को वापस करता है।

#### आवश्यक परिवर्तन

**1. नया इंटरफ़ेस: ट्रिपल स्टोर कनेक्शन**

<<<<<<< HEAD
लाइब्रेरियन को प्रसंस्करण शुरू करते समय दस्तावेज़ मेटाडेटा किनारों को सीधे ज्ञान ग्राफ में उत्सर्जित करने की आवश्यकता है।
=======
लाइब्रेरियन को प्रसंस्करण शुरू करते समय दस्तावेज़ मेटाडेटा किनारों को सीधे नॉलेज ग्राफ में उत्सर्जित करने की आवश्यकता है।
>>>>>>> 82edf2d (New md files from RunPod)
लाइब्रेरियन सेवा में ट्रिपल स्टोर क्लाइंट/प्रकाशक जोड़ें।
प्रसंस्करण शुरू होने पर: रूट दस्तावेज़ मेटाडेटा को ग्राफ किनारों के रूप में उत्सर्जित करें (एक बार)।

**2. दस्तावेज़ प्रकार शब्दावली**

चाइल्ड दस्तावेज़ों के लिए `document_type` मानों का मानकीकरण करें:
`source` - मूल अपलोड किया गया दस्तावेज़।
<<<<<<< HEAD
`page` - स्रोत से निकाला गया पृष्ठ (पीडीएफ, आदि)।
=======
`page` - स्रोत (पीडीएफ, आदि) से निकाला गया पृष्ठ।
>>>>>>> 82edf2d (New md files from RunPod)
`chunk` - पृष्ठ या स्रोत से प्राप्त पाठ चंक।

#### इंटरफ़ेस परिवर्तन सारांश

| इंटरफ़ेस | परिवर्तन |
|-----------|--------|
| ट्रिपल स्टोर | नया आउटबाउंड कनेक्शन - दस्तावेज़ मेटाडेटा किनारों को उत्सर्जित करें |
| प्रसंस्करण प्रारंभ | ग्राफ पर मेटाडेटा उत्सर्जित करें प्रसंस्करण को अग्रेषित करने से पहले |

### पीडीएफ एक्सट्रैक्टर परिवर्तन

#### वर्तमान स्थिति

दस्तावेज़ सामग्री प्राप्त करता है (या बड़े दस्तावेज़ों को स्ट्रीम करता है)।
पीडीएफ पृष्ठों से पाठ निकालता है।
पृष्ठ सामग्री को चंकर को अग्रेषित करता है।
लाइब्रेरियन या ट्रिपल स्टोर के साथ कोई इंटरैक्शन नहीं।

#### आवश्यक परिवर्तन

**1. नया इंटरफ़ेस: लाइब्रेरियन क्लाइंट**

<<<<<<< HEAD
पीडीएफ एक्सट्रैक्टर को प्रत्येक पृष्ठ को लाइब्रेरियन में एक चाइल्ड दस्तावेज़ के रूप में सहेजना होगा।
=======
पीडीएफ एक्सट्रैक्टर को प्रत्येक पृष्ठ को लाइब्रेरियन में एक चाइल्ड दस्तावेज़ के रूप में सहेजने की आवश्यकता है।
>>>>>>> 82edf2d (New md files from RunPod)
पीडीएफ एक्सट्रैक्टर सेवा में लाइब्रेरियन क्लाइंट जोड़ें।
प्रत्येक पृष्ठ के लिए: `add-child-document` को रूट दस्तावेज़ आईडी के साथ कॉल करें।

**2. नया इंटरफ़ेस: ट्रिपल स्टोर कनेक्शन**

<<<<<<< HEAD
पीडीएफ एक्सट्रैक्टर को ज्ञान ग्राफ में माता-पिता-बच्चे किनारे उत्सर्जित करने की आवश्यकता है।
=======
पीडीएफ एक्सट्रैक्टर को नॉलेज ग्राफ में माता-पिता-बच्चे किनारों को उत्सर्जित करने की आवश्यकता है।
>>>>>>> 82edf2d (New md files from RunPod)
ट्रिपल स्टोर क्लाइंट/प्रकाशक जोड़ें।
प्रत्येक पृष्ठ के लिए: पृष्ठ दस्तावेज़ को माता-पिता दस्तावेज़ से जोड़ने वाले किनारे को उत्सर्जित करें।

**3. आउटपुट प्रारूप बदलें**

सीधे पृष्ठ सामग्री अग्रेषित करने के बजाय, पृष्ठ दस्तावेज़ आईडी अग्रेषित करें।
<<<<<<< HEAD
चंकर लाइब्रेरियन का उपयोग करके आईडी के साथ सामग्री प्राप्त करेगा
=======
चंकर लाइब्रेरियन का उपयोग करके आईडी के साथ सामग्री प्राप्त करेगा।
>>>>>>> 82edf2d (New md files from RunPod)

#### इंटरफ़ेस परिवर्तनों का सारांश

| इंटरफ़ेस | परिवर्तन |
|-----------|--------|
| लाइब्रेरियन | नया आउटबाउंड - चाइल्ड दस्तावेज़ सहेजें |
| ट्रिपल स्टोर | नया आउटबाउंड - पैरेंट-चाइल्ड किनारे उत्सर्जित करें |
| आउटपुट संदेश | सामग्री से दस्तावेज़ आईडी में परिवर्तन |

### चंकर परिवर्तन

#### वर्तमान स्थिति

पृष्ठ/पाठ सामग्री प्राप्त करता है
टुकड़ों में विभाजित करता है
डाउनस्ट्रीम प्रोसेसर को टुकड़े सामग्री अग्रेषित करता है
लाइब्रेरियन या ट्रिपल स्टोर के साथ कोई इंटरैक्शन नहीं

#### आवश्यक परिवर्तन

**1. इनपुट हैंडलिंग बदलें**

सामग्री के बजाय दस्तावेज़ आईडी प्राप्त करें, लाइब्रेरियन से प्राप्त करें।
चंकर सेवा में लाइब्रेरियन क्लाइंट जोड़ें
दस्तावेज़ आईडी का उपयोग करके पृष्ठ सामग्री प्राप्त करें

**2. नया इंटरफ़ेस: लाइब्रेरियन क्लाइंट (लिखना)**

प्रत्येक टुकड़े को लाइब्रेरियन में एक चाइल्ड दस्तावेज़ के रूप में सहेजें।
प्रत्येक टुकड़े के लिए: `add-child-document` को पैरेंट = पृष्ठ दस्तावेज़ आईडी के साथ कॉल करें

**3. नया इंटरफ़ेस: ट्रिपल स्टोर कनेक्शन**

नॉलेज ग्राफ में पैरेंट-चाइल्ड किनारे उत्सर्जित करें।
ट्रिपल स्टोर क्लाइंट/प्रकाशक जोड़ें
प्रत्येक टुकड़े के लिए: टुकड़े दस्तावेज़ को पृष्ठ दस्तावेज़ से जोड़ने वाला किनारा उत्सर्जित करें

**4. आउटपुट प्रारूप बदलें**

टुकड़े दस्तावेज़ आईडी और टुकड़े सामग्री दोनों अग्रेषित करें (टुकड़े-टुकड़े अनुकूलन के बाद)।
डाउनस्ट्रीम प्रोसेसर उत्पत्ति के लिए आईडी और काम करने के लिए सामग्री प्राप्त करते हैं

#### इंटरफ़ेस परिवर्तनों का सारांश

| इंटरफ़ेस | परिवर्तन |
|-----------|--------|
| इनपुट संदेश | सामग्री से दस्तावेज़ आईडी में परिवर्तन |
| लाइब्रेरियन | नया आउटबाउंड (पढ़ना + लिखना) - सामग्री प्राप्त करें, चाइल्ड दस्तावेज़ सहेजें |
| ट्रिपल स्टोर | नया आउटबाउंड - पैरेंट-चाइल्ड किनारे उत्सर्जित करें |
| आउटपुट संदेश | सामग्री-केवल से आईडी + सामग्री में परिवर्तन |

### नॉलेज एक्सट्रैक्टर परिवर्तन

#### वर्तमान स्थिति

टुकड़े सामग्री प्राप्त करता है
ट्रिपल और एम्बेडिंग निकालता है
ट्रिपल स्टोर और एम्बेडिंग स्टोर में उत्सर्जित करता है
`subjectOf` संबंध शीर्ष-स्तरीय दस्तावेज़ (टुकड़े नहीं) की ओर इशारा करता है

#### आवश्यक परिवर्तन

**1. इनपुट हैंडलिंग बदलें**

<<<<<<< HEAD
टुकड़े दस्तावेज़ आईडी के साथ-साथ सामग्री प्राप्त करें।
=======
सामग्री के साथ-साथ टुकड़े दस्तावेज़ आईडी प्राप्त करें।
>>>>>>> 82edf2d (New md files from RunPod)
उत्पत्ति लिंकिंग के लिए टुकड़े आईडी का उपयोग करें (सामग्री पहले से ही अनुकूलन के अनुसार शामिल है)

**2. ट्रिपल उत्पत्ति को अपडेट करें**

निकाले गए ट्रिपल को टुकड़े (शीर्ष-स्तरीय दस्तावेज़ नहीं) से लिंक करें।
किनारे को इंगित करने वाले किनारे को बनाने के लिए पुन: उपयोग करें
`subjectOf` संबंध: ट्रिपल → टुकड़े दस्तावेज़ आईडी
मौजूदा पुन: उपयोग समर्थन का पहला उपयोग

**3. एम्बेडिंग उत्पत्ति को अपडेट करें**

<<<<<<< HEAD
एम्बेडिंग इकाई आईडी को टुकड़े से लिंक करें।
किनारा उत्सर्जित करें: एम्बेडिंग इकाई आईडी → टुकड़े दस्तावेज़ आईडी
=======
एम्बेडिंग एंटिटी आईडी को टुकड़े से लिंक करें।
किनारा उत्सर्जित करें: एम्बेडिंग एंटिटी आईडी → टुकड़े दस्तावेज़ आईडी
>>>>>>> 82edf2d (New md files from RunPod)

#### इंटरफ़ेस परिवर्तनों का सारांश

| इंटरफ़ेस | परिवर्तन |
|-----------|--------|
<<<<<<< HEAD
| इनपुट संदेश | टुकड़े आईडी + सामग्री की अपेक्षा करें (केवल सामग्री नहीं) |
| ट्रिपल स्टोर | ट्रिपल → टुकड़े उत्पत्ति के लिए पुन: उपयोग का उपयोग करें |
| एम्बेडिंग उत्पत्ति | इकाई आईडी → टुकड़े आईडी से लिंक करें |
=======
| इनपुट संदेश | सामग्री के साथ टुकड़े आईडी + सामग्री की अपेक्षा करें (केवल सामग्री नहीं) |
| ट्रिपल स्टोर | ट्रिपल → टुकड़े उत्पत्ति के लिए पुन: उपयोग का उपयोग करें |
| एम्बेडिंग उत्पत्ति | एंटिटी आईडी → टुकड़े आईडी से लिंक करें |
>>>>>>> 82edf2d (New md files from RunPod)

## संदर्भ

क्वेरी-टाइम उत्पत्ति: `docs/tech-specs/query-time-provenance.md`
उत्पत्ति मॉडलिंग के लिए PROV-O मानक
नॉलेज ग्राफ में मौजूदा स्रोत मेटाडेटा (ऑडिट की आवश्यकता है)