𝗪𝗵𝘆 𝗜 𝗦𝘁𝗼𝗽𝗽𝗲𝗱 𝗥𝗲𝗹𝘆𝗶𝗻𝗴 𝗼𝗻 𝗮 𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗜 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿
ನಾನು ಒಂದು ಸಮುದಾಯದ ಫೋರಂಗಾಗಿ (community forum) ರಿಯಲ್-ಟೈಮ್ ಚಾಟ್ಬಾಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿದೆ. ನಾನು ಕೇವಲ OpenAI API ಅನ್ನು ಬಳಸಿದ್ದೆ. ಅದು ಸರಳವಾಗಿ ಕಂಡಿತು.
ಮೂರು ವಾರಗಳ ನಂತರ, ಪೀಕ್ ಅವರ್ಸ್ (peak hours) ಸಮಯದಲ್ಲಿ ನಾನು 5xx ಎದ್ದರ್ ಎದುರಿಸಿದೆ. ನನ್ನ ಚಾಟ್ಬಾಟ್ ಸ್ಥಗಿತಗೊಂಡಿತು. ಬಳಕೆದಾರರು ಕೋಪಗೊಂಡರು. ಪ್ರೊಡಕ್ಷನ್ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗಾಗಿ ನಾನು ಕೇವಲ ಒಬ್ಬ ಪೂರೈಕೆದಾರರನ್ನು ನಂಬಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನನಗೆ ಅರಿವಾಯಿತು.
ಏಕೈಕ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ನಾನು ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದೆ:
- Rate limits
- Timeouts
- ಸಂಪೂರ್ಣ ಸ್ಥಗಿತ (Complete outages)
ನಾನು ಇತರ ಪೂರೈಕೆದಾರರನ್ನು ಪ್ರಯತ್ನಿಸಿದೆ, ಆದರೆ ಅವೆಲ್ಲವೂ ವಿಭಿನ್ನ ಫಾರ್ಮ್ಯಾಟ್ಗಳು ಮತ್ತು ಅಥೆಂಟಿಕೇಶನ್ (authentication) ವಿಧಾನಗಳನ್ನು ಹೊಂದಿದ್ದವು. ನನ್ನ ಕೋಡ್ switch-case ಸ್ಟೇಟ್ಮೆಂಟ್ಗಳ ಗೊಂದಲವಾಯಿತು.
ನನಗೆ ಈ ಕೆಳಗಿನವುಗಳಿಗಾಗಿ ಒಂದು ವ್ಯವಸ್ಥೆಯ ಅಗತ್ಯವಿತ್ತು:
- ವಿವಿಧ ಪೂರೈಕೆದಾರರನ್ನು ಪ್ರಮಾಣೀಕರಿಸಲು (Standardize)
- ಒಂದು ಪೂರೈಕೆದಾರ ವಿಫಲವಾದಾಗ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮರುಪ್ರಯತ್ನಿಸಲು (Retry)
- ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕ್ಯಾಶ್ (Cache) ಮಾಡಲು
- ವೆಂಡರ್ ಲಾಕ್-ಇನ್ (vendor lock-in) ತಪ್ಪಿಸಲು
ಥರ್ಡ್-ಪಾರ್ಟಿ ಲೈಬ್ರರಿಗಳು ತುಂಬಾ ಬಿಗಿಯಾಗಿದ್ದವು (rigid), ಆದ್ದರಿಂದ ನಾನು ಅವುಗಳನ್ನು ಬಳಸಲಿಲ್ಲ. ಬದಲಾಗಿ, ನಾನು ಸರಳ ವಿನ್ಯಾಸವನ್ನು ಬಳಸಿ ಒಂದು ಕಸ್ಟಮ್ ಫಾಲ್ಬ್ಯಾಕ್ (fallback) ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸಿದೆ.
ಮೊದಲಿಗೆ, ನಾನು ಎಲ್ಲಾ ಪೂರೈಕೆದಾರರಿಗಾಗಿ ಒಂದು ಸಾಮಾನ್ಯ ಇಂಟರ್ಫೇಸ್ (interface) ಅನ್ನು ರಚಿಸಿದೆ. ಇದು ಯಾವುದೇ AI ಮಾಡೆಲ್ ಒಂದೇ ಕೋಡ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ನಂತರ, ನಾನು ಒಂದು router class ಅನ್ನು ನಿರ್ಮಿಸಿದೆ. ಈ ಕ್ಲಾಸ್ ಪೂರೈಕೆದಾರರನ್ನು ಕ್ರಮಾನುಗತವಾಗಿ ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಇದು ವೈಫಲ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಲು exponential backoff ಮತ್ತು ಸರಳ ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಬಳಸುತ್ತದೆ.
ಅದರ ತರ್ಕ (logic) ಇಲ್ಲಿದೆ:
- AI ಪೂರೈಕೆದಾರರಿಗಾಗಿ ಒಂದು abstract base class ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ.
- OpenAI ಮತ್ತು ಇತರ ಪೂರೈಕೆದಾರರಿಗಾಗಿ ನಿರ್ದಿಷ್ಟ ಕ್ಲಾಸ್ಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಿ.
- ನಿಮ್ಮ ಪೂರೈಕೆದಾರರ ಪಟ್ಟಿಯ ಮೂಲಕ ಲೂಪ್ ಮಾಡಲು router ಅನ್ನು ಬಳಸಿ.
- ಒಂದು ಪೂರೈಕೆದಾರ ವಿಫಲವಾದರೆ, router ಕಾಯುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಪೂರೈಕೆದಾರರನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.
ಇತ್ತೀಚಿನ ಮೂರು ಸ್ಥಗಿತದ ಸಮಯದಲ್ಲಿ ಈ ವ್ಯವಸ್ಥೆಯು ನನ್ನ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಉಳಿಸಿತು. ಇದು ಪಾರದರ್ಶಕ ಮತ್ತು ಸರಳವಾಗಿದೆ.
ನೀವು AI ನೊಂದಿಗೆ ಏನನ್ನಾದರೂ ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ಈ ಅಂಶಗಳನ್ನು ನೆನಪಿಡಿ:
- ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಲೋಕಲ್ ಡಿಕ್ಷನರಿಗಿಂತ ಕ್ಯಾಶಿಂಗ್ಗಾಗಿ Redis ಬಳಸಿ.
- ನಿಮ್ಮ ವೆಚ್ಚವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಕಾಸ್ಟ್ ಟ್ರ್ಯಾಕಿಂಗ್ (cost tracking) ಸೇರಿಸಿ.
- ವೇಗವಾದ ಪ್ರತಿಕ್ರಿಯೆಗಳಿಗಾಗಿ asynchronous ಸಪೋರ್ಟ್ ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಿ.
- Rate limits ಅನ್ನು ಉತ್ತಮವಾಗಿ ನಿರ್ವಹಿಸಲು "Retry-After" ಹೆಡರ್ಗಳನ್ನು ಪಾರ್ಸ್ (parse) ಮಾಡಿ.
ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಚಿಕ್ಕದಾಗಿದ್ದರೆ ಅತಿಯಾದ ಎಂಜಿನಿಯರಿಂಗ್ (over-engineer) ಮಾಡಬೇಡಿ. ಆದರೆ ನಿಮ್ಮ ಸೇವೆ ಅಪ್ಟೈಮ್ (uptime) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದರೆ, ಒಂದು ಫಾಲ್ಬ್ಯಾಕ್ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸಿ.
ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ಗಳಲ್ಲಿ ಪೂರೈಕೆದಾರರ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ನೀವು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತೀರಿ? ನೀವು ಫಾಲ್ಬ್ಯಾಕ್ ಲೇಯರ್ ಅನ್ನು ಬಳಸುತ್ತೀರಾ ಅಥವಾ ಒಬ್ಬನೇ ವೆಂಡರ್ ಮೇಲೆ ಅವಲಂಬಿತರಾಗುತ್ತೀರಾ?