AI സംഭാഷണങ്ങളിലെ വിട്ടുപോയ ഭാഗം

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

അഞ്ച് മിനിറ്റ് നീണ്ടുനിൽക്കുന്ന ഒരു ഡെമോയ്ക്ക് ആ മിഥ്യാധാരണ മനോഹരമായി പ്രവർത്തിക്കും. എന്നാൽ യഥാർത്ഥ ഉപയോക്താക്കളും, യഥാർത്ഥ ഡാറ്റയും, യഥാർത്ഥ പണവും രംഗപ്രവേശം ചെയ്യുമ്പോൾ അത് തകർന്നടിയുന്നു. പ്രൊഡക്ഷനിൽ (production), ബന്ധം എന്നത് വെറും User ↔ LLM മാത്രമല്ല. അത് User ↔ ഒരു LLM അടങ്ങിയിരിക്കുന്ന സങ്കീർണ്ണമായ ഒരു സിസ്റ്റം ആണ്. ആ സിസ്റ്റത്തിന്റെ ആരും സംസാരിക്കാത്ത ഭാഗമാണ് ഹാർനെസ് (harness)—മോഡലിന് ചുറ്റുമുള്ള എല്ലാ കാര്യങ്ങളെയും തിരഞ്ഞെടുക്കുന്നതിനും, റൂട്ട് ചെയ്യുന്നതിനും, സംരക്ഷിക്കുന്നതിനും, ഏകോപിപ്പിക്കുന്നതിനും സഹായിക്കുന്ന ഒരു പ്ലാറ്റ്‌ഫോം (scaffolding). അത് ഇല്ലാതെ നിങ്ങൾക്ക് ഒരു ഉൽപ്പന്നമില്ല; പകരം ഒരു പ്രോട്ടോടൈപ്പ് (prototype) മാത്രമേയുള്ളൂ.

എന്തുകൊണ്ടാണ് ലളിതമായ ലൂപ്പ് പരാജയപ്പെടുന്നത്

ഒരു ഡെമോ എന്നത് നിയന്ത്രിതമായ ഒരു സാഹചര്യമാണ്. ചോദ്യങ്ങൾ ചെറുതാണ്, കോൺടെക്സ്റ്റ് (context) പരിമിതമാണ്, റിസ്ക് കുറവാണ്. ഡെവലപ്പർ ഒരു സിംഗിൾ API കോൾ നടത്തുന്നു, മറുപടി ലഭിക്കുന്നു, കാണികൾ കൈയടിക്കുന്നു. എന്നാൽ പ്രൊഡക്ഷൻ എന്നത് സങ്കീർണ്ണമാണ്. ഉപയോക്താക്കൾ അവ്യക്തമായ ചോദ്യങ്ങൾ ചോദിക്കുന്നു. തേർഡ് പാർട്ടി API-കൾ ടൈംഔട്ട് ആകുന്നു. ഇന്നലെ കൃത്യമായ JSON നൽകിയ ഒരു മോഡൽ പെട്ടെന്ന് മാർക്ക്ഡൗൺ (markdown) നൽകാൻ തുടങ്ങുന്നു. കോൺടെക്സ്റ്റ് വിൻഡോകൾ നിറയുന്നു. ഏറ്റവും മോശം സമയത്ത് റേറ്റ് ലിമിറ്റുകൾ (rate limits) വരുന്നു.

ഒരു സാധാരണ പ്രോംപ്റ്റ്-റെസ്പോൺസ് ലൂപ്പിന് ഇതിനൊന്നും ഉത്തരം നൽകാൻ കഴിയില്ല. ഏത് മോഡൽ വേരിയന്റ് ആണ് ഒരു പ്രത്യേക ടാസ്ക് കൈകാര്യം ചെയ്യേണ്ടതെന്ന് അതിന് അറിയില്ല. മൂന്ന് ഘട്ടങ്ങൾക്ക് മുമ്പ് എന്താണ് സംഭവിച്ചതെന്ന് അതിന് ഓർമ്മയില്ല. പരാജയപ്പെട്ട ഒരു കോൾ വീണ്ടും ശ്രമിക്കാനോ (retry), ചിലവ് കൂടുമ്പോൾ റിക്വസ്റ്റുകൾ നിയന്ത്രിക്കാനോ (throttle), അല്ലെങ്കിൽ ഡാറ്റാബേസിലേക്ക് എത്തുന്നതിന് മുമ്പ് ഔട്ട്പുട്ട് ശുദ്ധീകരിക്കാനോ (sanitize) അതിന് കഴിയില്ല. ഇവ വെറും അപ്രതീക്ഷിത സംഭവങ്ങളല്ല (edge cases), മറിച്ച് യഥാർത്ഥ ലോക സോഫ്റ്റ്‌വെയറുകളുടെ അടിസ്ഥാന സവിശേഷതകളാണ്. ഇവ കൈകാര്യം ചെയ്യുക എന്നത് ഹാർനെസിന്റെ ജോലിയാണ്.

ഹാർനെസ് യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്യുന്നത്

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

നിലവിലെ ടാസ്കിന് അനുയോജ്യമായ മോഡൽ തിരഞ്ഞെടുക്കൽ. എല്ലാ ഇടപാടുകൾക്കും ലഭ്യമായ ഏറ്റവും ശക്തമായ ഫൗണ്ടേഷൻ മോഡൽ തന്നെ ആവശ്യമില്ല. ചില ജോലികൾക്ക് ഉയർന്ന ചിന്താശേഷി (reasoning power) ആവശ്യമാണ്; മറ്റു ചിലതിന് വേഗതയും കുറഞ്ഞ ചിലവും മതിയാകും. മികച്ച രീതിയിൽ നിർമ്മിച്ച ഒരു ഹാർനെസ് റിക്വസ്റ്റുകളെ ബുദ്ധിപരമായി റൂട്ട് ചെയ്യുന്നു. ഉദാഹരണത്തിന്, ഒരു കസ്റ്റമർ സപ്പോർട്ട് ഏജന്റ് വരുന്ന സന്ദേശത്തിന്റെ ഉദ്ദേശ്യം (intent) തിരിച്ചറിയാൻ—റീഫണ്ട് അഭ്യർത്ഥനയാണോ അതോ ഷിപ്പിംഗ് സംശയമാണോ എന്ന് അറിയാൻ—വേഗതയേറിയതും കുറഞ്ഞ ചിലവുള്ളതുമായ ഒരു മോഡൽ ഉപയോഗിച്ചേക്കാം. സങ്കീർണ്ണമായ ഒരു തർക്കമാണെങ്കിൽ, ഹാർനെസ് ആ ടാസ്കിനെ കൂടുതൽ ശേഷിയുള്ള ഒരു മോഡലിലേക്ക് മാറ്റുന്നു. ഉപയോക്താവിന് വെറുമൊരു ട്രാക്കിംഗ് ലിങ്ക് മാത്രമാണ് വേണ്ടതെങ്കിൽ, ലൈറ്റ് വെയ്റ്റ് മോഡൽ ഉടൻ തന്നെ മറുപടി നൽകുന്നു, ഇത് ചിലവ് നിയന്ത്രിക്കാൻ സഹായിക്കുന്നു.

