अंशांकन बैठक को मापने लायक बनाना

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

वह बैठक जो कोई सबूत नहीं छोड़ती

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

यह चलता है। यह पूरी तरह बिना मापा हुआ भी है। चर्चा से पहले लोगों की जो राय थी, वह ग़ायब है। किसने मन बदला, और बदला इसलिए कि वह क़ायल हुआ या इसलिए कि कोई वरिष्ठ साथी पहले बोल पड़ा, यह भी ग़ायब है। और बैठक से सहमति में कोई सुधार हुआ भी या नहीं, इसका जवाब कोई नहीं दे सकता, क्योंकि किसी ने उसे नापा ही नहीं।

मल्टीप्लेयर रूम उस सत्र को टूल के भीतर ले आते हैं।

बीच सत्र में एक नॉर्मिंग रूम

rooms:
  enabled: true
  who_can_create: any
  persist_votes: true
  schema: sarcasm

/rooms खोलिए, एक रूम बनाइए, और उसे छह अक्षरों का कोड मिल जाता है जिसे आप कॉल पर बोलकर बता सकते हैं। प्रवाह सोच-समझकर बनाया गया है:

1. सब ब्लाइंड वोट देते हैं। सदस्य देख सकते हैं कि किसने वोट दिया, कभी नहीं कि क्या। यह सर्वर की तरफ़ लागू होता है, इसलिए पहली राय सचमुच स्वतंत्र रहती है।
2. होस्ट खुलासा करता है। इसी क्षण ब्लाइंड वोट अपरिवर्तनीय हो जाते हैं।
3. समूह चर्चा करता है, साइड चैट में या आपकी कॉल पर।
4. कोई भी अपना वोट बदल सकता है। खुलासे के बाद हर बदलाव इस विवरण के साथ दर्ज होता है कि किससे किसमें बदला और उस क्षण बहुमत क्या था।

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

सहमति मीटर बताता है कि “क्या यह सार्थक था?”

Krippendorff's α खोले जा चुके आइटमों पर लाइव, दो बार गिना जाता है: एक बार ब्लाइंड वोटों पर, एक बार मौजूदा वोटों पर। इन दोनों का अंतर सत्र की नॉर्मिंग बढ़त है, और वह सत्र के चलते-चलते स्क्रीन पर दिखती रहती है।

यही वह संख्या है जो बैठक को जवाबदेह बनाती है। अगर एक घंटे की चर्चा ने α को 0.61 से 0.78 कर दिया, तो आप जानते हैं कि उस घंटे से कुछ मिला। अगर उसने उसे 0.61 से 0.62 किया, तो आपने यह जान लिया कि असहमति व्याख्या को लेकर नहीं है। वह दिशानिर्देश को लेकर है, और कितनी भी बातचीत उसे ठीक नहीं करेगी। जाइए और दिशानिर्देश दोबारा लिखिए।

दो रूपांतर जान लेने लायक हैं। Huddle रूम को ठीक उन्हीं आइटमों से भरते हैं जिन पर आपकी टीम अभी असहमत है, जो एनोटेशन स्थिति से लाइव गिने जाते हैं, और इससे वे अधिनिर्णय का समकालिक रूप बन जाते हैं। Shadow रूम प्रशिक्षुओं को किसी वरिष्ठ एनोटेटर को रीयल टाइम में काम करते देखने देते हैं, यह भी कि वह टेक्स्ट का कौन-सा हिस्सा हाइलाइट कर रहा है। किसी के बग़ल में बैठकर उसे एनोटेट करते देखने के सबसे क़रीब यही है।

रूम एक JSONL लॉग में इवेंट-सोर्स्ड हैं, इसलिए चालू रूम सर्वर के पुनरारंभ के बाद भी बचा रहता है, और वही लॉग सत्र का ऑडिट ट्रेल भी बन जाता है। इसमें कोई WebSocket नहीं है; क्लाइंट एक कर्सर के साथ पोल करते हैं, यानी रूम किसी भी WSGI डिप्लॉयमेंट पर काम करते हैं।

वह तर्क जिसे आपने कभी दर्ज नहीं किया

दूसरी चुपचाप होने वाली नाकामी तर्क हैं। ज़्यादातर टूल एक फ़्री-टेक्स्ट बॉक्स देते हैं, और ज़्यादातर एनोटेटर उसमें “obvious” लिखते हैं, या कुछ नहीं।

यह आलस नहीं है। अपने तर्क को लिखकर बताना उसे सोचने से सचमुच धीमा काम है, और अगर टास्क 400 आइटम लंबा हो, तो सबसे पहले तर्क वाला बॉक्स ही छूटता है।

