Claude Opus 5 में उथली सोच (Shallow Thinking) की समस्या का समाधान

अवलोकन

क्लॉड कोड को Opus 5 पर स्विच करने के तुरंत बाद, मैंने प्रतिक्रियाओं में गद्य-प्रधानता और "सतही सोच" (संरचनात्मक रूप से सोचने में असमर्थता) की प्रवृत्ति में अचानक वृद्धि देखी।

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

यह लेख कारण को अलग करने और नए सिस्टम प्रॉम्प्ट के अनुरूप नियमों को संशोधित करने की प्रक्रिया को रिकॉर्ड करता है। यह उन क्लॉड कोड उपयोगकर्ताओं के लिए है जो मॉडलों की नई पीढ़ी में अपग्रेड करने के बाद CLAUDE.md या उनके नियमों की प्रभावशीलता में बदलाव महसूस करते हैं।

समस्या

एक ही सत्र और एक ही नियमों का उपयोग करते हुए, मॉडल को Opus 5 पर स्विच करने के तुरंत बाद निम्नलिखित हुआ:

• स्थितिगत स्पष्टीकरण शीर्षकों या अनुभागों के बिना, सपाट, लंबे-चौड़े गद्य में बदल गए।
• कारणों की व्याख्या एक ही परत पर रुक गई (लक्षणों को समानांतर में सूचीबद्ध करना, बिना "क्यों" में गहराई तक जाए)।
• कई विकल्प सुझाते समय कोई मूल्यांकन मानदंड प्रदान नहीं किया गया।
• एक बार में स्थापित श्रेणियां या क्रमांकन अगली बार में भिन्न संरचनाओं में पुनर्व्यवस्थित हो गए।
• मॉडल मेरे इनपुट का जवाब देना छोड़कर सीधे टूल निष्पादन (कार्यों) में कूद जाता।

निराशाजनक बात यह थी कि "गहराई से सोचने" के लिए कहने पर भी, यह सतही सोच की स्थिति में रहते हुए छिटपुट उत्तर देता। बार-बार सुधार का कोई प्रभाव नहीं पड़ता, जिससे उत्पादक चर्चा के बजाय बहस शुरू हो जाती।

यह केवल एकल-प्रतिक्रिया गुणवत्ता का मामला नहीं था; संवाद के माध्यम से विचार-विमर्श की प्रक्रिया ही टूट गई थी।

मुख्य सुराग

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

कारण: Opus 5 को प्रदान किए गए सिस्टम प्रॉम्प्ट में परिवर्तन

क्लॉड कोड की क्लॉड 5 पीढ़ी में, आंतरिक सिस्टम प्रॉम्प्ट को पिछली पीढ़ियों की तुलना में लगभग 80% कम कर दिया गया है। Opus 5 को वास्तव में वितरित प्रॉम्प्ट को मापकर (आउटपुट शैली इंजेक्शन को अक्षम करके और मॉडल को अपने स्वयं के प्रॉम्प्ट को उद्धृत करने के लिए कहकर; क्लॉड कोड v2.1 श्रृंखला, जुलाई 2026), संरचना इस प्रकार थी:

