𝗬𝗼𝘂𝗿 𝗔𝗜 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿 𝗜𝘀 𝗮 𝗦𝗶𝗻𝗴𝗹𝗲 𝗣𝗼𝗶𝗻𝘁 𝗼𝗳 𝗙𝗮𝗶𝗹𝘂𝗿𝗲
ಕಳೆದ ಶುಕ್ರವಾರ, ಅಮೆರಿಕದ ವಾಣಿಜ್ಯ ಇಲಾಖೆಯು Anthropic ಗೆ ಪತ್ರವನ್ನು ಕಳುಹಿಸಿತು. ಅಂದೇ ಸಂಜೆಯ ವೇಳೆಗೆ, Fable 5 ಮತ್ತು Mythos 5 ಮಾದರಿಗಳು ಮಾಯವಾದವು.
ಅವುಗಳನ್ನು ನಿработಿಸಲಾಗಿರಲಿಲ್ಲ (deprecated). ಅವುಗಳ ವೇಗವನ್ನು ಕಡಿಮೆ ಮಾಡಲಾಗಿರಲಿಲ್ಲ (throttled). ಅವು ಕೇವಲ ಇಲ್ಲದಂತಾದವು.
API ಕರೆಗಳು 404 ದೋಷಗಳನ್ನು (errors) ನೀಡಿದವು. ಲೈವ್ ಸೆಷನ್ಗಳು ಸಂಭಾಷಣೆಯ ಮಧ್ಯದಲ್ಲೇ ವಿಫಲವಾದವು. ಆ ಮಾದರಿಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದವು. ಇದು ಬಿಡುಗಡೆಯಾದ ಮೂರು ದಿನಗಳ ನಂತರ ಸಂಭವಿಸಿತು. ಯಾವುದೇ ಎಚ್ಚರಿಕೆ ಅಥವಾ ಬದಲಾವಣೆಗೆ ಬೇಕಾದ ಸಮಯ (migration window) ನೀಡಲಾಗಿರಲಿಲ್ಲ.
ಆ ಮಾದರಿಗಳು ಹೊಸದಾಗಿದ್ದರಿಂದ ನಾವು ಅದೃಷ್ಟವಂತರಾಗಿದ್ದೆವು. ಯಾರೂ ಅವುಗಳ ಮೇಲೆ ಹೆಚ್ಚಿನ ಅವಲಂಬನೆಯನ್ನು ಹೊಂದಿರಲಿಲ್ಲ. ನೀವು ಆರು ತಿಂಗಳಿನಿಂದ ಪ್ರತಿದಿನ ಬಳಸುವ ಮಾದರಿ ಹೀಗೆ ಆಗುತ್ತದೆ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ.
ಒಂದು ಸರ್ಕಾರಿ ಪತ್ರವು ನಿಮ್ಮ ಪ್ರಾಥಮಿಕ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಬಲ್ಲದಿದ್ದರೆ, ನೀವು ಯಾವುದೇ ಫೇಲ್ಓವರ್ (failover) ಇಲ್ಲದೆ ಅದನ್ನು ನಡೆಸುತ್ತೀರಾ? ಖಂಡಿತ ಇಲ್ಲ. ಆದರೂ, ಹೆಚ್ಚಿನ ತಂಡಗಳು AI ವಿಷಯದಲ್ಲಿ ಹೀಗೆಯೇ ಮಾಡುತ್ತಿವೆ.
ಅನೇಕ ತಂಡಗಳು AI ಅನ್ನು ವಿದ್ಯುತ್ನಂತೆ ಪರಿಗಣಿಸುತ್ತವೆ. ನೀವು ಸ್ವಿಚ್ ಒತ್ತಿದ ತಕ್ಷಣ ಬೆಳಕು ಬರಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸುತ್ತೀರಿ. ಅದರ ಮೂಲದ ಬಗ್ಗೆ ಅಥವಾ ವಿದ್ಯುತ್ ಸ್ಥಗಿತಗೊಂಡಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬ ಬಗ್ಗೆ ನೀವು ಯೋಚಿಸುವುದಿಲ್ಲ. ನೀವು ಒಂದು ಮಾದರಿಯನ್ನು ಆರಿಸಿಕೊಳ್ಳುತ್ತೀರಿ, ಒಂದು ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು (endpoint) ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡುತ್ತೀರಿ ಮತ್ತು ಬಿಡುಗಡೆ ಮಾಡುತ್ತೀರಿ.
ಇದು ಎಂಜಿನಿಯರಿಂಗ್ ಅಲ್ಲ. ಇದು ಕೇವಲ ಭರವಸೆಯ ಮೇಲೆ ನಿಂತಿರುವ ಆರ್ಕಿಟೆಕ್ಚರ್ (hope-driven architecture).
ಈ ಕಾರಣಗಳಿಂದ ಮಾದರಿಗಳು ಮಾಯವಾಗಬಹುದು:
- ನಿಯಂತ್ರಕ ಕಾರಣಗಳು (Regulatory reasons)
- ನೀತಿ ಬದಲಾವಣೆಗಳು (Policy changes)
- ಭೌಗೋಳಿಕ ರಾಜಕೀಯ ಸಮಸ್ಯೆಗಳು (Geopolitical issues)
Anthropic ಪರಿಸ್ಥಿತಿಯು ಬಗ್ (bug) ಅಥವಾ ಮೂಲಸೌಕರ್ಯ ವೈಫಲ್ಯವಾಗಿರಲಿಲ್ಲ. ಅದು ನಿಯಂತ್ರಕ ಕಿಲ್ಲೊ ಸ್ವಿಚ್ (regulatory kill switch) ಆಗಿತ್ತು.
ನೀವು ನಿಮ್ಮ ಮಾದರಿ ಪದರದಲ್ಲಿ (model layer) ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು (resilience) ನಿರ್ಮಿಸಬೇಕು. ಈ ಮಾದರಿಗಳನ್ನು ಬಳಸಿ:
- ನಿಮ್ಮ ಮಾದರಿ ಕರೆಗಳನ್ನು ಅಬ್ಸ್ಟ್ರಾಕ್ಟ್ (Abstract) ಮಾಡಿ. ಒಂದು ಇಂಟರ್ಫೇಸ್ ಬಳಸಿ, ಇದರಿಂದ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಯಾವ ಪೂರೈಕೆದಾರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತಾರೆ ಎಂಬ ಬಗ್ಗೆ ತಲೆಕೆಡಿಸಿಕೊಳ್ಳುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.
- ಬಹು ಪೂರೈಕೆದಾರರನ್ನು ಬಳಸಿ. ಪೂರೈಕೆದಾರರನ್ನು ಬದಲಾಯಿಸುವುದು ಕೇವಲ ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾವಣೆಯಾಗಿರಬೇಕೇ ಹೊರತು, ಸಂಪೂರ್ಣವಾಗಿ ಮರುಬರಹ ಮಾಡುವಂತಿರಬಾರದು.
- ಓಪನ್-ವೇಟ್ (open-weight) ಮಾದರಿಗಳನ್ನು ಬಳಸಿ. ನೀವು ಮಾದರಿಯನ್ನು ನೀವೇ ನಡೆಸಿದರೆ, ಯಾರೂ ಅದನ್ನು ದೂರದಿಂದ ಸ್ಥಗಿತಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ವಿದ್ಯುತ್ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡಾಗ ಜನರೇಟರ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೋ, ಈ ಮಾದರಿಗಳು ಹಾಗೆಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
- ಗ್ರೇಸ್ಫುಲ್ ಡಿಗ್ರಡೇಶನ್ (graceful degradation) ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಿ. ಅಪ್ಲಿಕೇಶನ್ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಗಿತಗೊಳ್ಳುವುದಕ್ಕಿಂತ, ಒಂದು ಸಣ್ಣ ಅಥವಾ ಹಳೆಯ ಮಾದರಿಯನ್ನು ಬಳಸುವುದು ಉತ್ತಮ.
ನಿಮ್ಮ ದೋಷ ದರಗಳನ್ನು (error rates) ಗಮನಿಸಿ. ಅವು ಹೆಚ್ಚಾದರೆ, ತಕ್ಷಣ ಫಾಲ್ಬ್ಯಾಕ್ (fallback) ಗೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ವರ್ಗಾಯಿಸಿ.
ನಿಮ್ಮ AI ಅನ್ನು ಇತರ ಯಾವುದೇ ನಿರ್ಣಾಯಕ ಪ್ರೊಡಕ್ಷನ್ ಅವಲಂಬನೆಗಳಂತೆ (critical production dependency) ಪರಿಗಣಿಸಿ. ವೈಫಲ್ಯಕ್ಕಾಗಿ ಸಿದ್ಧರಾಗಿ (Design for failure).
ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ನಿಮ್ಮ ಪೂರೈಕೆದಾರರು ವೈಫಲ್ಯಕ್ಕೊಳಗಾಗಬಹುದು ಎಂದು ಭಾವಿಸುತ್ತದೆಯೇ? ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ಅಪಾಯದಲ್ಲಿದ್ದೀರಿ.
ನೀವು ನಿಮ್ಮ ಸ್ಟ್ಯಾಕ್ನಲ್ಲಿ ಮಲ್ಟಿ-ಪ್ರೊವೈಡರ್ ಫಾಲ್ಬ್ಯಾಕ್ ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೀರಾ? ಕಾಮೆಂಟ್ಗಳಲ್ಲಿ ತಿಳಿಸಿ.
ಮೂಲ: https://dev.to/aws/your-ai-provider-is-a-single-point-of-failure-26i2
ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi