AI-नेटिव बहुभाषी न्यूज़रूम बनाते हुए हमने क्या सीखा

न्यूज़रूम के लिए सॉफ्टवेयर बनाना आम कंटेंट मैनेजमेंट सिस्टम बनाने से अलग काम है। न्यूज़रूम में जानकारी कई शक्लों में आती है: टेक्स्ट, फोटो, वीडियो, मैसेज, डॉक्यूमेंट और फील्ड से आई रिपोर्ट। इसमें से ज़्यादातर जानकारी किसी बंधे-बंधाए ढांचे में नहीं आती। साथ ही यह जानकारी वक़्त की पाबंद होती है, कई भाषाओं में होती है, और छपने से पहले संपादकीय जांच मांगती है। हमने न्यूज़ दर्पण बनाना एक सीधे सवाल से शुरू किया: अगर न्यूज़रूम का रोज़ दोहराया जाने वाला प्रोडक्शन काम सॉफ्टवेयर इन्फ्रास्ट्रक्चर की तरह देखा जाए, तो न्यूज़रूम कैसा दिखेगा? मकसद पत्रकारों की जगह AI बिठाना नहीं है। मकसद यह है कि पत्रकारिता के इर्द-गिर्द जो दोहराव वाला काम है वह कम हो, और रिपोर्टिंग, तथ्यों की जांच तथा संपादकीय जवाबदेही इंसान के हाथ में रहे।

फील्ड की जानकारी से ढांचागत खबर तक

रिपोर्टर आम तौर पर डेटाबेस के हिसाब से काम नहीं करते। वे जानकारी उन्हीं टूल्स से भेजते हैं जो पहले से इस्तेमाल कर रहे हैं: मैसेजिंग ऐप, वेब इंटरफेस और स्टाफ ऐप। एक रिपोर्ट में टेक्स्ट, फोटो, वीडियो और अतिरिक्त संदर्भ हो सकता है। इसलिए हमारी पहली इंजीनियरिंग दिक्कत है इनजेशन, यानी जानकारी को अंदर लेना। सिस्टम इन अलग-अलग इनपुट को लेकर उन्हें एक संभावित खबर के ढांचागत रूप में बदलता है।

इनजेशन पाइपलाइन

रिपोर्टर की भेजी सामग्री में टेक्स्ट, फोटो, वीडियो और संदर्भ होता है। इनजेशन इन्हें एक ढांचागत खबर में बदलता है:

1. रिपोर्टर: टेक्स्ट, फोटो, वीडियो और संदर्भ भेजता है
2. इनजेशन: भेजी सामग्री को पढ़कर ढांचा बनाता है
3. ढांचागत खबर: मशीन के पढ़ने लायक रूप

जानकारी का ढांचा बन जाने के बाद, उसी एक खबर पर प्रोसेसिंग के अलग-अलग चरण काम कर सकते हैं।

हम LLM को पूरा न्यूज़रूम नहीं मानते

शुरुआती सबक यह था कि पूरी खबर एक बड़े लैंग्वेज मॉडल को थमा देना और कहना कि "खबर लिख दो", यह कोई काम का ढांचा नहीं है। न्यूज़रूम के अलग-अलग कामों की ज़रूरतें अलग होती हैं। एक खबर में रिसर्च की मदद, दोबारा लिखाई, अनुवाद, हेडलाइन बनाना, सारांश, SEO मेटाडेटा, मीडिया प्रोसेसिंग और वितरण, सब लग सकता है। इसलिए हम इन्हें अलग-अलग चरण मानते हैं।

प्रोसेसिंग के चरण

एक ढांचागत खबर से अलग-अलग चरण निकलते हैं, और हर चरण की ज़रूरत अलग होती है:

• रिसर्च: सहायक संदर्भ
• रीराइट: संपादकीय भाषा
• अनुवाद: दूसरी भाषाओं में
• हेडलाइन: शीर्षक बनाना
• मेटाडेटा: SEO फ़ील्ड और स्कीमा
• मीडिया: तस्वीर और वीडियो प्रोसेसिंग
• वितरण: प्रकाशन और सिंडिकेशन

दिलचस्प इंजीनियरिंग सवाल यह नहीं है कि मॉडल हर काम अलग-अलग कर सकता है या नहीं। सवाल यह है कि इन कामों को भरोसे के साथ एक क्रम में कैसे चलाया जाए।

इंसानी संपादकीय नियंत्रण पक्की शर्त है

खबर के सिस्टम में लिखना और जांचना, दोनों एक ही काम नहीं माने जा सकते। AI मॉडल भरोसे लायक दिखने वाला वाक्य तब भी बना देता है जब पीछे की जानकारी अधूरी या गलत हो। इसलिए न्यूज़ दर्पण में संपादकीय मंज़ूरी वर्कफ्लो का साफ हिस्सा है। आसान शब्दों में:

संपादकीय वर्कफ्लो

