𝗧𝗿𝘂𝘀𝘁 𝗧𝗵𝗲 𝗛𝗮𝗿𝗻𝗲𝘀𝘀, 𝗡𝗼𝘁 𝗧𝗵𝗲 𝗠𝗼𝗱𝗲𝗹
ਮੇਰੇ ਘਰ ਦੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਚੱਲ ਰਿਹਾ ਇੱਕ ਸਥਾਨਕ 27B ਕੋਡਿੰਗ ਮਾਡਲ ਕਿਸਮਤ ਦੀ ਖੇਡ ਵਰਗਾ ਹੈ। ਕਦੇ ਇਹ ਵੀਹ ਮਿੰਟਾਂ ਵਿੱਚ ਕੋਡ ਨੂੰ ਠੀਕ ਕਰ ਦਿੰਦਾ ਹੈ। ਦੂਜੇ ਸਮੇਂ ਇਹ ਗਲਤ ਫਾਈਲ ਨੂੰ ਐਡਿਟ ਕਰਦਾ ਹੈ ਜਾਂ ਅਜਿਹਾ ਟੈਸਟ ਲਿਖਦਾ ਹੈ ਜੋ ਕੁਝ ਵੀ ਹੋਵੇ ਪਾਸ ਹੋ ਜਾਂਦਾ ਹੈ।
LLMKube ਦੇ Foreman ਦਾ ਉਦੇਸ਼ ਇੱਕ ਸੰਪੂਰਨ ਮਾਡਲ ਲੱਭਣਾ ਨਹੀਂ ਹੈ। ਉਦੇਸ਼ ਇੱਕ ਅਜਿਹਾ ਹਾਰਨੈੱਸ ਬਣਾਉਣਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਮਾਡਲ ਨਾਲੋਂ ਵੱਧ ਭਰੋਸਾ ਕਰ ਸਕੋ।
ਇਸ ਵੀਕੈਂਡ, ਹਾਰਨੈੱਸ ਨੇ ਆਪਣੇ ਗਾਰਡਰੇਲਜ਼ (guardrails) ਬਣਾ ਕੇ ਆਪਣਾ ਹੀ ਟੈਸਟ ਕੀਤਾ। ਇੱਥੇ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਕੀ ਹੋਇਆ:
• ਮੇਰੇ ਸਥਾਨਕ ਕੋਡਰ ਨੇ ਆਪਣੇ ਲਈ ਤਿੰਨ ਨਵੇਂ ਗੇਟ (gates) ਬਣਾਏ। • ਇੱਕ ਗੇਟ ਉਸੇ ਖਾਮੀ ਦੇ ਨਾਲ ਆਇਆ ਜਿਸ ਨੂੰ ਉਸਨੂੰ ਫੜਨਾ ਸੀ। ਰਿਵਿਊ ਪ੍ਰਕਿਰਿਆ ਨੇ ਇਸਨੂੰ ਫੜ ਲਿਆ। • ਜਦੋਂ ਮਸ਼ੀਨਾਂ ਕੰਮ ਕਰ ਰਹੀਆਂ ਸਨ, ਤਿੰਨ ਨਵੇਂ ਮਨੁੱਖੀ ਯੋਗਦਾਨੀਆਂ ਨੇ ਚਾਰ ਸਾਫ਼ ਪੁੱਲ ਰਿਕਵੈਸਟਾਂ (pull requests) ਭੇਜੀਆਂ। • ਉਹੀ ਮਾਡਲ ਇੱਕ AMD ਬਾਕਸ ਅਤੇ ਇੱਕ Apple Silicon Mac 'ਤੇ ਚੱਲਿਆ। Mac ਨੇ ਇੱਕ ਅਜਿਹਾ ਰਾਊਂਡ ਜਿੱਤਿਆ ਜਿਸਦੀ ਕਿਸੇ ਨੂੰ ਉਮੀਦ ਨਹੀਂ ਸੀ। • ਕੋਈ ਵੀ ਡਾਟਾ ਕਲਾਉਡ API ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ।
ਇੱਕ ਸਥਾਨਕ ਮਾਡਲ 'ਤੇ ਕੋਡਿੰਗ ਏਜੰਟ ਵੱਖ-ਵੱਖ ਗੁਣਵੱਤਾ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਪ੍ਰੋਂਪਟ ਟਿਊਨਿੰਗ (prompt tuning) ਦੀ ਕੋਈ ਵੀ ਮਾਤਰਾ ਇੱਕ ਛੋਟੇ ਮਾਡਲ ਨੂੰ ਫਰੰਟੀਅਰ ਮਾਡਲ (frontier model) ਵਾਂਗ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਬਣਾ ਸਕਦੀ।
Foreman ਮਾਡਲ ਨੂੰ ਭਰੋਸੇਯੋਗ ਹੋਣ ਲਈ ਨਹੀਂ ਕਹਿੰਦਾ। ਇਹ ਮਾਡਲ ਨੂੰ ਇੱਕ ਪਾਈਪਲਾਈਨ (pipeline) ਵਿੱਚ ਲਪੇਟ ਦਿੰਦਾ ਹੈ:
- ਕੋਡਰ ਇੱਕ ਕਲੋਨ ਕੀਤੇ ਵਰਕਸਪੇਸ (cloned workspace) ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ।
- ਇੱਕ ਤੇਜ਼ ਗੇਟ gofmt, vet, build, lint, ਅਤੇ unit tests ਚਲਾਉਂਦਾ ਹੈ।
- ਇੱਕ ਰਿਵਿਊਅਰ ਇਸ਼ੂ (issue) ਦੇ ਵਿਰੁੱਧ ਡਿਫ (diff) ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ।
- ਕੋਈ ਵੀ ਕੋਡ ਮਨਜ਼ੂਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਕਲੀਨ-ਰੂਮ Kubernetes Job ਪੂਰੀ ਸੂਟ (suite) ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਂਦਾ ਹੈ।
- ਸਕੋਪ ਚੈੱਕ (scope checks) ਅਤੇ ਰੈਪੋ-ਮੈਪ ਕੰਟੈਕਸਟ (repo-map context) ਵਰਗੇ ਨਿਸ਼ਚਿਤ ਰੇਲ (deterministic rails) ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਰਹਿੰਦੇ ਹਨ।
ਮਾਡਲ ਇੱਕ ਸਿਸਟਮ ਦਾ ਇੱਕ ਰੈਂਡਮ ਹਿੱਸਾ ਹੈ। ਸਿਸਟਮ ਦਾ ਕੰਮ ਫੈਸਲੇ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣਾ ਹੈ, ਭਾਵੇਂ ਮਾਡਲ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਵੇ।
ਅਸਲੀ ਸਵਾਲ ਇਹ ਨਹੀਂ ਹੈ ਕਿ "ਕੀ ਮਾਡਲ ਚੰਗਾ ਹੈ।" ਸਵਾਲ ਇਹ ਹੈ ਕਿ "ਕੀ ਹਾਰਨੈੱਸ ਮਾਡਲ ਨੂੰ ਉਦੋਂ ਫੜਦਾ ਹੈ ਜਦੋਂ ਉਹ ਖਰਾਬ ਹੁੰਦਾ ਹੈ।"
ਇਸ ਵੀਕੈਂਡ, ਹਾਰਨੈੱਸ ਨੇ ਦੋ ਵੱਡੇ ਬੱਗ (bugs) ਫੜੇ। ਦੋਵੇਂ ਸਵੈ-ਪੁਸ਼ਟੀਕਰਨ ਟੈਸਟ (self-confirming tests) ਸਨ। ਟੈਸਟ ਇਸ ਲਈ ਪਾਸ ਹੋ ਗਏ ਕਿਉਂਕਿ ਟੈਸਟ ਖੁਦ ਪਾਸ ਹੋਣ ਲਈ ਲਿਖੇ ਗਏ ਸਨ। ਉਹਨਾਂ ਨੇ ਅਸਲ ਵਿੱਚ ਕੋਡ ਦਾ ਟੈਸਟ ਨਹੀਂ ਕੀਤਾ ਸੀ।
ਮੈਂ ਇਹ ਅਸਫਲਤਾਵਾਂ Foreman ਨੂੰ ਵਾਪਸ ਕਰ ਦਿੱਤੀਆਂ। ਮੈਂ ਹਾਰਨੈੱਸ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਗੇਟ ਬਣਾਉਣ ਦਿੱਤੇ:
- ਇੱਕ ਸਕੋਪ ਗਾਰਡ (scope guard): ਇਹ ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਐਡਿਟ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ ਜੋ ਗਲਤ ਸਬ-ਸਿਸਟਮ ਨੂੰ ਛੂਹਦਾ ਹੈ।
- ਇੱਕ ਰਿਵਿਊਅਰ ਰੂਬਰਿਕ (reviewer rubric): ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਟੈਸਟ ਪਲੇਸਹੋਲਡਰਾਂ (placeholders) ਦੀ ਬਜਾਏ ਅਸਲ ਪ੍ਰੋਡਕਸ਼ਨ ਵੈਲਯੂਜ਼ (production values) ਦੀ ਵਰਤੋਂ ਕਰਨ।
- ਇੱਕ ਬਾਈਟ ਚੈੱਕ (bite check): ਇੱਕ ਨਵਾਂ ਟੈਸਟ ਪੁਰਾਣੇ ਕੋਡ ਦੇ ਵਿਰੁੱਧ ਫੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਇਹ ਦੋਵਾਂ ਵਿੱਚ ਪਾਸ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਅਸਲੀ ਟੈਸਟ ਨਹੀਂ ਹੈ।
ਬਾਈਟ ਚੈੱਕ ਆਪਣੇ ਪਹਿਲੇ ਟੈਸਟ ਵਿੱਚ ਫੇਲ ਹੋ ਗਿਆ। ਜੋ ਗੇਟ ਉਸਨੇ ਬਣਾਇਆ ਸੀ ਉਹ ਖਾਮੀ ਵਾਲਾ ਸੀ। ਪਰ ਰਿਵਿਊ ਪ੍ਰਕਿਰਿਆ ਨੇ ਮਰਜ (merge) ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਗਲਤੀ ਨੂੰ ਫੜ ਲਿਆ। ਇਹ ਡਿਜ਼ਾਈਨ ਦਾ ਕੰਮ ਕਰਨਾ ਹੈ।
ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵਿਸ਼ਾਲ ਫਰੰਟੀਅਰ ਮਾਡਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਇੱਕ ਅਜਿਹੇ ਹਾਰਨੈੱਸ ਦੀ ਲੋੜ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰ ਸਕੋ। ਉਸਨੂੰ ਬਣਾਓ, ਅਤੇ ਇੱਕ ਛੋਟਾ ਮਾਡਲ ਇੱਕ ਲਾਭਦਾਇਕ ਸਾਥੀ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਅਜਿਹਾ ਸਿਸਟਮ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਗਲਤੀਆਂ ਨੂੰ ਫੜਦਾ ਹੈ, ਨਾ ਕਿ ਤੁਹਾਨੂੰ ਅੱਧੀ ਰਾਤ ਨੂੰ ਕੋਡ ਦੀ ਹਰ ਲਾਈਨ ਪੜ੍ਹਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।
Optional learning community: https://t.me/GyaanSetuAi