AI-ಚಾಲಿತ ಚಾಟ್‌ನ ಅವಧಿಯವರೆಗೆ ಡೇಟಾಬೇಸ್ ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಅನ್ನು ತೆರೆದಿಡುವುದು ಉತ್ತರಗಳನ್ನು ತಪ್ಪಾಗಿ ಮಾಡಬಹುದು ಮತ್ತು ಅಡಿಪಾಯದ DBMS ಅನ್ನು ಕುಂಠಿತಗೊಳಿಸಬಹುದು ಎಂದು ಒಬ್ಬ ಡೆವಲಪರ್ ಗೈಡ್ ಎಚ್ಚರಿಸುತ್ತದೆ. LLM-ಆಧಾರಿತ ಪರಿಕರಗಳನ್ನು ನಿರ್ಮಿಸುವ ತಂಡಗಳನ್ನು ಉದ್ದೇಶಿಸಿ ಬರೆದಿರುವ ಈ ಟಿಪ್ಪಣಿಯು, ಅಂತಹ ಅಭ್ಯಾಸವನ್ನು "ಮಾಡಬಾರದು" ಎಂದು ಹೇಳುತ್ತದೆ ಮತ್ತು ಬದಲಾಗಿ ನಾಲ್ಕು ಅಲ್ಪಾವಧಿಯ consistency ಮಾದರಿಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ಈ ಎಚ್ಚರಿಕೆಯ ಮಹತ್ವವೇನು

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 ಬ್ಲಾಕ್‌ನಲ್ಲಿ ಸುತ್ತುವರಿಯುತ್ತಾರೆ, ಇದು ಸ್ಥಿರತೆಯನ್ನು (consistency) ಖಚಿತಪಡಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಿರುತ್ತಾರೆ.

ಚಾಟ್ ದೀರ್ಘವಾಗಿದೆಯೇ, DB engine ಮೂಲ row versions ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ ಇದರಿಂದ ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಸ್ಥಿರವಾದ ನೋಟವನ್ನು (stable view) ನೋಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಆ versions ಗಳು tempdb ನಲ್ಲಿ ಕುಳಿತುಕೊಳ್ಳುತ್ತವೆ, ಇದರಿಂದ ಸ್ಥಳ (space) ಮತ್ತು I/O ಬಳಕೆಯಾಗುತ್ತದೆ. ಅದೇ ಅವಧಿಯವರೆಗೆ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಲಾದ locks ಏಕಕಾಲಿಕ ಬರವಣಿಗೆಗಳನ್ನು (concurrent writers) ತಡೆಯುತ್ತವೆ ಮತ್ತು ನಿಷ್ಕ್ರಿಯವಾದ (idle) connection ಪೂಲ್ ಅನ್ನು ಖಾಲಿ ಮಾಡದೆ ಇರುವುದರಿಂದ, ಹೊಸ ಬಳಕೆದಾರರು ಖಾಲಿ ಇರುವ ಸ್ಲಾಟ್‌ಗಾಗಿ ಕಾಯಬೇಕಾಗುತ್ತದೆ.

ನಾಲ್ಕು ಅಲ್ಪಾವಧಿಯ ಮಾದರಿಗಳು

ಸ್ಥಿರತೆಯನ್ನು (consistency) ಪ್ರತಿ ಸಂಭಾಷಣೆಯ ಬದಲಾಗಿ ಪ್ರತಿ tool-call ನ ಕಾಳಜಿಯಾಗಿ ಪರಿಗಣಿಸಲು ಗೈಡ್ ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ. ಆ ನಾಲ್ಕು ಮಾದರಿಗಳು ಇಲ್ಲಿವೆ:

  1. Live statements – ಪ್ರತಿ ಕರೆಯು ಡಿಫಾಲ್ಟ್ isolation level ಅಡಿಯಲ್ಲಿ ಚಲಿಸುತ್ತದೆ, ಇದು ಕೇವಲ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಕ್ಷಣದಲ್ಲಿ commit ಆಗಿರುವ ಡೇಟಾವನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ. ಇದು ಸರಳವಾದ ಮಾದರಿಯಾಗಿದೆ; ಹಿಂದಿನ ಹಂತದಿಂದ ಡೇಟಾ ಬದಲಾಗಿರಬಹುದು ಎಂಬುದನ್ನು ಬಳಕೆದಾರರು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತಾರೆ.
  2. Bounded transactions – ಡೆವಲಪರ್ ಕೆಲವು ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳನ್ನು ಒಂದೇ ಸಣ್ಣ ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಒಳಗೆ ಗುಂಪು ಮಾಡುತ್ತಾರೆ, ಇದು ಮುಂದಿನ LLM ಹಂತಕ್ಕೆ ಮುನ್ನವೇ ಮುಕ್ತಾಯಗೊಳ್ಳುತ್ತದೆ. ಇದು tool call ನಂತರ ಉಳಿಯದೆ ಆ ಬ್ಯಾಚ್‌ಗೆ atomicity ಅನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.
  3. Snapshot reads – ಈ ಕಾರ್ಯಾಚರಣೆಯು ನಿರ್ದಿಷ್ಟ snapshot timestamp ನೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಇದು ಕರೆಯ ಅವಧಿಯವರೆಗೆ ಡೇಟಾಬೇಸ್‌ನ ಸ್ಥಿರ ನೋಟವನ್ನು ನೀಡುತ್ತದೆ. ಏಕಕಾಲಿಕ (concurrent) ಬರವಣಿಗೆಗಳು ನಡೆದರೂ ಸಹ, ಕರೆಯೊಳಗಿನ ಎಲ್ಲಾ ರೀಡ್‌ಗಳು ಒಂದೇ ಡೇಟಾವನ್ನು ನೋಡುತ್ತವೆ.
  4. Materialized reports – ಈ ಟೂಲ್ ಅರಿವಿನಲ್ಲಿರುವ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಮಯದ (cutoff point) ಡೇಟಾಬೇಸ್ ಸ್ಥಿತಿಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವ, ಮೊದಲೇ ಸಿದ್ಧಪಡಿಸಿದ, versioned result set ನಿಂದ ಡೇಟಾವನ್ನು ಓದುತ್ತದೆ. ನಂತರದ ಪೇಜಿನೇಷನ್ ಅಥವಾ ಹೆಚ್ಚಿನ ಲೆಕ್ಕಾಚಾರಗಳು ಆ ಸ್ಥಿರ ಡೇಟಾಸೆಟ್ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.

