AI Humanization

AI टेक्स्ट को मानवीय कैसे बनाएं: संपूर्ण मार्गदर्शिका

AI टेक्स्ट को हाथ से मानवीय बनाने का एक व्यावहारिक मार्गदर्शन, वास्तविक पहले और बाद के संपादनों के साथ, इस बात का ईमानदार आकलन कि मैनुअल संपादन क्या ठीक नहीं कर सकता, और यह कि AI humanizer tool समय की बचत के लिहाज़ से कहाँ उपयोगी है।

9 min
Editor's markup on a paragraph of AI generated text, showing how to humanize AI text by hand

ChatGPT से एक पहला मसौदा एक मिनट से कम समय में वापस आ जाता है, साफ़ पढ़ा जाता है, और वही कहता है जो आप कहना चाहते थे। समस्या यह है कि वह भी हर उस दूसरे मसौदे की तरह पढ़ा जाता है जिसे ChatGPT वापस देता है, वही लय, वही सुरक्षित शब्दावली, वही आदत कि वह अभी-अभी लिखे गए शीर्षक को फिर से दोहराता है। AI text को humanize करना सीखना वास्तव में उसी एकरूपता को, वाक्य दर वाक्य, तब तक हटाना सीखना है, जब तक वह किसी detector या ऐसे पाठक तक पहुँचे जिसने इसके जैसे सौ मसौदे पहले ही देख रखे हों।

AI text को humanize करने का अर्थ है मशीन के मसौदे को इस तरह संपादित करना कि उसकी वाक्य-लय, शब्द-चयन और संरचना एक व्यक्ति की लेखन-शैली की तरह पढ़ी जाए, न कि language model के सर्वोत्तम अनुमान के सांख्यिकीय औसत की तरह। इस संपादन का कुछ भाग मिनटों में हो जाता है। पूरे दस्तावेज़ में इसका कुछ भाग इतना नीरस होता है कि कोई tool सचमुच अपना स्थान अर्जित कर लेता है। यह मार्गदर्शिका दोनों को उसी क्रम में कवर करती है जो सहायक है, पहले संपादन, फिर वह स्थान जहाँ AI humanizer tool वह उठा लेता है जिसे manual editing पूरा नहीं कर पाती।

जो कोई UK वर्तनी के साथ "humanise AI" खोजता है, उसके लिए एक त्वरित नोट, तकनीक बिल्कुल समान है, केवल अक्षर बदलते हैं।

AI text हर बार एक जैसा क्यों सुनाई देता है?

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

यह सब हमारे सहायक लेख में विस्तार से समझाया गया है, AI detectors कैसे काम करते हैं। यहाँ हम उस बात पर ध्यान देते हैं जिसे समझना महत्वपूर्ण है, नीचे दिया गया हर संपादन एक ऐसे पैटर्न को तोड़ता है जिसे model अनिवार्य रूप से बनाता। इनमें से कोई भी इस तथ्य को नहीं छिपाता कि इसमें model शामिल था, क्योंकि यह ऐसा कुछ नहीं है जो sentence-level संपादन कर सके। detectors प्रतिशत दिखाने से पहले जिन दो सबसे सामान्य metrics की गणना करते हैं, वे perplexity और burstiness हैं।

लय तोड़ें, वाक्य की लंबाई और संरचना

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

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

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

उन शब्दों को हटाएँ जो इसे उजागर करते हैं

कुछ शब्द मशीन-जनित प्रारूपों में मानव-लिखित पाठ की तुलना में बहुत अधिक बार दिखाई देते हैं, इसलिए नहीं कि वे गलत हैं, बल्कि इसलिए कि औपचारिक रजिस्टर के लिए मॉडल के प्रायिकता वितरण के हिसाब से वे बिल्कुल उपयुक्त होते हैं। help के बजाय facilitate। strong के बजाय robust। many के बजाय myriad। show के बजाय underscore। इनमें से कोई भी गलत नहीं है। ये सभी बस उपलब्ध सबसे सुरक्षित, सबसे औसत विकल्प हैं, और यही कारण है कि मॉडल सबसे पहले इन्हीं की ओर जाता है।

एक सपाट वाक्य इस प्रकार पढ़ा जाता है: "The study employed a robust methodology to facilitate a wide-ranging understanding of the myriad factors involved." वही दावा, उन शब्दों में जिन्हें कोई व्यक्ति वास्तव में चुनेगा: "The study used a mixed-methods design to work out which of several factors mattered most." दूसरी संस्करण में कुछ भी कम सटीक नहीं है। वह बस कम औसत है।

