ಇಬ್ಬರು AI ಏಜೆಂಟ್ಗಳು ಒಂದೇ ಫೈಲ್ ಅನ್ನು ಎಡಿಟ್ ಮಾಡಬಹುದು, ಇಬ್ಬರಿಗೂ “success” ಎಂಬ ಅಕ್ನಾಲೆಡ್ಜ್ಮೆಂಟ್ (acknowledgment) ಸಿಗಬಹುದು, ಆದರೂ ಕೇವಲ ಒಬ್ಬರ ಬದಲಾವಣೆ ಮಾತ್ರ ಉಳಿಯುತ್ತದೆ. ಐದು ಏಜೆಂಟ್ಗಳಿರುವ ಸರಳ ಪರೀಕ್ಷೆಯಲ್ಲಿ, ಐದರಲ್ಲಿ ನಾಲ್ಕು ಬರವಣಿಗೆಗಳು ಯಾವುದೇ ದೋಷ ಅಥವಾ ಲಾಗ್ ಎಂಟ್ರಿ ಇಲ್ಲದೆ ಮಾಯವಾದವು—ಇದು ಕ್ಲಾಸಿಕ್ “lost-update anomaly” ಆಗಿದ್ದು, ಮಾಯವಾದ ಕೆಲಸಕ್ಕಾಗಿ ಪಾವತಿಸಿದ ಟೋಕನ್ಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.
ಈ ಸಮಸ್ಯೆಯ ಪ್ರಾಮುಖ್ಯತೆ
ಒಂದು AI ಏಜೆಂಟ್ ಫಲಿತಾಂಶವನ್ನು ಬರೆಯುವಾಗ, ಅಡಿಯಲ್ಲಿರುವ ಸೇವೆ ಜನರೇಟ್ ಆದ ಪ್ರತಿ ಟೋಕನ್ಗೆ ಶುಲ್ಕ ವಿಧಿಸುತ್ತದೆ. ಬರವಣಿಗೆಯನ್ನು ಮೌನವಾಗಿ ಓವರ್ರೈಟ್ (overwrite) ಮಾಡಿದರೂ, ವಜಾ ಮಾಡಲಾದ ಔಟ್ಪುಟ್ ಅನ್ನು ಉತ್ಪಾದಿಸಿದ ಕಂಪ್ಯೂಟೇಶನ್ಗಾಗಿ ಪ್ರೊವೈಡರ್ ಶುಲ್ಕವನ್ನು ವಿಧಿಸುತ್ತಲೇ ಇರುತ್ತಾರೆ. ಮಲ್ಟಿ-ಏಜೆಂಟ್ ಪೈಪ್ಲೈನ್ಗಳಲ್ಲಿ—ಏಜೆಂಟ್ ಸ್ವರ್ಮ್ಗಳು (agent swarms), ಸಮಾಂತರ ಡೇಟಾ-ಕ್ಲೀನಿಂಗ್ ವರ್ಕರ್ಸ್ ಅಥವಾ ಹಲವಾರು ಬಾಟ್ಗಳು ಪ್ಲಾನ್ ಫೈಲ್ ಅಥವಾ ಸ್ಕ್ರ್ಯಾಚ್ಪ್ಯಾಡ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ—ಈ ಗುಪ್ತ ನಷ್ಟಗಳು ದೊಡ್ಡ ಮಟ್ಟದ ವೆಚ್ಚದ ಸೋರಿಕೆಯಾಗಿ (cost leak) ಪರಿಣಮಿಸಬಹುದು. ಈ ಅನಾಮಧೇಯತೆಯು ಡೇಟಾ ಸಮಗ್ರತೆಯನ್ನೂ (data integrity) ಬೆದರಿಸುತ್ತದೆ: ಮುಂದಿನ ಹಂತಗಳು ಅಪೂರ್ಣ ಅಥವಾ ಹಳೆಯ ಮಾಹಿತಿಯ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು, ಇದು ಸರಣಿ ದೋಷಗಳಿಗೆ (cascading errors) ಕಾರಣವಾಗಬಹುದು.
ಈ ಅನಾಮಧೇಯತೆ ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ
ಇದರ ಮೂಲ ಕಾರಣ race condition:
- ಇಬ್ಬರು (ಅಥವಾ ಹೆಚ್ಚಿನ) ಏಜೆಂಟ್ಗಳು ಸಂಪನ್ಮೂಲದ ಒಂದೇ ಆವೃತ್ತಿಯನ್ನು (ಉದಾಹರಣೆಗೆ, ಒಂದು JSON ಪ್ಲಾನ್ ಫೈಲ್) ಓದುತ್ತಾರೆ.
- ಪ್ರತಿಯೊಬ್ಬರೂ ಆ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಆಧಾರದ ಮೇಲೆ ತಮ್ಮದೇ ಆದ ತರ್ಕ ಅಥವಾ ರೂಪಾಂತರವನ್ನು (transformation) ಮಾಡುತ್ತಾರೆ.
- ಎರಡೂ ಏಜೆಂಟ್ಗಳು ಹಂಚಿಕೆಯ ಸ್ಟೋರೇಜ್ಗೆ ಬರವಣಿಗೆಯ ಕಾರ್ಯಾಚರಣೆಯನ್ನು (write operation) ನೀಡುತ್ತವೆ.
- ಸ್ಟೋರೇಜ್ ಸಿಸ್ಟಮ್ ಯಾವುದೇ ಸಂಘರ್ಷ ಪತ್ತೆಹಚ್ಚದೆ (conflict detection) ಎರಡನೇ ಬರವಣಿಗೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಮೊದಲ ಬರವಣಿಗೆಯನ್ನು ಓವರ್ರೈಟ್ ಮಾಡುತ್ತದೆ.
- ಮೊದಲ ಕೊಡುಗೆ ಮಾಯವಾದರೂ ಸಹ, ಎರಡೂ ಏಜೆಂಟ್ಗಳಿಗೆ ಬರವಣಿಗೆ ಯಶಸ್ವಿಯಾಗಿದೆ ಎಂದು ದೃಢೀಕರಿಸುವ “ACK” ಸಿಗುತ್ತದೆ.
ಸ್ಟೋರೇಜ್ ಸಿಸ್ಟಮ್ನ ಅಕ್ನಾಲೆಡ್ಜ್ಮೆಂಟ್ ಬರವಣಿಗೆ ನಡೆದಿದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಅದು ಇತರ ಏಕಕಾಲಿಕ ಅಪ್ಡೇಟ್ಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಬರವಣಿಗೆ ಸುರಕ್ಷಿತವಾಗಿದೆ ಎಂದು ಖಾತರಿ ನೀಡುವುದಿಲ್ಲ. ರಕ್ಷಣೆಗಾಗಿ ಬಳಸಲಾಗುವ append-only log ಕೂಡ ಇದೇ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ: ಇದು ಬರವಣಿಗೆ ನಡೆದಿದೆ ಎಂದು ದಾಖಲಿಸುತ್ತದೆ ಆದರೆ ನಂತರದ ಬರವಣಿಗೆಗಳು ಹಿಂದಿನವುಗಳನ್ನು ಅಳಿಸಿಹಾಕದಂತೆ ತಡೆಯುವುದಿಲ್ಲ.
"compare-and-set" (CAS) ಗೇಟ್ ಏನು ಮಾಡುತ್ತದೆ
ಒಂದು compare-and-set (CAS) ಗೇಟ್ ಬರವಣಿಗೆಯನ್ನು ಸ್ವೀಕರಿಸುವ ಮೊದಲು ಆವೃತ್ತಿ ಪರಿಶೀಲನೆಯನ್ನು (version check) ಸೇರಿಸುತ್ತದೆ:
- Read: ಏಜೆಂಟ್ ಫೈಲ್ನ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿ ಸಂಖ್ಯೆಯನ್ನು (ಅಥವಾ hash) ಪಡೆಯುತ್ತದೆ.
- Compute: ಏಜೆಂಟ್ ತನ್ನ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಫೈಲ್ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
- Write: ಏಜೆಂಟ್ ತಾನು ಮೂಲತಃ ಓದಿದ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಹೊಸ ವಿಷಯವನ್ನು ಕಳುಹಿಸುತ್ತದೆ.
- Validate: ಸ್ಟೋರೇಜ್ ಲೇಯರ್ ಒದಗಿಸಿದ ಆವೃತ್ತಿಯನ್ನು ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ. ಅವುಗಳು ಭಿನ್ನವಾಗಿದ್ದರೆ, ಬರವಣಿಗೆಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ; ಇಲ್ಲದಿದ್ದರೆ, ಅದು ಮುಂದುವರಿಯುತ್ತದೆ ಮತ್ತು ಆವೃತ್ತಿಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
ಆವೃತ್ತಿಯು ಬದಲಾಗಿದ್ದರೆ, ತನ್ನ ಮಾಹಿತಿ ಹಳೆಯದಾಗಿದೆ ಎಂದು ಏಜೆಂಟ್ಗೆ ತಿಳಿಯುತ್ತದೆ ಮತ್ತು ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಿ ಇಡೀ ಚಕ್ರವನ್ನು—ಓದು, ಕಂಪ್ಯೂಟ್, ಬರೆಯುವುದು—ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬೇಕಾಗುತ್ತದೆ. ಇದು ಅದೃಶ್ಯ ಓವರ್ರೈಟ್ ಅನ್ನು ಲಾಗ್ ಮಾಡಬಹುದಾದ, ಮರುಪ್ರಯತ್ನ ಮಾಡಬಹುದಾದ ಮತ್ತು ಲೆಕ್ಕಬಾக்கி ಇಡಬಹುದಾದ ಸ್ಪಷ್ಟ ವೈಫಲ್ಯವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
ಸುರಕ್ಷತೆಯ ಬೆಲೆ
CAS ಗೇಟ್ ಉಚಿತವಾಗಿ ಸಿಗುವುದಿಲ್ಲ. ಅದೇ ಐದು-ಏಜೆಂಟ್ ಸಿಮ್ಯುಲೇಶನ್ನಲ್ಲಿ:
| ಸನ್ನಿವೇಶ (Scenario) | ಪ್ರಯತ್ನಿಸಿದ ಬರವಣಿಗೆಗಳು (Writes attempted) | ಯಶಸ್ವಿ ಕೊಡುಗೆಗಳು (Successful contributions) | ಟೋಕನ್ ವೆಚ್ಚ (Token cost) |
|---|---|---|---|
| No CAS gate | 5 | 1 | 5 units |
| With CAS gate | 5 | 5 (ಮರುಪ್ರಯತ್ನಗಳ ನಂತರ) | 9 units |
ಆವೃತ್ತಿ ಸಂಘರ್ಷವನ್ನು ಎದುರಿಸುವ ಏಜೆಂಟ್ಗಳಿಗಾಗಿ ಗೇಟ್ ಹೆಚ್ಚುವರಿ read-compute-write ಚಕ್ರಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ಇದರಿಂದ ಟೋಕನ್ ಬಳಕೆಯು ಹೆಚ್ಚಾಗುತ್ತದೆ. ಇಲ್ಲಿನ ವಹಿವಾಟು (trade-off) ಸ್ಪಷ್ಟವಾಗಿದೆ: ಗೇಟ್ ಇಲ್ಲದಿದ್ದರೆ ನೀವು ಡೇಟಾವನ್ನು ಮೌನವಾಗಿ ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ; ಗೇಟ್ ಇದ್ದರೆ ನೀವು ಸ್ವಲ್ಪ ಹೆಚ್ಚಿನ ವೆಚ್ಚವನ್ನು ಪಾವತಿಸುತ್ತೀರಿ ಆದರೆ ಪ್ರತಿ ಸಂಘರ್ಷದ ಬಗ್ಗೆ ಸ್ಪಷ್ಟತೆ ಪಡೆಯುತ್ತೀರಿ.
ಈ ವೈಫಲ್ಯ ಎಷ್ಟು ಸಾಮಾನ್ಯ?
ಕೇವಲ ಇಬ್ಬರು ಏಜೆಂಟ್ಗಳಿದ್ದರೂ ಸಹ, ಪರೀಕ್ಷೆಯು ಒಂದು ಬರವಣಿಗೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳುವ 75% ಸಾಧ್ಯತೆಯನ್ನು ತೋರಿಸಿದೆ. ಐದು ಏಜೆಂಟ್ಗಳಿದ್ದಾಗ, ನಷ್ಟದ ಪ್ರಮಾಣವು 100% ಗೆ ಸಮೀಪಿಸುತ್ತದೆ. ಯಾವುದೇ ಪ್ರೊಡಕ್ಷನ್-ಮಟ್ಟದ ಮಲ್ಟಿ-ಏಜೆಂಟ್ ವರ್ಕ್ಫ್ಲೋಗೆ “ಸಾಮಾನ್ಯವಾಗಿ ಸರಿಯಾಗಿರುತ್ತದೆ” ಎಂಬುದು ಅಪಾಯಕಾರಿ ಅಂದಾಜಾಗಿದೆ ಎಂದು ಈ ಅಂಕಿಅಂಶಗಳು ಸೂಚಿಸುತ್ತವೆ.
ವಿರೋಧಾತ್ಮಕ ವಾದ: ಗೇಟ್ ಅನ್ನು ಯಾವಾಗ ಬಿಡಬಹುದು
ಒಂದು ವ್ಯವಸ್ಥೆಯು ಪ್ರತಿ ಸಂಪನ್ಮೂಲಕ್ಕೆ ಒಂದೇ ಏಜೆಂಟ್ ಅನ್ನು ನಡೆಸುತ್ತಿದ್ದರೆ ಅಥವಾ ಉನ್ನತ ಮಟ್ಟದಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾದ ಸೀರಿಯಲೈಸೇಶನ್ ಅನ್ನು (strict serialisation) ಜಾರಿಗೊಳಿಸುತ್ತಿದ್ದರೆ, ಹೆಚ್ಚುವರಿ CAS ಪರಿಶೀಲನೆಗಳು ಅನಗತ್ಯವಾಗಿರಬಹುದು. ಆದಾಗ್ಯೂ, ವಿಫಲವಾದ ಕೆಲಸವನ್ನು ಮರುಪ್ರಯತ್ನಿಸುವ ಗುಪ್ತ ವೆಚ್ಚ ಮತ್ತು ಡೇಟಾ ಕಾಣೆಯಾದಾಗ ಉಂಟಾಗಬಹುದಾದ ಮುಂದಿನ ಪರಿಣಾಮಗಳನ್ನು ಒಳಗೊಂಡೇ ಅಪಾಯದ ಲೆಕ್ಕಾಚಾರವನ್ನು ಮಾಡಬೇಕು.
ಮುಂದೆ ಗಮನಿಸಬೇಕಾದ ಅಂಶಗಳು
- ಟೂಲಿಂಗ್ ಸಪೋರ್ಟ್ (Tooling support): ಆವೃತ್ತಿ ಸಂಖ್ಯೆಗಳು ಅಥವಾ ETags ಅನ್ನು ಪ್ರದರ್ಶಿಸುವ ಮತ್ತು ಔಟ್ ಆಫ್ ದಿ ಬಾಕ್ಸ್ (out of the box) ಅಟಾಮಿಕ್ CAS ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಒದಗಿಸುವ ಸ್ಟೋರೇಜ್ APIಗಳನ್ನು ಹುಡುಕಿ.
- ಮೆಟ್ರಿಕ್ಸ್ (Metrics): ಆವೃತ್ತಿ ಹೊಂದಾಣಿಕೆಯ ಕೊರತೆಯಿಂದಾಗಿ ಬರವಣಿಗೆಯನ್ನು ಎಷ್ಟು ಬಾರಿ ತಿರಸ್ಕರಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ದಾಖಲಿಸಲು ನಿಮ್ಮ ಏಜೆಂಟ್ಗಳನ್ನು ಸಜ್ಜುಗೊಳಿಸಿ. ಹೆಚ್ಚುತ್ತಿರುವ ಸಂಘರ್ಷದ ದರವು ನೀವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೆಚ್ಚಿಸುವ ಅಥವಾ ವರ್ಕ್ಫ್ಲೋವನ್ನು ಮರು ವಿನ್ಯಾಸಗೊಳಿಸುವ ಅಗತ್ಯವಿದೆ ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತದೆ.
- ಮರುಪ್ರಯತ್ನದ ತಂತ್ರಗಳು (Retry strategies): ಸರಳ ಎಕ್ಸ್ಪೋನೆನ್ಶಿಯಲ್ ಬ್ಯಾಕ್-ಆಫ್ (exponential back-off) ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಪದೇ ಪದೇ ಮರುಪ್ರಯತ್ನ ಮಾಡುವುದು ಟೋಕನ್ ಬಳಕೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ. ಮರುಪ್ರಯತ್ನದ ಮಿತಿಗಳನ್ನು ಸ್ವೀಕಾರಾರ್ಹ ಡೇಟಾ ನಷ್ಟದೊಂದಿಗೆ ಸಮತೋಲನಗೊಳಿಸಿ.
- ಹೈಬ್ರಿಡ್ ವಿಧಾನಗಳು (Hybrid approaches): ಕೆಲವು ತಂಡಗಳು ಆಡಿಟಿಂಗ್ಗಾಗಿ (auditability) append-only log ಅನ್ನು ಮತ್ತು ಸ್ಥಿರತೆಗಾಗಿ (consistency) CAS ಗೇಟ್ ಅನ್ನು ಸಂಯೋಜಿಸುತ್ತವೆ, ಇದರಿಂದ ಏನಾಯಿತು ಎಂಬ ದಾಖಲೆ ಮತ್ತು ಓವರ್ರೈಟ್ಗಳ ವಿರುದ್ಧ ರಕ್ಷಣೆ ಎರಡನ್ನೂ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು.
ಸಾರಾಂಶ
Lost-update ಅಸಮತೋಲನಗಳು ಟೋಕನ್-ಚಾಲಿತ AI ಪೈಪ್ಲೈನ್ಗಳನ್ನು ಹಣ ಸೋರಿಕೆಯಾಗುವ ಕಪ್ಪು дыರೆಗಳನ್ನಾಗಿ ಮಾಡುತ್ತವೆ. 'Compare-and-set' ವರ್ಷನ್ ಗೇಟ್ ಅನ್ನು ಅಳವಡಿಸುವುದರಿಂದ ಸಣ್ಣ ಪ್ರಮಾಣದ ಟೋಕನ್ ಹೆಚ್ಚುವರಿ ವೆಚ್ಚವಾಗಬಹುದು, ಆದರೆ ಇದು ಮೌನವಾಗಿ ನಡೆಯುವ ದತ್ತಾಂಶ ನಷ್ಟವನ್ನು ಕಣ್ಣಿಗೆ ಕಾಣುವ ಮತ್ತು ಮರುಪ್ರಯತ್ನಗೊಳಿಸಬಹುದಾದ ಘಟನೆಯನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಡೇಟಾಬೇಸ್ಗಳು, ಪ್ಲಾನ್ ಫೈಲ್ಗಳು ಅಥವಾ ಸ್ಕ್ರ್ಯಾಚ್ಪ್ಯಾಡ್ಗಳಂತಹ ಹಲವು ಏಜೆಂಟ್ಗಳು ಸ್ಟೇಟ್ (state) ಹಂಚಿಕೊಳ್ಳುವ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಬರೆಯುವ ಮೊದಲು ವರ್ಷನ್ ಚೆಕ್ ಅನ್ನು ಅಳವಡಿಸುವುದು ಗುಪ್ತ ವೆಚ್ಚಗಳು ಮತ್ತು ಹಾಳಾದ ವರ್ಕ್ಫ್ಲೋಗಳ (workflows) ವಿರುದ್ಧದ ಅತ್ಯಂತ ಅಗ್ಗದ ವಿಮೆಯಾಗಿದೆ.