pgvector თუ Qdrant — რომელი ვჰოსტინგო?

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

რამდენი RAM სჭირდება vector მონაცემთა ბაზას?

მეტი, ვიდრე გამოიცნობდით, რადგან კარგ ძებნას სჭირდება ინდექსი მეხსიერებაში. უხეში წესი: რამდენიმე ასეული ათასი embedding კომფორტულად ჯდება 2 GB-ში; როგორც კი დაბალ მილიონებს მიაღწევთ, დაგეგმეთ 4 GB+ და მოარგეთ ინდექსი. დაიწყეთ 2 GB-ზე, უყურეთ მეხსიერებას, resize გააკეთეთ, როცა ძებნა ნელდება.

რატომ ვჰოსტინგო vector store თავად managed-ის ნაცვლად?

ორი მიზეზი, რის გამოც ხალხი რეალურად აკეთებს ამას: თქვენი embedding-ები ხშირად შეიცავენ თქვენს პირად მონაცემებს (შენიშვნები, დოკუმენტები, კლიენტის კონტენტი), და თვით-ჰოსტინგ store ინახავს ამას სერვერზე, რომელსაც აკონტროლებთ. და ის ფიქსირებული-ღირებულებაა — managed vector სერვისი ახდევინებს vector-ებითა და query-ებით, ხოლო VPS ერთი თვიური რიცხვია per-query meter-ის გარეშე.

შეუძლიათ vector DB-სა და ჩემს აგენტს ერთ VPS-ზე მუშაობა?

დიახ, პატარა-საშუალო დატვირთვებისთვის — აგენტისა და pgvector/Qdrant ინსტანსის co-locating ერთ box-ზე მარტივია და ჭრის შეყოვნებას თითქმის-ნულამდე. გამოყავით ისინი ცალკე სერვერებზე მხოლოდ მაშინ, როცა ერთი იწყებს მეორის RAM-ისთვის მოშიმშილებას, რაც კარგი პრობლემაა მოგვიანებით, არა პირველი-დღის საზრუნავი.

იღებენ embedding-ები ბევრ დისკს?

ერთი embedding რამდენიმე კილობაიტია, ასე რომ მილიონი მათგანი რამდენიმე გიგაბაიტია პლუს ინდექსის overhead — მნიშვნელოვანი, მაგრამ არა უზარმაზარი. 25–45 GB დისკი ფარავს არსებით მეხსიერების store-ს უმეტესი აგენტისთვის. RAM, არა დისკი, ჩვეულებრივ პირველი ზღვარია, რომელსაც წააწყდებით.

განათავსეთ vector მონაცემთა ბაზა AI აგენტის მეხსიერებისთვის VPS-ზე

AI აგენტი მეხსიერების გარეშე ჩარჩენილია საკუთარი თავის ხელახლა წარდგენაში ყოველ საუბარზე. გამოსავალი არის vector მონაცემთა ბაზა — ის ინახავს თქვენი დოკუმენტების, შენიშვნების ან წარსული chat-ების embedding-ებს, რომ აგენტმა შეძლოს შესაბამისი ნაწილების გახსენება მოთხოვნისამებრ (ეს არის „R“ RAG-ში). შეგიძლიათ დაიქირაოთ ის როგორც managed სერვისი, ან გაუშვათ ის თავად VPS-ზე და შეინახოთ თქვენი მონაცემები — რომელიც ხშირად თქვენი პირადი მონაცემია — box-ზე, რომელსაც აკონტროლებთ. აი როგორ, და რა ჯდება ის რეალურად RAM-ში.

ორი კარგი ვარიანტი

არაფერი ეგზოტიკური არ გჭირდებათ. ორი გზა ფარავს თითქმის ყველას:

pgvector — Postgres გაფართოება. თუ უკვე უშვებთ Postgres-ს (ან სიხარულით გააკეთებდით), ეს ამატებს vector ძებნას მონაცემთა ბაზას, რომელიც უკვე გაქვთ. ერთი სერვისი, ერთი სარეზერვო ასლი, SQL, რომელიც იცით. ყველაზე ნაკლები-ძალისხმევის დასაწყისი ბევრად.

Qdrant — სპეციალურად-აგებული vector engine. მიწვდით მას, როცა ბევრი vector გაქვთ (დაბალი მილიონები+) ან გინდათ სწრაფი metadata ფილტრაცია და გამოყოფილი API. ის ცალკე სერვისია გასაშვები, მაგრამ ის აგებულია ზუსტად ამ სამუშაოსთვის.

