ഒരു AI അധിഷ്ഠിത ചാറ്റിന്റെ മുഴുവൻ സമയവും ഒരു ഡാറ്റാബേസ് ട്രാൻസാക്ഷൻ (database transaction) തുറന്നു വെക്കുന്നത് ഉത്തരങ്ങൾ തെറ്റാക്കാനും അടിസ്ഥാന DBMS-നെ തളർത്താനും കാരണമാകുമെന്ന് ഒരു ഡെവലപ്പർ ഗൈഡ് മുന്നറിയിപ്പ് നൽകുന്നു. LLM അധിഷ്ഠിത ടൂളുകൾ നിർമ്മിക്കുന്ന ടീമുകൾക്കായി തയ്യാറാക്കിയ ഈ കുറിപ്പിൽ, ഇത്തരത്തിലുള്ള രീതി "ഒഴിവാക്കേണ്ടതാണ്" എന്ന് പറയുന്നതിനൊപ്പം പകരം ഉപയോഗിക്കാൻ കഴിയുന്ന നാല് ഹ്രസ്വകാല കൺസിസ്റ്റൻസി പാറ്റേണുകളും (short-lived consistency patterns) നിർദ്ദേശിക്കുന്നു.

ഈ മുന്നറിയിപ്പ് പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്

LLM അധിഷ്ഠിത അസിസ്റ്റന്റുകൾ പലപ്പോഴും തുടർച്ചയായ ചോദ്യങ്ങൾ ചോദിക്കാറുണ്ട്: അവർ ഒരു റെക്കോർഡ് വായിക്കുന്നു, ഒരു വിവരത്തിനായി ആവശ്യപ്പെടുന്നു, തുടർന്ന് മൊത്തം തുക ചോദിക്കുന്നു. ഈ ഘട്ടങ്ങൾക്കിടയിൽ ഡാറ്റയിൽ മാറ്റം വന്നാൽ, അസിസ്റ്റന്റ് പരസ്പരവിരുദ്ധമായ കണക്കുകൾ നൽകിയേക്കാം—അതായത് ഒരു ഉത്തരം തെറ്റാകാൻ സാധ്യതയുണ്ട്. സംഭാഷണത്തിന്റെ തുടക്കത്തിൽ ഒരു ട്രാൻസാക്ഷൻ തുറക്കുകയും ചാറ്റ് അവസാനിക്കുന്നത് വരെ അത് നിലനിർത്തുകയും ചെയ്യുക എന്നതാണ് ഇതിനുള്ള എളുപ്പവഴി എന്ന് തോന്നാമെങ്കിലും, പ്രായോഗികമായി ഈ രീതി റോ വേർഷനുകളെ (row versions) തടഞ്ഞുവെക്കാനും, tempdb നിറയ്ക്കാനും, ലോക്കുകൾ (locks) നിലനിർത്താനും, കണക്ഷൻ പൂളിംഗിനെ (connection pooling) ബാധിക്കാനും കാരണമാകും.

ദീർഘനേരം നീണ്ടുനിൽക്കുന്ന ട്രാൻസാക്ഷനുകൾക്ക് കാരണമാകുന്നവ

  • മൾട്ടി-ടേൺ പ്രോംപ്റ്റിംഗ് (Multi-turn prompting) – ഉപയോക്താവിന് മറുപടി ലഭിക്കുന്നതിന് മുമ്പ് LLM-കൾ സാധാരണയായി നിരവധി പ്രോംപ്റ്റുകൾ തയ്യാറാക്കുന്നു.
  • ഡാറ്റാബേസിനെ ബാധിക്കുന്ന ടൂൾ കോളുകൾ (Tool calls that hit the database) – ഓരോ ഘട്ടത്തിലും ഒരു സ്റ്റോർഡ് പ്രൊസീജർ (stored procedure), ഒരു SELECT, അല്ലെങ്കിൽ ഒരു UPDATE എന്നിവ ആവശ്യമായി വന്നേക്കാം.
  • നിയന്ത്രണമില്ലാത്ത ട്രാൻസാക്ഷൻ സ്കോപ്പ് (Uncontrolled transaction scope) – കൺസിസ്റ്റൻസി ഉറപ്പാക്കാൻ വേണ്ടി ഡെവലപ്പർമാർ ചിലപ്പോൾ മുഴുവൻ ചാറ്റിനെയും ഒരു BEGIN…COMMIT ബ്ലോക്കിനുള്ളിൽ ഉൾപ്പെടുത്താറുണ്ട്.

