Model Routing और Cascades

Model का सही आकार

हर अनुरोध को सबसे बड़ा model नहीं चाहिए। Router सरल, स्पष्ट अनुरोध (वर्गीकरण, extraction, FAQ-शैली के सवाल) छोटे model को भेजता है और केवल कठिन अनुरोधों को ज़्यादा सक्षम model तक बढ़ाता है। Cascade पहले छोटे model को आज़माता है और उसका उत्तर जाँच में विफल हो या भरोसा कम हो तो आगे बढ़ाता है। बचत इस पर निर्भर है कि कितना traffic आसान है और router कितनी बार ग़लत है, इसलिए अपने evaluation set से दोनों रास्तों की गुणवत्ता मापें।

Routing से बचत, चलाकर

मैंने यह उदाहरण क़ीमतों से चलाया। 0.25 / 1.25 वाला छोटा model उसी traffic के लिए 75 में पड़ता है; 70% अनुरोध वहाँ और 30% बड़े model को भेजने पर 900 की जगह 322.5 लगता है, लगभग 64% की बचत, बशर्ते आसान 70% पर गुणवत्ता स्वीकार्य रहे।

def monthly(requests, in_tok, out_tok, p_in, p_out):
    return round(requests * (in_tok / 1e6 * p_in + out_tok / 1e6 * p_out), 2)

base  = monthly(100_000, 1500, 300, 3.0, 15.0)      # large model for everything
small = monthly(100_000, 1500, 300, 0.25, 1.25)     # small model for everything
routed = round(0.7 * small + 0.3 * base, 2)         # 70% easy -> small model
print(base, small, routed, round(1 - routed / base, 3))

Output:

900.0 75.0 322.5 0.642

सस्ते रास्ते पर गुणवत्ता जाँचें

छोटा model चुपचाप गुणवत्ता घटाए तो बचत का कोई मतलब नहीं। बदलने से पहले और बाद में routed system पर slice-वार रिपोर्ट सहित अपना evaluation set चलाएँ।

त्वरित जाँच: अनुरोधों को सस्ते model पर भेजने का मुख्य जोखिम क्या है?

• बिल हमेशा बढ़ता है
• जिन अनुरोधों को router ने ग़लती से आसान माना उन पर गुणवत्ता गिर सकती है
• छोटे models text नहीं पढ़ सकते
• Routing अवैध है