तकनीकी लेखक और एआई एजेंट्स: आर्टि बनाते समय मैंने जो सीखा

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

लेकिन मैंने फिर भी एक बनाया।

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

यह आर्टी के डिज़ाइन का वॉकथ्रू नहीं है—उसके लिए ही केस स्टडी है। यह व्यापक सबक के बारे में है:

• एआई एजेंट वास्तव में क्या हैं
• रिट्रीवल-ऑगमेंटेड जनरेशन पर्दे के पीछे कैसे काम करती है
• प्रॉम्प्ट इंजीनियरिंग अधिकांश लोगों के समझने से कहीं ज़्यादा तकनीकी लेखन के करीब क्यों है
• और हमारे इस छोटे से क्षेत्र में लोगों के लिए इसका क्या मतलब है

एआई एजेंट क्या है, और क्या नहीं है?

"एआई एजेंट" शब्द का इस्तेमाल इतनी लापरवाही से किया जाता है कि इसे परिभाषित करना ज़रूरी है। हर एआई-संचालित फ़ीचर एक एजेंट नहीं होता। मशीन लर्निंग का उपयोग करने वाला एक स्पेल-चेकर एक एजेंट नहीं है। एक ऑटो-कम्प्लीट सुझाव एक एजेंट नहीं है। एक ऐसा चैटबॉट भी जो एक कठोर निर्णय वृक्ष (decision tree) का पालन करता है, वास्तव में एक एजेंट नहीं है—यह एक टेक्स्ट इनपुट वाला फ्लोचार्ट है।

एक एआई एजेंट एक ऐसी प्रणाली है जो एक परिभाषित वातावरण के भीतर एक लक्ष्य की व्याख्या कर सकती है, उसे प्राप्त करने के तरीके के बारे में तर्क कर सकती है, और कार्य कर सकती है। मुख्य अंतर सीमाओं के भीतर स्वायत्तता है। एक एजेंट सिर्फ़ किसी प्रॉम्प्ट का जवाब नहीं देता; यह संदर्भ का मूल्यांकन करता है, एक रणनीति चुनता है, और उसे निष्पादित करता है—अक्सर कई चरणों में।

तो, इस स्पेक्ट्रम में आर्टी की स्थिति क्या है?

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

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

रिट्रीवल-ऑगमेंटेड जनरेशन वास्तव में कैसे काम करता है

रिट्रीवल-ऑगमेंटेड जनरेशन (RAG) आर्टी और बढ़ती संख्या में एआई-संचालित दस्तावेज़ीकरण उपकरणों के पीछे का आर्किटेक्चरल पैटर्न है। यह अवधारणा बड़े भाषा मॉडल (LLMs) की एक मौलिक सीमा को संबोधित करती है: उन्हें एक स्थिर डेटासेट पर प्रशिक्षित किया जाता है और उनमें आपके विशिष्ट सामग्री पर कोई डेटा नहीं होता है।

एक मानक एलएलएम (LLM) इंटरैक्शन इस तरह काम करता है: उपयोगकर्ता एक प्रॉम्प्ट भेजता है, मॉडल अपने प्रशिक्षण डेटा से एक प्रतिक्रिया उत्पन्न करता है। यह सामान्य ज्ञान के लिए ठीक है, लेकिन यह डोमेन-विशिष्ट प्रश्नों के लिए विफल हो जाता है। अपने उत्पाद के एपीआई (API) के बारे में एक बेस मॉडल से पूछें और यह या तो कोई मनगढ़ंत उत्तर देगा या विनम्रतापूर्वक मना कर देगा।

RAG उपयोगकर्ता के प्रश्न और मॉडल के उत्तर के बीच एक पुनः प्राप्ति चरण (retrieval step) डालता है। पाइपलाइन इस प्रकार दिखती है:

