RAG vs. LLM: സാങ്കേതിക വിശകലനം (നിർവചനങ്ങൾ, വ്യത്യാസങ്ങൾ, use cases)

LLM-കൾ അവരുടെ training data-യിലെ pattern-ുകളിൽ നിന്ന് പഠിച്ച parameters ഉപയോഗിച്ച് പ്രതികരണങ്ങൾ സൃഷ്ടിക്കുന്നു. ആ parameters പുതുതായോ സമ്പൂർണമോ ആയ വിവരങ്ങളെ പ്രതിഫലിപ്പിക്കണമെന്നില്ലാത്തതിനാൽ, retrieval-augmented generation എന്ന് വിളിക്കുന്ന RAG, external sources-ൽ നിന്നുള്ള ഡാറ്റ LLM-ന്റെ input context-ലേക്ക് ചേർത്ത് ഈ പ്രക്രിയയെ പൂർത്തിയാക്കുന്നു. ഒരു AI tool പുറംവിവരങ്ങൾ retrieves ചെയ്ത് LLM-ന്റെ generation പ്രക്രിയയെ augment ചെയ്യുന്നു.

യാഥാർത്ഥ്യത്തിൽ, നിങ്ങളുടെ തെരഞ്ഞെടുപ്പ് RAG അല്ലെങ്കിൽ ഒരു LLM എന്നതിനു ഇടയിൽ അല്ല. അത് ഒരു hybrid സമീപനത്തിനും LLM മാത്രം ഉപയോഗിക്കുന്ന സമീപനത്തിനും ഇടയിലാണ്.

LLM-യ്ക്ക് company documentation, databases, അല്ലെങ്കിൽ വേഗത്തിൽ മാറുന്ന വിവരങ്ങളിലേക്കുള്ള പ്രവേശനം ആവശ്യമുള്ളപ്പോൾ RAG ആവശ്യമാണ്. എല്ലാ inputs-ഉം ഉപയോക്താവ് നൽകാൻ കഴിയുന്ന ചില administrative, data processing, content creation ജോലികൾക്കായി LLM-only സമീപനം അനുയോജ്യമാണ്.

RAG vs. LLM: പ്രധാന വ്യത്യാസങ്ങൾ എന്തൊക്കെയാണ്?

• RAG ഉം LLM-കളും പരസ്പരം പൂരകമായ സംവിധാനങ്ങളാണ്. RAG ഇല്ലാതെ ഒരു AI model ഉപയോഗിക്കാം (അത് തന്റെ നിലവിലുള്ള parameters-ലേയ്ക്ക് മാത്രം ആശ്രയിക്കുന്നിടത്ത്), എന്നാൽ ഒരു model ഇല്ലാതെ RAG system ഉപയോഗിക്കാൻ കഴിയില്ല.
• LLM-കളിലെ മൂന്ന് പ്രധാന പ്രശ്നങ്ങൾ മറികടക്കാനാണ് RAG അവതരിപ്പിക്കപ്പെട്ടത്: പഴകിയ വിവരം, hallucinated responses, മൂന്നാംകക്ഷി ഉറവിടങ്ങളോട് താരതമ്യം ചെയ്ത് verification ഇല്ലായ്മ.
• വെരിഫൈ ചെയ്ത ആഭ്യന്തര ഡോക്യുമെന്റേഷൻ, ഡാറ്റാബേസുകൾ, API endpoints എന്നിവയുമായി LLM-കളെ ബന്ധിപ്പിക്കുന്നതിനാൽ, യഥാർത്ഥ ബിസിനസ് സാഹചര്യങ്ങളിൽ AI-യെ RAG വളരെ കൂടുതൽ ഫലപ്രദമാക്കുന്നു.
• മുൻനിര RAG use cases-ൽ customer support chatbots, വേഗത്തിൽ മാറുന്ന ഡാറ്റയെ അടിസ്ഥാനമാക്കിയ queries (industry news പോലുള്ളവ), കൂടാതെ കൃത്യതയും ഉറവിട fact-checking-ഉം പ്രധാനപ്പെട്ട medicine, law പോലുള്ള പ്രത്യേക മേഖലകൾ എന്നിവ ഉൾപ്പെടുന്നു.
• RAG-യുടെ മൂന്ന് പ്രധാന തരങ്ങൾ ഇവയാണ്: naive RAG, modular RAG, advanced RAG. Naive RAG എന്നത് നേരിട്ടുള്ള വിവരതിരച്ചിലായി ഏറ്റവും നന്നായി മനസ്സിലാക്കാം, അതേസമയം modular ഒപ്പം advanced RAG query rewriting, chunk optimization പോലുള്ള അധിക പ്രവർത്തനങ്ങൾ ചേർക്കുന്നു.

