Case Study: Support Ticket Routing

3,500-token prompt से निर्णय तक

एक टीम महीने में 2,00,000 support tickets को 12 श्रेणियों में route करती है। उनका few-shot prompt 3,500 tokens का है और मज़बूत मॉडल अच्छा score करता है पर महँगा है और कभी-कभी धीमा। सीढ़ी का अनुसरण: वे दो agents से label कराया 600-ticket मूल्यांकन set बनाते हैं, prompt कसते हैं और prompt caching आज़माते हैं (सस्ता, फिर भी बजट से ऊपर), फिर learning curve देखते हैं: डेटा के साथ सटीकता अब भी बढ़ रही है। उनके पास 8,000 समीक्षित ऐतिहासिक tickets हैं, इसलिए वे छोटे prompt के साथ छोटा मॉडल fine-tune करते हैं, held-out set पर सर्वश्रेष्ठ prompted baseline से तुलना करते हैं, पुरानी श्रेणियों में forgetting जाँचते हैं, और prompted मॉडल fallback रखते हैं। यह कहानी काल्पनिक उदाहरण है, मापा परिणाम नहीं; निर्णय उनकी अपनी संख्याएँ करतीं।

Case study, platform का चुनाव और जीवनचक्र

एक यथार्थवादी निर्णय आदि से अंत तक चलें, फिर मॉडल के पूरे जीवन की योजना बनाएँ।

योजना checklist के रूप में

कोई एक चरण नहीं, क्रम अधिक मायने रखता है।

1. 600-ticket eval set, two labellers, agreement measured
2. best prompt + caching baseline: quality, cost, latency recorded
3. learning curve on historical tickets: still rising -> training may help
4. clean + dedupe + group-split 8,000 tickets; scan for personal data
5. fine-tune a small model (LoRA first), short prompt, early stopping
6. compare with step 2 on the held-out set, with intervals
7. check old categories and refusal behaviour for regressions
8. ship behind a flag, prompted model as fallback, monitor drift

पहले से मानक तय करें

प्रशिक्षण से पहले आवश्यक लाभ लिखें (जैसे आधी लागत पर गुणवत्ता-समता), ताकि बाद में परिणाम को मोड़ा न जा सके।

त्वरित जाँच: Case study में fine-tuning को किसने उचित ठहराया?

• सस्ती prompting अब भी बजट से ऊपर थी और डेटा के साथ learning curve अब भी बढ़ रही थी
• Fine-tuning चलन में थी
• उनके पास मूल्यांकन set नहीं था
• Retrieval असंभव था