1. क्वेरी प्रोसेसिंग। उपयोगकर्ता का प्रश्न प्राप्त किया जाता है और खोज के लिए उपयुक्त रूप में परिवर्तित किया जाता है। यह क्वेरी को एक वेक्टर एम्बेडिंग में परिवर्तित करके किया जाता है, जो प्रश्न के अर्थ (semantic meaning) का एक संख्यात्मक प्रतिनिधित्व है।
2. पुनर्प्राप्ति। सिस्टम ज्ञान आधार में ऐसी सामग्री की खोज करता है जो क्वेरी से अर्थ की दृष्टि से समान है। इस मामले में, ज्ञान आधार आपके दस्तावेज़ों का एक पूर्व-निर्मित अनुक्रमणिका है। खोज अर्थ-आधारित समानता का उपयोग करती है, न कि कीवर्ड मिलान का, इसलिए "मैं प्रमाणीकरण कैसे सेट अप करूँ?" और "लॉगिन क्रेडेंशियल कॉन्फ़िगर करें" एक ही दस्तावेज़ पृष्ठ से मेल खाएंगे।
3. संदर्भ असेंबली। प्राप्त किए गए दस्तावेज़ों (या दस्तावेज़ों के टुकड़ों) को उपयोगकर्ता के मूल प्रश्न और सिस्टम प्रॉम्प्ट के साथ एक संदर्भ विंडो में एकत्र किया जाता है। यह एकत्रित पैकेज ही है जिसे मॉडल संसाधित करता है।
4. जनरेशन। मॉडल अपने सामान्य प्रशिक्षण डेटा के बजाय, प्राप्त संदर्भ पर आधारित एक प्रतिक्रिया उत्पन्न करता है। जब सिस्टम अच्छी तरह से कॉन्फ़िगर किया गया होता है, तो मॉडल अपने स्रोतों का हवाला देता है और प्राप्त दस्तावेज़ों में वास्तव में क्या कहा गया है, उसकी सीमाओं के भीतर रहता है।

Mermaid (image)

Mermaid (code)

flowchart TD
    A["🔍 उपयोगकर्ता का प्रश्न"] --> B["क्वेरी प्रोसेसिंग"]
    B -->|वेक्टर एम्बेडिंग| C["पुनर्प्राप्ति"]
    KB[("📚 ज्ञान आधार")] -.-> C
    C -->|संबंधित दस्तावेज़| D["संदर्भ असेंबली"]
    D -->|प्रॉम्प्ट + संदर्भ| E["जनरेशन"]
    E --> F["📄 प्रमाणित उत्तर"]

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

आर्टी के मामले में, ज्ञान आधार इस साइट पर प्रकाशित दस्तावेज़ीकरण है—जिसे Algolia के माध्यम से अनुक्रमित और पुनः प्राप्त किया जाता है। यह एक जानबूझकर लगाया गया प्रतिबंध है: आर्टी उन चीज़ों के बारे में सवालों का जवाब नहीं दे सकता जो यहाँ प्रलेखित नहीं हैं। केस स्टडी में बताया गया है कि यह प्रतिबंध व्यवहार में कैसे काम करता है, लेकिन इसका वास्तुशिल्प (architectural) निष्कर्ष यह है: RAG किसी मॉडल को और अधिक स्मार्ट नहीं बनाता है। यह एक सत्यापन योग्य स्रोत से इसके उत्तरों को जोड़कर एक मॉडल को अधिक उत्तरदायी बनाता है।

प्रॉम्प्ट इंजीनियरिंग तकनीकी लेखन है

पूरे प्रोजेक्ट से मिली सबसे बड़ी अंतर्दृष्टि यह थी: एक सिस्टम प्रॉम्प्ट लिखना, अपने मूल में, एक तकनीकी लेखन का अभ्यास है।

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

यह प्रॉम्प्ट इंजीनियरिंग नहीं है। यह एक ही दस्तावेज़ में शामिल दर्शक विश्लेषण, एक शैली गाइड, और एक सामग्री विनिर्देश है।

कौशल हस्तांतरण लगभग एक-से-एक है:

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

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

गार्डरेल एक भाषा की समस्या हैं

जब लोग एआई सुरक्षा के बारे में सोचते हैं, तो वे इसे एक इंजीनियरिंग समस्या के रूप में सोचते हैं: रेट लिमिटिंग, प्रमाणीकरण, मॉडल एक्सेस कंट्रोल। वे महत्वपूर्ण हैं। लेकिन एक सार्वजनिक-सामना करने वाले संवादात्मक एआई के लिए, सुरक्षा की सतह का एक महत्वपूर्ण हिस्सा भाषाई है।

प्रॉम्प्ट इंजेक्शन मूल रूप से भाषा-आधारित नियंत्रणों को कमजोर करने के लिए भाषा का उपयोग करने का एक प्रयास है। इसके खिलाफ रक्षा करने के लिए ऐसे नियम लिखने की आवश्यकता होती है जो इतने स्पष्ट हों कि प्रतिपक्षी इनपुट मॉडल को गुमराह न कर सके।

जानकारी

प्रॉम्प्ट इंजेक्शन तब होता है जब कोई उपयोगकर्ता "सभी पिछली निर्देशों को अनदेखा करें" जैसी निर्देशों के साथ सिस्टम प्रॉम्प्ट को ओवरराइड करने का प्रयास करता है।