Large language model (LLM) എന്താണ്?

LLM, അഥവാ large language model, fine-tuned parameters ഉപയോഗിച്ച് ഉള്ളടക്കം സൃഷ്ടിക്കുന്ന ഒരു സംവിധാനമാണ്. ഈ parameters LLM vocabulary-യിലെ എല്ലാ ടോക്കണുകൾക്കും നൽകിയിരിക്കുന്ന സാധ്യതകൾ നിർണ്ണയിക്കുന്നു, നൽകിയിരിക്കുന്ന sequence-ൽ അടുത്തതായി ഏത് token വരാൻ സാധ്യത കൂടുതലാണെന്ന് സൂചിപ്പിക്കുന്നു.

RAG എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത് (അതും LLM-കളിൽ നിന്ന് എങ്ങനെ വ്യത്യാസപ്പെടുന്നു) എന്ന് കൂടുതൽ നന്നായി മനസ്സിലാക്കാൻ, generative AI അടിസ്ഥാനതലത്തിൽ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് നോക്കുന്നത് സഹായകരമാണ്:

1. Tokenization: ഒരു ഉപയോക്താവിന്റെ prompt ടോക്കണുകളായി വിഭജിക്കപ്പെടുന്നു; അവ വാക്കുകളോ, വാക്കുകളുടെ ഭാഗങ്ങളോ, അല്ലെങ്കിൽ ഒറ്റ അക്ഷരങ്ങളോ ആയിരിക്കാം.
2. Embedding: ടോക്കണുകൾ embeddings-ആയി പരിവർത്തനം ചെയ്യപ്പെടുന്നു, ന്യൂമറിക്കൽ പ്രതിനിധാനങ്ങൾ (സംഖ്യകളുടെ നിരകൾ) ആയ vectors എന്ന് വിളിക്കുന്നത്, decoder ഉൾപ്പെടുന്ന neural network-ക്ക് പ്രോസസ്സ് ചെയ്യാൻ കഴിയുന്നതാണ്.
3. Decoding: decoder-ന്റെ ലെയറുകൾ (LLM-ന്റെ neural network-ന്റെ വലിയൊരു ഭാഗം രൂപപ്പെടുത്തുന്നവ) ഈ വെക്റ്ററുകൾ കൈകാര്യം ചെയ്യുന്നു, അർത്ഥം പിടികൂടാൻ attention എന്ന പ്രക്രിയ ഉപയോഗിച്ച്. ഈ പ്രക്രിയ sequence-ലെ മറ്റ് ടോക്കണുകളോട് ഓരോ ടോക്കണും എത്ര ശക്തമായി ബന്ധപ്പെട്ടിരിക്കണം എന്ന് നിർണ്ണയിക്കുന്നു.
4. Scoring: മോഡൽ തന്റെ മുൻകൂട്ടി നിലവിലിരിക്കുന്ന vocabulary-യിലെ ഓരോ ടോക്കണിനും അനുയോജ്യതാ സാധ്യത നല്കുകയും sequence-യ്ക്ക് സാധ്യതയുള്ള അടുത്ത token തിരഞ്ഞെടുക്കുകയും ചെയ്യുന്നു.

പ്രധാനപ്പെട്ട കാര്യം, ഒരു LLM-ക്ക് തന്റെ നിലവിലുള്ള parameters-നും context window-യിലെ tokens-നും അടിസ്ഥാനമാക്കി മാത്രം output-ുകൾ സൃഷ്ടിക്കാൻ കഴിയും. പരിശീലനത്തിനിടെ, ഒരു LLM-നെ അപൂർണ്ണമായ ടെക്സ്റ്റിന്റെ ഭാഗങ്ങൾ പൂർത്തിയാക്കാൻ കോടിക്കണക്കിന് തവണ പ്രോത്സാഹിപ്പിക്കുന്നു, കൂടാതെ tokens-ലേക്കുള്ള സാധ്യതകൾ (അങ്ങനെ ടെക്സ്റ്റ് പൂർത്തിയാക്കൽ) വിശ്വസനീയമായി നൽകുന്നതുവരെ അതിന്റെ parameters ക്രമീകരിക്കപ്പെടുന്നു.