ചാറ്റ് നീണ്ടുപോകുമ്പോൾ, ട്രാൻസാക്ഷന് സ്ഥിരതയുള്ള ഒരു കാഴ്ച (stable view) ലഭിക്കുന്നതിനായി ഡാറ്റാബേസ് എഞ്ചിൻ ഒറിജിനൽ റോ വേർഷനുകൾ സൂക്ഷിക്കേണ്ടി വരുന്നു. ഈ വേർഷനുകൾ tempdb-യിൽ ഇരിക്കുകയും സ്പേസും I/O-യും ഉപയോഗിക്കുകയും ചെയ്യുന്നു. ഇതേ കാലയളവിൽ നിലനിൽക്കുന്ന ലോക്കുകൾ ഒരേസമയം ഡാറ്റ എഴുതാൻ ശ്രമിക്കുന്നവരെ തടയുകയും, ഉപയോഗിക്കപ്പെടാത്ത കണക്ഷനുകൾ പൂൾ (pool) തീർന്നുപോകാൻ കാരണമാവുകയും ചെയ്യുന്നു. ഇത് പുതിയ കോളുകൾക്ക് ഒഴിവുള്ള സ്ലോട്ട് ലഭിക്കാനായി കാത്തുനിൽക്കേണ്ടി വരുന്ന അവസ്ഥയുണ്ടാക്കുന്നു.

നാല് ഹ്രസ്വകാല പാറ്റേണുകൾ

കൺസിസ്റ്റൻസിയെ ഒരു സംഭാഷണത്തിന്റെ ഭാഗമായി കാണുന്നതിന് പകരം ഓരോ ടൂൾ കോളിന്റെയും (per-tool-call) ഭാഗമായി കാണണമെന്ന് ഗൈഡ് നിർദ്ദേശിക്കുന്നു. ആ നാല് പാറ്റേണുകൾ ഇവയാണ്:

  1. ലൈവ് സ്റ്റേറ്റ്‌മെന്റുകൾ (Live statements) – ഓരോ കോളും ഡിഫോൾട്ട് ഐസൊലേഷൻ ലെവലിൽ (default isolation level) പ്രവർത്തിക്കുന്നു, അതിനാൽ എക്സിക്യൂഷൻ സമയത്ത് കമ്മറ്റ് ചെയ്ത ഡാറ്റ മാത്രമേ ഇതിൽ കാണാൻ കഴിയൂ. ഇതാണ് ഏറ്റവും ലളിതമായ രീതി; മുൻപത്തെ ഘട്ടത്തിന് ശേഷം ഡാറ്റയിൽ മാറ്റം വന്നേക്കാം എന്ന് ഇതിൽ കണക്ട് ചെയ്യുന്നയാൾ അംഗീകരിക്കുന്നു.
  2. ബൗണ്ടഡ് ട്രാൻസാക്ഷനുകൾ (Bounded transactions) – അടുത്ത LLM ടേണിന് മുമ്പ് അവസാനിക്കുന്ന ഒരു ചെറിയ ട്രാൻസാക്ഷനുള്ളിൽ ഡെവലപ്പർ കുറച്ച് സ്റ്റേറ്റ്‌മെന്റുകൾ ഗ്രൂപ്പ് ചെയ്യുന്നു. ഇത് ടൂൾ കോളിന് ശേഷം നീണ്ടുനിൽക്കാതെ തന്നെ ആ ബാച്ചിന് അറ്റോമിസിറ്റി (atomicity) ഉറപ്പാക്കുന്നു.
  3. സ്നാപ്പ്ഷോട്ട് റീഡുകൾ (Snapshot reads) – ഒരു നിശ്ചിത സ്നാപ്പ്ഷോട്ട് ടൈംസ്റ്റാമ്പോടെയാണ് (snapshot timestamp) ഈ പ്രവർത്തനം ആരംഭിക്കുന്നത്, ഇത് കോളിന്റെ ദൈർഘ്യത്തിൽ ഡാറ്റാബേസിന്റെ സ്ഥിരതയുള്ള ഒരു കാഴ്ച നൽകുന്നു. ഒരേസമയം ഡാറ്റ എഴുതപ്പെട്ടാൽ പോലും, കോളിനുള്ളിലെ എല്ലാ റീഡുകളും ഒരേ ഡാറ്റ തന്നെ കാണുന്നു.
  4. മെറ്റീരിയലൈസ്ഡ് റിപ്പോർട്ടുകൾ (Materialized reports) – ഒരു നിശ്ചിത സമയത്തെ ഡാറ്റാബേസ് അവസ്ഥയെ പ്രതിഫലിപ്പിക്കുന്ന, മുൻകൂട്ടി തയ്യാറാക്കിയ ഒരു റിസൾട്ട് സെറ്റിൽ നിന്നാണ് ടൂൾ വിവരങ്ങൾ വായിക്കുന്നത്. തുടർന്ന് പേജിനേഷനോ (pagination) മറ്റ് കണക്കുകൂട്ടലുകളോ ഈ ഫ്രോസൺ ഡാറ്റാസെറ്റിൽ (frozen dataset) നടക്കുന്നു.

