Велики језички модели (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 подешава радни процес векторизатора да се извршава као засебан процес и асинхроно генерише угнежђивања (нпр. сваких пет минута или у било ком жељеном ритму).
2) Практично је обавити цео процес „близу“ базе података.
pgai може да увози садржај из табела, али и да учитава документе са места као што је S3, а затим да их рашчлани, подели и угнезди. Подржава и различите формате текстуалних докумената, као што су PDF, Markdown итд.
1) Губите велики део контроле (а RAG понекад захтева контролу).
RAG системи високих перформанси (мерено квалитетом одговора) често захтевају посебно прилагођене процесе, као што су:
прилагођена правила поделе (према насловима, страницама, сменама говорника итд.)
подела која узима у обзир метаподатке (чување наслова одељака, временских ознака, аутора и типа документа)
различите стратегије угнежђивања за сваки тип документа
pgai нуди мање флексибилности за наведене потребе.
Тренутно постоје две главне стратегије поделе: раздвајање текста према броју знакова и рекурзивно раздвајање према броју знакова, као и опција без поделе. То може бити довољно за неке случајеве употребе, али многи продукциони RAG системи захтевају више прилагођавања.
Било би сјајно када би Timescale могао да уврсти неке напредније стратегије поделе какве налазимо у библиотекама попут Chonkie, као и да подржи напредна решења попут контекстуалног претраживања компаније Anthropic.
2) Првенствено за текст, а не за мултимодални садржај.
Многи занимљиви RAG проблеми више нису искључиво текстуални:
PDF документи с дијаграмима
снимци екрана / слике
аудио-снимци
видео-клипови
Чак и ако из тих извора можете да „извучете текст“, то није исто што и прави процес мултимодалног угнежђивања.
Ако pgai на крају омогући потпуну подршку за мултимодалне моделе (учитавање → подела → угнежђивање великих слика, аудио и видео записа у S3, уз поуздану синхронизацију), то би било веома привлачно. Данас је, међутим, то процес за угнежђивање текста.
3) Ако су вам потребна само угнежђивања, pgai вам можда није потребан.
Ако је ваш процес увоза већ прилагођен (или то мора да буде), онда „угнежђивање делова текста“ није најтежи део RAG-а. У том случају pgai решава најлакши део проблема.
Поред тога, ако се база знања ретко ажурира, аутоматска синхронизација угнежђивања има мању вредност.
Један нарочито добар начин употребе pgai-ја био би постављање интерфејса за претварање текста у SQL над вашим базама података. То се може прилично лако постићи помоћу модула semantic_catalog који нуди pgai. Једноставно га подесите овако:
Bash
а затим омогућите семантичком каталогу да прикупи речнике података помоћу команде 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 поставке
недовољно флексибилан за прилагођеније процесе (нарочито мултимодалне)
Обећава и свакако вреди пратити његов даљи развој.