ഉദാഹരണത്തിന്, നിങ്ങൾ ഒരു AI model-നോട് “ഞങ്ങളുടെ കമ്പനിയുടെ 2026 refund policy എന്താണ് പറയുന്നത്?” എന്ന് ചോദിക്കുന്നതായി കരുതുക. നിങ്ങളുടെ support documentation ഉപയോഗിച്ച് fine-tune ചെയ്യപ്പെടാത്തതിനാൽ, നിലവിലുള്ള parameters അടിസ്ഥാനമാക്കി അടുത്ത tokens മാത്രമേ LLM പ്രവചിക്കാൻ കഴിയൂ. അധിക കോൺടെക്സ്റ്റൊന്നുമില്ലാതെ ഈ ചോദ്യം നിങ്ങൾ ചോദിച്ചാൽ, അത് അർത്ഥവത്തായ രീതിയിൽ പ്രതികരിക്കാൻ കഴിയാതെ പോകുകയോ തെറ്റായ മറുപടി hallucinate ചെയ്യുകയോ ചെയ്യും.

Retrieval-augmented generation (RAG) എന്താണ്?

RAG (retrieval-augmented generation) എന്നത് external systems-ിൽ നിന്നുള്ള വിവരങ്ങൾ ഒരു LLM prompt-ലിൽ ഉൾപ്പെടുത്തുന്ന പ്രക്രിയയാണ്.

അടിസ്ഥാന LLM പ്രക്രിയ, embedding ഉം probabilistic token matching ഉം ഉൾപ്പെടുന്ന, അതേപോലെയാണ് തുടരുന്നത്. RAG ഒരു പ്രാരംഭ ഘട്ടം അവതരിപ്പിക്കുന്നു, അതിൽ ഉപയോക്താവിന്റെ prompt അധിക ഡാറ്റ ഉപയോഗിച്ച് വിപുലീകരിക്കപ്പെടുന്നു.

RAG എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനൊരു അവലോകനം ഇതാ:

1. Knowledge preparation: ഒരു knowledge source തയ്യാറാക്കപ്പെടുന്നു. ഇത് ഒരു കൂട്ടം documents, ഒരു vector database, ഒരു knowledge graph, അല്ലെങ്കിൽ ഒരു live index (AI search-നായി പോലുള്ളത്) ആയിരിക്കാം.
2. Prompting: ഒരു ഉപയോക്താവ് "Should I go for a walk in London today?" പോലെയുള്ള ഒരു prompt നൽകുന്നു.
3. Retrieval: പുറമേയുള്ള വിവരസ്രോതസ് AI tool-ന്റെ retriever വഴി query ചെയ്യപ്പെടുന്നു. ഇത് prompt-നെ embed ചെയ്ത്, അതിനെ ഒരു vector ആക്കി മാറ്റി, തുടർന്ന് vector database query ചെയ്യാം. അല്ലെങ്കിൽ, API call, keyword matching, അല്ലെങ്കിൽ knowledge graph traversal പോലുള്ള മറ്റൊരു രീതിയും ഉപയോഗിക്കാം.
4. Insertion: ഈ വിവരങ്ങൾ ഉപയോക്താവിന്റെ യഥാർത്ഥ prompt-ലേക്ക് ചേർക്കപ്പെടുന്നു. ലണ്ടനിൽ നടക്കലിനെക്കുറിച്ചുള്ള ചോദ്യത്തിന്റെ ഉദാഹരണത്തിൽ, ഇതിൽ ലണ്ടനിലെ കാലാവസ്ഥ വിവരങ്ങളും ജനപ്രിയ നടപ്പാതകളുടെ നിലവിലെ പ്രാപ്യതയും ഉൾപ്പെടാം.
5. Answer generation: LLM വിപുലീകരിച്ച prompt ഉപയോഗിച്ച് സാധാരണ രീതിയിൽ ഒരു പ്രതികരണം സൃഷ്ടിക്കുന്നു.

അകത്തളത്തിൽ, തിരിച്ചെടുക്കുന്ന ടെക്സ്റ്റ് ഇൻപുട്ട് കോൺടെക്സ്റ്റിൽ ചേർക്കപ്പെടുകയും, ടോക്കണൈസ് ചെയ്യപ്പെടുകയും, എംബെഡ് ചെയ്യപ്പെടുകയും ചെയ്യുന്നു. തുടർന്ന് മോഡൽ ആ അധിക കോൺടെക്സ്റ്റ് തന്റെ decoder മുഖേന പ്രോസസ്സ് ചെയ്യുന്നു, അതുവഴി ഔട്ട്‌പുട്ട് ടോക്കൺ സാധ്യതകൾ മാറ്റപ്പെടുന്നു.

