DeepEval თუ Ragas: CI ტესტი და მეტრიკების არჩევანი სხვადასხვა გზას ქმნის

თუ RAG სისტემის ცვლილებას pytest ტესტის ჩავარდნით აკონტროლებთ, DeepEval პირდაპირ გზას გაძლევთ: DeepEval-ის RAG ინსტრუქცია აჩვენებს assert_test()-ს, deepeval test run ბრძანებას და მოძიებისა და პასუხის გენერაციის ცალკე შეფასებას. Ragas-იც შეიძლება CI-ში გამოიყენოთ, მაგრამ მის შემთხვევაში მეტრიკის არჩევასა და მიღებული ქულისთვის შემოწმების წესის დაწერას მეტი ყურადღება სჭირდება.

თუ გუნდი ჯერ არკვევს, რა უნდა გაზომოს, Ragas უფრო მრავალფეროვან არჩევანს სთავაზობს. Ragas-ის მეტრიკების სიაში context precision, context recall და faithfulness-თან ერთად ინსტრუმენტის გამოძახებისა და სხვა ამოცანების შეფასებაც შედის. არჩევანის დასაწყისი კონკრეტული კითხვაა: საჭირო ინფორმაცია მოიძებნა, პასუხი მოძიებულ ტექსტს დაეყრდნო, თუ მომხმარებლის მოთხოვნას სათანადოდ უპასუხა?

ერთი შემთხვევა, ერთი და იგივე მონაცემები

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

შედარებისას უცვლელად შეინახეთ შეკითხვა, სისტემის პასუხი და მოძიებული ფრაგმენტები იმავე მიმდევრობით. DeepEval-ის სატესტო შემთხვევის შესაბამისი ველებია input, actual_output და retrieval_context; Ragas-ის შეფასებაში ანალოგიურ როლს ასრულებს user_input, response და retrieved_contexts. ველების სახელები განსხვავდება, მაგრამ ორივე მხარეს ერთი და იგივე სისტემის შედეგი უნდა მიეწოდოს. თუ ფრაგმენტების რიგი ან პასუხი შეიცვალა, მიღებული სხვაობა ბიბლიოთეკებს ვეღარ მიეწერება.

ეტალონური პასუხი ამ პირობით შემთხვევაში იქნებოდა „განაცხადი პორტალიდან იგზავნება“. DeepEval-ში მისთვის expected_output გამოიყენება, Ragas-ში — reference. ეს ველი ყველა მეტრიკისთვის აუცილებელი არ არის: მისი საჭიროება იმაზეა დამოკიდებული, პასუხს თავად მოძიებულ კონტექსტს ადარებთ თუ წინასწარ შეთანხმებულ სწორ პასუხს. ეტალონის ხარისხიც მნიშვნელოვანია — არასრული ეტალონი შეიძლება სწორად მოძიებულ ინფორმაციას გამორჩენილად წარმოაჩენდეს.

რომელი მეტრიკა რას ამოწმებს

Faithfulness ამოწმებს, ეყრდნობა თუ არა გენერირებული პასუხის მტკიცებები მოძიებულ ფრაგმენტებს. პირობით მაგალითში პასუხი „პორტალიდან“ მოცემულ წყაროს შეესაბამება. პასუხი „ელფოსტით“ შეიძლება შეკითხვის ფორმას მაინც პასუხობდეს, მაგრამ ამ ფრაგმენტში არ დასტურდებოდეს. ამიტომ წყაროსთან შესაბამისობა და შეკითხვასთან რელევანტურობა ერთმანეთის ნაცვლად არ უნდა გამოიყენოთ.

Context precision-ის შემთხვევაში მნიშვნელოვანია, რა მიიჩნევა გამოსადეგ ფრაგმენტად და სად დგას ის მოძიების რიგში. Ragas-ის context precision-ის განმარტება განასხვავებს ეტალონურ პასუხზე დაფუძნებულ ContextPrecision-ს და ContextUtilization-ს, რომელიც ფრაგმენტებს უკვე გენერირებულ პასუხს ადარებს. პირველს reference სჭირდება, მეორეს — response. ერთი და იმავე ფრაგმენტების შემთხვევაშიც ეს მეტრიკები სხვადასხვა კითხვას პასუხობს: რა იყო საჭირო სწორი პასუხისთვის და რა გამოიყენა სისტემამ მიღებულ პასუხში.

