ਦੋ AI ਏਜੰਟ ਇੱਕੋ ਫਾਈਲ ਨੂੰ ਐਡਿਟ ਕਰ ਸਕਦੇ ਹਨ, ਦੋਵਾਂ ਨੂੰ "success" ਦੀ ਪੁਸ਼ਟੀ ਮਿਲਦੀ ਹੈ, ਫਿਰ ਵੀ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ ਇੱਕ ਦੇ ਬਦਲਾਅ ਹੀ ਬਚਦੇ ਹਨ। ਪੰਜ ਸਮਾਂਵਰਤੀ (concurrent) ਏਜੰਟਾਂ ਦੇ ਇੱਕ ਸਧਾਰਨ ਟੈਸਟ ਵਿੱਚ, ਪੰਜ ਵਿੱਚੋਂ ਚਾਰ ਲਿਖਤਾਂ (writes) ਬਿਨਾਂ ਕਿਸੇ ਗਲਤੀ ਜਾਂ ਲੌਗ ਐਂਟਰੀ ਦੇ ਗਾਇਬ ਹੋ ਗਈਆਂ—ਇਹ ਇੱਕ ਕਲਾਸਿਕ ਲੌਸਟ-ਅਪਡੇਟ ਐਨੋਮਲੀ (lost-update anomaly) ਹੈ ਜੋ ਗਾਇਬ ਹੋਏ ਕੰਮ ਲਈ ਭੁਗਤਾਨ ਕੀਤੇ ਗਏ ਟੋਕਨਾਂ ਨੂੰ ਬਰਬਾਦ ਕਰਦੀ ਹੈ।
ਇਹ ਸਮੱਸਿਆ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਜਦੋਂ ਇੱਕ AI ਏਜੰਟ ਨਤੀਜਾ ਵਾਪਸ ਲਿਖਦਾ ਹੈ, ਤਾਂ ਅੰਡਰਲਾਈਂਗ ਸਰਵਿਸ ਬਣੇ ਹੋਏ ਹਰ ਟੋਕਨ ਲਈ ਚਾਰਜ ਕਰਦੀ ਹੈ। ਜੇਕਰ ਲਿਖਤ (write) ਚੁੱਪਚਾਪ ਓਵਰਰਾਈਟ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪ੍ਰੋਵਾਈਡਰ ਅਜੇ ਵੀ ਉਸ ਕੰਪਿਊਟੇਸ਼ਨ ਲਈ ਬਿੱਲ ਭੇਜਦਾ ਹੈ ਜਿਸਨੇ ਉਸ ਰੱਦ ਕੀਤੇ ਗਏ ਆਉਟਪੁੱਟ ਨੂੰ ਤਿਆਰ ਕੀਤਾ ਸੀ। ਮਲਟੀ-ਏਜੰਟ ਪਾਈਪਲਾਈਨਾਂ ਵਿੱਚ—ਜਿਵੇਂ ਕਿ ਏਜੰਟ ਸਵਾਰਮਜ਼ (agent swarms), ਪੈਰਲਲ ਡਾਟਾ-ਕਲੀਨਿੰਗ ਵਰਕਰ, ਜਾਂ ਕੋਈ ਵੀ ਅਜਿਹਾ ਸਿਸਟਮ ਜਿੱਥੇ ਕਈ ਬੋਟਸ ਇੱਕ ਸਾਂਝੀ ਪਲਾਨ ਫਾਈਲ ਜਾਂ ਸਕ੍ਰੈਚਪੈਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ—ਇਹ ਲੁਕਵੇਂ ਨੁਕਸਾਨ ਲਾਗਤ ਦੇ ਇੱਕ ਵੱਡੇ ਰਿਸਾਅ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ। ਇਹ ਐਨੋਮਲੀ ਡਾਟਾ ਦੀ ਅਖੰਡਤਾ (data integrity) ਲਈ ਵੀ ਖਤਰਾ ਪੈਦਾ ਕਰਦੀ ਹੈ: ਅਗਲੇ ਪੜਾਵਾਂ (downstream steps) ਵਿੱਚ ਅਧੂਰੀ ਜਾਂ ਪੁਰਾਣੀ ਜਾਣਕਾਰੀ ਦੇ ਅਧਾਰ 'ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਲੜੀਵਾਰ ਗਲਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਇਹ ਐਨੋਮਲੀ ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ
ਇਸਦਾ ਮੂਲ ਕਾਰਨ ਰੇਸ ਕੰਡੀਸ਼ਨ (race condition) ਹੈ:
- ਦੋ (ਜਾਂ ਵੱਧ) ਏਜੰਟ ਇੱਕੋ ਸਰੋਤ ਦਾ ਇੱਕੋ ਵਰਜ਼ਨ ਪੜ੍ਹਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਇੱਕ JSON ਪਲਾਨ ਫਾਈਲ।
- ਹਰੇਕ ਉਸ ਸਨੈਪਸ਼ੌਟ ਦੇ ਅਧਾਰ 'ਤੇ ਆਪਣੀ ਤਰਕ ਜਾਂ ਤਬਦੀਲੀ ਕਰਦਾ ਹੈ।
- ਦੋਵੇਂ ਏਜੰਟ ਸਾਂਝੇ ਸਟੋਰੇਜ 'ਤੇ ਵਾਪਸ ਲਿਖਣ (write operation) ਦੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ।
- ਸਟੋਰੇਜ ਸਿਸਟਮ ਦੂਜੀ ਲਿਖਤ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਟਕਰਾਅ (conflict) ਦੀ ਪਛਾਣ ਕੀਤੇ ਬਿਨਾਂ ਪਹਿਲੀ ਲਿਖਤ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਦਿੰਦਾ ਹੈ।
- ਦੋਵੇਂ ਏਜੰਟ ਇੱਕ “ACK” ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਜੋ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਲਿਖਤ ਸਫਲ ਰਹੀ, ਭਾਵੇਂ ਕਿ ਪਹਿਲਾ ਯੋਗਦਾਨ ਗਾਇਬ ਹੋ ਗਿਆ ਹੋਵੇ।
ਸਟੋਰੇਜ ਸਿਸਟਮ ਦੀ ਪੁਸ਼ਟੀ ਸਿਰਫ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਇੱਕ ਲਿਖਤ ਹੋਈ ਹੈ; ਇਹ ਇਸ ਗੱਲ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ ਕਿ ਉਹ ਲਿਖਤ ਹੋਰ ਸਮਾਂਵਰਤੀ ਅਪਡੇਟਾਂ ਦੇ ਮੁਕਾਬਲੇ ਸੁਰੱਖਿਅਤ ਸੀ। ਇੱਕ ਅਪੈਂਡ-ਓਨਲੀ ਲੌਗ (append-only log), ਜਿਸ ਨੂੰ ਅਕਸਰ ਸੁਰੱਖਿਆ ਵਜੋਂ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ, ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ: ਇਹ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਲਿਖਤ ਹੋਈ ਸੀ ਪਰ ਇਹ ਬਾਅਦ ਵਾਲੀਆਂ ਲਿਖਤਾਂ ਨੂੰ ਪਹਿਲਾਂ ਵਾਲੀਆਂ ਲਿਖਤਾਂ ਨੂੰ ਮਿਟਾਉਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ।
ਕੰਪੇਅਰ-ਐਂਡ-ਸੈੱਟ (CAS) ਗੇਟ ਕੀ ਕਰਦਾ ਹੈ
ਇੱਕ ਕੰਪੇਅਰ-ਐਂਡ-ਸੈੱਟ (CAS) ਗੇਟ ਲਿਖਤ ਸਵੀਕਾਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਵਰਜ਼ਨ ਚੈੱਕ ਜੋੜਦਾ ਹੈ:
- Read (ਪੜ੍ਹਨਾ): ਏਜੰਟ ਫਾਈਲ ਦਾ ਮੌਜੂਦਾ ਵਰਜ਼ਨ ਨੰਬਰ (ਜਾਂ ਹੈਸ਼) ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।
- Compute (ਗਣਨਾ ਕਰਨਾ): ਏਜੰਟ ਆਪਣਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਫਾਈਲ ਦਾ ਇੱਕ ਨਵਾਂ ਵਰਜ਼ਨ ਤਿਆਰ ਕਰਦਾ ਹੈ।
- Write (ਲਿਖਣਾ): ਏਜੰਟ ਨਵੀਂ ਸਮੱਗਰੀ ਨੂੰ ਉਸ ਵਰਜ਼ਨ ਦੇ ਨਾਲ ਭੇਜਦਾ ਹੈ ਜੋ ਉਸਨੇ ਅਸਲ ਵਿੱਚ ਪੜ੍ਹਿਆ ਸੀ।
- Validate (ਪੁਸ਼ਟੀ ਕਰਨਾ): ਸਟੋਰੇਜ ਲੇਅਰ ਦਿੱਤੇ ਗਏ ਵਰਜ਼ਨ ਦੀ ਮੌਜੂਦਾ ਵਰਜ਼ਨ ਨਾਲ ਤੁਲਨਾ ਕਰਦੀ ਹੈ। ਜੇਕਰ ਉਹ ਵੱਖਰੇ ਹਨ, ਤਾਂ ਲਿਖਤ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ; ਨਹੀਂ ਤਾਂ, ਇਹ ਅੱਗੇ ਵਧਦੀ ਹੈ ਅਤੇ ਵਰਜ਼ਨ ਨੂੰ ਵਧਾ ਦਿੰਦੀ ਹੈ।
ਜੇਕਰ ਵਰਜ਼ਨ ਬਦਲ ਗਿਆ ਹੈ, ਤਾਂ ਏਜੰਟ ਨੂੰ ਪਤਾ ਲੱਗ ਜਾਂਦਾ ਹੈ ਕਿ ਉਸਦਾ ਦੇਖਿਆ ਗਿਆ ਡਾਟਾ ਪੁਰਾਣਾ (stale) ਸੀ ਅਤੇ ਉਸਨੂੰ ਨਵੇਂ ਵਰਜ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੂਰੇ ਚੱਕਰ—ਪੜ੍ਹਨਾ, ਗਣਨਾ ਕਰਨਾ, ਲਿਖਣਾ—ਨੂੰ ਦੁਬਾਰਾ ਕਰਨਾ ਪਵੇਗਾ। ਇਹ ਇੱਕ ਅਦਿੱਖ ਓਵਰਰਾਈਟ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਅਸਫਲਤਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਲੌਗ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਅਤੇ ਜਿਸਦਾ ਹਿਸਾਬ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਸੁਰੱਖਿਆ ਦੀ ਕੀਮਤ
CAS ਗੇਟ ਮੁਫ਼ਤ ਨਹੀਂ ਹੈ। ਉਸੇ ਪੰਜ-ਏਜੰਟ ਸਿਮੂਲੇਸ਼ਨ ਵਿੱਚ:
| ਸਥਿਤੀ (Scenario) | ਕੋਸ਼ਿਸ਼ ਕੀਤੀਆਂ ਗਈਆਂ ਲਿਖਤਾਂ (Writes attempted) | ਸਫਲ ਯੋਗਦਾਨ (Successful contributions) | ਟੋਕਨ ਲਾਗਤ (Token cost) |
|---|---|---|---|
| ਬਿਨਾਂ CAS ਗੇਟ ਦੇ | 5 | 1 | 5 ਯੂਨਿਟ |
| CAS ਗੇਟ ਦੇ ਨਾਲ | 5 | 5 (ਰੀਟ੍ਰਾਈਜ਼ ਤੋਂ ਬਾਅਦ) | 9 ਯੂਨਿਟ |
ਗੇਟ ਉਹਨਾਂ ਏਜੰਟਾਂ ਲਈ ਵਾਧੂ ਰੀਡ-ਕੰਪਿਊਟ-ਰਾਈਟ ਚੱਕਰ ਜੋੜਦਾ ਹੈ ਜੋ ਵਰਜ਼ਨ ਟਕਰਾਅ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਟੋਕਨ ਖਰਚ ਵਧ ਜਾਂਦਾ ਹੈ। ਸਮਝੌਤਾ ਸਪਸ਼ਟ ਹੈ: ਗੇਟ ਤੋਂ ਬਿਨਾਂ ਤੁਸੀਂ ਚੁੱਪਚਾਪ ਡਾਟਾ ਗੁਆ ਲੈਂਦੇ ਹੋ; ਗੇਟ ਦੇ ਨਾਲ ਤੁਸੀਂ ਇੱਕ ਮਾਮੂਲੀ ਵਾਧੂ ਕੀਮਤ ਅਦਾ ਕਰਦੇ ਹੋ ਪਰ ਹਰ ਟਕਰਾਅ ਬਾਰੇ ਸਪਸ਼ਟਤਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ।
ਇਹ ਅਸਫਲਤਾ ਕਿੰਨੀ ਆਮ ਹੈ?
ਸਿਰਫ ਦੋ ਏਜੰਟਾਂ ਦੇ ਨਾਲ ਵੀ, ਟੈਸਟ ਨੇ ਦਿਖਾਇਆ ਕਿ 75% ਸੰਭਾਵਨਾ ਸੀ ਕਿ ਲਿਖਤਾਂ ਵਿੱਚੋਂ ਇੱਕ ਗੁਆਚ ਜਾਵੇਗੀ। ਪੰਜ ਏਜੰਟਾਂ ਦੇ ਨਾਲ, ਨੁਕਸਾਨ ਦੀ ਦਰ 100% ਦੇ ਨੇੜੇ ਪਹੁੰਚ ਗਈ। ਇਹ ਅੰਕੜੇ ਸੁਝਾਉਂਦੇ ਹਨ ਕਿ ਕਿਸੇ ਵੀ ਪ੍ਰੋਡਕਸ਼ਨ-ਲੇਵਲ ਮਲਟੀ-ਏਜੰਟ ਵਰਕਫਲੋ ਲਈ "ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਹੈ" ਮੰਨਣਾ ਇੱਕ ਖ਼ਤਰਨਾਕ ਅੰਦਾਜ਼ਾ ਹੈ।
ਵਿਰੋਧੀ ਦਲੀਲ: ਗੇਟ ਨੂੰ ਕਦੋਂ ਛੱਡਣਾ ਹੈ
ਜੇਕਰ ਕੋਈ ਸਿਸਟਮ ਹਰੇਕ ਸਰੋਤ ਲਈ ਇੱਕ ਸਿੰਗਲ ਏਜੰਟ ਚਲਾਉਂਦਾ ਹੈ ਜਾਂ ਉੱਚ ਪੱਧਰ 'ਤੇ ਸਖ਼ਤ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ (strict serialisation) ਲਾਗੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਵਾਧੂ CAS ਚੈੱਕਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਹਾਲਾਂਕਿ, ਜੋਖਮ ਦੀ ਗਣਨਾ ਵਿੱਚ ਅਸਫਲ ਕੰਮ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ ਦੀ ਲੁਕਵੀਂ ਲਾਗਤ ਅਤੇ ਡਾਟਾ ਗੁੰਮ ਹੋਣ ਦੇ ਸੰਭਾਵੀ ਪ੍ਰਭਾਵ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
- ਟੂਲਿੰਗ ਸਪੋਰਟ (Tooling support): ਅਜਿਹੇ ਸਟੋਰੇਜ API ਲੱਭੋ ਜੋ ਵਰਜ਼ਨ ਨੰਬਰ ਜਾਂ ETags ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਅਤੇ ਆਟੋਮੈਟਿਕ CAS ਆਪਰੇਸ਼ਨਾਂ ਦੀ ਸਹੂਲਤ ਦਿੰਦੇ ਹਨ।
- ਮੈਟ੍ਰਿਕਸ (Metrics): ਆਪਣੇ ਏਜੰਟਾਂ ਨੂੰ ਇਹ ਰਿਕਾਰਡ ਕਰਨ ਲਈ ਤਿਆਰ ਕਰੋ ਕਿ ਵਰਜ਼ਨ ਮਿਸਮੈਚ ਕਾਰਨ ਲਿਖਤ ਕਿੰਨੀ ਵਾਰ ਰੱਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਵਧ ਰਹੀ ਟਕਰਾਅ ਦੀ ਦਰ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਸਰੋਤਾਂ ਨੂੰ ਵਧਾਉਣ ਜਾਂ ਵਰਕਫਲੋ ਨੂੰ ਮੁੜ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
- ਰੀਟ੍ਰਾਈ ਰਣਨੀਤੀਆਂ (Retry strategies): ਸਧਾਰਨ ਐਕਸਪੋਨੈਂਸ਼ੀਅਲ ਬੈਕ-ਆਫ (exponential back-off) ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਧਿਆਨ ਰੱਖੋ ਕਿ ਵਾਰ-ਵਾਰ ਰੀਟ੍ਰਾਈ ਕਰਨ ਨਾਲ ਟੋਕਨ ਦੀ ਖਪਤ ਵਧਦੀ ਹੈ। ਰੀਟ੍ਰਾਈ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਤੇ ਡਾਟਾ ਨੁਕਸਾਨ ਦੇ ਸਵੀਕਾਰਯੋਗ ਪੱਧਰ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਬਣਾਓ।
- ਹਾਈਬ੍ਰਿਡ ਪਹੁੰਚਾਂ (Hybrid approaches): ਕੁਝ ਟੀਮਾਂ ਆਡਿਟੇਬਿਲਟੀ ਲਈ ਅਪੈਂਡ-ਓਨਲੀ ਲੌਗ ਅਤੇ ਇਕਸਾਰਤਾ ਲਈ CAS ਗੇਟ ਨੂੰ ਮਿਲਾਉਂਦੀਆਂ ਹਨ, ਜੋ ਕਿ ਕੀ ਹੋਇਆ ਉਸਦਾ ਰਿਕਾਰਡ ਅਤੇ ਓਵਰਰਾਈਟ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਦੋਵੇਂ ਯਕੀਨੀ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਸਿੱਖਿਆ (Takeaway)
ਲੌਸਟ-ਅਪਡੇਟ ਅਨੋਮਲੀਆਂ (Lost-update anomalies) ਟੋਕਨ-ਅਧਾਰਿਤ AI ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਪੈਸੇ ਦੀ ਬਰਬਾਦੀ ਵਾਲੇ ਬਲੈਕ ਹੋਲ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ 'ਕੰਪੇਅਰ-ਐਂਡ-ਸੈੱਟ' (compare-and-set) ਵਰਜ਼ਨ ਗੇਟ ਥੋੜ੍ਹਾ ਜਿਹਾ ਟੋਕਨ ਵਾਧਾ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਚੁੱਪਚਾਪ ਹੋਣ ਵਾਲੇ ਡੇਟਾ ਨੁਕਸਾਨ ਨੂੰ ਇੱਕ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾ ਸਕਣ ਵਾਲੀ ਘਟਨਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਸਿਸਟਮ ਲਈ ਜਿੱਥੇ ਕਈ ਏਜੰਟ ਸਟੇਟ ਸਾਂਝੀ ਕਰਦੇ ਹਨ—ਜਿਵੇਂ ਕਿ ਡੇਟਾਬੇਸ, ਪਲਾਨ ਫਾਈਲਾਂ, ਜਾਂ ਸਕ੍ਰੈਚਪੈਡਸ—ਲਿਖਣ (writes) ਤੋਂ ਪਹਿਲਾਂ ਵਰਜ਼ਨ ਚੈੱਕ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਲੁਕਵੇਂ ਖਰਚਿਆਂ ਅਤੇ ਖਰਾਬ ਵਰਕਫਲੋਜ਼ ਵਿਰੁੱਧ ਸਭ ਤੋਂ ਸਸਤੀ ਬੀਮਾ ਹੈ।