მოდელი თქვენი ბაზის თავზე: პროგნოზი გაწვრთნის გარეშე, დროითი მწკრივები და ძებნა Postgres-ში

NVIDIA-მ გამოაქვეყნა მოდელი, რომელიც რელაციურ ბაზაზე პროგნოზებს აკეთებს კონკრეტულ ამოცანაზე გაწვრთნის გარეშე, IBM-მა დროითი მწკრივების ოთხი მოდელი ერთ ანსამბლად შეკრიბა, TigerData-მ კი PostgreSQL-ის შიგნით ძებნის ბიბლიოთეკა გახსნა. საერთო აზრი ასეთია: კომპანიის მონაცემები უკვე ბაზაშია, და კითხვები „რა იქნება შემდეგ“ და „რა იყო მაშინ“ შეიძლება პირდაპირ მას დაუსვა. ბიზნესის მფლობელისთვის მოთხოვნის ან კლიენტების გადინების პროგნოზის ზღვარი ერთ ბაზამდე ჩამოვიდა, რომელშიც ისტორია ინახება.

რა გამოვიდა

NVIDIA-მ 21 ოქტომბერს Hugging Face-ის ბლოგში წარადგინა Kumo Relational. მოდელი კითხულობს ცხრილებს, გარე გასაღებებსა და დროის ნიშნულებს და პასუხობს საპროგნოზო მოთხოვნას, მაგალითად, რომელი კლიენტი წავა ან რამდენი ერთეული გაიყიდება. ამოცანაზე გაწვრთნისა და ნიშნების ხელით აწყობის გარეშე. 15 ბაზის 41 ამოცანაზე მან აჯობა გაწვრთნილ მოდელებსა და გრადიენტულ ბუსტინგზე აგებულ პაიპლაინებს. პროგნოზისთვის მოდელი მხოლოდ საკონტროლო თარიღამდე მომხდარ მოვლენებს იღებს, რომ მომავალში არ ჩაიხედოს. კოდი და წონები ღიაა.

IBM Research-მა 22 ოქტომბერს იქვე აღწერა Granite-ის ანსამბლი დროითი მწკრივებისთვის. განსხვავებული არქიტექტურის ოთხი წინასწარ გაწვრთნილი მოდელი პროგნოზს იძლევა, რეცეპტი კი მათ მედიანად და კვანტილებად აერთიანებს. ნაგულისხმევად ოთხივე მოდელს თანაბარი გავლენა აქვს, დამატებით არაფერი იწვრთნება. კვანტილები 0,1 და 0,9 იძლევა ინტერვალს 80%-იანი ნომინალური დაფარვით. ამოწმებდნენ GIFT-Eval-ის 97 კონფიგურაციაზე, დამატებითი გაწვრთნის გარეშე.

TigerData-მ 20 ოქტომბერს გახსნა searchgres.js, TypeScript-ზე დაწერილი ბიბლიოთეკა Apache-2.0 ლიცენზიით: PostgreSQL-ზე ერთი მოთხოვნა აერთიანებს სიტყვებით ძებნას BM25-ით, ვექტორულ ძებნას და ფილტრებს იერარქიით, მეტამონაცემებითა და დროით. მაგალითი სტატიიდან: ელექტროსადგურის ოპერატორი გრაფიკზე მონიშნავს ნახევარ საათს, როცა სიმძლავრე დაეცა, და იკითხავს: „ეს დაგეგმილი იყო?“. ძებნა იპოვის დისპეჩერის მითითებას და ცვლის ჩანაწერს ამ ბლოკისა და დროის მიხედვით. ფილტრები რანჟირებამდე მოქმედებს, ამიტომ საჭირო ჩანაწერი პირველი ოცეულიდან არ ვარდება.

