LLM आउटपुट्स को ‘मानवीय’ बनाना बेवकूफ़ी है

Large language model उपयोगकर्ता increasingly verbose, metaphor-heavy outputs के खिलाफ़ pushback कर रहे हैं, जो human readability की बजाय “agentic” self-talk के लिए optimized लगते हैं। कई लोग extra prompts, skills, या अलग “translation” agents जोड़कर jargon हटाने, simplified technical English लागू करने, या terse, engineering-style responses मांगने की बात करते हैं, हालांकि उन्हें चिंता है कि इससे model की internal reasoning या उपयोगी detail कम हो सकती है। इसके पीछे एक व्यापक तनाव है: LLMs को एक साथ personable भी बनाया जा रहा है और अन्य agents के साथ coordinate करने योग्य भी, जबकि power users मुख्यतः precise, low-friction tools चाहते हैं—और models को anthropomorphize करने या clarity की बजाय engagement के लिए optimize करने को लेकर skeptical हैं.

“मानवीय” / वाचाल आउटपुट से झुंझलाहट

  • कई टिप्पणीकारों को हाल के frontier models increasingly unreadable लगते हैं: अलंकृत, jargon‑dense, metaphor‑heavy, और आत्म‑प्रशंसात्मक।
  • लंबे explanations “slop” जैसे लगते हैं जो असली जवाब को ढक देते हैं, खासकर code review या debugging में।
  • कुछ लोगों के लिए यह सचमुच productivity loss और irritant बन जाता है, खासकर ADHD users के लिए जिन्हें text की दीवारों से दिक्कत होती है।
  • कई लोगों को लगता है कि models अब LinkedIn posts या corporate marketing की तरह बोलते हैं, experts की तरह नहीं।

वांछित शैली और उपयोग के मामले

  • बहुतों की strong preference terse, technical, engineering‑style responses के लिए है: concise, factual, minimal emotional tone।
  • कुछ लोग अब भी playful या colloquial styles पसंद करते हैं और explicitly वैसा prompt करते हैं; demand heterogeneous है।
  • कुछ लोगों के लिए “humanization” मुख्यतः UX/engagement feature है; serious work के लिए वे impersonal tool चाहते हैं, faux friend नहीं।

Prompting, Skills, और Workarounds

  • आम strategies:
    • Explicit instructions: “be terse/brief,” “ELI5,” “no metaphors,” “no chit-chat,” “engineering tone,” “no first person।”
    • Simplified Technical English या ऐसे skills का उपयोग जो outputs को clearer, simpler language में rewrite करें, अक्सर केवल final step के रूप में।
    • अलग “worker” model और “translator” model: agents अपनी शैली में काम करते हैं; एक liaison agent humans के लिए rewrite करता है।
    • Two-step flows: model से think/solve करवाना, फिर अलग से summarize या visualize करना।

Lossiness, Internal Reasoning, और Style Constraints

  • Article का दावा: style instructions (short, simple, non-jargony) continuous compression की तरह काम करती हैं और inherently lossy होती हैं, जिससे multi-step reasoning और agent performance को नुकसान हो सकता है।
  • कुछ टिप्पणीकार सिद्धांत रूप में इससे सहमत हैं, लेकिन वही loss चाहते हैं: वे “paragraph per line of code” commentary से बचने के लिए high-level, lossy summaries पसंद करते हैं।
  • दूसरे लोग तर्क देते हैं कि models पहले से internal chain-of-thought और user-facing text के बीच “code-switch” करते हैं, इसलिए clearer prose मांगने से underlying reasoning को शायद meaningful नुकसान नहीं होता।
  • कई लोग नोट करते हैं कि कोई भी style instruction task instructions से compete करती है और behavior को perturb करती है, लेकिन यह कितना harmful है, इसका evidence अभी स्पष्ट नहीं है।

Anthropomorphism और Tone की Ethics

  • LLMs को इंसानों की तरह treat करने पर बहस:
    • कुछ लोग politeness पर इसलिए ज़ोर देते हैं क्योंकि वे human हैं, model नहीं।
    • दूसरे warn करते हैं कि anthropomorphizing वही है जो vendors चाहते हैं, क्योंकि इससे emotional manipulation और over-trust को बढ़ावा मिलता है।
  • एक recurring theme: LLMs को सबसे पहले powerful tools की तरह treat और design किया जाना चाहिए; बहुतों की नज़र में “personality” distraction या dark pattern है।