რა არის ვექტორული ბაზა — და რატომ სჭირდება AI-ს ის?

ვექტორული ბაზა (vector database) არის მონაცემთა ბაზა, რომელიც შექმნილია ე.წ. embedding-ების — რიცხვთა მიმდევრობების, რომლებითაც AI მოდელი გამოსახავს ტექსტის, სურათის თუ აუდიოს „მნიშვნელობას" — შესანახად და მოსაძებნად ისე, რომ აპლიკაციამ სწრაფად იპოვოს ის ჩანაწერები, რომელთა მნიშვნელობა ყველაზე ახლოსაა მოთხოვნასთან — და არა უბრალოდ ისინი, ვისაც იგივე საკვანძო სიტყვები აქვს.

რატომ არ არის ჩვეულებრივი ბაზა ამისთვის მორგებული

ჩვეულებრივი მონაცემთა ბაზა აგებულია ზუსტი ან ნაწილობრივი დამთხვევისთვის: იპოვე ჩანაწერი, სადაც email = 'x@y.com', ან სათაური შეიცავს კონკრეტულ სიტყვას. ეს კარგად მუშაობს სტრუქტურირებულ მონაცემებზე, მაგრამ ვერ პასუხობს სულ სხვა ტიპის კითხვას: „იპოვე აბზაცი, რომელიც დაახლოებით იმავეს ამბობს, რასაც ეს" ან „იპოვე პროდუქტის ფოტო, რომელიც ამ სურათს ჰგავს". მნიშვნელობა არ არის სტრიქონი, რომლის შედარებაც LIKE-ის მსგავსი ოპერატორით შეიძლება — მისი გამოსახვა სხვაგვარად უწევს.

სწორედ ეს გამოსახვა ხდება embedding-ის საშუალებით. Embedding-ის მოდელი კითხულობს ტექსტის ნაწყვეტს (ან სურათს, ან აუდიოჩანაწერს) და გამოსცემს ვექტორს — ჩვეულებრივ რამდენიმე ასეულიდან რამდენიმე ათას რიცხვამდე — რომელიც მას მაღალგანზომილებიან სივრცეში ერთ წერტილად აქცევს. მოდელი ისეა გაწვრთნილი, რომ მსგავსი მნიშვნელობის შემცველი ჩანაწერები ერთმანეთთან ახლოს აღმოჩნდნენ, ხოლო დაუკავშირებელი — შორს. ორი წინადადება, რომელიც ერთსა და იმავეს სხვადასხვა სიტყვებით გამოხატავს, თითქმის იდენტურ ვექტორს შეიძლება გამოსცემდეს, მიუხედავად იმისა, რომ არცერთი საერთო სიტყვა არ აქვთ.

როგორ მუშაობს ძებნა პრაქტიკაში

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

მოთხოვნის შედარება ყოველ ცალკეულ შენახულ ვექტორთან (უხეში, სრული სკანირება) ზუსტ შედეგს იძლევა, მაგრამ მასშტაბს ვერ უძლებს — მილიონობით ჩანაწერზე ეს ნელი ხდება. ამის ნაცვლად, ვექტორული ბაზები ინდექსს აშენებენ მიახლოებითი უახლოესი მეზობლის (ANN) ალგორითმებით — ყველაზე ხშირად გრაფის სტრუქტურით სახელად HNSW (Hierarchical Navigable Small World) ან კლასტერიზაციის მეთოდით, როგორიცაა IVF (Inverted File Index). ეს მეთოდები სიზუსტის მცირე ნაწილს სანაცვლოდ იღებენ დიდი დაჩქარებისთვის და, ჩვეულებრივ, პასუხს ერთეულ ან ორნიშნა მილიწამებში აბრუნებენ, თუნდაც ათობით მილიონ ვექტორზე. მათი უმეტესობა ასევე უჭერს მხარს „ჰიბრიდულ ძებნას" — ვექტორული მსგავსობის შედეგს აერთიანებს ჩვეულებრივ საკვანძო-სიტყვიან ფილტრთან, რაც საშუალებას იძლევა მოთხოვნა ერთდროულად იყოს სემანტიკურად რელევანტური და შეზღუდული, ვთქვათ, კონკრეტული კატეგორიით ან თარიღით.

რატომ აქვს მნიშვნელობა

ვექტორული ბაზები სწორედ ის ინფრასტრუქტურული რგოლია, რომელიც სემანტიკურ ძებნას აპლიკაციის მასშტაბზე პრაქტიკულს ხდის, და ისინი სტანდარტული საცავია RAG-ის (Retrieval-Augmented Generation) მიღმა — ტექნიკის, რომელიც ჩატბოტს საშუალებას აძლევს, უპასუხოს კითხვებს კომპანიის საკუთარი დოკუმენტების საფუძველზე და არა მხოლოდ იმის, რაც დიდმა ენობრივმა მოდელმა წვრთნისას დაიმახსოვრა. ტიპურ RAG სისტემაში შემომავალი დოკუმენტები იყოფა ნაწყვეტებად, თითოეული ნაწყვეტი embedding-ად გარდაიქმნება და ინახება ვექტორულ ბაზაში, ხოლო მოთხოვნის დროს მომხმარებლის კითხვაც embedding-ად იქცევა და შედარდება ამ შენახულ ნაწყვეტებს, რათა მოდელმა პასუხის დაწერამდე ყველაზე რელევანტური ნაწყვეტები მიიღოს.

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

