ਇੱਕ ਮੁੱਖ ਲਾਰਜ ਲੈਂਗੂਏਜ ਮਾਡਲ (large language model) ਦੀ ਚੋਣ ਕਰਨ ਵਿੱਚ ਇੱਕ ਦੁਪਹਿਰ ਲੱਗ ਸਕਦੀ ਹੈ। ਪਰ ਜਦੋਂ ਇਹ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਸ ਸਥਿਤੀ ਨੂੰ ਸੰਭਾਲਣਾ ਅਸਲ ਇੰਜੀਨੀਅਰਿੰਗ ਦਾ ਕੰਮ ਹੈ।

ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਸਿਰਫ਼ ਸੁਚੱਜੇ ਰਸਤੇ (happy path) ਲਈ ਅਨੁਕੂਲਤਾ (optimize) ਕਰਦੀਆਂ ਹਨ। ਉਹ ਸਾਫ਼ ਡੇਟਾਸੈਟਾਂ 'ਤੇ ਸ਼ੁੱਧਤਾ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ, ਆਦਰਸ਼ ਇਨਪੁਟਸ ਦੇ ਅਨੁਸਾਰ ਪ੍ਰੋਂਪਟਸ (prompts) ਨੂੰ ਸੁਧਾਰਦੇ ਹਨ, ਅਤੇ ਭਰੋਸੇ ਨਾਲ ਡਿਪਲੋਏ ਕਰਦੇ ਹਨ। ਫਿਰ ਪ੍ਰੋਡਕਸ਼ਨ ਟ੍ਰੈਫਿਕ ਆਉਂਦਾ ਹੈ। ਪੀਕ ਘੰਟਿਆਂ ਦੌਰਾਨ ਮਾਡਲ ਟਾਈਮ-ਆਊਟ ਹੋਣ ਲੱਗਦਾ ਹੈ, ਸ਼ੁੱਕਰਵਾਰ ਦੀ ਸ਼ਾਮ ਨੂੰ ਗਲਤ JSON ਵਾਪਸ ਕਰਦਾ ਹੈ, ਜਾਂ ਕੀਮਤਾਂ ਵਿੱਚ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਅਚਾਨਕ ਤਿੰਨ ਗੁਣਾ ਜ਼ਿਆਦਾ ਖਰਚਾ ਕਰਨ ਲੱਗਦਾ ਹੈ। ਤੁਹਾਡਾ ਸੋਚ-ਸਮਝ ਕੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ AI ਫੀਚਰ ਇੱਕ ਬੋਝ ਬਣ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਮਾਡਲ ਦੇ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾਈ ਸੀ।

ਕਿਸੇ ਵੀ ਗੰਭੀਰ ਮਲਟੀ-ਮਾਡਲ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ, ਫਾਲਬੈਕ ਨਿਯਮ (fallback rules) ਕੋਈ ਸੋਚਣ ਤੋਂ ਬਾਅਦ ਦੀ ਚੀਜ਼ ਨਹੀਂ ਹਨ। ਉਹ ਮੁੱਖ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਹਨ। ਜਦੋਂ ਮੁੱਖ ਮਾਡਲ ਡੋਲਦਾ ਹੈ ਤਾਂ ਤੁਹਾਡਾ ਸਿਸਟਮ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ, ਇਸੇ ਤੋਂ ਤੈਅ ਹੁੰਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਰੁਕਣਗੇ ਜਾਂ ਚਲੇ ਜਾਣਗੇ।

ਸਪੱਸ਼ਟ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਸੰਕੇਤਾਂ (Failure Signals) ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੋ

ਤੁਸੀਂ ਇਹ ਜਾਣੇ ਬਿਨਾਂ ਕਿ ਤੁਸੀਂ ਕਿਸ ਚੀਜ਼ ਪ੍ਰਤੀ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰ ਰਹੇ ਹੋ, ਇੱਕ ਫਾਲਬੈਕ ਰਣਨੀਤੀ ਨਹੀਂ ਬਣਾ ਸਕਦੇ। ਹਰ ਬਾਹਰੀ ਮਾਡਲ ਕਾਲ (outbound model call) ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਅਤੇ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਕਾਰਨਾਂ ਨੂੰ ਖਾਸ, ਕਾਰਵਾਈਯੋਗ ਸੰਕੇਤਾਂ ਵਿੱਚ ਵੰਡਣ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੋ।

ਜਦੋਂ ਕਿਸੇ ਪ੍ਰੋਵਾਈਡਰ ਦਾ ਐਂਡਪੁਆਇੰਟ (endpoint) ਅਟਕ ਜਾਂਦਾ ਹੈ, ਤਾਂ API ਟਾਈਮ-ਆਊਟ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ। ਰੇਟ ਲਿਮਿਟ ਗਲਤੀਆਂ — ਆਮ ਤੌਰ 'ਤੇ HTTP 429s — 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ, ਜੋ ਉਦੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੋ ਜਾਂਦਾ ਹੈ ਜਾਂ ਮਹੀਨਾਵਾਰ ਕੋਟਾ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਅਵੈਧ JSON ਆਉਟਪੁੱਟ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ ਜੋ ਤੁਹਾਡੇ ਪਾਰਸਰ ਪਾਈਪਲਾਈਨ (parser pipeline) ਨੂੰ ਕ੍ਰੈਸ਼ ਕਰ ਦਿੰਦਾ ਹੈ। ਖਾਲੀ ਜਾਂ ਅਧੂਰੇ ਜਵਾਬਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ ਜੋ HTTP ਪੱਧਰ 'ਤੇ ਸਫਲ ਲੱਗਦੇ ਹਨ ਪਰ ਉਹਨਾਂ ਵਿੱਚ ਕੋਈ ਵਰਤੋਂਯੋਗ ਸਮੱਗਰੀ ਨਹੀਂ ਹੁੰਦੀ। ਉੱਚ ਲੇਟੈਂਸੀ (high latency) 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ ਜੋ ਕਿਸੇ ਵੀ ਹਾਰਡ ਟਾਈਮ-ਆਊਟ ਤੋਂ ਪਹਿਲਾਂ ਚੈਟ ਦੇ ਅਨੁਭਵ ਨੂੰ ਖਰਾਬ ਕਰ ਦਿੰਦੀ ਹੈ। ਜਦੋਂ ਯੂਜ਼ਰ ਦਾ ਇਨਪੁਟ ਮਾਡਲ ਦੀ ਸੀਮਾ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੰਟੈਕਸ ਲੈਂਥ ਓਵਰਫਲੋ (context length overflow) 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ। ਅਤੇ ਗੁਣਵੱਤਾ ਵਿੱਚ ਗਿਰਾਵਟ (quality regression) 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ, ਜੋ ਸਭ ਤੋਂ ਸੂਖਮ ਫੇਲ੍ਹ ਹੋਣਾ ਹੈ: ਮਾਡਲ ਜਵਾਬ ਤਾਂ ਦਿੰਦਾ ਹੈ, ਪਰ ਪ੍ਰੋਵਾਈਡਰ-ਸਾਈਡ ਅਪਡੇਟ ਤੋਂ ਬਾਅਦ ਉਸਦੇ ਜਵਾਬ ਭਟਕਣ ਲੱਗਦੇ ਹਨ, ਅਸਪਸ਼ਟ ਹੋ ਜਾਂਦੇ ਹਨ, ਜਾਂ ਫਾਰਮੈਟਿੰਗ ਹਦਾਇਤਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦੇ ਹਨ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਸੰਕੇਤ ਨੂੰ ਵੱਖਰੀ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ। ਟਾਈਮ-ਆਊਟ ਲਈ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ (retry) ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਗਲਤ JSON ਲਈ ਮਾਡਲ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਰੇਟ ਲਿਮਿਟ ਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੇ ਪ੍ਰੋਵਾਈਡਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਫਾਲਬੈਕ ਨੂੰ ਵਰਕਫਲੋ (Workflow) ਦੇ ਅਨੁਸਾਰ ਮਿਲਾਓ