ഡാറ്റാ ഫ്ലോ കൈകാര്യം ചെയ്യൽ. യഥാർത്ഥ ആപ്ലിക്കേഷനുകൾ ഒറ്റപ്പെട്ടവയല്ല. ഒരു AI ഏജന്റിന് പലപ്പോഴും ഒരു വെക്റ്റർ സ്റ്റോറിൽ (vector store) നിന്ന് ഡോക്യുമെന്റുകൾ എടുക്കാനും, ഒരു CRM ക്വറി ചെയ്യാനും, ഉപയോക്താവിന്റെ സമീപകാല പ്രവർത്തനങ്ങൾ വായിക്കാനും, അവയെല്ലാം ചേർത്ത് ഒരു കൃത്യമായ മറുപടി നൽകാനും ആവശ്യമായി വന്നേക്കാം. ഹാർനെസ് ഈ പ്രക്രിയ നിയന്ത്രിക്കുന്നു. അത് ശരിയായ കോൺടെക്സ്റ്റ് ഭാഗങ്ങൾ ശേഖരിക്കുന്നു, അവ പ്രസക്തി നഷ്ടപ്പെടാതെ ടോക്കൺ പരിധിക്കുള്ളിൽയാണോ എന്ന് പരിശോധിക്കുന്നു, അവ മോഡലിന് അനുയോജ്യമായ രീതിയിൽ ക്രമീകരിക്കുന്നു, തുടർന്ന് ഔട്ട്പുട്ട് അടുത്ത സിസ്റ്റത്തിലേക്ക് കൈമാറുന്നു. ഈ ഏകോപനമില്ലെങ്കിൽ, മോഡലിന് ആവശ്യമായ വിവരങ്ങൾ ലഭിക്കാതെ വരികയോ അല്ലെങ്കിൽ അനാവശ്യ വിവരങ്ങൾ കൊണ്ട് അത് നിറയുകയോ ചെയ്യും.

എററുകൾ കൈകാര്യം ചെയ്യൽ. പരമ്പരാഗത സർവീസുകളിൽ നിന്ന് വ്യത്യസ്തമായി LLM-കൾ പരാജയപ്പെടുന്നത് പല രീതിയിലാണ്. അവ തെറ്റായ വിവരങ്ങൾ (hallucinate) നൽകുന്നു. ശൂന്യമായ മറുപടികൾ നൽകുന്നു. മോഡൽ വേർഷനിൽ ചെറിയ മാറ്റം വന്നാൽ പോലും ഫോർമാറ്റിംഗ് നിർദ്ദേശങ്ങൾ ലംഘിക്കുന്നു. ഹാർനെസ് ഇത്തരം പരാജയങ്ങളെ അപ്രതീക്ഷിത സംഭവങ്ങളായല്ല, മറിച്ച് പ്രതീക്ഷിക്കാവുന്ന കാര്യങ്ങളായാണ് കാണുന്നത്. അത് സ്കീമകൾ (schemas) പരിശോധിക്കുന്നു, തെറ്റായ മറുപടികൾ തടയുന്നു, റീട്രൈ ലോജിക് (retry logic) പ്രയോഗിക്കുന്നു, കൂടാതെ പ്രധാന എൻഡ്പോയിന്റ് പരാജയപ്പെടുമ്പോൾ സെക്കൻഡറി പ്രൊവൈഡറിലേക്കോ കാഷഡ് (cached) റിസൾട്ടിലേക്കോ മാറുന്നു. മറ്റെല്ലാം പരാജയപ്പെട്ടാൽ, ഉപയോക്താവിന് തെറ്റായ വിവരങ്ങൾ നൽകുന്നതിന് പകരം ഒരു മനുഷ്യ ഓപ്പറേറ്ററുടെ സഹായം തേടുന്നു.

സിസ്റ്റം വിശ്വാസ്യത ഉറപ്പാക്കൽ. പ്രൊഡക്ഷൻ എന്നാൽ ഒരേസമയം നിരവധി ഉപയോക്താക്കൾ, ചിലവ് നിയന്ത്രണങ്ങൾ, പ്രവചനാതീതമായ ലേറ്റൻസി (latency) എന്നിവയാണ്. ഹാർനെസ് റേറ്റ് ലിമിറ്റുകൾ നടപ്പിലാക്കുന്നു, കണക്ഷൻ പൂളിംഗ് (connection pooling) നിയന്ത്രിക്കുന്നു, കൂടാതെ സർക്യൂട്ട് ബ്രേക്കറുകൾ (circuit breakers) ഉപയോഗിക്കുന്നു. ഇത് ഒരു മോഡൽ പ്രൊവൈഡർ പതുക്കെയായാൽ പോലും നിങ്ങളുടെ മുഴുവൻ ആപ്ലിക്കേഷനും തടസ്സപ്പെടാതിരിക്കാൻ സഹായിക്കുന്നു. ഓരോ ഇടപാടും ഇത് ലോഗ് ചെയ്യുന്നു, അതുവഴി ഒരു സെഷൻ പരാജയപ്പെട്ടതിന്റെ കാരണം കണ്ടെത്താൻ സാധിക്കും. കൂടാതെ, പ്രോംപ്റ്റുകളുടെ വേർഷനുകൾ സൂക്ഷിക്കുന്നതിലൂടെ നിങ്ങളുടെ ഏജന്റിന്റെ സ്വഭാവം അറിയാതെ മാറുന്നത് ഒഴിവാക്കാം.

