શું Postgres તમારી RAG પાઇપલાઇન સંભાળી શકે?

• LLM એક સમયે મર્યાદિત પ્રમાણમાં લખાણ જ “જોઈ” શકે છે (સંદર્ભ વિન્ડો). નાનાં કાર્યો માટે આ સારી રીતે કામ કરે છે, પરંતુ જ્ઞાનભંડાર હજારો પાનાંમાં ફેલાયેલો હોય ત્યારે નિષ્ફળ જાય છે. સંદર્ભ વિન્ડો પૂરતી હોય તો પણ “ઘાસના ઢગલામાં સોય શોધવાની” સમસ્યાને કારણે પ્રદર્શન કથળી શકે છે.

• RAG (‘પુનઃપ્રાપ્તિ-સંવર્ધિત સર્જન’) ખૂબ સામાન્ય પદ્ધતિ બની છે. તેમાં તમે જ્ઞાનભંડાર (દસ્તાવેજો, વિકિ, નીતિઓ, પ્રતિલિપિઓ વગેરે) જાળવો છો, વપરાશકર્તાની ક્વેરી પર અર્થલક્ષી શોધ ચલાવીને એમ્બેડિંગની મદદથી સૌથી સુસંગત અંશો મેળવો છો અને પછી પ્રશ્ન સાથે એ અંશો LLMને આપો છો. આ મોડલનો સંદર્ભ મર્યાદિત કરે છે અને યોગ્ય રીતે કરવામાં આવે તો જવાબોની ગુણવત્તા સુધારીને ભ્રામક જવાબો ઘટાડી શકે છે.

• pgai એક ઓપન સોર્સ Postgres એક્સ્ટેન્શન (અને તેની સહાયક સાધનસામગ્રી) છે, જે વિશ્વસનીય ઓપન સોર્સ ડેટાબેઝ PostgreSQL પર “AI પુનઃપ્રાપ્તિ” કાર્યપ્રવાહ બનાવવામાં મદદ કરે છે.

• મુખ્ય વિચાર એ છે કે એમ્બેડિંગ માટે ડેટાબેઝને “માત્ર સંગ્રહ” માનવાને બદલે પ્રમાણભૂત RAG પાઇપલાઇનનો વધુ ભાગ ડેટાબેઝ સ્તરે ખસેડવો (ગ્રહણ → વિભાજન → એમ્બેડિંગ → એમ્બેડિંગને સમન્વયિત રાખવું).

• પ્રારંભિક તારણ મુજબ આ આશાસ્પદ છે, પરંતુ તમારી RAG પાઇપલાઇન સહેજ પણ જટિલ બને, ખાસ કરીને વિભાજનની રીતોમાં, ત્યારે તે યોગ્ય રહેતું નથી. તેમ છતાં, અમે આ પ્રોજેક્ટ પર નજીકથી નજર રાખીશું.

RAG બનાવવાની ઘણી રીતો છે. વિવિધ RAG અભિગમોની વિગતવાર સમજ માટે અનુકૂલિત RAG ઉકેલોનાં વ્યવહારુ ઉદાહરણો. વાંચો. ગુણવત્તા મહત્ત્વની બનતાં રચનાની શક્યતાઓ આશ્ચર્યજનક રીતે ઊંડી બને છે અને સામાન્ય “મૂળભૂત” અભિગમ મોટેભાગે આવો હોય છે:

1. દસ્તાવેજોનો સમૂહ લો.

2. તેમને અંશોમાં વહેંચો. આ કરવાની ઘણી અલગ રીતો છે (દા.ત. ફકરા, અર્થલક્ષી જૂથીકરણ).

3. દરેક અંશને એમ્બેડિંગમાં ફેરવો.

4. એમ્બેડિંગને વેક્ટર ડેટાબેઝમાં (Pinecone, Milvus વગેરે) અથવા pgvector વડે Postgresમાં સંગ્રહો.

