ഇക്കാലത്ത് RAG-ന് ചിലപ്പോൾ ചീത്തപ്പേര് കിട്ടാറുണ്ട്. ഇപ്പോൾ അത് തീർത്തും നിസ്സാരമാണെന്ന് ആളുകൾ കരുതുന്നതാകാം കാരണം—തുടങ്ങാൻ എളുപ്പമാണെങ്കിലും വിപുലീകരിക്കാൻ അത്ര എളുപ്പമല്ല—അല്ലെങ്കിൽ ‘സ്വയം പ്രവർത്തിക്കുന്ന സംവിധാനങ്ങൾ’ അതിനെ മറികടന്നുവെന്ന് അവർ കരുതുന്നതാകാം. എന്നാൽ പലപ്പോഴും അവയുടെ പുറംതോട് ഒന്ന് ചുരണ്ടിനോക്കിയാൽ വളരെ വേഗം RAG-നോട് ഏറെ സാമ്യമുള്ളതായി കാണാം…
പൊതുവായ ചില വെല്ലുവിളികൾ ഞങ്ങൾ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നുവെന്ന് ഒന്നോ രണ്ടോ പ്രായോഗിക ഉദാഹരണങ്ങളിലൂടെ ഈ ബ്ലോഗ് വിശദീകരിക്കുന്നു. അവ ഇവയാണ്:
ടെക്സ്റ്റും സംഖ്യാ ഡാറ്റയും കലർന്ന ഉള്ളടക്കം കൈകാര്യം ചെയ്യൽ, അത് ലളിതമായ RAG-നെ പരാജയപ്പെടുത്തുന്നതിന്റെ കാരണം: കീവേഡുകൾ പരസ്പരം കലരുന്നു, സംഖ്യകൾക്ക് സ്വതവേ അർഥപരമായ പ്രസക്തിയുമില്ല.
ആദ്യം സംഗ്രഹം സൃഷ്ടിക്കുന്ന ഉൾച്ചേർക്കലുകൾ രൂപകൽപ്പന ചെയ്യുന്നത് സഹായിക്കുന്നതെന്തുകൊണ്ട്: ഓരോ ഭാഗത്തിനും ഹ്രസ്വമായ വിവരണാത്മക സംഗ്രഹം സൃഷ്ടിച്ചശേഷം അതിനെ ഉൾച്ചേർത്ത് തിരയുക.
സാന്ദർഭിക സംഗ്രഹങ്ങൾ സൃഷ്ടിക്കുന്ന വിധം: ഒരേ ഘടനയുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ വേർതിരിച്ചറിയാൻ മൂലരേഖയുടെ സന്ദർഭം ഉൾപ്പെടുത്തുക.
കോഡിനെയും Pydantic മോഡലുകളെയും ആശ്രയിക്കേണ്ട സമയം: ഉള്ളടക്കം അതേപടി നിലനിർത്തേണ്ടിടത്ത് വിശ്വാസ്യതയ്ക്കായി ഇഷ്ടാനുസൃത കോഡ്, Pydantic മോഡൽ എന്നിവയിൽ ഒന്നോ രണ്ടുമോ LLM അഭ്യർഥനകളുമായി ചേർത്തുപയോഗിക്കുക.
അടിസ്ഥാനകാര്യങ്ങൾ
ഉപഭോക്തൃസഹായ ബോട്ടുകൾ മുതൽ ആന്തരിക വിജ്ഞാന സഹായികൾ വരെയുള്ളവയ്ക്ക് RAG സംവിധാനങ്ങളാണ് കരുത്തേകുന്നത്.
പശ്ചാത്തലത്തിൽ സാധാരണയായി നിങ്ങൾ ചെയ്യുന്നത്:
മൂലരേഖകളെ ഭാഗങ്ങളാക്കുക.
ഓരോ ഭാഗവും സദിശമേഖലയിൽ ഉൾച്ചേർക്കുക.
ചോദ്യം ലഭിക്കുമ്പോൾ മികച്ച K ഭാഗങ്ങൾ വീണ്ടെടുക്കുക.
ആ ഭാഗങ്ങളെ അടിസ്ഥാനമാക്കി ഉത്തരം സൃഷ്ടിക്കുക.
LangChain, LlamaIndex, OpenAI-യുടെ Filestore എന്നിവ പോലുള്ള ജനപ്രിയ ഉപകരണസഞ്ചയങ്ങൾ ഈ ഘട്ടങ്ങളെ ഏറെ ലളിതമാക്കുന്നു. എന്നാൽ യഥാർഥ പ്രയോഗങ്ങളിലെ പ്രവർത്തനശൃംഖലകളിൽ സാന്ദ്രമായ ടെക്സ്റ്റ് മാത്രമല്ലാത്ത ഡാറ്റയും കാണാം; അടിസ്ഥാന RAG അതിൽ ബുദ്ധിമുട്ടിയേക്കാം. തുടർന്നുള്ള വിഭാഗങ്ങളിൽ ഡാറ്റാ വെല്ലുവിളികളുടെ വ്യക്തമായ ഉദാഹരണങ്ങൾ കാണിക്കുകയും സങ്കീർണത കൂടുന്നതിനനുസരിച്ച് പരിഹാരം പടിപടിയായി നിർമ്മിക്കുകയും ചെയ്യും.
നിങ്ങളുടെ ഡാറ്റ വെറും ടെക്സ്റ്റ് മാത്രമല്ലാത്തപ്പോൾ—യഥാർഥത്തിൽ ഇത് അപൂർവമല്ല
ഒരു കളിയുടെ സന്ദർഭത്തിലുള്ള ഇനിപ്പറയുന്ന ഡാറ്റാഭാഗം പരിഗണിക്കുക:
JSON
വാക്കുകളുടെ അർഥവും വ്യാകരണവും വഴി പഠിച്ചെടുത്ത പരസ്പരബന്ധങ്ങളാണ് ഉൾച്ചേർക്കലുകൾ പ്രവർത്തിക്കാൻ കാരണം. മുകളിലെ ഡാറ്റയിൽ ടെക്സ്റ്റും സംഖ്യകളും കലർന്നിരിക്കുന്നു. ഈ പ്രത്യേക സന്ദർഭത്തിനു പുറത്ത് ആ സംഖ്യകൾക്ക് വാക്കുകളുമായി ഒരു ബന്ധവുമില്ല. അതുകൊണ്ട്, ഏതാനും വിവരണാത്മക വാക്കുകൾക്കു പിന്നാലെ ക്രമരഹിതമായ ചില സംഖ്യകൾ ചേർന്നതാണ് ഈ ഡാറ്റാഭാഗമെന്ന് പറയാം.
നമുക്കുള്ള ഏക ഡാറ്റാരൂപം ഇതായിരുന്നെങ്കിൽ ഇതൊരു പ്രശ്നമാകുമായിരുന്നില്ല. ലഭ്യമായ കുറച്ച് വിവരണാത്മക വാക്കുകളുടെ ഉൾച്ചേർക്കലുകൾ ഉപയോഗിച്ച് അപ്പോഴും വീണ്ടെടുക്കാമായിരുന്നു; അല്ലെങ്കിൽ ടെക്സ്റ്റിൽനിന്ന് SQL സൃഷ്ടിക്കുന്ന രീതി ഉപയോഗിക്കാമായിരുന്നു. എന്നാൽ ഇതേ വാക്കുകൾ ഉൾപ്പെടുന്ന ധാരാളം ടെക്സ്റ്റ് സാന്ദ്രമായ ഭാഗങ്ങൾക്കിടയിൽ ഈ ഭാഗം മറഞ്ഞുകിടക്കുകയാണെങ്കിൽ എന്തുചെയ്യും? ഉദാഹരണത്തിന്:
JSON
ഇനി “ഡ്രാക്കോണിക് അസൻഷൻ ഉപയോഗിക്കുമ്പോഴുള്ള ആക്രമണപരിധി എത്രയാണ്?” എന്ന് വീണ്ടെടുക്കാൻ ശ്രമിക്കുന്നതായി കരുതുക. ഒരേ കീവേഡുകൾ അടങ്ങിയ മറ്റു ഭാഗങ്ങളുടെ ബഹളത്തിൽ പ്രസക്തമായ ഭാഗം മറഞ്ഞിരിക്കുന്നതിനാൽ അത് വീണ്ടെടുക്കാൻ കഴിയാതിരിക്കാനാണ് സാധ്യത.
ഒരേ വിഷയത്തെക്കുറിച്ചുള്ള വ്യത്യസ്തതരം വിവരങ്ങളാണ് ഈ ഡാറ്റാഭാഗങ്ങളിൽ ഉള്ളതെങ്കിലും അവയെ നന്നായി വേർതിരിച്ചറിയാനാകുന്നില്ല എന്നതാണ് അടിസ്ഥാന പ്രശ്നം. നമുക്ക് അതിനെ ഏതെങ്കിലും വിധത്തിൽ കൂടുതൽ സമ്പന്നവും മെച്ചപ്പെട്ടതുമാക്കാനാകുമോ? തീർച്ചയായും കഴിയും:smile:
ഡാറ്റ സംഗ്രഹിച്ച് അതിനെ സമ്പന്നമാക്കുക; അതെ, നിങ്ങൾ വായിച്ചത് ശരിയാണ്
ഡാറ്റാഭാഗം നേരിട്ട് ഉൾച്ചേർക്കുന്നതിനു പകരം അത് എന്തിനെക്കുറിച്ചാണെന്ന് വിവരിക്കുന്ന ഒരു സംഗ്രഹം ആദ്യം സൃഷ്ടിക്കാം. തുടർന്ന് ആ സംഗ്രഹത്തെ ഉൾച്ചേർത്ത് അതിന്റെ അടിസ്ഥാനത്തിൽ വീണ്ടെടുക്കാം. ഉത്തരം സൃഷ്ടിക്കുന്ന ഘട്ടത്തിൽ സംഗ്രഹവുമായി ബന്ധിപ്പിച്ച യഥാർഥ ഡാറ്റ തന്നെയായിരിക്കും ഉപയോഗിക്കുക.
അതിനാൽ മുകളിൽ കാണിച്ച രണ്ട് ഉദാഹരണഭാഗങ്ങൾക്കും ഇതുപോലുള്ള സംഗ്രഹങ്ങൾ സൃഷ്ടിക്കാം:
പരിധി, വേഗം, നാശം എന്നിവയുടെ ആക്രമണ സ്ഥിതിവിവരക്കണക്കുകൾ—സ്വതവേയുള്ളതും ഡ്രാക്കോണിക് അസൻഷൻ ഉപയോഗിക്കുമ്പോഴുള്ളതും.
സജീവമാകാനുള്ള വ്യവസ്ഥകൾ, ദൃശ്യഫലങ്ങൾ, പശ്ചാത്തലകഥ എന്നിവ ഉൾപ്പെടെ ഡ്രാക്കോണിക് അസൻഷന്റെ വിവരണവും വിശദാംശങ്ങളും.
തുടർന്ന് ചോദ്യത്തെ സംഗ്രഹവുമായി “പൊരുത്തപ്പെടുന്ന” വിധത്തിൽ വിപുലീകരിക്കുകയും ചെയ്യും. ഉദാഹരണത്തിന്, “ഡ്രാക്കോണിക് അസൻഷൻ ഉപയോഗിക്കുമ്പോഴുള്ള ആക്രമണപരിധി എത്രയാണ്?” എന്നത് “ഡ്രാക്കോണിക് അസൻഷൻ ഉപയോഗിക്കുമ്പോഴുള്ള ആക്രമണപരിധിയുടെ സ്ഥിതിവിവരക്കണക്ക് എന്താണ്?” എന്നാക്കി മാറ്റും. സാങ്കേതികമേഖലയ്ക്കു പുറത്തുള്ള ഉപയോക്താക്കൾ ~~“തോന്നിയപോലെ”~~ സാധാരണ മനുഷ്യഭാഷയിൽ ചോദിക്കുമ്പോൾ ഇത് ഏറെ പ്രധാനമാണ്. കൃത്യതയും തിരിച്ചുവിളിക്കൽ നിരക്കും പരമാവധിയാക്കാൻ RAG എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നത് അവരുടെ അറിവിലോ പരിഗണനയിലോ ഉള്ള കാര്യമല്ലല്ലോ.


