ਇਵੈਲ-ਡਰਾਈਵਨ ਏਜੰਟ ਡਿਵੈਲਪਮੈਂਟ: ਮੈਂ ਕਿਵੇਂ 'ਵਾਈਬਸ' ਦੇ ਆਧਾਰ 'ਤੇ ਪ੍ਰੋਂਪਟ ਟਿਊਨ ਕਰਨਾ ਬੰਦ ਕੀਤਾ

ਮੈਂ ਇੱਕ ਪ੍ਰੋਂਪਟ ਬਦਲਿਆ। ਅਗਲੀ ਵਾਰ ਨਤੀਜਾ ਬਿਹਤਰ ਲੱਗਿਆ। ਕੀ ਉਸ ਬਦਲਾਅ ਨੇ ਮਦਦ ਕੀਤੀ, ਜਾਂ ਮੇਰੀ ਕਿਸਮਤ ਚੰਗੀ ਸੀ?

ਲੰਬੇ ਸਮੇਂ ਤੱਕ, ਮੇਰਾ ਜਵਾਬ ਸੀ "ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ।" ਮੈਂ ਇੱਕ ਕਮਾਂਡ ਵਿੱਚ ਥੋੜ੍ਹਾ ਬਦਲਾਅ ਕਰਦਾ, ਪਾਈਪਲਾਈਨ ਚਲਾਉਂਦਾ, ਉਸ ਨੂੰ ਸਫਲ ਹੁੰਦੇ ਦੇਖਦਾ ਅਤੇ ਫਿਰ ਉਸ ਨੂੰ ਲਾਂਚ ਕਰ ਦਿੰਦਾ। ਇਹ 'ਵਾਈਬਸ-ਅਧਾਰਿਤ' (vibes-based) ਇੰਜੀਨੀਅਰਿੰਗ ਹੈ। ਏਜੰਟ ਬਣਾਉਣ ਵਾਲਾ ਲਗਭਗ ਹਰ ਕੋਈ ਇਹੀ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸ ਦਾ ਵਿਕਲਪ ਮੁਸ਼ਕਲ ਲੱਗਦਾ ਹੈ।

ਪਰ ਕੋਡਿੰਗ ਏਜੰਟ ਨਾਨ-ਡਿਟਰਮਿਨਿਸਟਿਕ (non-deterministic) ਹੁੰਦੇ ਹਨ। ਤੁਸੀਂ ਇੱਕੋ ਕੰਮ ਨੂੰ ਦੋ ਵਾਰ ਚਲਾ ਸਕਦੇ ਹੋ ਅਤੇ ਦੋ ਵੱਖਰੇ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਇੱਕ ਵਾਰ ਦਾ ਚੰਗਾ ਨਤੀਜਾ ਤੁਹਾਨੂੰ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਤੁਹਾਡਾ ਬਦਲਾਅ ਕੰਮ ਕਰ ਗਿਆ ਜਾਂ ਸਿਰਫ਼ ਕਿਸਮਤ ਸਾਥ ਦੇ ਗਈ।

ਮੈਂ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਦੇ ਅਨੁਸ਼ਾਸਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਨੂੰ ਹੱਲ ਕੀਤਾ। ਮੈਂ ਆਪਣੇ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਕਵਰ ਕਰਨ ਲਈ ਇੱਕ ਇਵੈਲੂਏਸ਼ਨ ਫਰੇਮਵਰਕ (evaluation framework) ਤਿਆਰ ਕੀਤਾ।

ਇਹ ਫਰੇਮਵਰਕ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ:

• ਟਾਰਗੇਟ (Target): ਇੱਕ ਫ੍ਰੋਜ਼ਨ ਕੋਡਬੇਸ (frozen codebase)। ਇਹ ਉਹੀ ਰਹਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਸਕੋਰਾਂ ਦੀ ਤੁਲਨਾ ਕੀਤੀ ਜਾ ਸਕੇ। • ਟਾਸਕ (Task): ਇੱਕ ਪ੍ਰੋਂਪਟ ਅਤੇ ਇੱਕ ਓਰੇਕਲ (oracle) ਦੇ ਨਾਲ ਇੱਕ ਖਾਸ ਬੈਂਚਮਾਰਕ ਆਈਟਮ। • ਓਰੇਕਲ (Oracle): ਇੱਕ ਡਿਟਰਮਿਨਿਸਟਿਕ ਚੈੱਕ। ਇਹ ਸ਼ੈੱਲ ਕਮਾਂਡਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਪਾਸ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। • ਵੇਰੀਐਂਟ (Variant): ਉਹ ਖਾਸ ਬਦਲਾਅ ਜਿਸਦੀ ਤੁਸੀਂ ਜਾਂਚ ਕਰ ਰਹੇ ਹੋ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਨਵਾਂ ਪਲਾਨਰ। • ਟ੍ਰਾਇਲ (Trial): ਇੱਕ ਸਿੰਗਲ ਰਨ। ਮੈਂ ਰੈਂਡਮਨੈੱਸ (randomness) ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਲਈ ਹਰ ਟਾਸਕ ਨੂੰ ਕਈ ਵਾਰ ਚਲਾਉਂਦਾ ਹਾਂ।

