മോഡലിനെയല്ല, ഹാർനെസിനെ വിശ്വസിക്കുക

എന്റെ വീട്ടിലെ ഹാർഡ്‌വെയറിൽ പ്രവർത്തിക്കുന്ന ഒരു ലോക്കൽ 27B കോഡിംഗ് മോഡൽ എന്നത് ഒരു ഭാഗ്യപരീക്ഷണം പോലെയാണ്. ചിലപ്പോൾ അത് ഇരുപത് മിനിറ്റിനുള്ളിൽ കോഡ് ശരിയാക്കും. എന്നാൽ മറ്റു ചിലപ്പോൾ അത് തെറ്റായ ഫയൽ എഡിറ്റ് ചെയ്യുകയോ അല്ലെങ്കിൽ എന്ത് ചെയ്താലും പാസ്സാകുന്ന തരത്തിലുള്ള ഒരു ടെസ്റ്റ് എഴുതുകയോ ചെയ്യും.

LLMKube-ന്റെ Foreman-ന്റെ ലക്ഷ്യം ഒരു പെർഫെക്റ്റ് മോഡലിനെ കണ്ടെത്തുക എന്നതല്ല. മറിച്ച്, മോഡലിനേക്കാൾ കൂടുതൽ നിങ്ങൾക്ക് വിശ്വസിക്കാൻ കഴിയുന്ന ഒരു ഹാർനെസ് (harness) നിർമ്മിക്കുക എന്നതാണ്.

ഈ വാരാന്ത്യത്തിൽ, സ്വന്തം ഗാർഡ്‌റെയിലുകൾ (guardrails) നിർമ്മിച്ചുകൊണ്ട് ആ ഹാർനെസ് സ്വയം പരിശോധന നടത്തി. നടന്ന കാര്യങ്ങൾ ഇതാ:

• എന്റെ ലോക്കൽ കോഡർ തനിക്കായി മൂന്ന് പുതിയ ഗേറ്റുകൾ (gates) നിർമ്മിച്ചു. • ഒരൊറ്റ ഗേറ്റ്, താൻ കണ്ടെത്തേണ്ടിയിരുന്ന അതേ പിഴവോടെയാണ് വന്നത്. എന്നാൽ റിവ്യൂ പ്രക്രിയ അത് കണ്ടെത്തി. • മെഷീനുകൾ ജോലി ചെയ്തുകൊണ്ടിരിക്കുമ്പോൾ മൂന്ന് പുതിയ മനുഷ്യരായ കൺട്രിബ്യൂട്ടർമാർ നാല് ക്ലീൻ പുൾ റിക്വസ്റ്റുകൾ (pull requests) അയച്ചു. • ഒരേ മോഡൽ തന്നെ ഒരു AMD ബോക്സിലും ഒരു Apple Silicon Mac-ലും പ്രവർത്തിച്ചു. ആരും പ്രതീക്ഷിക്കാത്ത രീതിയിൽ Mac ഒരു റൗണ്ട് വിജയിച്ചു. • ഒരു ഡാറ്റയും ക്ലൗഡ് API-ൽ എത്തിയില്ല.

ഒരു ലോക്കൽ മോഡലിലുള്ള കോഡിംഗ് ഏജന്റ് വ്യത്യസ്ത നിലവാരത്തിലുള്ള ഫലങ്ങളാണ് നൽകുന്നത്. എത്ര പ്രോംപ്റ്റ് ട്യൂണിംഗ് (prompt tuning) ചെയ്താലും ഒരു ചെറിയ മോഡലിനെ ഒരു ഫ്രോണ്ടിയർ മോഡലിനോളം (frontier model) വിശ്വസനീയമാക്കാൻ കഴിയില്ല.