ഒരേ മോഡൽ, തികച്ചും വ്യത്യസ്തമായ ഫലങ്ങൾ

ഇത് പല പ്രൊഡക്റ്റ് ടീമുകളെയും കുഴപ്പിക്കുന്ന ഒരു പ്രതിഭാസത്തെ വിവരിക്കുന്നു. ഒരേ ഫൗണ്ടേഷൻ മോഡൽ ഉപയോഗിച്ച്—ഒരേ വെയ്റ്റുകൾ (weights), ഒരേ കോൺടെക്സ്റ്റ് വിൻഡോ (context window), ഒരേ ട്രെയിനിംഗ് കട്ട്ഓഫ് (training cutoff)—രണ്ട് കമ്പനികൾക്ക് തികച്ചും വ്യത്യസ്തമായ അനുഭവങ്ങൾ നൽകാൻ സാധിക്കും. ഒന്ന് വളരെ വേഗത കുറഞ്ഞതും, തകരാറിലാകാൻ സാധ്യതയുള്ളതും, കാര്യങ്ങൾ മറന്നുപോകുന്നതുമായി തോന്നും. മറ്റൊന്ന് വളരെ വേഗതയേറിയതും, സ്ഥിരതയുള്ളതും, വിശ്വസനീയവുമാണ്.

വ്യത്യാസം ഒരിക്കലും മോഡലിലല്ല. അത് മോഡലിന് ചുറ്റുമുള്ള സിസ്റ്റത്തിലാണ്. ഒരു ടീം മോഡലിനെ മുഴുവൻ ഉൽപ്പന്നമായും കണ്ടപ്പോൾ, മറ്റേ ടീം അതിനെ ഒരു കൃത്യമായ ആർക്കിടെക്ചറിലെ ഒരു ഘടകമായി മാത്രം കണ്ടു. ആ അച്ചടക്കം നിലനിൽക്കുന്നത് ഹാർനെസിലാണ് (harness).

പ്രോംപ്റ്റുകളിൽ നിന്ന് ആർക്കിടെക്ചറിലേക്കുള്ള മാറ്റം

AI വികസനത്തിന്റെ ആദ്യകാലങ്ങളിൽ പ്രോംപ്റ്റ് എഞ്ചിനീയറിംഗിനാണ് (prompt engineering) മുൻഗണന നൽകിയിരുന്നത്. വാക്കുകളിൽ മാറ്റം വരുത്തുന്നതും ഉദാഹരണങ്ങൾ ചേർക്കുന്നതും റോൾ-പ്ലേ നിർദ്ദേശങ്ങൾ നൽകുന്നതും ഔട്ട്‌പുട്ടിന്റെ ഗുണനിലവാരം മെച്ചപ്പെടുത്താൻ സഹായിച്ചിരുന്നു. ആ കഴിവ് ഇപ്പോഴും പ്രസക്തമാണ്, എന്നാൽ ഒരു മത്സരപരമായ നേട്ടമായി അതിന്റെ ഗുണഫലങ്ങൾ കുറഞ്ഞുവരികയാണ്. ഒരു റിട്രൈ പോളിസി (retry policy) ഇല്ലാത്തതോ അല്ലെങ്കിൽ സ്വകാര്യ വിവരങ്ങൾ പുറത്തുവിടുന്ന ഡാറ്റാ പൈപ്പ്‌ലൈൻ ഉള്ളതോ ആയ പ്രശ്നങ്ങൾ കേവലം പ്രോംപ്റ്റുകൾ കൊണ്ട് പരിഹരിക്കാൻ കഴിയില്ല.