Context recall ამოწმებს, მოიძებნა თუ არა ეტალონური პასუხისთვის საჭირო ინფორმაცია. Ragas-ის შესაბამის ვარიანტს შესადარებლად reference ან reference_contexts სჭირდება; DeepEval-ის Contextual Precision და Contextual Recall expected_output-ს მოითხოვს. პირობით მაგალითში პორტალის შესახებ ფრაგმენტის საერთოდ გამოტოვება recall-ის პრობლემაზე მიანიშნებს. თუ ფრაგმენტი მოიძებნა, მაგრამ სატელეფონო მხარდაჭერის ტექსტის შემდეგ მოხვდა, უფრო გამოსადეგი კითხვა მისი რიგისა და context precision-ის შეფასებაა.

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

ორივე მუშაობს CI-ში, მაგრამ ჩავარდნას სხვადასხვაგვარად ადგენს

DeepEval-ში pytest ტესტი ქმნის LLMTestCase-ს, მეტრიკებს assert_test()-ს გადასცემს და არჩეული ზღვრის დაუკმაყოფილებლობისას ტესტს აგდებს. მისი ინსტრუქცია ასევე აჩვენებს გზას, რომლითაც retriever-ისა და generator-ის ნაბიჯებს ცალკე მეტრიკები მიენიჭება, თუ გუნდი RAG სისტემის კოდს მართავს. ასე პასუხის გაუარესებისას უფრო გასაგები ხდება, სად გაჩნდა პრობლემა: მოძიებულ მასალაში თუ მის საფუძველზე შედგენილ პასუხში.

Ragas-ს pytest-ის გზა ნამდვილად აქვს. Ragas-ის CI ინსტრუქცია evaluate()-ს pytest ტესტში უშვებს, აჩვენებს in_ci=True პარამეტრს და მიღებულ ქულებზე ცალკე assert პირობებს წერს. დოკუმენტაციის მიხედვით, ეს რეჟიმი მეტრიკების შედეგებს უფრო გამეორებადს ხდის, თუმცა შეფასებას აძვირებს. განსხვავება იმაშია, რომ მაგალითში ჩავარდნის პირობას გუნდი თითოეული ქულისთვის თავად წერს, ხოლო DeepEval-ის მაგალითი ამ გადაწყვეტილებას assert_test()-ში მოქცეულ მეტრიკას აბარებს.

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

რატომ ვერ ცვლის ქულა ადამიანურ შეფასებას

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

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

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

არჩევანი გუნდის სამუშაო წესზეა დამოკიდებული

DeepEval აირჩიეთ, როცა უკვე იცით, რომელი RAG შემთხვევები უნდა იქცეს ტესტად და გინდათ მათი ჩავარდნა pytest-სა და CI-ში პირდაპირ გამოჩნდეს. Ragas გამოგადგებათ, როცა პირველ რიგში მეტრიკების ვარიანტები, ეტალონის საჭიროება და შეფასების სქემა გაქვთ გასარკვევი; ამის შემდეგ მისი ქულებიც შეიძლება pytest-ის პირობად აქციოთ. ორივე შემთხვევაში არჩევანი საკუთარი შეკითხვებით, შენახული მოძიებული ფრაგმენტებითა და ხარისხის შეთანხმებული კრიტერიუმით უნდა შემოწმდეს.

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

• n8n თუ Make: გრძელი ავტომატიზაციის ფასს სხვადასხვა მრიცხველი ცვლის
• Braze-ში Amazon Bedrock შედის — მოდელის არჩევანი მარკეტინგის ხარჯიც ხდება
• Claude Code თუ Gemini CLI: უფასო არჩევანსაც სჭირდება მკაცრი კონტროლი