HarnessDev: LLMs ਆਪਣਾ ਖੁਦ ਦਾ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਬਣਾ ਰਹੇ ਹਨ
ByteDance ਅਤੇ ਯੂਨੀਵਰਸਿਟੀਆਂ ਦੇ ਇੱਕ ਸਮੂਹ ਨੇ HarnessDev ਲਾਂਚ ਕੀਤਾ ਹੈ, ਜੋ ਇੱਕ ਅਜਿਹਾ ਫਰੇਮਵਰਕ ਹੈ ਜੋ ਲਾਰਜ ਲੈਂਗੂਏਜ ਮਾਡਲਾਂ (LLMs) ਨੂੰ ਆਪਣੇ "ਏਜੰਟ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ" ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਨੂੰ Agent Harnesses ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਟੀਮ ਇੱਕ LLM ਨੂੰ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਸਟਾਰਟਰ ਕਿੱਟ ਦਿੰਦੀ ਹੈ ਅਤੇ ਬਾਕੀ ਦਾ ਕੰਮ ਖੁਦ ਕਰਨ ਦਿੰਦੀ ਹੈ, ਜੋ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਵੇਂ AI ਉਸ ਕੰਟਰੋਲ ਲੇਅਰ ਦਾ ਨਿਰਮਾਣ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਆਪਣੇ ਟੂਲ-ਯੂਜ਼ ਲੂਪਸ, ਵੈਰੀਫਿਕੇਸ਼ਨ ਸਟੈਪਸ ਅਤੇ ਐਰਰ ਹੈਂਡਲਿੰਗ ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ—ਇੱਕ ਇਨਸਾਨ ਦੁਆਰਾ ਹਰ ਲਾਈਨ ਟਾਈਪ ਕੀਤੇ ਬਿਨਾਂ।
ਖੁਦ-ਬਣਾਇਆ ਹਾਰਨੈਸ (harness) ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
AI ਏਜੰਟ ਸਿੰਗਲ-ਪ੍ਰੋਂਪਟ ਸਹਾਇਕਾਂ ਤੋਂ ਬਦਲ ਕੇ ਮਲਟੀ-ਸਟੈਪ ਵਰਕਰਾਂ ਵਿੱਚ ਬਦਲ ਗਏ ਹਨ ਜੋ APIs ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ, ਡੇਟਾਬੇਸ ਨੂੰ ਕੁਐਰੀ ਕਰਦੇ ਹਨ ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਜੋੜਦੇ ਹਨ। ਹੁਣ ਤੱਕ, ਡਿਵੈਲਪਰਾਂ ਨੇ ਉਹ ਆਰਕੇਸਟ੍ਰੇਸ਼ਨ ਕੋਡ ਖੁਦ ਤਿਆਰ ਕੀਤਾ ਸੀ ਜੋ ਮਾਡਲ ਨੂੰ ਦੱਸਦਾ ਸੀ ਕਿ ਸਰਚ ਟੂਲ ਕਦੋਂ ਕਾਲ ਕਰਨਾ ਹੈ, ਇੰਟਰਮੀਡੀਏਟ ਸਟੇਟ ਨੂੰ ਕਿਵੇਂ ਸਟੋਰ ਕਰਨਾ ਹੈ, ਅਤੇ ਅੰਤਿਮ ਉੱਤਰ ਦੀ ਪੁਸ਼ਟੀ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। HarnessDev ਇਸ ਮਾਡਲ ਨੂੰ ਉਲਟਾ ਦਿੰਦਾ ਹੈ: ਇੱਕ seed harness ਸਿਰਫ ਲੋੜੀਂਦੀ ਸਕੈਫੋਲਡਿੰਗ (scaffolding) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ—ਲੂਪਿੰਗ, ਟੂਲ ਚੁਣਨ ਅਤੇ ਸਟੇਟ ਨੂੰ ਟ੍ਰੈਕ ਕਰਨ ਲਈ ਬੁਨਿਆਦੀ ਫੰਕਸ਼ਨ—ਅਤੇ LLM ਇਸ ਨੂੰ ਇੱਕ ਫੁੱਲ-ਫੀਚਰਡ ਰਨਟਾਈਮ ਵਿੱਚ ਵਿਸਤਾਰ ਦਿੰਦਾ ਹੈ।
ਪੇਪਰ ਦੇ ਬੈਂਚਮਾਰਕ ਵਿੱਚ, ਮਾਡਲ ਨੇ 18 ਵੱਖਰੇ ਹਾਰਨੈਸ ਤਿਆਰ ਕੀਤੇ, ਜੋ ਕਿ ਅਸਲ ਸੀਡ (seed) ਵਿੱਚ 17,000 ਤੋਂ ਵੱਧ ਲਾਈਨਾਂ ਦਾ ਕੋਡ ਜੋੜਦੇ ਹਨ। ਹਰੇਕ ਹਾਰਨੈਸ ਨੇ ਇੱਕ ਕੰਮ ਦੇ ਪੂਰੇ ਜੀਵਨ-ਚੱਕਰ (life-cycle) ਦਾ ਪ੍ਰਬੰਧਨ ਕੀਤਾ: ਲੂਪਸ ਨੂੰ ਚਲਾਉਣਾ, ਸਹੀ ਟੂਲ ਚੁਣਨਾ, ਸੰਦਰਭ (context) ਬਣਾਈ ਰੱਖਣਾ, ਸਟੇਟ ਨੂੰ ਟ੍ਰੈਕ ਕਰਨਾ, ਨਤੀਜਿਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ, ਅਤੇ ਗਲਤੀਆਂ ਤੋਂ ਉਭਰਨਾ।
ਅਧਿਐਨ ਦੁਆਰਾ ਸਾਹਮਣੇ ਲਿਆਂਦੇ ਗਏ ਲੁਕਵੇਂ ਖਰਚੇ
ਅੰਕੜੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗਦੇ ਹਨ, ਪਰ ਲੇਖਕਾਂ ਨੇ ਚੇਤਾਵਨੀ ਦਿੱਤੀ ਹੈ ਕਿ ਸਿਰਫ਼ ਕੋਡ ਲਾਗੂ ਕਰ ਦੇਣਾ ਹੀ ਵਿਵਹਾਰਕ ਵਰਤੋਂ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ।
- ਅਣਵਰਤੇ ਕੰਪੋਨੈਂਟਸ (Unused components) – ਤਿਆਰ ਕੀਤੇ ਗਏ ਕੋਡ ਦਾ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਅਸਲ ਕੰਮ ਦੇ ਦੌਰਾਨ ਕਦੇ ਚੱਲਿਆ ਹੀ ਨਹੀਂ। LLM ਨੇ ਅਜਿਹੇ ਫੰਕਸ਼ਨ ਲਿਖੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਏਜੰਟ ਨੇ ਕਦੇ ਕਾਲ ਨਹੀਂ ਕੀਤਾ, ਜਿਸ ਨਾਲ ਕੋਡ ਬੇਸ ਵਧ ਗਿਆ ਪਰ ਕੋਈ ਮੁੱਲ ਨਹੀਂ ਪੈਦਾ ਹੋਇਆ।
- ਮਾਡਲ ਲੌਕ-ਇਨ (Model lock-in) – ਹਾਰਨੈਸ ਉਸ ਖਾਸ LLM ਦੇ ਅਨੁਕੂਲ ਹੋਣ ਦੀ ਪ੍ਰਵਿਰਤੀ ਰੱਖਦੇ ਸਨ ਜਿਸ ਨੇ ਉਹਨਾਂ ਨੂੰ ਬਣਾਇਆ ਸੀ। ਜਦੋਂ ਉਹੀ ਹਾਰਨੈਸ ਕਿਸੇ ਦੂਜੇ ਮਾਡਲ ਨੂੰ ਦਿੱਤਾ ਗਿਆ, ਤਾਂ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ သိਖਣਯੋਗ ਗਿਰਾਵਟ ਆਈ, ਜੋ ਇਹ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ ਕਿ ਆਟੋ-ਜਨਰੇਟਡ ਕੰਟਰੋਲ ਲੌਜਿਕ ਵਿੱਚ ਮਾਡਲ-ਵਿਸ਼ੇਸ਼ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ।
- ਵੈਰੀਫਿਕੇਸ਼ਨ ਦੀਆਂ ਕਮੀਆਂ (Verification gaps) – ਇੱਕ ਟੈਸਟ ਹਾਰਨੈਸ ਨੇ 99% (100 ਵਿੱਚੋਂ 99 ਵਾਰ) ਸਫਲਤਾ ਦਰ ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ, ਪਰ ਇਹ ਸਿਰਫ 48% ਸਮੇਂ ਹੀ ਸਹੀ ਸੀ। ਮਜ਼ਬੂਤ ਵੈਰੀਫਿਕੇਸ਼ਨ ਤੋਂ ਬਿਨਾਂ, ਇੱਕ ਏਜੰਟ ਭਰੋਸੇ ਨਾਲ ਗਲਤ ਉੱਤਰ ਦੇ ਸਕਦਾ ਹੈ।
- ਟੋਕਨ ਓਵਰਹੈੱਡ (Token overhead) – ਟੋਕਨ ਦੀ ਵਰਤੋਂ—ਜੋ ਕੰਪਿਊਟਿੰਗ ਲਾਗਤ ਦਾ ਇੱਕ ਪ੍ਰਤੀਕ ਹੈ—ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਬਦਲਦੀ ਰਹੀ। ਇੱਕੋ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇੱਕ ਹਾਰਨੈਸ ਨੂੰ ਦੂਜੇ ਨਾਲੋਂ ਸੱਤ ਗੁਣਾ ਜ਼ਿਆਦਾ ਟੋਕਨਾਂ ਦੀ ਲੋੜ ਸੀ, ਜੋ ਕਿ ਪ੍ਰੋਡਕਸ਼ਨ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਸਕੇਲੇਬਿਲਟੀ (scalability) ਬਾਰੇ ਚਿੰਤਾਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।
ਇਹ ਖੋਜਾਂ ਅਨੁਸ਼ਾਸਿਤ ਡਿਜ਼ਾਈਨ ਦੀ ਲੋੜ ਨੂੰ ਉਜਾਗਰ ਕਰਦੀਆਂ ਹਨ, ਭਾਵੇਂ ਕੋਡ ਇੱਕ LLM ਤੋਂ ਪੈਦਾ ਹੋਇਆ ਹੋਵੇ।
ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕੀ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ
- ਹਾਰਨੈਸ ਡਿਜ਼ਾਈਨ ਨੂੰ ਆਰਕੀਟੈਕਚਰ ਵਜੋਂ ਮੰਨੋ – ਮਾਡਲ ਦੇ "ਬਸ ਕੰਮ ਕਰਨ" 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। LLM ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਭਰਨ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਲੂਪ ਕੰਟਰੋਲ, ਟੂਲ ਚੋਣ, ਸਟੇਟ ਹੈਂਡਲਿੰਗ ਅਤੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲਈ ਸਪਸ਼ਟ ਮੋਡੀਊਲ ਤੈਅ ਕਰੋ।
- ਮਜ਼ਬੂਤ ਵੈਰੀਫਿਕੇਸ਼ਨ ਬਣਾਓ – ਅਜਿਹੇ ਸਪਸ਼ਟ ਚੈੱਕ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਏਜੰਟ ਦੇ ਦਾਅਵੇ ਦੀ ਤੁਲਨਾ ਗਰਾਊਂਡ ਟ੍ਰੂਥ (ground truth) ਜਾਂ ਕਿਸੇ ਦੂਜੇ ਮਾਡਲ ਨਾਲ ਕਰਦੇ ਹਨ। 99% ਸਵੈ-ਰਿਪੋਰਟ ਕੀਤੀ ਸਫਲਤਾ ਦਰ ਦੇ ਬਾਵਜੂਦ ਅਧਿਐਨ ਦੀ 48% ਸ਼ੁੱਧਤਾ ਇਹ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਵੈਰੀਫਿਕੇਸ਼ਨ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਸੋਚਣ ਵਾਲੀ ਚੀਜ਼ ਨਹੀਂ ਬਣਾਇਆ ਜਾ ਸਕਦਾ।
- ਟੋਕਨ ਬਜਟ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ – ਵਧੇਰੇ ਵਿਸਤ੍ਰਿਤ ਹਾਰਨੈਸ ਟੋਕਨਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਬਹੁਤ ਵਧਾ ਸਕਦੇ ਹਨ। ਲੁਕਵੇਂ ਖਰਚਿਆਂ ਦੇ ਵਾਧੇ ਤੋਂ ਬਚਣ ਲਈ ਵੱਖ-ਵੱਖ ਹਾਰਨੈਸ ਵੇਰੀਐਂਟਸ ਦਾ ਜਲਦੀ ਪ੍ਰੋਫਾਈਲ ਕਰੋ।
- ਵੱਖ-ਵੱਖ ਮਾਡਲਾਂ 'ਤੇ ਟੈਸਟ ਕਰੋ – ਇੱਕੋ ਹਾਰਨੈਸ ਨੂੰ ਕਈ LLM ਬੈਕ-ਐਂਡਸ ਨਾਲ ਚਲਾਓ। ਜੇਕਰ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਗਿਰਾਵਟ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਮਾਡਲ-ਅਗਨੌਸਟਿਕ (model-agnostic) ਡਿਜ਼ਾਈਨ ਜਾਂ ਹਰੇਕ ਮਾਡਲ ਲਈ ਵੱਖਰੇ ਹਾਰਨੈਸ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਸਿੱਟਾ: HarnessDev ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ LLMs ਆਪਣੇ ਆਪ ਓਪਰੇਟਿੰਗ-ਸਿਸਟਮ ਵਰਗਾ ਕੰਟਰੋਲ ਕੋਡ ਲਿਖ ਸਕਦੇ ਹਨ।