ഞങ്ങളുടെ 3 വർഷം പഴക്കമുള്ള ഫിൻടെക് കോഡ്ബേസിൽ AI ഹാലൂസിനേഷൻ (Hallucinating) ഒഴിവാക്കിയത് എങ്ങനെ

യഥാർത്ഥ പ്രൊഡക്ഷൻ പ്രോജക്റ്റുകളിൽ AI കോഡിംഗ് ടൂളുകൾ പരാജയപ്പെടുന്നു. പുതിയ കോഡുകളിൽ അവ നന്നായി പ്രവർത്തിക്കുമെങ്കിലും, ചരിത്രമുള്ള (history) പഴയ കോഡ്ബേസുകളിൽ അവ പരാജയപ്പെടുന്നു.

ഞങ്ങളുടെ ഫിൻടെക് പ്രോജക്റ്റിലൂടെ ഞാൻ ഇത് പ്രായോഗികമായി പഠിച്ചു. ഞങ്ങൾക്ക് രണ്ട് React ഫ്രണ്ട്‌എൻഡുകളും, ഒരു അഡ്മിൻ പാനലും, ഒരു FastAPI ബാക്കെൻഡും ഉണ്ട്. ഞങ്ങളുടെ ഡാറ്റാബേസ് സങ്കീർണ്ണമാണ്. അതിൽ സെൻസിറ്റീവ് ആയ സാമ്പത്തിക വിവരങ്ങളും ഉപയോക്താക്കളുടെ ഡാറ്റയും അടങ്ങിയിരിക്കുന്നു.

വേഗത്തിൽ പണി തീർക്കാൻ ഞങ്ങൾ AI ഉപയോഗിക്കാൻ ശ്രമിച്ചു. എന്നാൽ അത് ഉടൻ തന്നെ പരാജയപ്പെട്ടു.

ഒരു contacts ടേബിൾ നിർമ്മിക്കാൻ ഞാൻ AI-യോട് ആവശ്യപ്പെട്ടു. അത് പേരിനും ഇമെയിലിനും പുതിയ കോളങ്ങൾ നിർമ്മിച്ചു. എന്നാൽ ഈ കോളങ്ങൾ ഞങ്ങളുടെ users ടേബിളിൽ നേരത്തെ തന്നെ ഉണ്ടായിരുന്നു. ഒരു foreign key ഉപയോഗിക്കുന്നതിന് പകരം AI ഡാറ്റ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്തു. ഞങ്ങളുടെ users ടേബിളിനെക്കുറിച്ച് അതിന് യാതൊരു അറിവുമില്ലായിരുന്നു.

AI എങ്ങനെ മികച്ച കോഡ് എഴുതാൻ സഹായിക്കും എന്ന് ചോദിക്കുന്നത് ഞാൻ നിർത്തി. പകരം, ശരിയായ തീരുമാനങ്ങൾ എടുക്കാൻ AI എന്താണ് അറിഞ്ഞിരിക്കേണ്ടത് എന്ന് ഞാൻ ചോദിക്കാൻ തുടങ്ങി.

നിങ്ങൾ നൽകുന്ന കോൺടെക്സ്റ്റ് (context) എത്രത്തോളം മികച്ചതാണോ അത്രത്തോളം മാത്രമേ AI-യും മികച്ചതാകൂ. ഞങ്ങൾ ഞങ്ങളുടെ കോൺടെക്സ്റ്റ് വ്യക്തവും നിർണ്ണായകവുമാക്കി. ഞങ്ങൾ നിർമ്മിച്ച സംവിധാനം ഇതാ:

• ADR ഫയലുകൾ: ഞങ്ങൾ ഒരു docs/adrs/ ഫോൾഡർ നിർമ്മിച്ചു. ആർക്കിടെക്ചറൽ തീരുമാനങ്ങൾ എടുക്കുന്നതിന്റെ കാരണങ്ങൾ ഈ ഫയലുകളിൽ രേഖപ്പെടുത്തുന്നു. ഒരു ഫയൽ (ADR-001) AI-യോട് ഇപ്രകാരം പറയുന്നു: "ആദ്യം നിലവിലുള്ള ടേബിളുകൾ പരിശോധിക്കുക. Foreign keys ഉപയോഗിക്കുക. ഒരിക്കലും ഉപയോക്താക്കളുടെ ഡാറ്റ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യരുത്."