robust को strong से बदलने से वाक्य की लंबाई नहीं बदलेगी और न ही उस लय को छुएगा जिसे कोई detector वास्तव में अंकित कर रहा है। केवल शब्द बदलने से अपने आप बहुत कुछ नहीं होने वाला। यह जानना आपको इस बात से सावधान रहने में मदद करेगा कि thesaurus का एक दौर आपको आगे की संपादन-प्रक्रिया के बिना ही पूरी तरह वहाँ पहुँचा देगा। यह एक मानव पाठक को यह नोटिस करने में मदद करेगा कि गद्य कम प्रयास कर रहा है। ऊपर किए गए संरचनात्मक संपादन फिर भी इसके साथ-साथ होने ही चाहिए। किसी अनुच्छेद को AI word cleaner से गुजारने पर शब्द-स्तर के संकेत जल्दी पकड़ में आ जाते हैं।

विराम-चिह्न की उन आदतों को ठीक करें जिन्हें detector और पाठक दोनों नोटिस करते हैं

विराम-चिह्न की अपनी एक पहचान होती है। यह एक या दो चिह्नों पर अत्यधिक निर्भर रहता है, और उन चिह्नों का उपयोग सामान्य लेखन की तुलना में कहीं अधिक बार करता है, सबसे अधिक एक dash का, जिसे एक सार्वभौमिक संयोजक की तरह इस्तेमाल किया जाता है, जहाँ comma, full stop या colon भी उतना ही उपयुक्त होता। जब कोई अनुच्छेद हर तीसरे वाक्य में उसी चिह्न की ओर बार-बार बढ़ने की कोशिश करता है, तो वह दोहरावपूर्ण हो जाता है और शैली के बजाय एक आदत जैसी ध्वनि देने लगता है।

Semicolons और colons का भी इसी तरह अत्यधिक उपयोग होता है, आमतौर पर दो उपवाक्यों को जोड़ने के लिए, जो दो वाक्यों के रूप में अधिक स्वाभाविक रूप से पढ़े जाते। "The results were mixed; some participants improved while others showed no change" व्याकरण की दृष्टि से ठीक है और शैली की दृष्टि से थका हुआ है। दो वाक्य वही जानकारी अधिक सहजता से देते हैं: "The results were mixed. Some participants improved. Others showed no change at all." किसी अनुच्छेद को ज़ोर से पढ़ने पर इसका अधिकांश भाग पकड़ में आ जाता है, क्योंकि कान आँख से पहले दोहराई गई लय को नोटिस कर लेता है।

em dash remover इस चरण के यांत्रिक भाग को कुछ ही सेकंड में संभाल देता है। TextPulse की अपनी house style इस चिह्न को पूरी तरह निषिद्ध करती है, और यह मार्गदर्शिका उसी नियम का पालन करती है। निर्णय का प्रश्न, कि कोई वाक्य एक उपवाक्य के रूप में बेहतर काम करता है या दो के रूप में, फिर भी एक व्यक्ति की आवश्यकता रखता है।

Humanize your own paper

Transform your AI-assisted text and make it sound human, without touching important words or citations.

Get started free

सामान्य पंक्तियों को विशिष्ट पंक्तियों से बदलें

इस सूची में अंतिम संपादन सबसे अधिक समय लेता है, और सबसे अधिक महत्वपूर्ण भी है। एक language model को आपके वास्तविक प्रोजेक्ट की कोई स्मृति नहीं होती, इसलिए वह उपलब्ध सबसे सुरक्षित वाक्य-रचना पर लौट आता है, सक्षम, अस्पष्ट, और उसी विषय पर लगभग किसी भी शोधपत्र पर लागू होने योग्य।

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

यह भी वह संपादन है जो एक language model आपके लिए नहीं कर सकता, humanizer tool सहित। एक tool आपके वाक्य की लंबाई बदल सकता है और आपकी शब्दावली को अदल-बदल सकता है, लेकिन जब वह रोचक घटना हुई थी तब वह कमरे में मौजूद नहीं था, इसलिए वह आपको वह विवरण नहीं दे सकता जो आपने उसे कभी दिया ही नहीं। फिर से rewriter के माध्यम से जाने के बजाय, अपनी notes पर लौटें।

मैनुअल संपादन क्या ठीक नहीं कर सकता

ऊपर का हर संपादन निःशुल्क है और एक ही अनुच्छेद पर कुछ मिनट लेता है। वास्तविक समस्या लंबाई है। discussion post पर पाँच-अनुच्छेद का उत्तर हाथ से पंद्रह मिनट का काम है। चालीस-पृष्ठ का thesis chapter, उसी सावधानी के साथ पुनर्लिखित, कई दिनों का काम है, और लगभग किसी के पास एक ही chapter के लिए इतना समय नहीं होता।

