मॉडल, context और गलत उत्तर

क्षमता और उपलब्ध जानकारी को अलग समझें

Language model सीखे हुए patterns और काम के दौरान दी गई जानकारी का उपयोग करता है। आधुनिक मॉडल काफी reasoning और उपयोगी software कार्य कर सकते हैं। वे ऐसा विस्तृत उत्तर भी दे सकते हैं जो गलत धारणा पर आधारित हो।

“Frontier model” क्षमता के बदलते स्तर को बताता है। इस शब्द से यह सिद्ध नहीं होता कि मॉडल ने आपकी repository पढ़ी है। इससे यह भी पता नहीं चलता कि मॉडल आपके dependency versions या अलिखित business rules जानता है। काम के environment से ये तथ्य मिलने चाहिए।

उपयुक्त tools वाला agent जानकारी प्राप्त कर सकता है। Access के बिना chat repository का निरीक्षण नहीं कर सकता। उत्तर गलत लगे तो दो प्रश्न पूछें। क्या सही जानकारी मिलने पर मॉडल यह समस्या हल कर सकता है? क्या मॉडल को वह जानकारी मिली थी?

पहली समस्या में दूसरा मॉडल मदद कर सकता है। दूसरी समस्या का समाधान छूटी हुई policy देना या dependency जाँचना हो सकता है।

इस काम के लिए context तय करें

Context वह जानकारी है जो वर्तमान उत्तर के लिए उपलब्ध है। इसमें instructions, दी गई files, संबंधित बातचीत और tools के परिणाम शामिल हैं। Products इस जानकारी को अलग-अलग तरीकों से चुनते और बनाए रखते हैं। वे पहले की सामग्री का सारांश भी बना सकते हैं।

यह न मानें कि मॉडल uploaded folder की हर file पढ़ता है। यह भी न मानें कि लंबे session में शुरुआत का instruction हमेशा उपलब्ध रहता है। Tool से पूछें कि उसने किन files और instructions का उपयोग किया।

अधिक context से उत्तर हमेशा बेहतर नहीं होता। असंबंधित source files से अधिक उपयोगी वर्तमान architecture decision हो सकता है। पुरानी migration guide आधिकारिक लगने के कारण गलत उत्तर का कारण बन सकती है।

Account settings के एक काल्पनिक feature पर विचार करें। Route, authorization middleware, संबंधित data model और मौजूदा test दें। स्पष्ट शर्त जोड़ें: “सदस्य अपना display name बदल सकता है। सदस्य organization में अपनी role नहीं बदल सकता।” अब मॉडल के पास पालन करने के लिए स्पष्ट नियम है।

व्याख्या के दावों की जाँच करें

उत्तर में कहा जा सकता है कि endpoint सुरक्षित है क्योंकि middleware ownership जाँचता है। इस दावे के हर हिस्से की जाँच करें।

1. जाँचें कि endpoint बताए गए middleware का उपयोग करता है।
2. जाँचें कि middleware केवल authentication नहीं, ownership भी जाँचता है।
3. User identity का स्रोत पहचानें।
4. दूसरे उपयोगकर्ता के रूप में negative test करें।

Repository का reference बताता है कि कहाँ देखना है। Reference से यह सिद्ध नहीं होता कि व्याख्या code से मेल खाती है।

API के सुझाव के लिए भी यही तरीका अपनाएँ। Generated code ऐसा method call कर सकता है जिसे installed package export नहीं करता। Dependencies बदलने से पहले package version और आधिकारिक documentation जाँचें। अन्यथा अप्रमाणित धारणा से अनावश्यक migration हो सकता है।

अनिश्चितता को जाँच में बदलें

“सटीक रहें” verification की योजना नहीं है। धारणा, जरूरी प्रमाण और गलत परिणाम का असर पहचानें।

उदाहरण: “हमने इस endpoint के लिए tenant isolation नहीं जाँचा है। Request handler का निरीक्षण करें। ऐसा test जोड़ें जिसमें दूसरे tenant का उपयोगकर्ता यही record माँगता है।” यह instruction agent को स्पष्ट जाँच और देखने योग्य परिणाम देता है।

Implementation के प्रश्नों के लिए system का वास्तविक version जाँचें। Document इच्छित व्यवहार बता सकता है। Code का निरीक्षण और tests वर्तमान व्यवहार सिद्ध करने में मदद करते हैं। दोनों में अंतर हो, तो जिम्मेदार व्यक्ति के उसे हल करने तक अंतर दर्ज रखें। चुपचाप अधिक सुविधाजनक उत्तर न चुनें।

Managers हर code change पढ़े बिना यह तरीका इस्तेमाल कर सकते हैं। पूछें कि team ने कौन-सी धारणाएँ जाँचीं। अधूरी धारणाएँ और उनके जिम्मेदार लोग पहचानें। यह जानकारी release के निर्णय में मॉडल के नाम से अधिक सीधे काम आती है।