• context.md: ഞങ്ങളുടെ പ്രത്യേക പദാവലികൾ (terms) ഈ ഫയൽ വിശദീകരിക്കുന്നു. ഞങ്ങളുടെ സിസ്റ്റത്തിൽ വിവിധ ആശയങ്ങൾ എങ്ങനെ പരസ്പരം ബന്ധപ്പെട്ടിരിക്കുന്നു എന്ന് ഇത് AI-യെ അറിയിക്കുന്നു.

• plot.md: ഇതൊരു ഹൈ-ലെവൽ മാപ്പാണ്. പ്രോജക്റ്റിലെ വിവിധ ഭാഗങ്ങൾ എങ്ങനെ പരസ്പരം ബന്ധപ്പെട്ടിരിക്കുന്നു എന്ന് ഇത് കാണിക്കുന്നു.

• കർശനമായ നിയമങ്ങൾ: docs ഡയറക്ടറിയാണ് പരമമായ അധികാരം എന്ന് ഞങ്ങൾ AI-യോട് പറഞ്ഞു. അത് ഈ നിയമങ്ങൾ ക്രമമായി പാലിക്കണം.

• നിർബന്ധിത ടെസ്റ്റുകൾ: ഓരോ പുതിയ API റൂട്ടിലും ടെസ്റ്റ് കേസുകൾ ഉണ്ടായിരിക്കണം.

ഈ സംവിധാനം AI-യെ പ്രവചിക്കാവുന്നതാക്കുന്നു (predictable).

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

നിങ്ങളുടെ കോഡ്ബേസിനെക്കുറിച്ച് അറിയില്ലാത്തതിന് AI-യെ കുറ്റപ്പെടുത്തുന്നത് നിർത്തുക. അതിനെ ഒരു പുതിയ ജീവനക്കാരനെപ്പോലെ കാണുക. നിങ്ങളുടെ നിയമങ്ങൾ അറിയില്ലാത്തതിന് നിങ്ങൾ ഒരു പുതിയ ജീവനക്കാരനെ കുറ്റപ്പെടുത്തില്ലല്ലോ. പകരം നിങ്ങൾ അവർക്ക് ഡോക്യുമെന്റേഷനും ഓൺബോർഡിംഗും നൽകുന്നു.

ഞങ്ങളുടെ ഘടന ഇപ്രകാരമാണ്:

docs/

  • context.md (പദാവലികളും ബന്ധങ്ങളും)
  • plot.md (ഹൈ-ലെവൽ മാപ്പ്)
  • adr/ (ടേബിൾ നിർമ്മാണം അല്ലെങ്കിൽ API ഘടന പോലുള്ള പ്രത്യേക നിയമങ്ങൾ)

നിങ്ങളുടെ വർക്ക്ഫ്ലോയ്ക്കായി മൂന്ന് നിർദ്ദേശങ്ങൾ:

  • ADR-കളിൽ കൃത്യത പാലിക്കുക. അവ്യക്തമായ ഉപദേശങ്ങൾക്ക് പകരം വ്യക്തമായ നിർദ്ദേശങ്ങൾ നൽകുക.
  • ഡോക്യുമെന്റേഷനുകൾക്ക് മുൻഗണന നൽകുക. ഈ നിയമങ്ങൾക്കാണ് പ്രഥമ പരിഗണന എന്ന് AI-യോട് പറയുക.
  • തെറ്റുകളെ നിയമങ്ങളാക്കി മാറ്റുക. ഓരോ തവണ AI പരാജയപ്പെടുമ്പോഴും, അത് തടയാൻ പുതിയൊരു ADR നിർമ്മിക്കുക.

ഇത് AI-യെ പൂർണ്ണമാക്കുന്നില്ല. എന്നാൽ ഇത് അതിനെ സ്ഥിരതയുള്ളതാക്കുന്നു (consistent).

Source: https://dev.to/jaskiratanand/how-i-made-ai-stop-hallucinating-on-our-3-year-old-fintech-codebase-3g0h

Optional learning community: https://t.me/GyaanSetuAi