SQL Server ನಲ್ಲಿ, READ_COMMITTED_SNAPSHOT ಸಕ್ರಿಯವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಕೇವಲ ಹೆಸರನ್ನು ನೋಡಿ ನಿರ್ಧರಿಸಬೇಡಿ.

LLM-ಚಾಲಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ಪ್ರಾಯೋಗಿಕ ನಿಯಮಗಳು

  • Batch what you need – ಒಂದು ಪ್ರಶ್ನೆಗೆ ಅನೇಕ ಮೌಲ್ಯಗಳು ಬೇಕಾದಲ್ಲಿ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ಹೊಸ ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಪ್ರಾರಂಭಿಸುವ ಪ್ರತ್ಯೇಕ ಕ್ವೇರಿಗಳನ್ನು ಮಾಡುವ ಬದಲು, ಒಂದೇ tool call ನಲ್ಲಿ ಅವುಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ.
  • Deterministic pagination – ಫಲಿತಾಂಶಗಳನ್ನು ಪುಟಗಳ ಮೂಲಕ ಪ್ರಸ್ತುತಪಡಿಸುವಾಗ, ಸ್ಥಿರವಾದ ordering key, cursor ಅಥವಾ materialized result set ಅನ್ನು ಬಳಸಿ. ಬಳಕೆದಾರರು ಸ್ಕ್ರೋಲ್ ಮಾಡುವಾಗ ಎಂದಿಗೂ ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಅನ್ನು ತೆರೆದಿಡಬೇಡಿ.
  • Return evidence – ಡೇಟಾದ ಜೊತೆಗೆ, consistency ಮಾದರಿಯನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುವ metadata ಅನ್ನು ಸೇರಿಸಿ: consistency class, snapshot start time, reporting cutoff, data freshness, row count, database identity ಮತ್ತು trace ID.
  • Stress-test with concurrency – LLM ಪ್ರಾಂಪ್ಟ್ ಮಾಡುವಾಗ ಏಕಕಾಲಿಕ ಬರವಣಿಗೆಗಳನ್ನು (concurrent writes) ಅನುಕರಿಸುವ ಮೂಲಕ (simulate), ಅಪ್ಲಿಕೇಶನ್ ಸುಗಮವಾಗಿ ಮರುಪ್ರಯತ್ನಿಸುತ್ತದೆಯೇ ಅಥವಾ ಪರ್ಯಾಯ ಮಾರ್ಗವನ್ನು (fallback) ಅನುಸರಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.

ಅಂತಿಮ ತೀರ್ಮಾನ ಸ್ಪಷ್ಟವಾಗಿದೆ: AI ಚಾಟ್ ಡೇಟಾಬೇಸ್ ಟ್ರಾನ್ಸಾಕ್ಷನ್‌ನ ಜೀವಿತಾವಧಿಯನ್ನು ನಿರ್ಧರಿಸಬಾರದು. ಸ್ಥಿರತೆಯನ್ನು ಪ್ರತಿ tool call ಗೆ ಸೀಮಿತಗೊಳಿಸುವ ಮೂಲಕ, ಡೆವಲಪರ್‌ಗಳು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಆರೋಗ್ಯಕರವಾಗಿಡಬಹುದು, ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬಹುದು ಮತ್ತು LLM ಗೆ ನಿಖರವಾಗಿ ಉತ್ತರಿಸಲು ಸಾಕಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹ ಡೇಟಾವನ್ನು ನೀಡಬಹುದು.