ਇੱਕ ਡਿਵੈਲਪਰ ਗਾਈਡ ਚੇਤਾਵਨੀ ਦਿੰਦੀ ਹੈ ਕਿ AI-ਅਧਾਰਿਤ ਚੈਟ ਦੀ ਮਿਆਦ ਲਈ ਡੇਟਾਬੇਸ ਟ੍ਰਾਂਜੈਕਸ਼ਨ (transaction) ਨੂੰ ਖੁੱਲ੍ਹਾ ਰੱਖਣ ਨਾਲ ਜਵਾਬ ਗਲਤ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਅੰਡਰਲਾਈਂਗ DBMS ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਨੋਟ, LLM-ਅਧਾਰਿਤ ਟੂਲ ਬਣਾਉਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ ਹੈ, ਜਿਸ ਵਿੱਚ ਕਿਹਾ ਗਿਆ ਹੈ ਕਿ ਇਹ ਅਭਿਆਸ "ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ" ਅਤੇ ਇਸ ਦੀ ਬਜਾਏ ਚਾਰ ਛੋਟੇ ਸਮੇਂ ਦੇ ਇਕਸਾਰਤਾ ਪੈਟਰਨ (consistency patterns) ਦੀ ਪੇਸ਼ਕਸ਼ ਕੀਤੀ ਗਈ ਹੈ।

ਇਹ ਚੇਤਾਵਨੀ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

LLM-ਪਾਵਰਡ ਸਹਾਇਕ ਅਕਸਰ ਫਾਲੋ-ਅੱਪ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲੜੀ ਪੁੱਛਦੇ ਹਨ: ਉਹ ਇੱਕ ਰਿਕਾਰਡ ਪੜ੍ਹਦੇ ਹਨ, ਇੱਕ ਵੇਰਵਾ ਮੰਗਦੇ ਹਨ, ਫਿਰ ਕੁੱਲ ਜੋੜ (total) ਲਈ ਪੁੱਛਦੇ ਹਨ। ਜੇਕਰ ਉਹਨਾਂ ਕਦਮਾਂ ਦੇ ਵਿਚਕਾਰ ਅੰਡਰਲਾਈਂਗ ਡੇਟਾ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਹਾਇਕ ਵਿਰੋਧੀ ਤੱਥਾਂ ਵਾਲੇ ਅੰਕੜੇ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ—ਇੱਕ ਜਵਾਬ ਗਲਤ ਹੋਵੇਗਾ। ਇਸਦਾ ਇੱਕ ਲਾਲਚੀ ਹੱਲ ਇਹ ਹੈ ਕਿ ਗੱਲਬਾਤ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਇੱਕ ਸਿੰਗਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਖੋਲ੍ਹੀ ਜਾਵੇ ਅਤੇ ਚੈਟ ਖਤਮ ਹੋਣ ਤੱਕ ਇਸਨੂੰ ਜਿਉਂਦਾ ਰੱਖਿਆ ਜਾਵੇ। ਅਸਲ ਵਿੱਚ, ਉਹ ਪਹੁੰਚ row versions ਨੂੰ ਰੋਕ ਲੈਂਦੀ ਹੈ, tempdb ਨੂੰ ਭਰ ਦਿੰਦੀ ਹੈ, locks ਨੂੰ ਫੜ ਕੇ ਰੱਖਦੀ ਹੈ, ਅਤੇ connection pooling ਵਿੱਚ ਦਖਲ ਦਿੰਦੀ ਹੈ।

ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੀਆਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦੇ ਕਾਰਨ ਕੀ ਹਨ

  • Multi-turn prompting – LLMs ਆਮ ਤੌਰ 'ਤੇ ਉਪਭੋਗਤਾ ਦੇ ਜਵਾਬ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਕਈ ਪ੍ਰੋਂਪਟ ਤਿਆਰ ਕਰਦੇ ਹਨ।
  • Tool calls that hit the database – ਹਰ ਵਾਰ (turn) ਇੱਕ stored procedure, ਇੱਕ SELECT, ਜਾਂ ਇੱਕ UPDATE ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ।
  • Uncontrolled transaction scope – ਡਿਵੈਲਪਰ ਕਈ ਵਾਰ ਇਹ ਮੰਨ ਕੇ ਕਿ ਇਹ ਇਕਸਾਰਤਾ (consistency) ਦੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ, ਪੂਰੀ ਚੈਟ ਨੂੰ BEGIN…COMMIT ਬਲਾਕ ਵਿੱਚ ਰੱਖ ਦਿੰਦੇ ਹਨ।