Think-Aloud मोड माध्यम बदलकर यह रुकावट हटा देता है: एनोटेटर काम करते-करते बस बोलते हैं।

Think-Aloud, एक पहचाने गए लेबल के साथ

thinkaloud:
  enabled: true
  schema: politeness
  model: tiny.en

स्पीच-टू-टेक्स्ट लोकल ही faster-whisper से चलता है, जो 39 MB वाले tiny.en मॉडल पर CPU पर ही रीयल-टाइम है। ऑडियो कभी मशीन से बाहर नहीं जाता, न कोई क्लाउड API बुलाना पड़ता है और न प्रति-टोकन बिल भरना पड़ता है। बहुत सारे संवेदनशील डेटा के लिए यही “हम इसे इस्तेमाल कर सकते हैं” और “लीगल ने मना कर दिया” का फ़र्क़ है।

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

शब्दशः, जान-बूझकर

ट्रांसक्रिप्ट ठीक वैसे ही सहेजा जाता है जैसे बोला गया, और जान-बूझकर उसका सारांश नहीं बनाया जाता। यह असली डिज़ाइन निर्णय है, आलस नहीं: थिंक-अलाउड प्रोटोकॉल को दूसरे शब्दों में ढालना उस कलाकृति को दूषित कर देता है। हिचकिचाहटें, अपनी बात सुधारना, वह “well, it could be sarcastic, but…”: डेटा यही है। उसका सुथरा सारांश एक अलग और कहीं कम काम की चीज़ है।

एनोटेटर आवाज़ से भी लेबल दर्ज कर सकते हैं, कुछ तय वाक्यांशों से जिन्हें एक नियम-आधारित पार्सर पहचानता है:

• "I label this Polite"
• "My answer is impolite"
• "Final answer: neutral"

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

साथ ही आपको निर्धारक हिचकिचाहट संकेत मिलते हैं (चुप्पी वाले टुकड़ों की गिनती, भराव-शब्दों की गिनती), जो किसी मॉडल के बजाय सादे गणित से निकलते हैं। किसी आइटम पर लंबे ठहराव कठिनाई का ठीक-ठाक सरोगेट हैं, और उन्हें जुटाने में कुछ नहीं लगता।

यह तर्कों से आगे क्यों मायने रखता है

अब वह हिस्सा जो बाक़ी Potato 2.7 से जुड़ता है।

Think-Aloud एक इंसानी सोच-की-शृंखला रिकॉर्डर है। यह पकड़ता है कि कोई व्यक्ति किसी लेबल तक असल में कैसे तर्क करता है: बाद में लिखा गया साफ़-सुथरा औचित्य नहीं, बल्कि होते-होते चलता तर्क, ग़लत शुरुआतों समेत।

Potato का प्रोसेस रिवॉर्ड एनोटेशन मॉडल के लिए यही काम करता है: वह मॉडल की सोच की शृंखला को खंडों में बाँटता है और क़दम-दर-क़दम उसे अंक देता है।

एक ही आइटम, दो सोच की शृंखलाएँ, एक इंसान की और एक मॉडल की। आप उन्हें आमने-सामने रखकर देख सकते हैं कि तर्क कहाँ अलग हो जाता है। ऐसा रिकॉर्ड होना सचमुच नई बात है, और बेहतर प्रोसेस-रिवॉर्ड डेटा का कच्चा माल यही है, क्योंकि “मॉडल को सही जवाब ग़लत वजह से मिला” ठीक वही विफलता है जो आख़िरी जवाब पर अंक देने से नहीं दिखती।

Potato आपको दोनों को दर्ज करने की सतहें देता है। वह आपके लिए उनके बीच diff नहीं गिनता। वह सुविधा नहीं, शोध का सवाल है, और हम आपको अपनी गढ़ी हुई कोई संख्या थमाने के बजाय कलाकृति देना बेहतर समझते हैं।

आगे पढ़ें

• मल्टीप्लेयर रूम और Think-Aloud मोड — पूरा कॉन्फ़िगरेशन
• अंतर-एनोटेटर सहमति — α असल में माप क्या रहा है
• अधिनिर्णय और असहमति
• एरर बार वाले लेबल — साइकोमेट्रिक्स कोडबुक की गड़बड़ियाँ चिह्नित करता है; उन्हें सुलझाया रूम में जाता है
• प्रोसेस रिवॉर्ड मॉडल — मॉडल की तरफ़ की सोच की शृंखला