failproofai 1.0.1-beta.0 → 1.0.1

package/.next/standalone/docs-old/hi/agenteye/alerts.mdx

@@ -0,0 +1,62 @@
+---
+title: "सतर्कताएं"
+description: "उसी क्षण जानें जब कोई चीज़ आपकी सीमा को पार करे, उसी चैनल पर जो आपकी टीम पहले से देखती है, बजाय इसके कि किसी ग्राहक से सुनें।"
+---
+
+उसी क्षण जानें जब कोई चीज़ आपकी सीमा को पार करे, उसी चैनल पर जो आपकी टीम पहले से देखती है, बजाय इसके कि किसी ग्राहक से सुनें। एक बार नियम सेट करें और Failproof AI Observability इसे निर्धारित अनुसूची पर जांचता है, फिर ईमेल, Slack, webhook, या सीधे डैशबोर्ड में आपको सूचित करता है।
+
+![सतर्कता पृष्ठ: सतर्कता-नियम कार्डों का एक ग्रिड, प्रत्येक अपने ट्रिगर, मूल्यांकन विंडो, चैनल, और एक सूचना, चेतावनी, या महत्वपूर्ण गंभीरता बैज दिखा रहा है](/agenteye/images/alerts.png)
+*एक नज़र में हर सतर्कता नियम: यह क्या देखता है, कितनी बार, कहां सूचित करता है, और कितना जरूरी है।*
+
+## अपने उपयोगकर्ताओं से पहले समस्याओं के बारे में जानें
+
+डैशबोर्ड को ताज़ा करना बंद करें और प्रतिगमन पकड़ने की उम्मीद करें। जब भी कोई संकेत हो जो आप सुनना चाहते हैं तब भी जब कोई नहीं देख रहा हो, तो एक सतर्कता का उपयोग करें, और इसे उसी जगह भेजें जहां आप पहले से हैं:
+
+- **ईमेल**, जिसे यह जानना चाहिए उन लोगों को।
+- **Slack**, एक समृद्ध संदेश एक बटन के साथ जो सीधे घटना पर कूदता है।
+- **Webhook**, PagerDuty, Opsgenie, या आपके अपने endpoint के लिए JSON POST, एक वैकल्पिक हस्ताक्षर के साथ ताकि प्राप्तकर्ता इस पर विश्वास कर सके।
+- **डैशबोर्ड में**, डिज़ाइन के अनुसार शांत, जब आप एक नियम को समायोजित कर रहे हों और अभी किसी को सूचित नहीं करना चाहते।
+
+किसी एक नियम के लिए कोई भी संयोजन संलग्न करें, और इसकी गंभीरता (सूचना, चेतावनी, या महत्वपूर्ण) साथ जाती है ताकि जरूरी वाले जरूरी दिखें।
+
+## फॉर्म में नियम बनाएं, JSON में नहीं
+
+आप एक फॉर्म में बताते हैं कि "टूटा हुआ" का अर्थ क्या है, और Failproof AI Observability आपके लिए अंतर्निहित नियम लिखता है। JSON spec केवल वह है जो वह फॉर्म हुड के नीचे बनाता है, इसलिए आप इसे एक नियम को समझने के लिए पढ़ सकते हैं लेकिन आप शायद ही कभी इसे टाइप करते हैं।
+
+![नई-सतर्कता फॉर्म: नाम और विवरण, एक सक्षम टॉगल, और एक ट्रिगर पिकर जो मेट्रिक थ्रेसहोल्ड, कस्टम SQL, मूल्यांकन स्कोर, यौगिक मूल्यांकन, और प्रति-ईवेंट शर्तें प्रदान करता है](/agenteye/images/alert-new.png)
+*एक ट्रिगर चुनें और फॉर्म सही फील्ड में स्वैप करता है; सहेजें नियम लिखता है।*
+
+खुशियों की राह तेज़ है: इसका नाम दें, एक **ट्रिगर** चुनें (क्या देखना है), **थ्रेसहोल्ड और विंडो** सेट करें (कितना बुरा, कितने समय में), कम से कम एक **चैनल** संलग्न करें, फिर **सहेजें** और **परीक्षण** दबाएं एक कृत्रिम सूचना भेजने के लिए और पुष्टि करें कि हर गंतव्य सेट अप है। हुड के नीचे यह एक छोटा spec बनाता है जैसे:
+
+```json
+{ "metric": "p95_latency_ms", "op": ">", "value": 5000, "window_secs": 900 }
+```
+
+आप एक प्रकार के संकेत तक सीमित नहीं हैं। ऐसे ट्रिगर को चुनें जो आपके विफलता के बारे में सोचने के तरीके से मेल खाता हो:
+
+| ट्रिगर | कब फायर होता है |
+|---|---|
+| **मेट्रिक थ्रेसहोल्ड** | एक पूर्वनिर्धारित मेट्रिक (त्रुटि दर, p95 या p99 विलंबता, ईवेंट या त्रुटि गणना, टोकन खर्च) एक विंडो पर आपकी सीमा को पार करता है |
+| **कस्टम SQL** | आपकी स्वयं की पढ़ने-केवल क्वेरी एक पंक्ति लौटाती है, या यह एक मान की गणना करता है जो थ्रेसहोल्ड को पार करता है |
+| **मूल्यांकन स्कोर** | एक मूल्यांकनकर्ता स्कोर का औसत (कहें, मतिभ्रम) एक थ्रेसहोल्ड को पार करता है |
+| **यौगिक मूल्यांकन** | कई स्कोर जांचें any, all, या कम से कम-N तर्क के साथ संयोजित होते हैं, एक प्रतिगमन को पकड़ने के लिए जो केवल स्कोर में दिखाई देता है |
+| **प्रति ईवेंट** | एक एकल मिलान वाली ईवेंट आती है: एक विशिष्ट agent, एक विशिष्ट त्रुटि प्रकार, या एक संदेश सबस्ट्रिंग |
+
+पहले से ही [त्रुटि पृष्ठ](/hi/agenteye/error-tracking) पर एक विफलता को देख रहे हैं? वहां हर पंक्ति में एक **+ alert** बटन है जो इसी फॉर्म को खोलता है उस सटीक विफलता को पकड़ने के लिए पूर्वनिर्धारित, इसलिए घटना जिसे आपने अभी ट्रियेज किया वह वह है जो अगली बार आपको सूचित करती है।
+
+**इसे कहां खोजें:** Alerts `/<org-slug>/alerts` पर रहते हैं। नियम बनाना, संपादन, हटाना, और परीक्षण करना **`alerts:write`** की आवश्यकता है; `alerts:read` देखने के लिए पर्याप्त है। प्राप्तकर्ता पिकर आपके org के सदस्यों को नाम के अनुसार सूचीबद्ध करता है, इसलिए आप फॉर्म छोड़े बिना एक व्यक्ति को सूचित कर सकते हैं।
+
+## मुझे केवल तब सूचित करें जब यह वास्तविक हो
+
+एक खराब माप आपको नहीं जगाना चाहिए। **M of N** शोर फ़िल्टर नियंत्रित करता है कि सतर्कता वास्तव में आपको सूचित करने से पहले कितनी अंतिम कुछ जांचें विफल होनी चाहिए। इसे **3 of 5** पर सेट करें और नियम केवल तभी फायर करता है जब इसने अपनी अंतिम पाँच जांचों में से तीन का उल्लंघन किया हो, इसलिए एक अस्थिर संकेत झूठी अलर्ट बंद करता है; इसे डिफ़ॉल्ट **1 of 1** पर छोड़ें पहली बार उल्लंघन पर फायर करने के लिए। आप यह भी चुनते हैं कि नियम कितनी बार चलता है, 1m, 5m, 15m, और 1h के पूर्वनिर्धारित से, संकेत कितनी तेज़ी से चलता है इसके साथ मेल खाते हुए।
+
+## जब कोई सतर्कता फायर होती है तो क्या होता है
+
+एक उल्लंघन एक **घटना** खोलता है और आपके चैनलों को एक बार सूचित करता है। वहां से आपकी टीम इसे स्वीकार करती है, एक मालिक निर्दिष्ट करती है, इसके माध्यम से बात करती है, और इसे हल करती है, सब कुछ एक स्वच्छ, जिम्मेदार रिकॉर्ड के विरुद्ध। वह ट्रियेज वर्कफ़्लो का अपना घर है: [घटनाएं](/hi/agenteye/incidents) देखें।
+
+## संबंधित
+
+- [घटनाएं](/hi/agenteye/incidents): एक फायर की हुई सतर्कता को खुले से स्वीकृत से हल तक ट्रैक करें।
+- [त्रुटि ट्रैकिंग](/hi/agenteye/error-tracking): agent विफलताओं को समूहीकृत करें और एक क्लिक में एक को सतर्कता में प्रचार करें।
+- [डैशबोर्ड](/hi/agenteye/dashboards): साझा बोर्ड देखें जिन थ्रेसहोल्ड पर आप सतर्क होते हैं वे कहां से आते हैं।
+- [CLI और agents](/hi/agenteye/cli-and-agents): अपने टर्मिनल से सतर्कता बनाएं और घटनाओं को स्वीकार करें, या उन्हें CI में स्क्रिप्ट करें।

