ਇੱਕ ਇਕੱਲੇ ਡਿਵੈਲਪਰ ਦੇ ਤਿੰਨ Claude ਮਾਡਲਾਂ ਦੇ ਪ੍ਰਯੋਗ ਨੇ ਮਹੀਨਾਵਾਰ API ਲਾਗਤਾਂ ਵਿੱਚ 35% ਦੀ ਕਮੀ ਕੀਤੀ ਅਤੇ ਮੱਧਮ (median) ਟਾਸਕ ਲੇਟੈਂਸੀ ਨੂੰ 42 ਸੈਕਿੰਡ ਤੋਂ ਘਟਾ ਕੇ 27 ਸੈਕਿੰਡ ਕਰ ਦਿੱਤਾ। ਸਧਾਰਨ, ਘੱਟ ਅਸਪਸ਼ਟਤਾ (low-ambiguity) ਵਾਲੇ ਕੰਮਾਂ ਨੂੰ ਸਸਤੇ Haiku ਮਾਡਲ ਨੂੰ, ਰੁਟੀਨ ਕੰਮਾਂ ਨੂੰ Sonnet ਨੂੰ ਭੇਜ ਕੇ, ਅਤੇ ਭਾਰੀ Opus ਨੂੰ ਉੱਚ-ਜੋਖਮ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਲਈ ਰਾਖਵਾਂ ਰੱਖ ਕੇ, ਲੇਖਕ ਨੇ ਸਾਬਤ ਕਰ ਦਿੱਤਾ ਕਿ "ਹਰ ਚੀਜ਼ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਮਾਡਲ" ਦੀ ਆਦਤ ਬਹੁਤ ਮਹਿੰਗੀ ਪੈਂਦੀ ਹੈ।
ਰੂਟਿੰਗ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ
ਲੇਖਕ ਇੱਕ ਆਟੋਨੋਮਸ ਕੋਡਿੰਗ ਏਜੰਟ ਚਲਾਉਂਦਾ ਹੈ ਜਿਸਨੂੰ ਡਿਵੈਲਪਮੈਂਟ ਟਾਸਕਾਂ ਦੀ ਲਗਾਤਾਰ ਲੜੀ ਮਿਲਦੀ ਹੈ—ਜਿਵੇਂ ਕਿ lint ਫਿਕਸ, ਫੀਚਰ ਐਡੀਸ਼ਨ, ਸੁਰੱਖਿਆ ਸਮੀਖਿਆਵਾਂ (security reviews), ਅਤੇ ਡੂੰਘੇ ਡੀਬੱਗਿੰਗ ਸੈਸ਼ਨ। ਕਈ ਮਹੀਨਿਆਂ ਤੱਕ, ਏਜੰਟ ਹਰ ਰਿਕਵੈਸਟ ਨੂੰ Opus (Claude ਦਾ ਸਭ ਤੋਂ ਸਮਰੱਥ ਮਾਡਲ) ਨੂੰ ਭੇਜਦਾ ਰਿਹਾ, ਇਹ ਮੰਨਦੇ ਹੋਏ ਕਿ ਉੱਚ ਗੁਣਵੱਤਾ ਹਮੇਸ਼ਾ ਕੀਮਤ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇਗੀ। Opus ਪ੍ਰਤੀ ਟੋਕਨ (token) ਇੱਕ ਉੱਚ ਕੀਮਤ ਲੈਂਦਾ ਹੈ, ਜਿਸ ਕਾਰਨ ਬਿੱਲ ਬੇਕਾਬੂ ਹੋ ਰਿਹਾ ਸੀ।
ਜਦੋਂ ਲੇਖਕ ਨੇ ਇੱਕ ਤਰਤੀਬਵਾਰ (tiered) ਰੂਟਿੰਗ ਸਕੀਮ ਸ਼ੁਰੂ ਕੀਤੀ, ਤਾਂ ਖਰਚਾ ਅਸਲ ਪੱਧਰ ਦੇ 65% ਤੱਕ ਡਿੱਗ ਗਿਆ ਅਤੇ ਕੁੱਲ ਟਾਸਕਾਂ ਵਿੱਚੋਂ Opus ਦੀ ਵਰਤੋਂ ਘਟ ਕੇ 11% ਰਹਿ ਗਈ।
ਤਿੰਨ-ਦਰਜਾ (three-tier) ਪ੍ਰਣਾਲੀ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ
ਰੂਟਿੰਗ ਦਾ ਤਰਕ ਅਸਪਸ਼ਟਤਾ (ambiguity) 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਇਸ 'ਤੇ ਕਿ ਇੱਕ ਟਾਸਕ ਵਿੱਚ ਕੋਡ ਦੀਆਂ ਕਿੰਨੀਆਂ ਲਾਈਨਾਂ ਸ਼ਾਮਲ ਹਨ। ਲੇਖਕ ਨੇ ਤਿੰਨ ਸ਼੍ਰੇਣੀਆਂ (buckets) ਤੈਅ ਕੀਤੀਆਂ:
- Haiku – ਘੱਟ ਅਸਪਸ਼ਟਤਾ ਵਾਲੇ, ਨਿਸ਼ਚਿਤ (deterministic) ਕੰਮ। ਉਦਾਹਰਨਾਂ: lint ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਠੀਕ ਕਰਨਾ, ਵੇਰੀਏਬਲਜ਼ ਦਾ ਨਾਮ ਬਦਲਣਾ, ਲੌਗ ਫਾਈਲਾਂ ਦਾ ਸਾਰ (summarising) ਕੱਢਣਾ। ਸਹੀ ਜਵਾਬ ਆਮ ਤੌਰ 'ਤੇ ਕੋਡ ਜਾਂ ਟੈਕਸਟ ਦੀ ਇੱਕ ਸਿੰਗਲ ਲਾਈਨ ਹੁੰਦਾ ਹੈ।
- Sonnet – ਡਿਫੌਲਟ ਕੰਮ ਕਰਨ ਵਾਲਾ ਮਾਡਲ। ਇਹ ਫੀਚਰ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ, ਰੁਟੀਨ ਬੱਗ ਫਿਕਸ, ਅਤੇ ਸਟੈਂਡਰਡ ਰੈਫੈਕਟਰਿੰਗ (refactors) ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਜਿੱਥੇ ਸਮੱਸਿਆ ਸਪਸ਼ਟ ਹੁੰਦੀ ਹੈ ਪਰ ਹੱਲ ਵਿੱਚ ਕਈ ਕਦਮ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ।
- Opus – ਉੱਚ-ਜੋਖਮ ਵਾਲਾ, ਉੱਚ-ਅਸਪਸ਼ਟਤਾ ਵਾਲਾ ਕੰਮ। ਆਰਕੀਟੈਕਚਰ ਫੈਸਲੇ, ਸੁਰੱਖਿਆ ਆਡਿਟ, ਗੁੰਝਲਦਾਰ ਡੀਬੱਗਿੰਗ ਸੈਸ਼ਨ, ਜਾਂ ਕੋਈ ਵੀ ਅਜਿਹਾ ਟਾਸਕ ਜਿੱਥੇ ਸਹੀ ਰਸਤਾ ਅਸਪਸ਼ਟ ਹੋਵੇ ਅਤੇ ਇੱਕ ਗਲਤੀ ਪਾਈਪਲਾਈਨ ਨੂੰ ਤੋੜ ਸਕਦੀ ਹੋਵੇ।
ਇੱਕ ਸਟੈਟਿਕ ਲੁੱਕਅੱਪ ਟੇਬਲ ਇਹਨਾਂ ਨਿਯਮਾਂ ਦੇ ਅਧਾਰ 'ਤੇ ਹਰ ਆਉਣ ਵਾਲੀ ਰਿਕਵੈਸਟ ਨੂੰ ਉਚਿਤ ਮਾਡਲ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਲੇਖਕ ਨੇ ਇੱਕ "ਸਮਾਰਟ" ਮਾਡਲ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜੋ ਤੁਰੰਤ (on the fly) ਤਰਤੀਬ ਦਾ ਫੈਸਲਾ ਕਰਦਾ, ਪਰ ਵਾਧੂ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਨੇ ਸਾਰੀ ਬਚਤ ਖਤਮ ਕਰ ਦਿੱਤੀ। ਸਧਾਰਨ ਸਟੈਟਿਕ ਨਿਯਮਾਂ ਨੇ ਲਗਭਗ 80% ਕੰਮ ਨੂੰ ਕਵਰ ਕੀਤਾ ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਸਸਤਾ ਅਤੇ ਭਵਿੱਖਬਾਣੀਯੋਗ (predictable) ਰੱਖਿਆ।
ਐਸਕਲੇਸ਼ਨ ਸੇਫਟੀ ਨੈੱਟ (The escalation safety net)
ਸਸਤੇ ਮਾਡਲ ਅਜੇ ਵੀ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ। Haiku ਜਾਂ Sonnet ਦੇ ਗਲਤ ਜਵਾਬ ਕਾਰਨ ਬਿਲਡ (build) ਨੂੰ ਵਿਗੜਨ ਤੋਂ ਬਚਾਉਣ ਲਈ, ਸਿਸਟਮ ਦੋ ਅਸਫਲਤਾਵਾਂ ਤੋਂ ਬਾਅਦ ਰਿਕਵੈਸਟ ਨੂੰ ਅਗਲੇ ਪੱਧਰ (tier) 'ਤੇ ਭੇਜ ਦਿੰਦਾ ਹੈ। ਇਹ ਸੇਫਟੀ ਨੈੱਟ ਗਲਤੀਆਂ ਨੂੰ ਜਲਦੀ ਫੜ ਲੈਂਦਾ ਹੈ ਅਤੇ ਮਨੁੱਖੀ ਦਖਲਅੰਦਾਜ਼ੀ ਤੋਂ ਬਿਨਾਂ ਪਾਈਪਲਾਈਨ ਨੂੰ ਸੁਚਾਰੂ ਰੂਪ ਵਿੱਚ ਚਲਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ।
ਅੰਕੜੇ ਜੋ ਆਪਣੇ ਆਪ ਬੋਲਦੇ ਹਨ
ਤਰਤੀਬਵਾਰ ਰੂਟਰ ਚਲਾਉਣ ਦੇ ਚਾਰ ਹਫ਼ਤਿਆਂ ਬਾਅਦ, ਲੇਖਕ ਨੇ ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਦਰਜ ਕੀਤਾ:
- API ਖਰਚਾ ਅਸਲ ਲਾਗਤ ਦੇ 65% ਤੱਕ ਡਿੱਗ ਗਿਆ (35% ਦੀ ਕਮੀ)।
- ਮੱਧਮ (Median) ਟਾਸਕ ਪੂਰਾ ਕਰਨ ਦਾ ਸਮਾਂ 42 ਸੈਕਿੰਡ ਤੋਂ ਘਟ ਕੇ 27 ਸੈਕਿੰਡ ਹੋ ਗਿਆ।
- Opus ਦੀ ਵਰਤੋਂ ਹਰ ਰਿਕਵੈਸਟ ਨੂੰ ਸੰਭਾਲਣ ਤੋਂ ਘਟ ਕੇ ਕੁੱਲ ਟਾਸਕਾਂ ਦੇ ਸਿਰਫ 11% ਰਹਿ ਗਈ।
ਇਹ ਅੰਕੜੇ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਮੈਂਟ ਕੰਮ ਗੁਣਵੱਤਾ ਵਿੱਚ သိਹੇਯੋਗ ਗਿਰਾਵਟ ਤੋਂ ਬਿਨਾਂ ਸਸਤੇ ਮਾਡਲਾਂ ਨੂੰ ਸੌਂਪਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਸਭ ਤੋਂ ਔਖੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਅਜੇ ਵੀ Opus ਦੇ ਵੱਡੇ ਕੰਟੈਕਸ ਵਿੰਡੋ (context window) ਦਾ ਲਾਭ ਮਿਲਦਾ ਹੈ।
ਹੋਰ ਡਿਵੈਲਪਰਾਂ ਲਈ ਸਬਕ
- ਘੱਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਉੱਚ ਤੋਂ ਨਹੀਂ। ਜ਼ਿਆਦਾਤਰ ਰੋਜ਼ਾਨਾ ਕੋਡਿੰਗ ਦੇ ਕੰਮਾਂ ਲਈ ਸਭ ਤੋਂ ਸ਼ਕਤੀਸ਼ਾਲੀ ਮਾਡਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਅਸਪਸ਼ਟ ਟਾਸਕਾਂ ਲਈ Sonnet ਨੂੰ ਡਿਫੌਲਟ ਬਣਾਉਣ ਨਾਲ Haiku ਰਾਹੀਂ ਸਭ ਕੁਝ ਕਰਨ ਦੇ ਮੁਕਾਬਲੇ ਜ਼ਿਆਦਾ ਪੈਸੇ ਬਚੇ।
- ਔਖਾਈ ਨੂੰ ਮਾਪੋ, ਆਕਾਰ ਨੂੰ ਨਹੀਂ। ਇੱਕ ਲਾਈਨ ਦਾ ਰੇਸ-ਕੰਡੀਸ਼ਨ (race-condition) ਫਿਕਸ ਇੱਕ ਪੂਰੀ ਫਾਈਲ ਨੂੰ ਰੈਫੈਕਟਰ ਕਰਨ ਨਾਲੋਂ ਔਖਾ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਅਧਾਰ 'ਤੇ ਰੂਟ ਕਰੋ ਕਿ ਹੱਲ ਕਿੰਨਾ ਅਸਪਸ਼ਟ ਹੈ, ਨਾ ਕਿ ਬਦਲੀਆਂ ਗਈਆਂ ਲਾਈਨਾਂ ਦੀ ਗਿਣਤੀ ਦੇ ਅਧਾਰ 'ਤੇ।
- ਐਸਕਲੇਸ਼ਨ ਦਰ (escalation rate) 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ। ਐਸਕਲੇਸ਼ਨਾਂ ਦੀ ਵਧਦੀ ਗਿਣਤੀ ਇਹ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ ਕਿ ਸਟੈਟਿਕ ਨਿਯਮ ਹੁਣ ਕੰਮ ਦੇ ਬੋਝ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ। ਸਸਤੇ ਮਾਡਲਾਂ ਦੁਆਰਾ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਵਧੇਰੇ ਅਸਫਲਤਾਵਾਂ ਪੈਦਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸ਼੍ਰੇਣੀਆਂ (buckets) ਨੂੰ ਐਡਜਸਟ ਕਰੋ।
ਸਭ ਤੋਂ ਮਹਿੰਗੇ ਮਾਡਲ ਨੂੰ ਸਭ ਤੋਂ ਔਖੀਆਂ ਸਮੱਸਿਆਵਾਂ ਲਈ ਰਾਖਵਾਂ ਰੱਖਣਾ ਅਤੇ ਬਾਕੀ ਕੰਮ ਸਸਤੇ ਮਾਡਲਾਂ ਨੂੰ ਸੌਂਪਣਾ AI-ਸਹਾਇਤਾ ਪ੍ਰਾਪਤ ਡਿਵੈਲਪਮੈਂਟ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਕਿਫਾਇਤੀ ਰੱਖਦਾ ਹੈ। ਅਸਲ ਫਾਇਦਾ ਇੱਕ ਅਨੁਸ਼ਾਸਿਤ ਰੂਟਿੰਗ ਰਣਨੀਤੀ ਵਿੱਚ ਹੈ ਜੋ ਸਹੀ ਕੰਮ ਲਈ ਸਹੀ ਸੰਦ (tool) ਦੀ ਚੋਣ ਕਰਦੀ ਹੈ।