तुमचा CI पास झाला. तुमचा Agent 'Operator-Ready' नाही

आम्ही गेल्या तिमाहीत एका एंटरप्राइझ क्लायंटला डॉक्युमेंट एजंट (document agent) पुरवला.

आमच्या टेस्ट सुईटमध्ये (test suite) ९४% पास रेट दिसून आला.

पायलट प्रोजेक्ट सुरू होऊन तीन आठवडे झाले असतानाच, एजंटने वाचू न शकलेल्या इनव्हॉइसेससाठी (invoices) रिफंड देण्यास सुरुवात केली. हे सर्व अत्यंत शांतपणे घडले. कोणताही एरर (error) किंवा लॉग (log) दिसला नाही. एजंटने फक्त चुकीची उत्तरे दिली, जी दिसायला अगदी बरोबर वाटत होती.

संपूर्ण वेळ आमचा CI 'ग्रीन' (green) होता.

समस्या मॉडेलमध्ये किंवा प्रॉम्प्टमध्ये (prompt) नव्हती. समस्या त्या ६% डेटाची होती ज्याची आम्ही चाचणी केली नव्हती. तो ६% डेटा ऑपरेटरकडून आलेला पहिला खरा डेटा होता.

ही एखादी 'एज केस' (edge case) नाही. 'Operator-ready' असण्याची व्याख्याच ही आहे.

'Production-ready' असणे हे इन्फ्रास्ट्रक्चरशी (infrastructure) संबंधित आहे. याचा अर्थ तुमची सेवा सुरू राहते आणि लोड हाताळू शकते.

'Operator-ready' असणे वेगळे आहे. याचा अर्थ असा की तुमचा एजंट अशा व्यक्तीसाठी काम करतो ज्याने तो बनवलेला नाही. तो अशा डेटावर काम करतो जो तुम्ही डिझाइन केलेला नाही. तो प्रत्यक्ष परिणामांसह निर्णय घेतो.

बहुतेक टेस्ट पाइपलाइन्स (test pipelines) तुम्ही तयार केलेल्या डेटा सेटवर पास रेट मोजतात. तुमचा टेस्ट सेट आणि प्रत्यक्ष डेटा यामध्ये फरक पडल्यास काय होईल, हे त्या मोजत नाहीत.

९७% व्हॅलिडेशन सक्सेस (validation success) असलेले मॉडेल ऐकायला चांगले वाटते. पण जे ३% फेल होतात, त्याकडे लक्ष द्या.

जर तुमचा एजंट 'रिट्राय' (retry) दरम्यान गहाळ फील्ड्समध्ये डिफॉल्ट व्हॅल्यूज (default values) भरत असेल, तर तुम्ही एक 'सायलेंट एरर मशीन' तयार केले आहे. स्कीमा (schema) पास होतो, पण डेटा चुकीचा असतो.

हे सुधारण्यासाठी, स्कीमा व्हॅलिडिटी (schema validity) आणि कंटेंट कॉन्फिडन्स (content confidence) वेगळे करा.

आम्ही प्रत्येक प्रतिसादाला (response) एक 'कॉन्फिडन्स स्कोअर' (confidence score) जोडला. आता कमी कॉन्फिडन्स असल्यास 'रिट्राय' करण्याऐवजी मानवी पुनरावलोकन (human review) केले जाते. या बदलामुळे आमच्या पहिल्या १८ घटनांपैकी १४ घटना वेळीच पकडल्या गेल्या.

तुमचा टेस्ट सेट तुम्ही विचारलेल्या गोष्टी कव्हर करतो. ऑपरेटरचा डेटा तुम्ही ज्या गोष्टींकडे दुर्लक्ष केले, त्या कव्हर करतो.

आमच्या बाबतीत, आम्ही सिंगल-पेज इनव्हॉइसेसची चाचणी केली होती. पण ऑपरेटरने स्कॅन केलेल्या पीडीएफसह (scanned PDFs) मल्टि-पेज इनव्हॉइसेस वापरले. एजंट नवीन फॉरमॅटमध्ये अपयशी ठरला.

फक्त पार्सर (parser) दुरुस्त करू नका. लाईव्ह जाण्यापूर्वी प्रत्यक्ष ऑपरेटरच्या डेटावर चाचणी करा.

आता कोणत्याही हँडऑफपूर्वी (handoff), आम्ही ऑपरेटरच्या स्वतःच्या डेटातील ५० डॉक्युमेंट्सची मागणी करतो. आम्ही सिंथेटिक डेटा (synthetic data) वापरत नाही. आम्ही त्यांचाच डेटा वापरतो.

तुम्हाला पूर्ण ऑडिट ट्रेलची (audit trail) देखील गरज आहे. मॉडेलने काय रिर्टन केले (returned) याचे लॉग ठेवण्यासोबतच, मॉडेलने काय न करण्याचा निर्णय घेतला, याचेही लॉग ठेवा.

किमान ऑडिट ट्रेलसाठी खालील गोष्टी आवश्यक आहेत:

  • फील्ड-लेव्हल कॉन्फिडन्स स्कोअरसह आउटपुट (Output with field-level confidence scores)
  • एजंटने रिट्राय केला की नाही हे दर्शवणारा फॉलबॅक इंडिकेटर (A fallback indicator showing if the agent retried)
  • नेमका तोच डॉक्युमेंट पुन्हा प्ले करण्यासाठी इनपुट हॅश (An input hash to replay the exact document)
  • वापरलेले विशिष्ट मॉडेल आणि प्रॉम्प्ट व्हर्जन (The specific model and prompt version used)

एजंट ऑपरेटरकडे सोपवण्यापूर्वी, या पाच गोष्टी तपासा:

  • ऑपरेटरच्या प्रत्यक्ष डेटातील ५०+ सॅम्पल्स चालवून पहा.
  • स्कीमा चेक पास झाले पण डाउनस्ट्रीम एरर्स (downstream errors) निर्माण झाले, अशा आउटपुट्ससाठी लॉग्स तपासा.
  • एजंट सुरक्षितपणे फेल (fail safely) होतो की नाही हे सुनिश्चित करण्यासाठी चुकीचे (malformed) इनपुट्स देऊन पहा.
  • एखाद्या विशिष्ट डॉक्युमेंटबाबत काय घडले, याचे उत्तर तुम्ही ५ मिनिटांच्या आत देऊ शकता याची खात्री करा.
  • एजंटला शक्य तितक्या कमी परमिशन्स (permissions) देण्यात आल्या आहेत का, हे तपासा.

आमचा टेस्ट पास रेट ९४% होता. पहिल्या महिन्यात आमचा एरर रेट ८% होता.

कॉन्फिडन्स स्कोअर, रिअल-वर्ल्ड टेस्टिंग आणि चांगले लॉग्स जोडल्यानंतर, एरर रेट १.४% पर्यंत खाली आला.

टेस्ट स्कोअर ही समस्या नव्हती. टेस्ट स्कोप (test scope) ही समस्या होती.

Source: https://dev.to/ethanwritesai/our-ci-passed-your-agent-isnt-operator-ready-2mfn

Optional learning community: https://t.me/GyaanSetuAi