വ്യാപകമായി പറഞ്ഞാൽ, RAG-നെ മൂന്ന് ഉപതരങ്ങളായി വിഭജിക്കാം. Naive RAG അടിസ്ഥാന RAG പ്രക്രിയ പിന്തുടർന്ന്, വിവരങ്ങൾ തിരിച്ചെടുത്ത് prompt-ലേക്ക് നൽകുന്നു. Advanced RAG query rewriting, multiple query passes പോലുള്ള അധിക പ്രവർത്തനങ്ങൾ ചേർക്കുന്നു. Modular RAG എന്നത് വിവിധ advanced functionalities-നെ ഘടകങ്ങളായി പരിഗണിച്ച് ആവശ്യാനുസരണം സംയോജിപ്പിക്കാവുന്ന ഒരു architecture തരത്തെ സൂചിപ്പിക്കുന്നു.

RAG vs. LLM: use cases-ന്റെ അവലോകനം

RAG ഉപയോക്താക്കൾക്ക് പുതുക്കിയ ഡാറ്റയിലേക്കുള്ള പ്രവേശനം നൽകുന്നു. ഇതിന്റെ ഫലമായി, hallucinations ഉം വിവരക്കുറവുകളും സംഭവിക്കാൻ സാധ്യത കുറവുള്ള LLM ഔട്ട്‌പുട്ടുകൾ ലഭിക്കുന്നു. ഔട്ട്‌പുട്ടിൽ ഉപയോഗിച്ച വിവരങ്ങളുടെ ഉറവിടങ്ങൾ നിങ്ങൾക്ക് കാണേണ്ടതുണ്ടെങ്കിൽ, RAG അനിവാര്യമാണ്; കാരണം grounded അല്ലാത്ത LLM ഉത്തരങ്ങൾക്കൊപ്പം attributionകൾ ലഭിക്കില്ല.

വലുതാക്കുക

RAG ഉപയോഗ കേസുകൾ

• സമയ-സെൻസിറ്റീവ് വിവര അഭ്യർത്ഥനകൾ: വേഗത്തിൽ പഴകിപ്പോകുന്ന വിവരങ്ങളുമായി ബന്ധപ്പെട്ട ഏത് queries-യും, weather forecast പോലുള്ള അത്ര ലളിതമായ ഒന്നായാലും, വളർന്നുവരുന്ന ഒരു news story-യുടെ വിശദമായ വിശകലനം പോലുള്ള സങ്കീർണ്ണമായ ഒന്നായാലും, സാധൂകരിച്ച മൂന്നാംകക്ഷി ഉറവിടങ്ങളെ അടിസ്ഥാനമാക്കിയിരിക്കണം.
• Company documentation: ഉപയോക്താക്കൾ കമ്പനി അല്ലെങ്കിൽ ഉൽപ്പന്ന ഡോക്യുമെന്റേഷനുമായി ബന്ധപ്പെട്ട ചോദ്യങ്ങൾ ചോദിക്കുന്ന ആഭ്യന്തരമോ customer-facing ആയോ AI chatbots RAG-enabled ആയിരിക്കണം, പ്രത്യേകിച്ച് ഡോക്യുമെന്റേഷൻ പലപ്പോഴും പുതുക്കപ്പെടുന്നുണ്ടെങ്കിൽ.
• Customer support: കൃത്യമായ മറുപടികൾ നൽകുന്നതിനായി customer chatbots-ന് നിലവിലെതും വിശദവുമായ support documentation-ലേക്കുള്ള പ്രവേശനം ആവശ്യമുണ്ട്.
• Specialized fields (medicine, law, finance, etc.): domain-specific corpora-യിൽ പരിശീലനം ലഭിക്കാത്ത LLM-കൾക്ക് (പ്രത്യേകിച്ച് mainstream models) specialized prompts-ന്റെ സൂക്ഷ്മതകൾ സാധാരണയായി കൈകാര്യം ചെയ്യാൻ ബുദ്ധിമുട്ടാണ്.

LLM use cases