नीचे दी गई तालिका एक planning guide है, माप नहीं। समय औसत academic prose के लिए कार्यकारी अनुमान हैं, और वे लेखन की घनता के साथ बदलते हैं।

मैनुअल संपादनयह किसे ठीक करता हैसमय लागतयह किसे ठीक नहीं करेगा
वाक्य की लंबाई और संरचना में विविधता लाएँएकसमान लय, सबसे मजबूत burstiness संकेतप्रति 1,000 शब्दों पर लगभग 10 से 15 मिनटशब्द-स्तर के संकेत, जिन्हें केवल लय में परिवर्तन छूता भी नहीं
सामान्य शब्दावली हटाएँवे अलग-अलग शब्द जिन्हें एक सावधान पाठक आधा-सा नोटिस करता हैfind पास के साथ 5 से 10 मिनटवाक्य की वह सपाट लय जो शब्द के आसपास बैठी रहती है
विराम-चिह्न की आदतें ठीक करेंदंड या अर्धविरामों की श्रृंखला जैसे दोहराए गए चिह्नलगभग 5 मिनटसतह के नीचे की कोई भी चीज, यह पास केवल सौंदर्यात्मक है
विशिष्ट विवरण जोड़ेंसामान्य दावे जो विषय पर किसी भी पेपर में हो सकते हैंप्रति 1,000 शब्दों पर 20 से 30 मिनट, यदि आपको विवरण खोजकर निकालना पड़े तो अधिककुछ नहीं, यदि आपके पास वास्तव में जोड़ने के लिए विवरण है
किसी humanizer tool से पूरा पास चलाएँपूरे दस्तावेज़ में एकरूपता, तेज, लंबे मसौदों पर प्रथम पास के रूप में उपयोगीएक मिनट से कम, साथ में आपकी अपनी समीक्षा का समयकिसी विशिष्ट detector के विरुद्ध निश्चितता, और कोई भी विवरण जो tool को कभी दिया ही नहीं गया

पाँचों पंक्तियों में से कोई भी लंबे दस्तावेज़ को पूरी तरह वहाँ तक नहीं पहुँचाती। अगला खंड इसी के लिए है।

जहाँ एक AI humanizer tool वास्तव में अपना स्थान अर्जित करता है

एक समर्पित AI humanizer tool (कभी-कभी इसे ChatGPT humanizer के रूप में बेचा जाता है, क्योंकि अधिकांश मसौदे यहीं से शुरू होते हैं) इन संपादनों को एक साथ लागू करेगा, लय और शब्दावली, पूरे दस्तावेज़ पर, उस समय में जितना कॉफी बनाने में लगता है, न कि पंद्रह मिनट में एक अनुच्छेद। चाहे इन्हें जो भी कहा जाए, AI humanizer tool, AI text humanizer, AI paragraph rewriter या AI to human text converter, अच्छे वाले वही करेंगे: वाक्य के आकार और शब्द-चयन को बदलना, जबकि अर्थ को बनाए रखना। शब्दांकन कितनी दूर तक बदलता है, यह एक अंश से दूसरे अंश में भिन्न होता है।

TextPulse इस तरह काम करता है। यह एक पूर्ण मसौदे को पुनर्लेखित करता है और उन्हीं संकेतों से गणना किए गए एक अनुमानित Human Score को लौटाता है, न कि यह वादा कि कोई विशिष्ट detector उसे पास कर देगा। यह सावधानी केवल हमारे लिए विशिष्ट नहीं है, Grammarly के अपने AI humanizer पृष्ठ पर स्पष्ट रूप से कहा गया है कि उसका tool "not intended to bypass AI detectors," जो किसी भी humanizing pass के ईमानदार रूप से किए जा सकने वाले वादे का उचित वर्णन है। यदि आप यहाँ AI text को undetectable बनाने की तलाश में आए हैं, तो ईमानदार उत्तर यह है कि कोई भी संपादन और कोई भी tool इसकी गारंटी नहीं दे सकता, क्योंकि detectors एक दूसरे से असहमत होते हैं और बिना सूचना के बदलते रहते हैं।

एक जिम्मेदार AI humanizer tool एक तेज़ पहला pass और काम करने के लिए एक score दे सकता है। लक्ष्य AI score को कम करना है, पैटर्न को कम समान बनाकर, न कि संख्या को सीधे धोखा देना। एक AI rewrite का उद्देश्य दस्तावेज़ स्तर पर वही करना है जो एक सावधान हाथ से किया गया संपादन अनुच्छेद स्तर पर करता है। ऊपर वाले section से विशिष्ट, मानवीय विवरण हाथ से जोड़ें, क्योंकि tool उस कमरे में नहीं था जब वह रोचक बात हुई थी।