ਹਰ ਕੰਮ ਲਈ ਇੱਕੋ ਜਿਹਾ ਫਾਲਬੈਕ ਨਿਯਮ ਵਰਤਣਾ ਤਬਾਹੀ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ। ਇੱਕ ਚੈਟਬੋਟ ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਡੇਟਾ ਐਕਸਟਰੈਕਸ਼ਨ (data extraction) ਕੰਮ ਦੀਆਂ ਲੋੜਾਂ ਬਿਲਕੁਲ ਵੱਖਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਆਪਣੇ ਫਾਲਬੈਕ ਨੂੰ ਖਾਸ ਵਰਕਫਲੋ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਤਿਆਰ ਕਰੋ।

ਚੈਟਬੋਟਸ ਨੂੰ ਤੇਜ਼ੀ ਅਤੇ ਗੱਲਬਾਤ ਦੀ ਰਵਾਨਗੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਉਪਭੋਗਤਾ ਥੋੜ੍ਹਾ ਜਿਹਾ ਆਮ ਜਵਾਬ ਦੇਣ ਲਈ ਮਾਫ਼ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਪੰਜ ਸੈਕਿੰਡ ਦੇ ਵਿਰਾਮ ਨੂੰ ਮਾਫ਼ ਨਹੀਂ ਕਰਨਗੇ। ਜੇਕਰ ਤੁਹਾਡਾ ਮੁੱਖ ਮਾਡਲ ਹੌਲੀ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਤੇਜ਼ ਬੈਕਅੱਪ — ਅਕਸਰ ਉਸੇ ਮਾਡਲ ਪਰਿਵਾਰ ਦਾ ਇੱਕ ਛੋਟਾ ਵੇਰੀਐਂਟ, ਜਾਂ ਕਿਸੇ ਹੋਰ ਪ੍ਰੋਵਾਈਡਰ ਦੀ ਸਪੀਡ-ਟੀਅਰ ਆਫਰਿੰਗ — 'ਤੇ ਫਾਲਬੈਕ ਕਰੋ। ਗੱਲਬਾਤ ਨੂੰ ਜਾਰੀ ਰੱਖੋ।

RAG ਸਿਸਟਮਾਂ ਨੂੰ ਸ਼ੁੱਧਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਰੀਟ੍ਰੀਵਲ (retrieval) ਦੀ ਕੀਮਤ ਚੁਕਾ ਚੁੱਕੇ ਹੋ — ਵੈਕਟਰ ਸਰਚ (vector search), ਰੀ-ਰੈਂਕਿੰਗ (reranking), ਸ਼ਾਇਦ ਵੈੱਬ ਕ੍ਰੌਲਿੰਗ (web crawling)। ਜੇਕਰ ਜਨਰੇਟਰ ਦਿੱਤੇ ਗਏ ਕੰਟੈਕਸ ਦਾ ਸਤਿਕਾਰ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਉਹ ਸਾਰਾ ਕੰਮ ਬਰਬਾਦ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਅਜਿਹੇ ਮਾਡਲ 'ਤੇ ਫਾਲਬੈਕ ਕਰੋ ਜੋ ਸਹੀ ਹਦਾਇਤਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨ ਅਤੇ ਲੰਬੇ ਕੰਟੈਕਸ ਨੂੰ ਸਮਝਣ ਲਈ ਜਾਣਿਆ ਜਾਂਦਾ ਹੋਵੇ, ਭਾਵੇਂ ਉਹ ਹੌਲੀ ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ।