• Administrative tasks: കുറഞ്ഞ latency-യിൽ LLM-കൾ അടിസ്ഥാന ജോലികൾ പൂർത്തിയാക്കാൻ കഴിയും. സ്പെൽ-ചെക്കിംഗ് അല്ലെങ്കിൽ summarization പോലുള്ള, ബാഹ്യ വിവരങ്ങൾ ആവശ്യമായിട്ടില്ലാത്ത അടിസ്ഥാന എഴുത്തും admin ജോലികളുംക്കായി RAG അനാവശ്യമാണ്.
• Creative tasks: ഒരു ചെറുകഥയോ ഒരു ചിത്രമോ സൃഷ്ടിക്കുന്നതുപോലുള്ള ചില സൃഷ്ടിപരമായ ജോലികൾക്ക്, ആദ്യം നൽകിയ prompt-ിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്ന വിവരങ്ങൾ മാത്രം മതിയാകും.
• റീസണിംഗ് and data-based tasks: നിങ്ങൾ ഒരു വലിയ dataset-ുമായി പ്രവർത്തിക്കുന്നുവെങ്കിൽ, റീസണിംഗ്, വിശകലനം പ്രവർത്തനങ്ങൾ പ്രയോഗിക്കാൻ ഒരു LLM-യ്ക്ക് ബാഹ്യ വിവരങ്ങളിലേക്കുള്ള പ്രവേശനം ആവശ്യമില്ല.
• General coding: ഒരു coding വർക്ക്ഫ്ലോയ്ക്ക് സ്വകാര്യ codebase അല്ലെങ്കിൽ documentation-ലേക്കുള്ള പ്രവേശനം ആവശ്യമാകാമെങ്കിലും, LLM-കൾ bug fix ചെയ്യൽ, functions സൃഷ്ടിക്കൽ പോലുള്ള പൊതുവായ coding ജോലികൾ external sources-നെ ആശ്രയിക്കാതെ തന്നെ വളരെ നന്നായി നിർവഹിക്കാൻ കഴിവുള്ളവയാണ്.

RAG vs. long-context LLM, agentic AI, grounding

RAG ഉം LLM-കളും തമ്മിലുള്ള വ്യത്യാസത്തിന് പ്രസക്തമായ മൂന്ന് ബന്ധപ്പെട്ട ആശയങ്ങളുണ്ട്. അവയാണ് long-context LLM-കൾ, agentic AI, grounding.

Long-context LLM-കൾക്ക് ചിലപ്പോൾ RAG-enabled systems-ന്റെ പകരം ഉപയോഗിക്കാം, അതേസമയം agentic AI ഉം grounding ഉം അവയുമായി സമാനമായോ അവയ്‌ക്കൊപ്പം പ്രവർത്തിക്കുന്നതോ ആണ്.

Long-context LLM-കൾ

ഇവ വലിയ context windows ഉള്ള models ആണ്, ചില വ്യാപകമായി ലഭ്യമായ commercial models ഒരു million tokens വരെ പ്രവർത്തിക്കുന്നു.

ബന്ധപ്പെട്ട മെറ്റീരിയൽ ഒരു model-ന്റെ context window-ലേക്ക് ഫിറ്റ് ചെയ്യുകയും text format-ൽ ലഭ്യമായിരിക്കുകയുമാണെങ്കിൽ, LLM-only സമീപനം ഉപയോഗിക്കുന്നതിന് ചില ഗുണങ്ങൾ ഉണ്ട്. ഇത് retrieval പിശകുകളുടെ സാധ്യത കുറയ്ക്കാനും, കൂടുതൽ സമഗ്രമായ കോൺടെക്സ്റ്റ് നൽകാനും, വ്യാപകമായ RAG architecture setup-ന്റെ ആവശ്യം ഒഴിവാക്കാനും സഹായിക്കും.

Agentic AI

ഒരു ഏജന്റ് എന്നത് RAG കഴിവുകൾ ഉൾപ്പെടെ പല ഉപകരണങ്ങളെയും ആശ്രയിച്ച് സങ്കീർണ്ണ ജോലികൾ നിർവഹിക്കുന്ന ഒരു സംവിധാനമാണ്. RAG agentic AI-യുടെ ഒരു ഘടകമാണ്, കൂടാതെ ഒരു prompt-ന്റെ ഉള്ളടക്കത്തെ ആശ്രയിച്ച് ഒരു ഏജന്റ് പലപ്പോഴും വ്യത്യസ്ത retrieval രീതികൾ (ഉദാ., web search vs. vector search) ഉപയോഗിക്കും.