लिखना और जांचना अलग-अलग काम हैं, इसलिए मंज़ूरी एक साफ चरण है, कोई साइड-इफेक्ट नहीं:

1. रिपोर्टर
2. खबर इनजेशन
3. AI प्रोसेसिंग
4. ड्राफ्ट
5. क्वालिटी जांच
6. संपादकीय समीक्षा: खबर को समीक्षा या सुधार के लिए वापस भेज सकती है
7. मंज़ूरी
8. प्रकाशन

संपादक छपने से पहले खबर देख और मंज़ूर कर सकते हैं। ज़्यादा जोखिम वाली या संवेदनशील खबरें अपने आप छपने के बजाय अतिरिक्त समीक्षा में भेजी जा सकती हैं। इससे एक ज़रूरी फर्क साफ होता है: AI कंटेंट बनाने में मदद कर सकता है, पर यह तय करने का आखिरी हक उसका नहीं है कि कुछ छपना चाहिए या नहीं।

भरोसेमंदी भी संपादकीय इंजीनियरिंग का हिस्सा है

जब AI प्रोडक्शन सिस्टम का हिस्सा बन जाता है, तो प्रॉम्प्ट की क्वालिटी समस्या का बस एक हिस्सा रह जाती है। प्रोडक्शन सिस्टम को नाकामियों से भी निपटना पड़ता है। AI रिक्वेस्ट फेल हो जाए तो क्या? मंज़ूर हो चुकी खबर कतार में अटक जाए तो क्या? तस्वीर गायब हो तो क्या? मेटाडेटा बना ही न हो तो क्या? कंटेंट इतना पुराना पड़ जाए कि अपने आप छापना ठीक न हो, तो क्या? ये सॉफ्टवेयर की भरोसेमंदी के सवाल हैं, लेकिन न्यूज़रूम में ये संपादकीय सवाल भी बन जाते हैं। इसलिए सिस्टम में बैकग्राउंड प्रक्रियाएं शामिल हैं, जैसे:

• सोर्स पोलिंग
• मंज़ूर-कतार की रिकवरी
• SEO रखरखाव
• पुराने कंटेंट की जांच
• गायब तस्वीर की रिकवरी
• वर्गीकरण
• ऑडिट नोट
• मूल स्रोत के संदर्भ
• तस्वीर का श्रेय
• ऑल्ट टेक्स्ट
• रिस्पॉन्सिव मीडिया
• बैकअप
• स्टोरेज निगरानी
• छपने से पहले क्वालिटी जांच
• ऑडिट ट्रेल

सिद्धांत सीधा है: सॉफ्टवेयर की एक नाकामी चुपचाप संपादकीय फैसला नहीं बन जानी चाहिए।

ताज़गी डेटा मॉडल का हिस्सा है

खबर की खासियत है कि जानकारी सिर्फ वक़्त बीतने से अपनी अहमियत खो देती है। हम नहीं चाहते कि हर कंटेंट पर ताज़गी का एक ही नियम लगे। ब्रेकिंग न्यूज़, सामान्य खबर और एक्सप्लेनर, इनकी ताज़गी की ज़रूरतें अलग हो सकती हैं। इसका मतलब है कि वर्कफ्लो कुछ अपने-आप होने वाले कामों की इजाज़त देने से पहले कंटेंट की उम्र पर सोच सकता है। मोटे तौर पर:

ताज़गी जांच

अपने आप छापने वाला कोई भी चरण चलने से पहले कंटेंट की उम्र परखी जाती है:

1. कंटेंट
2. कंटेंट का प्रकार: ब्रेकिंग न्यूज़, सामान्य खबर या एक्सप्लेनर
3. ताज़गी जांच: उस प्रकार का नियम लगाती है

जांच के दो नतीजे होते हैं:

• ताज़ा: प्रकाशन की तरफ आगे बढ़ो
• पुराना: समीक्षा में भेजो, या अस्वीकार करो

यह एक बड़े सबक का छोटा नमूना है जो हम सीख रहे हैं: न्यूज़रूम के ऑटोमेशन को इस क्षेत्र के अपने नियम चाहिए, सिर्फ आम AI जनरेशन नहीं।

बहुभाषी प्रकाशन अनुवाद से आगे की चीज़ है

भारत में बहुभाषी प्रकाशन को खास दिलचस्प बना देता है। कई भारतीय भाषाओं में काम करने वाला न्यूज़रूम अनुवाद को अंग्रेज़ी लेख लिखने के बाद का आखिरी कदम नहीं मान सकता। अलग भाषाओं की शब्दावली, वाक्य रचना और संपादकीय परंपराएं अलग होती हैं। इसलिए हम बहुभाषी प्रकाशन को एक तैयार लेख के इर्द-गिर्द नहीं, बल्कि पीछे मौजूद खबर के इर्द-गिर्द सोचते हैं।

