სისტემური მოთხოვნის სწავლება: AI სისტემების ახალი პარადიგმა

ოდესმე შეგიმჩნევიათ, რომ კონკრეტული მოთხოვნა კარგად მუშაობს, შემდეგ კი მოულოდნელად აღარ მუშაობს?

ოდესმე აღმოჩენილხართ სისტემური მოთხოვნის მუდმივად შესწორების წრეში, როცა შედეგების გაუმჯობესებას ცდილობთ, მაგრამ არაფერი ჭრის?

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

სისტემური მოთხოვნის სწავლება (SPL) AI-ის საზოგადოებაში ინტერესის ახალი სფეროა, რომელიც მაისში ანდრეი კარპატიმ X-ზე ფართოდ გააცნო საზოგადოებას.

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

სანამ დეტალებზე გადავალთ, მოკლედ მიმოვიხილოთ მოთხოვნების შექმნის საფუძვლები.

აგენტის ან მორგებული მოდელის შექმნისას ჯერ ორი ძირითადი კომპონენტი უნდა შევიმუშაოთ:

1. სისტემური მოთხოვნა

2. მომხმარებლის მოთხოვნა

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

“You are an intelligent assistant. Your role is to perform <insert task here>.

You must not do (A), (B), or (C).”

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

I’m in the capital city of Portugal. Can you suggest some things I can do tonight?

AI-ის წამყვანი ლაბორატორიების ახალი მოდელების გამოშვების შემდეგ სისტემური მოთხოვნების გაჟონვა ხშირი გახდა, რადგან მომხმარებლები ჩატბოტებს მწარმოებლის შეზღუდვებს უხსნიან და მათ ფარულ ინსტრუქციებს ამჟღავნებინებენ. დღეს პოპულარული GitHub-რეპოზიტორიუმი ამ სისტემური მოთხოვნებიდან ბევრს ერთ ადგილას აერთიანებს. ისინი გვიჩვენებს იმ „საიდუმლო ინგრედიენტს“, რომელიც AI-ის ლაბორატორიებმა დროთა განმავლობაში მოდელის სათანადო ქცევის წასახალისებლად შეიმუშავეს. მაგალითად, ახლახან გაჟონილი GPT-5-ის სისტემური მოთხოვნა (რომელიც ChatGPT-ში გამოავლინეს) დაახლოებით 6 000 სიტყვას შეიცავს, რაც აჩვენებს, რამდენი ცოდნისა და მითითების კოდირებაა საჭირო სისტემის ქცევის ჩამოსაყალიბებლად.

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

• ძიების ინსტრუქციები

• ხელსაწყოების განსაზღვრებები

• მომხმარებლის პრეფერენციები

• ციტირების ინსტრუქციები

• ცნობილი პრობლემების სწრაფი შესწორებები

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

მოდელის ქცევის მართვის სხვა გზებია:

• მოთხოვნების შექმნა, მათ შორის მოძიებით გაძლიერებული გენერაცია (RAG), რომელიც აკონტროლებს მოდელისთვის მიწოდებულ შიგთავსს

• დამატებითი სწავლება (მოდელის საბაზისო წონების უშუალოდ შეცვლა)

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

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

შენიშვნა: აგენტის ხელსაწყო არის ნებისმიერი გარე ფუნქცია, API ან რესურსი, რომლის გამოძახებაც AI აგენტს შეუძლია ტექსტის ფარგლებს გასცდეს და რეალური ქმედებები შეასრულოს.

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

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

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

მოდი, ეტაპობრივად და უფრო ახლოს განვიხილოთ, როგორ მუშაობს ეს პროცესი:

1. დაიწყეთ მომხმარებლის შეკითხვით და სისტემას კონკრეტული ამოცანის შესრულება სთხოვეთ.

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

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

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

პროგრამირების პრობლემების გადასაჭრელი გამარტივებული სტრატეგიების საცავის საწყისი მაგალითი.

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

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

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

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

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

• ლაკონიურობა (პასუხი მხოლოდ ერთი წინადადებით)

• შემოთავაზებული აქტივობის შესაბამისობა

• მდებარეობის სიზუსტე

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

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

LLM-ებს ხშირად სჭირდება დეტალური ინსტრუქციები და დამატებითი ნაბიჯები იმ კონტექსტური ცოდნის შესაგროვებლად, რომელიც ადამიანებს პრობლემის გადაჭრისას ბუნებრივად მოაქვთ. რაც უფრო ფართო პრობლემებს მოიცავს სისტემა, მით უფრო სწრაფად შეიძლება გაიზარდოს საჭირო ამოცანების რაოდენობა. მაგალითად, პროგრამირების პრობლემაზე მომუშავე ადამიანმა შეიძლება მის გარშემო არსებული კოდური ბაზა ინტუიციურად გაიგოს, LLM-ს კი ჯერ რამდენიმე ფაილის „წაკითხვა“ დასჭირდეს.

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

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

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

• როდის არ არის სასარგებლო: თუ თქვენი გუნდი AI-ს ძირითადად მარტივი სამუშაო პროცესებისთვის იყენებს, სადაც ადამიანის ჩართულობა მინიმალურია, მაგალითად, ინვოისების დამუშავებისთვის, თანამშრომლობის ხარჯმა შეიძლება სარგებელს გადააჭარბოს.

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

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

თეორიულად ეს ყველაფერი იმედისმომცემად ჟღერს, თუმცა SPL-ის დანერგვას რეალური გამოწვევები ახლავს. ქვემოთ რამდენიმე ძირითად გამოწვევას განვიხილავთ:

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

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

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

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

სტრატეგიების საცავის დახვეწისას გაითვალისწინეთ:

• სიცოცხლის ციკლი: ამოიღეთ სტრატეგიები, როცა ისინი განსაზღვრულ ვადას ან გენერაციების რაოდენობას გადააჭარბებს.

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

• LLM-ის შეფასება: პერიოდულად შეაფასეთ სტრატეგიები და გამოავლინეთ ისინი, რომლებიც უნიკალურ მიგნებებს აღარ გვთავაზობს, რადგან მათი სასარგებლო ელემენტები, სავარაუდოდ, უკვე ახალ ვერსიებშია შეტანილი.

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

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

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