നിങ്ങളുടെ RAG പ്രക്രിയ Postgres-ന് കൈകാര്യം ചെയ്യാനാകുമോ?

• LLM-കൾക്ക് ഒരേസമയം പരിമിതമായ അളവിലുള്ള വാചകം മാത്രമേ “കാണാൻ” കഴിയൂ (സന്ദർഭ പരിധി). ചെറിയ ജോലികൾക്ക് ഇത് ഫലപ്രദമാണെങ്കിലും, വിജ്ഞാനശേഖരം ആയിരക്കണക്കിന് പേജുകളിലായി വ്യാപിക്കുമ്പോൾ പരാജയപ്പെടുന്നു. സന്ദർഭ പരിധി മതിയായാലും, “വൈക്കോൽക്കൂനയിൽ സൂചി തിരയുന്ന” പ്രശ്നം കാരണം പ്രകടനം കുറയാം.

• RAG (‘വീണ്ടെടുക്കൽ സഹായത്തോടെയുള്ള ഉള്ളടക്ക സൃഷ്ടി’) വളരെ സാധാരണമായൊരു മാതൃകയായി മാറിയിട്ടുണ്ട്. ഇതിൽ വിജ്ഞാനശേഖരം (രേഖകൾ, വിക്കികൾ, നയങ്ങൾ, പകർപ്പെഴുത്തുകൾ തുടങ്ങിയവ) പരിപാലിക്കുകയും, ഉപയോക്താവിന്റെ ചോദ്യത്തിൽ അർത്ഥാധിഷ്ഠിത തിരയൽ നടത്തി എംബെഡിങ്ങുകൾ ഉപയോഗിച്ച് ഏറ്റവും പ്രസക്തമായ ഭാഗങ്ങൾ വീണ്ടെടുക്കുകയും, തുടർന്ന് ചോദ്യത്തോടൊപ്പം അവ LLM-ന് നൽകുകയും ചെയ്യുന്നു. ഇത് മോഡലിന്റെ സന്ദർഭം പരിമിതപ്പെടുത്തുന്നു. ശരിയായി നടപ്പാക്കിയാൽ ഉത്തരങ്ങളുടെ നിലവാരം മെച്ചപ്പെടുത്താനും വ്യാജവിവര സൃഷ്ടി കുറയ്ക്കാനും കഴിയും.

• വിശ്വസനീയമായ ഓപ്പൺ സോഴ്‌സ് ഡാറ്റാബേസായ PostgreSQL-ൽ “AI വീണ്ടെടുക്കൽ” പ്രവർത്തനക്രമങ്ങൾ നിർമ്മിക്കാൻ സഹായിക്കുന്ന ഓപ്പൺ സോഴ്‌സ് Postgres വിപുലീകരണവും അനുബന്ധ ഉപകരണങ്ങളുമാണ് pgai.

• എംബെഡിങ്ങുകൾക്കുള്ള “വെറും സംഭരണമായി” ഡാറ്റാബേസിനെ കാണുന്നതിനു പകരം, സാധാരണ RAG പ്രക്രിയയുടെ കൂടുതൽ ഭാഗങ്ങൾ ഡാറ്റാബേസ് തലത്തിലേക്ക് മാറ്റുകയാണ് പ്രധാന ആശയം (ഉൾക്കൊള്ളിക്കുക → ഭാഗങ്ങളാക്കുക → എംബെഡ് ചെയ്യുക → എംബെഡിങ്ങുകൾ സമന്വയത്തിൽ നിലനിർത്തുക).

• ആദ്യ വിലയിരുത്തലിൽ ഇത് പ്രതീക്ഷ നൽകുന്നതാണ്. എന്നാൽ RAG പ്രക്രിയ അൽപ്പമെങ്കിലും സങ്കീർണമാകുമ്പോൾ, പ്രത്യേകിച്ച് ഭാഗങ്ങളാക്കുന്ന രീതികളിൽ, ഇത് അനുയോജ്യമല്ല. എങ്കിലും ഈ പദ്ധതി ഞങ്ങൾ സൂക്ഷ്മമായി നിരീക്ഷിക്കും.

