30 ਅਗ 2025·8 ਮਿੰਟ
ਐਪ ਬਣਾਉਂਦੇ ਵੇਲੇ AI ਕਿਵੇਂ ਸੋਚਦਾ ਹੈ — ਇੱਕ ਸਧਾਰਨ ਮਾਨਸਿਕ ਮਾਡਲ
ਟੋਕਨਾਂ, ਕੰਟੈਕਸਟ, ਟੂਲ ਅਤੇ ਟੈਸਟ—ਇੱਕ ਸਪਸ਼ਟ ਮਾਨਸਿਕ ਮਾਡਲ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ AI ਐਪਸ ਲਈ ਕੋਡ ਅਤੇ ਫੈਸਲੇ ਕਿਵੇਂ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਸੀਮਾਵਾਂ ਅਤੇ ਪ੍ਰਯੋਗਿਕ ਪ੍ਰਾਂਪਟਿੰਗ ਸੁਝਾਵਾਂ ਸਮੇਤ।
ਟੋਕਨਾਂ, ਕੰਟੈਕਸਟ, ਟੂਲ ਅਤੇ ਟੈਸਟ—ਇੱਕ ਸਪਸ਼ਟ ਮਾਨਸਿਕ ਮਾਡਲ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ AI ਐਪਸ ਲਈ ਕੋਡ ਅਤੇ ਫੈਸਲੇ ਕਿਵੇਂ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਸੀਮਾਵਾਂ ਅਤੇ ਪ੍ਰਯੋਗਿਕ ਪ੍ਰਾਂਪਟਿੰਗ ਸੁਝਾਵਾਂ ਸਮੇਤ।
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ “AI ਸੋਚਦਾ ਹੈ,” ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹੀ ਮੰਨਦੇ ਹਨ: ਇਹ ਤੁਹਾਡੇ ਸਵਾਲ ਨੂੰ ਸਮਝਦਾ ਹੈ, ਤਰਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਕਿਸੇ ਜਵਾਬ 'ਤੇ ਪਹੁੰਚਦਾ ਹੈ।
ਆਧੁਨਿਕ ਟੈਕਸਟ-ਆਧਾਰਿਤ AI (LLMs) ਲਈ ਇੱਕ ਹੋਰ ਲਾਭਦਾਇਕ ਮਾਨਸਿਕ ਮਾਡਲ ਹੋਰ ਸਧਾਰਨ ਹੈ: ਮਾਡਲ ਅਗਲਾ ਟੈਕਸਟ ਭਵਿੱਖਵਾਣੀ ਕਰਦਾ ਹੈ।
ਇਹ ਘੱਟ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗ ਸਕਦਾ ਹੈ—ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ “ਅਗਲਾ ਟੈਕਸਟ” ਕਿੰਨਾ ਕੁ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਸੋਚੋ। ਜੇ ਮਾਡਲ ਨੇ ਟ੍ਰੇਨਿੰਗ ਤੋਂ ਕਾਫੀ ਪੈਟਰਨ ਸਿੱਖ ਲਈਤੇ ਹਨ, ਤਾਂ ਅਗਲਾ ਸ਼ਬਦ (ਅਤੇ ਫਿਰ ਅਗਲਾ, ਅਤੇ ਫਿਰ) ਪੈਦਾ ਕਰਨ ਨਾਲ ਇਹ ਵਿਆਖਿਆਵਾਂ, ਯੋਜਨਾਵਾਂ, ਕੋਡ, ਸਾਰਾਂ ਅਤੇ ਹੇਠਾਂ-ਦਿੱਖੇ ਡੇਟਾ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਐਪ ਵਰਤ ਸਕਦੀ ਹੈ।
ਤੁਹਾਨੂੰ ਚੰਗੀਆਂ AI ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਣਾਉਣ ਲਈ ਅੰਦਰਲੇ ਗਣਿਤ ਸਿੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਜੋ ਚਾਹੀਦਾ ਹੈ ਉਹ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਹੈ ਜੋ ਵਿਵਹਾਰ ਦੀ ਪੇਸ਼ਗੀ ਕੀਤੀ ਜਾ ਸਕੇ:
ਇਹ ਲੇਖ ਓਸ ਕਿਸਮ ਦਾ ਮਾਡਲ ਹੈ: ਨਾ ਤਾਂ ਜੋਸ਼, ਨਾ ਕੋਈ ਡੂੰਘਾ ਤਕਨੀਕੀ ਪੇਪਰ—ਸਿਰਫ਼ ਉਹ ਸਿਧਾਂਤ ਜੋ ਤੁਹਾਡੇ ਲਈ ਭਰੋਸੇਯੋਗ ਪ੍ਰੋਡਕਟ ਤਜੁਰਬੇ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵਿੱਚ ਮਦਦਗਾਰ ਹਨ।
ਐਪ ਬਿਲਡਰ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ, ਮਾਡਲ ਦੀ "ਸੋਚ" ਉਹ ਟੈਕਸਟ ਹੈ ਜੋ ਇਹ ਤੁਹਾਡੇ ਦਿੱਤੇ ਇਨਪੁੱਟ (ਤੁਹਾਡਾ ਪ੍ਰਾਂਪਟ, ਯੂਜ਼ਰ ਸੰਦੇਸ਼, ਸਿਸਟਮ ਨਿਯਮ ਅਤੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਸਮੱਗਰੀ) ਦੇ ਜਵਾਬ ਵਿੱਚ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਮਾਡਲ ਡਿਫ਼ਾਲਟ ਤੌਰ 'ਤੇ ਤੱਥਾਂ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰ ਰਿਹਾ, ਵੈਬ ਨੂੰ ਨਹੀਂ ਰਿਹਾ, ਅਤੇ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਦੇ ਬਾਰੇ ਨਹੀਂ ਜਾਣਦਾ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਉਹ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦੇਂਦੇ।
ਉਮੀਦਾਂ ਨੂੰ ਇਹਨਾਂ ਅਨੁਸਾਰ ਸੈੱਟ ਕਰੋ: LLMs ਡਰਾਫਟ, ਰੂਪਾਂਤਰਨ ਅਤੇ ਟੈਕਸਟ ਦੀ ਵਰਗੀਫਿਕੇਸ਼ਨ ਲਈ ਬਹੁਤ ਲਾਭਕਾਰੀ ਹਨ, ਅਤੇ ਕੋਡ-ਜਿਹੀ ਆਉਟਪੁੱਟ ਬਣਾਉਣ ਲਈ ਵੀ। ਉਹ ਜਾਦੂਈ ਸੱਚਾਈ ਇੰਜਨ ਨਹੀਂ ਹਨ।
ਅਸੀਂ ਮਾਨਸਿਕ ਮਾਡਲ ਨੂੰ ਕੁਝ ਹਿੱਸਿਆਂ ਵਿੱਚ ਤੋੜਾਂਗੇ:
ਇਹ ਵਿਚਾਰ ਤੁਹਾਨੂੰ ਪ੍ਰਾਂਪਟ, UI ਅਤੇ ਸੁਰੱਖਿਆ-ਉਪਾਇ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨਗੇ ਤਾਂ ਜੋ AI ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਗਾਤਾਰ ਅਤੇ ਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਹੋਣ।
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਇੱਕ AI "ਸੋਚਦਾ" ਹੈ, ਤਾਂ ਅਕਸਰ ਇਹ ਸੋਚਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਇਹ ਮਨुष्य ਵਾਂਗ ਤਰਕ ਕਰਦਾ ਹੈ। ਇੱਕ ਹੋਰ ਲਾਭਦਾਇਕ ਮਾਨਸਿਕ ਮਾਡਲ ਸਧਾਰਨ ਹੈ: ਇਹ ਬਹੁਤ ਤੇਜ਼ ਆਟੋਮੈਟਿਕ-ਪੂਰਨਤਾ ਕਰ ਰਿਹਾ ਹੈ—ਇੱਕ ਛੋਟੇ ਟੁਕੜੇ ਤੋਂ ਇੱਕ ਵਾਰੀ ਵਿੱਚ।
ਇੱਕ ਟੋਕਨ ਉਹ ਟੁਕੜਾ ਹੈ ਜਿਸ 'ਤੇ ਮਾਡਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਕਦੇ ਇਹ ਇੱਕ ਪੂਰਾ ਸ਼ਬਦ ਹੁੰਦਾ ਹੈ ("apple"), ਕਦੇ ਸ਼ਬਦ ਦਾ ਹਿੱਸਾ ("app" + "le"), ਕਦੇ विरਾਮ ਚਿੰਨ੍ਹ, ਅਤੇ ਕਈ ਵਾਰ ਖਾਲੀ ਥਾਂ ਵੀ। ਟੋਕਨਾਈਜ਼ਰ ’ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ ਇਹ ਟੁਕੜੇ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ ਹਨ, ਪਰ ਨਿਸ਼ਚਿਤ ਗੱਲ ਇਹ ਹੈ ਕਿ ਮਾਡਲ ਵਾਕਾਂ ਨੂੰ ਨਹੀਂ ਪਰ ਟੋਕਨਾਂ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ।
ਮਾਡਲ ਦਾ ਮੂਲ ਲੂਪ ਇਹ ਹੈ:
بس। ਹਰ ਪੈਰਾ, ਬੁਲੇਟ ਲਿਸਟ ਅਤੇ "ਤਰਕ" ਦੀ ਲੜੀ ਜੋ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਉਹ ਇਸ ਅਗਲੇ-ਟੋਕਨ ਭਵਿੱਖਵਾਣੀ ਨੂੰ ਕਈ ਵਾਰੀ ਦੁਹਰਾਉਣ ਨਾਲ ਬਣਦੀ ਹੈ।
ਕਿਉਂਕਿ ਮਾਡਲ ਨੇ ਟ੍ਰੇਨਿੰਗ ਦੌਰਾਨ ਬਹੁਤ ਸਾਰੀ ਟੈਕਸਟ ਦੇਖੀ ਹੁੰਦੀ ਹੈ, ਇਹ ਉਹ ਪੈਟਰਨ ਸਿੱਖਦਾ ਹੈ ਕਿ ਵਿਵਰਣ ਆਮ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਵਹਿੰਦੇ ਹਨ, ਨਮ੍ਰ ਈਮੇਲ ਕਿਵੇਂ ਲੱਗਦੀ ਹੈ, ਜਾਂ ਬੱਗ ਫਿਕਸ ਕਿਵੇਂ ਵੇਰਵਾ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਸਵਾਲ ਪੁੱਛਦੇ ਹੋ, ਇਹ ਐਸਾ ਜਵਾਬ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਉਹਨਾਂ ਸਿੱਖੇ ਪੈਟਰਨਾਂ ਨਾਲ ਮਿਲਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਦਿੱਤੇ ਸੰਦਰਭ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।
ਇਸੇ ਲਈ ਇਹ ਪੱਕਾ ਅਤੇ ਸੁਚਾਰੂ ਲੱਗ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਇਹ ਗਲਤ ਹੋਵੇ: ਇਹ ਅਗਲੇ-ਟੋਕਨ ਲਈ ਸਭ ਤੋਂ ਉਚਿਤ ਟੈਕਸਟ ਲਈ ਅਪਟਿਮਾਈਜ਼ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ—ਹਕੀਕਤ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਨਹੀਂ।
ਕੋਡ ਮਾਡਲ ਲਈ ਕੋਈ ਖ਼ਾਸ ਗੱਲ ਨਹੀਂ ਹੈ। JavaScript, SQL, JSON ਅਤੇ ਐਰਰ ਮੇਸੇਜ ਸਾਰੇ ਸਿਰਫ ਟੋਕਨਾਂ ਦੀ ਲੜੀ ਹਨ। ਮਾਡਲ ਲਾਭਦਾਇਕ ਕੋਡ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਉਸਨੇ ਆਮ ਕੋਡਿੰਗ ਪੈਟਰਨ ਸਿੱਖੇ ਹਨ, ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਇਹ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਇੱਕ ਇੰਜੀਨੀਅਰ ਵਾਂਗ ਸਚਮੁਚ "ਸਮਝਦਾ" ਹੈ।
ਲੋਕ ਪੁੱਛਦੇ ਹਨ "ਮਾਡਲ ਨੇ ਉਹ ਜਵਾਬ ਕਿੱਥੋਂ ਲਿਆ?", ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਮਾਨਸਿਕ ਮਾਡਲ ਇਹ ਹੈ: ਇਸਨੇ ਭਾਰੀ ਮਾਤਰਾ ਵਿੱਚ ਉਦਾਹਰਨਾਂ ਤੋਂ ਪੈਟਰਨ ਸਿੱਖੇ ਹਨ, ਅਤੇ ਹੁਣ ਉਹ ਪੈਟਰਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਮਿਲਾ ਕੇ ਅਗਲਾ ਟੈਕਸਟ ਪੈਦਾ ਕਰਦਾ ਹੈ।
ਟ੍ਰੇਨਿੰਗ ਦੌਰਾਨ ਮਾਡਲ ਨੂੰ ਕਈ ਟੈਕਸਟ ਦੇ ਟੁਕੜੇ (ਕਿਤਾਬਾਂ, ਲੇਖ, ਕੋਡ, ਡੌਕੂਮੈਂਟੇਸ਼ਨ, Q&A ਆਦਿ) ਦਿਖਾਏ ਜਾਂਦੇ ਹਨ। ਇਹ ਇੱਕ ਸਧਾਰਨ ਟਾਸਕ ਪ੍ਰੈਕਟਿਸ ਕਰਦਾ ਹੈ: ਕੁਝ ਟੈਕਸਟ ਮਿਲਣ 'ਤੇ ਅਗਲਾ ਟੋਕਨ ਭਵਿੱਖਵਾਣੀ ਕਰੋ। ਜੇ ਗਲਤ ਹੋਵੇ, ਤਾਂ ਟ੍ਰੇਨਿੰਗ ਪ੍ਰਕਿਰਿਆ ਮਾਡਲ ਦੇ ਅੰਦਰੂਨੀ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਥੋੜ੍ਹਾ ਬਦਲ ਦਿੰਦੀ ਹੈ ਤਾਂ ਜੋ ਅਗਲੀ ਵਾਰੀ ਬਿਹਤਰ ਅਨੁਮਾਨ ਹੋ ਸਕੇ।
ਸਮੇਂ ਦੇ ਨਾਲ, ਉਹ ਬਦਲਾਅ ਇਕੱਠੇ ਹੋ ਕੇ ਇਹ ਰਿਸ਼ਤੇ ਏਨਕੋਡ ਕਰਦੇ ਹਨ ਕਿ:
ਕਿਉਂਕਿ ਇਹ ਆੰਕੜਿਕ ਰੀਗੁਲਰਿਟੀਆਂ ਸਿੱਖਦਾ ਹੈ—ਇਕ ਫਿਕਸਡ ਸਕ੍ਰਿਪਟ ਨਹੀਂ—ਇਹ ਨਵੇਂ ਤਰੀਕੇ ਨਾਲ ਪੈਟਰਨਾਂ ਮਿਲਾ ਸਕਦਾ ਹੈ। ਜੇ ਇਸਨੇ "ਕਿਸੇ ਸੰਕਲਪ ਦੀ ਵਿਆਖਿਆ" ਦੇ ਬਹੁਤ ਉਦਾਹਰਨ ਤੇ "ਤੁਹਾਡੇ ਐਪ ਸਿਨਾਰਿਓ" ਦੇ ਬਹੁਤ ਉਦਾਹਰਨ ਵੇਖੇ ਹਨ, ਤਾਂ ਇਹ ਅਕਸਰ ਉਹਨਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਟੇਲਰ ਕੀਤੇ ਜਵਾਬ ਬਣਾਉਂਦਾ ਹੈ।
ਇਸੇ ਲਈ LLM ਕਿਸੇ ਨਿਸ਼ ਦੀ ਉਤਪਾਦ ਜਾਣ-पਹਿਚਾਣ ਲਈ ਪਲੇਨ-ਬਚਨ ਬਣਾਉ ਸਕਦਾ ਹੈ। ਇਹ ਕਿਸੇ ਇਕ ਗੋਦਾਮ ਵਿਚੋਂ ਇੱਕ ਛੇੜੀ ਹੋਈ ਪੈਰਾ ਨਹੀਂ ਲੈ ਰਿਹਾ; ਇਹ ਨਵਾਂ ਕ੍ਰਮ ਪੈਦਾ ਕਰ ਰਿਹਾ ਹੈ ਜੋ ਸਿੱਖੇ ਹੋਏ ਪੈਟਰਨਾਂ ਨਾਲ ਮੈਚ ਕਰਦਾ ਹੈ।
ਇਹ ਮੰਨਣਾ ਗਲਤ ਹੈ ਕਿ ਮਾਡਲ ਵਿਸ਼ੇਸ਼ ਤੱਥਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ "ਲੁਕਅਪ" ਕਰ ਸਕਦਾ ਹੈ। ਟ੍ਰੇਨਿੰਗ ਇੰਡੈਕਸਿੰਗ ਵਾਲੀ ਨ੍ਹਾਂ ਹੈ; ਇਹ ਕੁਝ ਵੱਡੇ ਡੇਟਾ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਕੇ ਵਜ਼ਨ (weights) ਵਿੱਚ ਡਾਲ ਦਿੰਦੀ ਹੈ ਜੋ ਭਵਿੱਖੀ ਭਵਿੱਖਵਾਣੀਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਮਾਡਲ ਕਈ ਵਾਰ ਐਸੇ ਵੇਰਵਿਆਂ 'ਤੇ ਭਰੋਸੇਯੋਗ ਦਿਸਣ ਵਾਲੀ ਗਲਤ ਜਾਣਕਾਰੀ ਦੇ ਸਕਦਾ ਹੈ ਜੋ ਇਹ ਅਨੁਮਾਨ 'ਤੇ ਨਿਰਭਰ ਹੋ ਕੇ ਦਿੰਦਾ ਹੈ।
ਪੈਟਰਨ ਸਿੱਖਣਾ ਫਲੂਏਂਟ ਅਤੇ ਸੰਬੰਧਿਤ ਟੈਕਸਟ ਬਣਾਉਣ ਲਈ ਤਾਕਤਵਰ ਹੈ, ਪਰ ਫਲੂਏਂਸੀ ਸੱਚਾਈ ਨਾਲ ਬਰਾਬਰ ਨਹੀਂ। ਮਾਡਲ:
ਐਪ ਬਿਲਡਰਾਂ ਲਈ ਮੁੱਖ ਨਤੀਜਾ: LLM ਦੇ ਜਵਾਬ ਆਮ ਤੌਰ 'ਤੇ ਸਿੱਖੇ ਹੋਏ ਪੈਟਰਨਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਨ ਕਿ ਪੁਸ਼ਟੀ ਕੀਤੇ ਤੱਥਾਂ ਤੋਂ। ਜੇ ਸਹੀਪਨ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਨਤੀਜਿਆਂ ਨੂੰ ਆਪਣੇ ਡੇਟਾ ਅਤੇ ਚੈੱਕਾਂ ਨਾਲ ਜ਼ਮੀਨੀ ਕਰੋ।
ਜਦੋਂ ਇੱਕ LLM ਜਵਾਬ ਲਿਖਦਾ ਹੈ, ਇਹ ਕਿਸੇ ਇਕ "ਸਹੀ ਵਾਕ" ਨੂੰ ਨਹੀਂ ਖਿੱਚ ਰਿਹਾ। ਹਰ ਕਦਮ 'ਤੇ ਇਹ ਅਗਲੇ ਟੋਕਨ ਲਈ ਕਈ ਸੰਭਾਵਿਤ ਵਿਕਲਪਾਂ ਦਾ ਹਿਸਾਬ ਕਰਦਾ ਹੈ, ਹਰ ਇਕ ਦੀ ਆਪਣੀ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਹੈ।
ਜੇ ਮਾਡਲ ਹਮੇਸ਼ਾਂ ਸਿਰਫ ਸਭ ਤੋਂ ਸੰਭਾਵਤ ਅਗਲਾ ਟੋਕਨ ਚੁਣਦਾ, ਤਾਂ ਨਤੀਜੇ ਬਹੁਤ ਲਗਾਤਾਰ ਹੁੰਦੇ—ਪਰ ਇੱਕੇ ਹੀ ਅਤੇ ਕਦਾਚਿਤ ਕੁੱਝ ਕਠੋਰ। ਇਸ ਲਈ ਅਧਿਕਤਨ ਪ੍ਰਣਾਲੀਆਂ ਸੰਭਾਵਨਾਵਾਂ ਵਿੱਚੋਂ ਸੈਂਪਲ ਲੈਂਦੀਆਂ ਹਨ, ਜੋ ਨਿਯੰਤਰਿਤ ਰਾਂਡਮਨੈਸ ਲਿਆਉਂਦਾ ਹੈ।
ਦੋ ਆਮ ਸੈਟਿੰਗ ਹਨ ਜੋ ਨਤੀਜਿਆਂ ਦੀ ਵਿਆਪਕਤਾ ਨੂੰ ਰੂਪ ਦਿੰਦੀਆਂ ਹਨ:
ਜੇ ਤੁਸੀਂ ਐਪ ਬਣਾਉ ਰਹੇ ਹੋ, ਇਹ ਨਾਬਜ਼ ਉਸਤੋਂ "ਕਲਾਕਾਰੀ ਰਚਨਾਤਮਕਤਾ" ਤੋਂ ਵੱਧ ਉਹ ਹੈ ਕਿ:
ਕਿਉਂਕਿ ਮਾਡਲ plausible ਟੈਕਸਟ ਲਈ ਅਪਟਿਮਾਈਜ਼ ਕਰ ਰਿਹਾ ਹੈ, ਇਹ ਐਸੇ ਬਿਆਨ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਪੱਕੇ-ਪੱਕੇ ਲੱਗਦੇ ਹਨ—ਚਾਹੇ ਅਧਾਰ ਗਲਤ ਹੋਵੇ ਜਾਂ ਮਹੱਤਵਪੂਰਕ ਸੰਦਰਭ ਘਾਟਾ ਹੋਵੇ। ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਜਦੋਂ ਸਹੀਪਨ ਮਾਇਨੇ ਰੱਖਦੀ ਹੋਵੇ ਤਾਂ ਐਪ ਵਿੱਚ ਅਕਸਰ ਰੀਟ੍ਰੀਵਲ ਜਾਂ ਵੈਰੀਫਿਕੇਸ਼ਨ ਸਟੈਪ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ।
LLM ਨੂੰ ਪੁੱਛੋ: “ਇੱਕ JavaScript ਫੰਕਸ਼ਨ ਲਿਖੋ ਜੋ ਇੱਕ ਐਰੇ ਤੋਂ ਡੁਪਲੀਕੇਟ ਹਟਾਵੇ।” ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਮਿਲ ਸਕਦਾ ਹੈ—ਸਭ ਠੀਕ ਹਨ:
// Option A: concise
const unique = (arr) => [...new Set(arr)];
// Option B: explicit
function unique(arr) {
return arr.filter((x, i) => arr.indexOf(x) === i);
}
ਵੱਖ-ਵੱਖ ਸੈਂਪਲਿੰਗ ਚੋਣਾਂ ਵਖ-ਵਖ ਅੰਦਾਜ਼ (ਸੰਖੇਪ ਬਨਾਮ ਵਿਸਥਾਰ), ਵੱਖਰੇ ਤਰ੍ਹਾਂ ਦੇ ਟਰੇਡ-ਆਫ (ਗਤੀ, ਪੜ੍ਹਨਯੋਗਤਾ), ਅਤੇ ਇਨਪੁੱਟ ਦੇ ਏਜ-ਕੇਸ ਵਿਹਾਰ ਵੀ ਲਿਆ ਸਕਦੀਆਂ ਹਨ—ਸਾਰਾ ਕੁੱਝ ਬਿਨਾ ਮਾਡਲ ਦਾ "ਰਾਏ ਬਦਲਣ" ਦੇ। ਇਹ ਸਿਰਫ਼ ਉੱਚ-ਸੰਭਾਵਿਤ ਲਗਾਤਾਰ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਚੁਣਨ ਹੈ।
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਮਾਡਲ ਤੁਹਾਡੀ ਗੱਲ-ਬਾਤ "ਯਾਦ" ਰੱਖਦਾ ਹੈ, ਤਦ ਅਸਲ ਵਿੱਚ ਇਸਦੇ ਕੋਲ ਉਹ ਕੰਟੈਕਸਟ ਹੁੰਦਾ ਹੈ: ਉਹ ਟੈਕਸਟ ਜੋ ਮਾਡਲ ਇਸ ਸਮੇਂ ਦੇਖ ਸਕਦਾ ਹੈ—ਤੁਹਾਡਾ ਨਵੀਨਤਮ ਸੁਨੇਹਾ, ਕੋਈ ਸਿਸਟਮ ਨਿਰਦੇਸ਼, ਅਤੇ ਜੋ ਕੁਝ ਵੀ ਪਹਿਲਾਂ ਦੀ ਗੱਲਬਾਤ ਵਿੱਚ ਹੋ ਕੇ ਵੀ ਖਿੜਦਾ ਹੈ।
ਕੰਟੈਕਸਟ ਵਿੰਡੋ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੀਮਾ ਹੈ ਕਿ ਮਾਡਲ ਇਕ ਵਾਰੀ ਵਿੱਚ ਕਿੰਨਾ ਟੈਕਸਟ ਵਿਚਾਰ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਗੱਲ-ਬਾਤ ਇਸ ਤੋਂ ਲੰਬੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਪਹਿਲੇ ਹਿੱਸੇ ਵਿੰਡੋ ਤੋਂ ਬਾਹਰ ਨਿਕਲ ਜਾਂਦੇ ਹਨ ਅਤੇ ਮਾਡਲ ਦੇ ਨਜ਼ਰ ਤੋਂ ਹਟ ਜਾਂਦੇ ਹਨ।
ਇਸ ਲਈ ਤੁਸੀਂ ਅਕਸਰ ਐਸਾ ਵੇਖੋਗੇ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਥ੍ਰੈਡ 'ਤੇ ਸਦਾ ਨਵੇਂ ਸੁਨੇਹੇ ਪਾਇਆ ਜਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸੀਮਤ ਜਗ੍ਹਾ ਲਈ ਮੁਕਾਬਲਾ ਕਰ ਰਹੇ ਹੋ। ਮਹੱਤਵਪੂਰਨ ਨਿਯਮ-ਭਾਗ ਨਵੀਂ-ਨਵੀਂ ਗੱਲਬਾਤ ਨਾਲ ਬਾਹਰ ਹੋ ਸਕਦੇ ਹਨ। ਬਿਨਾਂ ਸੰਖੇਪ ਦੇ, ਮਾਡਲ ਜੋ ਕੁਝ ਵੀ ਦਿਖਾਈ ਦੇ ਰਿਹਾ ਹੈ ਉਸ ਤੋਂ ਹੀ ਨਿਰਣੇ ਲੈਂਦਾ ਹੈ—ਇਸ ਲਈ ਇਹ ਪੱਕਾ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਚੁਪਚਾਪ ਕੁਝ ਮੁੱਖ ਵੇਰਵੇ ਗੁਆ ਸਕਦਾ ਹੈ।
ਇੱਕ ਵਰਤਣਯੋਗ ਢੰਗ ਹੈ ਕਿ ਤੁਸੀਂ ਥੋੜਾ-ਥੋੜਾ ਸਮਾਂ ਬਾਅਦ ਸੰਖੇਪ ਬਣਾਓ: ਲਕੜੀਵਾਰ ਰੂਪ ਵਿੱਚ ਲਕੜੀ-ਫੈਸਲਿਆਂ ਅਤੇ ਪਾਬੰਦੀਆਂ ਨੂੰ ਦੁਹਰਾਓ, ਫਿਰ ਉੱਥੋਂ ਅੱਗੇ ਵਧੋ। ਐਪ ਵਿੱਚ, ਇਹ ਅਕਸਰ ਇੱਕ ਆਟੋਮੈਟਿਕ "ਗੱਲ-ਬਾਤ ਸੰਖੇਪ" ਵਜੋਂ ਪ੍ਰਭਾਵੀ ਹੁੰਦਾ ਹੈ ਜਿਸਨੂੰ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਮਾਡਲ ਅਕਸਰ ਉਹ ਨਿਰਦੇਸ਼ ਮਾਨਦਾ ਹੈ ਜੋ ਉਤਪਾਦ ਦੇ ਫੌਰ-ਨੀਕਟ ਆਉਟਪੁੱਟ ਦੇ ਨੇੜੇ ਹੁੰਦੇ ਹਨ। ਇਸ ਲਈ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਮਸਤ-ਮੰਗਾਂ ਹਨ (ਫਾਰਮੈਟ, ਟੋਨ, ਐਜ-ਕੇਸ), ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰਾਂਪਟ ਦੇ ਆਖ਼ਰ ਵਿੱਚ ਰੱਖੋ—ਠੀਕ ਉੱਥੇ ਜਿੱਥੇ "ਹੁਣ ਜਵਾਬ ਪੈਦਾ ਕਰੋ" ਹੋਵੇ।
ਜੇ ਤੁਸੀਂ ਐਪ ਬਣਾ ਰਹੇ ਹੋ, ਇਹਨੂੰ ਇੰਟਰਫੇਸ ਡਿਜ਼ਾਈਨ ਵਾਂਗ ਸੋਚੋ: ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਕਿੱਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਕੰਟੈਕਸਟ ਵਿੱਚ ਸਦਾ ਰਹੇ (ਲੋੜਾਂ, ਯੂਜ਼ਰ ਪਸੰਦ, ਸਕੀਮਾ), ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਹ ਹਮੇਸ਼ਾਂ ਸ਼ਾਮਿਲ ਹੈ—ਇਥੇ ਤੱਕ ਕਿ ਚੈਟ ਇਤਿਹਾਸ ਨੂੰ ਛਾਂਟ ਕੇ ਜਾਂ ਇੱਕ ਸੰਖੇਪ ਸ਼ਾਮਿਲ ਕਰਕੇ। ਵਧੇਰੇ ਪ੍ਰਾਂਪਟ ਸਟ੍ਰਕਚਰਿੰਗ ਲਈ ਵੇਖੋ: /blog/prompting-as-interface-design.
LLMs ਟੈਕਸਟ ਪੈਦਾ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਵਧੀਆ ਹਨ ਜੋ ਇੱਕ ਮਾਹਿਰ ਵਿਕਾਸਕਰਤਾ ਵਾਂਗ ਲੱਗਦੇ ਹਨ। ਪਰ "ਠੀਕ ਲੱਗਣਾ" ਅਤੇ "ਠੀਕ ਹੋਣਾ" ਇੱਕੋ ਗੱਲ ਨਹੀਂ। ਮਾਡਲ ਅਗਲੇ ਟੋਕਨ ਲਈ ਭਵਿੱਖਵਾਣੀ ਕਰ ਰਿਹਾ ਹੈ, ਨਾ ਕਿ ਤੁਹਾਡੇ ਕੋਡਬੇਸ, ਡਿਪੈਂਡੈਂਸੀਜ਼ ਜਾਂ ਅਸਲ ਦੁਨੀਆ ਦੇ ਖਿਲਾਫ਼ ਆਉਟਪੁੱਟ ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ।
ਜਦੋਂ ਮਾਡਲ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ—ਇੱਕ ਫਿਕਸ, ਰਿਫੈਕਟਰ, ਜਾਂ ਨਵੀਂ ਫੰਕਸ਼ਨ—ਤਾਂ ਵੀ ਉਹ ਸਿਰਫ਼ ਲਿਖਤ ਹੀ ਹੈ। ਇਹ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਕਦੇ ਚਲਾਉਂਦਾ, ਪੈਕੇਜ ਇੰਸਟਾਲ ਕਰਦਾ, API ਨੂੰ ਹਿੱਟ ਕਰਦਾ, ਜਾਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਕੰਪਾਇਲ ਕਰਦਾ ਨਹੀਂ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਸੇ ਐਸੇ ਟੂਲ ਨਾਲ ਨਹੀਂ ਜੋੜਦੇ ਜੋ ਇਹ ਕੰਮ ਕਰ ਸਕੇ (ਜਿਵੇਂ ਕਿ ਟੈਸਟ ਰੰਨਰ, ਲਿੰਟਰ, ਜਾਂ ਬਿਲਡ ਸਟੈਪ)।
ਇਹ ਮੁੱਖ ਵੱਖਰਾ ਨੁਕਤਾ ਹੈ:
ਜਦੋਂ AI ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਹ ਅਕਸਰ ਪੇਸ਼ਗੋਈਯੋਗ ਢੰਗ ਨਾਲ ਫੇਲ ਹੁੰਦਾ ਹੈ:
ਇਹ ਗਲਤੀਆਂ ਪਹਚਾਣਣਾ ਔਖਾ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਵਿਆਖਿਆ ਆਮ ਤੌਰ 'ਤੇ ਸੁਚਾਰੂ ਹੁੰਦੀ ਹੈ।
AI ਆਉਟਪੁੱਟ ਨੂੰ ਉਸ ਸਹਿ-ਟੀਮ-ਮੀਬਰ ਦੀ ਤਰ੍ਹਾਂ ਮੰਨੋ ਜਿਸਨੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ ਚਲਾਇਆ। ਭਰੋਸਾ ਉੱਚਾ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ:
ਜੇ ਟੈਸਟ ਪਾਸ ਨਹੀਂ ਹੁੰਦੇ, ਤਾਂ ਮਾਣੋ ਕਿ ਮਾਡਲ ਦਾ ਜਵਾਬ ਸਿਰਫ਼ ਸ਼ੁਰੂਆਤ ਹੈ—ਅੰਤਿਮ ਫਿਕਸ ਨਹੀਂ।
ਇੱਕ ਭਾਸ਼ਾ ਮਾਡਲ ਇਹ ਸੁਝਾ ਸਕਦਾ ਹੈ ਕਿ "ਕੀ ਹੋ ਸਕਦਾ ਹੈ"—ਪਰ ਆਪਣੇ ਆਪ ਇਹ ਅਜੇ ਵੀ ਸਿਰਫ਼ ਲਿਖਤ ਹੈ। ਟੂਲ ਉਹ ਹਨ ਜੋ AI-ਸਹਾਇਤ ਵਾਲੀ ਐਪ ਨੂੰ ਉਹ ਪ੍ਰਸਤਾਅ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਬਦਲਣ ਦਿੰਦੀਆਂ ਹਨ: ਕੋਡ ਚਲਾਉਣਾ, ਡੇਟਾਬੇਸ ਪੁੱਛਤਾਛ, ਦਸਤਾਵੇਜ਼ ਲਿਆਉਣਾ, ਜਾਂ ਕਿਸੇ ਬਾਹਰੀ API ਨੂੰ ਕਾਲ ਕਰਨਾ।
ਐਪ-ਬਣਾਉਣ ਕਾਰਜ-ਪ੍ਰਵਾਹ ਵਿੱਚ, ਟੂਲ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦਿੱਸਦੇ ਹਨ:
ਅਹੰਕਾਰਕ ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਮਾਡਲ ਹੁਣ ਦਾਅਵਾ ਨਹੀਂ ਕਰ ਰਿਹਾ ਕਿ ਉਹ ਨਤੀਜਾ ਜਾਣਦਾ—ਇਹ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਕ ਉਪਯੋਗੀ ਮਾਨਸਿਕ ਮਾਡਲ ਹੈ:
ਇਸ ਤਰੀਕੇ ਨਾਲ ਤੁਸੀਂ "ਅਨੁਮਾਨ" ਘਟਾ ਸਕਦੇ ਹੋ। ਜੇ ਲਿੰਟਰ unused imports ਦਿਖਾਏ, ਮਾਡਲ ਕੋਡ ਅਪਡੇਟ ਕਰੇਗਾ। ਜੇ ਯੂਨਿਟ ਟੈਸਟ ਫੇਲ ਹੋਣ, ਤਾਂ ਇਹ ਫੇਲਅ ਅਤੇ ਏਜ-ਕੇਸਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਦੁਹਰਾਏਗਾ (ਜਾਂ ਸਮਝਾਏਗਾ ਕਿ ਕਿਉਂ ਨਹੀਂ ਹੋ ਸਕਦਾ)।
eslint/ruff/prettier ਚਲਾਕੇ ਸਟਾਈਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਅਤੇ ਮੁੱਦਿਆਂ ਨੂੰ ਪਕੜਦਾ।ਟੂਲ ਤਾਕਤਵਰ—ਅਤੇ ਖ਼ਤਰਨਾਕ—ਹੋ ਸਕਦੇ ਹਨ। least privilege ਦੀ ਪਾਲਣਾ ਕਰੋ:
ਟੂਲ ਮਾਡਲ ਨੂੰ "ਜ਼ਿਆਦਾ ਚਤੁਰ" ਨਹੀਂ ਬਣਾਉਂਦੇ—ਪਰ ਉਹ ਤੁਹਾਡੀ ਐਪ ਦੇ AI ਨੂੰ ਜ਼ਮੀਨੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ, ਸਿਰਫ਼ ਨੈਰੇਟ ਨਹੀਂ ਕਰਦਾ।
ਇੱਕ ਭਾਸ਼ਾ ਮਾਡਲ ਚੰਗੀ ਲਿਖਤ ਅਤੇ ਸਾਰ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਇਹ ਦੇਖ ਸਕਦਾ ਹੈ। ਪਰ ਇਹ ਆਪਣੇ-आप ਹੀ ਤੁਹਾਡੇ ਤਾਜ਼ਾ ਪ੍ਰੋਡਕਟ ਬਦਲਾਅ, ਕੰਪਨੀ ਨੀਤੀਆਂ, ਜਾਂ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਗਾਹਕ ਦੇ ਖਾਤੇ ਦੇ ਵੇਰਵੇ ਨਹੀਂ ਜਾਣਦਾ। Retrieval‑Augmented Generation (RAG) ਇੱਕ ਸਧਾਰਨ ਹੱਲ ਹੈ: ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਭੰਧਤ ਤੱਥ ਖਿੱਚੋ, ਫਿਰ ਮਾਡਲ ਨੂੰ ਉਹਨਾਂ ਤੱਥਾਂ ਨਾਲ ਜਵਾਬ ਬਣਾਉਣ ਦਿਓ।
RAG ਨੂੰ "ਓਪਨ-ਬੁੱਕ AI" ਸਮਝੋ। ਮਾਡਲ ਨੂੰ ਯਾਦ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਹਾਡੀ ਐਪ ਸਭ ਤੋਂ ਸਬੰਧਤ ਪੈਰਾਗ੍ਰਾਫ (snippets) ਖਿੱਚਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰਦੀ ਹੈ। ਫਿਰ ਮਾਡਲ ਉਨ੍ਹਾਂ ਮੁਹੱਈਆ ਕੀਤੇ ਸਮੱਗਰੀ ਦੀ ਆਧਾਰ 'ਤੇ ਜਵਾਬ ਬਣਾਉਂਦਾ ਹੈ।
RAG ਨੂੰ ਹਰ ਵਾਰੀ ਵਰਤਣਾ ਵਧੀਆ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਹੀਪਨ ਬਾਹਰਲੇ ਜਾਣਕਾਰੀਆਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ:
ਜੇ ਤੁਹਾਡੇ ਐਪ ਦੀ ਕੀਮਤ "ਸਾਡੀ ਬਿਜ਼ਨਸ ਲਈ ਸਹੀ ਜਵਾਬ" 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ RAG ਆਮ ਤੌਰ 'ਤੇ ਉਮੀਦ 'ਤੇ ਮਾਡਲ ਨੂੰ ਅਣਪੜਿਆ ਪੁੱਛਣ ਨਾਲੋਂ ਵਧੀਆ ਹੈ।
RAG ਉਸ ਸਮੱਗਰੀ ਤੋਂ ਹੀ ਚੰਗੀ ਹੁੰਦੀ ਹੈ ਜੋ ਇਹ ਖਿੱਚਦਾ ਹੈ। ਜੇ ਖੋਜ ਕਦਮ ਪੁਰਾਣੇ, ਅਸਬੰਧਤ, ਜਾਂ ਅਧੂਰੇ ਪੈਸਾਜ਼ ਲਿਆਉਂਦਾ ਹੈ, ਤਾਂ ਮਾਡਲ ਪੱਕਾ-ਪੱਞਪਾ ਉੱਤਰ ਦੇ ਸਕਦਾ ਹੈ—ਹੁਣ "ਗਲਤ ਸਰੋਤ" 'ਤੇ ਆਧਾਰਿਤ। ਅਮਲ ਵਿੱਚ, retrieval ਦੀ ਗੁਣਵੱਤਾ (ਚੰਕਿੰਗ, ਮੈਟਾਡੇਟਾ, ਤਾਜ਼ਗੀ, ਰੈਂਕਿੰਗ) ਨੂੰ ਸੁਧਾਰਨਾ ਅਕਸਰ ਪ੍ਰਾਂਪਟ ਟਿੱਕ-ਟਿੱਕਾਂ ਨਾਲੋਂ ਵੱਧ ਨਤੀਜੇ ਦਿੰਦਾ ਹੈ।
"ਏਜੰਟ" ਸਿਰਫ਼ ਇੱਕ LLM ਹੈ ਜੋ ਲੂਪ ਵਿੱਚ ਚੱਲਦਾ: ਇਹ ਯੋਜਨਾ ਬਣਾਂਦਾ, ਇੱਕ ਕਦਮ ਲੈਂਦਾ, ਜੋ ਹੋਇਆ ਵੇਖਦਾ, ਅਤੇ ਫਿਰ ਫੈਸਲਾ ਕਰਦਾ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇ। ਇਕੱਲੇ ਉੱਤਰ ਦੇਣ ਦੀ ਥਾਂ, ਇਹ ਲਕੜੀਵਾਰ ਕਰਵਾਈ ਕਰਦਾ ਜਦੋਂ ਤੱਕ ਉਹ ਮਕਸਦ ਨਾ ਪੂਰਾ ਹੋ ਜਾਏ।
ਇੱਕ ਲਾਗੂ ਮਾਨਸਿਕ ਮਾਡਲ ਹੈ:
Plan → Do → Check → Revise
ਇਹ ਲੂਪ ਇੱਕ ਸਿੰਗਲ ਪ੍ਰਾਂਪਟ ਨੂੰ ਇੱਕ ਛੋਟੀ ਵਰਕਫਲੋ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਏਜੰਟਾਂ ਨੂੰ ਜ਼ਿਆਦਾ "ਅਜ਼ਾਦ" ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ—ਮਾਡਲ ਸਿਰਫ ਲਿਖਤ ਹੀ ਨਹੀਂ ਬਣਾ ਰਿਹਾ, ਇਹ ਕਾਰਵਾਈਆਂ ਚੁਣਦਾ ਅਤੇ ਲੜੀਬੱਧ ਕਰਦਾ ਹੈ।
ਏਜੰਟਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਸਪਸ਼ਟ ਨਿਯਮ ਚਾਹੀਦੇ ਹਨ। ਆਮ ਰੋਕਣ ਦੀਆਂ ਸ਼ਰਤਾਂ:
ਗਾਰਡਰੇਲ ਉਹ ਪਾਬੰਦੀਆਂ ਹਨ ਜੋ ਲੂਪ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਭਵਿੱਟਯੋਗ ਰੱਖਦੀਆਂ ਹਨ: ਆਗਿਆਪਾਤੀ ਟੂਲ, ਮਨਜ਼ੂਰ ਕੀਤਾ ਡਾਟਾ ਸਰੋਤ, ਮਨੁੱਖੀ-ਇਨ-ਦਾ-ਲੂਪ ਲਈ ਪੁਸ਼ਟੀ, ਅਤੇ ਆਉਟਪੁੱਟ ਫਾਰਮੇਟ।
ਕਿਉਂਕਿ ਇੱਕ ਏਜੰਟ ਹਮੇਸ਼ਾਂ "ਹੋਰ ਇੱਕ ਕਦਮ" ਸੁਝਾ ਸਕਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਫੇਲ ਮੋਡਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਬਿਨਾਂ ਬਜਟ, ਟਾਈਮਆਉਟ ਅਤੇ ਕਦਮ ਸੀਮਾਵਾਂ, ਏਜੰਟ ਮੁੜ-ਮੁੜ ਕਾਰਵਾਈਆਂ ('ਹੌਲੀ-ਹੌਲੀ ਹੋਰ ਇੱਕ ਖੋਜ ਕੋਸ਼ਿਸ਼ ਕਰੋ') ਵਿੱਚ ਫਸ ਸਕਦਾ ਹੈ ਜਾਂ ਖ਼ਰਚ ਬੜਾ ਸਕਦਾ ਹੈ।
ਪ੍ਰਯੋਗਿਕ ਡਿਫ਼ਾਲਟ: ਇਟਰੈਸ਼ਨਾਂ ਨੂੰ ਕੈਪ ਕਰੋ, ਹਰ ਕਾਰਵਾਈ ਲੌਗ ਕਰੋ, ਟੂਲ ਨਤੀਜਿਆਂ ਦੀ ਜਾਂਚ ਲਾਜ਼ਮੀ ਕਰੋ, ਅਤੇ ਆਫਟ-ਗਰੇਸਫੁੱਲ ਪ੍ਰਤੀਉਤਰ ਦੇਵੋ ਜੋ ਇੱਕ ਅਧੂਰਾ ਜਵਾਬ ਅਤੇ ਕੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਗਈ—ਇਹ ਅਕਸਰ ਉਸ ਤੋਂ ਵਧੀਆ ਹੈ ਕਿ ਏਜੰਟ ਅਨੰਤ ਲੂਪ ਵਿੱਚ ਰਹਿ ਜਾਵੇ।
ਜੇ ਤੁਸੀਂ vibe-coding ਪਲੇਟਫਾਰਮ ਵਰਗਾ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ "ਏਜੰਟ + ਟੂਲ" ਮਾਨਸਿਕ ਮਾਡਲ ਬਹੁਤ ਹੀ ਕਾਰਗਰ ਹੈ। ਤੁਸੀਂ ਸਿਰਫ ਸੁਝਾਅ ਲਈ ਗੱਲ-ਬਾਤ ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਇਕ ਐਸਾ ਵਰਕਫਲੋ ਉਪਯੋਗ ਕਰ ਰਹੇ ਹੋ ਜਿੱਥੇ ਮਦਦਗਾਰ ਫੀਚਰ ਯੋਜਨਾ ਬਣਾਉਣ, React/Go/PostgreSQL ਜਾਂ Flutter ਕੰਪੋਨੈਂਟ ਜਨਰੇਟ ਕਰਨ, ਅਤੇ ਚੈਕਪੋਇੰਟਸ (snapshots ਅਤੇ rollback) ਵਰਗੇ ਮਕੈਨਿਜ਼ਮਾਂ ਨਾਲ ਇੰਟਰੇਕਟ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵੱਧ ਸਕੋ ਬਿਨਾਂ ਬਦਲਾਵਾਂ 'ਤੇ ਨਿਯੰਤਰਣ ਗੁਆਉਣ ਦੇ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ LLM ਨੂੰ ਕਿਸੇ ਐਪ ਫੀਚਰ ਦੇ ਪਿੱਛੇ ਰੱਖਦੇ ਹੋ, ਤੁਹਾਡਾ ਪ੍ਰਾਂਪਟ 'ਸਿਰਫ ਟੈਕਸਟ' ਨਹੀਂ ਰਹਿੰਦਾ। ਇਹ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਅਤੇ ਮਾਡਲ ਦੇ ਦਰਮਿਆਂਨ ਇੰਟਰਫੇਸ ਦਾ ਕਾਂਟਰੈਕਟ ਹੁੰਦਾ ਹੈ: ਮਾਡਲ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਇਹ ਕੀ ਵਰਤ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਕਿਸ ਤਰ੍ਹਾਂ ਜਵਾਬ ਦੇਵੇ ਤਾਂ ਕਿ ਤੁਹਾਡੀ ਕੋਡ ਆਸਾਨੀ ਨਾਲ ਖਪਤ ਕਰ ਸਕੇ।
ਇੱਕ ਮਦਦਗਾਰ ਸੋਚ ਇਹ ਹੈ ਕਿ ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ UI ਫਾਰਮਾਂ ਵਾਂਗ سمجھੋ। ਚੰਗੀਆਂ ਫਾਰਮਾਂ ਅਸਪਸ਼ਟਤਾ ਘਟਾਉਂਦੀਆਂ ਹਨ, ਚੋਣਾਂ ਨੂੰ ਸੀਮਤ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਸਪਸ਼ਟ ਕਰਦੀਆਂ ਹਨ। ਚੰਗੇ ਪ੍ਰਾਂਪਟ ਵੀ ਇਹੀ ਕਰਦੇ ਹਨ।
ਪ੍ਰਾਂਪਟ ਨੂੰ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਦੱਸਦਾ ਹੈ:
ਮਾਡਲ ਪੈਟਰਨਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਪੈਟਰਨ ਸਿਖਾਉਣ ਦਾ ਇੱਕ ਤਾਕਤਵਰ ਤਰੀਕਾ ਇੱਕ ਚੰਗੇ ਇਨਪੁੱਟ ਅਤੇ ਆਉਟਪੁੱਟ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਸ਼ਾਮਿਲ ਕਰਨਾ ਹੈ (ਖ਼ਾਸ ਕਰਕੇ ਜੇ ਤੁਹਾਡੇ ਟਾਸਕ ਵਿੱਚ ਏਜ-ਕੇਸ ਹਨ)।
ਇੱਕ ਹੀ ਉਦਾਹਰਨ ਬਹੁਤ ਸਾਰੇ ਬੈਕ-ਐਂਡ-ਫੋਰਥ ਘਟਾ ਸਕਦੀ ਹੈ ਅਤੇ ਮਾਡਲ ਨੂੰ ਉਸ ਫਾਰਮੇਟ ਨੂੰ ਬਣਾਉਣ ਤੋਂ ਰੋਕਦੀ ਹੈ ਜੋ ਤੁਹਾਡੇ UI ਲਈ ਦਿਖਾਉਣਾ ਔਖਾ ਹੋਵੇ।
ਜੇ ਕਿਸੇ ਹੋਰ ਸਿਸਟਮ ਨੂੰ ਜਵਾਬ ਪੜ੍ਹਨਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸਰਗ੍ਰਹਿਤ ਬਣਾਓ। JSON, ਇੱਕ ਸਾਰਣੀ, ਜਾਂ ਸਖਤ ਬੁਲੇਟ ਨਿਯਮ ਮੰਗੋ।
You are a helpful assistant.
Task: {goal}
Inputs: {inputs}
Constraints:
- {constraints}
Output format (JSON):
{
"result": "string",
"confidence": "low|medium|high",
"warnings": ["string"],
"next_steps": ["string"]
}
ਇਸ ਨਾਲ "ਪ੍ਰਾਂਪਟਿੰਗ" ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਇੰਟਰਫੇਸ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਸਪਸ਼ਟ ਨਿਯਮ ਸ਼ਾਮਿਲ ਕਰੋ: "ਜੇ ਕੁੰਜੀ ਲੋੜਾਂ ਗਾਇਬ ਹਨ, ਤਾਂ ਜਵਾਬ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਸਪਸ਼ਟੀਕਰਨ ਸਵਾਲ ਪੁੱਛੋ."
ਇਕੋ ਇੱਕ ਲਾਈਨ ਕਈ ਵਾਰ ਦੂਜੀਂ-ਭਰੋਸੇਯੋਗ, ਗਲਤ-ਲੱਗਣ ਵਾਲੀਆਂ ਆਉਟਪੁੱਟਾਂ ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ—ਕਿਉਂਕਿ ਮਾਡਲ ਨੂੰ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਥਾਂ ਰੋਕਿਆ ਜਾ ਰਿਹਾ ਹੈ ਅਤੇ ਉਹ ਟਿਕੜੇ ਪੁੱਛਣ ਲਈ ਮਿਲਿਆ-ਜੁਲਿਆ ਸਮਾਂ ਲੈਂਦਾ ਹੈ।
ਅਮਲੀ ਤੌਰ 'ਤੇ, ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਪ੍ਰਾਂਪਟ ਉਹ ਹਨ ਜੋ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਦੇ ਬਣਾਉਣ ਅਤੇ ਤੈਅਰ-ਕਰਨ ਦੇ ਤਰੀਕੇ ਨਾਲ ਮੇਲ ਰੱਖਦੇ ਹਨ। ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਪਹਿਲਾਂ ਯੋਜਨਾ ਤਿਆਰ ਕਰਨ, ਫਿਰ ਬਦਲਾਅ ਜਨਰੇਟ ਕਰਨ, ਫਿਰ ਸੋਧਾਂ ਨਿਰਯਾਤ/ਡਿਪਲੌਇ ਕਰਨ ਨੂੰ ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਪ੍ਰਾਂਪਟ ਕਾਂਟਰੈਕਟ ਵਿੱਚ ਦਰਸਾ ਸਕਦੇ ਹੋ (plan → produce diff/steps → confirm → apply)। Koder.ai ਦੀ "planning mode" ਇੱਕ ਚੰਗਾ ਉਦਾਹਰਨ ਹੈ ਕਿ ਕਿਵੇਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਪੱਸ਼ਟ ਫੇਜ਼ਾਂ ਵਿੱਚ ਵੰਡਣ ਨਾਲ ਡ੍ਰਿਫਟ ਘਟਦੀ ਹੈ ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਬਦਲਾਅ ਸਮੀਖਿਆ ਕਰਨ ਵਿੱਚ ਆਸਾਨੀ ਹੁੰਦੀ ਹੈ।
ਭਰੋਸਾ ਮਾਡਲ ਦੇ "ਪੱਕਾ ਲੱਗਣ" ਤੋਂ ਨਹੀਂ ਆਉਂਦਾ; ਇਹ ਤੁਹਾਡੇ AI ਆਉਟਪੁੱਟ ਨੂੰ ਹੋਰ ਇੱਕ ਨਿਰਭਰਤਾ ਵਜੋਂ ਮਾਪਿਆ, ਨਿਗਰਾਨੀ ਕੀਤਾ ਅਤੇ ਸੀਮਤ ਕੀਤਾ ਜਾਣ ਨਾਲ ਆਉਂਦਾ ਹੈ।
ਛੋਟੀ ਗਿਣਤੀ ਦੇ ਅਸਲੀ ਟਾਸਕ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਅੱਛੀ ਤਰ੍ਹਾਂ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਦੁਹਰਾਓਗੇ ਚੈੱਕਾਂ ਵਿੱਚ ਬਦਲੋ:
"ਔਕਚਾ ਚੰਗਾ ਹੈ?" ਪੁੱਛਣ ਦੀ ਥਾਂ, ਟਰੈਕ ਕਰੋ "ਇਹ ਕਿੰਨੀ ਵਾਰੀ ਪਾਸ ਹੁੰਦਾ ਹੈ?" ਉਪਯੋਗ ਮੈਟ੍ਰਿਕਸ:
ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਮੁੜ-ਚਲਾਉਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਲੌਗ ਕਰੋ (ਉਚਿਤ ਰੀਡੈਕਸ਼ਨ ਨਾਲ):
ਇਸ ਨਾਲ ਡਿਬੱਗ ਕਰਨਾ ਅਸਾਨ ਬਣਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਪੁੱਛ ਸਕਦੇ ਹੋ "ਕੀ ਮਾਡਲ ਬਦਲਿਆ, ਜਾਂ ਸਾਡਾ ਡੇਟਾ/ਟੂਲ ਬਦਲਿਆ?"
ਕੁਝ ਡਿਫ਼ਾਲਟ ਪ੍ਰਵਧਾਨ ਆਮ ਘਟਨਾਵਾਂ ਰੋਕਦੇ ਹਨ:
ਇਸਦਾ ਅਰਥ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਮਾਡਲ ਸਮਰਥ, ਲਕੜੀਵਾਰ ਟੈਕਸਟ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਸਮਝ ਅਤੇ ਤਰਕ ਕਰਨ ਵਰਗਾ ਲੱਗਦਾ ਹੈ। ਹਕੀਕਤ ਵਿੱਚ, ਇੱਕ LLM "ਅਗਲਾ-ਟੋਕਨ ਭਵਿੱਖਵਾਣੀ" ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ: ਇਹ ਉਹੀ ਜਨਰੇਸ਼ਨ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਪ੍ਰਾਂਪਟ, ਨਿਰਦੇਸ਼ ਅਤੇ ਦਿੱਤੀ ਗਈ ਸੰਦਰਭ ਦੇ ਆਧਾਰ 'ਤੇ ਸਭ ਤੋਂ ਸੰਭਾਵਤ ਅਗਲਾ ਟੋਕਨ ਹੈ।
ਐਪ ਬਣਾਉਣ ਵਾਲਿਆਂ ਲਈ ਲਾਭ ਇਹ ਹੈ ਕਿ “ਸੋਚਣਾ” ਉਹ ਨਤੀਜਾ-ਵਰਤੀ ਵਰਤੋਂ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸ਼ੇਪ ਦੇ ਸਕਦੇ ਹੋ ਅਤੇ ਨਿਯੰਤ੍ਰਿਤ ਕਰ ਸਕਦੇ ਹੋ—ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਸੱਚਾਈ ਦੀ ਗਰੰਟੀ ਨਹੀਂ।
ਇੱਕ ਟੋਕਨ ਉਹ ਟੁਕੜਾ ਹੈ ਜਿਸ 'ਤੇ ਮਾਡਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਜੋ ਇਹ ਪੈਦਾ ਕਰਦਾ ਹੈ (ਇੱਕ ਪੂਰਾ ਸ਼ਬਦ, ਸ਼ਬਦ ਦਾ ਹਿੱਸਾ, विरਾਮ ਚਿੰਨ੍ਹ, ਜਾਂ ਖਾਲੀ ਥਾਂ)। ਕਿਉਂਕਿ ਮਾਡਲ ਟੋਕਨਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਖ਼ਰਚੇ, ਸੀਮਾਵਾਂ ਅਤੇ ਟ੍ਰੰਕੇਸ਼ਨ ਸਾਰੇ ਟੋਕਨ-ਆਧਾਰਿਤ ਹੁੰਦੇ ਹਨ।
ਅਮਲੀ ਤੌਰ 'ਤੇ:
ਕਿਉਂਕਿ ਜਨਰੇਸ਼ਨ ਸੰਭਾਵਨਾਤਮਕ ਹੈ। ਹਰ ਕਦਮ 'ਤੇ ਮਾਡਲ ਕਈ ਸੰਭਾਵਤ ਅਗਲੇ ਟੋਕਨਾਂ ਨੂੰ ਅਲਾਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਣਾਲੀਆਂ ਉਸ ਵੰਡ ਤੋਂ ਸੈਂਪਲ ਲੈਂਦੀਆਂ ਹਨ ਬਜਾਏ ਕਿ ਹਮੇਸ਼ਾਂ ਸਿਰਫ ਸਭ ਤੋਂ ਉੱਚਾ ਵਿਕਲਪ ਚੁਣਨ।
ਨਤੀਜਿਆਂ ਨੂੰ ਜ਼ਿਆਦਾ ਦੋਹਰਾਏ ਜਾਣਯੋਗ ਬਣਾਉਣ ਲਈ:
LLMs ਸੁਚਾਰੂ ਟেক্সਟ ਪੈਦਾ ਕਰਨ ਲਈ ਢਾਲੇ ਜਾਂਦੇ ਹਨ, ਨ ਕਿ ਤੱਥਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ। ਉਹਨਾਂ ਨੂੰ ਪੱਕਾ ਲੱਗਣ ਵਾਲੀ ਬੋਲੀ ਦੇਣ ਦੀ ਆਦਤ ਦੱਸੀ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਐਸਾ ਪੈਟਰਨ ਟ੍ਰੇਨਿੰਗ ਡੇਟਾ ਵਿੱਚ ਆਮ ਹੈ, ਚਾਹੇ ਆਧਾਰਿਕ ਦਾਅਵਾ ਅਨੁਮਾਨ ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ।
ਪ੍ਰੋਡਕਟ ਡਿਜ਼ਾਈਨ ਵਿੱਚ, ਲਿਖਤ ਤਰਤੀਬ ਨੂੰ “ਚੰਗੀ ਲਿਖਾਈ” ਵਜੋਂ ਮੰਨੋ, ਨਾ ਕਿ “ਸਹੀ”—ਜਦੋਂ ਸਹੀ ਜਾਣਕਾਰੀ ਜ਼ਰੂਰੀ ਹੋਵੈ ਤਾਂ RAG, ਟੂਲ, ਟੈਸਟ ਜਾਂ ਮਨੁੱਖ-ਇਨ-ਦਾ-ਲੂਪ ਵਰਗੇ ਚੈੱਕ ਸ਼ਾਮਿਲ ਕਰੋ।
ਕੰਟੈਕਸਟ ਵਿਂਡੋ ਮਾਡਲ ਦੀ ਵੱਖ-ਵੱਖ ਸਮਝ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਉਹ ਲਿਮਿਟ ਹੈ ਕਿ ਮਾਡਲ ਇਕ ਵਾਰ ਵਿੱਚ ਕਿੰਨਾ ਟੈਕਸਟ ਦੇਖ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਗੱਲ-ਬਾਤ ਲੰਮੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਪੁਰਾਣੇ ਹਿੱਸੇ ਇਸ ਵਿਂਡੋ ਤੋਂ ਬਾਹਰ ਚਲੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਮਾਡਲ ਉਹਨਾਂ ਨੂੰ "ਯਾਦ" ਨਹੀਂ ਰੱਖਦਾ।
ਰੋਕਥਾਮ ਲਈ:
ਨਹੀਂ। ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਮਾਡਲ-Web ਬ੍ਰਾਊਜ਼ ਨਹੀਂ ਕਰਦਾ, ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਨਹੀਂ ਪੜ੍ਹਦਾ, ਅਤੇ ਨਹੀਂ ਚਲਾਉਂਦਾ—ਇਸ ਨੂੰ ਉਹੀ ਜਾਣਕਾਰੀ ਮਿਲਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰਦੇ ਹੋ ਜਾਂ ਜਿਹੜੇ ਟੂਲ ਤੁਸੀਂ ਜੋੜਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਨੂੰੱਤੇ-ਅੰਦਰੂਨੀ ਜਾਂ ਅੱਪ-ਟੂ-ਡੇਟ ਤੱਥਾਂ 'ਤੇ ਨਿਰਭਰ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਰੀਟ੍ਰੀਵਲ (RAG) ਜਾਂ ਟੂਲ ਕਾਲ ਰਾਹੀਂ ਪ੍ਰਾਪਤ ਕਰੋ—"ਹੋਰ ਸਖਤ ਪੁੱਛੋ" ਕਰਨ ਦੀ ਉਮੀਦ ਨਾ ਰੱਖੋ।
ਟੂਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਦੋਂ ਤੁਹਾਨੂੰ "ਪ੍ਰਮਾਣਿਤ ਨਤੀਜੇ" ਜਾਂ ਅਸਲ ਕਾਰਵਾਈ ਚਾਹੀਦੀ ਹੋਵੇ ਨਾ ਕਿ ਸਿਰਫ ਸੰਭਾਵਤ ਲਿਖਤ। ਆਮ ਉਦਾਹਰਨਾਂ:
ਇੱਕ ਚੰਗਾ ਪੈਟਰਨ ਹੈ propose → check → adjust: ਮਾਡਲ ਸੁਝਾਵੇ, ਟੂਲ ਚਲਾਏ, ਅਤੇ ਨਤੀਜੇ ਦੇ ਆਧਾਰ 'ਤੇ ਮੁੜ ਅਪਡੇਟ ਕਰੇ।
RAG (Retrieval‑Augmented Generation) ਇੱਕ "ਓਪਨ‑ਬੁੱਕ" ਤਰੀਕਾ ਹੈ: ਤੁਹਾਡੀ ਐਪ ਸਭ ਤੋਂ ਸਬੰਧਤ ਨੁਕਤੇ (snippets) ਖਿੱਚਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਪਾ ਕੇ ਮਾਡਲ ਨੂੰ ਮਨੁੱਖੀ-ਅਧਾਰਿਤ ਤੱਥਾਂ 'ਤੇ ਨਿਰਭਰ ਜਵਾਬ ਲੈਣ ਲਈ ਕਹਿੰਦੀ ਹੈ।
RAG ਵਰਤੋ ਜਦੋਂ:
ਦੀਖੋ ਕਿ ਖੋਜ ਕਦਮ ਜਿੰਨਾ ਚੰਗਾ ਹੋਵੇਗਾ, ਨਤੀਜੇ ਉਤਨੇ ਹੀ ਭਰੋਸੇਯੋਗ ਹੋਣਗੇ—ਸਲੀਕਾ, ਫਰੈਸ਼ਨੈਸ ਅਤੇ ਰੈਂਕਿੰਗ ਉੱਤੇ ਧਿਆਨ ਦਿਓ।
ਏਜੰਟ ਇੱਕ LLM ਹੈ ਜੋ ਲੂਪ ਵਿੱਚ ਚੱਲਦਾ ਹੈ: ਇਹ ਯੋਜਨਾ ਬਣਾਉਂਦਾ, ਇੱਕ ਕਦਮ ਲੈਂਦਾ, ਨਤੀਜੇ ਵੇਖਦਾ, ਅਤੇ ਫਿਰ ਫੇਰ ਸੋਚਦਾ ਹੈ। ਇਹ ਇੱਕ-ਬਾਰ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ—ਇਹ ਲਕੜੀਵਾਰ ਕੰਮ ਕਰ ਕੇ ਟਾਸਕ ਪੂਰਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।
ਰੋਕਥਾਮ ਲਈ:
ਪ੍ਰਾਂਪਟ ਨੂੰ ਇੱਕ ਇੰਟਰਫੇਸ ਕरਾਰ ਦਿਓ: ਇਹ ਦੱਸੋ ਕਿ ਮਾਡਲ ਦਾ ਮਕਸਦ ਕੀ ਹੈ, ਇਹ ਕਿਹੜੀਆਂ ਜਾਣਕਾਰੀਆਂ ਵਰਤ ਸਕਦਾ/ਸਕਦੀ ਹੈ, ਅਤੇ ਇਹ ਕਿਵੇਂ ਜਵਾਬ ਦੇਵੇ ਤਾਂ ਕਿ ਤੁਹਾਡੀ ਕੋਡ ਭਰੋਸੇਯੋਗੀ ਢੰਗ ਨਾਲ ਨਤੀਜਾ ਲੈ ਸਕੇ।
ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਲਈ: