ನಾನು ಏಕೆ ಏಕೈಕ AI ಪೂರೈಕೆದಾರರ ಮೇಲೆ ಅವಲಂಬಿತರಾಗುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ
ನಾನು ಒಂದು ಸಮುದಾಯ ಫೋರಂಗಾಗಿ (community forum) ರಿಯಲ್-ಟೈಮ್ ಚಾಟ್ಬಾಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿದೆ. ಕೇವಲ ಒಂದು API ಬಳಸಿದರೆ ಸಾಕು ಎಂದು ನಾನು ಭಾವಿಸಿದ್ದೆ. ನಾನು ತಪ್ಪು ಮಾಡಿದ್ದೆ.
ಮೂರು ವಾರಗಳ ನಂತರ, ಪೀಕ್ ಅವರ್ಗಳ (peak hours) ಸಮಯದಲ್ಲಿ ನಾನು 5xx ಎರರ್ ಎದುರಿಸಿದೆ. ನನ್ನ ಚಾಟ್ಬಾಟ್ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿತು. ಬಳಕೆದಾರರು ಅಸಮಾಧಾನಗೊಂಡರು. ಪ್ರೊಡಕ್ಷನ್ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗಾಗಿ (production apps) ನಾನು ಕೇವಲ ಒಬ್ಬ ಪೂರೈಕೆದಾರನನ್ನು ನಂಬಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನನಗೆ ಅರಿವಾಯಿತು.
ನಾನು GPT-4 ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೆ. ಅದು ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು, ಆದರೆ ಯಾವಾಗಲೊಬ್ಬ ಅದು ನಿಂತುಹೋಯಿತು. ನಾನು ರೇಟ್ ಲಿಮಿಟ್ಸ್ (rate limits), ಟೈಮೌಟ್ಗಳು (timeouts) ಮತ್ತು ಸಂಪೂರ್ಣ ಸೇವೆಯ ಸ್ಥಗಿತವನ್ನು (outages) ಎದುರಿಸಿದೆ. ಉನ್ನತ ಹಂತಗಳಿಗೆ (higher tiers) ಹಣ ಪಾವತಿಸುವುದು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಬದಲು ಅದರ ಲಕ್ಷಣವನ್ನು ಸರಿಪಡಿಸುವಂತೆ ಭಾಸವಾಯಿತು.
ನಾನು ಇತರ ಪೂರೈಕೆದಾರರನ್ನು ಪ್ರಯತ್ನಿಸಿದೆ, ಆದರೆ ಅವೆಲ್ಲವೂ ವಿಭಿನ್ನ ಫಾರ್ಮ್ಯಾಟ್ಗಳು ಮತ್ತು ಆಥರೈಸೇಶನ್ (auth) ವಿಧಾನಗಳನ್ನು ಹೊಂದಿದ್ದವು. ನನ್ನ ಕೋಡ್ switch-case ಸ್ಟೇಟ್ಮೆಂಟ್ಗಳ ಗೊಂದಲವಾಯಿತು. ನನಗೆ ಈ ಕೆಳಗಿನವುಗಳಿಗಾಗಿ ಒಂದು ವ್ಯವಸ್ಥೆಯ ಅಗತ್ಯವಿತ್ತು:
- ಪೂರೈಕೆದಾರರ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಮರೆಮಾಚಲು.
- ವೈಫಲ್ಯ ಸಂಭವಿಸಿದಾಗ ಬ್ಯಾಕಪ್ ಪೂರೈಕೆದಾರರಿಗೆ ಬದಲಾಯಿಸಲು.
- ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕ್ಯಾಶ್ (cache) ಮಾಡಲು.
- ವೆಂಡರ್ ಲಾಕ್-ಇನ್ (vendor lock-in) ತಪ್ಪಿಸಲು.
ಥರ್ಡ್-ಪಾರ್ಟಿ ಲೈಬ್ರರಿಗಳು ತುಂಬಾ ಸಂಕೀರ್ಣವಾಗಿದ್ದವು ಮತ್ತು ಸುಲಭವಾಗಿ ದೋಷಗಳನ್ನು ತೋರಿಸುತ್ತಿದ್ದವು ಎಂಬ ಕಾರಣಕ್ಕೆ ನಾನು ಅವುಗಳನ್ನು ಬಳಸಲಿಲ್ಲ. ಬದಲಾಗಿ, ನಾನು ಒಂದು ಸರಳ ರೂಟರ್ ಅನ್ನು ನಿರ್ಮಿಸಿದೆ.
ಮೊದಲಿಗೆ, ನಾನು ಎಲ್ಲಾ ಪೂರೈಕೆದಾರರಿಗಾಗಿ ಒಂದು ಸಾಮಾನ್ಯ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿದೆ. ಪ್ರತಿಯೊಂದು ಪೂರೈಕೆದಾರರು generate method ಮತ್ತು health check ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುತ್ತಾರೆ.
ನಂತರ, ನಾನು ಒಂದು router class ಅನ್ನು ನಿರ್ಮಿಸಿದೆ. ಇದು ನಿರ್ದಿಷ್ಟ ಕ್ರಮದಲ್ಲಿ ಪೂರೈಕೆದಾರರನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಇದು exponential backoff ಮತ್ತು ಸರಳ ಕ್ಯಾಶ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಮೊದಲ ಪೂರೈಕೆದಾರ ವಿಫಲವಾದರೆ, ವ್ಯವಸ್ಥೆಯು ಕಾಯುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಪೂರೈಕೆದಾರರನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.
ಮೂರು ವಿಭಿನ್ನ ಸೇವೆಯ ಸ್ಥಗಿತಗಳ ಸಮಯದಲ್ಲಿ ಈ ವ್ಯವಸ್ಥೆಯು ನನ್ನ ವಾರಾಂತ್ಯಗಳನ್ನು ಉಳಿಸಿತು. ಪ್ರಮುಖ ಪೂರೈಕೆದಾರರು ಸ್ಥಗಿತಗೊಂಡಾಗಲೂ ಇದು ನನ್ನ ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಲ್ಲಿರುವಂತೆ ನೋಡಿಕೊಳ್ಳುತ್ತದೆ.
ನೀವು ಇದನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ಈ ಅಂಶಗಳನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ:
- ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಲೋಕಲ್ ಡಿಕ್ಷನರಿ ಬದಲಿಗೆ ಕ್ಯಾಶಿಂಗ್ಗಾಗಿ Redis ಬಳಸಿ.
- ಹೆಲ್ತ್ ಚೆಕ್ಗಳು ಯಶಸ್ಸನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಪೂರೈಕೆದಾರರು ಚೆಕ್ನಲ್ಲಿ ಉತ್ತೀರ್ಣರಾಗಬಹುದು ಆದರೆ ನೈಜ ವಿನಂತಿಯನ್ನು (request) ವಿಫಲಗೊಳಿಸಬಹುದು.
- ರೇಟ್ ಲಿಮಿಟ್ಗಳನ್ನು ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸಲು Retry-After ಹೆಡರ್ಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡಿ.
- ವೆಚ್ಚವನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಟೋಕನ್ ಬಳಕೆಯ ಲಾಗಿಂಗ್ ಅನ್ನು ಸೇರಿಸಿ.
- ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ asyncio ಬಳಸಿ.
ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಚಿಕ್ಕದಾಗಿದ್ದರೆ, ಅತಿಯಾದ ಎಂಜಿನಿಯರಿಂಗ್ (over-engineer) ಮಾಡಬೇಡಿ. ನಿಮಗೆ ಸ್ಟ್ರೀಮಿಂಗ್ ಅಗತ್ಯವಿದ್ದರೆ, ಈ ಮಾದರಿಯು ವಿಳಂಬವನ್ನು (latency) ಉಂಟುಮಾಡಬಹುದು. ನಿಮ್ಮ ಅಗತ್ಯಕ್ಕೆ ತಕ್ಕಂತೆ ಸರಿಯಾದ ಸಾಧನವನ್ನು ಆರಿಸಿ.
ನೀವು ಪೂರೈಕೆದಾರರ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತೀರಿ? ನೀವು ಒಬ್ಬನೇ ಪೂರೈಕೆದಾರನಿಗೆ ಅಂಟಿಕೊಂಡಿರುತ್ತೀರಾ ಅಥವಾ ಫಾಲ್ಬ್ಯಾಕ್ ಲೇಯರ್ (fallback layer) ಅನ್ನು ನಿರ್ಮಿಸುತ್ತೀರಾ?