ഇപ്പോൾ സംഭവിക്കുന്ന യഥാർത്ഥ മാറ്റം സോഫ്റ്റ്‌വെയർ ആർക്കിടെക്ചറിലേക്കുള്ള മാറ്റമാണ്. എഞ്ചിനീയർമാർ സ്റ്റേറ്റ് മെഷീനുകൾ (state machines) രൂപകൽപ്പന ചെയ്യുകയും, മോഡൽ ലെയറും ആപ്ലിക്കേഷൻ ലോജിക്കും തമ്മിൽ കർശനമായ ഇന്റർഫേസുകൾ നിർവചിക്കുകയും ചെയ്യുന്നു. നോൺ-ഡിറ്റർമിനിസത്തെ (non-determinism) ഒരു പ്രധാന എഞ്ചിനീയറിംഗ് പ്രശ്നമായി അവർ കാണുന്നു. വിതരണ സംവിധാനങ്ങളെക്കുറിച്ചുള്ള (distributed systems) ചോദ്യങ്ങളാണ് അവർ ചോദിക്കുന്നത്: ഒരു സംഭാഷണത്തിലുടനീളം സ്റ്റേറ്റ് എങ്ങനെ നിലനിൽക്കും? ഒരു ടൂൾ ലഭ്യമാകാതിരുന്നാൽ എന്ത് സംഭവിക്കും? പ്രോബബലിസ്റ്റിക് ആയ ഒരു സിസ്റ്റത്തെ എങ്ങനെ ടെസ്റ്റ് ചെയ്യാം? ഒരു കളിപ്പാട്ടവും ഒരു യഥാർത്ഥ ഉപകരണവും തമ്മിലുള്ള വ്യത്യാസം ഈ ചോദ്യങ്ങളാണ്.

പ്രൊഡക്ഷന് വേണ്ടി നിർമ്മിക്കുമ്പോൾ: ഒബ്സർവബിലിറ്റിയും കൺട്രോളും

നിങ്ങൾ ഗൗരവമായി ഉൽപ്പന്നങ്ങൾ പുറത്തിറക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഹാർനെസിന് രണ്ട് പ്രധാന ഗുണങ്ങൾ ആവശ്യമാണ്: ഒബ്സർവബിലിറ്റി (observability), ഓർക്കസ്ട്രേഷൻ (orchestration).

ഒബ്സർവബിലിറ്റി എന്നാൽ മോഡലിന് എന്ത് ലഭിച്ചു, അത് എന്ത് തിരിച്ചുനൽകി, ഓരോ ഘട്ടത്തിനും എത്ര സമയം എടുത്തു എന്നിവ കാണാൻ സാധിക്കണം എന്നാണ് അർത്ഥമാക്കുന്നത്. ഒരു ഏജന്റിന്റെ തീരുമാനങ്ങൾ എവിടെയാണ് തെറ്റുന്നത് എന്ന് കൃത്യമായി കണ്ടെത്താൻ ഇത് സഹായിക്കുന്നു. ഈ കാഴ്ചപ്പാടില്ലാതെ, ഒരു AI സിസ്റ്റം ഡിബഗ് (debug) ചെയ്യുന്നത് ഇരുട്ടത്തിരുന്ന് ഒരു കാർ എഞ്ചിൻ നന്നാക്കുന്നത് പോലെയാണ്.

