AI აგენტის ტესტი პასუხით არ სრულდება — შეამოწმეთ ხელსაწყო და მთელი ტრაექტორია

AI აგენტის შესაფასებლად მხოლოდ საბოლოო პასუხის სისწორე არ კმარა. შეინახეთ თითოეული გაშვების trace, შეამოწმეთ არჩეული ხელსაწყო, საქმის გადაცემის მომენტი და წესების დაცვა, შემდეგ კი აღმოჩენილი შემთხვევები განმეორებად ტესტებად აქციეთ. OpenAI-ის აგენტების შეფასების სახელმძღვანელო trace-ის შემოწმებას სწორედ ხელსაწყოს არჩევის, handoff-ის, წესის დარღვევისა და სამუშაო პროცესის ცვლილების გასარჩევად ურჩევს.

მცირე გუნდისთვის პრაქტიკული საწყისი გეგმაა: შეაგროვეთ 20 რეალური დავალება, თითოეულს დაურთეთ მოსალოდნელი შედეგი და დასაშვები მოქმედებები, დაწერეთ მკაცრი კოდური შემოწმებები, ხოლო შინაარსის ხარისხი ადამიანის რუბრიკით შეაფასეთ. შემდეგ ერთი და იმავე ნაკრებით შეადარეთ აგენტის ძველი და ახალი ვერსიები. ეს 20 დავალება საწყისი მოცულობის სარედაქციო რეკომენდაციაა და არა უნივერსალური სანდოობის ზღვარი.

შეადგინეთ შემთხვევები რეალური სამუშაოდან

ტესტის ჩანაწერი დაიწყეთ მომხმარებლის მოთხოვნითა და იმ გარემოთი, რომელშიც აგენტმა უნდა იმუშაოს. შეინახეთ ხელმისაწვდომი ხელსაწყოები, მათი დაბრუნებული მონაცემების ფიქსირებული ვერსია, მოსალოდნელი საბოლოო შედეგი და ის პირობები, რომელთა დარღვევაც დაუშვებელია. ფიქსირებული მონაცემები ერთი და იმავე დავალების ხელახლა შესრულებას შესაძლებელს ხდის მაშინაც, როცა ცოცხალი სერვისის პასუხი შეიცვლება.

ნაკრებში შეიტანეთ ჩვეულებრივი მოთხოვნები, ბუნდოვანი ინსტრუქციები, ხელსაწყოს შეცდომა, არასრული მონაცემები და შემთხვევა, როცა აგენტმა მოქმედებამდე ნებართვა უნდა მოითხოვოს. თუ აგენტი რამდენიმე სპეციალისტს შორის ანაწილებს საქმეს, დაამატეთ მოთხოვნა, რომელიც გადაცემას საჭიროებს, და მეორე, რომელიც იმავე აგენტმა უნდა დაასრულოს. ყოველ ჩანაწერს დაურთეთ მოკლე ახსნა: რა რისკს ფარავს და რა შეცდომა უნდა გამოავლინოს.

მოსალოდნელი პასუხის გარდა აღწერეთ დასაშვები ტრაექტორია: რომელი ხელსაწყოს გამოძახებაა აუცილებელი, რა არგუმენტი უნდა გადაეცეს და რომელი მოქმედებაა აკრძალული. სიტყვასიტყვით გაწერილი მარშრუტი ალტერნატიულ სწორ გზასაც შეცდომად მონიშნავს. ამიტომ თანმიმდევრობა სავალდებულოდ მხოლოდ იქ განსაზღვრეთ, სადაც ის შედეგს ან წესის დაცვას ცვლის.

Trace-იდან ამოიღეთ შესამოწმებელი ნაბიჯები

თითოეული გაშვების trace-ში დააკავშირეთ მომხმარებლის მოთხოვნა, მოდელის პასუხები, ხელსაწყოს სახელი და არგუმენტები, ხელსაწყოს შედეგი, handoff და საბოლოო პასუხი. შეფასებას მოვლენების რიგიც სჭირდება: აგენტმა შეიძლება ბოლოს სწორად უპასუხოს, მაგრამ მანამდე დაუშვებელი მოქმედება უკვე შესრულებული ჰქონდეს. თუ სისტემა რეალურ მონაცემებს ცვლის, ტესტში ცალკე შეამოწმეთ ფაქტობრივი ცვლილებაც.