ਕੋਡਿੰਗ ਟੂਲਸ ਨੂੰ ਤਰਕ (logic) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਵਧੀਆ ਵਿਆਖਿਆਵਾਂ ਨਾਲੋਂ ਸਹੀ ਸਿੰਟੈਕਸ (syntax) ਅਤੇ ਵੈਧ API ਕਾਲਜ਼ ਚਾਹੀਦੀਆਂ ਹਨ। ਜੇਕਰ ਮੁੱਖ ਮਾਡਲ ਫੰਕਸ਼ਨਾਂ ਦੀ ਕਲਪਨਾ (hallucinating) ਕਰਨ ਲੱਗਦਾ ਹੈ ਜਾਂ ਐਜ ਕੇਸਾਂ (edge cases) ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਕੋਡ 'ਤੇ ਫਾਈਨ-ਟਿਊਨ ਕੀਤੇ ਗਏ ਮਾਡਲ 'ਤੇ ਬਦਲ ਜਾਓ। ਕੰਪਾਈਲ-ਤਿਆਰ ਆਉਟਪੁੱਟ ਦੇ ਬਦਲੇ ਉੱਚ ਲੇਟੈਂਸੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰੋ।

JSON ਐਕਸਟਰੈਕਸ਼ਨ ਨੂੰ ਢਾਂਚੇ (structure) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸਟ੍ਰਕਚਰਡ ਜਨਰੇਸ਼ਨ ਬਹੁਤ ਨਾਜ਼ੁਕ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਗਲਤ ਬ੍ਰੈਕਟ ਜਾਂ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਐਸਕੇਪ ਕੀਤਾ ਕੋਟ (quote) ਡਾਊਨਸਟ੍ਰੀਮ ਡੇਟਾਬੇਸ ਰਾਈਟ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਮੁੱਖ ਮਾਡਲ ਸਕੀਮਾ ਦੀ ਪਾਲਣਾ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਵਾਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਫਿਰ ਉੱਚ ਫਾਰਮੈਟਿੰਗ ਭਰੋਸੇਯੋਗਤਾ ਵਾਲੇ ਮਾਡਲ 'ਤੇ ਬਦਲ ਜਾਓ। ਅਜੀਬ ਗੱਲ ਇਹ ਹੈ ਕਿ ਆਗਿਆਕਾਰੀ ਹੋਣ ਲਈ ਟਿਊਨ ਕੀਤੇ ਗਏ ਛੋਟੇ ਮਾਡਲ ਅ

  • ਮਾਡਲ ਦੀ ਸਮਰੱਥਾ: ਕੀ ਇਹ ਅਸਲ ਵਿੱਚ ਪ੍ਰੋਂਪਟ ਦੀ ਕਿਸਮ ਨੂੰ ਸੰਭਾਲ ਸਕਦਾ ਹੈ, ਜਾਂ ਇਹ ਕਿਸੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਅਸਫਲ ਹੋ ਜਾਵੇਗਾ?
  • ਭਾਸ਼ਾ ਸਮਰਥਨ: ਤੁਹਾਡਾ ਬੈਕਅੱਪ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਮਾਹਰ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਹਿੰਦੀ, ਸਪੈਨਿਸ਼ ਜਾਂ ਜਾਪਾਨੀ ਵਿੱਚ ਗਲਤ ਜਾਣਕਾਰੀ (hallucinate) ਦੇ ਸਕਦਾ ਹੈ।
  • ਕੰਟੈਕਸਟ ਵਿੰਡੋ ਦਾ ਆਕਾਰ: ਜੇਕਰ ਤੁਹਾਡਾ ਇਨਪੁਟ 50,000 ਟੋਕਨ ਹੈ, ਤਾਂ 16,000-ਟੋਕਨ ਦੀ ਸੀਮਾ ਵਾਲਾ ਫਾਲਬੈਕ (fallback) ਇਸਨੂੰ ਕੱਟ ਦੇਵੇਗਾ ਅਤੇ ਚੁੱਪਚਾਪ ਅਰਥ ਖਤਮ ਕਰ ਦੇਵੇਗਾ।
  • ਲੇਟੈਂਸੀ (Latency): ਕੁਝ ਪ੍ਰੋਵਾਈਡਰ ਤੁਹਾਡੇ ਖੇਤਰ ਲਈ ਦੂਜਿਆਂ ਨਾਲੋਂ ਲਗਾਤਾਰ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ।
  • ਪ੍ਰਤੀ ਰਿਕਵੈਸਟ ਲਾਗਤ: ਇੱਕ ਸਖ਼ਤ ਸੀਮਾ ਨਿਰਧਾਰਤ ਕਰੋ। ਜਾਣੋ ਕਿ ਪੀਕ ਵੌਲਯੂਮ ਸਮੇਂ ਫਾਲਬੈਕ ਦੀ ਕੀ ਲਾਗਤ ਆਉਂਦੀ ਹੈ।
  • ਆਊਟਪੁੱਟ ਦੀ ਭਰੋਸੇਯੋਗਤਾ: ਕੀ ਇਹ ਹਰ ਵਾਰ ਆਊਟਪੁੱਟ ਫਾਰਮੈਟ ਦੀ ਪਾਲਣਾ ਕਰੇਗਾ, ਜਾਂ ਸਿਰਫ਼ ਮੰਗਲਵਾਰ ਨੂੰ ਹੀ?

