ਮੈਂ ਦੇਖਣਾ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਕੀ ਇੱਕੋ ਸਵਾਲ ਨੂੰ 51 ਵਾਰ ਪੁੱਛਣ ਨਾਲ ਜਵਾਬ ਵਧੇਰੇ ਭਰੋਸੇਮੰਦ ਹੋ ਜਾਵੇਗਾ। ਮੈਂ ਇੱਕ local LLM ਲਿਆ, ਉਸਨੂੰ production code ਦਾ ਇੱਕ ਹਿੱਸਾ ਦਿੱਤਾ, ਅਤੇ ਉਸਦੀ ਰਿਵਿਊ ਕਰਨ ਲਈ ਕਿਹਾ। ਫਿਰ ਮੈਂ ਇਹ ਦੁਬਾਰਾ ਕੀਤਾ। ਅਤੇ ਫਿਰ। ਕੁੱਲ 51 ਵਾਰ, "ਸਭ ਤੋਂ ਵਧੀਆ" ਜਵਾਬ ਚੁਣਨ ਲਈ majority voting ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਵਿਚਾਰ ਸਧਾਰਨ ਸੀ: ਜੇਕਰ ਮਾਡਲ ਇੱਕ ਵਾਰ ਗਲਤੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਸ਼ਾਇਦ 51 ਵਾਰਾਂ ਵਿੱਚ ਬਹੁਮਤ ਦੀ ਸਿਆਣਪ ਸ਼ੋਰ (noise) ਨੂੰ ਖਤਮ ਕਰ ਦੇਵੇਗੀ ਅਤੇ ਸਹੀ ਵਿਸ਼ਲੇਸ਼ਣ ਸਾਹਮਣੇ ਲਿਆਵੇਗੀ। ਪਰ ਅਜਿਹਾ ਨਹੀਂ ਹੋਇਆ। ਪ੍ਰਯੋਗ ਨੇ ਦਿਖਾਇਆ ਕਿ majority voting ਸਹੀ ਹੋਣ ਲਈ ਨਹੀਂ ਚੁਣਦੀ। ਇਹ ਉਸ ਚੀਜ਼ ਨੂੰ ਚੁਣਦੀ ਹੈ ਜਿਸ ਬਾਰੇ ਮਾਡਲ ਸਭ ਤੋਂ ਵੱਧ ਜ਼ਿੱਦੀ ਹੁੰਦਾ ਹੈ।
ਇਹ ਅੰਤਰ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ LLM pipelines ਵਿੱਚ majority voting ਇੱਕ ਪ੍ਰਸਿੱਧ ਹੈਕ ਬਣ ਗਈ ਹੈ। ਇਹ ਤਰੀਕਾ ਸਿੱਧਾ ਹੈ। ਤੁਸੀਂ ਇੱਕੋ ਪ੍ਰੋਂਪਟ 'ਤੇ ਮਾਡਲ ਨੂੰ ਕਈ ਵਾਰ ਚਲਾਉਂਦੇ ਹੋ, ਆਉਟਪੁੱਟ ਇਕੱਠਾ ਕਰਦੇ ਹੋ, ਅਤੇ ਉਹ ਜਵਾਬ ਰੱਖਦੇ ਹੋ ਜੋ ਸਭ ਤੋਂ ਵਾਰ-ਵਾਰ ਆਉਂਦਾ ਹੈ। ਮੈਡੀਕਲ ਇਮੇਜਿੰਗ ਜਾਂ ਸਪੈਮ ਡਿਟੈਕਸ਼ਨ ਵਰਗੇ ਖੇਤਰਾਂ ਵਿੱਚ, ensemble methods ਕੰਮ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਵੱਖ-ਵੱਖ ਮਾਡਲ, ਜਾਂ ਡੇਟਾ ਦੇ ਵੱਖ-ਵੱਖ ਦ੍ਰਿਸ਼ਟੀਕੋਣ, ਸੁਤੰਤਰ ਗਲਤੀਆਂ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜੋ ਅਸਲ ਵਿੱਚ ਇੱਕ ਦੂਜੇ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੀਆਂ ਹਨ। Large language models ਸੁਤੰਤਰ ਵੋਟਰ ਨਹੀਂ ਹਨ। ਉਹ ਇੱਕ ਸਿਖਲਾਈ ਇਤਿਹਾਸ (training history), ਵੇਟਸ (weights) ਦੇ ਇੱਕ ਸੈੱਟ, ਅਤੇ ਇੱਕ ਪੱਖਪਾਤ (biases) ਦੇ ਬ੍ਰਹਿਮੰਡ ਵਾਲਾ ਇੱਕ ਹੀ ਸਿਸਟਮ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕੋ ਮਾਡਲ ਨੂੰ ਇੱਕੋ ਸਵਾਲ ਇਕਵੰਜਾ ਵਾਰ ਪੁੱਛਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕੋਈ ਕਮੇਟੀ ਨਹੀਂ ਬੁਲਾ ਰਹੇ ਹੁੰਦੇ। ਤੁਸੀਂ ਥੋੜ੍ਹੇ ਬਹੁਤ ਵੱਖਰੇ ਮੂਡ ਵਿੱਚ ਇੱਕੋ ਵਿਅਕਤੀ ਦਾ ਸਰਵੇਖਣ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ।
ਦ੍ਰਿੜਤਾ ਦੀ ਸਮੱਸਿਆ
ਮੁੱਖ ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ LLM ਦੀਆਂ ਗਲਤੀਆਂ ਸ਼ਾਇਦ ਹੀ ਕਦੇ ਰੈਂਡਮ ਹੁੰਦੀਆਂ ਹਨ। ਉਹ ਟ੍ਰੇਨਿੰਗ ਡੇਟਾ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਰਚੇ ਹੋਏ ਪੈਟਰਨ ਹਨ। ਇੱਕ ਮਾਡਲ ਜੋ ਇੱਕ ਵਾਰ ਕਿਸੇ ਖਾਸ Python decorator ਨੂੰ ਗਲਤ ਪੜ੍ਹਦਾ ਹੈ, ਉਸਦੀ ਅਗਲੀ ਵਾਰ ਵੀ ਉਸਨੂੰ ਗਲਤ ਪੜ੍ਹਨ ਦੀ ਸੰਭਾਵਨਾ ਹੈ। ਇੱਕ ਮਾਡਲ ਜੋ ਸੁਰੱਖਿਆ ਕਮਜ਼ੋਰੀ (security vulnerability) ਦਾ ਭਰਮ (hallucinate) ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਵੇਰੀਏਬਲ ਦਾ ਨਾਮ ਪਾਸਵਰਡ ਵਰਗਾ ਲੱਗਦਾ ਹੈ, ਉਹ ਸ਼ਾਇਦ ਚਾਲੀਵੇਂ ਵਾਰ ਵੀ ਅਜਿਹਾ ਹੀ ਕਰੇਗਾ। ਜਿਸ ਸ਼ੋਰ ਨੂੰ ਤੁਸੀਂ ਔਵਰੇਜ ਕਰ ਰਹੇ ਹੋ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਬਦਾਵਲੀ ਜਾਂ ਫਾਰਮੈਟਿੰਗ ਵਿੱਚ ਸਤਹੀ ਤਬਦੀਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਅਸਲ ਤਰਕ ਅਕਸਰ ਉਹੀ ਰਹਿੰਦਾ ਹੈ।
ਇੱਕ ਖਾਸ ਉਦਾਹਰਣ 'ਤੇ ਵਿਚਾਰ ਕਰੋ। ਮੰਨ ਲਓ ਇੱਕ ਫੰਕਸ਼ਨ ਹੈ ਜੋ regular expression ਦੀ ਵਰਤੋਂ ਕਰਕੇ log files ਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹੈ। regex ਸਖ਼ਤ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੈ। ਪਰ ਸਟ੍ਰਿੰਗ r'...' ਵਿੱਚ ਅਜਿਹੇ ਅੱਖਰ ਹਨ ਜੋ, ਵੱਖਰੇ ਸੰਦਰਭ ਵਿੱਚ, ਇੰਜੈਕਸ਼ਨ ਨੂੰ ਸੱਦਾ ਦੇ ਸਕਦੇ ਹਨ। ਇੱਕ LLM ਨੂੰ ਇਸਦੀ ਰਿਵਿਊ ਕਰਨ ਲਈ ਕਹੋ। ਜੇਕਰ ਮਾਡਲ ਨੇ log parsers ਵਿੱਚ regex injection ਵਿਰੁੱਧ ਚੇਤਾਵਨੀ ਦੇਣ ਵਾਲੀਆਂ ਹਜ਼ਾਰਾਂ Stack Overflow ਪੋਸਟਾਂ ਦੇਖੀਆਂ ਹਨ, ਤਾਂ ਇਹ ਇਸ ਸੁਰੱਖਿਅਤ ਕੋਡ ਨੂੰ ਇੱਕ ਜੋਖਮ ਵਜੋਂ ਫਲੈਗ ਕਰ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਵਾਰ ਚਲਾਓ, ਤੁਹਾਨੂੰ ਇੱਕ false positive ਮਿਲੇਗਾ। ਇਸਨੂੰ 51 ਵਾਰ ਚਲਾਓ, ਅਤੇ ਇਸ ਗੱਲ ਦੀ ਪੂਰੀ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ 51 false positives ਮਿਲਣਗੇ, ਜਾਂ ਘੱਟੋ ਘੱਟ ਇੱਕ ਵੱਡੀ ਬਹੁਮਤ ਮਿਲੇਗੀ। ਹੁਣ majority vote ਉਸ ਭਰਮ ਨੂੰ ਹੋਰ ਪੱਕਾ ਕਰ ਦਿੰਦਾ ਹੈ। ਮਾਡਲ ਦ੍ਰਿੜ ਹੈ, ਇਸ ਲਈ "ਸਹਿਮਤੀ" ਵੀ ਦ੍ਰਿੜ ਹੈ।
ਅਜਿਹਾ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ temperature ਅਤੇ sampling ਦੇ ਤਰੀਕੇ ਮਾਡਲ ਦੇ ਗਿਆਨ ਨੂੰ ਨਹੀਂ ਬਦਲਦੇ। ਉਹ ਸਿਰਫ਼ ਇਸਦੇ ਬੋਲਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲਦੇ ਹਨ। ਉੱਚ temperature ਵਿਆਖਿਆ ਨੂੰ ਗੱਲਾਂ ਕਰਨ ਵਾਲਾ ਜਾਂ ਸੰਖੇਪ ਬਣਾ ਸਕਦਾ ਹੈ। ਇਹ ਸਮਾਨਾਰਥੀ ਸ਼ਬਦਾਂ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ। ਇਹ ਅਚਾਨਕ ਮਾਡਲ ਨੂੰ ਇਹ ਨਹੀਂ ਸਿਖਾਉਂਦਾ ਕਿ regex ਅਸਲ ਵਿੱਚ ਨੁਕਸਾਨ ਰਹਿਤ ਹੈ। ਜਿਸ ਵੇਰੀਏਸ਼ਨ 'ਤੇ ਤੁਸੀਂ ਵੋਟ ਪਾ ਰਹੇ ਹੋ, ਉਹ ਸਿਰਫ਼ ਬਾਹਰੀ ਹਨ। ਗਲਤੀ ਬਣਤਰ ਵਿੱਚ ਹੈ।
51 ਰਨ ਕੀ ਦੱਸਦੇ ਹਨ
ਜਦੋਂ ਮੈਂ ਉਹ 51 ਆਉਟਪੁੱਟ ਆਪਣੀ ਮੇਜ਼ 'ਤੇ ਫੈਲਾਏ, ਤਾਂ ਪੈਟਰਨ ਸਪੱਸ਼ਟ ਸੀ। ਮਾਡਲ ਨੇ ਕੋਡ ਦੀਆਂ 51 ਵੱਖ-ਵੱਖ ਵਿਆਖਿਆਵਾਂ ਨਹੀਂ ਕੀਤੀਆਂ। ਉਸਨੇ ਥੋੜ੍ਹੇ ਬਹੁਤ ਵੱਖਰੇ ਅੰਦਾਜ਼ ਵਿੱਚ ਉਹੀ ਵਿਆਖਿਆ ਦੁਹਰਾਈ। ਕੁਝ ਰਨਾਂ ਨੇ ਸਕ੍ਰਿਪਟ ਤੋਂ ਹਟ ਕੇ edge-case ਫਿਕਸਾਂ ਦਾ ਸੁਝਾਅ ਦਿੱਤਾ ਜਾਂ ਅਸੰਬੰਧਿਤ ਸਟਾਈਲ ਦੇ ਮੁੱਦਿਆਂ ਵੱਲ ਧਿਆਨ ਦਿੱਤਾ। ਪਰ ਪ੍ਰਮੁੱਖ ਸਮੂਹ, ਸਪੱਸ਼ਟ ਬਹੁਮਤ, ਲਗਾਤਾਰ ਇੱਕੋ ਗਲਤ ਕੇਂਦਰੀ ਦਾਅਵੇ 'ਤੇ ਵਾਪਸ ਆ ਰਿਹਾ ਸੀ। ਉਹ ਦਾਅਵਾ ਸਹੀ ਨਹੀਂ ਸੀ। ਉਹ ਸਿਰਫ਼ ਜਾਣਕਾਰ ਸੀ।
Majority voting ਦਾ ਗਣਿਤ ਸੁਤੰਤਰ Bernoulli trials 'ਤੇ ਅਧਾਰਤ ਹੈ। ਬਹੁਮਤ ਨੂੰ ਵਿਅਕਤੀਗਤ ਨਾਲੋਂ ਬਿਹਤਰ ਪ੍ਰਦਰਸ਼ਨ ਕਰਨ ਲਈ ਅਸੰਬੰਧਿਤ ਗਲਤੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਮੇਰੇ ਪ੍ਰਯੋਗ ਵਿੱਚ, ਗਲਤੀਆਂ ਡੂੰਘੇ ਤੌਰ 'ਤੇ ਸਬੰਧਤ ਸਨ। ਉਹਨਾਂ ਦਾ ਮੂਲ ਕਾਰਨ ਇੱਕੋ ਸੀ: ਮਾਡਲ ਦੀ ਟ੍ਰੇਨਿੰਗ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਕੁਝ ਖਾਸ ਕੋਡਿੰਗ ਰੂੜੀਵਾਦ (tropes) ਨੂੰ ਜ਼ਿਆਦਾ ਮਹੱਤਵ ਦਿੰਦੀ ਹੈ। ਇਸ ਲਈ, majority vote ਨੇ ਗਲਤੀ ਨੂੰ ਘਟਾਇਆ ਨਹੀਂ। ਇਸਨੇ ਬਹੁਮਤ ਦੇ ਪੱਖਪਾਤ ਨੂੰ ਵਧਾ ਦਿੱਤਾ। ਇਸਨੇ ਇੱਕ ਖ਼ਰਾਬ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਯਕੀਨ ਦਾ ਇੱਕ ਝੂਠਾ ਅਹਿਸਾਸ ਦਿੱਤਾ।
ਇਹ ਕੋਡ ਰਿਵਿਊ ਵਿੱਚ ਖਾਸ ਤੌਰ 'ਤੇ ਖ਼ਤਰਨਾਕ ਹੈ ਕਿਉਂਕਿ ਡਿਵੈਲਪਰ ਸਰਵਸੰਮਤੀ ਜਾਂ ਲਗਭਗ ਸਰਵਸੰਮਤੀ ਵਾਲੇ AI ਆਉਟਪੁੱਟ ਨੂੰ ਅਧਿਕਾਰਤ ਮੰਨਦੇ ਹਨ। ਇੱਕ ਇਕੱਲਾ ਝਿਜਕਣ ਵਾਲਾ ਸੁਝਾਅ ਅਸੌਖਾ ਹੈ। ਇੱਕ ਸਿਫਾਰਸ਼ ਜੋ ਇਕਵੰਜਾ ਵਾਰਾਂ ਤੱਕ ਟਿਕੀ ਰਹਿੰਦੀ ਹੈ, ਉਹ ਸੱਚਾਈ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ। ਇਹ ਸੱਚਾਈ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ground loop ਹੈ।
ਵੋਟਿੰਗ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਕੰਮ ਕਰਦੀ ਹੈ
ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇੱਕ ਮਾਡਲ ਨੂੰ ਇੱਕ ਵਾਰ ਤੋਂ ਵੱਧ ਕਦੇ ਨਹੀਂ ਚਲਾਉਣਾ ਚਾਹੀਦਾ। ਮੈਜੋਰਿਟੀ ਵੋਟਿੰਗ ਉਹਨਾਂ ਸੀਮਤ ਸਥਿਤੀਆਂ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ ਜਿੱਥੇ ਕੰਮ ਸਤਹੀ ਹੋਵੇ ਅਤੇ ਗਲਤੀਆਂ ਸੱਚਮੁੱਚ ਰੈਂਡਮ ਹੋਣ। ਇੱਕ ਮਾਡਲ ਨੂੰ ਦੋ ਸਿੰਟੈਕਟਿਕ ਫਾਰਮੈਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਚੁਣਨ ਲਈ ਕਹਿਣਾ, ਵੇਰੀਏਬਲ ਨਾਮ ਰੱਖਣ ਦਾ ਤਰੀਕਾ ਚੁਣਨਾ, ਜਾਂ ਲੌਗ ਲਾਈਨ ਵਿੱਚੋਂ ਡੇਟ ਸਟ੍ਰਿੰਗ ਕੱਢਣਾ—ਇਹ ਘੱਟ ਜੋਖਮ ਵਾਲੇ ਕੰਮ ਕਈ ਵਾਰ ਵਾਰ-ਵਾਰ ਸੈਂਪਲਿੰਗ ਤੋਂ ਲਾਭ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ। ਇਹ ਵੈਰੀਏਸ਼ਨ ਅਸਲ ਸ਼ੋਰ ਹੈ, ਅਤੇ ਇੱਕ ਤੇਜ਼ ਵੋਟ ਇਸਨੂੰ ਸਾਫ਼ ਕਰ ਦਿੰਦੀ ਹੈ।
ਮੁਸ਼ਕਲ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕੰਮ ਲਈ ਇਰਾਦੇ (intent) ਬਾਰੇ ਤਰਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਕੀ ਇਹ auth ਚੈੱਕ ਇੱਥੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ? ਕੀ ਇਹ async ਕਾਲ ਸੁਰੱਖਿਅਤ ਹੈ? ਕੀ ਇਹ cache key collision ਅਸਲ ਵਿੱਚ ਐਕਸਪਲੋਇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ? ਇਹ ਸਵਾਲ ਸਿਰਫ਼ ਪੈਟਰਨ ਮੈਚਿੰਗ ਦੀ ਨਹੀਂ, ਸਗੋਂ ਸੰਦਰਭ (context) ਦੀ ਸਮਝ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ। ਇੱਕ ਮਾਡਲ ਦਾ ਪੈਟਰਨ ਮੈਚਰ ਆਪਣੇ ਪੱਖਪਾਤ ਵਿੱਚ ਡਿਟਰਮਿਨਿਸਟਿਕ ਹੁੰਦਾ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਲਈ ਸਭ ਤੋਂ ਸਹੀ ਉੱਤਰ ਦੇਣ ਦੀ ਬਜਾਏ, ਆਪਣੇ ਟ੍ਰੇਨਿੰਗ ਡੇਟਾ ਤੋਂ ਸਭ ਤੋਂ ਆਮ ਉੱਤਰ ਲੱਭੇਗਾ।
ਆਪਣੇ ਕੰਪਿਊਟ (Compute) ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਸਮਾਰਟ ਤਰੀਕੇ
ਇੱਕ ਲੋਕਲ ਮਾਡਲ ਨੂੰ ਇਕਵੰਜਾ ਵਾਰ ਚਲਾਉਣ ਨਾਲ ਅਸਲ ਸਮਾਂ ਅਤੇ ਬਿਜਲੀ ਖਰਚ ਹੁੰਦੀ ਹੈ। ਉਸ ਕੰਪਿਊਟ ਨੂੰ ਨਿਵੇਸ਼ ਕਰਨ ਦੇ ਬਿਹਤਰ ਤਰੀਕੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਵਿਭਿੰਨਤਾ ਮਾਤਰਾ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ। ਦੋ ਵੱਖ-ਵੱਖ ਮਾਡਲਾਂ ਨੂੰ ਚਲਾਓ