საიდან დავიწყოთ

დეველოპერებს, რომლებსაც უკვე აქვთ გაშვებული PostgreSQL, შეუძლიათ დაამატონ ვექტორული ძებნა pgvector-ის საშუალებით — უფასო, ღია კოდის გაფართოებით, რომელიც embedding-ებს ინახავს ჩვეულებრივ რელაციურ მონაცემებთან ერთად და ცალკე სისტემას არ საჭიროებს. ის კომფორტულად უმკლავდება რამდენიმე მილიონამდე ვექტორის კოლექციებს საშუალო სიმძლავრის აპარატურაზეც კი. უფრო დიდი ან მოთხოვნადი დატვირთვისთვის, გავრცელებული ალტერნატივებია სრულად მართული სერვისები, როგორიცაა Pinecone, ან სპეციალურად ვექტორული ძებნისთვის აგებული ღია კოდის სისტემები, როგორებიცაა Weaviate და Milvus — არჩევანი, ჩვეულებრივ, ოპერაციული სიმარტივესა (მართული სერვისი) და ხარჯების კონტროლს/საკუთარ ინფრასტრუქტურაზე მართვის მოქნილობას (ღია კოდი) შორის კომპრომისს ნიშნავს.

მართული ვექტორული ბაზები, ჩვეულებრივ, ფასდება საცავისა და მოთხოვნების მოცულობის მიხედვით და არა ფიქსირებული საფასურით ერთ მომხმარებელზე. მაგალითად, Pinecone გთავაზობთ უფასო „Starter" დონეს (2GB საცავამდე და წაკითხვა/ჩაწერის ოპერაციების ყოველთვიური ლიმიტი), ხოლო ფასიანი, მოხმარებაზე დაფუძნებული გეგმები იწყება 20$/თვეში ფიქსირებული „Builder" დონით და „Standard" დონით, რომელიც მინიმუმ 50$/თვეში ღირს — 2026 წლის ივლისის მდგომარეობით, Pinecone-ის ფასების გვერდის მიხედვით. pgvector-ის, Weaviate-ის ან Milvus-ის საკუთარ ინფრასტრუქტურაზე გაშვება ამ გადასახადს მთლიანად აშორებს სანაცვლოდ იმისა, რომ ბაზის მართვა და მასშტაბირება თავად გიწევთ.

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

ვექტორული ბაზა უბრალოდ ჩვეულებრივი ბაზაა, რომელსაც ძებნის ფუნქცია დაუმატეს?
არა. ჩვეულებრივი „სრულტექსტური ძებნაც" კვლავ საკვანძო სიტყვებსა და მათ ვარიაციებს ეყრდნობა. ვექტორული ბაზა კი მნიშვნელობას ადარებს embedding-ებს შორის მანძილის გაზომვით, ამიტომ მას შეუძლია მოთხოვნა დაუკავშიროს ნაწყვეტს, რომელიც იმავე იდეას სრულიად სხვა სიტყვებით გამოხატავს.

საჭიროა თუ არა ცალკე ვექტორული ბაზა, თუ შეიძლება უბრალოდ Postgres-ს ვექტორული სვეტი დავამატო?
რამდენიმე მილიონამდე ვექტორის მქონე უმეტესი აპლიკაციისთვის, გაფართოება, როგორიცაა pgvector, უკვე არსებულ ბაზაში, უფრო მარტივი და იაფია, ვიდრე ახალი სისტემის დამატება. ცალკეული ვექტორული ბაზები თავს იმართლებენ უფრო დიდ მასშტაბზე ან როცა გჭირდებათ ისეთი ფუნქციები, როგორიც არის რეალურ დროში ინდექსის განახლება მილიარდობით ვექტორზე.

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

აქვს თუ არა მნიშვნელობა, რომელ embedding მოდელს ვირჩევთ?
დიახ. ორი სხვადასხვა embedding მოდელის ვექტორები, ჩვეულებრივ, ერთმანეთთან შედარებადი არ არის, ამიტომ ბაზა ერთი კონკრეტული მოდელის გამოსავალ სივრცეზეა აგებული ერთდროულად; მოგვიანებით embedding მოდელის შეცვლა, როგორც წესი, მონაცემების ხელახლა embedding-ად გარდაქმნასა და ხელახლა ინდექსირებას ნიშნავს.