ഓർക്കസ്ട്രേഷൻ എന്നാൽ നിങ്ങളുടെ ബിസിനസ് ലോജിക് മോഡൽ ഇന്ററാക്ഷൻ ലെയറിൽ നിന്ന് വേറിട്ട് നിൽക്കണം എന്നാണ് അർത്ഥമാക്കുന്നത്. കോഡ് വേർഷൻ ചെയ്യുന്നതുപോലെ തന്നെ പ്രോംപ്റ്റുകളും വേർഷൻ ചെയ്യണം, അങ്ങനെ പുതിയൊരു ഡെപ്ലോയ്‌മെന്റ് സിസ്റ്റത്തിന്റെ പെരുമാറ്റത്തിൽ മാറ്റം വരുത്തുന്നില്ലെന്ന് ഉറപ്പാക്കാം. പരാജയസാധ്യതകൾ (failure modes) മനഃപൂർവ്വം പരീക്ഷിക്കണം—ഉദാഹരണത്തിന് ഒരു API ഇടയ്ക്ക് നിർത്തുകയോ, തെറ്റായ ടൂൾ റിസൾട്ടുകൾ നൽകുകയോ ചെയ്യുന്നത് വഴി സിസ്റ്റം എങ്ങനെ പ്രതികരിക്കുന്നു എന്ന് നോക്കണം. നിങ്ങൾ ഒരു റെഡിമെയ്ഡ് ഓർക്കസ്ട്രേഷൻ ലൈബ്രറി ഉപയോഗിച്ചാലും സ്വന്തമായി നിർമ്മിച്ചാലും, ആ അച്ചടക്കമാണ് പ്രധാനം.

യഥാർത്ഥ പാഠം

ഫൗണ്ടേഷൻ മോഡലുകൾ മെച്ചപ്പെട്ടുകൊണ്ടിരിക്കും. അവ കൂടുതൽ വേഗതയുള്ളതും, വില കുറഞ്ഞതും, കാര്യശേഷിയുള്ളതുമായി മാറും. എന്നാൽ കൂടുതൽ കരുത്തുള്ള ഒരു എഞ്ചിൻ ഉണ്ടായതുകൊണ്ട് മാത്രം തകരാറിലായ ഒരു ചേസിസ് (chassis) ശരിയാകില്ല. അടുത്ത കുറച്ച് വർഷങ്ങളിൽ വിജയിക്കുന്ന ടീമുകൾ ഏറ്റവും മികച്ച മോഡലുകൾ ഉപയോഗിക്കുന്നവരായിരിക്കില്ല. മറിച്ച്, വിശ്വസനീയവും നിരീക്ഷിക്കാൻ കഴിയുന്നതും കൃത്യമായി ഏകോപിപ്പിച്ചതുമായ ഒരു ഹാർനെസ് നിർമ്മിച്ചവരായിരിക്കും. അവർക്ക് ആപ്ലിക്കേഷനുകൾ മാറ്റാതെ തന്നെ മോഡലുകൾ മാറ്റാൻ സാധിക്കും. ഓരോ ടോക്കണും നിയന്ത്രിക്കാൻ കഴിയുന്നതിനാൽ അവർക്ക് ചിലവ് നിയന്ത്രിക്കാനും സാധിക്കും. അവരുടെ സിസ്റ്റങ്ങൾ പരാജയപ്പെടുമ്പോൾ പോലും കൃത്യമായ രീതിയിൽ പ്രവർത്തിക്കുന്നതിനാൽ അവർക്ക് സമാധാനമായി ഉറങ്ങാനും സാധിക്കും.

മോഡലിനെക്കുറിച്ച് മാത്രം ചിന്തിക്കുന്നത് നിർത്തുക. അത് പ്രവർത്തിപ്പിക്കുന്ന സിസ്റ്റത്തെക്കുറിച്ച് ചിന്തിച്ചു തുടങ്ങുക. സ്മാർട്ട് മോഡലുകൾക്ക് ചുറ്റും സ്മാർട്ട് സിസ്റ്റങ്ങൾ നിർമ്മിക്കുന്ന എഞ്ചിനീയർമാരുടെ കാലമാണ് വരാനിരിക്കുന്നത്.

This article draws on ideas originally discussed by Abdulaziz Zos in "Beyond The Model".

AI എഞ്ചിനീയറിംഗിനെക്കുറിച്ചും സിസ്റ്റം ഡിസൈനിനെക്കുറിച്ചും കൂടുതൽ ചർച്ചകൾക്കായി GyaanSetu learning community സന്ദർശിക്കുക.