पाठ 20 / 25

Eval Set बनाना

साफ़ सफलता-जाँचों वाले यथार्थपूर्ण काम इकट्ठे करें और हर बदलाव पर दोबारा चलाएँ।

व्यवहार के tests

20 से 50 यथार्थपूर्ण काम इकट्ठे करें, कठिन और अस्पष्ट भी, और हर असली विफलता जो आपने देखी हो। हर एक के लिए जाँच तय करें: सटीक मान, database में record, पास होने वाला test, या खुले output के लिए दूसरे model द्वारा अंकित rubric। Prompt, tool description या model बदलने पर set चलाएँ और scores, ख़र्च और tool calls की तुलना करें।

डेटा के रूप में eval मामला

मामलों को डेटा के रूप में रखने से उनकी समीक्षा, versioning और विस्तार आसान होता है।

{
  "id": "refund-basic",
  "input": "Refund order 10482, the item arrived broken.",
  "must_call": ["get_order", "refund_order"],
  "must_not_call": ["delete_account"],
  "max_tool_calls": 6,
  "check": "order 10482 status == refunded"
}

सामान्य मामले भी रखें

कठिन किनारे के मामले लुभाते हैं, पर असली ट्रैफ़िक ज़्यादातर सामान्य होता है। Eval set में सिर्फ़ पेचीदा inputs हों तो रोज़मर्रा के अनुरोध तोड़ने वाला बदलाव निकल सकता है।

त्वरित जाँच: Eval set कब दोबारा चलाना चाहिए?

  • सिर्फ़ launch पर
  • Prompts, tool descriptions या model में किसी बदलाव के बाद
  • कभी नहीं
  • सिर्फ़ जब users शिकायत करें
Answer

Prompts, tool descriptions या model में किसी बदलाव के बाद — इनमें से कोई भी बदलाव व्यवहार बदल सकता है, इसलिए हर एक पर regression जाँच चाहिए।