Grounding

Grounding എന്നത് തെളിവുകളെയോ ഡാറ്റയെയോ ഉപയോഗിച്ച് ഒരു LLM-ന്റെ പ്രതികരണത്തിന്റെ കൃത്യത മെച്ചപ്പെടുത്തുന്ന, അല്ലെങ്കിൽ അതിനെ ground ചെയ്യുന്ന, വിശാലമായ പ്രക്രിയയെ സൂചിപ്പിക്കുന്നു. RAG grounding-ന്റെ ഒരു രൂപമാണ്, എന്നാൽ ഒരു technical document context window-ലേക്ക് ചേർക്കുന്നതും grounding ആകുന്നു.

RAG vs. LLM: യഥാർത്ഥ ലോക ഉദാഹരണങ്ങൾ

RAG ഇല്ലാതെ LLM ഉപയോഗിക്കുന്നതുമായി താരതമ്യം ചെയ്യുമ്പോൾ RAG എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് കൂടുതൽ നന്നായി മനസ്സിലാക്കാൻ, Perplexity ഉപയോഗിച്ചുള്ള ഒരു ലളിതമായ യഥാർത്ഥ ലോക ഉദാഹരണവും vector database പരിശോധിക്കുന്ന hypothetical enterprise കേസും നോക്കാം.

സാധാരണ prompt ഉപയോഗിച്ചുള്ള RAG vs. LLM

Perplexity-യോട് "Should I go for a walk in London today?” എന്ന് ചോദിക്കുമ്പോൾ AI web search (RAG-ന്റെ ഒരു രൂപം) ഓഫാക്കിയ നിലയിൽ ലഭിക്കുന്ന ഔട്ട്‌പുട്ട് ഇതാ (രണ്ട് വാക്യങ്ങളിലേക്ക് പരിമിതപ്പെടുത്തിയിരിക്കുന്നത്):

അതെ—കാലാവസ്ഥ താരതമ്യേന വരണ്ടതാണെന്നും നിങ്ങൾക്ക് സമയം ഉണ്ടെന്നുമെങ്കിൽ, ഇന്ന് ലണ്ടനിൽ ഒരു നടക്കൽ ദൃശ്യപശ്ചാത്തലത്തിൽ ഒരു പുതുമയാകാം. South Bank, Regent’s Canal, അല്ലെങ്കിൽ Hyde Park വഴിയുള്ള ഒരു മാർഗം തിരഞ്ഞെടുക്കുക, ആവശ്യത്തിന് ഒരു ലഘു waterproof കൂടെ കൊണ്ടുപോകുക.

LLM ബാഹ്യ ഉറവിടങ്ങൾ പരിശോധിക്കാനാകുന്നപ്പോൾ ലഭിക്കുന്ന prompt ഇതുമായി താരതമ്യം ചെയ്യുക:

അതെ, ലണ്ടനിൽ ഒരു നടക്കലിന് ഇന്ന് നല്ല ദിവസം തന്നെയാണ്: പ്രവചനം 19–21°C വരെയുള്ള മിതമായ താപനിലയും സൂര്യപ്രകാശ ഇടവേളകളും മഴയ്ക്ക് വളരെ കുറഞ്ഞ സാധ്യതയുമാണ് സൂചിപ്പിക്കുന്നത്. ഭാഗികമായി മേഘാവൃതമായ ആകാശവും നേരിയ കാറ്റും ഉള്ളതിനാൽ, പാർക്കുകൾ അല്ലെങ്കിൽ South Bank പോലുള്ള നദീതീര മാർഗങ്ങൾ അന്വേഷിക്കാൻ സാഹചര്യങ്ങൾ സുഖകരമാണ്.

ഈ രണ്ട് ഉദാഹരണങ്ങൾക്കിടയിൽ സാമ്യങ്ങൾ ഉണ്ട്, കാരണം LLM അതേ അടിസ്ഥാന token scoring പ്രക്രിയയാണ് ഉപയോഗിക്കുന്നത്. എന്നാൽ, രണ്ടാമത്തെ ഉദാഹരണത്തിൽ വിശദമായ കാലാവസ്ഥ വിവരങ്ങൾ ഉൾപ്പെടുത്തിയിരിക്കുന്നു, ഇത് അതിനെ വളരെ കൂടുതൽ ഉപയോഗപ്രദമാക്കുന്നു.