കാര്യങ്ങളെ സന്ദർഭത്തിൽനിന്ന് അടർത്തിമാറ്റരുത്—ജീവിതത്തിലും പൊതുവേ ബാധകമാണ്
ഇനി, താഴെ കാണുന്നതുപോലെ ഒരേ രൂപത്തിലുള്ള ഒട്ടേറെ ഡാറ്റാഭാഗങ്ങൾ കൈകാര്യം ചെയ്യേണ്ട തുടർസാഹചര്യം പരിഗണിക്കാം:
Plain Text
ഇതേ സമീപനം തുടർന്നാൽ, “കഥാപാത്രം X-ന്റെ ആക്രമണപരിധി എത്രയാണ്?” എന്ന് ചോദിക്കുന്നതായി കരുതുക. ഇപ്പോൾ സൃഷ്ടിച്ച സംഗ്രഹങ്ങളും പരസ്പരം ഏറെ സമാനമായതിനാൽ ഉത്തരം കണ്ടെത്തുന്നത് ഭാഗ്യത്തെ ആശ്രയിച്ചുള്ള ഊഹക്കളിയായി മാറും. അപ്പോൾ അവയെ എങ്ങനെ വേർതിരിച്ചറിയാം?
ലളിതമായ ഉത്തരം: സന്ദർഭം നൽകുക. ഡാറ്റാഭാഗത്തിൽ അതിന്റെ മൂലരേഖയെക്കുറിച്ചുള്ള ഒരു സൂചന ഉൾപ്പെടുത്തിയാൽ മതി. ഉദാഹരണത്തിന്, ഇവിടെ {”കഥാപാത്രം”: “X”} എന്ന് ചേർക്കാം. അപ്പോൾ കഥാപാത്രം Y, Z എന്നിവയ്ക്കും ഇതേ ഡാറ്റ ഉണ്ടായാലും കഥാപാത്രം X-ന്റെ ശരിയായ ഡാറ്റ കൃത്യമായി വീണ്ടെടുക്കാനാകും.
എന്നാൽ കൂടുതൽ മികച്ചതും മറ്റു സാഹചര്യങ്ങളിലേക്കും വ്യാപിപ്പിക്കാവുന്നതുമായ സമീപനം ആ ഭാഗത്തിന് സാന്ദർഭിക സംഗ്രഹം സൃഷ്ടിക്കുകയാണ്. അതായത്, ഡാറ്റാഭാഗത്തിന്റെ മാത്രം സംഗ്രഹം സൃഷ്ടിക്കുന്നതിനു പകരം അതും അതിന്റെ മൂലരേഖയും ഒരുമിച്ച് നൽകി പൊതുവായ സാന്ദർഭിക സംഗ്രഹം സൃഷ്ടിക്കാം. ആ ഭാഗം മൂലരേഖയിൽ എങ്ങനെ ചേരുന്നു എന്നതും സംഗ്രഹത്തിൽ ഉൾപ്പെടുത്താം. ഉദാഹരണത്തിന്:
കഥാപാത്രം X-ന്റെ … സംബന്ധിച്ച വിശദമായ സ്ഥിതിവിവരക്കണക്കുകൾ ഈ ഭാഗം നൽകുന്നു. ആക്രമണവേഗത്തിൽ X-നുള്ള കരുത്ത് വ്യക്തമാക്കിക്കൊണ്ട് ഈ ഭാഗം പൂർണരേഖയുമായി ബന്ധപ്പെടുന്നു…
കഥാപാത്രം Y-യുടെ … സംബന്ധിച്ച വിശദമായ സ്ഥിതിവിവരക്കണക്കുകൾ ഈ ഭാഗം നൽകുന്നു. പ്രത്യേക കഴിവ് ഉപയോഗിക്കുമ്പോൾ Y-യുടെ വർധിച്ച സ്ഥിതിവിവരക്കണക്കുകൾ കാണിച്ചുകൊണ്ട് ഈ ഭാഗം പൂർണരേഖയുമായി ബന്ധപ്പെടുന്നു…
കഥാപാത്രം Z-ന്റെ … സംബന്ധിച്ച വിശദമായ സ്ഥിതിവിവരക്കണക്കുകൾ ഈ ഭാഗം നൽകുന്നു. സംഘമത്സരങ്ങളിൽ പ്രതിരോധഭൂമികയ്ക്ക് അനുയോജ്യമായ Z-ന്റെ സ്ഥിതിവിവരക്കണക്കുകൾ കാണിച്ചുകൊണ്ട് ഈ ഭാഗം പൂർണരേഖയുമായി ബന്ധപ്പെടുന്നു…
Anthropic-ൽനിന്ന് ഭാഗികമായി പ്രചോദനം ഉൾക്കൊണ്ട ഈ രീതി മുകളിലെ ഉദാഹരണത്തിന് അമിതമായി തോന്നാം. എന്നാൽ “സന്ദർഭത്തിനു പുറത്ത്” തെറ്റായി വ്യാഖ്യാനിക്കപ്പെടാവുന്ന ഭാഗങ്ങൾക്ക് ഇത് ഏറെ ഫലപ്രദമാണ്. എല്ലാ ഭാഗങ്ങൾക്കും ചേരുന്ന ഏകീകൃത സമീപനം നൽകുന്നതിനാൽ സാങ്കേതിക പ്രവർത്തനശൃംഖല വൃത്തിയായി നിലനിർത്താനും ഇത് സഹായിക്കുന്നു.


നിങ്ങൾ ~~എല്ലാം നിയന്ത്രിക്കുന്നയാൾ~~ കർശനനാകേണ്ടപ്പോൾ
സാധാരണയായി ഡാറ്റ പൂർണരൂപത്തിൽ ലഭിച്ചശേഷം RAG സംവിധാനത്തിനായി അതിനെ ഭാഗങ്ങളാക്കുകയാണ് ചെയ്യുന്നത്. ഈ ഉദാഹരണത്തിൽ അല്പം വ്യത്യസ്തമായ ഒന്നാണ് കാണിക്കുന്നത്. ഡാറ്റ ഭാഗങ്ങളാക്കിയിട്ടുണ്ട്, പക്ഷേ അവ മോശം ഭാഗങ്ങളാണ്. യഥാർഥത്തിൽ വീണ്ടും ഒന്നിച്ചുചേർക്കേണ്ട യുക്തിസഹമായ ഒരു ഭാഗത്തിന്റെ ക്രമരഹിത വിഭാഗങ്ങളാണവ. ഒരു രേഖയുടെ ഉപവിഭാഗമോ ആശയപരമായി യോജിക്കുന്ന ഖണ്ഡികയോ പോലെ സ്വാഭാവികമായി ഒന്നിച്ചിരിക്കേണ്ട ഉള്ളടക്കത്തെയാണ് യുക്തിസഹമായ ഭാഗം എന്നു പറയുന്നത്.