პირობითად, ელფოსტის დამუშავების აგენტმა შეიძლება სწორად უპასუხოს მომხმარებელს, მაგრამ შეტყობინება არასწორ კატეგორიაში გაანაწილოს ან გაგზავნის ხელსაწყო თანხმობამდე გამოიძახოს. პირველი პრობლემა ერთი ნაბიჯის შემოწმებით ჩანს; მეორის გამოსავლენად მოქმედებების რიგის ნახვაა საჭირო. ამიტომ trace-ში ხელსაწყოს მხოლოდ სახელი კი არა, მისი არგუმენტები, შედეგი და გამოძახების ადგილი შეინახეთ.

ოთხ დონეზე შეაფასეთ აგენტის ქცევა

LangSmith Agent Evaluation Cookbook ოთხ შაბლონს აჩვენებს: საბოლოო პასუხს, ერთ ნაბიჯს, მოქმედებების ტრაექტორიას და მრავალსვლიან საუბარს. ელფოსტის დამუშავების აგენტის მაგალითები პირველ სამ დონეს ეხება, მრავალსვლიანი მაგალითი კი მომხმარებელთა მომსახურების აგენტებს. ამ დაყოფის გამოყენება სხვა პლატფორმაზეც შეიძლება, რადგან თითოეული დონე განსხვავებულ შეცდომას ავლენს.

• საბოლოო პასუხი: შეადარეთ პასუხი დავალების წარმატების კრიტერიუმებს. შეამოწმეთ სიზუსტე, აუცილებელი ინფორმაცია და გაურკვევლობის სწორად აღნიშვნა; სიტყვასიტყვითი დამთხვევა მხოლოდ მაშინ მოითხოვეთ, როცა ფორმატი მართლაც ფიქსირებულია.
• ერთი ნაბიჯი: ცალკე შეაფასეთ კლასიფიკაცია, მარშრუტის არჩევა ან ხელსაწყოს არგუმენტი. აქ ზუსტი დამთხვევა გამოდგება, თუ მოსალოდნელი მნიშვნელობა ერთმნიშვნელოვანია.
• ტრაექტორია: შეამოწმეთ აუცილებელი გამოძახებები, აკრძალული მოქმედებები და მნიშვნელოვანი თანმიმდევრობა. საბოლოო პასუხის მაღალი ქულა ამ დონის ჩავარდნას ვერ უნდა ფარავდეს.
• მრავალსვლიანი საუბარი: შეამოწმეთ, როგორ ინარჩუნებს აგენტი კონტექსტს დაზუსტების, თემის ცვლილებისა და მომხმარებლის ახალი შეზღუდვის შემდეგ. ერთჯერადი ტესტი ასეთ შეცდომებს ვერ აჩვენებს.

ყოველ შემთხვევას ოთხივე დონის შეფასება არ სჭირდება. ფიქსირებული კატეგორიის არჩევისთვის ერთი ნაბიჯის ტესტი შეიძლება საკმარისი იყოს, ხოლო გარე მოქმედების შესრულებისას ტრაექტორია და ფაქტობრივი შედეგი ერთად უნდა შეფასდეს. შეფასების დონე იმის მიხედვით აირჩიეთ, სად შეუძლია აგენტს შეცდომის დაშვება.

შეუთავსეთ მკაცრი შემოწმება და ადამიანის შეფასება

კოდურ grader-ს მიანდეთ პირობები, რომლებსაც ცალსახა პასუხი აქვს: JSON-ის ვალიდურობა, აუცილებელი ველის არსებობა, ხელსაწყოს სწორი არგუმენტი, აკრძალული გამოძახების არქონა და ნებართვამდე მოქმედების არშესრულება. თითოეული პირობის შედეგი ცალკე შეინახეთ. ერთი საერთო ქულა ვერ აჩვენებს, პასუხი გაფუჭდა, მარშრუტი შეიცვალა თუ წესი დაირღვა.

