AI-യെ അന്ധമായി വിശ്വസിക്കുന്നത് നിർത്തുക: AI ഏജന്റുകളുടെ ഹാളുസിനേഷനുകൾ (Hallucinations) എങ്ങനെ കുറയ്ക്കാം

AI ഏജന്റുകൾ പലപ്പോഴും തെറ്റുകൾ വരുത്താറുണ്ട്. അവ തെറ്റായ കോഡുകൾ നിർമ്മിക്കുകയോ, ബിസിനസ്സ് നിയമങ്ങൾ ലംഘിക്കുകയോ, അല്ലെങ്കിൽ തെറ്റായ ടൂളുകൾ തിരഞ്ഞെടുക്കുകയോ ചെയ്തേക്കാം.

മികച്ച പ്രോംപ്റ്റുകൾ (prompts) ഉപയോഗിച്ച് ഇത് പരിഹരിക്കാൻ മിക്കവരും ശ്രമിക്കാറുണ്ട്. അത് ഒരു തെറ്റാണ്.

നിങ്ങൾക്ക് വിശ്വസനീയമായ AI ഏജന്റുകളെ വേണമെന്നുണ്ടെങ്കിൽ, വ്യക്തമായ നിയന്ത്രണങ്ങളോടു കൂടിയ (constraints) സിസ്റ്റങ്ങൾ നിങ്ങൾ രൂപകൽപ്പന ചെയ്യണം. നിങ്ങൾ ഒരു "Typist"-ൽ നിന്ന് ഒരു "Architect"-ലേക്ക് മാറേണ്ടതുണ്ട്.

The Typist vs. The Architect

മിക്ക ഉപയോക്താക്കളും Typists ആയിട്ടാണ് പ്രവർത്തിക്കുന്നത്:

  • നിങ്ങൾ ചോദിക്കുന്നു: "Implement an authentication system."
  • AI അതിന്റെ ഘടന (structure), ലൈബ്രറികൾ, ഫോൾഡർ ലേഔട്ട് എന്നിവ തീരുമാനിക്കുന്നു.
  • ഓരോ തീരുമാനവും ഒരു ഹാളുസിനേഷൻ (hallucination) സംഭവിക്കാനുള്ള സാധ്യതയാണ്.

എഞ്ചിനീയർമാർ Architects ആയിട്ടാണ് പ്രവർത്തിക്കുന്നത്:

  • നിങ്ങൾ ആദ്യം ഘടനയും ലൈബ്രറികളും നിർവചിക്കുന്നു.
  • നിങ്ങൾ നിയന്ത്രണങ്ങളും (constraints) നിയമങ്ങളും നിശ്ചയിക്കുന്നു.
  • നിങ്ങളുടെ പരിധിക്കുള്ളിൽ നിന്നുകൊണ്ട് മാത്രമേ AI കോഡ് എഴുതുകയുള്ളൂ.

കോഡിംഗ് കഴിവില്ലാത്തതുകൊണ്ടല്ല AI ഹാളുസിനേഷൻ നടത്തുന്നത്. മറിച്ച്, നിങ്ങളുടെ മനസ്സിലുള്ള എന്നാൽ നിങ്ങൾ പങ്കുവെക്കാത്ത സന്ദർഭങ്ങൾ (context) ഊഹിക്കാൻ ശ്രമിക്കുന്നത് കൊണ്ടാണ് അത് സംഭവിക്കുന്നത്.

Strategy 1: Context Files

ഓരോ ചാറ്റിലും നിർദ്ദേശങ്ങൾ ആവർത്തിക്കുന്നത് നിർത്തുക. AI-ക്ക് ഒരു സ്ഥിരമായ ചട്ടക്കൂട് (framework) നൽകുന്നതിനായി കോൺഫിഗറേഷൻ ഫയലുകൾ ഉപയോഗിക്കുക. വിവിധ ടൂളുകൾ വ്യത്യസ്ത മാനദണ്ഡങ്ങളാണ് ഉപയോഗിക്കുന്നത്:

• Claude Code-ന് വേണ്ടി CLAUDE.md • ഓപ്പൺ സോഴ്സ് ഇക്കോസിസ്റ്റങ്ങൾക്കായി AGENTS.md • Cursor-ന് വേണ്ടി .cursorrules • GitHub Copilot-ന് വേണ്ടി .copilotrules

Pro tip: ഒരു കേന്ദ്രീകൃത AGENTS.md ഫയൽ നിർമ്മിക്കുകയും, മറ്റെല്ലാ ഫയലുകളും സ്വയമേവ അപ്‌ഡേറ്റ് ആകാൻ symlinks ഉപയോഗിക്കുകയും ചെയ്യുക.

Strategy 2: ARD (Architecture Decision Records)

ഒരു ഏജന്റിനോട് എന്തെങ്കിലും നിർമ്മിക്കാൻ ആവശ്യപ്പെടുന്നതിന് മുമ്പ് ഒരു ADR തയ്യാറാക്കുക. ഈ ഡോക്യുമെന്റ് AI-യുടെ "ഊഹിക്കൽ" ഒഴിവാക്കുന്നു.

ഒരു നല്ല ADR-ൽ ഇവ ഉൾപ്പെടുന്നു:

  • എന്താണ് നിർമ്മിക്കേണ്ടത് എന്നതിനെക്കുറിച്ചുള്ള കൃത്യമായ വിവരങ്ങൾ.
  • ഏതൊക്കെ ഫയലുകൾ നിർമ്മിക്കണം, ഏതൊക്കെ ഫയലുകളിൽ മാറ്റം വരുത്താൻ പാടില്ല എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ.
  • ഉപയോഗിക്കേണ്ട പ്രത്യേക ടെക് സ്റ്റാക്കും (tech stack) ലൈബ്രറികളും.
  • വ്യക്തമായ നിയന്ത്രണങ്ങൾ (ഉദാഹരണത്തിന്, "No state in memory").
  • ഏജന്റ് തീരുമാനിക്കാൻ പാടില്ലാത്ത കാര്യങ്ങളുടെ പട്ടിക.

ഒരു Orchestrator-ന് ADR ലഭിക്കുമ്പോൾ, ഡിസൈൻ തീരുമാനങ്ങൾ നേരത്തെ തന്നെ പൂർത്തിയായിട്ടുണ്ടാകും. Developer ഏജന്റ് ആ സ്പെസിഫിക്കേഷൻ കോഡിലേക്ക് മാറ്റുക മാത്രമാണ് ചെയ്യുന്നത്. ഇത് പിശകുകൾ കുറയ്ക്കുകയും നിങ്ങളുടെ കോഡ്ബേസ് (codebase) സ്ഥിരതയുള്ളതാക്കി നിലനിർത്തുകയും ചെയ്യുന്നു.

വിശ്വസനീയമായ AI ഏജന്റ് വർക്ക്ഫ്ലോകൾ (workflows) നിർമ്മിക്കുന്നതിനെക്കുറിച്ച് ഞാൻ ഒരു പരമ്പര ആരംഭിക്കുകയാണ്. അടുത്ത ഭാഗങ്ങളിൽ, സിസ്റ്റം പ്രോംപ്റ്റ് കോമ്പോസിഷനും (system prompt composition) അഡ്വാൻസ്ഡ് എഞ്ചിനീയറിംഗ് സാങ്കേതിക വിദ്യകളും ഞാൻ ചർച്ച ചെയ്യും.

Source: https://dev.to/devjohanadrian/el-problema-de-la-confianza-ciega-como-reducir-las-alucinaciones-en-agentes-de-ia-parte-1-2aah