package/.next/standalone/docs-old/hi/agenteye/api-keys.mdx

@@ -0,0 +1,279 @@
+---
+title: "API कुंजियाँ"
+description: "API कुंजियाँ नियंत्रित करती हैं कि कौन और क्या आपके Failproof AI Observability सर्वर तक पहुँच सकता है, जिससे एक कलेक्टर कभी भी पढ़ने या व्यवस्थापक शक्तियों को प्राप्त किए बिना ईवेंट भेज सकता है।"
+---
+
+API कुंजियाँ नियंत्रित करती हैं कि कौन और क्या आपके Failproof AI Observability सर्वर तक पहुँच सकता है, जिससे एक कलेक्टर कभी भी पढ़ने या व्यवस्थापक शक्तियों को प्राप्त किए बिना ईवेंट भेज सकता है। प्रत्येक कुंजी एक या अधिक अनुमतियाँ रखती है, और प्रत्येक अनुमति विशिष्ट सर्वर रूट को नियंत्रित करती है; आप केवल वह अनुमतियाँ देते हैं जो एक कार्य को चाहिए। अधिकांश परिनियोजन केवल तीन प्रकार की कुंजियाँ बनाते हैं।
+
+## 3 कुंजियाँ जो अधिकांश परिनियोजन को चाहिए
+
+| कुंजी | अनुमतियाँ | इसका उपयोग कौन करता है |
+|---|---|---|
+| कलेक्टर कुंजी | `events:add` | प्रत्येक एजेंट मशीन पर `agenteye-collector`, ईवेंट भेजने के लिए। |
+| डैशबोर्ड पढ़ने की कुंजी | `events:read`, `keys:read` | केवल-पढ़ने वाला ऑपरेटर या एकीकरण जो डेटा को बिना बदले क्वेरी करता है। |
+| बूटस्ट्रैप व्यवस्थापक कुंजी | सभी अनुमतियाँ | ऑपरेटर जो पहली बार उदाहरण को चलाता है (और डैशबोर्ड)। `ADMIN_KEY` पर्यावरण चर से बीजित। [बूटस्ट्रैप व्यवस्थापक कुंजी](#bootstrap-admin-key) देखें। |
+
+यहाँ से शुरुआत करें। पूर्ण अनुमति सूची नीचे केवल तभी देखें जब आपको एक संकीर्ण, कस्टम-स्कोप की गई कुंजी चाहिए। [अनुशंसित कुंजी लेआउट](#recommended-key-layout) और [कुंजियाँ बनाना](#creating-keys) भी देखें।
+
+---
+
+## अनुमतियाँ
+
+सर्वर एक निश्चित अनुमतियों की सूची को लागू करता है; प्रत्येक विशिष्ट HTTP रूट को नियंत्रित करता है। एक **व्यवस्थापक कुंजी** उन सभी को रखती है; एक स्कोप की गई कुंजी उस सबसेट को रखती है जो आप निर्माण पर देते हैं। अज्ञात अनुमति स्ट्रिंग को अस्वीकार कर दिया जाता है जब एक कुंजी बनाई जाती है।
+
+> **नोट:** दो वैध अनुमतियाँ मानव/डैशबोर्ड-केवल हैं और एक API कुंजी को नहीं दी जा सकतीं: `orgs:admin` (उदाहरण प्रशासन, जो केवल ऑपरेटर के लिए है) और `keys:update`। `POST /keys` या `PATCH /keys/:id` के लिए एक अनुरोध जो इनमें से किसी एक को देने का प्रयास करता है HTTP 422 से अस्वीकार कर दिया जाता है। `keys:update` पंक्ति देखें कि क्यों एक वाहक कुंजी कुंजियाँ बना सकती है लेकिन कभी संपादित नहीं कर सकती।
+
+### ईवेंट अंतर्ग्रहण और क्वेरी
+
+| अनुमति | HTTP रूट | यह क्या अनुमति देता है |
+|---|---|---|
+| `events:add` | `POST /events` | एक कलेक्टर से ईवेंट के बैच को अंतर्ग्रहण करें। एकमात्र अनुमति जो एक कलेक्टर को चाहिए। |
+| `events:read` | `GET /events`, `GET /events/latency_aggregate`, `GET /events/environments`, `GET /events/models`, `GET /sessions/:session_id/export` | ईवेंट को क्वेरी करें, ज्ञात वातावरणों की सूची बनाएँ, डेटा में देखे गए मॉडल पहचानकर्ताओं की सूची बनाएँ (मॉडल दृश्य और मॉडल फ़िल्टर द्वारा उपयोग), अव्यवस्थित समन्वय की गणना करें जो ताप-मानचित्र / प्रतिशतक बैंड को शक्ति देता है, और एक सत्र को JSONL के रूप में निर्यात करें। साझा फ़िल्टर-बार पहलू अंतिम बिंदु `GET /events/environments` और `GET /events/agent_ids` **या तो** `events:read` **या** `evaluations:read` के साथ पहुँचने योग्य हैं, इसलिए सत्र पृष्ठ (द्वार `evaluations:read`) समान प्रति-ऑर्ग पहलू का पुन: उपयोग करता है। `GET /events/models` उनमें से एक नहीं है: इसे `events:read` की आवश्यकता है, इसलिए केवल `evaluations:read` रखने वाला एक प्रिंसिपल इससे 403 प्राप्त करता है। |
+
+### सत्र और मूल्यांकन
+
+| अनुमति | HTTP रूट | यह क्या अनुमति देता है |
+|---|---|---|
+| `evaluations:read` | `GET /sessions`, `GET /evaluations`, `GET /evaluations/aggregate`, `GET /evaluations/environments`, `GET /evaluation-jobs` | सत्रों की सूची बनाएँ, मूल्यांकन परिणाम पढ़ें, डैशबोर्ड द्वारा उपयोग की जाने वाली रोल-अप मूल्यांकन स्वास्थ्य, और मूल्यांकन-कार्य कार्यकर्ता कतार स्थिति। |
+| `evaluations:trigger` | `POST /sessions/:session_id/re-evaluate` | एक समाप्त सत्र के लिए पुन: मूल्यांकन को मैन्युअल रूप से कतार में डालें। |
+
+### डैशबोर्ड
+
+| अनुमति | HTTP रूट | यह क्या अनुमति देता है |
+|---|---|---|
+| `dashboards:read` | `GET /dashboards`, `GET /dashboards/:id`, `GET /dashboards/:id/tiles` | डैशबोर्ड की सूची बनाएँ, एक को लोड करें, और इसकी टाइलें पढ़ें। |
+| `dashboards:write` | `POST /dashboards`, `PUT /dashboards/:id`, `POST /dashboards/:id/tiles`, `PUT /dashboards/:id/tiles/:tile_id`, `DELETE /dashboards/:id/tiles/:tile_id`, `PUT /dashboards/:id/tiles/layout` | डैशबोर्ड बनाएँ और संपादित करें, टाइलें जोड़ें / संपादित करें / हटाएँ, और टाइल ग्रिड को पुन: क्रमबद्ध करें। |
+| `dashboards:delete` | `DELETE /dashboards/:id` | एक संपूर्ण डैशबोर्ड हटाएँ (टाइल-स्तर का विलोपन `dashboards:write` के तहत रहता है)। |
+
+### सहेजी गई क्वेरीज़ (SQL संगीतकार)
+
+| अनुमति | HTTP रूट | यह क्या अनुमति देता है |
+|---|---|---|
+| `queries:read` | `GET /queries`, `GET /queries/:id`, `GET /queries/schema` | सहेजी गई क्वेरीज़ की सूची बनाएँ, एक को लोड करें, और संगीतकार लक्ष्य के केवल-पढ़ने वाले स्कीमा का निरीक्षण करें। |
+| `queries:write` | `POST /queries`, `PUT /queries/:id` | सहेजी गई क्वेरीज़ बनाएँ और संपादित करें। SQL अभी भी `queries:run` कॉल के समान केवल-पढ़ने वाली भूमिका के माध्यम से दिया जाता है और संरक्षित SQL जांच द्वारा संरक्षित है। |
+| `queries:delete` | `DELETE /queries/:id` | एक सहेजी गई क्वेरी हटाएँ। |
+| `queries:run` | `POST /queries/run` | संगीतकार द्वारा उपयोग की जाने वाली केवल-पढ़ने वाली भूमिका के विरुद्ध सहेजी गई या तदर्थ SQL को निष्पादित करें। |
+
+### AI सहायक
+
+| अनुमति | HTTP रूट | यह क्या अनुमति देता है |
+|---|---|---|
+| `agent:use` | `GET /agent/conversations`, `POST /agent/conversations`, `GET /agent/conversations/:id`, `PATCH /agent/conversations/:id`, `DELETE /agent/conversations/:id`, `PUT /agent/conversations/:id/messages` | AI सहायक से बात करें और अपनी स्वयं की (निजी) बातचीत का प्रबंधन करें। सहायक डॉक देखने के लिए **उपयोगकर्ता** पर आवश्यक; सहायक की अपनी कुंजी `dashboard-assistant` है और अलग से बीजित है (नीचे देखें)। |
+
+### API कुंजियाँ
+
+| अनुमति | HTTP रूट | यह क्या अनुमति देता है |
+|---|---|---|
+| `keys:create` | `POST /keys` | एक नई स्कोप की गई API कुंजी बनाएँ। मौजूदा कुंजी की अनुमतियों को संपादित करने के लिए **नहीं** देता है (वह `keys:update` है)। |
+| `keys:read` | `GET /keys` | मौजूदा कुंजियों की सूची बनाएँ। गोपनीयताएँ कभी भी इस अंतिम बिंदु द्वारा नहीं दी जाती हैं। |
+| `keys:update` | `PATCH /keys/:id` | मौजूदा कुंजी की अनुमतियों को संपादित करें। एक **मानव/डैशबोर्ड-केवल** अनुमति; इसे एक API कुंजी को असाइन नहीं किया जा सकता (एक वाहक कुंजी कुंजियाँ बना सकती है लेकिन उन्हें कभी संपादित नहीं कर सकती)। |
+| `keys:disable` | `POST /keys/:id/disable` | एक कुंजी को रद्द करें। संरक्षित कुंजियाँ (`admin`, `dashboard-assistant`) को अक्षम नहीं किया जा सकता; env var + पुनः आरंभ के माध्यम से उन्हें घुमाएँ। |
+| `keys:regenerate` | `POST /keys/:id/regenerate` | एक कुंजी की गोपनीयता को घुमाएँ। संरक्षित कुंजियों को इस रूट के माध्यम से पुन: निर्मित नहीं किया जा सकता। |
+
+### डैशबोर्ड उपयोगकर्ता
+
+| अनुमति | HTTP रूट | यह क्या अनुमति देता है |
+|---|---|---|
+| `users:create` | `POST /users`, `GET /users/defaults` | एक नए डैशबोर्ड उपयोगकर्ता को आमंत्रित करें (एक ईमेल + एकबारगी पासकोड (OTP) लॉगिन जारी करता है) और डैशबोर्ड-कॉन्फ़िगर की गई डिफ़ॉल्ट अनुमति सेट पढ़ें जो आमंत्रण फॉर्म को बीजित करने के लिए उपयोग किया जाता है। |
+| `users:read` | `GET /users`, `GET /users/:id` | उपयोगकर्ताओं की सूची बनाएँ और एक एकल उपयोगकर्ता रिकॉर्ड लोड करें। |
+| `users:update` | `PUT /users/:id` | एक उपयोगकर्ता की अनुमतियों को संपादित करें। अपडेट प्रभावित उपयोगकर्ता को अनुमति-परिवर्तन ईमेल भेजते हैं और उनके अगले अनुरोध पर प्रभावी होते हैं; कोई पुन: लॉगिन आवश्यक नहीं। |
+| `users:delete` | `DELETE /users/:id`, `POST /users/:id/enable` | एक उपयोगकर्ता को अक्षम करें (उनके सत्र को तुरंत रद्द करता है) और पहले से अक्षम उपयोगकर्ता को पुन: सक्षम करें। |
+
+ये अनुमतियाँ डैशबोर्ड के **उपयोगकर्ता** पृष्ठ को समर्थन देती हैं, जहाँ प्रत्येक सदस्य के दिए गए दायरे चिप्स के रूप में दिखाए जाते हैं:
+
+![उपयोगकर्ता पृष्ठ: प्रत्येक डैशबोर्ड उपयोगकर्ता के लिए एक कार्ड उनके ईमेल, दी गई अनुमतियों, और संपादन/अक्षम नियंत्रण के साथ](/agenteye/images/users.png)
+
+### परिचालन सेटिंग्स
+
+| अनुमति | HTTP रूट | यह क्या अनुमति देता है |
+|---|---|---|
+| `settings:read` | `GET /settings`, `GET /settings/schema`, `GET /settings/model-context-windows`, `GET /settings/model-context-windows/resolve` | डैशबोर्ड-प्रबंधित परिचालन सेटिंग्स और उनके मेटाडेटा को देखें; प्रति-मॉडल संदर्भ-विंडो ओवरराइड की सूची बनाएँ; और एक मॉडल के लिए प्रभावी विंडो को हल करें। |
+| `settings:write` | `PUT /settings/:key`, `PUT /settings/model-context-windows`, `DELETE /settings/model-context-windows` | परिचालन सेटिंग्स को संपादित करें और प्रति-मॉडल संदर्भ-विंडो ओवरराइड को जोड़ें, बदलें, या हटाएँ। परिवर्तन सर्वर को पुनः आरंभ किए बिना नई ईवेंट को प्रभावित करते हैं। |
+
+![सेटिंग्स पृष्ठ: डैशबोर्ड-प्रबंधित परिचालन सेटिंग्स जैसे अनुमति दी गई साइन-इन और सत्र/OTP जीवनकाल, पुनः आरंभ के बिना संपादन योग्य](/agenteye/images/settings.png)
+
+### अलर्ट और घटनाएँ
+
+| अनुमति | HTTP रूट | यह क्या अनुमति देता है |
+|---|---|---|
+| `alerts:read` | `GET /alerts`, `GET /alerts/:id` | कॉन्फ़िगर किए गए अलर्ट परिभाषाओं को देखें। |
+| `alerts:write` | `POST /alerts`, `PUT /alerts/:id`, `DELETE /alerts/:id`, `POST /alerts/:id/test` | अलर्ट परिभाषाओं को बनाएँ, संपादित करें, हटाएँ, और परीक्षण-फायर करें। |
+| `incidents:read` | `GET /alerts/incidents`, `GET /alerts/incidents/:iid`, `GET /alerts/incidents/:iid/comments`, `GET /alerts/incidents/:iid/subscribers` | घटनाओं और उनके ट्रिएज ट्रेल को देखें। |
+| `incidents:write` | `POST /alerts/:id/incidents` | एक मौजूदा अलर्ट के विरुद्ध मैन्युअल रूप से एक घटना खोलें। |
+| `incidents:ack` | `POST /alerts/incidents/:iid/ack`, `POST /alerts/incidents/:iid/assign`, `POST /alerts/incidents/:iid/resolve`, `POST /alerts/incidents/:iid/comments`, `POST /alerts/incidents/:iid/subscribe`, `POST /alerts/incidents/:iid/unsubscribe` | घटनाओं को स्वीकार करें, असाइन करें, हल करें, और उन पर टिप्पणी करें। |
+
+### ऑडिट
+
+| अनुमति | HTTP रूट | यह क्या अनुमति देता है |
+|---|---|---|
+| `audits:read` | `GET /audits`, `GET /audits/:id`, `GET /audits/:id/runs`, `GET /audits/findings`, `GET /audits/findings/:fid` | ऑडिट परिभाषाओं, चलाने का इतिहास, और निष्कर्ष देखें। |
+| `audits:write` | `POST /audits`, `PUT /audits/:id`, `DELETE /audits/:id`, `POST /audits/:id/run`, `POST /audits/findings/:fid/status` | ऑडिट बनाएँ, संपादित करें, हटाएँ, और चलाएँ; निष्कर्षों को ट्रिएज करें (स्वीकार करें / म्यूट करें / खारिज करें / हल करें / फिर से खोलें / असाइन करें)। |
+
+> **नोट:** एक कुंजी को ऑडिट सतह देने के लिए, इसे `audits:*` को स्पष्ट रूप से दें। [अपग्रेड और बैकवर्ड-संगतता नोट्स](#upgrade-and-backward-compatibility-notes) देखें कि जब ऑडिट आया तो मौजूदा अनुदानकर्ताओं को कैसे माइग्रेट किया गया।
+
+> प्राप्तकर्ता-पिकर अंतिम बिंदु `GET /alerts/recipients` (जो सदस्य ईमेल सूचीबद्ध करता है एक अलर्ट संपादक को सूचित कर सकता है) **या तो** `alerts:read` **या** `alerts:write` के धारक द्वारा पहुँचने योग्य है, इसलिए अलर्ट संपादक बिना `users:read` को दिए गए पिकर को पॉप्युलेट कर सकते हैं।
+
+> एक डैशबोर्ड दर्शक को **दोनों** `dashboards:read` (सहेजे गए दृश्यों को लोड करने के लिए) और `evaluations:read` (स्वास्थ्य मेट्रिक्स मूल्यांकन डेटा से गणना की जाती हैं) की आवश्यकता होती है। डैशबोर्ड बनाने या संपादित करने देने के लिए `dashboards:write` दें, और उन्हें हटाने के लिए `dashboards:delete` दें।
+
+> `/health` और `/auth/*` (OTP अनुरोध, OTP सत्यापन, सत्र जांच, लॉगआउट) डिज़ाइन द्वारा प्रमाणीकृत नहीं हैं; वे लॉगिन प्रवाह और जीविता जांच हैं। `GET /access-granters` एक वैध कुंजी की आवश्यकता है लेकिन कोई विशिष्ट अनुमति नहीं, इसलिए कोई भी लॉगिन उपयोगकर्ता देख सकता है कि किन व्यवस्थापकों से संपर्क करना है।
+
+---
+
+## अनुमति सेट
+
+अनुमति सेट आपको प्रत्येक बार व्यक्तिगत टोकन को चुनने के बजाय एक नामित भूमिका को लागू करने देते हैं। प्रत्येक नए डैशबोर्ड उपयोगकर्ता या API कुंजी के लिए एक दर्जन अनुमतियों को एक-एक करके चुनने के बजाय, आप एक सेट चुनते हैं, और हर कोई इसे असाइन किया गया एक सुसंगत, समीक्षक अनुदान रखता है। एक कस्टम सेट को संपादित करने से पहले से ही इसे असाइन किए गए हर उपयोगकर्ता को नई अनुदान को पुन: लागू किया जाता है, इसलिए एक भूमिका परिवर्तन एक संपादन है बजाय हर सदस्य के माध्यम से एक स्वीप।
+
+हर संगठन को तीन अंतर्निहित सेट के साथ बीजित किया जाता है:
+
+| सेट | अनुमतियाँ | के लिए इरादा |
+|---|---|---|
+| `read-only` | `events:read`, `keys:read`, `users:read`, `evaluations:read`, `dashboards:read`, `queries:read`, `settings:read`, `alerts:read`, `audits:read`, `incidents:read` | हर परिचालन सतह में केवल-दृश्य पहुँच। |
+| `standard` | `read-only` में सब कुछ, प्लस `evaluations:trigger`, `queries:run`, `incidents:ack`, `agent:use` | केवल-पढ़ें प्लस रोज़मर्रा के ऑन-कॉलर कार्य: क्वेरीज़ चलाएँ, सत्रों को पुन: मूल्यांकन करें, घटनाओं को स्वीकार करें, और AI सहायक का उपयोग करें। |
+| `admin` | हर असाइन करने योग्य अनुमति | ऑर्ग का पूर्ण नियंत्रण। |
+
+तीन अंतर्निहित सेट **अपरिवर्तनीय** हैं; उनके नाम हमेशा समान बात का मतलब रखते हैं, इसलिए `read-only`, `standard`, और `admin` नीति और ऑनबोर्डिंग में संदर्भित करना सुरक्षित है। एक ऑपरेटर आपके संगठन के लिए विशिष्ट भूमिकाओं को मॉडल करने के लिए अतिरिक्त **कस्टम सेट** बना सकता है (उदाहरण के लिए, एक "डैशबोर्ड लेखक" भूमिका या एक "कलेक्टर-केवल" भूमिका)।
+
+सेट डैशबोर्ड में सतह पर आते हैं और `GET /permission-sets` पर API के माध्यम से प्रबंधित होते हैं (सूची, `users:read` द्वारा द्वारपाल) और `POST /permission-sets` / `PUT /permission-sets/:name` / `DELETE /permission-sets/:name` (कस्टम सेट बनाएँ, संपादित करें, हटाएँ, `settings:write` द्वारा द्वारपाल)। अंतर्निहित सेट को हटाना या संपादित करना अस्वीकार कर दिया जाता है।
+
+सेट सदस्यता दो अन्य सुविधाओं को समर्थन देता है:
+
+- **`DEFAULT_USER_PERMISSIONS`** (जब एक व्यवस्थापक **+ नया उपयोगकर्ता** खोलता है तो पूर्व-चयनित अनुदान) डिफ़ॉल्ट `standard` सेट के लिए।
+- **`--set` फ़्लैग** `agenteye-orgctl` पर (ऑपरेटर सदस्य प्रबंधन) एक सदस्य को एक नामित सेट से शुरू करता है, जिसे आप फिर `--add` / `--remove` के साथ ठीक-ट्यून करते हैं।
+
+> **नोट:** जब एक सेट एक अनुमति को शामिल करता है जो कुंजी-असाइन करने योग्य नहीं है (उदाहरण के लिए `keys:update` रखने वाला कस्टम सेट), उस सेट से एक कुंजी को बीजित करने से गैर-असाइन करने योग्य टोकन को छोड़ दिया जाता है; सर्वर अन्यथा HTTP 422 से कुंजी को अस्वीकार कर देगा। डैशबोर्ड **उपयोगकर्ता** उस प्रतिबंध के अधीन नहीं हैं।
+
+---
+
+## बूटस्ट्रैप व्यवस्थापक कुंजी
+
+व्यवस्थापक कुंजी एकल मूल क्रेडेंशियल है जो एक ऑपरेटर को कुछ भी नहीं से एक्सेस को लाया जा सकता है: इसके साथ आप हर अन्य स्कोप की गई कुंजी को टकसाली कर सकते हैं, पहले डैशबोर्ड उपयोगकर्ताओं को आमंत्रित कर सकते हैं, और किसी भी अन्य कुंजी अस्तित्व से पहले उदाहरण को कॉन्फ़िगर कर सकते हैं। यह एकमात्र कुंजी है जो आप कुंजी API के माध्यम से नहीं बनाते हैं; इसे पर्यावरण से प्रदान किया जाता है इसलिए सर्वर पहले बूट पर पहुँचने योग्य है।
+
+सर्वर पर `ADMIN_KEY` पर्यावरण चर सेट करें। हर स्टार्टअप पर सर्वर इस मान को एक व्यवस्थापक कुंजी के रूप में सभी अनुमतियों के साथ अपसर्ट करता है।
+
+घुमाने के लिए: `ADMIN_KEY` को एक नई गोपनीयता में बदलें और सर्वर को पुनः आरंभ करें।
+
+---
+
+## संगठन स्कोपिंग
+
+**संगठन स्वयं ऑपरेटर द्वारा बैंड से बाहर बनाए और प्रबंधित किए जाते हैं, इस कुंजी API के माध्यम से नहीं।** ऑर्ग और सदस्य जीवनचक्र (एक ऑर्ग बनाएँ / नाम दें / हटाएँ / शुद्ध करें; एक सदस्य जोड़ें / अपडेट करें / हटाएँ) **`agenteye-orgctl`** CLI के साथ किया जाता है; इसके लिए कोई HTTP API या डैशबोर्ड बटन नहीं है। क्या *अपरिवर्तित है*: **प्रति-ऑर्ग API कुंजियाँ अभी भी डैशबोर्ड में टकसाली होती हैं (या इस कुंजी API के माध्यम से)** ऑर्ग सदस्यों द्वारा।
+
+एक मल्टी-ऑर्ग परिनियोजन में, हर कुंजी एक ऑर्ग सदस्य बनाता है (इस कुंजी API या डैशबोर्ड **कुंजियाँ** पृष्ठ के माध्यम से) **एक संगठन** के अंतर्गत आता है और केवल कभी भी उस ऑर्ग के डेटा को पढ़ या लिख सकता है; ऑर्ग निर्माण पर कुंजी पर स्टैम्प किया जाता है और हर अनुरोध पर लागू किया जाता है। दो बूटस्ट्रैप कुंजियाँ एकमात्र अपवाद हैं: `admin` कुंजी (`ADMIN_KEY` से बीजित) और `dashboard-assistant` कुंजी (`AGENT_API_KEY` से बीजित) **उदाहरण-स्कोप किए गए** हैं (वे कोई ऑर्ग नहीं रखते हैं)। डैशबोर्ड `admin` कुंजी के साथ प्रमाणीकरण करता है इसलिए यह हस्ताक्षरित सदस्यों की ओर से प्रति-ऑर्ग अनुरोधों को प्रॉक्सी कर सकता है। एकल-किरायेदार परिनियोजन को इसके बारे में सोचना पड़ता है नहीं; सभी कुंजियाँ अंतर्निहित `default` ऑर्ग के अंतर्गत आती हैं।
+
+---
+
+## कुंजियाँ बनाना
+
+व्यवस्थापक कुंजी (या `keys:create` अनुमति रखने वाली किसी भी कुंजी) का उपयोग करके अतिरिक्त स्कोप की गई कुंजियाँ बनाएँ।
+
+### कलेक्टर कुंजी (केवल अंतर्ग्रहण)
+
+```bash
+curl -s -X POST http://your-server/keys \
+  -H "Authorization: Bearer $ADMIN_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "name": "prod-collector",
+    "key": "your-collector-secret",
+    "permissions": ["events:add"]
+  }'
+```
+
+### डैशबोर्ड कुंजी (केवल पढ़ें)
+
+```bash
+curl -s -X POST http://your-server/keys \
+  -H "Authorization: Bearer $ADMIN_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "name": "dashboard",
+    "key": "your-dashboard-secret",
+    "permissions": ["events:read", "keys:read"]
+  }'
+```
+
+जब आप HTTP API पर एक कुंजी बनाते हैं, तो आप स्वयं `key` मान प्रदान करते हैं; एक मजबूत गोपनीयता चुनें और इसे सुरक्षित रूप से स्टोर करें। (डैशबोर्ड दूसरे तरीके से काम करता है: यह आपके लिए एक मजबूत गोपनीयता उत्पन्न करता है और निर्माण पर इसे एक बार दिखाता है; [डैशबोर्ड में कुंजी प्रबंधन](#key-management-in-the-dashboard) देखें।) प्रतिक्रिया की पुष्टि करती है कि कुंजी बनाई गई थी:
+
+```json
+{
+  "id": "550e8400-e29b-41d4-a716-446655440000",
+  "name": "prod-collector",
+  "permissions": ["events:add"],
+  "created_at": "2026-04-01T12:00:00Z"
+}
+```
+
+---
+
+## कुंजियों की सूची बनाना
+
+```bash
+curl -s http://your-server/keys \
+  -H "Authorization: Bearer $ADMIN_KEY"
+```
+
+कुंजी गोपनीयताएँ सूची प्रतिक्रिया में नहीं लौटाई जाती हैं, केवल IDs, नाम, और अनुमतियाँ।
+
+---
+
+## एक कुंजी को अक्षम करना
+
+अक्षम करना कुंजी रिकॉर्ड को हटाए बिना तुरंत एक्सेस को रद्द करता है।
+
+```bash
+curl -s -X POST http://your-server/keys/<id>/disable \
+  -H "Authorization: Bearer $ADMIN_KEY"
+```
+
+---
+
+## एक कुंजी को पुन: उत्पन्न करना
+
+एक मौजूदा कुंजी के लिए एक नई गोपनीयता उत्पन्न करता है। पुरानी गोपनीयता तुरंत अमान्य कर दी जाती है।
+
+```bash
+curl -s -X POST http://your-server/keys/<id>/regenerate \
+  -H "Authorization: Bearer $ADMIN_KEY"
+```
+
+प्रतिक्रिया में नई सादा पाठ गोपनीयता शामिल है, **केवल एक बार दिखाई दी**।
+
+---
+
+## डैशबोर्ड में कुंजी प्रबंधन
+
+डैशबोर्ड में **कुंजियाँ** पृष्ठ उपरोक्त सभी कार्यों के लिए एक UI प्रदान करता है। सूची को देखने के लिए आपको `keys:read` अनुमति के साथ एक कुंजी चाहिए, और क्रमशः निर्माण / संपादन / अक्षम / पुन: उत्पन्न कार्यों के लिए `keys:create` / `keys:update` / `keys:disable` / `keys:regenerate`। एक कुंजी की अनुमतियों को संपादित करना (`keys:update`) एक बनाने (`keys:create`) से अलग है, इसलिए आप एक ऑपरेटर को कुंजियों को टकसाली करने की क्षमता दे सकते हैं बिना मौजूदा कुंजियों को पुन: स्कोप करने की क्षमता के, या इसके विपरीत। व्यवस्थापक कुंजी इन सभी को कवर करती है।
+
+जब आप डैशबोर्ड से एक कुंजी बनाते हैं तो आप गोपनीयता की आपूर्ति नहीं करते हैं; डैशबोर्ड आपके लिए एक मजबूत गोपनीयता उत्पन्न करता है और इसे **एक बार** निर्माण पर प्रदर्शित करता है। इसे तुरंत कॉपी करें और सुरक्षित रूप से स्टोर करें; यह कभी फिर से दिखाया नहीं जाता है, एक पुन: उत्पन्न के समान ही। आप अभी भी कुंजी की अनुमतियों को सीधे चुन सकते हैं, या एक अनुमति सेट से उन्हें बीजित कर सकते हैं (नीचे देखें)।
+
+![API कुंजियाँ पृष्ठ: प्रत्येक कुंजी के लिए एक कार्ड इसके नाम, दी गई अनुमतियों, और निर्माण समय के साथ, पुन: उत्पन्न और अक्षम कार्य; `admin` जैसी संरक्षित कुंजियाँ चिह्नित हैं](/agenteye/images/api-keys.png)
+
+---
+
+## अनुशंसित कुंजी लेआउट
+
+| कुंजी | अनुमतियाँ | का उपयोग कौन करता है |
+|---|---|---|
+| `admin` (`ADMIN_KEY` env var के माध्यम से बूटस्ट्रैप) | सभी | Ops/सेटअप, और डैशबोर्ड (`ADMIN_KEY` के साथ प्रमाणीकरण, अनुमति जांच के साथ उपयोगकर्ता अनुरोधों को प्रॉक्सी) |
+| प्रति-होस्ट कलेक्टर कुंजी | `events:add` | प्रत्येक एजेंट मशीन पर कलेक्टर |
+| `dashboard-assistant` (`AGENT_API_KEY` env var के माध्यम से बूटस्ट्रैप) | `events:read`, `evaluations:read`, `dashboards:read`, `dashboards:write`, `queries:read`, `queries:write`, `queries:run` | AI सहायक, स्वचालित रूप से बीजित, **संरक्षित**; API के माध्यम से संपादित नहीं किया जा सकता |
+| सहायक टेलीमेट्री कुंजी (वैकल्पिक) | `events:add` | AI सहायक आत्म-प्रवृत्तिकरण, यदि सक्षम है |
+
+> **नोट:** सहायक की कुंजी **स्वचालित रूप से बीजित** की जाती है सर्वर द्वारा `AGENT_API_KEY` env var से (वही गोपनीयता जो एजेंट `AGENTEYE_API_KEY` के रूप में प्रस्तुत करता है); कोई मैन्युअल कुंजी-मिंटिंग चरण नहीं है और कोई व्यवस्थापक कुंजी शामिल नहीं है। इसकी अनुमतियाँ स्रोत कोड में तय की जाती हैं इसलिए स्कोप को गलतफहमी से व्यापक नहीं किया जा सकता: ईवेंट / मूल्यांकन / डैशबोर्ड में पढ़ें, प्लस डैशबोर्ड-लेखन और क्वेरीज-पढ़ें / लिखें / चलाएँ AI से क्वेरी लिखने के लिए कहने के लिए। सभी SQL अभी भी उसी केवल-पढ़ने वाली भूमिका और संरक्षित SQL पथ के माध्यम से जाता है एक उपयोगकर्ता-लिखी गई क्वेरी के रूप में, इसलिए यह *लेखन सतह* को व्यापक करता है, डेटा सतह नहीं; विनाशकारी कार्य (`queries:delete`, `dashboards:delete`) जानबूझकर सहायक कुंजी से दूर रहते हैं। `admin` कुंजी की तरह, यह **संरक्षित** है: इसे कुंजी API के माध्यम से अक्षम या पुन: उत्पन्न नहीं किया जा सकता, केवल `AGENT_API_KEY` को बदलकर और पुनः आरंभ करके घुमाया जा सकता है। डैशबोर्ड **उपयोगकर्ता** अतिरिक्त रूप से सहायक को देखने और उपयोग करने के लिए `agent:use` अनुमति की आवश्यकता होती है। यदि आप आत्म-प्रवृत्तिकरण सक्षम करते हैं, तो सहायक को एक अलग `events:add`-केवल कुंजी दें।
+
+---
+
+## अपग्रेड और बैकवर्ड-संगतता नोट्स
+
+आपको इन्हीं की आवश्यकता है यदि आप एक मौजूदा उदाहरण को अपग्रेड कर रहे हैं; नई परिनियोजन इन्हें छोड़ सकती है।
+
+> जब ऑडिट आया, मौजूदा अनुदानकर्ताओं को अलर्ट के समान भूमिका आकार के साथ व्यापक किया गया: हर उपयोगकर्ता और `alerts:read` रखने वाली अनुमति सेट `audits:read` प्राप्त की, और `alerts:write` के हर धारक को `audits:write` मिला। मौजूदा API कुंजियों को **नहीं** व्यापक किया गया। यदि इसे ऑडिट सतह चाहिए तो एक कुंजी को स्पष्ट रूप से `audits:*` दें।
+
+> विरासत `alerts:ack` टोकन के भंडारीकृत अनुदान `incidents:ack` के रूप में पार्स किए जाते हैं इसलिए ऑन-कॉलर पुनः कीइंग के बिना एक्सेस को बनाए रखते हैं। टोकन अब डैशबोर्ड के उपयोगकर्ता संपादक से असाइन करने योग्य नहीं है; मैट्रिक्स `incidents:ack` की पेशकश करता है।
+
+---
+
+## अगले कदम
+
+- [Python SDK](/hi/agenteye/python-sdk): कैसे आपका एजेंट कोड प्रमाणीकृत होता है जब ईवेंट भेज रहा हो।
+- [सुरक्षा](/hi/agenteye/security): साइन-इन, एक्सेस नियंत्रण, और प्रति-संगठन डेटा अलगाव कैसे काम करता है।

package/.next/standalone/docs-old/hi/agenteye/assistant.mdx

@@ -0,0 +1,63 @@
+---
+title: "AI सहायक"
+description: "अपने एजेंट डेटा से सामान्य अंग्रेजी में प्रश्न पूछें और ऐसा उत्तर प्राप्त करें जो सीधे साक्ष्य से जुड़ा हो।"
+---
+
+
+अपने एजेंट डेटा से सामान्य अंग्रेजी में प्रश्न पूछें और ऐसा उत्तर प्राप्त करें जो सीधे साक्ष्य से जुड़ा हो। कोई SQL लिखने की आवश्यकता नहीं, डैशबोर्ड को खोदने की जरूरत नहीं — **Failproof AI Observability** सहायक आपकी टीम के किसी भी सदस्य के लिए एजेंट्स के बारे में उत्तर पाने का सबसे तेज तरीका है।
+
+![Failproof AI Observability सहायक डैशबोर्ड के अंदर एक सामान्य-अंग्रेजी प्रश्न का उत्तर दे रहा है, जो एक लाइव एजेंट एक्टिविटी टेबल, प्रति-एजेंट मॉडल-उपयोग विभाजन और लिखित निष्कर्ष दिखा रहा है, जिसमें यह दिखाए गए क्वेरीज इनलाइन हैं](/agenteye/images/assistant.png)
+*सामान्य अंग्रेजी में पूछें और अपने स्वयं के डेटा से बनाया गया उत्तर प्राप्त करें। यहां यह दिखाता है कि कौन से एजेंट सबसे व्यस्त हैं और वे किन मॉडल का उपयोग करते हैं, और यह दिखाता है कि यह किन क्वेरीज को चलाता है ताकि आप प्रत्येक संख्या को सत्यापित कर सकें।*
+
+सीखने के लिए कुछ नहीं है। चैट खोलें, टाइप करें कि आप क्या जानना चाहते हैं, और इसके द्वारा दिए गए लिंक का पालन करें:
+
+```
+You:  which sessions errored today?
+AI:   5 sessions errored today, newest first. Each one is linked:
+      • checkout-agent   14:02   tool timeout
+      • billing-agent    11:47   unhandled error
+      • ...and 3 more
+
+You:  summarize this session          (asked while viewing a run)
+AI:   This run took 12 steps across 3 tools and failed near the end when a
+      payment tool returned an error. It scored low on your "resolved" eval.
+      Links: the session, the failing event, and that evaluation.
+```
+
+## बस पूछें और सीधे प्रमाण पर जाएं
+
+आप अनुमान लगाना बंद करते हैं और आप क्वेरीज लिखना बंद करते हैं। पूछें "इस सप्ताह प्रोड में गुणवत्ता कैसी है?", "आज कौन से सेशन एरर हुए?", या "इस सेशन को सारांशित करें", और आप सेकंड में सीधा उत्तर पाते हैं, क्वेरी बनाने और स्वयं पढ़ने के बजाय।
+
+हर उत्तर अपनी रसीद के साथ आता है। सहायक सटीक सेशन, सहेजी गई क्वेरीज, और डैशबोर्ड को जोड़ता है जिसका यह उत्तर तक पहुंचने के लिए उपयोग करता है, ताकि आप क्लिक करके पुष्टि कर सकें और इसके शब्दों पर विश्वास न करें। यह **पृष्ठ-सचेत** भी है: किसी एक को देखते समय "इस सेशन" के बारे में पूछें और यह पहले से ही जानता है कि आप कौन सा रन मतलब हैं। बाद में इतिहास स्विचर से किसी भी पहली बातचीत को फिर से खोलें और वहीं से जहां आप छोड़ गए थे, आगे बढ़ें।
+
+## एक अच्छे उत्तर को सहेजी गई क्वेरी या डैशबोर्ड में परिणत करें
+
+जब कोई उत्तर संरक्षण योग्य हो, तो सहायक को इसे सहेजने के लिए कहें। यह एक सहेजी गई क्वेरी के लिए SQL का मसौदा तैयार करता है, या उन क्वेरीज से एक डैशबोर्ड को असेंबल करता है, फिर आपको एक **अनुमोदित करें / अस्वीकार करें** कार्ड दिखाता है। जब तक आप अनुमोदित करें पर क्लिक नहीं करते, तब तक कुछ नहीं लिखा जाता है, तो आप "बस पूछें" की गति पाते हैं और अंतिम शब्द हमेशा आपका होता है।
+
+**Queries** पेज पर यह एक कदम आगे जाता है और एक SQL लेखक बन जाता है: उस क्वेरी का वर्णन करें जो आप चाहते हैं ("पिछले 7 दिनों के लिए एजेंट द्वारा त्रुटि दर दिखाएं") और यह SQL को सीधे संपादक में स्ट्रीम करता है, एक अंतर दृश्य खोलता है ताकि आप **स्वीकार करें** या **अस्वीकार करें** परिवर्तन से पहले यह चेक कर सकें।
+
+![Observability Queries पृष्ठ और इसका SQL संपादक](/agenteye/images/query-lab.png)
+*Queries पृष्ठ: यह संपादक वह स्थान है जहां सहायक एक मसौदा, केवल-पठन योग्य क्वेरी स्ट्रीम करता है ताकि आप स्वीकार या अस्वीकार कर सकें।*
+
+यहां SQL लेखन करना `queries:run` अनुमति का उपयोग करता है, जो संपादक के **Run** बटन के पीछे भी है। अन्य जगह चैट करने के लिए `agent:use` की आवश्यकता है।
+
+## पूरी टीम को सौंपने के लिए सुरक्षित
+
+आप सहायक को सभी के लिए खोल सकते हैं बिना चिंता किए कि यह क्या स्पर्श कर सकता है:
+
+- **यह केवल वही पढ़ता है जो आप पहले से देख सकते हैं।** उत्तर आपकी स्वयं की पढ़ने की अनुमतियों के दायरे में हैं, तो यह कभी भी आपकी डेटा सतह को नहीं बढ़ाता।
+- **हर लेखन आपके लिए प्रतीक्षा करता है।** सहेजी गई क्वेरीज और डैशबोर्ड केवल आपकी स्पष्ट अनुमोदन क्लिक के बाद बनाए जाते हैं, और कोई सेटिंग नहीं है जो उस गेट को बंद करता है।
+- **यह कभी भी कुछ नहीं हटा सकता।** कोई हटाने का उपकरण नहीं है और सहायक के पास कोई हटाने की अनुमति नहीं है। हटाने डैशबोर्ड में आपके हाथों में रहते हैं।
+- **यह आपके संगठन के अंदर रहता है।** सहायक केवल उस संगठन को देखता है जिसे आप वर्तमान में देख रहे हैं।
+- **आपके प्रश्न आपके हैं।** संकेत और उत्तर आपके स्वयं के Observability डेटाबेस में रहते हैं; उत्पाद विश्लेषण केवल उपयोग मेटाडेटा रिकॉर्ड करता है, कभी भी आपके संकेत पाठ को नहीं।
+
+## इसे कहां खोजें
+
+सहायक आपके संगठन के तहत हर पृष्ठ के दाईं ओर चलता है (`/<org-slug>/...`)। रेल पर क्लिक करें, या `⌘J` / `Ctrl+J` दबाएं, इसे पूर्ण चैट पैनल में विस्तारित करने के लिए, और इसके किनारे को आकार देने के लिए खींचें; आपकी चौड़ाई पुनः लोड में याद रखी जाती है। इसका उपयोग करने के लिए आपको **`agent:use`** अनुमति की आवश्यकता है, अन्यथा रेल धूसर होता है। यदि यह अभी तक आपकी तैनाती के लिए चालू नहीं किया गया है (इसे एक LLM कनेक्शन की आवश्यकता है), तो आप एक काम करने वाली चैट के बजाय एक सुस्त रेल देखेंगे।
+
+## संबंधित
+
+- [CLI और agents](/hi/agenteye/cli-and-agents)
+- [Queries](/hi/agenteye/queries)
+- [Dashboards](/hi/agenteye/dashboards)
+- [Evaluation suite](/hi/agenteye/evaluation-suite)

package/.next/standalone/docs-old/hi/agenteye/audits.mdx

@@ -0,0 +1,53 @@
+---
+title: "ऑडिट: आपका स्वचालित विश्वसनीयता विश्लेषक"
+description: "Failproof AI Observability उन विफलताओं को खोजता है जिनके लिए आपने कोई नियम नहीं लिखा था और आपको ठीक करने के लिए आवश्यक चीजों की एक रैंक की गई, साक्ष्य-समर्थित सूची देता है।"
+---
+
+Failproof AI Observability उन विफलताओं को खोजता है जिनके लिए आपने कोई नियम नहीं लिखा था और आपको ठीक करने के लिए आवश्यक चीजों की एक रैंक की गई, साक्ष्य-समर्थित सूची देता है। यह ऐसा है जैसे कोई विश्लेषक हर रात आपके लॉग को देखे, और फिर सुबह तक छोटी सूची आपकी डेस्क पर छोड़ दे।
+
+<div style={{ position: "relative", width: "100%", paddingBottom: "56.25%", height: 0, overflow: "hidden", borderRadius: "12px", margin: "1.5rem 0" }}>
+  <iframe src="https://www.youtube.com/embed/C5nHKGQIqZQ?autoplay=1&mute=1&loop=1&playlist=C5nHKGQIqZQ&rel=0&playsinline=1" title="देखें: स्वचालित रूप से खोजें कि आपका एजेंट कहां विफल हो रहा है (2 मिनट)" allow="autoplay; encrypted-media; picture-in-picture; fullscreen" allowFullScreen style={{ position: "absolute", top: 0, left: 0, width: "100%", height: "100%", border: 0 }}></iframe>
+</div>
+
+*दो मिनट का दौरा: एक निर्धारित रन से लेकर एक ऐसे फिक्स तक जिस पर आप कार्य कर सकते हैं।*
+
+![ऑडिट पृष्ठ: आवर्ती कार्य जो आपके सत्रों को विफलता पैटर्न के लिए स्कैन करते हैं, प्रत्येक के साथ एक शेड्यूल और संवेदनशीलता](/agenteye/images/audits.png)
+*प्रत्येक ऑडिट एक आवर्ती कार्य है जो आपके सत्रों को माइन करता है और रैंक की गई, साक्ष्य-समर्थित सिफारिशें लिखता है।*
+
+## अनुमान लगाना बंद करें कि आगे क्या ठीक करना है
+
+अलर्ट उन समस्याओं को पकड़ते हैं जिन्हें आप पहले से देखना जानते हैं। ऑडिट उन समस्याओं को पकड़ते हैं जिन्हें आप नहीं जानते। आपके द्वारा निर्धारित शेड्यूल पर, एक ऑडिट आपके सभी एजेंट सत्रों को पढ़ता है और ऐसे पैटर्न के लिए शिकार करता है जो ठीक करने के लायक हैं, इसलिए आप लॉग स्क्रॉल करने की बजाय निष्कर्षों पर कार्य करने में अपना समय लगाते हैं।
+
+एक एकल रन उन विफलता मोड के बाद जाता है जो वास्तव में उत्पादन में एजेंटों को तोड़ते हैं:
+
+- **त्रुटि क्लस्टर**: साझा मूल कारण के तहत समान विफलता दोहराई जाती है।
+- **बेसलाइन के विरुद्ध बहाव**: व्यवहार शांति से ज्ञात-अच्छी खिड़की से दूर जा रहा है।
+- **प्रतिलेखों में लक्ष्य विफलता**: चलता है जो तकनीकी रूप से समाप्त हुआ लेकिन कभी काम नहीं किया।
+- **उपकरण का दुरुपयोग**: गलत उपकरण, खराब तर्क, या लूप जो कॉल को जला देते हैं।
+- **गुणवत्ता और लागत के व्यापार**: जहां आप उस आउटपुट के लिए अधिक भुगतान कर रहे हैं जिसे आप सस्ते में प्राप्त कर सकते हैं।
+- **कवरेज अंतराल**: व्यवहार जिसे कोई eval या अलर्ट नहीं देख रहा है।
+
+आप एक एकल **संवेदनशीलता** सेटिंग (कम, मध्यम, या उच्च) के साथ यह तय करते हैं कि यह कितना कठोर दिखता है, इसलिए एक शोरगुल वाला स्टेजिंग एजेंट और एक लॉक-डाउन उत्पादन एजेंट दोनों को आप चाहते हैं उस सिग्नल के लिए ट्यून किया जा सकता है।
+
+## हर सिफारिश प्रमाण के साथ आती है
+
+आपको कभी भी किसी निष्कर्ष पर विश्वास करने की आवश्यकता नहीं है। प्रत्येक सिफारिश उन सटीक सत्रों का हवाला देती है जहां से यह आया था और उस SQL को जो इसे सामने लाया था, इसलिए आप एक क्लिक में साक्ष्य खोल सकते हैं और समस्या की पुष्टि कर सकते हैं, न कि एक दावे को रिवर्स-इंजीनियर कर सकते हैं।
+
+जब कोई निष्कर्ष एक लीक किए गए क्रेडेंशियल के बारे में हो, तो यह एक कदम आगे बढ़ता है और वह व्यक्तिगत इवेंट को लिंक करता है जिसे यह मेल खाता है। एक पर क्लिक करें और आप सत्र में उस सटीक क्षण पर उतरते हैं, पहले से ही चुना हुआ — एक लंबे प्रतिलेख के शीर्ष पर नहीं। लिंक इवेंट का नाम देता है; यह पाए गए रहस्य को निष्कर्ष में कभी नहीं कॉपी करता है, इसलिए एक निष्कर्ष पढ़ना आपके क्रेडेंशियल लिखे जाने का दूसरा स्थान नहीं है। यदि कोई इवेंट अब नहीं है क्योंकि सत्र आपकी प्रतिधारण विंडो पास कर गया है, तो पृष्ठ स्पष्ट रूप से कहता है कि आप गलत चीज पर क्लिक किया है या नहीं यह सोचकर छोड़ते हैं।
+
+यह भी है जो ऑडिट को ईमानदार रखता है। सर्वर जांच करता है कि प्रत्येक उद्धृत सत्र वास्तव में मौजूद है और **किसी भी सिफारिश को त्याग देता है जिसका साक्ष्य धारण नहीं करता है**, इसलिए ऑडिट जांच करता है लेकिन कभी आविष्कार नहीं करता। आपकी सूची पर जो आता है वह वास्तविक, पुन: पेश करने योग्य, और इस बात से रैंक किया जाता है कि यह कितना महत्वपूर्ण है, सबसे बड़ी जीत शीर्ष पर है।
+
+## एक फिक्स को एक सुरक्षा में बदलें
+
+एक समस्या को ठीक करना केवल आधी जीत है। दूसरा आधा यह सुनिश्चित करना है कि यह शांति से वापस न आए। हर निष्कर्ष एक **एक-क्लिक शॉर्टकट ले जाता है जो एक आवर्ती अलर्ट का मसौदा तैयार करता है**, एक समझदारी से भरे हुए शुरुआती ट्रिगर के साथ आप ट्यून कर सकते हैं। निष्कर्ष को बंद करें, अलर्ट को सशस्त्र करें, और अगली बार जब वह पैटर्न फिर से प्रकट होता है तो आप एक भविष्य के ऑडिट में इसे फिर से खोजने के बजाय पेजिंग प्राप्त करते हैं।
+
+## इसे कहां खोजें
+
+ऑडिट डैशबोर्ड में **`/<org-slug>/audits`** पर रहते हैं (साइडबार से *विश्लेषण* से *audits*)। रन और निष्कर्षों को देखने के लिए **`audits:read`** की जरूरत है; ऑडिट बनाने, संपादित करने, और ट्राइज करने के लिए **`audits:write`** की जरूरत है। एक ऑडिट का दायरा और कैडेंस सेट करें, फिर जब आप अगले निर्धारित पास की प्रतीक्षा करने के बजाय तुरंत परिणाम चाहते हैं तो **अभी चलाएं** को हिट करें।
+
+## संबंधित
+
+- [अलर्ट](/hi/agenteye/alerts): जिस पल एक थ्रेसहोल्ड को पार किया जाता है उस पल एक पेज प्राप्त करें।
+- [मूल्यांकन](/hi/agenteye/evaluations): हर रन को स्कोर करें ताकि गुणवत्ता प्रतिगमन अपने आप सामने आएं।
+- [त्रुटि ट्रैकिंग](/hi/agenteye/error-tracking): एजेंटों द्वारा फेंकी जाने वाली त्रुटियों को समूहित और अनुसरण करें।
+- [घटनाएं](/hi/agenteye/incidents): एक ऑडिट के माध्यम से एक समस्या को ट्रैक करें जो यह इसके फिक्स के माध्यम से बदल देता है।