ਚਾਰ ਫਾਲਬੈਕ ਪੈਟਰਨ ਜੋ ਕੰਮ ਕਰਦੇ ਹਨ

ਹਰ ਅਸਫਲਤਾ ਇੱਕੋ ਜਿਹੇ ਇਲਾਜ ਦੀ ਹੱਕਦਾਰ ਨਹੀਂ ਹੁੰਦੀ। ਫਾਲਬੈਕ ਕਿਸਮਾਂ ਦਾ ਇੱਕ ਟੂਲਕਿੱਟ ਬਣਾਓ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸੋਚ-ਸਮਝ ਕੇ ਲਾਗੂ ਕਰੋ।

ਰੀਟ੍ਰਾਈ ਫਾਲਬੈਕ (Retry fallback)। ਅਸਥਾਈ ਨੈੱਟਵਰਕ ਗਲਤੀਆਂ ਅਤੇ ਪ੍ਰੋਵਾਈਡਰ ਦੀਆਂ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਲਈ, ਐਕਸਪੋਨੈਂਸ਼ੀਅਲ ਬੈਕਆਫ (exponential backoff) ਦੇ ਨਾਲ ਉਸੇ ਮਾਡਲ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਗਲਤ ਆਊਟਪੁੱਟ ਜਾਂ ਕੰਟੈਕਸਟ ਓਵਰਫਲੋਅ 'ਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ — ਇੱਕੋ ਹੀ ਖਰਾਬ ਪ੍ਰੋਂਪਟ ਨੂੰ ਦੋ ਵਾਰ ਭੇਜਣ ਨਾਲ ਬਹੁਤ ਘੱਟ ਮਦਦ ਮਿਲਦੀ ਹੈ।

ਤူਲਯਿਕ ਫਾਲਬੈਕ (Equivalent fallback)। ਜਦੋਂ ਤੁਹਾਡਾ ਮੁੱਖ ਪ੍ਰੋਵਾਈਡਰ ਬੰਦ ਹੋਵੇ ਜਾਂ ਉਸਦੀ ਗਤੀ ਘੱਟ (throttled) ਹੋਵੇ, ਤਾਂ ਕਿਸੇ ਦੂਜੇ ਪ੍ਰੋਵਾਈਡਰ ਦੇ ਸਮਾਨ ਮਾਡਲ 'ਤੇ ਬਦਲ ਜਾਓ। ਇੱਕ ਫਰੰਟੀਅਰ ਮਾਡਲ ਤੋਂ ਲਗਭਗ ਇੱਕੋ ਜਿਹੀ ਸ਼੍ਰੇਣੀ ਦੇ ਦੂਜੇ ਮਾਡਲ 'ਤੇ ਜਾਣ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਘੱਟ ਪ੍ਰੋਂਪਟ ਰੀ-ਰਾਈਟਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਆਊਟਪੁੱਟ ਦੀ ਗੁਣਵੱਤਾ ਬਣੀ ਰਹਿੰਦੀ ਹੈ।

