თვითევოლუცია

თვითევოლუციის სისტემა არის 9,806 სტრიქონი Rust კოდი 22 მოდულში. ის საშუალებას აძლევს PRX-ს გააუმჯობესოს საკუთარი ქცევა დროთა განმავლობაში — არა მოდელების ხელახალი ტრენინგით, არამედ მათ გარშემო არსებული პრომპტების, მეხსიერების სტრუქტურებისა და ოპერაციული სტრატეგიების ევოლუციით.

პაიპლაინი

თვითევოლუცია მუშაობს სამფაზიანი ციკლით:

ჩაწერა (რეალურ დროში)
  │  ყოველი მოთხოვნა/პასუხის წყვილი ლოგირდება მეტამონაცემებით
  │
  ▼
ანალიზი (ყოველდღიური)
  │  შაბლონების ამოღება: წარუმატებლობის რეჟიმები, ნელი გზები, ხარჯის გადახრები
  │
  ▼
ევოლუცია (ყოველ 3 დღეში)
     კანდიდატ გაუმჯობესებების გენერირება, ჩრდილის რეჟიმში ტესტირება, დაწინაურება ან უკუქცევა

ჩაწერის ფაზა (რეალურ დროში)

ყოველი ინტერაქცია ჩაიწერება:

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

ეს მონაცემები გროვდება ლოკალურ საცავში, აშენებს მტკიცებულებათა ბაზას ანალიზისთვის.

ანალიზის ფაზა (ყოველდღიური)

ყოველდღიური ანალიზის ამოცანა ამუშავებს ბოლო ჩანაწერებს შემდეგის გამოსავლენად:

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

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

ევოლუციის ფაზა (ყოველ 3 დღეში)

დაგროვილი ანალიზის აღმოჩენების საფუძველზე, ევოლუციის ძრავა გენერირებს კანდიდატ ცვლილებებს:

ევოლუციის სამი ფენა

პრომპტის ევოლუცია

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

• ინსტრუქციების გადაწერა, რომლებმაც არასწორ ინტერპრეტაციას მოჰყვა
• რეალური წარუმატებლობის შემთხვევებზე დაყრდნობით few-shot მაგალითების დამატება ან დახვეწა
• ტონის, სიტყვიერების ან ფორმატირების დირექტივების რეგულირება
• ინსტრუმენტების გამოყენების ინსტრუქციების მორგება, როცა ინსტრუმენტების გამოძახებები ვერ ხერხდება

მეხსიერების ევოლუცია

prx-memory-ში შენახული ცოდნის გაუმჯობესება:

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

სტრატეგიის ევოლუცია

ოპერაციული პარამეტრების რეგულირება:

• როუტერის ქულის წონები (alpha, beta, gamma, delta, epsilon)
• Automix-ის საიმედოობის ზღვრები
• კონკურენტულობის ლიმიტები არხზე
• ტაიმაუტის ბიუჯეტები
• ნაგულისხმევი მოდელის პრეფერენციები განზრახვის კატეგორიის მიხედვით

უსაფრთხოების სისტემა

თვითევოლუცია ძლიერია, მაგრამ საშიში. PRX ახორციელებს უსაფრთხოების მრავალ ფენას რეგრესიების თავიდან ასაცილებლად.

კარიბჭის შემოწმებები

ნებისმიერი კანდიდატი ცვლილების გამოყენებამდე, მან უნდა გაიაროს კარიბჭის შემოწმებები:

1. სინტაქსის ვალიდაცია — ცვლილებამ უნდა წარმოქმნას ვალიდური კონფიგურაცია/პრომპტები
2. რეგრესიის ტესტი — ბოლო წარმატებული ინტერაქციების ნიმუშის ხელახალი გაშვება შემოთავაზებული ცვლილებით და გამოსავლების მისაღებობის ვერიფიკაცია
3. ფარგლების შემოწმება — ცვლილება არ უნდა გასცდეს ნებადართულ ფარგლებს (მაგ., პრომპტის ევოლუცია ვერ შეცვლის უსაფრთხოების პოლიტიკას)

