Feat: TrustGraph i18n & Documentation Translation Updates (#781)

Native CLI i18n: The TrustGraph CLI has built-in translation support
that dynamically loads language strings. You can test and use
different languages by simply passing the --lang flag (e.g., --lang
es for Spanish, --lang ru for Russian) or by configuring your
environment's LANG variable.

Automated Docs Translations: This PR introduces autonomously
translated Markdown documentation into several target languages,
including Spanish, Swahili, Portuguese, Turkish, Hindi, Hebrew,
Arabic, Simplified Chinese, and Russian.
This commit is contained in:
Alex Jenkins 2026-04-14 07:07:58 -04:00 committed by GitHub
parent 19f73e4cdc
commit f95fd4f052
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
560 changed files with 236300 additions and 99 deletions

View file

@ -0,0 +1,328 @@
---
layout: default
title: "फ्लो ब्लूप्रिंट परिभाषा विनिर्देश"
parent: "Hindi (Beta)"
---
# फ्लो ब्लूप्रिंट परिभाषा विनिर्देश
> **Beta Translation:** This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.
## अवलोकन
एक फ्लो ब्लूप्रिंट ट्रस्टग्राफ सिस्टम में एक पूर्ण डेटाफ्लो पैटर्न टेम्पलेट को परिभाषित करता है। जब इसे कार्यान्वित किया जाता है, तो यह प्रोसेसर का एक अंतर्संबंधित नेटवर्क बनाता है जो डेटा इनपुट, प्रसंस्करण, भंडारण और क्वेरी को एक एकीकृत प्रणाली के रूप में संभालता है।
## संरचना
एक फ्लो ब्लूप्रिंट परिभाषा में पाँच मुख्य अनुभाग होते हैं:
### 1. क्लास अनुभाग
<<<<<<< HEAD
यह साझा सेवा प्रोसेसर को परिभाषित करता है जिन्हें प्रत्येक फ्लो ब्लूप्रिंट के लिए एक बार इंस्टेंट किया जाता है। ये प्रोसेसर इस क्लास के सभी फ्लो उदाहरणों से अनुरोधों को संभालते हैं।
=======
साझा सेवा प्रोसेसर को परिभाषित करता है जिन्हें प्रत्येक फ्लो ब्लूप्रिंट के लिए एक बार इंस्टेंट किया जाता है। ये प्रोसेसर इस क्लास के सभी फ्लो उदाहरणों से अनुरोधों को संभालते हैं।
>>>>>>> 82edf2d (New md files from RunPod)
```json
"class": {
"service-name:{class}": {
"request": "queue-pattern:{class}",
"response": "queue-pattern:{class}",
"settings": {
"setting-name": "fixed-value",
"parameterized-setting": "{parameter-name}"
}
}
}
```
**विशेषताएं:**
समान वर्ग के सभी फ्लो उदाहरणों में साझा किया जाता है।
आमतौर पर महंगी या स्टेटलेस सेवाएं (एलएलएम, एम्बेडिंग मॉडल)।
<<<<<<< HEAD
कतार नामकरण के लिए `{class}` टेम्पलेट वेरिएबल का उपयोग करें।
=======
क्यू नामकरण के लिए `{class}` टेम्पलेट वेरिएबल का उपयोग करें।
>>>>>>> 82edf2d (New md files from RunPod)
सेटिंग्स निश्चित मान हो सकती हैं या `{parameter-name}` सिंटैक्स के साथ पैरामीटराइज़ की जा सकती हैं।
उदाहरण: `embeddings:{class}`, `text-completion:{class}`, `graph-rag:{class}`
### 2. फ्लो सेक्शन
फ्लो-विशिष्ट प्रोसेसर को परिभाषित करता है जिन्हें प्रत्येक व्यक्तिगत फ्लो उदाहरण के लिए इंस्टेंट किया जाता है। प्रत्येक फ्लो को इन प्रोसेसर का अपना अलग सेट मिलता है।
```json
"flow": {
"processor-name:{id}": {
"input": "queue-pattern:{id}",
"output": "queue-pattern:{id}",
"settings": {
"setting-name": "fixed-value",
"parameterized-setting": "{parameter-name}"
}
}
}
```
**विशेषताएं:**
प्रत्येक प्रवाह के लिए अद्वितीय उदाहरण।
प्रवाह-विशिष्ट डेटा और स्थिति को संभालें।
कतार नामकरण के लिए `{id}` टेम्पलेट चर का उपयोग करें।
सेटिंग्स या तो निश्चित मान हो सकती हैं या `{parameter-name}` सिंटैक्स के साथ पैरामीटराइज़ की जा सकती हैं।
उदाहरण: `chunker:{id}`, `pdf-decoder:{id}`, `kg-extract-relationships:{id}`
### 3. इंटरफेस अनुभाग
<<<<<<< HEAD
यह प्रवाह के लिए प्रवेश बिंदुओं और इंटरैक्शन अनुबंधों को परिभाषित करता है। ये बाहरी प्रणालियों और आंतरिक घटक संचार के लिए एपीआई सतह बनाते हैं।
=======
यह प्रवाह के लिए प्रवेश बिंदु और इंटरैक्शन अनुबंधों को परिभाषित करता है। ये बाहरी प्रणालियों और आंतरिक घटक संचार के लिए एपीआई सतह बनाते हैं।
>>>>>>> 82edf2d (New md files from RunPod)
इंटरफेस दो रूप ले सकते हैं:
**फायर-एंड-फॉरगेट पैटर्न** (एक कतार):
```json
"interfaces": {
"document-load": "persistent://tg/flow/document-load:{id}",
"triples-store": "persistent://tg/flow/triples-store:{id}"
}
```
**अनुरोध/प्रतिक्रिया पैटर्न** (अनुरोध/प्रतिक्रिया फ़ील्ड वाले ऑब्जेक्ट):
```json
"interfaces": {
"embeddings": {
"request": "non-persistent://tg/request/embeddings:{class}",
"response": "non-persistent://tg/response/embeddings:{class}"
}
}
```
**इंटरफेस के प्रकार:**
**एंट्री पॉइंट:** वे स्थान जहाँ बाहरी सिस्टम डेटा इंजेक्ट करते हैं (`document-load`, `agent`)
**सर्विस इंटरफेस:** सेवाओं के लिए अनुरोध/प्रतिक्रिया पैटर्न (`embeddings`, `text-completion`)
**डेटा इंटरफेस:** फायर-एंड-फॉरगेट डेटा प्रवाह कनेक्शन बिंदु (`triples-store`, `entity-contexts-load`)
### 4. पैरामीटर अनुभाग
यह प्रवाह-विशिष्ट पैरामीटर नामों को केंद्रीय रूप से संग्रहीत पैरामीटर परिभाषाओं से जोड़ता है:
```json
"parameters": {
"model": "llm-model",
"temp": "temperature",
"chunk": "chunk-size"
}
```
**विशेषताएं:**
कुंजियाँ प्रोसेसर सेटिंग्स में उपयोग किए जाने वाले पैरामीटर नामों को संदर्भित करती हैं (उदाहरण के लिए, `{model}`)
मान स्कीमा/कॉन्फ़िगरेशन में संग्रहीत पैरामीटर परिभाषाओं को संदर्भित करते हैं।
यह सामान्य पैरामीटर परिभाषाओं को विभिन्न फ्लो में पुन: उपयोग करने की अनुमति देता है।
पैरामीटर स्कीमा की डुप्लिकेसी को कम करता है।
### 5. मेटाडेटा
फ्लो ब्लूप्रिंट के बारे में अतिरिक्त जानकारी:
```json
"description": "Human-readable description",
"tags": ["capability-1", "capability-2"]
```
## टेम्पलेट वेरिएबल
### सिस्टम वेरिएबल
#### {id}
यह अद्वितीय फ्लो इंस्टेंस पहचानकर्ता से प्रतिस्थापित किया जाता है।
यह प्रत्येक फ्लो के लिए अलग-अलग संसाधन बनाता है।
उदाहरण: `flow-123`, `customer-A-flow`
#### {class}
यह फ्लो ब्लूप्रिंट नाम से प्रतिस्थापित किया जाता है।
यह समान क्लास के फ्लो में साझा संसाधनों का निर्माण करता है।
उदाहरण: `standard-rag`, `enterprise-rag`
### पैरामीटर वेरिएबल
#### {पैरामीटर-नाम}
फ्लो लॉन्च करते समय परिभाषित कस्टम पैरामीटर।
पैरामीटर नाम फ्लो के `parameters` अनुभाग में कुंजियों से मेल खाते हैं।
प्रोसेसर सेटिंग्स में व्यवहार को अनुकूलित करने के लिए उपयोग किया जाता है।
उदाहरण: `{model}`, `{temp}`, `{chunk}`
फ्लो लॉन्च करते समय प्रदान किए गए मानों से प्रतिस्थापित किया जाता है।
केंद्रीय रूप से संग्रहीत पैरामीटर परिभाषाओं के विरुद्ध मान्य किया जाता है।
## प्रोसेसर सेटिंग्स
सेटिंग्स, इंस्टैंशिएशन के समय प्रोसेसरों को कॉन्फ़िगरेशन मान प्रदान करती हैं। वे निम्न हो सकते हैं:
### फिक्स्ड सेटिंग्स
सीधे मान जो नहीं बदलते:
```json
"settings": {
"model": "gemma3:12b",
"temperature": 0.7,
"max_retries": 3
}
```
### पैरामीटराइज़्ड सेटिंग्स
<<<<<<< HEAD
वे मान जो प्रवाह शुरू करते समय प्रदान किए गए पैरामीटर का उपयोग करते हैं:
=======
वे मान जो फ्लो शुरू करते समय प्रदान किए गए पैरामीटर का उपयोग करते हैं:
>>>>>>> 82edf2d (New md files from RunPod)
```json
"settings": {
"model": "{model}",
"temperature": "{temp}",
"endpoint": "https://{region}.api.example.com"
}
```
सेटिंग्स में पैरामीटर नाम, प्रवाह के `parameters` अनुभाग में कुंजियों से मेल खाते हैं।
### सेटिंग्स के उदाहरण
**पैरामीटर के साथ एलएलएम प्रोसेसर:**
```json
// In parameters section:
"parameters": {
"model": "llm-model",
"temp": "temperature",
"tokens": "max-tokens",
"key": "openai-api-key"
}
// In processor definition:
"text-completion:{class}": {
"request": "non-persistent://tg/request/text-completion:{class}",
"response": "non-persistent://tg/response/text-completion:{class}",
"settings": {
"model": "{model}",
"temperature": "{temp}",
"max_tokens": "{tokens}",
"api_key": "{key}"
}
}
```
**निश्चित और पैरामीटराइज़्ड सेटिंग्स के साथ चंकर:**
```json
// In parameters section:
"parameters": {
"chunk": "chunk-size"
}
// In processor definition:
"chunker:{id}": {
"input": "persistent://tg/flow/chunk:{id}",
"output": "persistent://tg/flow/chunk-load:{id}",
"settings": {
"chunk_size": "{chunk}",
"chunk_overlap": 100,
"encoding": "utf-8"
}
}
```
## क्यू पैटर्न (पल्सर)
फ्लो ब्लूप्रिंट्स संदेश भेजने के लिए अपाचे पल्सर का उपयोग करते हैं। क्यू नामों का प्रारूप पल्सर प्रारूप का अनुसरण करता है:
```
<persistence>://<tenant>/<namespace>/<topic>
```
### घटक:
**स्थायित्व**: `persistent` या `non-persistent` (पल्सर स्थायित्व मोड)
<<<<<<< HEAD
**किरायेदार**: ट्रस्टग्राफ द्वारा प्रदान किए गए प्रवाह ब्लूप्रिंट परिभाषाओं के लिए `tg`
=======
**किरायेदार**: ट्रस्टग्राफ द्वारा प्रदान किए गए फ़्लो ब्लूप्रिंट परिभाषाओं के लिए `tg`
>>>>>>> 82edf2d (New md files from RunPod)
**नामस्थान**: यह संदेश पैटर्न को इंगित करता है
`flow`: फायर-एंड-फॉरगेट सेवाएं
`request`: अनुरोध/प्रतिक्रिया सेवाओं का अनुरोध भाग
`response`: अनुरोध/प्रतिक्रिया सेवाओं का प्रतिक्रिया भाग
**विषय**: टेम्पलेट चर के साथ विशिष्ट कतार/विषय नाम
### स्थायी कतारें
पैटर्न: `persistent://tg/flow/<topic>:{id}`
फायर-एंड-फॉरगेट सेवाओं और टिकाऊ डेटा प्रवाह के लिए उपयोग किया जाता है
डेटा पल्सर स्टोरेज में पुनरारंभों में बना रहता है
उदाहरण: `persistent://tg/flow/chunk-load:{id}`
### गैर-स्थायी कतारें
पैटर्न: `non-persistent://tg/request/<topic>:{class}` या `non-persistent://tg/response/<topic>:{class}`
अनुरोध/प्रतिक्रिया संदेश पैटर्न के लिए उपयोग किया जाता है
अस्थिर, पल्सर द्वारा डिस्क पर संग्रहीत नहीं है
कम विलंबता, RPC-शैली संचार के लिए उपयुक्त
उदाहरण: `non-persistent://tg/request/embeddings:{class}`
## डेटाफ्लो आर्किटेक्चर
<<<<<<< HEAD
प्रवाह ब्लूप्रिंट एक एकीकृत डेटाफ्लो बनाता है जहां:
=======
फ़्लो ब्लूप्रिंट एक एकीकृत डेटाफ्लो बनाता है जहां:
>>>>>>> 82edf2d (New md files from RunPod)
1. **दस्तावेज़ प्रसंस्करण पाइपलाइन**: अंतर्ग्रहण से लेकर परिवर्तन और भंडारण तक का प्रवाह
2. **क्वेरी सेवाएं**: एकीकृत प्रोसेसर जो समान डेटा स्टोर और सेवाओं को क्वेरी करते हैं
3. **साझा सेवाएं**: केंद्रीय प्रोसेसर जिनका उपयोग सभी प्रवाह कर सकते हैं
<<<<<<< HEAD
4. **भंडारण लेखक**: संसाधित डेटा को उपयुक्त स्टोर में सहेजें
सभी प्रोसेसर (दोनों `{id}` और `{class}`) एक सुसंगत डेटाफ्लो ग्राफ के रूप में एक साथ काम करते हैं, अलग-अलग सिस्टम के रूप में नहीं।
## उदाहरण प्रवाह कार्यान्वयन
दिया गया:
प्रवाह उदाहरण आईडी: `customer-A-flow`
प्रवाह ब्लूप्रिंट: `standard-rag`
प्रवाह पैरामीटर मैपिंग:
=======
4. **भंडारण लेखक**: संसाधित डेटा को उपयुक्त स्टोर में संग्रहीत करते हैं
सभी प्रोसेसर (दोनों `{id}` और `{class}`) एक सुसंगत डेटाफ्लो ग्राफ के रूप में एक साथ काम करते हैं, अलग-अलग सिस्टम के रूप में नहीं।
## उदाहरण फ़्लो इंस्टेंशिएशन
दिया गया:
फ़्लो इंस्टेंस आईडी: `customer-A-flow`
फ़्लो ब्लूप्रिंट: `standard-rag`
फ़्लो पैरामीटर मैपिंग:
>>>>>>> 82edf2d (New md files from RunPod)
`"model": "llm-model"`
`"temp": "temperature"`
`"chunk": "chunk-size"`
उपयोगकर्ता-प्रदत्त पैरामीटर:
`model`: `gpt-4`
`temp`: `0.5`
`chunk`: `512`
टेम्पलेट विस्तार:
`persistent://tg/flow/chunk-load:{id}``persistent://tg/flow/chunk-load:customer-A-flow`
`non-persistent://tg/request/embeddings:{class}``non-persistent://tg/request/embeddings:standard-rag`
`"model": "{model}"``"model": "gpt-4"`
`"temperature": "{temp}"``"temperature": "0.5"`
`"chunk_size": "{chunk}"``"chunk_size": "512"`
यह बनाता है:
`customer-A-flow` के लिए अलग दस्तावेज़ प्रसंस्करण पाइपलाइन
सभी `standard-rag` प्रवाह के लिए साझा एम्बेडिंग सेवा
दस्तावेज़ अंतर्ग्रहण से लेकर क्वेरी तक का पूर्ण डेटाफ्लो
प्रोसेसर प्रदान किए गए पैरामीटर मानों के साथ कॉन्फ़िगर किए गए
## लाभ
1. **संसाधन दक्षता**: महंगी सेवाओं को प्रवाह में साझा किया जाता है
<<<<<<< HEAD
2. **प्रवाह अलगाव**: प्रत्येक प्रवाह का अपना डेटा प्रसंस्करण पाइपलाइन होता है
3. **मापनीयता**: एक ही टेम्पलेट से कई प्रवाहों को कार्यान्वित किया जा सकता है
4. **मॉड्यूलरिटी**: साझा और प्रवाह-विशिष्ट घटकों के बीच स्पष्ट अलगाव
=======
2. **फ़्लो अलगाव**: प्रत्येक फ़्लो का अपना डेटा प्रसंस्करण पाइपलाइन होता है
3. **मापनीयता**: एक ही टेम्पलेट से कई फ़्लो को इंस्टेंशिएट किया जा सकता है
4. **मॉड्यूलरिटी**: साझा और फ़्लो-विशिष्ट घटकों के बीच स्पष्ट अलगाव
>>>>>>> 82edf2d (New md files from RunPod)
5. **एकीकृत आर्किटेक्चर**: क्वेरी और प्रसंस्करण एक ही डेटाफ्लो का हिस्सा हैं