ਸਸਤਾ ਫਾਲਬੈਕ (Cheaper fallback)। ਗੈਰ-ਮਹੱਤਵਪੂਰਨ ਕੰਮਾਂ ਲਈ ਘੱਟ ਲਾਗਤ ਵਾਲਾ ਮਾਡਲ ਰਾਖਵਾਂ ਰੱਖੋ। ਜੇਕਰ ਸਸਤਾ ਵਿਕਲਪ ਸੰਘਰਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਘੱਟ-ਮੁੱਲ ਦੇ ਕੰਮਾਂ 'ਤੇ ਪ੍ਰੀਮੀਅਮ ਟੋਕਨ ਖਰਚਣ ਦੀ ਬਜਾਏ ਫੀਚਰ ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਘਟਾ ਦਿਓ।

ਮਜ਼ਬੂਤ ਫਾਲਬੈਕ (Stronger fallback)। ਇਹ ਉਲਟਾ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਜ਼ਰੂਰੀ ਹੈ। ਜਦੋਂ ਇੱਕ ਮਿਡ-ਟੀਅਰ ਮਾਡਲ ਲਗਾਤਾਰ ਗੁੰਝਲਦਾਰ ਤਰਕ, ਬਹੁ-ਪੜਾਅ ਵਾਲੀ ਗਣਿਤ, ਜਾਂ ਸੂਖਮ ਕਾਨੂੰਨੀ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਵਧੇਰੇ ਸਮਰੱਥ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਸਦੀ ਵਰਤੋਂ ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਯੂਜ਼ਰ ਪਾਥਾਂ ਲਈ ਬਹੁਤ ਘੱਟ ਕਰੋ ਜਿੱਥੇ ਸਹੀ ਹੋਣਾ ਮਾਲੀਆ ਜਾਂ ਸੁਰੱਖਿਆ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ।

ਆਪਣੇ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਲੌਜਿਕ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ

ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਵਿੱਚ ਦਰਜਨਾਂ try-catch ਬਲਾਕਾਂ ਵਿੱਚ ਫਾਲਬੈਕ ਲੌਜਿਕ ਨੂੰ ਖਿਲਾਰੋ ਨਾ। ਰੂਟਿੰਗ ਨੂੰ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਵਜੋਂ ਮੰਨੋ। ਇੱਕ ਮਿਡਲਵੇਅਰ ਲੇਅਰ ਬਣਾਓ ਜੋ ਕੰਮ ਦੀਆਂ ਕਿਸਮਾਂ ਨੂੰ ਮਾਡਲਾਂ ਦੀਆਂ ਕ੍ਰਮਵਾਰ ਸੂਚੀਆਂ ਨਾਲ ਜੋੜਦੀ ਹੈ, ਜਿਸ ਵਿੱਚੋਂ ਹਰੇਕ ਦੀ ਆਪਣੀ ਟਾਈਮਆਊਟ ਸੀਮਾ, ਰੀਟ੍ਰਾਈ ਪਾਲਿਸੀ ਅਤੇ ਸਰਕਟ ਬ੍ਰੇਕਰ ਹੋਵੇ।

