თამაშების აღქმადობა LLM-აგენტებისთვის

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

რატომ უჭირთ LLM-ებს თამაშებთან

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

დეტერმინიზმი და რეპროდუცირებადი მდგომარეობები

იმისთვის, რომ თამაში აგენტისთვის აღქმადი გახდეს, დეტერმინიზმი მთავარია. თამაშს უნდა შეეძლოს კონკრეტული მდგომარეობის მარტივად და ზუსტად რეპროდუცირება. ეს მოითხოვს შემთხვევითობის ერთიანი seed-იანი წყაროს არსებობას თავიდანვე, რაც უზრუნველყოფს, რომ არადეტერმინისტულ ფუნქციებზე ყოველი გამოძახება ამ წყაროს იყენებდეს. თუ კოდი შემთხვევითი float ფუნქციას 30 ადგილას იძახებს, 30-ე გამოძახება ყოველ ჯერზე იდენტური უნდა იყოს. რეპროდუცირებადი მდგომარეობები აგენტებს საშუალებას აძლევს ნულიდან განმეორებით მიაღწიონ იმავე წერტილს ცვლილებების შესამოწმებლად. ასევე რეკომენდებულია ჩაშენებული screenshot API-ები. UI-ის და gameplay-ის ფენების ჩართვა-გამორთვა ამცირებს ვიზუალურ ხმაურს და LLM-ს საშუალებას აძლევს ფოკუსირდეს კონკრეტულ ფენაზე, რომელზეც მუშაობა მიმდინარეობს.

თამაშების AI-სთვის აღქმადად ქცევა

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

არქიტექტურა აგენტებისთვის: Thing Driven Development

არქიტექტურულ არჩევანსაც აქვს მნიშვნელობა. ღრმა ობიექტზე ორიენტირებული პროგრამირების იერარქიების შენარჩუნება AI-აგენტებში დაბნეულობას იწვევს, როცა ცდილობენ დაადგინონ, სად შეიტანონ ცვლილებები. ამის ნაცვლად, დეველოპერებმა უნდა დანერგონ Thing Driven Development. ეს გულისხმობს, რომ ყველაფერი ერთი ტიპის ობიექტია, ანუ Thing, stat მნიშვნელობებით და type enum-ით. AI-ს ეს მოსწონს, რადგან არსებობს ერთი სიმართლის წყარო. არ არის გაურკვევლობა, გავაფართოოთ კლასი თუ შევქმნათ ახალი. შენახვა და ჩატვირთვაც ტრივიალური ხდება. თამაში უბრალოდ Thing-ების გიგანტურ სიად იქცევა, რომელიც ერთი გზით სერიალიზდება. ამ ობიექტებში ცვლილებების დაფიქსირება შესაძლებელია Command Pattern-ის გამოყენებით, მოდიფიკაციების სერიალიზებადი command ობიექტების სახით შენახვით.

წყაროები: kylekukshtel.com