नमस्ते।
लगभग 6 महीने पहले, मैं वही डेवलपर हूं जिसने बिलों को आसानी से देखने और उन पर राय छोड़ने के लिए नागरिक भागीदारी सेवा 'Uhheung' के रूप में आपसे परिचय कराया था।
इस बार कम्युनिटी के भीतर फेक न्यूज और बेकार की बहसों को कम करने के लिए मैंने AI फैक्ट-चेक फीचर पेश किया है, और इस प्रक्रिया में हुई सोच-विचार और तकनीकी गलतियों/सीख को साझा करना चाहता हूं।
शुरुआत में मैंने बहुत सरल तरीके से अप्रोच किया। टारगेट टेक्स्ट देकर "जांचो कि यह पोस्ट सच है या नहीं" जैसा प्रॉम्प्ट बनाया। लेकिन जब इसे असली सेवा में डाला, तो अप्रत्याशित समस्याएं लगातार सामने आने लगीं।
यह साधारण व्यक्तिगत 'राय' तक को तथ्य मानकर फैक्ट-चेक करने लगा, और आधार न होने पर भी काफी विश्वसनीय लगने वाला निष्कर्ष दे देता था। ऊपर से, फैक्ट-चेक खत्म होने के बाद अगर लेखक मूल पोस्ट एडिट कर देता, तो परिणाम का संदर्भ मेल न खाने जैसी अजीब स्थिति भी बन जाती थी।
आखिरकार शुरुआती स्ट्रक्चर पूरी तरह छोड़कर, अब हमने pipeline को काफी बदलकर नीचे की तरह ऑपरेट करना शुरू किया है।
1. जांच के योग्य हिस्से छांटना (राय vs तथ्य)
पूरी पोस्ट को एक साथ verify करने के बजाय, पहले सिर्फ वे 'तथ्यात्मक दावे' निकालने को कहा जो objectively verify किए जा सकते हैं। यानी "यह नीति सबसे खराब है" जैसे value judgement को नजरअंदाज करते हुए, "यह बिल टैक्स 20% बढ़ाता है" जैसे वाक्यों को ही target बनाया जाता है।
सटीक context समझने के लिए सिर्फ target text नहीं देखते; मूल पोस्ट, parent comment, यहां तक कि attached images तक को multimodal रूप में जोड़कर AI को context दिया जा रहा है।
2. "मुझे नहीं पता" कहलवाना
यह उन हिस्सों में से एक है जिस पर सबसे ज्यादा ध्यान दिया। LLM की hallucination रोकने के लिए, जहां cross-check करने लायक भरोसेमंद evidence कम हो या verification संभव न हो, वहां जबरन निष्कर्ष निकालने के बजाय 'पता नहीं', 'निर्णय लंबित' जैसा जवाब देने के लिए prompt को कड़े तरीके से control किया।
3. मूल टेक्स्ट का snapshot सुरक्षित रखना और स्रोतों को पारदर्शी बनाना
लेखक द्वारा पोस्ट एडिट कर देने वाली समस्या रोकने के लिए, फैक्ट-चेक request किए जाने के उस समय का original data (snapshot) जस का तस रखा जाता है। जब दूसरे users result देखें, तो वे पारदर्शी तरीके से देख सकें कि "किस समय के किस text/image के आधार पर verification किया गया", और "किन sources का संदर्भ लिया गया"।
4. Traffic और resource handling
क्योंकि इस तरह पूरा context खींचकर verification करने की प्रक्रिया भारी है, user queue management की जरूरत पड़ी। इसलिए सभी requests को Redis Cluster + BullMQ का उपयोग करके async queue में डाला जाता है और background worker में क्रम से process किया जाता है।
Cost और speed को देखते हुए Gemini 3.5 Flash को main model के रूप में इस्तेमाल कर रहे हैं, लेकिन error rate बढ़ने या complex reasoning fail होने पर Gemini 3.1 Pro पर fallback करने वाला structure लगाया है।
(बेतहाशा requests रोकने के लिए रोज 1 बार free देने के बाद, in-app points deduct करने की limit भी रखी है।)
अभी भी सुलझाए जा रहे काम
अपनी तरफ से defensive logic बनाया है, लेकिन अभी भी कई tricky cases हैं। जब statistics का reference point अलग हो, politicians की खास तरह की metaphor या interpretation वाली statements हों, या बहुत लंबी posts जिनमें facts और falsehood चालाकी से मिले हों, उन्हें perfect तरीके से handle करना अभी भी मुश्किल है।
आप इसे Uhheung app में खुद test कर सकते हैं।
अगर ऐसे verification logic में hallucination को बेहतर पकड़ने के लिए prompt know-how, या ambiguous results को users द्वारा बेहतर accept करवाने के लिए UX/UI ideas हों, तो कृपया आराम से सलाह दें। लंबी पोस्ट पढ़ने के लिए धन्यवाद!
Google Play: https://play.google.com/store/apps/details?id=kr.uhheung.app
App Store: https://apps.apple.com/kr/app/%EC%96%B4%ED%9D%A5/id6751951353
अभी कोई टिप्पणी नहीं है.