5. ક્વેરી કરતી વખતે સૌથી નજીકના અંશો શોધો `અને તેમને LLMને આપો (ફરીથી...આ કરવાની પણ ઘણી રીતો છે).

ઘણી ટેક્નોલોજી વ્યવસ્થાઓમાં પગલાં (1)–(3) ડેટાબેઝની બહાર, એપ્લિકેશન કોડ અથવા ડેટા પાઇપલાઇનમાં થાય છે અને ડેટાબેઝ મુખ્યત્વે આ માટે વપરાય છે:

• એમ્બેડિંગનો સંગ્રહ

• એમ્બેડિંગની શોધ

pgai એક Postgres એક્સ્ટેન્શન છે (ઓપન સોર્સ, Timescale દ્વારા વિકસિત), જે આ ભેદરેખાને ઝાંખી કરવાનો પ્રયાસ કરે છે.

એમ્બેડિંગને તમારી એપ્લિકેશને જાતે સંચાલિત કરવાની બાબત માનવાને બદલે pgai તેને ડેટાબેઝની સુવિધા બનાવે છે:

• કયા કોષ્ટક અથવા દસ્તાવેજોનું એમ્બેડિંગ કરવું છે તે તમે નક્કી કરો છો.

• તમે એમ્બેડિંગ મોડલ અને વિભાજનની વ્યૂહરચના નક્કી કરો છો.

• તમારા સ્રોત ડેટામાં ફેરફાર થાય ત્યારે એમ્બેડિંગને અદ્યતન રાખવા સહિતનું બાકીનું સંચાલન pgai કરે છે.

તેની સંભાવના આકર્ષક છે:

• જાળવણી કરવી પડે એવો વિશિષ્ટ જોડાણ કોડ ઓછો થાય છે.

• મૂળ સ્રોત દસ્તાવેજો બદલાય ત્યારે એમ્બેડિંગને ‘તાજાં’ રાખવાનું વધુ સરળ બનવું જોઈએ.

• પુનઃપ્રયાસો, દર મર્યાદાઓ, નિષ્ફળ કાર્યો વગેરેનું સંચાલન Postgres/pgai કરે છે.

વાચક માટે નોંધ: pgaiમાં pgvector (RAG માટેનું બીજું અત્યંત લોકપ્રિય Postgres એક્સ્ટેન્શન) સામેલ છે. 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 સમસ્યાનો સૌથી સરળ ભાગ ઉકેલી રહ્યું છે.

ઉપરાંત, તમારું જ્ઞાનભંડાર ભાગ્યે જ અદ્યતન થતું હોય તો એમ્બેડિંગના આપમેળે સમન્વયનું મૂલ્ય એટલું વધારે નથી.

તમારા ડેટાબેઝ પર લખાણ-થી-SQL ઇન્ટરફેસ કાર્યરત કરવું એ pgaiનો ઉપયોગ કરવાની ખાસ સારી રીત હોઈ શકે છે. pgai દ્વારા મળતા semantic_catalog મોડ્યુલથી આ ઘણું સરળતાથી કરી શકાય છે. આ રીતે સરળતાથી ગોઠવો:

1OPENAI_API_KEY="your-OpenAPI-key-goes-here"2TARGET_DB="postgres://user:password@host:port/database"3CATALOG_DB="postgres://user:password@host:port/database"

અને pgai semantic-catalog create વડે અર્થલક્ષી સૂચિને તમારા ડેટા શબ્દકોશોમાંથી માહિતી એકત્ર કરવા દો. આ તમારા ડેટા સંગ્રહમાંથી સંદર્ભ બનાવે છે, જે લગભગ આવો દેખાય છે:

1---2schema: postgres_air3name: aircraft4type: table5description: Lists aircraft models with performance characteristics and unique codes.6columns:7- name: model8  description: Commercial name of the aircraft model.9- name: range10  description: Maximum flight range in kilometers.11- name: class12  description: Airframe class category or configuration indicator.13- name: velocity14  description: Cruising speed of the aircraft.15- name: code16  description: Three-character aircraft code serving as the primary key.17...

આ સંદર્ભ હવે pgaiને વિવિધ રીતે ઉપલબ્ધ છે:

અર્થલક્ષી શોધ દ્વારા:

આ ક્વેરી તમારી સ્વાભાવિક ભાષાની ક્વેરી માટે સુસંગત હોઈ શકે તેવાં કોષ્ટકો, ફંક્શન અને અન્ય ઑબ્જેક્ટ પરત કરશે:

1pgai semantic-catalog search -p "Your natural language question goes here!"

કાચો સંદર્ભ મેળવો:

આ તમારી સ્વાભાવિક ભાષાની ક્વેરી સાથે સંબંધિત કાચો YAML સંદર્ભ રજૂ કરશે:

1pgai semantic-catalog search -p "Your natural language question goes here!" --render

SQL બનાવો:

અથવા તમારી ક્વેરીનો જવાબ આપવા જરૂરી કાચું SQL તમે સીધું બનાવી શકો છો. પાછલા પગલાનો સંદર્ભ LLMને મોકલવામાં આવે છે અને જવાબ બનાવવામાં આવે છે:

1pgai semantic-catalog generate-sql -p "Your natural language question goes here!"

જો તમે પ્રમાણમાં સરળ RAG સિસ્ટમ બનાવી રહ્યા હો, તો આ જરૂરિયાતો માટે pgai અજમાવવા જેવું છે:

• માહિતીના અધિકૃત સ્રોત તરીકે Postgres,

• ન્યૂનતમ જોડાણ કોડ,

• આપમેળે સમન્વયિત રહેતાં એમ્બેડિંગ,

• તમારા ડેટાબેઝ પર લખાણ-થી-SQL ઝડપથી લાગુ કરવાની રીત,

• નવાં RAG સાધનો અને Postgres એક્સ્ટેન્શન અજમાવવા.

તમારી RAG પાઇપલાઇનને નીચેનામાંથી કોઈ બાબતની જરૂર હોય તો pgai માટે રાહ જોવી કદાચ યોગ્ય રહેશે:

• અત્યંત અનુકૂલિત ગ્રહણ અથવા વિભાજન તર્ક

• અલગ વિશ્લેષણ જરૂરિયાતો ધરાવતા ઘણા દસ્તાવેજ પ્રકારો

• બહુમાધ્યમ એમ્બેડિંગ

છેલ્લે, pgvectorનો વ્યાપક સ્વીકાર થયો છે એ સ્પષ્ટ છે, પરંતુ pgaiને પણ એટલો જ રસ અને તેથી સમર્થન મળશે કે નહીં એ અસ્પષ્ટ છે (જોકે તેને આવ્યાને માત્ર લગભગ 18 મહિના થયા છે).

pgai એ RAG માટેનો રસપ્રદ અભિગમ છે, જે ડેટાબેઝને વધુ નિયમિત સંચાલકીય કામ કરવા દે છે જેથી તમારો એપ્લિકેશન કોડ સરળ રહી શકે.

હાલમાં તે:

• સરળ RAG વ્યવસ્થાઓ માટે ઉપયોગી અને ખરેખર અનુકૂળ છે

• વધુ વિશિષ્ટ પાઇપલાઇન માટે પૂરતું સુગમ નથી, ખાસ કરીને બહુમાધ્યમ માટે

તે આશાસ્પદ છે અને તેની પ્રગતિ પર ચોક્કસપણે નજર રાખવા જેવી છે.