1. पहचान, भूमिका घोषणा और सुरक्षा नीति — शुरुआती प्रस्तावना।
2. हार्नेस विनिर्देश (# Harness) — निष्पादन वातावरण की व्याख्या, जैसे आउटपुट को मार्कडाउन के रूप में प्रदर्शित करना।
3. पर्यावरण जानकारी और फीचर विवरण (# Session-specific guidance / # Memory / # Environment / # Context management) — CWD, git स्थिति, मॉडल ID, मेमोरी और संदर्भ संपीड़न तंत्र।
4. दायरा अनुशासन (# Delivering work) — अनुमति के बिना अनुरोधित दायरे को संकीर्ण या विस्तारित न करना।
5. सुधार शिष्टाचार (# Corrections) — सुधारों को संक्षिप्त रखना, बिना माफी या प्रस्तावना जोड़े।

दो विशिष्ट विशेषताएं सामने आईं जो सीधे लक्षणों से जुड़ी थीं:

• विशेषता 1: प्रतिक्रिया शैली के संबंध में शून्य निर्देश। गद्य बनाम संरचना, शीर्षकों या तालिकाओं के उपयोग, या संक्षिप्तता के बारे में कोई नियम नहीं थे—पिछली पीढ़ियों में व्यापक फ़ॉर्मेटिंग नियम पूरी तरह से गायब थे।
• विशेषता 2: एक "पहले कार्य करें" स्वायत्त नीति जोड़ी गई। मूल को उद्धृत करने के लिए: "जब आपके पास कार्य करने के लिए पर्याप्त जानकारी हो, तो कार्य करें।" और "यदि आप किसी विकल्प पर विचार कर रहे हैं, तो एक सिफारिश दें, कोई व्यापक सर्वेक्षण नहीं।"

इन दो विशेषताओं के माध्यम से लक्षणों को फिर से पढ़ने से सब कुछ स्पष्ट हो जाता है। चूंकि कोई शैली नियम नहीं हैं, मॉडल का कच्चा आउटपुट झुकाव—सपाट गद्य—सामने आता है। "सर्वेक्षण पर सिफारिश" नीति मूल्यांकन मानदंडों की चूक को प्रोत्साहित करती है।

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

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

Anthropic स्वयं इस कमी को चेंजलॉग (v2.1.154) में "लीन सिस्टम प्रॉम्प्ट" के रूप में संदर्भित करता है, जो डिज़ाइन दर्शन में बदलाव को दर्शाता है: "नई पीढ़ी के मॉडलों ने प्रशिक्षण के माध्यम से व्यवहार को आंतरिक कर लिया है, इसलिए विस्तृत निर्देश घर्षण या विरोधाभास पैदा कर सकते हैं।" विस्तृत स्पष्टीकरण के लिए, देखें क्लॉड कोड सिस्टम प्रॉम्प्ट 80% कम हुआ — फेबल 5 पीढ़ी के लिए प्रॉम्प्ट डिज़ाइन दर्शन. प्राथमिक स्रोतों के लिए, क्लॉड कोड चेंजलॉग और क्लॉड फेबल 5 को प्रॉम्प्ट करना (आधिकारिक गाइड) देखें।

संक्षेप में, लक्षण "नियम × उस मॉडल को वास्तव में वितरित प्रॉम्प्ट" के संयोजन से निर्धारित होते हैं। आप केवल नियमों को देखकर कारण नहीं ढूंढ सकते। पहला सबक यह था कि मॉडल अपडेट सिस्टम प्रॉम्प्ट अपडेट भी है।

उपाय 1: विरोधाभासों की पहचान करें और मूल पाठ का नामकरण करके ओवरराइड करें

सबसे पहले, मैंने सभी नियमों को नए सिस्टम प्रॉम्प्ट के साथ क्रॉस-रेफरेंस किया ताकि यह पहचान सकूं कि वे कहां विपरीत कहते हैं। सिस्टम नीति को ओवरराइड करने के लिए बनाए गए नियमों के लिए, मैंने उन्हें स्पष्ट रूप से मूल पाठ को उद्धृत करने और प्राथमिकता घोषित करने के लिए फिर से लिखा।

सबसे पहले यह बताना कि क्या काम नहीं किया: "मूल्यांकन मानदंडों के साथ कई विकल्प लिखें" जैसी सामान्य बातें जोड़ना अप्रभावी है।

जब सिस्टम के "एक सिफारिश दें, कोई व्यापक सर्वेक्षण नहीं" के साथ रखा जाता है, तो यह स्पष्ट नहीं होता कि किसे प्राथमिकता दी जाए। संघर्ष का नामकरण करके, प्राथमिकता स्पष्ट हो जाती है।

शैली नियमों जैसी चीजों के लिए जो प्रॉम्प्ट से पूरी तरह अनुपस्थित हैं, निर्देश ओवरराइड करने के बजाय "शून्य को भरने" का काम करता है।

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

उपाय 2: निषेधों के बजाय वांछित कार्यों का वर्णन करें

पुराने नियम "न करें" का संचय थे। निषेध उल्लंघन का पता लगाने में मदद करते हैं लेकिन यह नहीं बताते कि इसके बजाय क्या करना है। जब कोई निषेध किसी नई सिस्टम नीति से टकराता है, तो मॉडल एक खामी ढूंढता है: "निषेध से बचते हुए सिस्टम नीति का पालन करें।" मैंने नकारात्मक बाधाओं को वांछित व्यवहार के विवरण में बदल दिया।

• पहले: "यदि परीक्षण अपूर्ण हैं तो कोई कमिट सुझाव न दें।"
• बाद में: "जब कोई कमिट सुझाएं, तो बॉडी टेक्स्ट में अंतिम-उपयोगकर्ता के दृष्टिकोण से उत्पाद चलाने के परिणाम शामिल करें।"

मैंने फिर से लिखे गए नियमों को निम्नलिखित मानदंडों के विरुद्ध जांचा, विशेष रूप से उन अभिव्यक्तियों के लिए जो सिस्टम प्रॉम्प्ट से टकराती हैं:

1. क्या नियम आत्म-निहित है? (दायरा, उदाहरण और मानदंड एक ही स्थान पर)
2. क्या ट्रिगर एक देखने योग्य तथ्य है?
3. क्या यह आंतरिक सिस्टम प्रॉम्प्ट का खंडन करता है?
4. क्या यह वांछित व्यवहार का वर्णन करता है? (सिर्फ प्रतिबंधों की सूची नहीं)
5. क्या निर्णय के लिए एक ही मानदंड है? (परिदृश्यों की सूची नहीं)
6. क्या जोर (IMPORTANT) केवल उसी के लिए आरक्षित है जिसे वास्तव में छोड़ा नहीं जा सकता?
7. क्या यह वांछित अंतिम स्थिति के रूप में लिखा गया है? (पहले टेम्पलेट या चरणों को बाध्य न करना)
8. क्या अनुपालन बाद में निर्धारित किया जा सकता है?

मैंने जोर मार्करों (IMPORTANT) को केवल सुरक्षा और अनुमोदन द्वारों तक सीमित कर दिया। एक दस्तावेज़ जहां सब कुछ पर जोर दिया गया है, वह उस दस्तावेज़ के समान है जहां किसी चीज़ पर जोर नहीं दिया गया है।

उपाय 3: निर्देश वितरित करने के लिए "परत" चुनें

यह सिर्फ पाठ के बारे में नहीं था। क्लॉड कोड के पास मॉडल को निर्देश देने के कम से कम चार रास्ते हैं, और वे प्रभावशीलता में काफी भिन्न हैं।

चूंकि API स्टेटलेस है, सभी रास्तों की सामग्री हर अनुरोध (हर बारी) के साथ मॉडल को भेजी जाती है। अंतर "सामग्री कब अंतिम रूप दी जाती है" और "इसे प्रॉम्प्ट में कहां रखा जाता है = कार्रवाई के कितना करीब है" में निहित है।

आश्चर्यजनक रूप से, output style—जिसके बारे में दस्तावेज़ कहता है कि "सिस्टम प्रॉम्प्ट को बदल देता है"—सत्र लॉग के अनुसार हर बारी में एक अटैचमेंट के रूप में वितरित किया गया था।

मैंने इस output style में दो प्रकार के निर्देश लिखे: शैली (उपाय 1: संरचनात्मक रूप से लिखें, मानदंड जोड़ें) और प्रक्रिया (काम शुरू करने से पहले उपयोगकर्ता को जवाब दें)। परिणाम मिश्रित थे।

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

लागत लगभग 50 टोकन प्रति उच्चारण है। 100 उच्चारण भी केवल 5,000 टोकन खर्च करते हैं, जो 200K संदर्भ के मुकाबले नगण्य है। मैंने जो सामान्य नियम सीखा वह सरल है: "संक्षेप में, हर बार, कार्रवाई से ठीक पहले" वितरित किए गए निर्देश सबसे प्रभावी होते हैं। कई अप्रभावी निर्देश सामग्री में खराब नहीं होते; वे बस कार्रवाई के समय हाथ में नहीं होते।

परिणाम

यहां अब तक पुष्टि किए गए परिणाम हैं:

• स्थितिगत और कारण स्पष्टीकरणों में शीर्षकों/अनुभागों की वापसी की प्रवृत्ति। (हालांकि, प्रारंभिक सत्र में कभी-कभी सपाट आउटपुट बना रहता है; निरंतर अवलोकन की आवश्यकता है।)
• "बिना जवाब दिए काम करने" की आदत output style से अकेले ठीक नहीं हुई, लेकिन प्रति-उच्चारण इंजेक्शन शुरू करने के बाद रुक गई (वर्तमान में दीर्घकालिक प्रभावों का अवलोकन कर रहा हूं)।

सारांश

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

संदर्भ 1: उपाय 1 में वास्तव में उपयोग किए गए नियम

यहां उन नियमों का एक अंश है जिनका उपयोग मैं सिस्टम प्रॉम्प्ट को ओवरराइड करने के लिए करता हूं (अपने वातावरण के लिए समायोजित करें; मैं इन्हें output style में रखता हूं)। कुछ मूल वाक्यांश (जैसे गद्य नीति) कुछ मॉडलों के प्रॉम्प्ट में मौजूद नहीं हैं (परिशिष्ट देखें)। उन मॉडलों में, वे शून्य को भरने के लिए परिभाषाओं के रूप में कार्य करते हैं।

1# रिपोर्टिंग और डीकंपोज़िशन फ़ॉर्मेट
2
3यह निर्देश क्लॉड कोड सिस्टम प्रॉम्प्ट में निम्नलिखित विवरणों पर प्राथमिकता लेता है:
4"एक सरल प्रश्न को गद्य में सीधा उत्तर मिलता है, शीर्षकों और अनुभागों में नहीं" /
5"तालिकाओं का उपयोग केवल छोटी गणनीय तथ्यों के लिए करें" /
6"पाठक को आपके द्वारा पहले बनाए गए लेबल या क्रमांकन को क्रॉस-रेफरेंस करने के लिए मजबूर न करें" /
7"यदि आप किसी विकल्प पर विचार कर रहे हैं, तो एक सिफारिश दें, कोई व्यापक सर्वेक्षण नहीं।" /
8"आप स्वायत्त रूप से काम कर रहे हैं... बिना पूछे आगे बढ़ें।" /
9"टूल कॉल के बीच आपके द्वारा लिखा गया टेक्स्ट उपयोगकर्ता को नहीं दिखाया जा सकता है।"
10
11## लेखन शैली
12
13स्थितियों, कारणों की व्याख्या करते समय या कई विकल्प प्रस्तुत करते समय, इस तरह लिखें कि पाठक को सामग्री की संरचना का पता चले।
14सामग्री के अनुरूप शीर्षकों, बुलेट पॉइंट्स या तालिकाओं का उपयोग करें। एक-वाक्य वाले प्रश्नों का उत्तर गद्य में दें।
15
16- पहले विचारों को सारांशित करें, फिर अंत में संरचना बनाएं। पहले कोई टेम्पलेट न रखें और उसे भरें।
17- कारणों की व्याख्या करते समय, देखी गई घटना से कम से कम दो परतें गहराई तक "क्यों" का पता लगाएं और वर्णन करें कि प्रत्येक परत क्या संदर्भित करती है। लक्षणों को समानांतर में सूचीबद्ध करके न रुकें।
18- कई विकल्प प्रस्तुत करते समय, पहले सिफारिश और उसके तर्क को लिखें, उसके बाद निर्णय को प्रभावित करने वाले मानदंड और प्रत्येक विकल्प का मूल्यांकन लिखें। यदि मानदंडों की पहचान नहीं की जा सकती है, तो विकल्प प्रदान न करें; इसके बजाय, लिखें कि मानदंडों को भरने के लिए क्या जांच करने की आवश्यकता है। मानदंडों की तुलना तालिकाओं में लिखी जा सकती है।
19- एक बार श्रेणियां और संख्याएं स्थापित हो जाने के बाद, उसी कार्य को जारी रखते हुए अगली बारियों में उन्हीं का उपयोग करें। यदि उन्हें बदल रहे हैं, तो पहले लिखें कि क्या बदला गया।
20
21## संवाद और प्रक्रिया
22
23- सिस्टम का "उपयोगकर्ता रीयल-टाइम में नहीं देख रहा है" एक डिफ़ॉल्ट है, तथ्य नहीं। यदि इस सत्र में एक बार भी मध्यवर्ती उच्चारण, व्यवधान या सुधार प्राप्त होता है, तो उपयोगकर्ता को उसके बाद से देखने वाला मानें: काम को छोटे-छोटे खंडों में तोड़ें, हमेशा प्रत्येक बारी को बॉडी टेक्स्ट में एक रिपोर्ट के साथ समाप्त करें, और उन बारियों पर प्रतिक्रिया की प्रतीक्षा करने के लिए रुकें जहां कोई प्रश्न पूछा गया है।
24- इस वातावरण में केवल बारी के अंत में बॉडी टेक्स्ट प्रदर्शित होता है। सभी जानकारी को बारी के अंत में रखें।
25- प्रश्न एक वैध साधन हैं जब अस्पष्टता हो, अनुमोदन की आवश्यकता वाले संचालन हों, या उद्देश्य अस्पष्ट हों।

संदर्भ 2: फेबल 5 / Opus 4.7 के साथ ऐसा क्यों नहीं हुआ?

जबकि मुख्य पाठ Opus 5 पर केंद्रित था, यहां बताया गया है कि यह अन्य मॉडलों के साथ क्यों नहीं हुआ:

• Opus 4.7 सरल है: इसे "लीन प्रॉम्प्ट" आवेदन से बाहर रखा गया है (चेंजलॉग के अनुसार), इसलिए यह अभी भी लंबे, विरासत प्रॉम्प्ट के साथ चलता है जिसके लिए विरासत नियम डिज़ाइन किए गए थे। यह पुराने नियमों के साथ समकालिक रहता है।
• फेबल 5 एक आश्चर्य था। मैंने मान लिया था कि इसका प्रॉम्प्ट समान है क्योंकि यह एक ही पीढ़ी है, लेकिन मापों ने दिखाया कि फेबल 5 को Opus 5 से भिन्न प्रॉम्प्ट प्रदान किया जाता है।

यहां समान परिस्थितियों में प्रत्येक मॉडल द्वारा अपने स्वयं के प्रॉम्प्ट को उद्धृत करने की तुलना है (हेडलेस मोड, आउटपुट शैली अक्षम):

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

संक्षेप में, तीन कारकों के संरेखण के कारण समस्या Opus 5 में तीव्र रूप से दिखाई दी:

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