RAG നിർമ്മിക്കാൻ നിരവധി മാർഗങ്ങളുണ്ട്. വിവിധ RAG സമീപനങ്ങളുടെ വിശദമായ അവലോകനത്തിന് ഇഷ്ടാനുസൃത RAG പരിഹാരങ്ങളുടെ പ്രായോഗിക ഉദാഹരണങ്ങൾ. വായിക്കുക. നിലവാരം പ്രധാനമാകുമ്പോൾ രൂപകൽപ്പനാ സാധ്യതകൾ അപ്രതീക്ഷിതമായി സങ്കീർണമാകുന്നു. പൊതുവായ “സ്ഥിരരീതി” സാധാരണയായി ഇങ്ങനെയാണ്:

1. ഒരു കൂട്ടം രേഖകൾ എടുക്കുക.

2. അവയെ ചെറിയ ഭാഗങ്ങളായി വിഭജിക്കുക. ഇതിന് പല രീതികളുണ്ട് (ഉദാ. ഖണ്ഡികകൾ, അർത്ഥാധിഷ്ഠിത കൂട്ടങ്ങൾ).

3. ഓരോ ഭാഗവും എംബെഡിങ്ങാക്കി മാറ്റുക.

4. എംബെഡിങ്ങുകൾ വെക്ടർ ഡാറ്റാബേസിലോ (Pinecone, Milvus തുടങ്ങിയവ) pgvector ഉപയോഗിച്ച് Postgres-ലോ സംഭരിക്കുക.