ਮੈਂ ਵੱਖ-ਵੱਖ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਫੜਨ ਲਈ ਦੋ ਤਰ੍ਹਾਂ ਦੇ ਸਕੋਰਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ:

• ਕੋਡ ਗ੍ਰੇਡਰ (Code Graders - Deterministic): ਇਹ ਟੈਸਟ ਪਾਸ ਰੇਟ, ਲਾਗਤ, ਸਮਾਂ ਅਤੇ ਫਾਈਲ ਬਦਲਾਅ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ।
• LLM ਜੱਜ (LLM Judge - Probabilistic): ਇੱਕ ਵੱਖਰਾ, ਫਿਕਸਡ ਮਾਡਲ ਸਪੈਕ (spec) ਦੀ ਗੁਣਵੱਤਾ ਅਤੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਦੀ ਸ਼ੁੱਧਤਾ ਨੂੰ ਸਕੋਰ ਕਰਦਾ ਹੈ।

ਕੋਡ ਗ੍ਰੇਡਰ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਕੋਡ ਚੱਲ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੱਜ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੋਡ ਕਿੰਨਾ ਚੰਗਾ ਹੈ। ਤੁਹਾਨੂੰ ਦੋਵਾਂ ਦੀ ਲੋੜ ਹੈ।

ਮੈਂ ਔਸਤ (averages) ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਵੀ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਮੀਨ (means) ਏਜੰਟਾਂ ਬਾਰੇ ਝੂਠ ਬੋਲਦੇ ਹਨ। ਜੇਕਰ ਕੋਈ ਟਾਸਕ 3 ਵਿੱਚੋਂ 2 ਵਾਰ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਠੀਕ ਲੱਗਦਾ ਹੈ। ਪਰ ਇਹ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ, ਮੈਂ ਦੋ ਮੈਟ੍ਰਿਕਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ:

• pass@k: ਕੀ ਏਜੰਟ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ ਸਫਲ ਹੋਇਆ? (ਸਮਰੱਥਾ/Capability)
• pass^k: ਕੀ ਏਜੰਟ ਹਰ ਵਾਰ ਸਫਲ ਹੋਇਆ? (ਭਰੋਸੇਯੋਗਤਾ/Reliability)

pass^k ਵਿੱਚ ਵਾਧਾ ਹੀ ਅਸਲ ਜਿੱਤ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਏਜੰਟ ਨੂੰ ਸਥਿਰ (consistent) ਬਣਾਇਆ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਕਿਸਮਤ ਨਾਲ।

ਸਿਸਟਮ ਨੂੰ ਤੇਜ਼ ਰੱਖਣ ਲਈ, ਮੈਂ ਅਜਿਹੇ ਔਖੇ ਟਾਸਕ ਜੋੜਦਾ ਹਾਂ ਜਿਨ੍ਹਾਂ ਲਈ ਡੂੰਘੀ ਸਮਝ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਕੋਈ ਏਜੰਟ ਅਸਲ ਬੱਗ (bug) 'ਤੇ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਮੈਂ ਉਸ ਅਸਫਲਤਾ ਨੂੰ ਇੱਕ ਸਥਾਈ ਟਾਸਕ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹਾਂ। ਇਹ ਇੱਕ 'ਕਲੋਜ਼ਡ ਲੂਪ' (closed loop) ਬਣਾਉਂਦਾ ਹੈ। ਜਿਵੇਂ-ਜਿਵੇਂ ਏਜੰਟ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ, ਬੈਂਚਮਾਰਕ ਵੀ ਔਖਾ ਹੁੰਦਾ ਜਾਂਦਾ ਹੈ।

ਇਹ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਬਣਾਉਣ ਵਿੱਚ ਬਹੁਤ ਮਿਹਨਤ ਲੱਗਦੀ ਹੈ, ਪਰ ਇਹ ਮੇਰੇ ਦੁਆਰਾ ਬਣਾਈ ਗਈ ਸਭ ਤੋਂ ਵੱਧ ਫਾਇਦੇਮੰਦ ਚੀਜ਼ ਹੈ। ਇਸ ਨੇ "ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਬਿਹਤਰ ਹੈ" ਨੂੰ "ਇਹ ਘੱਟ ਲਾਗਤ 'ਤੇ 20% ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਹੈ" ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ।

ਕੋਡਿੰਗ ਏਜੰਟਾਂ ਦਾ ਡੈਮੋ ਦੇਣਾ ਆਸਾਨ ਹੈ ਪਰ ਉਹਨਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਡੈਮੋ ਤੋਂ ਅੱਗੇ ਵਧਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਮਾਪਣ (measure) ਦਾ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

Source: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189

Optional learning community: https://t.me/GyaanSetuAi