ყოველი RAG სახელმძღვანელო მუშაობს laptop-ზე რამდენიმე ასეული დოკუმენტით, და ის უძალო გრძნობს თავს. შემდეგ მიმართავთ ნამდვილ corpus-ზე — კომპანიის docs, წლების ტიკეტები, ცოდნის ბაზა — და უცებ მეხსიერება მთელი საუბარია.
RAG არ მასშტაბირდება CPU-ით. ის მასშტაბირდება RAM-ით.
რატომ სჭირდება ინდექსს მეხსიერება
Retrieval მუშაობს ტექსტის ყოველი chunk-ის embedding-ად ქცევით — vector, რამდენიმე ასეულიდან ორ ათასამდე რიცხვის სიგრძის. ძებნა ნიშნავს თქვენი query vector-ის შედარებას ყველა მათგანთან, სწრაფად. „სწრაფად“ ოპერაციული სიტყვაა: დაბალი შეყოვნებისთვის ინდექსს RAM-ში ცხოვრება სჭირდება. დისკზე ის მუშაობს, მაგრამ ყოველი query იხდის ჯარიმას, და დაბალ-შეყოვნების retrieval იყო თვით-ჰოსტინგის აზრი თავიდანვე.
ასე რომ მეხსიერების ანგარიში მასშტაბირდება ორი რამით: რამდენი chunk გაქვთ და რამდენად ფართოა ყოველი vector.
ნამდვილი რიცხვები, უხეშად
გაზომეთ თქვენი საკუთარი — dimension და ინდექსის ტიპი ამას ბევრს ცვლის — მაგრამ საწყისი შეგრძნებისთვის:
- რამდენიმე ასეული ათასი embedding — კომფორტული 2–4 GB-ში. პირადი ცოდნის ბაზა, ერთი პროდუქტის docs.
- დაბალი მილიონები — აპლიკაციით, მოდელის client-ითა და OS-ით მის გარშემო, დაგეგმეთ 16–32 GB. ეს სერიოზული კომპანიის ცოდნის ბაზა ან multi-source RAG-ია.
- ათეული მილიონი ან მაღალ-dimension vector-ები — ახლა 48–80 GB-ში ხართ, და ამის მიღმა რამდენიმე box-ზე. დიდი დოკუმენტთა მასივები, multi-tenant retrieval, ან რამდენიმე ინდექსს ერთდროულად თბილად ინახავთ.
მრავალ-აგენტიანი სისტემა, რომელიც ასევე ინახავს დიდ ინდექსს, ორივე ღირებულებას აგროვებს იმავე box-ზე — ასე ხდება 32 GB ტარიფი ჩუმად 64 GB.
engine-ის არჩევანი, მოკლედ
თუ უკვე უშვებთ Postgres-ს, pgvector ყველაზე ნაკლები-ძალისხმევის ვარიანტია — ის გაფართოებაა, არა ახალი სერვისი, რომელსაც ძიძობა სჭირდება. როცა მილიონობით vector გაქვთ და გინდათ სწრაფი ფილტრირებული ძებნა, გამოყოფილი engine, როგორიცაა Qdrant ან Weaviate, იმსახურებს ცალკე პროცესს. ნუ over-engineer გააკეთებთ პირველ დღეს; გაუშვით, რასაც უკვე უშვებთ, და გამოყავით ის, როცა ძებნა რეალურად ნელდება.
რატომ იწვალოთ თვით-ჰოსტინგით
ორი მიზეზი, რის გამოც ხალხი რეალურად აკეთებს ამას, და არცერთი არ არის „რამდენიმე დოლარის დასაზოგად“:
კონფიდენციალურობა. embedding-ები აბსტრაქტული არ არის — ისინი კოდირებენ ტექსტს, საიდანაც მოვიდნენ. თქვენი docs, თქვენი კლიენტების კონტენტი, თქვენი შიდა შენიშვნები, vector-ებად ქცეული და მესამე მხარის სერვერებზე გაგზავნილი. თვით-ჰოსტინგი ინახავს ამას მანქანაზე, რომელსაც აკონტროლებთ. თუ მონაცემი საკმარისად მგრძნობიარეა, რომ ასევე კრიპტოთი იხდით no KYC-ით, managed vector cloud მთელ აზრს აუქმებს.
ფიქსირებული ღირებულება. managed vector სერვისები ახდევინებენ შენახული vector-ებითა და გაშვებული query-ებით. VPS ერთი თვიური რიცხვია და შეგიძლიათ იმდენად ურტყათ, რამდენადაც გინდათ. მასშტაბზე პროგნოზირებადი სჯობს გაზომილს.
რას ნიშნავს ეს ზომისთვის
დაიწყეთ თქვენი corpus-ის გაზომვით, არა გამოცნობით. მიიღეთ თქვენი embedding-ის რაოდენობა და dimension, ჩატვირთეთ ნიმუში, უყურეთ resident მეხსიერებას, ექსტრაპოლირეთ. შემდეგ აირჩიეთ ტარიფი ინდექსისა და ყველაფრის ადგილით მის გარშემო — აპლიკაცია, მოდელის client, ზრდის ადგილი.
ყველაფრისთვის, რაც რამდენიმე მილიონ vector-ს პირადად ინახავს, Pro ხაზი უშვებს 32-დან 80 GB-მდე გამოყოფილი IP-ითა და ღამის სარეზერვო ასლებით, რასაც მნიშვნელობა აქვს, როცა ინდექსი არის პროდუქტი და მისი დაკარგვა გტკივა.
კომენტარები
ჯერ არ არის კომენტარები. იყავით პირველი.