एक खबर के संदर्भ से कई प्रकाशन रूप

हर आउटपुट का साझा स्रोत खबर का संदर्भ है, कोई तैयार अंग्रेज़ी लेख नहीं:

• हिंदी
• अंग्रेज़ी
• क्षेत्रीय भाषा
• छोटा सारांश
• सोशल फॉर्मेट
• वीडियो फॉर्मेट

खबर का संदर्भ वह साझा स्रोत बन जाता है जिससे प्रकाशन के अलग-अलग रूप बनाए जा सकते हैं। इससे हमें अलग-अलग संस्करणों के बीच तालमेल बनाए रखने का बेहतर आधार भी मिलता है।

न्यूज़रूम कंपाइलर जैसा दिखने लगता है

इस ढांचे को समझने का एक काम का तरीका है कंपाइलर की तरह देखना। रिपोर्टर ऊपरी स्तर का इनपुट देता है। सिस्टम उस इनपुट को ढांचागत जानकारी में पढ़ता है। प्रोसेसिंग के अलग-अलग चरण उस रूप को बदलते हैं। संपादकीय समीक्षा गेट का काम करती है। मंज़ूर हुई खबर फिर प्रकाशन के अलग-अलग रूपों में ढाली जाती है।

न्यूज़रूम एक कंपाइलर की तरह

कच्ची रिपोर्टिंग को ढांचागत खबर में पढ़ा जाता है, और फिर वही खबर हर प्रकाशन रूप में ढाली जाती है:

1. कच्ची रिपोर्टिंग: रिपोर्टर का ऊपरी स्तर का इनपुट
2. ढांचागत खबर: पढ़ा गया रूप

वहां से खबर इन रूपों में ढलती है:

• लेख
• अनुवाद
• हेडलाइन
• सारांश
• SEO
• सोशल
• वीडियो

और ये सब वितरण तक पहुंचते हैं।

यह मॉडल पारदर्शिता को भी ज़रूरी बना देता है। हम समझना चाहते हैं कि जानकारी सिस्टम में कहां से आई, उस पर क्या बदलाव हुए, और इंसानी मंज़ूरी कहां लगी। पत्रकारिता के लिए यह बात लिखाई की क्वालिटी जितनी ही अहम है।

जिन चीज़ों को हम जानबूझकर ऑटोमेट नहीं करते

कुछ फैसले हैं जिन्हें हम मॉडल के हवाले नहीं करना चाहते। हम नहीं चाहते कि मॉडल किसी स्रोत को भरोसेमंद बता दे सिर्फ इसलिए कि मॉडल ऐसा कह रहा है। हम नहीं चाहते कि कोई एल्गोरिदम सच तय करे। हम नहीं चाहते कि ऑटोमेशन संपादकीय जवाबदेही खत्म कर दे। और हम नहीं चाहते कि छापने की रफ्तार बिना जांची जानकारी छापने का बहाना बन जाए। इसलिए दिलचस्प इंजीनियरिंग सवाल यह नहीं है: इंसानों के बगैर AI से खबर कैसे छपवाएं? सवाल यह है: न्यूज़रूम का दोहराव वाला कितना काम सॉफ्टवेयर हटा सकता है, और वह भी ऐसे कि इंसानी संपादकीय नियंत्रण कमज़ोर न हो बल्कि मजबूत हो? न्यूज़ दर्पण के साथ हम इसी सवाल पर काम कर रहे हैं।

हम किस दिशा में बना रहे हैं

न्यूज़ दर्पण को नीलवर्स स्टूडियोज़ इस सोच के साथ बना रहा है कि AI जानकारी-आधारित संस्थानों के लिए इन्फ्रास्ट्रक्चर बन सकता है। न्यूज़रूम असामान्य रूप से मुश्किल जगह है, क्योंकि यहां एक साथ मिलते हैं:

• बिना ढांचे वाले इनपुट
• तेज़ी से बदलती जानकारी
• कई भाषाओं का कंटेंट
• इंसानी समझ
• मीडिया प्रोसेसिंग
• प्रकाशन
• वितरण
• जांच-परख की सुविधा
• भरोसेमंदी

इसी वजह से पत्रकारिता AI-आधारित प्रोडक्शन सिस्टम बनाने और परखने के लिए दिलचस्प जगह है। हमारी सोच सीधी है: न्यूज़रूम को AI से बदलिए नहीं। न्यूज़रूम के आसपास बेहतर सॉफ्टवेयर बनाइए। अगर सॉफ्टवेयर दोहराव वाला ज़्यादा काम संभाल ले, तो पत्रकार उन कामों को ज़्यादा वक़्त दे सकेंगे जिन्हें ऑटोमेट करना मुश्किल है: जानकारी खोजना, लोगों से बात करना, छानबीन करना, तथ्य जांचना और संपादकीय फैसले लेना। यही सिस्टम हम बनाने की कोशिश कर रहे हैं।