LLM-ებს ერთდროულად მხოლოდ შეზღუდული მოცულობის ტექსტის „დანახვა“ შეუძლიათ (კონტექსტური ფანჯარა). ეს მცირე ამოცანებისთვის მუშაობს, თუმცა პრობლემები ჩნდება, როდესაც ცოდნის ბაზა ათასობით გვერდს მოიცავს. მაშინაც კი, როცა კონტექსტური ფანჯარა საკმარისია, წარმადობა შეიძლება მაინც გაუარესდეს „თივის ზვინში ნემსის პოვნის“ პრობლემის გამო.
RAG („მოძიებით გაძლიერებული გენერაცია“) მეტად გავრცელებული მიდგომაა: თქვენ მართავთ ცოდნის ბაზას (დოკუმენტებს, ვიკიებს, პოლიტიკებს, ტრანსკრიპტებს და ა.შ.), მომხმარებლის მოთხოვნაზე სემანტიკური ძიებითა და ემბედინგებით პოულობთ ყველაზე შესაბამის ფრაგმენტებს, შემდეგ კი მათ კითხვასთან ერთად LLM-ს აწვდით. ეს ზღუდავს მოდელის კონტექსტს და, სწორად შესრულების შემთხვევაში, პასუხების ხარისხს აუმჯობესებს და ჰალუცინაციებს ამცირებს.
pgai არის Postgres-ის ღია კოდის გაფართოება (და თანმხლები ხელსაწყოების ნაკრები), რომელიც სანდო ღია კოდის მონაცემთა ბაზა PostgreSQL-ზე „AI-მოძიების“ სამუშაო პროცესების აგებაში გეხმარებათ.
მთავარი იდეაა, სტანდარტული RAG კონვეიერის მეტი ნაწილი მონაცემთა ბაზის დონეზე გადავიდეს (მიღება → ფრაგმენტაცია → ემბედინგის შექმნა → ემბედინგების სინქრონიზაცია), ნაცვლად იმისა, რომ ბაზა ემბედინგების „უბრალო საცავად“ ჩაითვალოს.
პირველი შთაბეჭდილებით, მიდგომა პერსპექტიულია, თუმცა როგორც კი RAG კონვეიერი ოდნავ მაინც რთულდება — განსაკუთრებით ფრაგმენტაციის მეთოდების მხრივ — ის უკვე აღარ გამოდგება. თუმცა ამ პროექტს ყურადღებით დავაკვირდებით.
RAG-ის აგების მრავალი გზა არსებობს. სხვადასხვა მიდგომის უფრო ვრცელი მიმოხილვისთვის წაიკითხეთ მორგებული RAG გადაწყვეტების პრაქტიკული მაგალითები. ხარისხზე ზრუნვისას შესაძლო დიზაინების სივრცე მოულოდნელად ღრმავდება, ხოლო გავრცელებული „ნაგულისხმევი“ მიდგომა, როგორც წესი, ასე გამოიყურება:
აიღეთ დოკუმენტების კრებული.
დაყავით ისინი ფრაგმენტებად. ამის მრავალი მეთოდი არსებობს (მაგ., აბზაცების ან სემანტიკური ჯგუფების მიხედვით).
თითოეული ფრაგმენტისთვის შექმენით ემბედინგი.
ემბედინგები შეინახეთ ვექტორულ მონაცემთა ბაზაში (Pinecone, Milvus და სხვ.) ან Postgres-ში, pgvector-ის გამოყენებით.
მოთხოვნის შესრულებისას მოძებნეთ ყველაზე მსგავსი ფრაგმენტები `და მიაწოდეთ ისინი LLM-ს (აქაც... ამის მრავალი გზა არსებობს).
ბევრ ტექნოლოგიურ სტეკში ეტაპები (1)–(3) მონაცემთა ბაზის გარეთ, აპლიკაციის კოდში ან მონაცემთა კონვეიერში სრულდება, მონაცემთა ბაზა კი ძირითადად გამოიყენება:
ემბედინგების შესანახად
ემბედინგებში საძიებლად
pgai არის Postgres-ის გაფართოება (ღია კოდის, შემუშავებული Timescale-ის მიერ), რომელიც ამ ზღვრის წაშლას ცდილობს.
იმის ნაცვლად, რომ ემბედინგები აპლიკაციამ ხელით მართოს, pgai მათ მონაცემთა ბაზის ფუნქციად აქცევს:
თქვენ განსაზღვრავთ, რომელი ცხრილის ან დოკუმენტებისთვის უნდა შეიქმნას ემბედინგები.
უთითებთ ემბედინგის მოდელსა და ფრაგმენტაციის სტრატეგიას.
დანარჩენს pgai მართავს, მათ შორის ემბედინგების განახლებას საწყისი მონაცემების ცვლილების შესაბამისად.
დაპირება მიმზიდველია:
ნაკლები სპეციალურად დაწერილი დამაკავშირებელი კოდი, რომელსაც მოვლა სჭირდება.
საწყისი დოკუმენტების ცვლილებისას ემბედინგების „სიახლის“ შენარჩუნება უფრო მარტივი უნდა იყოს.
Postgres/pgai მართავს განმეორებით მცდელობებს, სიხშირის ლიმიტებს, წარუმატებელ დავალებებს და სხვ.
შენიშვნა მკითხველისთვის: pgai თავის თავში აერთიანებს pgvector-საც (Postgres-ის კიდევ ერთ ძალიან პოპულარულ RAG გაფართოებას). pgvector Postgres-ს ვექტორების შენახვისა და მსგავსებით ძიების შესაძლებლობას მატებს, ხოლო pgai მასზე დაყრდნობით ავტომატიზებას უკეთებს RAG კონვეიერის ეტაპებს, როგორიცაა ფრაგმენტაცია, ემბედინგების შექმნა და მათი განახლება.
1) მისი ამუშავება მარტივია.
სტანდარტული წარმატებული სცენარი საკმაოდ მარტივია:
ჩამოტვირთეთ Timescale-ის Docker-იმიჯები (მონაცემთა ბაზა + მუშა პროცესი).
მიუთითეთ ემბედინგის პროვაიდერის API გასაღები.
გაუშვით მცირე მოცულობის SQL ვექტორიზატორის განსაზღვრისთვის (ძირითადად: რას შეექმნას ემბედინგი, როგორ დაიყოს ფრაგმენტებად და რომელი მოდელი გამოიყენოს).
ამის შემდეგ pgai ვექტორიზატორის მუშა პროცესს ცალკე უშვებს და ემბედინგებს ასინქრონულად ქმნის (მაგ., ყოველ 5 წუთში ან თქვენთვის სასურველი სიხშირით).
2) მოსახერხებელია მთელი კონვეიერის მონაცემთა ბაზასთან „ახლოს“ შესრულება.
pgai-ს შეუძლია შიგთავსის ცხრილებიდან მიღება, ასევე დოკუმენტების S3-ის მსგავსი წყაროებიდან ჩატვირთვა, შემდეგ კი მათი დამუშავება, ფრაგმენტებად დაყოფა და ემბედინგების შექმნა. მას ასევე შეუძლია სხვადასხვა ტექსტური დოკუმენტის ფორმატის დამუშავება, მათ შორის PDF-ის, Markdown-ის და სხვ.
1) კონტროლის დიდ ნაწილს კარგავთ (RAG-ს კი ზოგჯერ კონტროლი სჭირდება).
მაღალი წარმადობის RAG სისტემებს — თუ მათ პასუხების ხარისხით ვაფასებთ — ხშირად ინდივიდუალურად მორგებული კონვეიერები სჭირდება, მაგალითად:
ფრაგმენტაციის მორგებული წესები (სათაურების, გვერდების, მოსაუბრეთა მონაცვლეობის და სხვ. მიხედვით)
მეტამონაცემების გათვალისწინებით ფრაგმენტაცია (განყოფილებების სათაურების, დროის ნიშნულების, ავტორებისა და დოკუმენტის ტიპის შენარჩუნება)
ემბედინგის განსხვავებული სტრატეგიები დოკუმენტის თითოეული ტიპისთვის
ზემოთ ჩამოთვლილ საკითხებში pgai ნაკლებ მოქნილობას გვთავაზობს.
ამჟამად ფრაგმენტაციის ორი ძირითადი სტრატეგია არსებობს: სიმბოლოებზე დაფუძნებული ტექსტის გამყოფი და მისი რეკურსიული ვარიანტი; ასევე შესაძლებელია ფრაგმენტაციის გამორთვა. ეს ზოგიერთი გამოყენების შემთხვევისთვის შეიძლება საკმარისი იყოს, თუმცა ბევრ საწარმოო RAG სისტემას მეტი მორგება სჭირდება.
შესანიშნავი იქნებოდა, Timescale-ს დაემატებინა ფრაგმენტაციის უფრო დახვეწილი სტრატეგიები, რომლებსაც Chonkie-ის მსგავს ბიბლიოთეკებში ვხვდებით, და ასევე დაეჭირა მხარი ისეთ მოწინავე დიზაინებისთვის, როგორიცაა Anthropic-ის კონტექსტური მოძიება.
2) პირველ რიგში ტექსტისთვისაა და არა მულტიმოდალური მონაცემებისთვის.
ბევრი საინტერესო RAG ამოცანა უკვე მხოლოდ ტექსტს აღარ ეხება:
დიაგრამების შემცველი PDF-ები
ეკრანის ანაბეჭდები / სურათები
აუდიოჩანაწერები
ვიდეოკლიპები
ამ წყაროებიდან „ტექსტის ამოღებაც“ რომ შეგეძლოთ, ეს ნამდვილ მულტიმოდალურ ემბედინგ-კონვეიერს მაინც არ უდრის.
თუ pgai საბოლოოდ მულტიმოდალურ მოდელებს სრულად დაუჭერს მხარს (S3-ში შენახული დიდი სურათების, აუდიოსა და ვიდეოს ჩატვირთვა → ფრაგმენტაცია → ემბედინგის შექმნა, საიმედო სინქრონიზაციით), ეს ძალიან მიმზიდველი იქნება; დღეს კი ის ტექსტური ემბედინგების სამუშაო პროცესია.
3) თუ მხოლოდ ემბედინგები გჭირდებათ, pgai შეიძლება არ დაგჭირდეთ.
თუ მონაცემთა მიღების კონვეიერი უკვე მორგებულია (ან ასეთი უნდა იყოს), მაშინ „ტექსტის ფრაგმენტებისთვის ემბედინგების შექმნა“ RAG-ის ყველაზე რთული ნაწილი არ არის. ასეთ შემთხვევაში pgai პრობლემის ყველაზე მარტივ ნაწილს აგვარებს.
ამასთან, თუ ცოდნის ბაზა იშვიათად ახლდება, ემბედინგების ავტომატური სინქრონიზაციაც ნაკლებად ღირებულია.
pgai-ის გამოყენების ერთ-ერთი განსაკუთრებით კარგი გზა თქვენს მონაცემთა ბაზებზე ტექსტიდან SQL-ის შექმნის ინტერფეისის დანერგვაა. ამის გაკეთება საკმაოდ მარტივად შეიძლება pgai-ის მიერ შემოთავაზებული semantic_catalog მოდულით. უბრალოდ დააყენეთ ასე:
Bash
შემდეგ semantic catalog-ს თქვენი მონაცემთა ლექსიკონები მოაპოვებინეთ ბრძანებით pgai semantic-catalog create. ეს თქვენი მონაცემთა საცავიდან დაახლოებით ასეთი სახის კონტექსტს ქმნის:
Plain Text
ეს კონტექსტი ახლა pgai-სთვის რამდენიმე გზითაა ხელმისაწვდომი;
სემანტიკური ძიებით:
ეს მოთხოვნა დააბრუნებს ცხრილებს, ფუნქციებსა და სხვა ობიექტებს, რომლებიც შეიძლება თქვენს ბუნებრივ ენაზე დაწერილ მოთხოვნას შეესაბამებოდეს:
Bash
დაუმუშავებელი კონტექსტის მიღება:
ეს გამოსახავს თქვენს ბუნებრივ ენაზე დაწერილ მოთხოვნასთან დაკავშირებულ დაუმუშავებელ YAML კონტექსტს:
Bash
SQL-ის გენერირება:
ან შეგიძლიათ პირდაპირ შექმნათ თქვენს მოთხოვნაზე პასუხისთვის საჭირო დაუმუშავებელი SQL. წინა ეტაპზე მიღებული კონტექსტი ეგზავნება LLM-ს, რომელიც პასუხს აგენერირებს:
Bash
თუ შედარებით მარტივ RAG სისტემას ქმნით, pgai-ის გამოცდა ღირს, როცა გსურთ:
Postgres იყოს თქვენი მთავარი მონაცემთა სისტემა,
მინიმალური დამაკავშირებელი კოდი,
ავტომატურად სინქრონიზებული ემბედინგები,
თქვენს მონაცემთა ბაზებზე ტექსტიდან SQL-ის შექმნის სწრაფად გამოყენება,
ახალი RAG ხელსაწყოებისა და Postgres-ის გაფართოებების გამოცდა.
pgai-ის გამოყენებისგან თავის შეკავება, ალბათ, ღირს, თუ თქვენს RAG კონვეიერს რომელიმე შემდეგი რამ სჭირდება:
რთული, ინდივიდუალურად მორგებული მიღების ან ფრაგმენტაციის ლოგიკა
მრავალი ტიპის დოკუმენტი განსხვავებული დამუშავების მოთხოვნებით
მულტიმოდალური ემბედინგები
დაბოლოს, აშკარაა, რომ pgvector ფართოდ გავრცელდა, თუმცა უცნობია, მიიპყრობს თუ არა pgai იმავე დონის ინტერესსა და, შესაბამისად, მხარდაჭერას (მიუხედავად იმისა, რომ ის მხოლოდ დაახლოებით 18 თვეა არსებობს).
pgai RAG-ისადმი საინტერესო მიდგომაა, რომელიც მონაცემთა ბაზებს მეტი რუტინული საოპერაციო სამუშაოს შესრულების საშუალებას აძლევს და აპლიკაციის კოდს ამარტივებს.
ამჟამად ის:
გამოსადეგი და მართლაც მოსახერხებელია მარტივი RAG კონფიგურაციებისთვის
არ არის საკმარისად მოქნილი მეტად მორგებული კონვეიერებისთვის (განსაკუთრებით მულტიმოდალურისთვის)
ის პერსპექტიულია და ნამდვილად ღირს დაკვირვება, თუ როგორ განვითარდება.