ჩრდილის რეჟიმი

კანდიდატი ცვლილებები ჯერ გაშვებულია ჩრდილის რეჟიმში:

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

ჩრდილის რეჟიმი მუშაობს კონფიგურირებადი შეფასების პერიოდის განმავლობაში (ნაგულისხმევი: 24 საათი).

მსაჯი მოდელი

ცალკე მსაჯი მოდელი აფასებს ჩრდილის რეჟიმის შედეგებს. ის ადარებს პროდაქშენის და კანდიდატის გამოსავლებს მოთხოვნების ნიმუშზე და აფასებს კანდიდატს 0-1 შკალაზე.

• ზღვარი: 0.6 — 0.6-ზე ქვემოთ კანდიდატები უარყოფილია
• მსაჯი მოდელი ჩვეულებრივ არის ძლიერი მსჯელობის მოდელი (მაგ., Claude Opus, o3), განსხვავებული შეფასებული მოდელებისგან
• მსაჯის პრომპტები თავად ვერსიონირებულია და არ ექვემდებარებიან თვითევოლუციას (თამაშის თავიდან ასაცილებლად)

ამომრთველი

თუ დაწინაურებული ცვლილება იწვევს წარუმატებლობების ზრდას გაშლის შემდეგ:

1. ამომრთველი აქტიურდება, როცა წარუმატებლობის სიხშირე აჭარბებს საბაზისოს 2-ჯერ 1-საათიან ფანჯარაში
2. ცვლილება ავტომატურად უკუქცევულია
3. ინციდენტის ჩანაწერი იქმნება წარუმატებლობის მტკიცებულებებით
4. ცვლილება მონიშნულია წარუმატებლად და არ ცდება ხელახლა მოდიფიკაციის გარეშე

ვერსიის სნეპშოტები

ყოველი კონფიგურაციის მდგომარეობა ვერსიონირებულია:

v1.0  ── საწყისი კონფიგურაცია
v1.1  ── პრომპტის ევოლუცია: გაუმჯობესებული კოდირების ინსტრუქციები
v1.2  ── სტრატეგიის ევოლუცია: როუტერის წონების რეგულირება
v1.3  ── უკუქცეული (ამომრთველი აქტიურდა)
v1.2  ── აღდგენილი (მიმდინარე)

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

ექსპერიმენტის თვალყურის დევნება

ყველა ევოლუციის მცდელობა თვალყური ედევნება:

ველი	აღწერა
კანდიდატის ID	შემოთავაზებული ცვლილების უნიკალური იდენტიფიკატორი
ფენა	prompt / memory / strategy
ტრიგერი	ანალიზის აღმოჩენა, რომელმაც მოტივირება გაუწია ცვლილებას
ჩრდილის მეტრიკები	დაკვირვებული ხარისხის, დაყოვნების, ხარჯის დელტები
მსაჯის ქულა	მსაჯი მოდელის ქულა
შედეგი	დაწინაურებული / უარყოფილი / უკუქცეული
ხანგრძლივობა	დრო, რომლის განმავლობაში იყო ცვლილება აქტიური უკუქცევამდე (თუ მოხდა)

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

RollbackManager

RollbackManager ამუშავებს ავტომატურ და ხელით უკუქცევებს:

• ავტომატური — აქტიურდება ამომრთველით, როცა წარუმატებლობის სიხშირე იზრდება
• ხელით — ოპერატორებს შეუძლიათ უკუქცევა ნებისმიერ წინა ვერსიაზე CLI-ით ან API-ით
• სელექციური — მხოლოდ ერთი ფენის უკუქცევა (მაგ., პრომპტის ცვლილებების დაბრუნება სტრატეგიის ცვლილებების შენარჩუნებით)

# ევოლუციის ისტორიის ნახვა
prx evolution history

# უკუქცევა კონკრეტულ ვერსიაზე
prx evolution rollback v1.2

# მხოლოდ პრომპტის ცვლილებების უკუქცევა
prx evolution rollback --layer prompt v1.1

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