დამწყები აგენტების უმეტესობისთვის pgvector სწორი პირველი პასუხია. გადადით Qdrant-ზე, როცა მას გადააჭარბებთ, არა მანამდე.

RAM რეალობა (ეს არის ნაწილი, რომელსაც ხალხი აქვეითებს)

vector ძებნა სწრაფია რადგან ინდექსი მეხსიერებაში ცხოვრობს — ასე რომ RAM, არა დისკი, თქვენი ნამდვილი შეზღუდვაა. უხეში გზამკვლევი:

რამდენიმე ასეული ათასი embedding — კომფორტული 2 GB-ში.
დაბალი მილიონები — დაგეგმეთ 4 GB+ და მოარგეთ ინდექსი.
დისკი ადვილი ნაწილია: მილიონი embedding მხოლოდ რამდენიმე GB-ია, ასე რომ 25–45 GB ფარავს სერიოზულ store-ს.

ასე რომ ზომა განსაზღვრეთ ინდექსისთვის, არა ფაილისთვის. (იგივე ლოგიკა, რაც ზოგადი ზომის გზამკვლევი — მძიმე რამ არ არის აშკარა, სანამ არ გაზომავთ.)

სწრაფი დაწყება: pgvector

box-ზე Postgres-ით (Docker ყველაზე ადვილია — იგივე შაბლონი, რაც n8n-ის თვით-ჰოსტინგი):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- match your embedding model's dimensions
);

-- after you have data, build an index for fast search:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

თქვენი აგენტი ამატებს content-სა + მის embedding-ს, შემდეგ query-ს აკეთებს ORDER BY embedding <=> $query_embedding LIMIT 5-ით უახლოესი მეხსიერებების ამოსაღებად. ეს არის მთელი მარყუჟი.

გირჩევნიათ Qdrant? ის ერთი Docker კონტეინერია, რომელიც აშკარავებს HTTP/gRPC API-ს; ქმნით collection-ს თქვენი vector ზომით და upsert-ს აკეთებთ point-ებს. იგივე იდეა, გამოყოფილი engine.

შეუძლია მას box-ის გაზიარება აგენტთან?

დიახ — პატარა-საშუალო მეხსიერების store-ებისთვის, გაუშვით vector DB იმავე VPS-ზე, რაც აგენტი. ეს უფრო მარტივია და შეყოვნება ძირითადად ნულია. გამოყავით ისინი ცალკე სერვერებზე მხოლოდ მაშინ, როცა ერთი იწყებს მეორის RAM-იდან გამოძევებას. ეს მოგვიანებითი, კარგ-პრობლემად-სასურველი გადაწყვეტილებაა, არა პირველი-დღის.

გულწრფელი გაფრთხილებები

RAM არის კედელი, და ის მშვიდია. ძებნა რჩება სწრაფი, სანამ ინდექსი აღარ ჯდება მეხსიერებაში, შემდეგ ის უარესდება. უყურეთ მეხსიერებას და resize გააკეთეთ მანამ, სანამ ის დაგკბენთ — ნუ დაელოდებით, სანამ ნელი query-ები გეტყვით.
Embedding-ები token-ებს ჯდება შესაქმნელად. ყოველი დოკუმენტი, რომელსაც embed-ს აკეთებთ, არის API ზარი embedding მოდელზე. store იაფია სახოსტინგოდ; vector-ების გენერაცია არის განმეორებადი ღირებულება — შესაბამისი რას ჯდება რეალურად აგენტის გაშვება-სთვის.
Back up ის. თქვენი აგენტის მეხსიერება არის მონაცემი, როგორც ნებისმიერი სხვა. თუ მას მნიშვნელობა აქვს, snapshot გააკეთეთ.

ამის ფარგლებში, თვით-ჰოსტინგ vector store სუფთა გზაა აგენტისთვის მდგრადი მეხსიერების მისაცემად თქვენი პირადი მონაცემების მესამე მხარისთვის გადაცემის გარეშე. დაიწყეთ pgvector-ით 2 GB box-ზე, თვალი ადევნეთ RAM-ს და გაიზარდეთ Qdrant-ში ან უფრო დიდ ტარიფში მხოლოდ მაშინ, როცა რიცხვები გეტყვით.