ਜਦੋਂ ਚੈਟ ਲੰਬੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ DB engine ਨੂੰ ਅਸਲ row versions ਨੂੰ ਸੰਭਾਲਣਾ ਪੈਂਦਾ ਹੈ ਤਾਂ ਜੋ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਇੱਕ ਸਥਿਰ ਦ੍ਰਿਸ਼ (stable view) ਦੇਖ ਸਕੇ। ਉਹ versions tempdb ਵਿੱਚ ਬੈਠਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਸਪੇਸ ਅਤੇ I/O ਦੀ ਵਰਤੋਂ ਹੁੰਦੀ ਹੈ। ਇੱਕੋ ਸਮੇਂ ਲਈ ਫੜੇ ਗਏ locks ਹੋਰ ਲਿਖਣ ਵਾਲਿਆਂ (concurrent writers) ਨੂੰ ਰੋਕਦੇ ਹਨ, ਅਤੇ ਖਾਲੀ (idle) ਕਨੈਕਸ਼ਨ ਪੂਲ ਨੂੰ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਨਵੇਂ ਕਾਲਰਾਂ ਨੂੰ ਖਾਲੀ ਸਲਾਟ ਲਈ ਉਡੀਕ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।

ਚਾਰ ਛੋਟੇ ਸਮੇਂ ਦੇ ਪੈਟਰਨ

ਗਾਈਡ ਇਹ ਸਿਫਾਰਸ਼ ਕਰਦੀ ਹੈ ਕਿ ਇਕਸਾਰਤਾ (consistency) ਨੂੰ ਪੂਰੀ ਗੱਲਬਾਤ ਦੀ ਬਜਾਏ ਹਰੇਕ tool-call ਦੇ ਸੰਬੰਧ ਵਿੱਚ ਦੇਖਿਆ ਜਾਵੇ। ਚਾਰ ਪੈਟਰਨ ਇਹ ਹਨ:

  1. Live statements – ਹਰੇਕ ਕਾਲ ਡਿਫੌਲਟ isolation level ਦੇ ਅਧੀਨ ਚੱਲਦੀ ਹੈ, ਅਤੇ ਸਿਰਫ ਉਸੇ ਡੇਟਾ ਨੂੰ ਦੇਖਦੀ ਹੈ ਜੋ ਕਾਰਜਕਾਰੀ (execution) ਦੇ ਸਮੇਂ ਕਮਿਟ (committed) ਕੀਤਾ ਗਿਆ ਹੋਵੇ। ਇਹ ਸਭ ਤੋਂ ਸਰਲ ਮਾਡਲ ਹੈ; ਕਾਲਰ ਇਹ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਕਿ ਪਿਛਲੇ ਵਾਰ (turn) ਤੋਂ ਡੇਟਾ ਬਦਲ ਸਕਦਾ ਹੈ।
  2. Bounded transactions – ਇੱਕ ਡਿਵੈਲਪਰ ਕੁਝ ਸਟੇਟਮੈਂਟਾਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਛੋਟੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੇ ਅੰਦਰ ਗਰੁੱਪ ਕਰਦਾ ਹੈ ਜੋ ਅਗਲੇ LLM turn ਤੋਂ ਪਹਿਲਾਂ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਹ tool call ਤੋਂ ਬਾਅਦ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਰੁਕੇ ਬਿਨਾਂ ਉਸ ਬੈਚ ਲਈ atomicity ਦੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ।
  3. Snapshot reads – ਆਪਰੇਸ਼ਨ ਇੱਕ ਨਿਰਧਾਰਤ snapshot timestamp ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਜੋ ਕਾਲ ਦੀ ਮਿਆਦ ਲਈ ਡੇਟਾਬੇਸ ਦਾ ਇੱਕ ਸਥਿਰ ਦ੍ਰਿਸ਼ ਦਿੰਦਾ ਹੈ। ਕਾਲ ਦੇ ਅੰਦਰ ਸਾਰੇ ਰੀਡਸ (reads) ਇੱਕੋ ਡੇਟਾ ਦੇਖਦੇ ਹਨ, ਭਾਵੇਂ ਕਿ ਇੱਕੋ ਸਮੇਂ ਹੋਣ ਵਾਲੇ ਲਿਖਣ (concurrent writes) ਕਿਉਂ ਨਾ ਹੋਣ।
  4. Materialized reports – ਟੂਲ ਇੱਕ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ ਕੀਤੇ ਗਏ, versioned result set ਤੋਂ ਪੜ੍ਹਦਾ ਹੈ ਜੋ ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ cutoff point 'ਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਪੇਜਨੇਸ਼ਨ (Pagination) ਜਾਂ ਹੋਰ ਗਣਨਾਵਾਂ ਫਿਰ ਉਸ ਫ੍ਰੀਜ਼ ਕੀਤੇ ਡੇਟਾਸੈੱਟ 'ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।

