ஒரு AI-ஆல் இயக்கப்படும் உரையாடலின் (chat) முழு நேரத்திற்கும் ஒரு தரவுத்தளப் பரிவர்த்தனையை (database transaction) திறந்து வைத்திருப்பது, பதில்களைச் சிதைக்கக்கூடும் மற்றும் அடிப்படையான DBMS-ஐ முடக்கிவிடக்கூடும் என்று ஒரு டெவலப்பர் வழிகாட்டி எச்சரிக்கிறது. LLM-ஆல் இயக்கப்படும் கருவிகளை உருவாக்கும் குழுக்களைக் கவரும் வகையில் எழுதப்பட்டுள்ள இந்த குறிப்பு, இத்தகைய நடைமுறையை "செய்யக்கூடாது" என்று கூறி, அதற்குப் பதிலாக குறுகிய கால நிலைத்தன்மை முறைகளை (short-lived consistency patterns) நான்கு பரிந்துரைக்கிறது.

இந்த எச்சரிக்கை ஏன் முக்கியமானது

LLM மூலம் இயங்கும் உதவியாளர்கள் பெரும்பாலும் தொடர்ச்சியான கேள்விகளைக் கேட்பார்கள்: அவை ஒரு பதிவை (record) வாசிப்பார்கள், ஒரு விவரத்தைக் கேட்பார்கள், பிறகு ஒரு மொத்தத் தொகையைக் கேட்பார்கள். அந்த நிலைகளுக்கு இடையே அடிப்படைத் தரவு மாறினால், உதவியாளர் முரண்பட்ட புள்ளிவிவரங்களைத் தரக்கூடும்—அதாவது ஒரு பதில் தவறாக இருக்கும். உரையாடலின் தொடக்கத்தில் ஒரு தனிப் பரிவர்த்தனையைத் தொடங்கி, உரையாடல் முடியும் வரை அதைத் திறந்து வைத்திருப்பதே எளிதான தீர்வாகத் தோன்றலாம். ஆனால் நடைமுறையில், அந்த அணுகுமுறை row versions-களைப் பிடித்து வைத்திருக்கும், tempdb-ஐ நிரப்பும், locks-களைத் தக்கவைக்கும் மற்றும் connection pooling-ஐப் பாதிக்கும்.

நீண்ட காலப் பரிவர்த்தனைகளுக்கு வழிவகுப்பது எது

  • Multi-turn prompting – பயனர் ஒரு பதிலைச் see செய்வதற்கு முன், LLM-கள் பொதுவாகப் பல தூண்டுதல்களை (prompts) உருவாக்குகின்றன.
  • Tool calls that hit the database – ஒவ்வொரு முறையும் ஒரு stored procedure, ஒரு SELECT, அல்லது ஒரு UPDATE-ஐ அழைக்கலாம்.
  • Uncontrolled transaction scope – டெவலப்பர்கள் சில நேரங்களில், இது நிலைத்தன்மையை (consistency) உறுதிப்படுத்தும் என்று கருதி, முழு உரையாடலையும் ஒரு BEGIN…COMMIT block-க்குள் வைத்துவிடுகிறார்கள்.

உரையாடல் நீடிக்கும்போது, பரிவர்த்தனை ஒரு நிலையான பார்வையைப் (stable view) பெறுவதற்காக, DB engine அசல் row versions-களைத் தக்கவைக்க வேண்டும். அந்த versions அனைத்தும் tempdb-இல் அமர்ந்து, இடம் மற்றும் I/O-வை நுகர்கின்றன. அதே காலப்பகுதியில் Held செய்யப்படும் locks, ஒரே நேரத்தில் தரவை எழுதும் (concurrent writers) செயல்பாடுகளைத் தடுக்கும், மேலும் காலியாக இருக்கும் connection, pool-ஐத் தீர்த்துவிடக்கூடும், இதனால் புதிய பயனர்கள் ஒரு காலியிடத்திற்காகக் காத்திருக்க வேண்டியிருக்கும்.

நான்கு குறுகிய கால முறைகள்

