მოდელის ბარათი 1M კონტექსტს ჰპირდება, პროვაიდერები კი ხშირად 32K-ს აძლევენ

ღია წონებზე მომუშავე chat- და coding აგენტის ავტორი dev.to-ზე 26 სექტემბერს აფრთხილებს, რომ მოდელის ბარათზე მითითებული კონტექსტის ფანჯარა იშვიათად ემთხვევა იმას, რასაც ჰოსტინგის პროვაიდერი რეალურად აძლევს.

ბარათზე დაწერილი ციფრი რეალურად მიღებული კონტექსტი არ არის

მოდელის ბარათზე მითითებული კონტექსტი წონების თვისებაა, ხოლო ის, რასაც პასუხად იღებთ, იმაზეა დამოკიდებული, ვინ ჰოსტავს მოდელს. ავტორის მიერ შემოწმებულ endpoint-ებზე უმეტესობა დაახლოებით 32K token-ს აძლევს, მიუხედავად იმისა, რას აცხადებს ბარათი; მცირე ნაწილი 256K-ს აღწევს, 1M-ის ციფრი კი ჯერ არც ერთ endpoint-ზე არ დაფიქსირებულა.

ოპერატორის მხრიდან ეს გასაგებია: კონტექსტის მაქსიმალური სიგრძე KV-cache-ის ბიუჯეტია, დაკავშირებული ერთდროულ მოთხოვნებთან. პრობლემა ის არის, რომ ეს თითქმის არასდროს არის დოკუმენტირებული და ჩუმად ხდება.

შეცდომა არ ჩნდება

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

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

როგორ გავიგოთ რეალური ზღვარი

გაგზავნეთ განზრახ ზედმეტად დიდი მოთხოვნა და წაიკითხეთ შეცდომა: პროვაიდერები შეცდომის ტექსტში ხშირად რეალურ მაქსიმუმს ასახელებენ, ამიტომ endpoint-ზე, რომელიც 1M-ს გვპირდება, 500K token-ის გაგზავნა რეალურ ჭერს ავლენს. მეორე მეთოდი უხეშია: იპოვეთ მომენტი, სადაც ყველაზე ადრეული შიგთავსი პასუხზე გავლენას წყვეტს, და უკან დაითვალეთ.

დოკუმენტაცია და მოდელის ბარათი სანდო არ აღმოჩნდა.

სამი შედეგი, რომელიც უნდა გაითვალისწინოთ

Benchmark-ის ქულა კონკრეტულ კონტექსტის სიგრძეზე მიღებული შეფასებაა და არა მოდელის თვისება: ერთი და იგივე წონები 32K-ზე და 200K-ზე ერთი და იგივე აგენტი არ არის. რეალური ჭერის დაფიქსირების გარეშე token-ის ფასით შედარება სხვაობას ფასს უწოდებს.

Fallback-ების მქონე gateway-ზე ჭერი სესიის შუაში იცვლება. გაშვება, რომელიც 200K-ის პროვაიდერზე იწყება და 32K-იანზე გადადის, შეცდომას არ იძლევა, არამედ კონტექსტს ჭრის. ეს სისწორის პრობლემაა და არა წარმადობის.

RAG-ში ეს ჩუმად აუქმებს retrieval-ის მორგებას: chunk-ის ზომა, top-k და reranking ბარათიდან აღებულ ბიუჯეტზეა მორგებული. 128K-ზე მორგებული, მაგრამ 32K-ზე მომუშავე სისტემა ზედმეტ ინფორმაციას ეძებს, reranked chunk-ები იჭრება და პასუხი თავდაჯერებული და არასწორია; გუნდი კი შემდეგ embedding-ის მოდელს ასწორებს.

ავტორის სურვილი მოკლეა: შესაძლებლობა, მოთხოვნისთვის რეალურად მოქმედი კონტექსტის წაკითხვა მოდელის მეტამონაცემებში ან პასუხის header-ში. ის ქმნის Grunz-ს, chat- და coding აგენტს ღია წონებზე.