Dikaya Pro 2 से कोड समीक्षा: CSV आयात के लिए जाँच योग्य टेस्ट

न्यूनतम API उदाहरण

समझाने वाला Python कोड, वास्तविक मॉडल उत्तर नहीं। कुंजी वातावरण से ली जाती है और अपने-आप दोहराना बंद है। कनेक्शन टूटने पर परिणाम और खर्च दोनों अज्ञात रह सकते हैं; बिना जाँच दोबारा न भेजें।

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-pro-2",
    max_tokens=512,
    messages=[{"role": "user", "content": "मेरे काम के लिए जाँच सूची बनाओ। स्रोत के तथ्यों और धारणाओं को अलग रखो।"}],
)
print(response.choices[0].message.content)

CSV के व्यवहार को पहले शब्दों में लिखें

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

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

पहले ऐसा टेस्ट लें जो दोष को पकड़ता हो

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

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

छोटा बदलाव लें, अज्ञात नियम न गढ़ें

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

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

सलाह और निष्पादन के प्रमाण अलग रखें

ब्राउज़र चैट द्वारा दिया गया टेस्ट या शेल कमांड सिर्फ पाठ है। अपने वातावरण में उसे चलाए बिना «टेस्ट पास» लिखना सही सत्यापन नहीं होगा। मॉडल से कमांड, जरूरी तैयारी और स्वीकार्य परिणाम का प्रकार पूछें, फिर वास्तविक आउटपुट सुरक्षित रखें। कोई उदाहरण लॉग केवल उदाहरण है। उसे निष्पादन का प्रमाण मानने से बाद का समीक्षक यह नहीं समझ पाएगा कि वास्तव में कौन सा मामला जाँचा गया था।

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

डेमो को छोटे सीखने योग्य काम तक रखें

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

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

समीक्षा को वास्तविक जाँच सूची के साथ बंद करें

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

चैट मसौदे में जाने पर seller-pro-2 का चयन, खाते की अनुमति और पुराने मसौदे की प्राथमिकता देखें। SDK के लिए max_retries=0 और स्पष्ट उत्तर सीमा रखें। ज्ञात HTTP अस्वीकृति को नेटवर्क में खोए परिणाम के बराबर न मानें; बाद वाला खर्च या सहेजना न होने का प्रमाण नहीं है। स्थिति स्पष्ट किए बिना समीक्षा फिर न भेजें और सार्वजनिक API में अघोषित इडेम्पोटेंसी की गारंटी न जोड़ें।

सवाल और जवाब

क्या Pro 2 और GLM 5.3 की API पहचान एक है?

नहीं। Pro 2 के लिए GLM-5.3 पर आधारित संशोधित संस्करण का विवरण स्वीकृत है, लेकिन उसका सार्वजनिक ID seller-pro-2 ही रहता है। seller-glm-5-3 अलग पहचान है। एक की अनुमति, डेमो शर्त या पैरामीटर दूसरे पर लागू न करें। कोड उदाहरण और सहेजी बातचीत में सटीक ID जाँचें।

यदि मॉडल टेस्ट पास होने की बात लिखे तो क्या उसे मान लें?

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

क्या डेमो में पूरे प्रोजेक्ट का आयात तंत्र जाँचा जा सकता है?

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

अस्पष्ट नियम पर मॉडल कौन सा टेस्ट लिखे?

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

स्रोत

यह सामग्री AI की सहायता से तैयार की गई है। उदाहरण समझाने के लिए हैं, वास्तविक मॉडल उत्तर या तुलनात्मक परीक्षण नहीं। बाहरी स्रोत सेवा की शर्तों की जगह नहीं लेते।

• Dikaya दस्तावेज: Pro 2 डेमो और अनुरोध
  dikaya.cc
• Dikaya मॉडल सूची: Pro 2 की अलग पहचान
  dikaya.cc
• OpenAI Python: SDK के दोहराव बंद करना
  github.com
• MDN: प्रतिक्रिया पढ़ना और नेटवर्क असफलता
  developer.mozilla.org