Foreman മോഡലിനോട് വിശ്വസനീയമാകാൻ ആവശ്യപ്പെടുന്നില്ല. പകരം അത് മോഡലിനെ ഒരു പൈപ്പ്‌ലൈനിൽ (pipeline) പൊതിയുന്നു:

  • കോഡർ ഒരു ക്ലോൺ ചെയ്ത വർക്ക്സ്പേസിൽ (cloned workspace) ജോലി ചെയ്യുന്നു.
  • ഒരു ഫാസ്റ്റ് ഗേറ്റ് gofmt, vet, build, lint, കൂടാതെ യൂണിറ്റ് ടെസ്റ്റുകൾ എന്നിവ പ്രവർത്തിപ്പിക്കുന്നു.
  • ഒരു റിവ്യൂവർ ഇഷ്യുവിനെ (issue) അടിസ്ഥാനമാക്കി വ്യത്യാസങ്ങൾ (diff) പരിശോധിക്കുന്നു.
  • ഏതൊരു കോഡും അംഗീകരിക്കുന്നതിന് മുമ്പ് ഒരു ക്ലീൻ-റൂം Kubernetes Job മുഴുവൻ ടെസ്റ്റുകളും വീണ്ടും പ്രവർത്തിപ്പിക്കുന്നു.
  • സ്കോപ്പ് ചെക്കുകൾ (scope checks), റിപ്പോ-മാപ്പ് കോൺടെക്സ്റ്റ് (repo-map context) തുടങ്ങിയ ഡെറ്റമിനിസ്റ്റിക് റെയിലുകൾ (deterministic rails) ഈ പ്രക്രിയയ്ക്ക് ചുറ്റും പ്രവർത്തിക്കുന്നു.

മോഡൽ എന്നത് ഒരു സിസ്റ്റത്തിന്റെ ഭാഗം മാത്രമാണ്. മോഡൽ വിശ്വസനീയമല്ലാതിരിക്കുമ്പോഴും സിസ്റ്റത്തിന്റെ തീരുമാനം വിശ്വസനീയമാക്കുക എന്നതാണ് സിസ്റ്റത്തിന്റെ ജോലി.

യഥാർത്ഥ ചോദ്യം "മോഡൽ നല്ലതാണോ?" എന്നതല്ല. മറിച്ച് "മോഡൽ മോശമാകുമ്പോൾ ഹാർനെസ് അത് പിടികൂടുമോ?" എന്നതാണ്.

ഈ വാരാന്ത്യത്തിൽ, ഹാർനെസ് രണ്ട് പ്രധാന ബഗുകൾ (bugs) കണ്ടെത്തി. രണ്ടും സ്വയം സ്ഥിരീകരിക്കുന്ന (self-confirming) ടെസ്റ്റുകളായിരുന്നു. ടെസ്റ്റുകൾ പാസ്സാകാൻ വേണ്ടി തന്നെ എഴുതപ്പെട്ടതുകൊണ്ടാണ് അവ പാസ്സാകുന്നത്. അവ യഥാർത്ഥത്തിൽ കോഡ് പരിശോധിച്ചില്ല.

ഈ പരാജയങ്ങൾ ഞാൻ Foreman-ന് തിരികെ നൽകി. അവ പരിഹരിക്കാനായി ഗേറ്റുകൾ നിർമ്മിക്കാൻ ഞാൻ ഹാർനെസിനെ അനുവദിച്ചു:

  • ഒരു സ്കോപ്പ് ഗാർഡ് (scope guard): തെറ്റായ സബ്സിസ്റ്റത്തെ (subsystem) സ്പർശിക്കുന്ന ഏത് എഡിറ്റും ഇത് നിരസിക്കുന്നു.
  • ഒരു റിവ്യൂവർ റൂബ്രിക് (reviewer rubric): ടെസ്റ്റുകൾ പ്ലേസ്‌ഹോൾഡറുകൾക്ക് (placeholders) പകരം യഥാർത്ഥ പ്രൊഡക്ഷൻ വാല്യൂസ് ഉപയോഗിക്കുന്നുണ്ടെന്ന് ഇത് ഉറപ്പാക്കുന്നു.
  • ഒരു ബൈറ്റ് ചെക്ക് (bite check): പുതിയൊരു ടെസ്റ്റ് പഴയ കോഡിനെതിരെ പരാജയപ്പെടണം. രണ്ടും പാസ്സായാൽ അത് യഥാർത്ഥ ടെസ്റ്റ് അല്ല.

ബൈറ്റ് ചെക്ക് അതിന്റെ ആദ്യത്തെ ടെസ്റ്റിൽ തന്നെ പരാജയപ്പെട്ടു. അത് നിർമ്മിച്ച ഗേറ്റിൽ പിഴവുണ്ടായിരുന്നു. എന്നാൽ മെർജ് ചെയ്യുന്നതിന് മുമ്പ് റിവ്യൂ പ്രക്രിയ ആ പിശക് കണ്ടെത്തി. അതാണ് ഡിസൈൻ ശരിയായി പ്രവർത്തിക്കുന്നത് എന്ന് അർത്ഥമാക്കുന്നത്.

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

Source: https://dev.to/defilan/trust-the-harness-not-the-model-a-weekend-of-local-agents-building-their-own-guardrails-52nl

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