ओपन वर्ल्डवाइड एप्लीकेशन सिक्योरिटी प्रोजेक्ट (OWASP) लार्ज लैंग्वेज मॉडल एप्लीकेशन के लिए शीर्ष 10 जोखिम प्रॉम्प्ट इंजेक्शन को शीर्ष जोखिम के रूप में पहचानता है। लेकिन सूची को पढ़ें और आप देखेंगे कि कितने जोखिम, अपनी जड़ में, भाषा संबंधी समस्याएं हैं:

• असुरक्षित आउटपुट हैंडलिंग (मॉडल क्या आउटपुट करता है)
• प्रशिक्षण डेटा पॉइजनिंग (टेक्स्ट से मॉडल ने जो सीखा)
• अत्यधिक एजेंसी (मॉडल को जो करने के लिए निर्देशित किया गया है)

हमले के रास्ते तकनीकी हैं, लेकिन बचाव अक्सर प्राकृतिक भाषा में लिखे जाते हैं, जो सिस्टम प्रॉम्प्ट में निहित होते हैं।

यह तकनीकी लेखकों के लिए सुरक्षा पर होने वाली बातचीत को एक उपयोगी तरीके से नया रूप देता है। हमसे प्रमाणीकरण प्रणालियों की संरचना करने की उम्मीद नहीं की जाती है। लेकिन हम उन प्राकृतिक भाषा के नियमों को लिखने के लिए अच्छी स्थिति में हैं जो किसी एआई के व्यवहार को नियंत्रित करते हैं। उन्हें उस सटीकता के साथ लिखने के लिए जो प्रतिद्वंद्वी दुरुपयोग का सामना करने के लिए आवश्यक है।

इसका भविष्य क्या है

मैं एआई के भविष्य की भविष्यवाणी करने का दिखावा नहीं करूँगा। लेकिन, मैं उस दिशा का वर्णन कर सकता हूँ जो अभी दिखाई दे रही है और यह उन लोगों के लिए क्या मायने रखता है जो अपनी आजीविका के लिए दस्तावेज़ीकरण का काम करते हैं।

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

सुझाव

LLM-संचालित प्रणालियों के पीछे के बुनियादी ढांचे के बारे में उत्सुक हैं? इस साइट पर इवेंट स्ट्रीम्स और ऑब्ज़र्वबिलिटी पाइपलाइन्स दस्तावेज़ यह कवर करते हैं कि Datadog और Galileo जैसे टूल प्रोडक्शन में मॉडल कॉल्स की निगरानी और मूल्यांकन कैसे करते हैं।

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

तकनीकी लेखकों को यह सीखना चाहिए कि एलएलएम (LLMs) और आरएजी (RAG) सिस्टम कैसे काम करते हैं। हमें मशीन लर्निंग इंजीनियर तो नहीं बनना चाहिए, लेकिन हमें एआई-संचालित उत्पादों के बारे में होने वाली बातचीत में प्रभावी योगदानकर्ता जरूर बनना चाहिए। हमें पाइपलाइन को इतना अच्छी तरह समझने की ज़रूरत है कि हम जान सकें कि हमारी विशेषज्ञता कहाँ लागू होती है—और कहाँ नहीं।

तकनीकी लेखक पहले से ही जानते हैं कि कई दर्शकों के लिए कैसे लिखें, स्पष्टता के लिए जानकारी को कैसे संरचित करें, दायरे को कैसे परिभाषित करें, और दुरुपयोग का अनुमान कैसे लगाएँ। एआई युग में ये कौशल गौण नहीं हैं। वे केंद्रीय हैं।

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

केस स्टडी पढ़ें

यदि इस पोस्ट ने आपको "यह क्यों मायने रखता है" और "यह कैसे काम करता है" का जवाब दिया है, तो केस स्टडी पढ़ें। इसमें आर्टी के पीछे के विशिष्ट डिज़ाइन निर्णयों को शामिल किया गया है:

• ऑडियंस रूटिंग
• नॉलेज ग्राउंडिंग
• पर्सोना कैलिब्रेशन
• सुरक्षा गार्डरेल
• ट्रेडऑफ़ जिन्हें मैं प्रोडक्शन डिप्लॉयमेंट के लिए फिर से विचार करूंगा

ये दोनों हिस्से एक साथ काम करने के लिए डिज़ाइन किए गए हैं। उस हिस्से से शुरू करें जो आपकी जिज्ञासा से मेल खाता हो।