यदि आप किसी deadline वाले project पर काम कर रहे हैं, तो आप AI humanizer for students का उपयोग कर सकते हैं, जो वही mechanism उपयोग करता है लेकिन academic conventions को पहले से ध्यान में रखकर। क्रम tool से अधिक महत्वपूर्ण है, क्योंकि सावधान prose में लिखा गया एक generic sentence फिर भी generic ही रहता है। आपको फिर भी specific-detail pass हाथ से करना होगा।

अगले दस मिनट में AI text को humanize कैसे करें

ऊपर दिए गए edits को क्रम में रखें और वे एक छोटी routine बनाते हैं, न कि याद करने योग्य checklist। एक page, लगभग 300 to 400 words, पर लागू करने पर, दस मिनट कैसे विभाजित होते हैं, यह यहाँ है।

  1. अनुच्छेद को एक बार ज़ोर से पढ़ें, और हर उस वाक्य को चिह्नित करें जो लंबाई या आकार में अपने पड़ोसी के समान लगता है।
  2. दो या तीन सबसे सपाट वाक्यों को तोड़ें, और प्रत्येक में मुख्य दावे को शुरुआत में ले आएँ।
  3. facilitate, robust, myriad और underscore जैसे तैयारशुदा शब्दों को खोजें, और उन्हें उस सरल शब्द से बदलें जिसे आप वास्तव में बोलते हैं।
  4. दोहराए गए डैश और सेमीकोलन हटाएँ या बदलें, और हर सुधार को ज़ोर से पढ़कर जाँचें कि वह अभी भी स्वाभाविक लगता है।
  5. प्रत्येक अनुच्छेद में एक विशिष्ट विवरण फिर से जोड़ें, एक संख्या, एक नाम, एक सीमा, जिसे केवल वही व्यक्ति जानता होगा जिसने वह काम किया हो।
  6. यदि मसौदा एक या दो पृष्ठों से लंबा हो जाता है, तो उसे पहले चरण में एक AI humanizer tool से गुज़ारें, फिर जो भी अभी भी सपाट पढ़ा जाए उस पर चरण एक से पाँच दोहराएँ।

यहाँ कई सूत्र अपने-अपने पृष्ठों में खुलते हैं। क्या ये उपकरण बिल्कुल काम करते हैं और क्या इन्हें ग्रेड किए गए काम में उपयोग करना सुरक्षित है अलग प्रश्न हैं जिनके अलग उत्तर हैं, और Turnitin humanized text के साथ क्या करता है जब वह जमा कर दिया जाता है, एक तीसरा प्रश्न है। अधिक संकीर्ण समस्याओं के लिए AI score कम करने और ChatGPT output को अनुच्छेद दर अनुच्छेद संपादित करने पर चरण-दर-चरण लेख उपलब्ध हैं।

इनमें से कोई भी चीज़ ऐसा लेखन नहीं बनाती जो undetectable हो, और कोई ईमानदार मार्गदर्शिका यह वादा नहीं करनी चाहिए कि वह ऐसा करती है। यह ऐसा लेखन बनाती है जो ऐसा लगता है जैसे आपने सचमुच दस मिनट लगाए, और यही अधिक टिकाऊ लक्ष्य है, एक पाठक विशिष्ट, असमान गद्य पर भरोसा करता है, चाहे कोई detector उसे कभी देखे या नहीं।

Frequently Asked Questions

हाँ, किसी भी छोटी सामग्री के लिए। AI टेक्स्ट को हाथ से मानवीय कैसे बनाएं, यह जानना चार संपादनों पर निर्भर करता है, वाक्य लंबाई में विविधता लाएँ, सामान्य शब्दावली हटाएँ, दोहराए गए विराम-चिह्न ठीक करें, और प्रति अनुच्छेद एक विशिष्ट विवरण वापस जोड़ें। एक पृष्ठ में 10 से 15 मिनट लगते हैं। सीमा लंबाई है, लंबे दस्तावेज़ में वही सावधानी कई घंटों का काम बन जाती है, और वहीं tool अपना मूल्य साबित करने लगता है।

Mark

Content strategist at TextPulse, here since the company started. Mark writes the product and technical coverage: how the humanizer works under the hood, what changes in each release, and what a specification actually means for your writing. His reviews of writing software come from using them on real documents rather than reading a feature list.