
Jev-ის მსგავსი wrapper: ერთი Python ფუნქცია LLM-ებისა და ვიზუალური მოდელებისთვის
2026 წლის სექტემბერში გამოქვეყნებულ ბლოგპოსტში ავტორი აჩვენებს ერთ Python ფუნქციას, რომელიც რამდენიმე LLM-პროვაიდერს, ვიზუალური მოდელების ჩათვლით, გამოძახების ერთიან ინტერფეისად აქცევს და ღია ტექსტით აღწერილ კითხვებს ალბათობებად ქცეულ პასუხებს უბრუნებს.
2026 წლის სექტემბერში გამოქვეყნებულ ბლოგპოსტში ავტორი აღწერს ერთ Python ფუნქციას, რომელიც რამდენიმე LLM-პროვაიდერს, ვიზუალური მოდელების ჩათვლით, გამოძახების ერთიან ინტერფეისად აქცევს. მისი თქმით, იდეა Jev-ისა და მის გარშემო არსებული თვითგანთავსებადი პროექტების, OpenJev-ისა და SemIf-ის, შესწავლიდან დაიბადა, რამაც მას LLM-ის ტოკენების ალბათობების წაკითხვის ხერხი გააცნო.
რას ნიშნავს „Jev-ის მსგავსი“
Jev-ის დოკუმენტირებული მოთხოვნის ფორმატი JSON დოკუმენტს იღებს: მასში შედის ტექსტური მდგომარეობა და კითხვების ნაკრები. ავტორის wrapper იგივე სტრუქტურას ინარჩუნებს, თუმცა საკუთარი დანამატით: დოკუმენტს ემატება attachments ველი სურათებისთვის, რომელსაც ოფიციალური ფორმატი არ აღწერს. ანუ „Jev-ის მსგავსი“ აქ მოთხოვნა-პასუხის სტრუქტურას ნიშნავს და არა თავად პროექტს.
როგორ მუშაობს wrapper
ყოველი კითხვა ჩამონათვალის ტიპის პრომპტად გადაიწერება, ვარიანტები A-დან T-მდე ასოებით აღინიშნება და ჩვეულებრივი HTTP მოთხოვნით იგზავნება. მოდელს მხოლოდ ერთი ტოკენის გამოტანა ევალება, სამაგიეროდ API ასოებთან ერთად მათ log-ალბათობებსაც აბრუნებს. ეს რიცხვები ალბათობებად გადაითვლება და პასუხიც მათზე დაყრდნობით დგინდება: choice-ტიპის კითხვაზე ყველაზე მაღალი ალბათობის ვარიანტი იმარჯვებს, noul-ტიპის დიახ/არა კითხვა „true“-ს ალბათობას უბრუნებს, score-ტიპი კი კრიტერიუმებს შორის მოსალოდნელ დონეს ითვლის. თითო კითხვას 2-დან 20 ვარიანტამდე აქვს; თუ პროვაიდერი რომელიმე ვარიანტს გამოტოვებს და მისი ალბათობა უგულებელყოფადი არ არის, ფუნქცია შეცდომას აბრუნებს და არ ცდილობს გამოცნობას.
პროვაიდერები, სურათები და სიჩქარე
მაგალითი ნაგულისხმევად ლოკალურ llama.cpp-სერვერს მიმართავს, გასაღების არსებობისას კი OpenAI-ს; API-გასაღები მხოლოდ api.openai.com-ს ეგზავნება. llama.cpp log-ალბათობებისთვის Chat Completions-ს საჭიროებს, OpenAI კი საკმარისი ალტერნატივების საჩვენებლად Responses-ს, და სკრიპტი ამ სხვაობას თავად აგვარებს. სურათები base64 data URL-ის სახით მიემგზავრება, ამიტომ იგივე კითხვები ვებკამერის კადრზეც შეიძლება დაისვას. დემოში ავტორი კადრებს OpenCV-ით კითხულობს, რომელიც მხოლოდ კამერაზე წვდომას ემსახურება, და პასუხების ცხრილს ბეჭდავს. RTX 3090-ზე Gemma 4 12B-ით, კადრზე სამი კითხვით, წამში დაახლოებით ერთი კადრი მიიღება; gpt-6-luna-ს API-ით წამში დაახლოებით 0,2 კადრი.
რაზე ამახვილებს ავტორი ყურადღებას
ავტორი პირდაპირ ამბობს, რომ სპეციალიზებული კომპიუტერული ხედვის მოდელები გაცილებით ეფექტურია, მისი მიდგომის ღირებულება კი მოქნილობაა: ახალი პირობა ჩვეულებრივი ტექსტით აღწერით ემატება. ის ასევე აღნიშნავს, რომ შეყვანის დამუშავება მაინც დროს მოითხოვს, საერთო state-პრეფიქსი ბექენდის მხარდაჭერის შემთხვევაში ქეშირდება, ხოლო მოცემული სიჩქარის მაჩვენებლები დაუოტიმიზებული კონფიგურაციიდან მიიღება, სადაც თითო კითხვა-კადრზე ცალკე კავშირი გამოიყენება.
SiTech — AI-გაძლიერებული ვებ დეველოპმენტი
ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.