Enterprise vector database-യോടുകൂടിയ RAG vs. LLM

ഒരു ഉപയോക്താവ് ബാങ്കിംഗ് ആപ്പിന്റെ in-app chatbot-നോട് ഇങ്ങനെ ചോദിക്കുന്നു എന്ന് ചിന്തിക്കുക: “എന്റെ ഏറ്റവും പുതിയ statement എവിടെ നിന്ന് ഡൗൺലോഡ് ചെയ്യാം?”

ആപ്പ് നിയന്ത്രിക്കുന്ന ബാങ്ക്, അതിന്റെ പുതുക്കിയ ഉൽപ്പന്ന ഡോക്യുമെന്റേഷന്റെ embeddings അടങ്ങിയ ഒരു database സൃഷ്ടിച്ച് അത് chatbot-ന്റെ RAG pipeline-ലേക്ക് ബന്ധിപ്പിച്ചിരിക്കുന്നു. ഡോക്യുമെന്റേഷൻ ഏകദേശം 1,000 source documents-കളിൽ നിന്നാണ് രൂപപ്പെട്ടിരിക്കുന്നത്, അവ ചെറിയ chunks-കളായി വിഭജിച്ച് retrieval-നായി vectors-ആയി പരിവർത്തനം ചെയ്തിരിക്കുന്നു.

ഉപയോക്താവിന്റെ query ഒരു embedding model-ലേക്ക് അയക്കപ്പെടുന്നു, തുടർന്ന് application ആ vector database-ലേക്ക് അയയ്ക്കുന്നു, അത് ബന്ധപ്പെട്ട chunks തിരികെ നൽകുന്നു.

Embedding model-ന് ഇങ്ങനെ ഒരു അഭ്യർത്ഥന ലഭിക്കും:

Embedding model താഴെ കാണുന്ന vector embedding തിരികെ നൽകുന്നു:

തുടർന്ന് vector database-ന് ഇങ്ങനെ ഒരു അഭ്യർത്ഥന ലഭിക്കുന്നു:

ഈ (വളരെ ലളിതമാക്കിയ) ഉദാഹരണത്തിൽ, ഡാറ്റാബേസ് ഉപയോക്താവിന്റെ query-യ്ക്ക് ഏറ്റവും ബന്ധപ്പെട്ടിരിക്കുന്ന അഞ്ച് chunks തിരികെ നൽകുന്നു, അവ application-ലേക്ക് അയയ്ക്കപ്പെടുകയും LLM prompt-യിൽ ഉൾപ്പെടുത്തപ്പെടുകയും ചെയ്യുന്നു.

RAG എപ്പോൾ തിരഞ്ഞെടുക്കണം, LLM എപ്പോൾ തിരഞ്ഞെടുക്കണം, കൂടാതെ എപ്പോൾ രണ്ടും സംയോജിപ്പിക്കണം

LLM-കളും RAG-യും പരസ്പരം പൂരകമായ സംവിധാനങ്ങളാണ്. അതിനാൽ, “എപ്പോൾ ഞാൻ ഒരു LLM തിരഞ്ഞെടുക്കണം, എപ്പോൾ RAG?” എന്ന ചോദ്യം തെറ്റായ രീതിയിൽ രൂപകൽപ്പന ചെയ്തതാണ്. പകരം, നിങ്ങൾ ചോദിക്കേണ്ടത്, “ഒരു LLM എപ്പോൾ മതിയാകും, RAG എപ്പോൾ ഉചിതമാണ്?” എന്നാണ്.

RAG സജ്ജീകരിക്കാത്ത LLM എപ്പോൾ ഉപയോഗിക്കണം

