- सॉफ्टवेयर इंडस्ट्री में हाल ही में 'Software Factory' की अवधारणा काफी चर्चा में है। यह एक नया paradigm है जिसमें AI agents दिए गए लक्ष्य के अनुसार कई चरणों वाला काम खुद करते हुए source code लिखने की जिम्मेदारी संभालते हैं, और developers उस code को भरोसेमंद तरीके से बड़े पैमाने पर बनाने वाले system, यानी 'factory', को बनाने और बेहतर करने पर ध्यान देते हैं।
- AI development tools कंपनी Tessl के Dru Knox ने इस नए development discipline को Harness Engineering नाम दिया है।
- Harness का मतलब उस पूरे framework से है जो घोड़े पर लगाए जाने वाले harness की तरह AI agents को नियंत्रित और चलाता है, और इस framework के केंद्र में तीन loops (एक ही प्रक्रिया को बार-बार दोहराने वाले चक्र) होते हैं।
- वीडियो में क्या शामिल है: Software Factory क्या है और उसे परिभाषित करने वाले तीन indicators / Tessl ने internally conversational coding sessions पर प्रतिबंध क्यों लगाया और उसके बाद क्या हुआ / Inner, Outer और Meta loops की तीन layers / Harness Engineering कठिन क्यों है / Tessl के change review और verifier ने इसे वास्तव में कैसे implement किया
- वीडियो: https://www.youtube.com/watch?v=D_cw-k0F1DM&t=236
यही structure ज्ञान उत्पादन पर लागू करें तो
- Knowledge Factory एक ऐसी व्यवस्था है जिसमें AI agents wiki pages लिखते हैं, और इंसान उन्हें बड़े पैमाने पर produce करने वाले 'newsroom system' को design और operate करते हैं। operator खुद articles नहीं लिखता, बल्कि writing guidelines और automated review mechanisms को manage करता है।
- factory के अंदरूनी संगठन ने newspaper newsroom की 5 भूमिकाओं वाली व्यवस्था को benchmark किया है: reporter, columnist, copy editor, desk और editor-in-chief।
- यहां मुख्य बात यह है कि सभी 5 भूमिकाएं 'judging AI' नहीं हैं। 'copy editor' AI नहीं, बल्कि rule-based Python code है, और 'editor-in-chief' काम बांटने वाला coordinator है। AI जिस जगह स्वतंत्र evaluative judgment करता है, वह केवल 'desk' है।
- असरदार factory design का मतलब agents की संख्या अंधाधुंध बढ़ाना नहीं, बल्कि यह साफ परिभाषित करना है कि judgment areas को कहां रखा जाए और कहां बाहर रखा जाए।
maturity के तीन axes, और trust
- system maturity को तीन axes पर मापा जाता है: autonomy (इंसानी हस्तक्षेप के बिना page completion), automation (इंसानी review के बिना publication की अनुमति की सीमा), और quality (produced knowledge का स्तर)।
- autonomy अधिक हो, फिर भी operator असहज होकर हर page की पूरी जांच करे, तो automation level कम ही रहता है। इस gap को भरने वाला मुख्य तत्व 'trust' है।
- पहले autonomy हासिल करें, trust जितनी सीमा तक जमा हो उतना automation zone बढ़ाएं, और इस प्रक्रिया में quality level स्थिर बनाए रखें। और इस trust की गारंटी देने वाला mechanism ही 'loop' है।
1. Inner Loop — real-time self-check
- Inner Loop वह तेज और हल्की verification process है जिसे agent draft submit करने से पहले, writing process के दौरान बार-बार चलाता है। यह loop जितना refined होगा, AI agent इंसानी हस्तक्षेप के बिना खुद errors ठीक करेगा, और नतीजतन autonomy बेहतर होगी।
- लिखते समय Python inspection tool (
tools/lint.py) से केवल अपने बनाए documents की जांच की जाती है, और अगर वही error 2 या अधिक बार दोहराता है, तो processing speed बनाए रखने के लिए उसे तुरंत अगले चरण में भेज दिया जाता है।
2. Outer Loop — publication से ठीक पहले का double gate
- पहला gate copy editing है। Python code links, citations, document structure, data conflicts आदि 10 areas को deterministic rules के आधार पर statically check करता है।
- दूसरा gate desk है। bias, information density, readability, argument flow आदि 6 perspectives से तीसरे पक्ष के reader के नजरिए से qualitative evaluation करता है, और सीधे edit नहीं करता बल्कि केवल improvement items की list लौटाता है।
- यह Software Factory के verifier (पहला gate) और change review (दूसरा gate) वाली two-stage structure के समान है।
- यहां एक निर्णायक design principle है। desk को केवल final manuscript और evaluation criteria दिए जाते हैं; लेखक का writing intent नहीं दिया जाता। क्योंकि उसी context में अपनी writing की खुद review करने पर judgment नरम हो जाता है, इसलिए जानकारी को शुरू से ही रोककर उस bias को prevent किया जाता है।
- इस system की वास्तविक differentiator यह नहीं है कि कितने agents चलाए गए, बल्कि यह context isolation है। अगर वही वजह देकर 3 बार reject किया जाता है, तो automatic progression रोक दी जाती है और judgment human operator को सौंप दिया जाता है।
3. Meta Loop — self-improvement mechanism
- यह सिद्धांत अपनाया जाता है: "एक ही गलती दो बार दोहराने न दें। मिली हुई error को system rule में upgrade करें।"
- यदि वही defect लगातार होता है, तो writing guidelines में संशोधन का प्रस्ताव अपने-आप दिया जाता है। प्रस्तावित संशोधन blind comparative evaluation से गुजरता है, जिसमें यह छिपाया जाता है कि किस side ने modified rule से लिखा है, और नए failure-case test से भी गुजरता है जिसे verification में कभी इस्तेमाल नहीं किया गया।
- इसे system में तभी reflect किया जाता है जब score सचमुच improve हो, और अनिवार्य रूप से human operator की final approval मिलने पर ही।
- बार-बार आने वाली comments को Python hooks या copy-editing rules में upgrade करके code में स्थायी किया जाता है। qualitative judgment areas को rule-checking areas में transfer किया जाता है, ताकि desk हमेशा higher-level problems पर focus कर सके।
4. Reground Loop — ज्ञान के लिए जरूरी चौथा loop
- software code एक बार build होकर deploy हो जाए, तो spec change तक stable state में रहता है, लेकिन knowledge assets समय के साथ वास्तविक facts से दूर होते जाते हैं और outdated हो जाते हैं।
- इसे हल करने के लिए published documents को फिर से knowledge production factory के input में feed back करने वाला Reground loop (यानी आधार से फिर जुड़ना) चौथे loop के रूप में जोड़ा गया।
- update: जब original data source में बदलाव होता है। inspection tool द्वारा पहचाने गए outdated pages को columnist फिर से analyze कर update करता है। (follow-up report)
- follow-up: जब document में 'बाद में confirmation जरूरी' या time-bound condition वाला वाक्य मौजूद हो। deadline आने पर desk और operator फिर से verify करते हैं। (tracking coverage)
- correction: जब हमारी pages के बीच information conflict पकड़ा जाता है। desk published cluster के document bundle को पूरा फिर से पढ़ता है और उन inconsistencies को पकड़ता है जो एक-एक करके देखने पर सामने नहीं आतीं। (correction report)
Human-in-the-Loop
- जिन exceptional situations में human approval चाहिए, उन्हें intuition पर निर्भर किए बिना स्पष्ट checklist से define और manage किया जाता है।
- फिलहाल इसे autonomy बढ़ाकर, लेकिन automation को जानबूझकर सीमित रखकर operate किया जा रहा है। agent page खुद लिखता है, लेकिन Wiki publication और writing rules में बदलाव के लिए अभी भी human final approval जरूरी है।
पूरा लेख: https://alfadur7.github.io/llm-wiki-newsroom/ko/knowledge-factory/
अभी कोई टिप्पणी नहीं है.