5. ചോദ്യം ലഭിക്കുമ്പോൾ, ഏറ്റവും അടുത്ത ഭാഗങ്ങൾ തിരഞ്ഞ് `അവ LLM-ന് നൽകുക (ഇതിനും പല മാർഗങ്ങളുണ്ട്).

പല സാങ്കേതിക സംവിധാനങ്ങളിലും (1)–(3) ഘട്ടങ്ങൾ ഡാറ്റാബേസിന് പുറത്തുള്ള ആപ്ലിക്കേഷൻ കോഡിലോ ഡാറ്റാ പ്രക്രിയയിലോ നടക്കുന്നു. ഡാറ്റാബേസ് പ്രധാനമായും ഉപയോഗിക്കുന്നത്:

• എംബെഡിങ്ങുകൾ സംഭരിക്കാൻ

• എംബെഡിങ്ങുകളിൽ തിരയാൻ

ആ വേർതിരിവ് ഇല്ലാതാക്കാൻ ശ്രമിക്കുന്ന ഒരു Postgres വിപുലീകരണമാണ് pgai (ഓപ്പൺ സോഴ്‌സ്, Timescale വികസിപ്പിച്ചത്).

ആപ്ലിക്കേഷൻ നേരിട്ട് നിയന്ത്രിക്കേണ്ട ഒന്നായി എംബെഡിങ്ങുകളെ കാണുന്നതിനു പകരം, pgai അവയെ ഡാറ്റാബേസിന്റെ സവിശേഷതയാക്കുന്നു:

• ഏത് പട്ടികയോ രേഖകളോ എംബെഡ് ചെയ്യണമെന്ന് നിർവചിക്കുന്നു.

• എംബെഡിങ് മോഡലും ഭാഗങ്ങളാക്കാനുള്ള തന്ത്രവും വ്യക്തമാക്കുന്നു.

• ഉറവിട ഡാറ്റ മാറുമ്പോൾ എംബെഡിങ്ങുകൾ പുതുക്കുന്നതുൾപ്പെടെയുള്ള ബാക്കി കാര്യങ്ങൾ pgai നിയന്ത്രിക്കുന്നു.

ഇത് നൽകുന്ന വാഗ്ദാനം ആകർഷകമാണ്:

• പരിപാലിക്കേണ്ട ഇഷ്ടാനുസൃത ബന്ധിപ്പിക്കൽ കോഡ് കുറയും.

• അടിസ്ഥാന ഉറവിടരേഖകൾ മാറുമ്പോൾ എംബെഡിങ്ങുകൾ പുതുമയോടെ നിലനിർത്തുന്നത് എളുപ്പമാകണം.

• വീണ്ടും ശ്രമിക്കൽ, നിരക്ക് പരിധികൾ, പരാജയപ്പെട്ട ജോലികൾ തുടങ്ങിയവ Postgres/pgai നിയന്ത്രിക്കുന്നു.

വായനക്കാർക്കുള്ള കുറിപ്പ്: pgai-യിൽ pgvector-ഉം (വളരെ ജനപ്രിയമായ മറ്റൊരു RAG Postgres വിപുലീകരണം) ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. pgvector, Postgres-ലേക്ക് വെക്ടർ സംഭരണവും സാമ്യതാ തിരയലും ചേർക്കുന്നു. അതിനു മുകളിൽ പ്രവർത്തിക്കുന്ന pgai, ഭാഗങ്ങളാക്കൽ, എംബെഡിങ്, എംബെഡിങ്ങുകൾ പുതുക്കൽ തുടങ്ങിയ RAG ഘട്ടങ്ങൾ യാന്ത്രികമാക്കുന്നു.

1) പ്രവർത്തിപ്പിച്ചുതുടങ്ങുന്നത് ലളിതമാണ്.

എല്ലാം പ്രതീക്ഷിച്ചതുപോലെ നടന്നാൽ പ്രക്രിയ താരതമ്യേന ലളിതമാണ്:

• Timescale ഡോക്കർ ഇമേജുകൾ (ഡാറ്റാബേസ് + വർക്കർ) എടുക്കുക.

• എംബെഡിങ് ദാതാവിന്റെ API കീ നൽകുക.

• വെക്ടറൈസർ പ്രഖ്യാപിക്കാൻ കുറച്ച് SQL പ്രവർത്തിപ്പിക്കുക (അടിസ്ഥാനമായി: എന്ത് എംബെഡ് ചെയ്യണം, എങ്ങനെ ഭാഗങ്ങളാക്കണം, ഏത് മോഡൽ ഉപയോഗിക്കണം എന്നിവ).

തുടർന്ന്, വെക്ടറൈസർ വർക്കർ ഒരു പ്രത്യേക പ്രക്രിയയായി പ്രവർത്തിച്ച് എംബെഡിങ്ങുകൾ അസമകാലികമായി സൃഷ്ടിക്കാൻ pgai ക്രമീകരിക്കുന്നു (ഉദാ. ഓരോ 5 മിനിറ്റിലും അല്ലെങ്കിൽ നിങ്ങൾ ആഗ്രഹിക്കുന്ന ഇടവേളയിൽ).

2) മുഴുവൻ പ്രക്രിയയും ഡാറ്റാബേസിന് “സമീപം” നടത്താനാകുന്നത് നല്ലതാണ്.

pgai-യ്ക്ക് പട്ടികകളിൽനിന്ന് ഉള്ളടക്കം ഉൾക്കൊള്ളാനും S3 പോലുള്ള ഇടങ്ങളിൽനിന്ന് രേഖകൾ ലഭ്യമാക്കി അവ വിശകലനം ചെയ്ത് ഭാഗങ്ങളാക്കി എംബെഡ് ചെയ്യാനും കഴിയും. PDF, Markdown തുടങ്ങിയ വിവിധ ടെക്സ്റ്റ് രേഖാ ഫോർമാറ്റുകളും ഇതിന് കൈകാര്യം ചെയ്യാം.

1) ഏറെ നിയന്ത്രണം നഷ്ടപ്പെടുന്നു (RAG-ന് ചിലപ്പോൾ നിയന്ത്രണം ആവശ്യമാണ്).

ഉത്തരത്തിന്റെ നിലവാരം അടിസ്ഥാനമാക്കി അളക്കുമ്പോൾ, ഉയർന്ന പ്രകടനമുള്ള RAG സംവിധാനങ്ങൾക്ക് പലപ്പോഴും ഇനിപ്പറയുന്നതുപോലുള്ള ഇഷ്ടാനുസൃത പ്രക്രിയകൾ ആവശ്യമാണ്:

• ഇഷ്ടാനുസൃത ഭാഗങ്ങളാക്കൽ നിയമങ്ങൾ (തലക്കെട്ട്, പേജ്, സംസാരിക്കുന്നവരുടെ ഊഴം തുടങ്ങിയവ അനുസരിച്ച്)

• മെറ്റാഡാറ്റ പരിഗണിച്ചുള്ള ഭാഗങ്ങളാക്കൽ (വിഭാഗത്തലക്കെട്ടുകൾ, സമയമുദ്രകൾ, രചയിതാക്കൾ, രേഖയുടെ തരം എന്നിവ നിലനിർത്തുക)

• ഓരോ രേഖാ തരത്തിനും വ്യത്യസ്ത എംബെഡിങ് തന്ത്രങ്ങൾ

മുകളിൽ പറഞ്ഞ കാര്യങ്ങളിൽ pgai നൽകുന്ന വഴക്കം കുറവാണ്.

നിലവിൽ പ്രധാനമായും രണ്ട് ഭാഗങ്ങളാക്കൽ തന്ത്രങ്ങളാണുള്ളത്: അക്ഷരാധിഷ്ഠിത ടെക്സ്റ്റ് സ്പ്ലിറ്ററും ആവർത്തനാത്മക അക്ഷരാധിഷ്ഠിത ടെക്സ്റ്റ് സ്പ്ലിറ്ററും. ഭാഗങ്ങളാക്കാതിരിക്കാനുള്ള സൗകര്യവുമുണ്ട്. ചില ഉപയോഗങ്ങൾക്ക് അതു മതിയാകാം. എന്നാൽ പ്രവർത്തനത്തിലുള്ള പല RAG സംവിധാനങ്ങൾക്കും കൂടുതൽ ഇഷ്ടാനുസൃതമാക്കൽ ആവശ്യമാണ്.

Chonkie പോലുള്ള ലൈബ്രറികളിൽ കാണുന്ന കൂടുതൽ സങ്കീർണമായ ഭാഗങ്ങളാക്കൽ തന്ത്രങ്ങൾ Timescale ഉൾപ്പെടുത്തുകയും Anthropic-ന്റെ സന്ദർഭാധിഷ്ഠിത വീണ്ടെടുക്കൽ പോലുള്ള നൂതന രൂപകൽപ്പനകളെ പിന്തുണയ്ക്കുകയും ചെയ്താൽ അതു മികച്ചതായിരിക്കും.

2) ബഹുമാധ്യമമല്ല, ടെക്സ്റ്റിന് മുൻഗണന.

രസകരമായ പല RAG പ്രശ്നങ്ങളും ഇപ്പോൾ ടെക്സ്റ്റിൽ മാത്രം ഒതുങ്ങുന്നില്ല:

• രേഖാചിത്രങ്ങളുള്ള PDF-കൾ

• സ്ക്രീൻ ചിത്രങ്ങൾ / ചിത്രങ്ങൾ

• ശബ്ദരേഖകൾ

• ദൃശ്യശകലങ്ങൾ

ഈ ഉറവിടങ്ങളിൽനിന്ന് “ടെക്സ്റ്റ് വേർതിരിച്ചെടുക്കാൻ” കഴിഞ്ഞാലും, അത് യഥാർഥ ബഹുമാധ്യമ എംബെഡിങ് പ്രക്രിയയ്ക്ക് തുല്യമല്ല.

S3-ൽ സംഭരിച്ച വലിയ ചിത്രങ്ങൾ, ശബ്ദം, ദൃശ്യങ്ങൾ എന്നിവ ശക്തമായ സമന്വയത്തോടെ ലഭ്യമാക്കാനും ഭാഗങ്ങളാക്കാനും എംബെഡ് ചെയ്യാനും കഴിയുന്ന സമഗ്ര ബഹുമാധ്യമ മോഡലുകൾക്ക് pgai ഭാവിയിൽ പിന്തുണ നൽകിയാൽ അത് ശ്രദ്ധേയമാകും. എന്നാൽ നിലവിൽ ഇതൊരു ടെക്സ്റ്റ് എംബെഡിങ് പ്രവർത്തനക്രമമാണ്.

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 മാസം മാത്രമേ ആയിട്ടുള്ളൂ.

പതിവ് പ്രവർത്തനങ്ങളുടെ കൂടുതൽ ഭാഗം ഡാറ്റാബേസുകൾക്ക് നിർവഹിക്കാനനുവദിച്ച് ആപ്ലിക്കേഷൻ കോഡ് ലളിതമാക്കുന്ന രസകരമായൊരു RAG സമീപനമാണ് pgai.

നിലവിൽ ഇത്:

• ലളിതമായ RAG ക്രമീകരണങ്ങളിൽ ഉപയോഗയോഗ്യവും യഥാർഥത്തിൽ സൗകര്യപ്രദവുമാണ്

• കൂടുതൽ ഇഷ്ടാനുസൃത പ്രക്രിയകൾക്ക്, പ്രത്യേകിച്ച് ബഹുമാധ്യമ സംവിധാനങ്ങൾക്ക്, വേണ്ടത്ര വഴക്കമുള്ളതല്ല

ഇത് പ്രതീക്ഷ നൽകുന്നു. എങ്ങനെ പുരോഗമിക്കുന്നുവെന്ന് തീർച്ചയായും നിരീക്ഷിക്കേണ്ടതാണ്.