𝗪𝗵𝘆 𝗜 𝗦𝘁𝗼𝗽𝗽𝗲𝗱 𝗥𝗲𝗹𝘆𝗶𝗻𝗴 𝗼𝗻 𝗮 𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗜 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿
ਮੈਂ ਇੱਕ ਕਮਿਊਨਿਟੀ ਫੋਰਮ ਲਈ ਇੱਕ ਰੀਅਲ-ਟਾਈਮ ਚੈਟਬੋਟ ਬਣਾਇਆ। ਮੈਂ ਸਿਰਫ਼ OpenAI API ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਇਹ ਬਹੁਤ ਸੌਖਾ ਲੱਗ ਰਿਹਾ ਸੀ।
ਤਿੰਨ ਹਫ਼ਤਿਆਂ ਬਾਅਦ, ਪੀਕ ਆਵਰਜ਼ (peak hours) ਦੌਰਾਨ ਮੈਨੂੰ 5xx ਐਰਰ ਆਇਆ। ਮੇਰਾ ਚੈਟਬੋਟ ਬੰਦ ਹੋ ਗਿਆ। ਯੂਜ਼ਰਸ ਗੁੱਸੇ ਸਨ। ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਮੈਂ ਪ੍ਰੋਡਕਸ਼ਨ ਐਪਸ ਲਈ ਇੱਕ ਹੀ ਪ੍ਰੋਵਾਈਡਰ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਮੈਨੂੰ ਇੱਕ ਸਿੰਗਲ ਪ੍ਰੋਵਾਈਡਰ ਨਾਲ ਕਈ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ:
- Rate limits
- Timeouts
- ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਰਵਿਸ ਬੰਦ ਹੋ ਜਾਣਾ (Complete outages)
ਮੈਂ ਹੋਰ ਪ੍ਰੋਵਾਈਡਰਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਪਰ ਉਨ੍ਹਾਂ ਸਾਰਿਆਂ ਦੇ ਫਾਰਮੈਟ ਅਤੇ ਆਥੈਂਟੀਕੇਸ਼ਨ (authentication) ਤਰੀਕੇ ਵੱਖਰੇ ਸਨ। ਮੇਰਾ ਕੋਡ switch-case ਸਟੇਟਮੈਂਟਸ ਦਾ ਇੱਕ ਜਾਲ ਬਣ ਗਿਆ।
ਮੈਨੂੰ ਇੱਕ ਅਜਿਹੇ ਸਿਸਟਮ ਦੀ ਲੋੜ ਸੀ ਜੋ:
- ਵੱਖ-ਵੱਖ ਪ੍ਰੋਵਾਈਡਰਾਂ ਨੂੰ ਸਟੈਂਡਰਡਾਈਜ਼ ਕਰ ਸਕੇ
- ਇੱਕ ਫੇਲ ਹੋਣ 'ਤੇ ਆਪਣੇ ਆਪ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕੇ
- ਰਿਸਪਾਂਸਾਂ ਨੂੰ ਕੈਸ਼ (cache) ਕਰ ਸਕੇ
- ਵੈਂਡਰ ਲੌਕ-ਇਨ (vendor lock-in) ਤੋਂ ਬਚ ਸਕੇ
ਮੈਂ Third-party ਲਾਇਬ੍ਰੇਰੀਆਂ ਤੋਂ ਬਚਿਆ ਕਿਉਂਕਿ ਉਹ ਬਹੁਤ ਸਖ਼ਤ (rigid) ਸਨ। ਇਸ ਦੀ ਬਜਾਏ, ਮੈਂ ਇੱਕ ਸਧਾਰਨ ਡਿਜ਼ਾਈਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਕਸਟਮ ਫਾਲਬੈਕ (fallback) ਸਿਸਟਮ ਬਣਾਇਆ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਂ ਸਾਰੇ ਪ੍ਰੋਵਾਈਡਰਾਂ ਲਈ ਇੱਕ ਸਾਂਝਾ ਇੰਟਰਫੇਸ (interface) ਬਣਾਇਆ। ਇਹ ਕਿਸੇ ਵੀ AI ਮਾਡਲ ਨੂੰ ਇੱਕੋ ਕੋਡ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
ਅਗਲੇ ਕਦਮ ਵਜੋਂ, ਮੈਂ ਇੱਕ router class ਬਣਾਈ। ਇਹ class ਕ੍ਰਮਵਾਰ ਪ੍ਰੋਵਾਈਡਰਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ। ਇਹ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸੰਭਾਲਣ ਲਈ exponential backoff ਅਤੇ ਸਧਾਰਨ ਕੈਸ਼ਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ।
ਇੱਥੇ ਇਸਦਾ ਲੌਜਿਕ (logic) ਹੈ:
- AI ਪ੍ਰੋਵਾਈਡਰਾਂ ਲਈ ਇੱਕ abstract base class ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।
- OpenAI ਅਤੇ ਹੋਰ ਪ੍ਰੋਵਾਈਡਰਾਂ ਲਈ ਖਾਸ ਕਲਾਸਾਂ ਲਾਗੂ ਕਰੋ।
- ਪ੍ਰੋਵਾਈਡਰਾਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਲੂਪ ਕਰਨ ਲਈ ਇੱਕ router ਦੀ ਵਰਤੋਂ ਕਰੋ।
- ਜੇਕਰ ਕੋਈ ਪ੍ਰੋਵਾਈਡਰ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ router ਇੰਤਜ਼ਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਅਗਲੇ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।
ਇਸ ਸਿਸਟਮ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਹੋਈਆਂ ਤਿੰਨ ਸਰਵਿਸ ਬੰਦ ਹੋਣ ਦੀਆਂ ਘਟਨਾਵਾਂ ਦੌਰਾਨ ਮੇਰੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਬਚਾਇਆ। ਇਹ ਪਾਰਦਰਸ਼ੀ ਅਤੇ ਸਧਾਰਨ ਰਹਿੰਦਾ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ AI ਨਾਲ ਕੁਝ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹਨਾਂ ਗੱਲਾਂ ਦਾ ਧਿਆਨ ਰੱਖੋ:
- ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਲੋਕਲ ਡਿਕਸ਼ਨਰੀ ਦੀ ਬਜਾਏ ਕੈਸ਼ਿੰਗ ਲਈ Redis ਦੀ ਵਰਤੋਂ ਕਰੋ।
- ਆਪਣੇ ਖਰਚੇ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ cost tracking ਸ਼ਾਮਲ ਕਰੋ।
- ਤੇਜ਼ ਰਿਸਪਾਂਸ ਲਈ asynchronous ਸਪੋਰਟ ਲਾਗੂ ਕਰੋ।
- ਰੇਟ ਲਿਮਿਟਸ ਨੂੰ ਬਿਹਤਰ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਣ ਲਈ "Retry-After" headers ਨੂੰ ਪਾਰਸ (parse) ਕਰੋ।
ਜੇਕਰ ਤੁਹਾਡਾ ਪ੍ਰੋਜੈਕਟ ਛੋਟਾ ਹੈ ਤਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ over-engineer ਨਾ ਕਰੋ। ਪਰ ਜੇਕਰ ਤੁਹਾਡੀ ਸੇਵਾ uptime 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਇੱਕ fallback ਬਣਾਓ।
ਤੁਸੀਂ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਪ੍ਰੋਵਾਈਡਰ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੇ ਹੋ? ਕੀ ਤੁਸੀਂ fallback ਲੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਜਾਂ ਇੱਕ ਹੀ ਵੈਂਡਰ 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੇ ਹੋ?