ორი დღის შემდეგ, 22 ოქტომბერს, იმავე გუნდმა მოგვითხრო, როგორ აშენებდა მეხსიერების სამ სისტემას თავისი Slack-აგენტისთვის. ფაქტების სია ზედმეტად ღარიბი აღმოჩნდა. ცოდნის საერთო გრაფი SQL-ზე თავისუფალი წვდომით ზედმეტად თავისუფალი აღმოჩნდა: აგენტები ათობით სვლას ბაზის მექანიკაზე ხარჯავდნენ ამოცანის ნაცვლად. ltree გაფართოებაზე აგებულმა ხემ ყოველ ჩანაწერს თავისი ადგილი და ოპერაციების გასაგები ნაკრები მისცა. ყველაზე გამომსახველი სისტემა ყველაზე სასარგებლო არ აღმოჩნდა.

Weaviate-მა 14 ოქტომბერს აღწერა PathSeer, ფილტრირებული ვექტორული ძებნის ალგორითმი Tsinghua University-ის სტატიიდან SIGMOD 2026-ზე. ავტორების იმპლემენტაციაში გამტარუნარიანობა ჩვეულებრივ HNSW-ზე 1,2–13,5-ჯერ მაღალია 90%-იანი recall-ისას, ხოლო Weaviate 1.40-ში სტრატეგია არსებულ ინდექსზე გადაირთვება, ხელახალი აგების გარეშე.

რატომ სჭირდება ეს ბიზნესს

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

მეორე კითხვა წარსულს ეხება, „რა იყო მაშინ“: კლიენტი დავობს, რომ მარტში სხვა ფასს დაჰპირდნენ. თუ მიმოწერა, ზარების ჩანაწერები და მენეჯერების შენიშვნები ერთ ბაზაშია, დროითა და ჯავშანთან კავშირით, სიტყვებითა და აზრით ძებნა კლიენტისა და თვის ფილტრით საჭირო ფრაზას წამებში პოულობს. დასკვნა: მთავარი პირობა აქ ბაზაში შენახული ისტორიაა, დროითა და ცხრილებს შორის კავშირებით. ახალი ბაზა ამისთვის საჭირო არ არის.

როგორ არის ეს ჩემთან

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

აშშ-ის PDR-კომპანიაში 2023 წლიდან მონაცემები MariaDB-შია, საკუთარ სერვერზე: ზარები AI-გარჩევით, ლიდები, შეკვეთები, leaderboard-ის 15 მაჩვენებელი ყოველ თანამშრომელზე. კითხვა „რა მოუვა ლიდების ნაკადს მომავალ თვეში“ ამ ბაზას უკვე ახლა შეიძლება დაესვას. Kumo Relational და Granite-ის ანსამბლი არ გამიშვია. 2023 წლიდან დაგროვილ ლიდების ისტორიაზე შევამოწმებდი, წინა წლის მიხედვით აგებულ პროგნოზთან შედარებით. თუ მოგება არ არის, მოდელი საჭირო არ არის.

რას გავაკეთებდი

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

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

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

აგენტის მეხსიერებას, თუ დასჭირდა, ხითა და ფილტრებით დავიწყებდი, როგორც TigerData-ს მესამე მცდელობაში, და აგენტს თავისუფალ SQL-ს არ მივცემდი.

დაკავშირებული მასალები

მოდელის შედეგის შემოწმებაზე: AI მონაცემის დამუშავებაში: ამოღება და შემოწმება. მიდგომა: Python დოკუმენტებისა და მონაცემის განმეორებადი დამუშავებისთვის და ცხრილების ავტომატიზაცია და ბიზნესანგარიშები. ქეისები: ფინანსური პანელი Google Sheets-ში, ლონდონის საკონსულტაციო კომპანია და სერვისული გუნდი და კონვერსიის ზრდა 30%-ით. იმავე თემაზე: სამი გადაწყვეტილება ბაზაში, რომელსაც მერე ნანობენ, AI წყვეტს, ადამიანი ადასტურებს და როგორ ვირჩევ საკუთარ მოდელსა და API-ს შორის. ადრე: ჰიბრიდული ძებნა და ტოკენიზაცია და ცოდნის გრაფი თუ ვექტორული RAG. თუ თქვენი კომპანიის ისტორია უკვე ბაზაშია, მომიყევით, რა კითხვას დაუსვამდით მას პირველად. ამოცანის განხილვა.