ആദ്യശ്രമത്തിൽ ഈ ഡാറ്റ മുഴുവൻ ഒരു LLM അഭ്യർഥനയ്ക്ക് നൽകി, ഉചിതമെന്ന് തോന്നുന്ന രീതിയിൽ അവയെ കൂട്ടങ്ങളാക്കി ആ ഉള്ളടക്കം തിരികെ നൽകാൻ ആവശ്യപ്പെട്ടു. LLM ഇതിൽ നല്ല പ്രകടനം കാഴ്ചവയ്ക്കേണ്ടതല്ലേ? ഉവ്വ്, ഇല്ല എന്നും പറയാം.
പൂർണവും കൃത്യവുമായ ഉള്ളടക്കം ആവശ്യപ്പെടുമ്പോൾ, പ്രത്യേകിച്ച് സന്ദർഭം ദൈർഘ്യമേറിയതാണെങ്കിൽ, LLM-കൾ അലസമായി പെരുമാറുകയും വിശ്വാസ്യത കുറയുകയും ചെയ്യുന്നതായി മറ്റു പല അവസരങ്ങളിലും ഞങ്ങൾ കണ്ടെത്തിയിട്ടുണ്ട്. അതിൽ അത്ഭുതപ്പെടാനൊന്നുമില്ല. എന്നാൽ ഈ പ്രത്യേക പ്രയോഗത്തിന് അത് അംഗീകരിക്കാനാകാത്തതായിരുന്നു. ഒരു സംഗ്രഹവും വേണ്ട, യഥാർഥ ഉള്ളടക്കത്തിന്റെ ഒരു ഭാഗവും ഒഴിവാക്കരുത്; ഓരോ വാക്കും അതേപടി വേണം. ഒരു വിശദാംശവും വിട്ടുപോകരുത്.
തകർന്ന ഭാഗങ്ങളുടെ അർഥവും ഘടനയും മനസ്സിലാക്കുന്നതിൽ അത് മികച്ച പ്രകടനം കാഴ്ചവച്ചു എന്നതായിരുന്നു തീർച്ചയായും അനുകൂലവശം. കൃത്യമായ ഉള്ളടക്കം അതേപടി ഉദ്ധരിക്കാൻ അത് വിസമ്മതിക്കാതിരുന്നാൽ മാത്രം. നാശം:/
അപ്പോൾ LLM നന്നായി ചെയ്യുന്ന കാര്യങ്ങൾ പ്രയോജനപ്പെടുത്തുകയും അതിന് വിശ്വാസ്യതയില്ലാത്ത കാര്യങ്ങൾ ഒഴിവാക്കുകയും ചെയ്യുന്നതെങ്ങനെ? ഞങ്ങൾ പഴയ സുഹൃത്തായ കോഡിന്റെ സഹായം തേടി—അതായത് ഇഷ്ടാനുസൃത Python ഫങ്ഷന്റെ. ഒപ്പം “ഇതിലും ലളിതമാക്കാനാകാത്ത” ഒരു pydantic മോഡലും. പരിഹാരം ഇതാണ്:
നിലവിലെ യുക്തിസഹമായ ഭാഗം നിലനിർത്തിക്കൊണ്ട് ഓരോ വിഭാഗത്തിലൂടെയും ആവർത്തിച്ച് കടന്നുപോകുക.
ഓരോ വിഭാഗത്തിലും LLM-നോട് ചോദിക്കുക: ഈ വിഭാഗം നിലവിലെ യുക്തിസഹമായ ഭാഗത്തിൽ ഉൾപ്പെടുമോ? pydantic മോഡൽ അനുസരിച്ച് അതെ അല്ലെങ്കിൽ ഇല്ല എന്ന് ഉത്തരം നൽകുക.
അതെ എങ്കിൽ വിഭാഗം ആ ഭാഗത്തോട് ചേർക്കുക. ഇല്ലെങ്കിൽ നിലവിലെ യുക്തിസഹമായ ഭാഗം പൂർത്തിയായതിനാൽ അതേപടി പുറത്തുവിട്ട്, ഈ വിഭാഗം ഉപയോഗിച്ച് പുതിയൊരു ഭാഗം ആരംഭിക്കുക.


