आप precision के बजाय recall के लिए optimize कब करेंगे, और threshold असल में तय कैसे करते हैं?

recall के लिए तब optimize करें जब छूटा हुआ positive किसी झूठे अलार्म से महंगा पड़ता हो, जैसे fraud screening या बीमारी की पहचान, जहां वैसे भी हर flag को कोई इंसान देखता है। precision के लिए तब optimize करें जब किसी positive पर कार्रवाई महंगी या चिढ़ पैदा करने वाली हो, जैसे offers भेजना या accounts block करना। threshold को 0.5 पर डिफॉल्ट छोड़ने के बजाय expected cost से तय करें: thresholds को घुमाकर देखें और सबसे कम expected loss वाला चुनें।

मैं यह पूछकर शुरू करता हूं कि हर तरह की गलती का नतीजा क्या होता है। किसी fraud queue पर false negative का मतलब है पैसा बाहर और ऊपर से chargeback, जबकि false positive का मतलब है किसी analyst के तीस सेकंड, तो recall जीतता है और मैं threshold नीचे धकेलता हूं। push notification model पर यह उलट जाता है: false positive एक असली यूजर को चिढ़ाता है और आपको uninstall तक करा सकता है, इसलिए मुझे precision चाहिए भले ही मैं कम लोगों तक पहुंचूं। असली नंबर चुनने के लिए मैं हर तरह की error पर एक मोटी लागत रखता हूं, validation set पर threshold को पूरे दायरे में घुमाता हूं, और expected cost plot करता हूं। उसमें आम तौर पर एक साफ गड्ढा दिखता है, और मैं ठीक न्यूनतम के बजाय उस गड्ढे का बीच वाला हिस्सा लेता हूं, क्योंकि न्यूनतम folds के बीच उछलता रहता है। जो बंदिश लोग भूल जाते हैं वह है capacity। एक fraud प्रोजेक्ट पर cost curve कह रही थी कि करीब चार प्रतिशत transactions flag करो, पर review टीम दिन में लगभग एक हजार केस ही संभाल सकती थी, तो असली threshold वही था जो एक हजार पैदा करे। मैंने यह साफ कहा, बजाय इसके कि दिखावा करता कि चुनाव पूरी तरह statistical था।