ਫਾਲਬੈਕ ਇਵੈਂਟਸ ਨੂੰ ਪ੍ਰਮੁੱਖ ਮੈਟ੍ਰਿਕਸ ਵਜੋਂ ਟਰੈਕ ਕਰੋ। ਗਲਤੀਆਂ ਦੀ ਦਰ (error rates) ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਮਾਡਲ ਕਦੋਂ ਬੰਦ ਹੈ; ਫਾਲਬੈਕ ਦੀ ਦਰ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਮਾਡਲ ਕੰਮ ਲਈ ਕਦੋਂ ਗਲਤ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਸਿਸਟਮ 30 ਜਾਂ 40 ਪ੍ਰਤੀਸ਼ਤ ਸਮੇਂ ਫਾਲਬੈਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਮੁੱਖ ਮਾਡਲ ਕੰਮ ਦੇ ਬੋਝ ਦੇ ਅਨੁਕੂਲ ਨਹੀਂ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਮਾਡਲ ਦੀ ਚੋਣ ਦੀ ਮੁੜ-ਜਾਂਚ ਕਰਨ ਦਾ ਸੰਕੇਤ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਤੁਹਾਡੀ ਗਲਤੀ ਨੂੰ ਸੰਭਾਲਣ (error handling) ਦਾ।

ਸਪਸ਼ਟ ਬਜਟ ਨਿਰਧਾਰਤ ਕਰੋ। ਫਾਲਬੈਕ ਕਦੇ ਵੀ ਬਲੈਂਕ ਚੈੱਕ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਜੇਕਰ ਤੁਸੀਂ ਲੋਡ ਦੇ ਅਧੀਨ ਪ੍ਰੀਮੀਅਮ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਪ੍ਰਤੀ ਮਿੰਟ ਵਧਾਈਆਂ ਗਈਆਂ ਰਿਕਵੈਸਟਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੀਮਤ ਕਰੋ। ਆਪਣੇ ਵਾਲਿਟ ਦੀ ਰੱਖਿਆ ਉਸੇ ਸਖ਼ਤੀ ਨਾਲ ਕਰੋ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਆਪਣੇ ਅਪ-ਟਾਈਮ (uptime) ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹੋ।

ਅਸਲ ਟੈਸਟ

ਤੁਸੀਂ ਡੈਮੋ ਲਈ ਨਹੀਂ ਬਣਾ ਰਹੇ ਹੋ। ਤੁਸੀਂ ਮੰਗਲਵਾਰ ਦੁਪਹਿਰ 3 ਵਜੇ ਲਈ ਬਣਾ ਰਹੇ ਹੋ, ਜਦੋਂ API ਸੁਸਤ ਹੋਵੇ, ਯੂਜ਼ਰ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੋਵੇ, ਅਤੇ ਫਾਈਨਾਂਸ ਟੀਮ ਨੇ ਹੁਣੇ ਪੁੱਛਿਆ ਹੋਵੇ ਕਿ AI ਬਿੱਲ ਦੁੱਗਣਾ ਕਿਉਂ ਹੋ ਗਿਆ। ਇੱਕ ਪਰਿਪੱਕ ਫਾਲਬੈਕ ਰਣਨੀਤੀ ਉਤਪਾਦ ਨੂੰ ਸਹੀ ਰੱਖਦੀ ਹੈ, ਯੂਜ਼ਰ ਅਨੁਭਵ ਨੂੰ ਇਕਸਾਰ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਤੁਹਾਡੀਆਂ ਲਾਗਤਾਂ ਨੂੰ ਅਨੁਮਾਨਿਤ ਰੱਖਦੀ ਹੈ।

ਆਪਣੇ ਮੁੱਖ ਮਾਡਲ ਦੀ ਚੋਣ ਧਿਆਨ ਨਾਲ ਕਰੋ। ਪਰ ਜਦੋਂ ਇਹ ਤੁਹਾਨੂੰ ਨਿਰਾਸ਼ ਕਰਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ, ਇਸ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵਿੱਚ ਦੁੱਗਣਾ ਸਮਾਂ ਲਗਾਓ।

ਸਰੋਤ: How to Design AI Model Fallback Rules for Multi-Model Apps

ਕਮਿਊਨਿਟੀ: GyaanSetu AI on Telegram