trustgraph/docs/tech-specs/schema-refactoring-proposal.hi.md

स्कीमा निर्देशिका का पुनर्गठन प्रस्ताव

वर्तमान मुद्दे

1. सममित संरचना - सभी स्कीमा एक ही निर्देशिका में होने से उनके बीच के संबंधों को समझना मुश्किल हो जाता है
2. विभिन्न चिंताएं - कोर प्रकार, डोमेन ऑब्जेक्ट और एपीआई अनुबंध सभी एक साथ
3. अस्पष्ट नामकरण - फ़ाइलें जैसे "object.py", "types.py", "topic.py" स्पष्ट रूप से उनकी propósito नहीं दर्शाती हैं
4. स्पष्ट परतें नहीं - यह स्पष्ट नहीं है कि कौन सी चीज़ किससे जुड़ी है

प्रस्तावित संरचना

trustgraph-base/trustgraph/schema/
├── __init__.py
├── core/              # हर जगह उपयोग किए जाने वाले कोर मूल प्रकार
│   ├── __init__.py
│   ├── primitives.py  # त्रुटि, मूल्य, त्रिक, फ़ील्ड, पंक्ति स्कीमा
│   ├── metadata.py    # मेटाडेटा रिकॉर्ड
│   └── topic.py       # विषय उपयोगिताएं
│
├── knowledge/         # ज्ञान डोमेन मॉडल और निष्कर्षण
│   ├── __init__.py
│   ├── graph.py       # एंटिटीसंदर्भ, एंटिटी एम्बेडिंग, त्रिक
│   ├── document.py    # दस्तावेज़, टेक्स्टदस्तावेज़, टुकड़ा
│   ├── knowledge.py   # ज्ञान निष्कर्षण प्रकार
│   ├── embeddings.py  # सभी एम्बेडिंग संबंधित प्रकार (कई फ़ाइलों से स्थानांतरित)
│   └── nlp.py         # परिभाषा, विषय, संबंध, तथ्य प्रकार
│
└── services/          # सेवा अनुरोध/प्रतिक्रिया अनुबंध
    ├── __init__.py
    ├── llm.py         # टेक्स्टकम्प्लीशन, एम्बेडिंग, टूल अनुरोध/प्रतिक्रिया
    ├── retrieval.py   # ग्राफ़RAG, दस्तावेज़RAG क्वेरी/प्रतिक्रिया
    ├── query.py       # ग्राफ़एम्बेडिंग अनुरोध/प्रतिक्रिया, दस्तावेज़एम्बेडिंग अनुरोध/प्रतिक्रिया
    ├── agent.py       # एजेंट अनुरोध/प्रतिक्रिया
    ├── flow.py        # फ़्लो अनुरोध/प्रतिक्रिया
    ├── prompt.py      # प्रॉम्प्ट सेवा अनुरोध/प्रतिक्रिया
    ├── config.py      # कॉन्फ़िगरेशन सेवा
    ├── library.py     # लाइब्रेरियन सेवा
    └── lookup.py      # लुकअप सेवा

मुख्य परिवर्तन

1. पदानुक्रमित संगठन - स्पष्ट विभाजन कोर प्रकारों, ज्ञान मॉडल और सेवा अनुबंधों के बीच

2. बेहतर नामकरण:

   • types.py → core/primitives.py (अधिक स्पष्ट उद्देश्य)
   • object.py → वास्तविक सामग्री के आधार पर उचित फ़ाइलों में विभाजित
   • documents.py → knowledge/document.py (एकल, सुसंगत)
   • models.py → services/llm.py (अधिक स्पष्ट रूप से किस प्रकार के मॉडल)
   • prompt.py → विभाजित: सेवा भागों को services/prompt.py में, डेटा प्रकारों को knowledge/nlp.py में

3. तार्किक समूहीकरण:

   • सभी एम्बेडिंग प्रकारों को knowledge/embeddings.py में समेकित किया गया है
   • सभी LLM-संबंधित सेवा अनुबंधों को services/llm.py में रखा गया है
   • सेवाओं की निर्देशिका में अनुरोध/प्रतिक्रिया जोड़े का स्पष्ट विभाजन
   • ज्ञान निष्कर्षण प्रकारों को अन्य ज्ञान डोमेन मॉडल के साथ समूहीकृत किया गया है

4. निर्भरता स्पष्टता:

   • कोर प्रकारों में कोई निर्भरता नहीं है
   • ज्ञान मॉडल केवल कोर पर निर्भर होते हैं
   • सेवा अनुबंध कोर और ज्ञान मॉडल दोनों पर निर्भर हो सकते हैं

माइग्रेशन के लाभ

1. आसान नेविगेशन - डेवलपर्स आसानी से वह ढूंढ सकते हैं जिसकी उन्हें आवश्यकता है
2. बेहतर मॉड्यूलरिटी - विभिन्न चिंताओं के बीच स्पष्ट सीमाएं
3. सरल आयात - अधिक सहज आयात पथ
4. भविष्य के लिए तैयार - बिना किसी अव्यवस्था के, नई ज्ञान प्रकारों या सेवाओं को आसानी से जोड़ा जा सकता है

उदाहरण आयात परिवर्तन

# पहले
from trustgraph.schema import Error, Triple, GraphEmbeddings, TextCompletionRequest

# बाद में
from trustgraph.schema.core import Error, Triple
from trustgraph.schema.knowledge import GraphEmbeddings
from trustgraph.schema.services import TextCompletionRequest

कार्यान्वयन नोट्स

1. मूल __init__.py में आयात को बनाए रखकर पिछड़े अनुकूलता बनाए रखें
2. धीरे-धीरे फ़ाइलों को स्थानांतरित करें, आवश्यक अनुसार आयात को अपडेट करें
3. एक legacy.py जोड़ने पर विचार करें जो एक संक्रमण अवधि के लिए सब कुछ आयात करता है
4. नए संरचना को दर्शाने के लिए दस्तावेज़ अपडेट करें

<function_calls> [{"id": "1", "content": "वर्तमान स्कीमा निर्देशिका संरचना की जाँच करें", "status": "पूर्ण", "प्राथमिकता": "उच्च"}, {"id": "2", "content": "स्कीमा फ़ाइलों और उनके उद्देश्यों का विश्लेषण करें", "status": "पूर्ण", "प्राथमिकता": "उच्च"}, {"id": "3", "content": "बेहतर नामकरण और संरचना का प्रस्ताव", "status": "पूर्ण", "प्राथमिकता": "उच्च"}]