நிலைத்தன்மையை (consistency) முழு உரையாடலுக்கும் பொதுவான ஒன்றாகக் கருதாமல், ஒவ்வொரு tool-call-க்கும் உரிய ஒன்றாகக் கருத வேண்டும் என்று வழிகாட்டி பரிந்துரைக்கிறது. அந்த நான்கு முறைகள்:

  1. Live statements – ஒவ்வொரு அழைப்பும் இயல்பான isolation level-இன் கீழ் இயங்கும், இது செயல்படுத்தப்படும் தருணத்தில் commit செய்யப்பட்ட தரவை மட்டுமே காணும். இதுவே எளிமையான மாதிரி; முந்தைய முறையிலிருந்து தரவு மாறியிருக்கலாம் என்பதை அழைப்பவர் ஏற்றுக்கொள்கிறார்.
  2. Bounded transactions – ஒரு டெவலப்பர் சில அறிக்கைகளை (statements) ஒரு சிறிய பரிவர்த்தனைக்குள் குழுவாகச் செய்கிறார், இது அடுத்த LLM turn-க்கு முன்பே முடிந்துவிடும். இது tool call-க்கு அப்பால் நீடிக்காமல், அந்தத் தொகுப்பிற்கு (batch) அணுத்தன்மையை (atomicity) உறுதி செய்கிறது.
  3. Snapshot reads – இந்தச் செயல்பாடு ஒரு குறிப்பிட்ட snapshot timestamp-உடன் தொடங்குகிறது, இது அழைப்பின் கால அளவு முழுவதும் தரவுத்தளத்தின் நிலையான பார்வையை வழங்குகிறது. ஒரே நேரத்தில் தரவு மாற்றங்கள் (concurrent writes) நடந்தாலும், அழைப்பிற்குள் இருக்கும் அனைத்து வாசிப்புகளும் ஒரே தரவைக் காண்கின்றன.
  4. Materialized reports – இந்தத் கருவி (tool), ஒரு குறிப்பிட்ட காலக்கட்டத்தின் தரவுத்தளத்தைப் பிரதிபலிக்கும், முன்னரே உருவாக்கப்பட்ட மற்றும் பதிப்புப்படுத்தப்பட்ட (versioned) முடிவுத் தொகுப்பிலிருந்து (result set) தரவைப் படிக்கிறது. பின்னர், பக்கப் பிரிப்பு (pagination) அல்லது கூடுதல் கணக்கீடுகள் அந்த உறைந்த தரவுத் தொகுப்பின் (frozen dataset) அடிப்படையில் செயல்படும்.

SQL Server-இல், READ_COMMITTED_SNAPSHOT செயல்பாட்டில் உள்ளதா என்று சரிபார்க்கவும். அதன் பெயர் மட்டுமே முழு விவரத்தையும் சொல்லிவிடும் என்று நினைக்க வேண்டாம்.

LLM மூலம் இயங்கும் செயலிகளுக்கான நடைமுறை விதிகள்

  • Batch what you need – ஒரு கேள்விக்கு பல மதிப்புகள் தேவைப்பட்டால், ஒவ்வொன்றிற்கும் தனித்தனி பரிவர்த்தனைகளைத் தொடங்கும் தனித்தனி வினவல்களை (queries) அனுப்புவதற்குப் பதிலாக, அவற்றை ஒரே tool call-இல் கணக்கிடுங்கள்.
  • Deterministic pagination – பல பக்கங்களில் முடிவுகளைக் காட்டும்போது, ஒரு நிலையான ordering key, ஒரு cursor, அல்லது ஒரு materialized result set-ஐப் பயன்படுத்தவும். பயனர் ஸ்க்ரோல் செய்யும்போது ஒருபோதும் பரிவர்த்தனையைத் திறந்து வைக்காதீர்கள்.
  • Return evidence – தரவோடு சேர்த்து, நிலைத்தன்மை மாதிரியை (consistency model) வெளிப்படையாகக் காட்டும் metadata-வையும் உள்ளடக்குங்கள்: consistency class, snapshot start time, reporting cutoff, data freshness, row count, database identity, மற்றும் ஒரு trace ID.
  • Stress-test with concurrency – LLM தூண்டுதல்களை (prompting) வழங்கிக் கொண்டிருக்கும்போதே, ஒரே நேரத்தில் தரவை எழுதும் (concurrent writes) சூழலைச் சோதித்துப் பாருங்கள், மேலும் செயலி (application) முறையாக மீண்டும் முயற்சிக்கிறதா (retry) அல்லது மாற்று வழியைப் பின்பற்றுகிறதா என்பதை உறுதிப்படுத்தவும்.

இதன் அடிப்படைத் தேவை தெளிவானது: ஒரு AI உரையாடல் தரவுத்தளப் பரிவர்த்தனையின் ஆயுட்காலத்தைத் தீர்மானிக்கக் கூடாது. நிலைத்தன்மையை ஒவ்வொரு tool call-க்கும் உட்படுத்துவதன் மூலம், டெவலப்பர்கள் தரவுத்தளத்தை ஆரோக்கியமாக வைத்திருக்கலாம், அனைத்துப் பயனர்களுக்கும் செயல்திறனைப் பாதுகாக்கலாம், மேலும் LLM துல்லியமாகப் பதிலளிக்கத் தேவையான நம்பகமான தரவையும் வழங்கலாம்.