AI ინტერვიუს კითხვა 2: როგორ უზრუნველვყოთ დიდი ენობრივი მოდელის (LLM) ინსტრუმენტების გამოძახების სანდოობა

როგორ უზრუნველვყოთ, რომ დიდი ენობრივი მოდელი (LLM) ინსტრუმენტების გამოძახებისას მუშაობდეს საიმედოდ და კონტროლირებად, მხოლოდ მინიშნებებზე (prompts) დაყრდნობის გარეშე. საჭიროა სისტემატური, მრავალდონიანი შეზღუდვების ჩარჩოს მიწოდება.

მაგალითად, ამინდის შეკითხვისას, მოდელის მიერ ინსტრუმენტების გამოძახებისას სამი ტიპიური "გამოგონილი" ქცევა:
1. ინსტრუმენტის გამოუძახებლად, პირდაპირ გამოგონილი პასუხის მიცემა.
2. ინსტრუმენტის გამოძახებისას არასწორი ფორმატის პარამეტრების გადაცემა (მაგ., ინსტრუმენტი არ უჭერს მხარს "ზეგ", მაგრამ გადაეცემა date="ზეგ").
3. პარამეტრების ფორმატის თვითნებურად შეცვლა (მაგ., "ზეგ"-ის კონკრეტულ თარიღად გადაქცევა), მაშინაც კი, თუ ინსტრუმენტს ეს არ მოეთხოვება.

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

ამ პრობლემის გადასაჭრელად, საჭიროა მრავალდონიანი საინჟინრო გადაწყვეტა:

1. პირველი დონე: მინიშნებების ოპტიმიზაცია (რბილი შეზღუდვები)

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

2. მეორე დონე: JSON Schema-ს დანერგვა (მკაცრი შეზღუდვები)

   • ეს არის გადამწყვეტი ნაბიჯი "დარწმუნებიდან" "შემოზღუდვისკენ".
   • ბუნებრივი ენით პარამეტრების აღწერის ნაცვლად, გამოიყენეთ მანქანით წაკითხვადი, გადამოწმებადი სტრუქტურირებული განსაზღვრება (JSON Schema). მას შეუძლია მკაცრად განსაზღვროს ველების ტიპები, სავალდებულოობა, ჩამოთვლილი მნიშვნელობების დიაპაზონი, და additionalProperties: false-ის დაყენებით აკრძალოს მოდელის მიერ ნებისმიერი განუსაზღვრელი ველის გამოტანა.
   • მთავარი API პლატფორმები მხარს უჭერენ ასეთ სტრუქტურირებული გამომავლის შეზღუდვას მოდელის დეკოდირების ფაზაში, რაც თავიდანვე გამორიცხავს ფორმატის დარღვევებს.

3. მესამე დონე: ვალიდაცია-შესწორება-ხელახალი მცდელობის ციკლის შექმნა (აღსრულების უკანასკნელი საშუალება)

   • Schema-ს არსებობის შემთხვევაშიც კი, მოდელის გამომავლის მიღების შემდეგ საჭიროა სინტაქსური და Schema ვალიდაცია.
   • ვალიდაციის წარუმატებლობისას, უნდა შეიქმნას ავტომატური გაწმენდისა და ხელახალი მცდელობის მექანიზმი (ლიმიტით), რომელიც შეცდომის ინფორმაციას უკუკავშირის სახით გადასცემს მოდელს გამომავლის გამოსასწორებლად. ხელახალი მცდელობების ლიმიტის გადაჭარბების შემდეგ, საჭიროა დეგრადაციის ან ადამიანის ჩარევის გეგმა.

4. არქიტექტურული დონე: პასუხისმგებლობების გამიჯვნა

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

მიმდინარე გადაწყვეტის შეზღუდვები: კარგად უმკლავდება პარამეტრების ფორმატის პრობლემებს, მაგრამ პარამეტრების სემანტიკის (მაგ., "შანხაი"-სა და "沪"-ს ეკვივალენტობა) ვალიდაციის მოცვა ჯერ კიდევ არასაკმარისია. ეს იქნება საინჟინრო გამოწვევა მომავალში.

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