SQL Server ਵਿੱਚ, ਚੈੱਕ ਕਰੋ ਕਿ ਕੀ READ_COMMITTED_SNAPSHOT ਐਕਟਿਵ ਹੈ। ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਨਾਮ ਹੀ ਸਾਰੀ ਕਹਾਣੀ ਦੱਸਦਾ ਹੈ।

LLM-ਅਧਾਰਿਤ ਐਪਸ ਲਈ ਵਿਵਹਾਰਕ ਨਿਯਮ

  • Batch what you need – ਜੇਕਰ ਕਿਸੇ ਸਵਾਲ ਲਈ ਕਈ ਮੁੱਲਾਂ (values) ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਵੱਖ-ਵੱਖ ਕੁਐਰੀਆਂ (queries) ਜਾਰੀ ਕਰਨ ਦੀ ਬਜਾਏ ਜੋ ਹਰੇਕ ਇੱਕ ਨਵੀਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ tool call ਵਿੱਚ ਕੰਪਿਊਟ ਕਰੋ।
  • Deterministic pagination – ਪੇਜਾਂ ਵਿੱਚ ਨਤੀਜੇ ਪੇਸ਼ ਕਰਦੇ ਸਮੇਂ, ਇੱਕ ਸਥਿਰ ordering key, ਇੱਕ cursor, ਜਾਂ ਇੱਕ materialized result set ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜਦੋਂ ਉਪਭੋਗਤਾ ਸਕ੍ਰੋਲ ਕਰਦਾ ਹੈ ਤਾਂ ਕਦੇ ਵੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਖੁੱਲ੍ਹਾ ਨਾ ਰੱਖੋ।
  • Return evidence – ਡੇਟਾ ਦੇ ਨਾਲ-ਨਾਲ, ਅਜਿਹਾ ਮੈਟਾਡਾਟਾ (metadata) ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਇਕਸਾਰਤਾ ਮਾਡਲ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ: consistency class, snapshot start time, reporting cutoff, data freshness, row count, database identity, ਅਤੇ ਇੱਕ trace ID।
  • Stress-test with concurrency – ਜਦੋਂ LLM ਪ੍ਰੋਂਪਟ ਕਰ ਰਿਹਾ ਹੋਵੇ ਤਾਂ concurrent writes ਦਾ ਸਿਮੂਲੇਸ਼ਨ ਕਰੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ ਜਾਂ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਫਾਲਬੈਕ (fallback) ਕਰਦੀ ਹੈ।

ਅੰਤ ਵਿੱਚ ਗੱਲ ਸਪਸ਼ਟ ਹੈ: ਇੱਕ AI ਚੈਟ ਨੂੰ ਡੇਟਾਬੇਸ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੀ ਉਮਰ ਤੈਅ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ। ਹਰੇਕ tool call ਤੱਕ ਇਕਸਾਰਤਾ ਨੂੰ ਸੀਮਤ ਕਰਕੇ, ਡਿਵੈਲਪਰ ਡੇਟਾਬੇਸ ਨੂੰ ਸਿਹਤਮੰਦ ਰੱਖਦੇ ਹਨ, ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਪ੍ਰਦਰਸ਼ਨ (performance) ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਵੀ LLM ਨੂੰ ਸਹੀ ਜਵਾਬ ਦੇਣ ਲਈ ਕਾਫ਼ੀ ਭਰੋਸੇਯੋਗ ਡੇਟਾ ਦਿੰਦੇ ਹਨ।