പൂർണ ഉള്ളടക്കം ഒറ്റത്തവണ പരിശോധിക്കുന്നതിനെക്കാൾ ഇവിടെ കുറച്ചുകൂടി ടോക്കണുകൾ ഉപയോഗിക്കുന്നുണ്ട്. എന്നാൽ കൃത്യമായ ഉള്ളടക്കം നിലനിർത്തുന്നതാണ് പരമപ്രധാനമായ ഈ പ്രയോഗത്തിൽ ചെറിയ അധികച്ചെലവ് പൂർണമായും മൂല്യവത്തായിരുന്നു.
ഇത് വളരെ ലളിതമായ പരിഹാരമാണ്. എന്നാൽ കർശനത ആവശ്യമായപ്പോൾ LLM-കൾ സാധ്യതാധിഷ്ഠിതമായതിനാൽ അവയെ മാത്രം ആശ്രയിക്കരുത് എന്ന സുപ്രധാന തത്ത്വം ഇത് പിന്തുടരുന്നു.
LLM-കളുടെ കഴിവുകൾ പൂർണമായി പ്രയോജനപ്പെടുത്തിക്കൊണ്ടുതന്നെ മുൻകൂട്ടി കണക്കാക്കാവുന്നതും വിശ്വാസ്യതയുള്ളതുമായ ഫലം നേടാൻ ഇഷ്ടാനുസൃത കോഡ്, ഫങ്ഷനുകൾ, pydantic മോഡലുകൾ എന്നിവ ഉപയോഗിക്കാം.
ജനറേറ്റീവ് AI പരിഹാരം നിർമ്മിക്കുന്നത് AI വെല്ലുവിളി മാത്രമല്ല, അത്രതന്നെ സാങ്കേതിക വെല്ലുവിളിയുമാണ്. നിങ്ങളുടേതായ സവിശേഷ വെല്ലുവിളികൾ നേരിടാൻ ഈ ഉദാഹരണങ്ങൾ പ്രചോദനമായെന്ന് പ്രതീക്ഷിക്കുന്നു. സാങ്കേതികവിദ്യയ്ക്ക് മുൻഗണന നൽകുന്ന ജനറേറ്റീവ് AI പരിഹാരങ്ങളെക്കുറിച്ച് കൂടുതലറിയാൻ റൂട്ടർ അധിഷ്ഠിത സ്വയം പ്രവർത്തിക്കുന്ന സംവിധാനങ്ങളുടെ രൂപകൽപ്പനയെക്കുറിച്ചുള്ള ഞങ്ങളുടെ ബ്ലോഗ് കുറിപ്പ് വായിക്കുക.