तपाईंले कसरी बुझ्नु हुन्छ कि एआई उत्तर विश्वसनीय छ, विशेषगरी उत्पादन कोडको लागि?

Question

Accepted Answer

एक एआई उत्तरलाई **एक आत्मविश्वासी मस्यौदा एक ज्ञानी तर अविश्वसनीय सहकर्मीबाट** मान्नुहोस्: उपयोगी, प्राय: सही, तर आफ्नै आप कहिले पनि आधिकारिक होइन। विश्वास *सत्यापन* बाट आउँछ, आउटपुट कति विश्वास गर्न बनेको सुनिन्छ भन्नेबाट होइन।

## मुख्य सोच

**आत्मविश्वास सहीपनसँग सम्बन्धित छैन।** एक LLM तरल पाठ उत्पन्न गर्दछ चाहे यो सत्य हो वा नहोस् (यो अगिलो-टोकन भविष्यवाणीकर्ता हो, तथ्य भण्डार होइन)। एक भ्रमपूर्ण API र एक वास्तविक एक समान पढिन्छ। त्यसैले तपाई विश्वास टोन द्वारा न्याय गर्न सक्नु हुन्न — केवल जे तपाई पुष्टि गर्न सक्नु हुन्छ।

## एक व्यावहारिक चेकलिस्ट

- **यो चलाउनुहोस्।** कोडको लागि, सबैभन्दा बलिष्ठ संकेत कार्यान्वयन हो: परीक्षण, प्रकार जाँचकर्ता, lint, कम्पाइलर। कोड जो वास्तविक परीक्षण सुइट पास गर्दछ कोड जो केवल सही देखिन्छ भन्दा धेरै विश्वसनीय हो।
- **भ्रमपूर्ण APIs को लागि जाँच गर्नुहोस्।** सत्यापन गर्नुहोस् कि हरेक प्रकार्य, विधि, झण्डा, र आयात वास्तवमा अस्तित्वमा छ — दस्तावेज वा स्थापित संस्करणमा, स्मृति बाट होइन। आविष्कृत-तर-यथार्थवादी APIs क्लासिक असफलता हो।
- **आधिकारिक स्रोत विरुद्ध सत्यापन गर्नुहोस्।** दावी अधिकारिक दस्तावेज, मानक, वा स्रोत कोड विरुद्ध क्रस-चेक गर्नुहोस् — मडेलको आफ्नै पुनर्कथनको विरुद्ध होइन।
- **किनारा केस र सुरक्षा को बारे मा सोच्नुहोस्।** Null/खाली इनपुट, समकालिकता, त्रुटि पथ, इन्जेक्शन, authz। एआई प्राय: खुशीको पथ संभाल्छ र खतरनाक कोणहरु छोड्छ।
- **जे तपाई पुष्टि गर्न सक्नु हुन्छ त्यसलाई पसन्द गर्नुहोस्।** क्लेभर-तर-अपारदर्शी आपूर्तिकर्ताहरु विरुद्ध तपाई परीक्षण वा हेर्न सक्नु हुन्छ आपूर्तिकर्ता।
- **महत्वपूर्ण पथका लागि मानव समीक्षा आवश्यक गर्नुहोस्।** Auth, भुक्तानी, डेटा हटाना, माइग्रेसन, infra — एक मानिस जो प्रणाली बुझ्छ अनुमोदन गर्नुपर्छ, उत्तर कति राम्रो देखिन्छ भन्नेको बिषैमा।

## एक द्रुत नियम

```text
Verifiable + verified        → trust
Verifiable + not yet checked → verify before using
Not verifiable               → don't depend on it
```

## किन यो महत्वपूर्ण छ

उत्पादनमा, एक गलत उत्तर जो *सही* देखिन्छ एक जो स्पष्ट रूप से टूटेको छ भन्दा अधिक खतरनाक छ, किनभने यो फिस्ल गर्दछ। जैसे एआई अधिक कोड लेख्छ, bottleneck *उत्पन्न* गर्ने बाट *सत्यापन* मा शिफ्ट हुन्छ। वरिष्ठ निर्णय ठीक यो हो: जान्न कि तरलता सहीपनको प्रमाण होइन, कि **मडेलको आत्मविश्वास सहीपन को बारे मा कुनै जानकारी बहन गर्दैन**, र विश्वास परीक्षण, स्रोत, र मानव समीक्षा द्वारा कुनै पनि कुरामा अर्जन गर्नुपर्छ जो महत्वपूर्ण छ। जे ईन्जिनियर विश्वसनीय रहन्छ ती हो जो विश्वास भन्दा सत्यापन गर्नु हुन्छ।