AI-ఆధారిత చాట్ సమయమంతా డేటాబేస్ ట్రాన్సాక్షన్ను (database transaction) తెరిచి ఉంచడం వల్ల సమాధానాలు తప్పుగా మారే అవకాశం ఉందని మరియు అది అండర్లయింగ్ DBMSని స్తంభింపజేస్తుందని ఒక డెవలపర్ గైడ్ హెచ్చరిస్తోంది. LLM-ఆధారిత సాధనాలను (tools) రూపొందిస్తున్న బృందాలను ఉద్దేశించి రాసిన ఈ నోట్లో, ఈ పద్ధతిని "చేయకూడదు" అని చెబుతూ, దానికి బదులుగా నాలుగు స్వల్పకాలిక కన్సిస్టెన్సీ పద్ధతులను (consistency patterns) సూచించింది.
ఈ హెచ్చరిక ఎందుకు ముఖ్యమైనది
LLM-ఆధారిత అసిస్టెంట్లు తరచుగా వరుసగా ఫాలో-అప్ ప్రశ్నలను అడుగుతుంటాయి: అవి ఒక రికార్డును చదువుతాయి, ఒక వివరానికి రిక్వెస్ట్ చేస్తాయి, ఆపై మొత్తాన్ని (total) అడుగుతాయి. ఆ దశల మధ్య డేటా మారితే, అసిస్టెంట్ పరస్పర విరుద్ధమైన గణాంకాలను చూపవచ్చు—అంటే ఒక సమాధానం తప్పు అవుతుంది. దీనికి సులభమైన పరిష్కారం ఏమిటంటే, సంభాషణ ప్రారంభంలోనే ఒకే ట్రాన్సాక్షన్ను ప్రారంభించి, చాట్ ముగిసే వరకు దానిని అలాగే ఉంచడం. కానీ వాస్తవానికి, ఈ పద్ధతి వల్ల row versions నిల్వ చేయబడతాయి, tempdb నిండిపోతుంది, లాక్స్ (locks) పట్టుకోబడతాయి మరియు కనెక్షన్ పూలింగ్కు అంతరాయం కలుగుతుంది.
దీర్ఘకాలిక ట్రాన్సాక్షన్లకు దారితీసే అంశాలు
- మల్టీ-టర్న్ ప్రాంప్టింగ్ (Multi-turn prompting) – వినియోగదారునికి స్పందన కనిపించకముందే LLMలు సాధారణంగా అనేక ప్రాంప్ట్లను రూపొందిస్తాయి.
- డేటాబేస్ను ప్రభావితం చేసే టూల్ కాల్స్ (Tool calls that hit the database) – ప్రతి టర్న్ ఒక stored procedure, SELECT లేదా UPDATEని పిలవవచ్చు.
- నియంత్రితం లేని ట్రాన్సాక్షన్ స్కోప్ (Uncontrolled transaction scope) – కన్సిస్టెన్సీ లభిస్తుందని భావించి, డెవలపర్లు కొన్నిసార్లు మొత్తం చాట్ను ఒకే BEGIN…COMMIT బ్లాక్లో ఉంచుతారు.
చాట్ సమయం పెరిగేకొద్దీ, ట్రాన్సాక్షన్ స్థిరమైన వ్యూ (stable view) చూడటం కోసం DB ఇంజిన్ అసలు row versionsలను నిల్వ చేయాల్సి ఉంటుంది. ఆ వెర్షన్లు tempdbలో ఉండి, స్పేస్ మరియు I/Oని వినియోగిస్తాయి. అదే సమయంలో పట్టుకోబడిన లాక్స్ (locks), ఇతర రైటర్లను (writers) అడ్డుకుంటాయి మరియు ఖాళీగా ఉన్న కనెక్షన్ పూల్ను (connection pool) ఖాళీ చేయకుండా నిలిపివేసి, కొత్త కాల్స్ కోసం వేచి ఉండేలా చేస్తుంది.
నాలుగు స్వల్పకాలిక పద్ధతులు
కన్సిస్టెన్సీని మొత్తం సంభాషణకు కాకుండా, ప్రతి టూల్-కాల్కు (per-tool-call) సంబంధించిన అంశంగా పరిగణించాలని ఈ గైడ్ సిఫార్సు చేస్తోంది. ఆ నాలుగు పద్ధతులు ఇవే:
- లైవ్ స్టేట్మెంట్స్ (Live statements) – ప్రతి కాల్ డిఫాల్ట్ ఐసోలేషన్ లెవల్ (default isolation level) కింద నడుస్తుంది, ఇది అమలు చేసే సమయంలో కమిట్ చేయబడిన డేటాను మాత్రమే చూస్తుంది. ఇది అత్యంత సరళమైన నమూనా; మునుపటి టర్న్ నుండి డేటా మారవచ్చని వినియోగదారుడు అంగీకరిస్తారు.
- బౌండెడ్ ట్రాన్సాక్షన్స్ (Bounded transactions) – డెవలపర్ కొన్ని స్టేట్మెంట్లను ఒకే చిన్న ట్రాన్సాక్షన్లో సమూహీకరిస్తారు, ఇది తదుపరి LLM టర్న్ రాకముందే ముగుస్తుంది. ఇది టూల్ కాల్ దాటి కొనసాగకుండా, ఆ బ్యాచ్కు అటామిసిటీని (atomicity) హామీ ఇస్తుంది.
- స్నాప్షాట్ రీడ్స్ (Snapshot reads) – ఈ ఆపరేషన్ ఒక నిర్దిష్ట స్నాప్షాట్ టైమ్స్టాంప్తో ప్రారంభమవుతుంది, ఇది కాల్ సమయమంతా డేటాబేస్కు స్థిరమైన వ్యూను అందిస్తుంది. సమాంతరంగా రైటింగ్ (concurrent writes) జరుగుతున్నప్పటికీ, కాల్ లోపల జరిగే అన్ని రీడ్స్ ఒకే డేటాను చూస్తాయి.
- మెటీరియలైజ్డ్ రిపోర్ట్స్ (Materialized reports) – టూల్ ఒక ముందే రూపొందించబడిన, వెర్షన్ చేయబడిన రిజల్ట్ సెట్ నుండి డేటాను చదువుతుంది, ఇది ఒక నిర్దిష్ట సమయానికి డేటాబేస్ స్థితిని ప్రతిబింబిస్తుంది. ఆ తర్వాత పేజినేషన్ లేదా ఇతర గణనలు ఆ ఫ్రోజన్ (frozen) డేటాసెట్పై జరుగుతాయి.
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) జరిగేలా చేసి, అప్లికేషన్ మళ్ళీ ప్రయత్నిస్తుందో (retry) లేదా తప్పులు లేకుండా తదుపరి దశకు వెళ్తుందో (fallback) తనిఖీ చేయండి.
ముగింపు స్పష్టంగా ఉంది: ఒక AI చాట్ డేటాబేస్ ట్రాన్సాక్షన్ యొక్క జీవితకాలాన్ని నిర్ణయించకూడదు. కన్సిస్టెన్సీని ప్రతి టూల్ కాల్కు పరిమితం చేయడం ద్వారా, డెవలపర్లు డేటాబేస్ను ఆరోగ్యంగా ఉంచుతారు, వినియోగదారులందరికీ పనితీరును (performance) కాపాడతారు మరియు LLM ఖచ్చితంగా సమాధానం ఇవ్వడానికి తగినంత నమ్మదగిన డేటాను అందిస్తారు.