SQL Server-ൽ READ_COMMITTED_SNAPSHOT ആക്റ്റീവ് ആണോ എന്ന് പരിശോധിക്കുക. പേര് മാത്രം നോക്കി കാര്യങ്ങൾ പൂർണ്ണമാണെന്ന് കരുതരുത്.

LLM അധിഷ്ഠിത ആപ്പുകൾക്കായുള്ള പ്രായോഗിക നിയമങ്ങൾ

  • ആവശ്യമായവ ബാച്ച് ചെയ്യുക (Batch what you need) – ഒരു ചോദ്യത്തിന് നിരവധി മൂല്യങ്ങൾ ആവശ്യമാണെങ്കിൽ, ഓരോന്നും പുതിയ ട്രാൻസാക്ഷൻ തുടങ്ങുന്ന പ്രത്യേക ക്വറികൾക്ക് പകരം ഒരു സിംഗിൾ ടൂൾ കോൾ ഉപയോഗിച്ച് അവ കണക്കാക്കുക.
  • ഡിറ്റർമിനിസ്റ്റിക് പേജിനേഷൻ (Deterministic pagination) – ഫലങ്ങൾ പല പേജുകളിലായി കാണിക്കുമ്പോൾ, ഒരു സ്റ്റേബിൾ ഓർഡറിംഗ് കീ (ordering key), ഒരു കർസർ (cursor), അല്ലെങ്കിൽ ഒരു മെറ്റീരിയലൈസ്ഡ് റിസൾട്ട് സെറ്റ് എന്നിവ ഉപയോഗിക്കുക. ഉപയോക്താവ് സ്ക്രോൾ ചെയ്യുമ്പോൾ ഒരിക്കലും ഒരു ട്രാൻസാക്ഷൻ തുറന്നു വെക്കരുത്.
  • തെളിവുകൾ നൽകുക (Return evidence) – ഡാറ്റയ്‌ക്കൊപ്പം കൺസിസ്റ്റൻസി മോഡൽ വ്യക്തമാക്കുന്ന മെറ്റാഡാറ്റയും ഉൾപ്പെടുത്തുക: കൺസിസ്റ്റൻസി ക്ലാസ്, സ്നാപ്പ്ഷോട്ട് സ്റ്റാർട്ട് ടൈം, റിപ്പോർട്ടിംഗ് കട്ട്ഓഫ്, ഡാറ്റ ഫ്രഷ്നസ്, റോ കൗണ്ട്, ഡാറ്റാബേസ് ഐഡന്റിറ്റി, കൂടാതെ ഒരു ട്രേസ് ഐഡി (trace ID) എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു.
  • കൺകറൻസി ഉപയോഗിച്ച് സ്ട്രെസ് ടെസ്റ്റ് ചെയ്യുക (Stress-test with concurrency) – LLM പ്രോംപ്റ്റുകൾ നൽകുന്ന സമയത്ത് ഒരേസമയം ഡാറ്റ എഴുതുന്നത് (concurrent writes) സിമുലേറ്റ് ചെയ്യുക, ആപ്ലിക്കേഷൻ അത് ശരിയായി കൈകാര്യം ചെയ്യുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.

ഇതിന്റെ സാരം വ്യക്തമാണ്: ഒരു AI ചാറ്റ് ഒരു ഡാറ്റാബേസ് ട്രാൻസാക്ഷന്റെ ആയുസ്സ് തീരുമാനിക്കരുത്. കൺസിസ്റ്റൻസിയെ ഓരോ ടൂൾ കോളിന്റെയും പരിധിയിലേക്ക് ഒതുക്കുന്നതിലൂടെ, ഡെവലപ്പർമാർക്ക് ഡാറ്റാബേസിന്റെ ആരോഗ്യം നിലനിർത്താനും എല്ലാ ഉപയോക്താക്കൾക്കും മികച്ച പെർഫോമൻസ് ഉറപ്പാക്കാനും കൃത്യമായ മറുപടി നൽകാൻ LLM-ന് ആവശ്യമായ വിശ്വസനീയമായ ഡാറ്റ നൽകാനും സാധിക്കും.