• നിങ്ങൾ തെരഞ്ഞെടുത്ത AI model-ന് വലിയ context window ഉണ്ട്: കൃത്യമായ മറുപടിക്കായി ആവശ്യമായ എല്ലാ വിവരങ്ങളോ ഡാറ്റയോ prompt-ലേക്ക് ഉൾപ്പെടുത്തുന്നത് എളുപ്പമാണെങ്കിൽ, ഉദാഹരണത്തിന് ഒരു ഡോക്യുമെന്റ് അപ്‌ലോഡ് ചെയ്യുന്നതുപോലെ, അത് latency കുറയ്ക്കാനും retrieval-ുമായി ബന്ധപ്പെട്ട പ്രശ്നങ്ങൾ തടയാനും സഹായിക്കും.
• റീസണിംഗ് and data analysis വർക്ക്ഫ്ലോകൾ: ഒരു prompt-ൽ നൽകിയിരിക്കുന്ന ഡാറ്റ മാത്രം ആശ്രയിക്കുന്ന analysis and റീസണിംഗ് വർക്ക്ഫ്ലോകൾക്ക് RAG capabilities ആവശ്യമില്ല.
• Code generation: പൊതുവായ coding ജോലികൾക്കായി സാധാരണയായി RAG ആവശ്യമില്ല, എന്നാൽ മുൻപ് ചെയ്ത fixes അല്ലെങ്കിൽ vendor APIs, documentation എന്നിവ തിരിച്ചെടുക്കുന്നതുപോലുള്ള project-specific ജോലികൾക്കായി ഇത് സാധാരണയായി ഉപയോഗിക്കുന്നു.

RAG സജ്ജീകരിച്ച LLM എപ്പോൾ ഉപയോഗിക്കണം

• നിങ്ങൾക്ക് പുതുക്കിയ വിവരങ്ങളിലേക്കുള്ള പ്രവേശനം ആവശ്യമാണ്: കൃത്യമായ മറുപടി സൃഷ്ടിക്കാൻ ഒരു AI application-ന് പുതുക്കിയ വിവരങ്ങളുടെ ബാഹ്യ ഉറവിടങ്ങളിലേക്കുള്ള പ്രവേശനം ആവശ്യമുണ്ടെങ്കിൽ, എപ്പോഴും RAG capabilities സജ്ജമാക്കിയിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക.
• നിങ്ങൾ ഒരു പ്രത്യേക മേഖലയിൽ പ്രവർത്തിക്കുന്നു: medicine, law, education മുതലായ മേഖലകളിൽ, കൃത്യത, വിശദാംശങ്ങൾ, source checking എന്നിവ പ്രധാനപ്പെട്ടിടത്ത്, LLM-only ഉപയോഗം പലപ്പോഴും അപര്യാപ്തമായിരിക്കും.
• Outputs should reference internal company files: നിങ്ങൾ ആഭ്യന്തരമായി ആയാലും customer-facing ആപ്പിലായാലും, ആഭ്യന്തര company documents, data, ഒരു brand kit, documentation, അല്ലെങ്കിൽ files എന്നിവയെ അടിസ്ഥാനമാക്കി ഉള്ളടക്കം സൃഷ്ടിക്കാൻ AI ഉപയോഗിക്കുന്നുവെങ്കിൽ, RAG ആ വിവരങ്ങളിലേക്കുള്ള പ്രവേശനം നൽകുന്നു.

RAG ഉം LLM-കളും പരസ്പരം പൂരകവും വികസിച്ചുകൊണ്ടിരിക്കുന്നതുമായ സാങ്കേതികവിദ്യകളാണ്

RAG AI-യുടെ പരിണാമത്തിലെ ഒരു പ്രധാന നവീകരണത്തെ സൂചിപ്പിച്ചു. ഇത് മൂന്ന് പ്രധാന പ്രശ്നങ്ങളെ പരിഹരിക്കുന്നു: പഴയ വിവരങ്ങൾ, പരിമിതമായ model memory, കൂടാതെ പ്രസക്തമായ training data-യുടെ അഭാവം മൂലമുള്ള വിവരക്കുറവുകൾ, ഇവ പലപ്പോഴും hallucinations-ലേക്ക് നയിച്ചു. തീർച്ചയായും, LLM-കൾ ഇവയെ പൂർണ്ണമായും മറികടന്നിട്ടില്ല, പക്ഷേ RAG വരവോടെ അവയുടെ സംഭവന തോത് വളരെ കുറഞ്ഞു.

RAG ഒരു static technology അല്ല. reranking, retrieval ഉം token usage ഉം സമയത്തുള്ള latency, അപകടകരമായ data sources-നേതിരായ security defenses, ഒന്നിലധികം sources-ൽ നിന്നുള്ള retrieved data സംയോജിപ്പിക്കൽ, എന്നിവ ഉൾപ്പെടെ പല മേഖലകളിലും മെച്ചപ്പെടുത്തൽ പ്രതീക്ഷിക്കപ്പെടുന്നു. LLM-കളും agentic AI-യും മുന്നേറുന്നതിനനുസരിച്ച്, അവയെ പിന്തുണയ്ക്കുന്ന RAG systems-വും മുന്നേറും.