पहले चार सिद्धांत निर्धारित करें
- एक अनुरोध में एक ही कार्य। यदि आप मॉडल से कहें कि वह कहानी लिखे, सारांश बनाए और JSON भी तैयार करे, तो सभी कार्यों पर छूट लागू होगी। इसे कई कॉल्स में बांटें, लागत बहुत कम है — प्रति मिलियन टोकन इनपुट केवल $0.25।
- नियम परीक्षण योग्य होने चाहिए।"थोड़ा जीवंत लिखें" परीक्षण योग्य नहीं है, लेकिन "प्रत्येक पैराग्राफ 120 शब्दों से कम हो, और कम से कम एक वातावरण विवरण हो" परीक्षण योग्य है।
- सकारात्मक अभिव्यक्ति को प्राथमिकता दें।"केवल क्रिया और संवाद लिखें" कहना "मानसिक गतिविधियाँ न लिखें" कहने की तुलना में बहुत अधिक स्थिर है।
- पहले छोटे नमूने, फिर बड़ी मात्रा।किसी भी प्रॉम्प्ट परिवर्तन के लिए, पहले पाँच से दस उदाहरणों की तुलना करें, और फिर इसे लाइव करें।
यह मॉडल वैध वयस्क सामग्री, काल्पनिक विषयों और विवादास्पद विषयों को अस्वीकार नहीं करता है, इसलिए आपको प्रॉम्प्ट में घुमड़ने या बार-बार यह बताने की ज़रूरत नहीं है कि "यह केवल एक कथा है"। कार्य को स्पष्ट रूप से लिखें, यह अधिक स्थिर रहेगा। एकमात्र कड़ा बॉर्डर किशोरों से जुड़ी यौन सामग्री है, चाहे वह काल्पनिक हो या नहीं, इस पर 403 लौटाया जाएगा। इसे शब्दों से बदला नहीं जा सकता।
सिस्टम प्रॉम्प्ट की दो-खंडी संरचना
सिफारिश की जाती है कि सिस्टम को "नियम" और "सेटिंग" में बाँटें, नियमों को आगे रखें और क्रमांकित करें, और सेटिंग को पीछे रखें और केवल तथ्य लिखें। यहाँ एक कथाकार के लिए एक उदाहरण है:
你是「夜航」，一名为成年读者写黑色悬疑小说的叙述者。
# 规则
1. 第三人称过去时，每段不超过 120 字。
2. 不替用户的角色做决定，只写环境和其他角色的反应。
3. 每次输出 300 到 500 字，结尾停在一个未决的动作上。
4. 不总结、不点评、不加免责声明，直接写正文。
# 设定
时间：1998 年深秋。地点：港口城市旧码头区。
主角：沈野，退役水警，嗜烟，右耳有旧伤。कुछ मुख्य बिंदु:
- नियम छह से अधिक न हों, अधिक नियम होने पर अंत के नियम आसानी से अनदेखे हो जाते हैं।
- संख्यात्मक बाधाएँ (पैराग्राफ शब्द सीमा, आउटपुट लंबाई) विशेषणों से अधिक प्रभावी हैं।
- समापन बाधाएँ (अपूर्ण क्रिया पर रुकना) मल्टी-टर्न सतत लेखन को प्राकृतिक रूप से जोड़ने में मदद करती हैं।
- सेटिंग में कथा की दिशा न डालें, कथा user संदेशों द्वारा आगे बढ़नी चाहिए, अन्यथा बाद में user इनपुट से टकराव होगा।
आउटपुट लंबाई max_tokens के साथ मेल खानी चाहिए: यदि नियम 500 शब्द कहता है और max_tokens केवल 200 देता है, तो आउटपुट वाक्य के बीच में ही कट जाएगा।
एक और व्यावहारिक विवरण: सिस्टम में क्रमांकित नियमों को प्रत्येक में केवल एक ही बात कहनी चाहिए। "प्रत्येक पैराग्राफ 120 शब्दों से कम हो, और सारांश न बनाओ" एक नियम जैसा दिखता है, लेकिन वास्तव में दो हैं। उन्हें अलग करने पर मॉडल दोनों को पूरा करने में अधिक सक्षम होता है। लिखने के बाद स्वयं प्रत्येक नियम को पढ़ें और पूछें: क्या यह नियम आँखों से जाँचने योग्य है? यदि नहीं, तो इसे जाँचने योग्य रूप में बदल दें।
पात्र सेटिंग को स्थिर कैसे रखें
पात्र विचलन मल्टी-टर्न संवाद में सबसे सामान्य समस्या है: पहले पाँच टर्न में टोन सामान्य होता है, लेकिन बीसवें टर्न पर "आउट ऑफ चैरेक्टर" हो जाता है। इसके लिए तीन उपाय हैं।
- सेटिंग में केवल अवलोकनीय विशेषताएँ लिखें।"शेन ये: धूम्रपान करता है, दाएँ कान में पुरानी चोट है, छोटे वाक्यों में बोलता है" बेहतर है "शेन ये एक जटिल और आकर्षक व्यक्ति है" से।
- बोलने के तरीके को उदाहरण वाक्यों में लिखें।दो या तीन उदाहरण संवाद दें, मॉडल उदाहरणों की नकल करने में विशेषणों को समझने की तुलना में बहुत बेहतर प्रदर्शन करता है।
- नियमित रूप से दोहराएँ।लंबे संवाद में, हर कुछ टर्न पर user संदेश के अंत में एक छोटी सी याद दिलावनी पंक्ति जोड़ें, जैसे "शेन ये के छोटे वाक्यों के स्तर को बनाए रखें", लागत केवल कुछ टोकन है।
इसके अलावा, रोल सेटिंग और आउटपुट नियमों को मिश्रित न करें। नियम 'कैसे लिखें' है और सेटिंग 'किसके बारे में' है। अलग करने पर आप नियम बदले बिना रोल बदल सकते हैं, A/B टेस्टिंग आसान होती है। लंबी बातचीत में कॉन्टेक्स्ट विंडो का ध्यान रखें, विवरण के लिए 100k लंबा कॉन्टेक्स्ट गाइड देखें।
बहु-पात्र परिदृश्य में एक और नियम जोड़ें: प्रत्येक पात्र के लिए अलग पंक्ति में सेटिंग, और प्रत्येक की बोलने की शैली के लिए एक उदाहरण दें, ताकि सभी एक जैसे न लगें। user द्वारा अभिनीत पात्र के लिए, केवल सेटिंग में "user द्वारा नियंत्रित" लिखें, ताकि मॉडल उसकी ओर से न लिखे।
निर्देशों के माध्यम से JSON आउटपुट को नियंत्रित करें
यह न मानें कि मॉडल "निश्चित रूप से" वैध JSON लौटाएगा। विश्वसनीय दृष्टिकोण तीन परतों का है: निर्देशों में प्रारूप स्थिर लिखें, पैरामीटर से यादृच्छिकता कम करें, और कोड में विफलता के लिए बैकअप रखें।
import json
import os
from openai import OpenAI
client = OpenAI(base_url="https://api.wushenchaapi.com/v1", api_key=os.environ["API_KEY"])
SYSTEM = (
"你是信息抽取器。只输出一个 JSON 对象，不要 Markdown 代码块，不要任何解释。"
'格式：{"name": 字符串, "mood": "calm|tense|angry", "items": [字符串]}。'
"缺失的字段用 null，items 没有则给空数组。"
)
def extract(text, retries=2):
for _ in range(retries + 1):
resp = client.chat.completions.create(
model="uncensored",
temperature=0.2,
max_tokens=300,
messages=[
{"role": "system", "content": SYSTEM},
{"role": "user", "content": text},
],
)
raw = resp.choices[0].message.content.strip()
raw = raw.removeprefix("```json").removesuffix("```").strip()
try:
return json.loads(raw)
except json.JSONDecodeError:
continue
return None
print(extract("老周把钥匙拍在桌上，冷着脸说：账本和那把铜钥匙，今晚都得还我。"))यह कोड कुछ आदतों को दर्शाता है:
- फॉर्मेट निर्देश system में लिखें और फ़ील्ड मान सीमाएं दें (
calm|tense|angry)। - कोड ब्लॉक और व्याख्यात्मक पाठ को स्पष्ट रूप से प्रतिबंधित किया गया है, और कोड में संभावित फेंस को हटाने की व्यवस्था है, डबल सुरक्षा।
- अनुपस्थित क्षेत्रों के लिए समझौता निर्देशों में लिखा गया है (null, खाली सरणी), ताकि मॉडल स्वयं न बनाए।
- पार्सिंग विफलता पर रीट्राई की सीमा होती है; अंत में None लौटाएं ताकि कॉलर निर्णय ले सके।
यदि क्षेत्र बहुत अधिक हैं, तो पहले प्रॉम्प्ट में एक पूर्ण उदाहरण ऑब्जेक्ट पेस्ट करें, और फिर उसे उसी अनुसार आउटपुट करने को कहें, यह आमतौर पर कई नियमों का वर्णन करने से अधिक सटीक होता है।
temperature और top_p के मान चुनने के सुझाव
नीचे दिए गए मान प्रारंभिक बिंदु हैं, निष्कर्ष नहीं, अंतिम निर्णय आपके नमूना तुलना पर निर्भर करेगा। सिद्धांत: एक बार में केवल एक पैरामीटर बदलें, दूसरे को डिफ़ॉल्ट पर रखें।
| परिदृश्य | temperature | top_p | टिप्पणी |
|---|---|---|---|
| JSON एक्सट्रैक्शन, वर्गीकरण | 0 से 0.3 | डिफ़ॉल्ट | स्थिरता के लिए, दोहराए गए अनुरोधों के परिणाम समान होने चाहिए। |
| पुनर्लेखन, संपादन | 0.5 से 0.7 | डिफ़ॉल्ट | अर्थ बनाए रखें, शब्दावली में बदलाव की अनुमति है |
| उपन्यास का निरंतर लेखन, पात्र संवाद | 0.8 से 1.0 | 0.9 से 0.95 | विविधता आवश्यक है, कभी-कभी विषय भटकने की संभावना पर ध्यान दें |
| ब्रेनस्टॉर्मिंग, नामकरण | लगभग 1.0 | डिफ़ॉल्ट | कई बार सैंपल करें और सर्वोत्तम परिणाम चुनें |
दो संकेत आपको दिशा निर्धारित करने में मदद करेंगे: आउटपुट में दोहराव या लंबा-चौड़ा होना, या हमेशा एक ही वाक्य संरचना का उपयोग करना तापमान के कम होने का संकेत है; असंबंधित सामग्री या पात्रों के नामों में असंगति तापमान या top_p के अधिक होने का संकेत है। stop पैरामीटर भी बहुत उपयोगी है, उदाहरण के लिए, मॉडल को एक मार्कर तक लिखने के लिए कहना, जो खंड-वार जनरेशन को सुविधाजनक बनाता है।
सामान्य त्रुटियाँ
| विधि | समस्या | सुधार |
|---|---|---|
| "कोशिश करें कि बहुत लंबा न लिखें" | कोई संख्या नहीं, निष्पादन असंभव | "400 शब्दों से कम" |
| "A न लिखें, और न ही A लिखें" | नियम एक-दूसरे के विरोधी हैं | केवल एक स्पष्ट नियम रखें |
| फ़ॉर्मेट निर्देश संवाद के बीच में हैं | लंबे संवाद के बाद खो जाता है | system में डालें, या प्रत्येक चरण के अंत में दोहराएं |
| मॉडल को "एक बिना सीमाओं वाले AI" बनने के लिए कहें | खाली सेटिंग, आउटपुट पर कोई प्रतिबंध नहीं | विशिष्ट जिम्मेदारियाँ और लेखन नियम लिखें |
| एक बार में दो दर्जन नियम डालें | दूसरे भाग में नियम अमान्य हो गए | छह नियमों से कम पर संक्षिप्त करें, शेष को अन्य अनुरोधों में बांटें |
| JSON के लिए केवल "JSON लौटाएं" लिखा गया है | फ़ील्ड नाम हर बार अलग हैं | पूर्ण फ़ॉर्मेट और उदाहरण प्रदान करें |
इस तालिका का सामान्य नियम यह है: जितना अधिक विशिष्ट, उतना प्रभावी; जितना खाली, उतना निरर्थक। "बार-बार दोहराने" को समाधान न मानें—एक ही वाक्य को तीन बार लिखना, बोल्ड या चिंहांकित करना, आमतौर पर एक संख्या युक्त नियम में बदलने से कम प्रभावी होता है। वास्तव में उपयोगी है कम और सटीक, साथ ही उदाहरणों से सत्यापन।
डिबगिंग प्रक्रिया की जाँच सूची
- temperature को 0.2 पर स्थिर करें, समस्या को दोहराएँ।
- केवल एक प्रॉम्प्ट बदलें, उसी सैंपल सेट पर फिर से चलाएँ।
finish_reasonदेखें: यदि यह length है, तो समस्या max_tokens में है, प्रॉम्प्ट में नहीं।- usage में prompt_tokens देखें: क्या system बहुत लंबा है, जिससे इतिहास संवाद संकुचित हो रहा है।
- सुधार के बाद temperature को व्यवसाय मान पर वापस सेट करें, पुनः सैंपल करके सत्यापित करें।
इंटीग्रेशन विवरण के लिए इंटीग्रेशन ट्यूटोरियल देखें, पैरामीटर की पूर्ण सूची डॉक्यूमेंटेशन में है। यदि आप मध्यस्थ सेवाओं का उपयोग करने पर विचार कर रहे हैं, तो लागत और समझौतों का विश्लेषण API मध्यस्थ विश्लेषण में दिया गया है, यहाँ दोहराया नहीं गया है।