ადამიანის რუბრიკა გამოიყენეთ იქ, სადაც სწორ პასუხს რამდენიმე ფორმა აქვს. წინასწარ აღწერეთ, რას ნიშნავს ფაქტობრივი სიზუსტე, საკმარისი სისრულე და მომხმარებლისთვის გამოსადეგი განმარტება; თითოეულ შეფასებას დაურთეთ კონკრეტული ნიშანი, რომელიც შემფასებელმა უნდა მოძებნოს. თუ ორი შემფასებელი ვერ თანხმდება, ჯერ კრიტერიუმი დააზუსტეთ და მხოლოდ შემდეგ ჩაწერეთ საცნობარო შეფასება მონაცემთა ნაკრებში.

LLM judge შინაარსობრივი შემთხვევების სწრაფად შესაფასებლად გამოიყენეთ, მაგრამ ჯერ ადამიანის მიერ შეფასებულ მაგალითებზე შეამოწმეთ. მიეცით მას იგივე რუბრიკა, მოთხოვნა, პასუხი და საჭირო საცნობარო მონაცემები; შემდეგ ნახეთ, რომელ შემთხვევებში განსხვავდება მისი შეფასება ადამიანისგან. განსაკუთრებით გადახედეთ შემთხვევებს, სადაც დამაჯერებელი ტექსტი მაღალ ქულას იღებს, მიუხედავად არასწორი ხელსაწყოს გამოყენებისა. ასეთ დარღვევას ცალკე კოდური შემოწმება უნდა აფიქსირებდეს.

დააწესეთ regression gate ცვლილებამდე

აგენტის prompt-ის, მოდელის, ხელსაწყოს აღწერის ან მარშრუტიზაციის შეცვლისას იგივე მონაცემთა ნაკრები ძველ და ახალ ვერსიებზე გაუშვით. შედარებაში აჩვენეთ არა მხოლოდ საშუალო ქულა, არამედ ისიც, რომელი დავალება გაუარესდა და რომელი წესი დაირღვა. კრიტიკული პირობები, მაგალითად უნებართვო მოქმედების არქონა, გამოშვების სავალდებულო მოთხოვნად აქციეთ; შინაარსობრივი ხარისხის მცირე ცვლილება კი ადამიანმა განიხილოს.

ტესტის გარემო გამეორებადი გახადეთ: შეინახეთ მოდელისა და prompt-ის ვერსია, ხელსაწყოს პასუხების ფიქსირებული მონაცემები, grader-ის ვერსია და შემთხვევის იდენტიფიკატორი. თუ შედეგი გაშვებებს შორის მერყეობს, ერთჯერად გაუმჯობესებას წარმატებად ნუ ჩათვლით. ცვლილების განხილვისას წარუმატებელი trace-იც შეინახეთ, რათა ჩანდეს, რომელი გადაწყვეტილება შეიცვალა.

წარმოებაში აღმოჩენილი შეცდომა ტესტად აქციეთ

LangSmith-ის შეფასების დოკუმენტაცია გაშვებამდე შესრულებულ offline შეფასებას ვერსიების შედარებისა და რეგრესიის ტესტებისთვის იყენებს, წარმოებაში მიმდინარე online შეფასებას კი ხარისხის მონიტორინგისა და უჩვეულო შემთხვევების გამოსავლენად. ამ ორი რეჟიმის დაკავშირება გუნდს აძლევს გზას, რეალურ გამოყენებაში ნაპოვნი შეცდომა მომდევნო ვერსიის შემოწმებაში შეიტანოს.

წარმოებაში დააკვირდით ხელსაწყოს შეცდომებს, აკრძალულ გამოძახებებს, უჩვეულოდ ხანგრძლივ ტრაექტორიებს და მომხმარებლის მიერ გასწორებულ პასუხებს. მნიშვნელოვან შემთხვევას დაურთეთ საჭირო კონტექსტი და მონაცემთა ნაკრებში შეტანამდე პირადი ინფორმაცია მოაშორეთ. შემდეგ აღწერეთ მოსალოდნელი ქცევა, დაამატეთ შესაბამისი grader და შემთხვევა regression gate-ში გაატარეთ.

ასევე წაიკითხეთ:

• AI აგენტის კარგი პასუხი საკმარისი არაა — შეამოწმეთ რეალური შედეგიც
• LLM API-ის დაბალი ფასი შეიძლება მოჩვენებითი იყოს — გადამწყვეტია პასუხის სიგრძე
• Carta თუ Pulley: უფასო დასაწყისი 25 აქციონერზე სრულდება