ਏਜੰਟ ਦੀ ਬਿਹਤਰ ਕਾਰਗੁਜ਼ਾਰੀ ਚਾਹੁੰਦੀਆਂ ਜ਼ਿਆਦਾਤਰ AI ਟੀਮਾਂ ਉਹੀ ਸਾਧਨ ਵਰਤਦੀਆਂ ਹਨ: ਵੱਡੀਆਂ ਸੰਦਰਭ ਸੀਮਾਵਾਂ, ਹੋਰ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਵਧੇਰੇ ਚੁਸਤ ਪ੍ਰੌਂਪਟ. ਇਸ ਲੇਖ ਦੀ ਦਲੀਲ ਹੈ ਕਿ ਇਹ ਸੋਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗ਼ਲਤ ਹੈ. ਗੁੰਮ ਤੱਤ ਹੋਰ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੈ. ਉਹ ਨਿਯੰਤਰਣ ਹੈ. ਵਧੀਆ ਢੰਗ ਨਾਲ ਬਣੀ ਨਿਯੰਤਰਣ ਪਰਤ ਹੀ ਡੈਮੋ ਵਿੱਚ ਚੱਲਣ ਵਾਲੇ ਏਜੰਟ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਚੱਲਣ ਵਾਲੇ ਏਜੰਟ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ.
AI ਏਜੰਟ ਨੂੰ ਵੱਡੀ ਯਾਦਦਾਸ਼ਤ, ਹੋਰ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਲੰਮੀ ਸੰਦਰਭ ਸੀਮਾ ਦੇਣ ਨਾਲ ਉਹ ਵਧੇਰੇ ਬੁੱਧੀਮਾਨ ਨਹੀਂ ਹੁੰਦਾ—ਸਿਰਫ਼ ਹੌਲਾ ਅਤੇ ਮਹਿੰਗਾ ਹੋ ਜਾਂਦਾ ਹੈ. ਅਸਲ ਲਾਭ ਏਜੰਟ ਨੂੰ ਸਭ ਕੁਝ ਇੱਕੋ ਵਾਰ ਵਰਤਣ ਦੀ ਬਜਾਏ ਇਹ ਚੁਣਨਾ ਸਿਖਾਉਣ ਨਾਲ ਮਿਲਦੇ ਹਨ ਕਿ ਉਸ ਨੂੰ ਕੀ ਅਤੇ ਕਦੋਂ ਚਾਹੀਦਾ ਹੈ.
ਭਰੋਸੇਯੋਗਤਾ ਲੂਪ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਮਾਡਲ ਤੋਂ ਨਹੀਂ. ਡੈਮੋ ਵਿੱਚ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੇ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਟਿਕਣ ਵਾਲੇ ਏਜੰਟ ਵਿਚਲਾ ਫ਼ਰਕ AI ਦੀ ਗੁਣਵੱਤਾ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਸਿਸਟਮ ਆਪਣੇ ਕੰਮ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ. ਹਰ ਪੜਾਅ ਉੱਤੇ ਯੋਜਨਾ ਬਣਾਉਣ, ਕਾਰਵਾਈ ਕਰਨ, ਨਿਰੀਖਣ ਅਤੇ ਤਸਦੀਕ ਕਰਨ ਵਾਲੇ ਏਜੰਟ ਪੂਰੇ ਭਰੋਸੇ ਨਾਲ ਗ਼ਲਤ ਹੋਣ ਦੀ ਬਜਾਏ ਆਪਣੀਆਂ ਗ਼ਲਤੀਆਂ ਆਪ ਫੜ ਲੈਂਦੇ ਹਨ.
ਅੱਜ ਜ਼ਿਆਦਾਤਰ AI ਏਜੰਟ ਅਸਲ ਵਿੱਚ ਵਾਧੂ ਪੜਾਵਾਂ ਵਾਲੇ ਚੈਟਬੌਟ ਹਨ—ਉਨ੍ਹਾਂ ਕੋਲ ਇਹ ਜਾਣਨ ਦਾ ਕੋਈ ਢੰਗ ਨਹੀਂ ਕਿ ਉਹ ਸਹੀ ਰਾਹ ਉੱਤੇ ਹਨ, ਕਦੋਂ ਰੁਕਣਾ ਹੈ ਜਾਂ ਕਦੋਂ ਵੱਖਰਾ ਤਰੀਕਾ ਅਜ਼ਮਾਉਣਾ ਹੈ. ਢੁਕਵੀਂ ਨਿਯੰਤਰਣ ਪਰਤ—ਸਪਸ਼ਟ ਸਫਲਤਾ ਮਾਪਦੰਡ, ਢਾਂਚਾਬੱਧ ਸਥਿਤੀ ਅਤੇ ਤਸਦੀਕੀ ਜਾਂਚਾਂ—ਹੀ ਏਜੰਟ ਵਰਗੀ ਵਸਤੂ ਨੂੰ ਸੱਚਮੁੱਚ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੀ ਹੈ.
ਤੁਸੀਂ ਕੱਲ੍ਹ ਦੁਪਹਿਰ ਦੇ ਖਾਣੇ ਵਿੱਚ ਕੀ ਖਾਧਾ ਸੀ?
ਸ਼ਾਇਦ ਤੁਸੀਂ ਆਪਣੀ ਹਰ ਪੁਰਾਣੀ ਯਾਦ ਨੂੰ ਉਦੋਂ ਤੱਕ ਮੁੜ ਨਹੀਂ ਚਲਾਇਆ, ਜਦੋਂ ਤੱਕ “ਕੱਲ੍ਹ + ਦੁਪਹਿਰ ਦਾ ਖਾਣਾ” ਨਾ ਮਿਲ ਗਿਆ. ਤੁਸੀਂ ਸਿੱਧੇ ਆਪਣੇ ਅਨੁਭਵ ਦੇ ਉਸ ਹਿੱਸੇ ਤੱਕ ਪਹੁੰਚੇ, ਜਿੱਥੇ ਇਹ ਧਾਰਨਾਵਾਂ ਵੱਸਦੀਆਂ ਹਨ. ਏਜੰਟ ਬਣਾਉਣ ਲਈ ਇਹ ਇੱਕ ਲਾਭਦਾਇਕ ਮਾਨਸਿਕ ਮਾਡਲ ਹੈ:
ਵਿਸ਼ਾਲ ਸੰਦਰਭ ਸੀਮਾ ਯਾਦਦਾਸ਼ਤ ਨਹੀਂ ਹੁੰਦੀ.
ਪ੍ਰਾਪਤ ਕੀਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਢੇਰ ਸਮਝ ਨਹੀਂ ਹੁੰਦਾ.
ਲੰਮੀ ਚੇਨ-ਆਫ-ਥੌਟ ਭਰੋਸੇਯੋਗਤਾ ਨਹੀਂ ਹੁੰਦੀ.
ਇਹ ਸਿਰਫ਼ ਸਮੱਗਰੀ ਹੈ. ਪਰ ਜਿਸ ਚੀਜ਼ ਨਾਲ ਇੱਕ ਏਜੰਟ ਸੱਚਮੁੱਚ ਏਜੰਟ ਲੱਗਦਾ ਹੈ, ਉਹੀ ਤੁਹਾਡੇ ਦਿਮਾਗ਼ ਨੂੰ ਪੂਰੇ ਜੀਵਨ-ਇਤਿਹਾਸ ਵਿੱਚ ਅੰਨ੍ਹੀ ਖੋਜ ਕਰਨ ਤੋਂ ਰੋਕਦੀ ਹੈ: ਨਿਯੰਤਰਣ.
ਇੱਕ ਹਾਲੀਆ ਸਰਵੇਖਣ—ਵੱਡੇ ਭਾਸ਼ਾ ਮਾਡਲਾਂ ਲਈ ਏਜੰਟਿਕ ਰੀਜ਼ਨਿੰਗ—ਨੇ ਉਸ ਤਬਦੀਲੀ ਨੂੰ ਬਹੁਤ ਵਧੀਆ ਢੰਗ ਨਾਲ ਸੰਖੇਪ ਅਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜੋ ਸਾਡੇ ਵਿੱਚੋਂ ਬਹੁਤਿਆਂ ਨੇ ਨਿਰਮਾਣ ਦੌਰਾਨ ਮਹਿਸੂਸ ਕੀਤੀ ਹੈ: ਮਾਡਲ ਦੇ ਅੰਦਰ ਰੀਜ਼ਨਿੰਗ ਤੋਂ ਪਰਸਪਰ ਕਿਰਿਆ ਰਾਹੀਂ ਰੀਜ਼ਨਿੰਗ ਤੱਕ. ਇਹ ਲੇਖ ਉਸ ਖੋਜ-ਪੱਤਰ ਦਾ ਸਾਰ ਨਹੀਂ ਹੈ. ਇਹ ਉਸ ਤਬਦੀਲੀ ਨੂੰ ਵਿਹਾਰਕ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਢਾਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਹੈ:
ਜੇ ਤੁਸੀਂ ਏਜੰਟਾਂ ਨੂੰ ਟੂਲਾਂ ਵਾਲੇ ਚੈਟਬੌਟਾਂ ਵਾਂਗ ਬਣਾਓਗੇ, ਤਾਂ ਚੈਟਬੌਟ ਵਾਲੀਆਂ ਅਸਫਲਤਾਵਾਂ ਮਿਲਦੀਆਂ ਰਹਿਣਗੀਆਂ—ਬੱਸ ਗ਼ਲਤੀਆਂ ਹੋਰ ਮਹਿੰਗੀਆਂ ਹੋਣਗੀਆਂ.
ਕੁਝ ਸਮੇਂ ਤੱਕ “ਮਾਡਲ ਨੂੰ ਵਧੇਰੇ ਬੁੱਧੀਮਾਨ ਬਣਾਉਣ” ਦੀ ਸਾਡੀ ਮੂਲ ਰਣਨੀਤੀ ਇਹ ਸੀ: ਬਿਹਤਰ ਪ੍ਰੌਂਪਟ, ਚੇਨ-ਆਫ-ਥੌਟ, ਸਵੈ-ਇਕਸਾਰਤਾ ਜਾਂ ਨਮੂਨਾ-ਅਧਾਰਿਤ ਸੁਧਾਰ ਅਤੇ ਸ਼ਾਇਦ ਕੁਝ ਖੋਜ.
ReAct ਇੱਕ ਨਿਰਣਾਇਕ ਮੋੜ ਸੀ, ਕਿਉਂਕਿ ਇਸ ਨੇ “ਵਿਚਾਰ → ਕਾਰਵਾਈ → ਨਿਰੀਖਣ” ਨੂੰ ਸੁਭਾਵਿਕ ਬਣਾ ਦਿੱਤਾ. ਪਰ ਲੁਕੀ ਹੋਈ ਪਾਬੰਦੀ ਵੇਖੋ: ਇਸ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਅਜੇ ਵੀ “ਵਧੇਰੇ ਟੋਕਨਾਂ ਨਾਲ ਵਨ-ਸ਼ਾਟ ਅਨੁਮਾਨ” ਬਣ ਜਾਂਦਾ ਹੈ. ਸਰਵੇਖਣ ਦੀ ਪੇਸ਼ਕਾਰੀ ਵਧੇਰੇ ਸਪਸ਼ਟ ਹੈ: ਏਜੰਟਿਕ ਰੀਜ਼ਨਿੰਗ ਟੈਸਟ-ਸਮੇਂ ਦੀ ਪਰਸਪਰ ਕਿਰਿਆ ਵਧਾਉਣ ਉੱਤੇ ਜ਼ੋਰ ਦਿੰਦੀ ਹੈ—ਅਨੁਮਾਨ ਨੂੰ ਦੁਹਰਾਈ ਜਾਂਦੀ ਪ੍ਰਕਿਰਿਆ ਬਣਾਉਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਮਾਡਲ, ਯਾਦਦਾਸ਼ਤ ਅਤੇ ਵਾਤਾਵਰਨ ਸਾਰੇ ਲੂਪ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ.
ਜੇ ਤੁਸੀਂ ਅਜਿਹੇ ਏਜੰਟ ਬਣਾਏ ਜਾਂ ਵਰਤੇ ਹਨ ਜੋ ਡੈਮੋ ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪਰ ਅਸਲ ਕਾਰਜ-ਪ੍ਰਵਾਹਾਂ ਵਿੱਚ ਨਾਜ਼ੁਕ ਲੱਗਦੇ ਹਨ, ਤਾਂ ਇਹ ਤੁਹਾਡੇ ਲਈ ਹੈ.
ਮੈਂ ਉਹ ਤਰੀਕਾ ਦੱਸਦਾ ਹਾਂ ਜੋ ਮੈਂ ਬਹੁਤ ਵਾਰ ਵੇਖਿਆ ਹੈ ਅਤੇ ਜਿਸ ਦੇ ਰੂਪ ਖ਼ੁਦ ਵੀ ਬਣਾਏ ਹਨ:
ਇੱਕ ਚੰਗਾ ਚੈਟ ਮਾਡਲ ਲਓ
ਕੁਝ ਟੂਲ ਜੋੜੋ, ਜਿਵੇਂ ਖੋਜ, DB ਪੁੱਛਗਿੱਛ ਅਤੇ ਸ਼ਾਇਦ ਕੋਡ ਚਲਾਉਣਾ
RAG ਜੋੜੋ
“ਤੁਸੀਂ ਇੱਕ ਖ਼ੁਦਮੁਖ਼ਤਿਆਰ ਏਜੰਟ ਹੋ” ਵਾਲਾ ਸਿਸਟਮ ਪ੍ਰੌਂਪਟ ਜੋੜੋ
ਇਸ ਸਭ ਨੂੰ ਉਦੋਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਲੂਪ ਵਿੱਚ ਲਪੇਟੋ, ਜਦੋਂ ਤੱਕ ਇਹ ਰੁਕ ਨਾ ਜਾਵੇ ਜਾਂ ਸਮਾਂ ਮੁੱਕ ਨਾ ਜਾਵੇ
ਵਧਾਈਆਂ, ਤੁਹਾਡੇ ਕੋਲ ਏਜੰਟ ਵਰਗੀ ਵਸਤੂ ਹੈ. ਪਰ ਇਹ ਅਨੁਮਾਨਯੋਗ ਢੰਗਾਂ ਨਾਲ ਅਸਫਲ ਹੁੰਦੀ ਹੈ:
ਸੰਦਰਭ ਦਾ ਫੁਲਾਅ: ਹਰ ਨਿਰੀਖਣ ਜੋੜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ; ਪ੍ਰੌਂਪਟ ਪੁਰਾਤੱਤਵੀ ਪਰਤਾਂ ਬਣ ਜਾਂਦੇ ਹਨ.
ਟੂਲਾਂ ਦੀ ਅੰਨ੍ਹੀ ਵਰਤੋਂ: “ਪੂਰੇ ਭਰੋਸੇ ਨਾਲ ਗ਼ਲਤ ਟੂਲ” ਮੂਲ ਅਸਫਲਤਾ ਦਾ ਢੰਗ ਬਣ ਜਾਂਦਾ ਹੈ.
ਰੁਕਣ ਦੀਆਂ ਸ਼ਰਤਾਂ ਨਹੀਂ: ਇਹ ਇਸ ਲਈ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ ਕਿ ਚੱਲ ਸਕਦਾ ਹੈ, ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ.
ਗ੍ਰਾਊਂਡਿੰਗ ਦਾ ਅਨੁਸ਼ਾਸਨ ਨਹੀਂ: ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਮਜਬੂਰ ਨਾ ਕਰੋ, ਇਹ ਆਪਣੀ ਗ਼ਲਤੀ ਨਹੀਂ ਪਛਾਣਦਾ.
ਮੇਮੋਰੀ = ਚੈਟ ਇਤਿਹਾਸ: ਅਸਲ ਵਿੱਚ ਲੌਗ ਲਿਖ ਕੇ ਉਸ ਨੂੰ ਸਿੱਖਣਾ ਕਹਿ ਦੇਣਾ.
ਇਸੇ ਲਈ “ਏਜੰਟ” ਅਕਸਰ ਡੈਮੋ ਵਿੱਚ ਜਾਦੂਈ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਬੇਤਰਤੀਬ ਲੱਗਦੇ ਹਨ. ਏਜੰਟਿਕ ਸਿਸਟਮਾਂ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਲਿਆਉਣ ਦਾ ਸਾਡਾ ਅਨੁਭਵ ਵੀ ਇਹੀ ਦਿਖਾਉਂਦਾ ਹੈ: ਜਦੋਂ ਤੁਸੀਂ ਮਾਡਲ ਦੀ ਬਜਾਏ ਸਿਸਟਮ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੇ ਹੋ, ਤਾਂ ਅਸਫਲਤਾਵਾਂ ਵਿੱਚ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਨ, ਟੂਲਾਂ ਦੀ ਸੁਚੱਜੀ ਵਰਤੋਂ, ਸੰਦਰਭ ਦੀ ਛਾਂਟੀ ਅਤੇ ਮੁਲਾਂਕਣ ਡਿਜ਼ਾਈਨ ਵੀ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ—ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਿ “ਕੀ ਮਾਡਲ ਨੇ ਸਹੀ ਜਵਾਬ ਦਿੱਤਾ.”
ਇਸ ਲਈ ਸਵਾਲ ਬਣਦਾ ਹੈ: ਮਨੋਰਥ ਅਨੁਸਾਰ ਏਜੰਟ ਕਿਹੋ ਜਿਹਾ ਹੈ?
ਇਸ ਨੂੰ ਘੱਟ ਅਮੂਰਤ ਬਣਾਉਣ ਲਈ, ਇਹ ਇੱਕ ਸਧਾਰਨ ਕਾਰਜ-ਪ੍ਰਵਾਹ ਹੈ ਜਿਸ ਦੀ ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਕਲਪਨਾ ਕਰ ਸਕਦੇ ਹਨ: “ਅਗਲੇ ਮੰਗਲਵਾਰ ਲੰਡਨ ਤੋਂ ਨਿਊਯਾਰਕ ਲਈ ਮੇਰੀ ਉਡਾਣ ਬੁੱਕ ਕਰੋ. ਸ਼ਾਮ 6 ਵਜੇ ਤੋਂ ਪਹਿਲਾਂ ਪਹੁੰਚਣਾ ਹੈ. ਕੀਮਤ £900 ਤੋਂ ਘੱਟ ਰੱਖੋ. ਗਲਿਆਰੇ ਵਾਲੀ ਸੀਟ ਚਾਹੀਦੀ ਹੈ.”
ਇੱਕ ਆਮ “ਏਜੰਟ ਵਰਗਾ” ਅਮਲ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਹੈ:
ਤੁਰੰਤ ਏਅਰਲਾਈਨ ਅਤੇ ਯਾਤਰਾ ਨੀਤੀ ਦੇ ਢੇਰ ਸਾਰੇ ਦਸਤਾਵੇਜ਼ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਭਾਵੇਂ ਅਜੇ ਕਿਸੇ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ.
ਖੋਜ ਟੂਲ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਨਤੀਜਿਆਂ ਦੀ ਲੰਮੀ ਸੂਚੀ ਪ੍ਰੌਂਪਟ ਵਿੱਚ ਚਿਪਕਾਉਂਦਾ ਹੈ ਅਤੇ “ਇੱਕ ਚੁਣ ਲੈਂਦਾ ਹੈ.”
ਪਾਬੰਦੀਆਂ—ਪਹੁੰਚਣ ਦਾ ਸਮਾਂ, ਸਮਾਨ, ਸੀਟ ਅਤੇ ਨੀਤੀ—ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੇ ਬਿਨਾਂ ਕਾਹਲੀ ਵਿੱਚ ਬੁਕਿੰਗ ਕਰ ਦਿੰਦਾ ਹੈ.
ਅਸਫਲ ਹੋਣ ਉੱਤੇ ਇਹ ਥੋੜ੍ਹੇ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਸਪਸ਼ਟ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕੀ ਬਦਲਿਆ ਜਾਂ ਇਸ ਨੇ ਕੀ ਸਿੱਖਿਆ.
ਅਸਫਲਤਾ ਦਾ ਕਾਰਨ ਇਹ ਨਹੀਂ ਕਿ ਮਾਡਲ ਰੀਜ਼ਨਿੰਗ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਸਿਸਟਮ ਕਾਰਜ-ਪ੍ਰਵਾਹ ਨੂੰ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰਦਾ.
ਇੱਕ ਵਧੇਰੇ ਏਜੰਟਿਕ ਰੂਪ ਕਾਰਜ ਨੂੰ ਸਪਸ਼ਟ ਸਥਿਤੀ ਅਤੇ ਜਾਂਚਾਂ ਵਾਲੀ ਪਰਸਪਰ ਪ੍ਰਕਿਰਿਆ ਮੰਨਦਾ ਹੈ:
ਯੋਜਨਾ: ਪਾਬੰਦੀਆਂ ਮੁੜ ਦੱਸੋ ਅਤੇ ਗੁੰਮ ਜਾਣਕਾਰੀ ਦੀ ਸੂਚੀ ਬਣਾਓ, ਜਿਵੇਂ “ਕਿਹੜਾ ਹਵਾਈ ਅੱਡਾ ਪਸੰਦ ਹੈ?” ਜਾਂ “ਕੀ ਇੱਕ ਠਹਿਰਾਅ ਠੀਕ ਹੈ?”
ਕਾਰਵਾਈ: ਢਾਂਚਾਬੱਧ ਪੁੱਛਗਿੱਛ—ਮਿਤੀ ਦੀ ਮਿਆਦ, ਪਹੁੰਚਣ ਦੀ ਪਾਬੰਦੀ ਅਤੇ ਬਜਟ—ਨਾਲ ਉਡਾਣ ਖੋਜ ਨੂੰ ਕਾਲ ਕਰੋ.
ਨਿਰੀਖਣ: ਨਤੀਜਿਆਂ ਨੂੰ ਚਿਪਕਾਏ ਹੋਏ ਵੱਡੇ ਢੇਰ ਦੀ ਬਜਾਏ ਸੰਖੇਪ ਸਥਿਤੀ ਆਬਜੈਕਟ ਵਿੱਚ ਸੰਭਾਲੋ, ਜਿਸ ਵਿੱਚ ਕੀਮਤ, ਪਹੁੰਚ ਅਤੇ ਠਹਿਰਾਵਾਂ ਸਮੇਤ ਚੋਟੀ ਦੇ 5 ਵਿਕਲਪ ਹੋਣ.
ਅੱਪਡੇਟ: ਪਾਬੰਦੀਆਂ ਪੂਰੀਆਂ ਨਾ ਹੋਣ ਉੱਤੇ ਪੁੱਛਗਿੱਛ ਸੁਧਾਰੋ, ਜਿਵੇਂ “ਸ਼ਾਮ 6 ਵਜੇ ਤੋਂ ਪਹਿਲਾਂ ਪਹੁੰਚਣ ਦੀ ਸ਼ਰਤ ਬਹੁਤ ਸਖ਼ਤ ਹੈ—ਸਮਾਂ ਵਧਾਈਏ ਜਾਂ ਬਜਟ?”
ਤਸਦੀਕ: ਵੈਲੀਡੇਟਰ ਚਲਾਓ (“ਪਹੁੰਚ < 18:00,” “ਕੀਮਤ ≤ £900,” “ਨੀਤੀ ਦੀ ਪਾਲਣਾ,” “ਸੀਟ ਚੋਣ ਉਪਲਬਧ”).
ਰੁਕੋ: ਸਿਰਫ਼ ਉਦੋਂ, ਜਦੋਂ ਬੁਕਿੰਗ API ਪੁਸ਼ਟੀ ਵਾਪਸ ਕਰੇ ਅਤੇ ਸਾਰੇ ਵੈਲੀਡੇਟਰ ਪਾਸ ਹੋਣ.
ਤਬਦੀਲੀ ਸੂਖਮ ਹੈ, ਪਰ ਨਿਰਣਾਇਕ ਹੈ. ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤੀ ਸ਼ਰਤ-ਅਧੀਨ ਹੈ, ਸਹਿਜ ਪ੍ਰਤੀਕਿਰਿਆ ਨਹੀਂ; ਸੰਦਰਭ ਦਾ ਪ੍ਰਬੰਧ ਹੁੰਦਾ ਹੈ, ਸਥਿਤੀ ਢਾਂਚਾਬੱਧ ਹੈ ਨਾ ਕਿ ਇਕੱਠੀ ਕੀਤੀ ਹੋਈ; ਅਤੇ ਤਸਦੀਕ ਲੂਪ ਵਿੱਚ ਹੈ, ਵਰਤੋਂਕਾਰ ਦੇ ਸਿਰ ਨਹੀਂ ਛੱਡੀ ਗਈ. “ਉਡਾਣ ਬੁੱਕ ਕਰਨ” ਦੀ ਥਾਂ “ਖਰੀਦ ਆਰਡਰ ਬਣਾਉਣਾ,” “ਰਿਫੰਡ ਜਾਰੀ ਕਰਨਾ,” “ਪ੍ਰੋਡਕਸ਼ਨ ਸੰਰਚਨਾ ਬਦਲਣਾ” ਜਾਂ “PR ਭੇਜਣਾ” ਰੱਖ ਦਿਓ ਅਤੇ ਗੱਲ ਉਹੀ ਰਹਿੰਦੀ ਹੈ: ਜਦੋਂ ਏਜੰਟ ਕਾਰਵਾਈ ਕਰ ਸਕੇ, ਤਾਂ ਪ੍ਰੌਂਪਟ ਨਾਲੋਂ ਲੂਪ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ.
ਉੱਪਰਲੇ ਸਰਵੇਖਣ ਨੇ ਏਜੰਟਿਕ ਰੀਜ਼ਨਿੰਗ ਨੂੰ ਤਿੰਨ ਪਰਤਾਂ ਵਿੱਚ ਵੰਡਿਆ ਹੈ: ਬੁਨਿਆਦੀ—ਯੋਜਨਾ, ਟੂਲ ਦੀ ਵਰਤੋਂ ਅਤੇ ਖੋਜ; ਸਵੈ-ਵਿਕਾਸੀ—ਫੀਡਬੈਕ ਅਤੇ ਯਾਦਦਾਸ਼ਤ; ਅਤੇ ਸਮੂਹਿਕ—ਬਹੁ-ਏਜੰਟ ਤਾਲਮੇਲ.
ਪਰ ਡੂੰਘਾ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਰੀਜ਼ਨਿੰਗ ਸਿਰਫ਼ ਸੰਭਾਵੀ ਚੇਨ-ਆਫ-ਥੌਟ ਬਣਾਉਣ ਦੀ ਬਜਾਏ ਯੋਜਨਾ, ਫ਼ੈਸਲੇ ਅਤੇ ਤਸਦੀਕ ਦਾ ਸੰਗਠਨਕ ਸਿਧਾਂਤ ਬਣ ਜਾਂਦੀ ਹੈ. ਇਹ ਉਦੋਂ ਤੱਕ ਅਮੂਰਤ ਲੱਗਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇਸ ਨੂੰ ਆਪਣੇ ਢਾਂਚੇ ਦੀਆਂ ਤਬਦੀਲੀਆਂ ਨਾਲ ਨਹੀਂ ਜੋੜਦੇ. ਤਿੰਨ ਮੁੱਖ ਗੱਲਾਂ ਯਾਦ ਰੱਖੋ:
ਇੱਕ ਚੰਗੇ ਏਜੰਟ ਨੂੰ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤੀ ਨੂੰ “ਹਮੇਸ਼ਾ ਕਰਨ ਵਾਲਾ ਕੰਮ” ਨਹੀਂ ਮੰਨਣਾ ਚਾਹੀਦਾ. ਇਹ ਇੱਕ ਫ਼ੈਸਲਾ ਹੈ, ਸਹਿਜ ਪ੍ਰਤੀਕਿਰਿਆ ਨਹੀਂ.
ਇਹ ਇੱਕ ਵਿਹਾਰਕ ਸਧਾਰਨ ਨਿਯਮ ਹੈ:
ਜੇ ਤੁਹਾਡਾ ਸਿਸਟਮ ਹਰ ਵਾਰੀ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤੀ ਨਹੀਂ ਬਣਾਈ—ਤੁਸੀਂ ਸੰਦਰਭ ਕਰ ਲਗਾਇਆ ਹੈ.
ਅਸਲ ਕੰਮ ਵਿੱਚ ਇਹ ਹਰ ਵੇਲੇ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਪ੍ਰੋਡਕਸ਼ਨ ਘਟਨਾ ਦੀ ਗੜਬੜ ਲੱਭਦੇ ਸਮੇਂ ਤੁਸੀਂ ਸਾਰੇ ਲੌਗ ਸੰਦਰਭ ਵਿੱਚ ਨਹੀਂ ਸੁੱਟਦੇ; ਆਪਣੀ ਮੌਜੂਦਾ ਧਾਰਨਾ ਮੁਤਾਬਕ ਫ਼ੈਸਲਾ ਕਰਦੇ ਹੋ ਕਿ ਅੱਗੇ ਕਿਹੜੇ ਮਾਪਦੰਡ ਜਾਂ ਲੌਗ ਲੈਣੇ ਹਨ. ਇਹ “ਏਜੰਟਿਕ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤੀ” ਹੈ. ਇਸ ਦਾ ਇੱਕ ਹੋਰ ਠੋਸ ਤਰੀਕਾ ਇਹ ਹੈ:
ਫ਼ੈਸਲਾ ਕਰੋ ਕਿ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤੀ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਨਹੀਂ
ਜੇ ਹਾਂ: ਪੁੱਛਗਿੱਛ ਲਿਖੋ, ਜਾਣਕਾਰੀ ਲਵੋ, ਸਰਸਰੀ ਪੜ੍ਹੋ ਅਤੇ ਲੋੜੀਂਦਾ ਹਿੱਸਾ ਕੱਢੋ
ਜੇ ਸਬੂਤ ਟਕਰਾਉਣ: ਮੁੜ ਜਾਣਕਾਰੀ ਲਵੋ
ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਨਿਚੋੜ ਬਣਾਓ
ਇੱਥੇ ਹੀ “ਏਜੰਟਿਕ RAG” ਰਵਾਇਤੀ RAG ਤੋਂ ਵੱਖਰਾ ਹੋਣਾ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤੀ ਮੂਲ ਪਾਈਪਲਾਈਨ ਪੜਾਅ ਨਹੀਂ, ਸਗੋਂ ਸੋਚ-ਸਮਝ ਕੇ ਕੀਤਾ ਰੀਜ਼ਨਿੰਗ ਪੜਾਅ ਬਣਦੀ ਹੈ.
ਜਦੋਂ ਤੁਸੀਂ “ਇੱਕ ਮਾਡਲ” ਦੀ ਬਜਾਏ “ਇੱਕ ਸਿਸਟਮ” ਦਾ ਮੁਲਾਂਕਣ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਥਿਤੀ ਦੀ ਨਿਗਰਾਨੀ ਅਤੇ ਟਰੇਸਿੰਗ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੇ ਹਨ.
ਹੁਣ ਤੱਕ ਉਦਯੋਗ ਏਜੰਟ ਕਾਰਜ-ਪ੍ਰਵਾਹਾਂ ਦੀ ਨਿਗਰਾਨੀਯੋਗਤਾ ਬਾਰੇ ਵਧੇਰੇ ਸਪਸ਼ਟ ਹੋ ਗਿਆ ਹੈ. ਉਦਾਹਰਨ ਵਜੋਂ, OpenAI ਦੇ Agents SDK ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਟਰੇਸਿੰਗ ਅਤੇ Traces ਡੈਸ਼ਬੋਰਡ ਸ਼ਾਮਲ ਹਨ, ਜੋ ਏਜੰਟ ਦੀਆਂ ਕਾਰਵਾਈਆਂ—ਸਿਰਜਣਾ, ਟੂਲ ਕਾਲਾਂ, ਸੌਂਪਣ, ਸੁਰੱਖਿਆ ਨਿਯਮ ਅਤੇ ਕਸਟਮ ਘਟਨਾਵਾਂ—ਦਰਜ ਕਰਦੇ ਹਨ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਹਰ ਪੜਾਅ ਉੱਤੇ ਵਾਪਰੀ ਘਟਨਾ ਦੀ ਗੜਬੜ ਲੱਭ ਅਤੇ ਪੜਤਾਲ ਕਰ ਸਕੋ.
ਇਹ ਕੋਈ “ਹੋਵੇ ਤਾਂ ਚੰਗਾ” ਵਾਲੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਹੈ. ਇਹ ਗੜਬੜ ਲੱਭਣਯੋਗ ਸਿਸਟਮ ਅਤੇ ਸਿਰਫ਼ ਅੰਦਾਜ਼ੇ ਨਾਲ ਪਰਖੇ ਜਾ ਸਕਣ ਵਾਲੇ ਸਿਸਟਮ ਵਿਚਲਾ ਫ਼ਰਕ ਹੈ.
ਮੇਰੇ ਵਿਚਾਰ ਵਿੱਚ, ਸਰਵੇਖਣ ਦਾ ਸਭ ਤੋਂ ਅਮਲਯੋਗ ਹਿੱਸਾ ਇਹ ਹੈ ਕਿ ਇਹ ਫੀਡਬੈਕ ਬਾਰੇ ਕਿੰਨੀ ਸਿੱਧੀ ਗੱਲ ਕਰਦਾ ਹੈ. ਇਹ ਫੀਡਬੈਕ ਨੂੰ ਤਿੰਨ ਢੰਗਾਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ: ਚਿੰਤਨਸ਼ੀਲ ਫੀਡਬੈਕ (ਬਣਾਓ → ਆਲੋਚਨਾ ਕਰੋ → ਸੋਧੋ), ਪੈਰਾਮੀਟਰ-ਅਧਾਰਿਤ ਅਨੁਕੂਲਨ (ਫਾਈਨ-ਟਿਊਨਿੰਗ ਜਾਂ RL ਰਾਹੀਂ ਸਿੱਖੋ) ਅਤੇ ਵੈਲੀਡੇਟਰ-ਅਧਾਰਿਤ ਫੀਡਬੈਕ (ਵੈਲੀਡੇਟਰ ਦੀ ਮਨਜ਼ੂਰੀ ਤੱਕ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰੋ).
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਨੂੰ ਵੈਲੀਡੇਟਰ-ਅਧਾਰਿਤ ਫੀਡਬੈਕ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਸਾਦਾ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ. ਜੇ ਤੁਸੀਂ ਕੋਈ ਵੀ ਅਜਿਹਾ ਵੈਲੀਡੇਟਰ ਲਿਖ ਸਕਦੇ ਹੋ ਜੋ ਇਕਾਈ ਟੈਸਟ ਕਰੇ, ਸਕੀਮਾ ਜਾਂਚੇ, ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਜਾਂ ਪਾਬੰਦੀਆਂ ਤੈਅ ਕਰੇ (“ਬਿਨਾਂ ਉੱਚ ਪੱਧਰ ਉੱਤੇ ਭੇਜੇ X ਤੋਂ ਵੱਧ ਰਿਫੰਡ ਨਹੀਂ”) ਜਾਂ ਤੱਥਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੇ (“ਹਵਾਲੇ ਲਾਜ਼ਮੀ ਹਨ”), ਤਾਂ ਤੁਸੀਂ ਮਾਡਲ ਦੇ ਗ਼ੈਰ-ਨਿਰਧਾਰਤ ਨਤੀਜੇ ਨੂੰ ਸੱਚਮੁੱਚ ਭਰੋਸੇਯੋਗ ਬਣਾ ਸਕਦੇ ਹੋ.
ਇੱਥੇ ਇੱਕ “ਅਣਜਾਣ ਬਾਰੇ ਵੀ ਅਣਜਾਣ” ਤਬਦੀਲੀ ਬਹੁਤ ਸਧਾਰਨ ਹੈ: ਏਜੰਟਾਂ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਭਰੋਸੇਯੋਗਤਾ ਅਕਸਰ ਮਾਡਲ ਨਾਲੋਂ ਲੂਪ ਤੋਂ ਵੱਧ ਆਉਂਦੀ ਹੈ.
ਬਿਨਾਂ ਸਿਖਲਾਈ ਦੇ ਵਿਹਾਰ ਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਸੁਧਾਰਨ ਵਾਲਾ ਇਹ ਸਭ ਤੋਂ ਛੋਟਾ ਅਨੁਸ਼ਾਸਿਤ ਲੂਪ ਮੈਨੂੰ ਮਿਲਿਆ ਹੈ:
ਪੜਾਵਾਂ ਵਿੱਚ ਕੰਮ ਕਰੋ: ਯੋਜਨਾ → ਕਾਰਵਾਈ → ਨਿਰੀਖਣ → ਅੱਪਡੇਟ,
ਹਰ ਕਾਰਵਾਈ ਤੋਂ ਬਾਅਦ ਨਿਰੀਖਣ ਨੂੰ 1–3 ਨੁਕਤਿਆਂ ਵਿੱਚ ਸੰਖੇਪ ਕਰੋ,
ਸਫਲਤਾ ਦੇ ਮਾਪਦੰਡ ਪੂਰੇ ਹੋਣ ਜਾਂ ਬਜਟ ਮੁੱਕਣ ਉੱਤੇ ਰੁਕੋ; ਹੁਣ ਤੱਕ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਨਤੀਜਾ ਅਤੇ ਬਾਕੀ ਅਨਿਸ਼ਚਿਤਤਾਵਾਂ ਵਾਪਸ ਦਿਓ.
ਇਸ ਦਾ ਮਕਸਦ ਮਾਡਲ ਨੂੰ ਬੇਲੋੜਾ ਵਿਸਤਾਰਪੂਰਨ ਬਣਾਉਣਾ ਨਹੀਂ ਹੈ. ਮਕਸਦ ਸਿਸਟਮ ਨੂੰ ਸਮਝਣਯੋਗ ਬਣਾਉਣਾ ਅਤੇ ਹਰ ਪੜਾਅ ਉੱਤੇ ਉਸ ਦਾ “ਹਕੀਕਤ ਨਾਲ ਸੰਪਰਕ” ਯਕੀਨੀ ਕਰਨਾ ਹੈ. ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਬਹੁਤ ਜਾਣੂ ਉਦਾਹਰਨ CI-ਸ਼ੈਲੀ ਦੀ ਬੰਦ-ਲੂਪ ਗ੍ਰਾਊਂਡਿੰਗ ਹੈ:
ਯੋਜਨਾ: ਤਬਦੀਲੀਆਂ ਦੀ ਸੂਚੀ ਸੁਝਾਓ
ਕਾਰਵਾਈ: ਟੈਸਟ ਜਾਂ ਲਿੰਟ ਚਲਾਓ
ਨਿਰੀਖਣ: ਅਸਫਲਤਾਵਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ
ਅੱਪਡੇਟ: ਪੈਚ ਲਗਾ ਕੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰੋ
ਇਹ ਕੁਝ ਸਵਾਲ ਅਣਜਾਣੇ ਵਿੱਚ ਬਣੇ ਏਜੰਟ ਡਿਜ਼ਾਈਨਾਂ ਦੀਆਂ ਕਮੀਆਂ ਸਾਹਮਣੇ ਲਿਆਉਂਦੇ ਹਨ:
“ਕੀ ਮੇਰਾ ਏਜੰਟ ਚੁਣਦਾ ਹੈ ਕਿ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ, ਜਾਂ ਮੈਂ ਹਮੇਸ਼ਾ ਸਭ ਕੁਝ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹਾਂ?”
ਜੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤੀ ਬਿਨਾਂ ਸ਼ਰਤ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਦੇਰੀ, ਲਾਗਤ, ਸੰਦਰਭ ਦੇ ਪਤਲੇਪਣ ਅਤੇ ਘਟੀਆ ਇਨਪੁੱਟ ਤੋਂ ਘਟੀਆ ਨਤੀਜੇ ਦੇ ਵਧੇਰੇ ਜੋਖਮ ਦੀ ਕੀਮਤ ਚੁਕਾਉਣੀ ਪਵੇਗੀ.
“ਕੀ ਮੇਰਾ ਏਜੰਟ ਪਛਾਣ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਗ਼ਲਤ ਹੈ?”
ਜੇ ਤੁਹਾਡੇ ਏਜੰਟ ਲਈ ਇਕੱਲਾ ਫੀਡਬੈਕ ਸੰਕੇਤ “ਵਰਤੋਂਕਾਰ ਦਾ ਖਿਝ ਜਾਣਾ” ਹੈ, ਤਾਂ ਤੁਸੀਂ ਮਨੁੱਖੀ ਤਕਲੀਫ਼ ਨਾਲ RL ਕਰ ਰਹੇ ਹੋ. ਵੈਲੀਡੇਟਰ-ਅਧਾਰਿਤ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਲੂਪ ਉਸ ਨੂੰ ਹਕੀਕਤ ਦੀ ਜਾਂਚ ਦੇਣ ਦਾ ਸਭ ਤੋਂ ਸਾਫ਼ ਤਰੀਕਾ ਹੈ.
“ਕੀ ਮੇਮੋਰੀ ਵਿੱਚ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਇਹ ਸਮੇਂ ਨਾਲ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ?”
ਜੇ ਤੁਹਾਡੀ “ਯਾਦਦਾਸ਼ਤ” ਸਿਰਫ਼ ਚੈਟ ਇਤਿਹਾਸ ਜੋੜਦੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਅਸਲ ਵਿੱਚ ਤੁਸੀਂ ਲੌਗ ਹੀ ਲਿਖ ਰਹੇ ਹੋ. ਸਰਵੇਖਣ ਵਿੱਚ ਯਾਦਦਾਸ਼ਤ ਦੀ ਪੇਸ਼ਕਾਰੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਇਹ ਸਿਰਫ਼ ਗੱਲਬਾਤ ਦੀ ਲਿਖਤ ਨਹੀਂ, ਸਗੋਂ ਸਮੇਂ ਨਾਲ ਏਜੰਟਾਂ ਵੱਲੋਂ ਨਿਖਾਰਿਆ ਜਾਂਦਾ ਗਤੀਸ਼ੀਲ ਅਤੇ ਵਧਦਾ ਸੰਦਰਭ ਬਣਦੀ ਹੈ.
ਲੌਗ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਵਾਪਰਿਆ ਸੀ, ਜਦਕਿ ਯਾਦਦਾਸ਼ਤ ਦੱਸਦੀ ਹੈ ਕਿ ਅਗਲੀ ਵਾਰ ਕੀ ਕਰਨਾ ਹੈ. ਚੈਟ ਇਤਿਹਾਸ ਗੱਲਬਾਤ ਦੀ ਲਿਖਤ ਹੈ. ਮੇਮੋਰੀ ਇਸ ਬਾਰੇ ਵਿਕਸਤ ਹੁੰਦੀ ਨੀਤੀ ਹੈ ਕਿ ਅੱਗੇ ਲਈ ਕੀ ਸੰਭਾਲਣਾ ਲਾਭਦਾਇਕ ਹੈ.
ਇੱਕ ਵਿਹਾਰਕ ਸ਼ੁਰੂਆਤ ਵਜੋਂ ਛੋਟੀ ਜਿਹੀ “ਸਿੱਖੇ ਸਬਕ” ਸਾਰਣੀ ਬਣਾਓ, ਜਿਸ ਦੀ ਕੁੰਜੀ ਵਿੱਚ ਕਾਰਜ ਦੀ ਕਿਸਮ, ਟੂਲ ਅਤੇ ਅਸਫਲਤਾ ਦਾ ਢੰਗ ਹੋਵੇ, ਤੇ ਮੁੱਲ ਵਿੱਚ ਇਹ ਦਰਜ ਹੋਵੇ ਕਿ ਕੀ ਕਾਰਗਰ ਰਿਹਾ ਅਤੇ ਕਿਸ ਤੋਂ ਬਚਣਾ ਹੈ. ਮਕਸਦ ਇੱਕ ਸੰਪੂਰਨ ਗਿਆਨ ਗ੍ਰਾਫ਼ ਬਣਾਉਣਾ ਨਹੀਂ ਹੈ. ਮਕਸਦ ਲਗਾਤਾਰ ਨਿਖਰਦਾ ਵਿਹਾਰ ਬਣਾਉਣਾ ਹੈ: ਯਾਦਦਾਸ਼ਤ ਅਤੇ ਫੀਡਬੈਕ ਏਜੰਟਾਂ ਨੂੰ “ਸਥਿਤੀ-ਰਹਿਤ ਸਹਾਇਕਾਂ” ਤੋਂ ਸਮੇਂ ਨਾਲ ਬਿਹਤਰ ਹੁੰਦੇ ਸਿਸਟਮਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ.
ਸਮੱਸਿਆ ਉੱਤੇ ਹੋਰ ਏਜੰਟ ਲਾਉਣ ਦਾ ਲਾਲਚ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਅਕਸਰ ਤਾਲਮੇਲ ਦਾ ਵਾਧੂ ਬੋਝ ਕਈ ਗੁਣਾ ਹੋ ਜਾਂਦਾ ਹੈ. “ਘੱਟੋ-ਘੱਟ ਵਿਹਾਰਕ ਟੀਮ” ਦਾ ਇੱਕ ਵਧੀਆ ਤਰੀਕਾ:
ਤਾਲਮੇਲਕਰਤਾ: ਕੰਮ ਵੰਡਦਾ ਅਤੇ ਸੌਂਪਦਾ ਹੈ
ਕਾਰਜਕਰਤਾ: ਟੂਲ ਕਾਲਾਂ ਜਾਂ ਤਬਦੀਲੀਆਂ ਕਰਦਾ ਹੈ
ਆਲੋਚਕ ਜਾਂ ਮੁਲਾਂਕਣਕਰਤਾ: ਸ਼ੁੱਧਤਾ ਅਤੇ ਜੋਖਮ ਜਾਂਚਦਾ ਹੈ
ਯਾਦਦਾਸ਼ਤ ਸੰਭਾਲਕ: ਸਬਕ ਲਿਖਦਾ ਅਤੇ ਚੁਣਦਾ ਹੈ
ਜੇ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ ਕਿ ਹਰ ਏਜੰਟ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਕੀ ਹੈ, ਤਾਂ ਸ਼ਾਇਦ ਤੁਹਾਨੂੰ ਅਜੇ ਕਈ ਏਜੰਟਾਂ ਦੀ ਲੋੜ ਨਹੀਂ.
ਜੇ ਅਸੀਂ ਇਸ ਪੈਰਾਡਾਈਮ ਤਬਦੀਲੀ ਨੂੰ ਸੱਚਮੁੱਚ ਮੰਨਦੇ ਹਾਂ, ਤਾਂ ਸ਼ਾਇਦ ਹਰ ਚੀਜ਼ ਪ੍ਰੌਂਪਟਾਂ ਵਿੱਚ ਭਰਨੀ, ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਅੰਤਿਮ ਨਤੀਜੇ ਮੰਨਣਾ ਅਤੇ ਏਜੰਟਾਂ ਦਾ ਚੈਟਬੌਟਾਂ ਵਾਂਗ ਮੁਲਾਂਕਣ ਕਰਨਾ ਛੱਡ ਦੇਵਾਂਗੇ. ਅਤੇ ਅਸੀਂ ਏਜੰਟਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੇ ਅਸਲ ਰੂਪ ਵਿੱਚ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕਰਾਂਗੇ: ਅਜਿਹੇ ਸਾਫਟਵੇਅਰ ਸਿਸਟਮ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਭਾਸ਼ਾ ਨਿਯੰਤਰਣ ਪੱਧਰ ਹੈ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਲੂਪ ਤੋਂ ਆਉਂਦੀ ਹੈ.
ਇੱਕ ਹੋਰ ਮਾਡਲ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਹੋਰ ਮੁਲਾਂਕਣ ਲੂਪ ਜੋੜੋ. ਸਭ ਕੁਝ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਨੂੰ ਸ਼ਰਤ-ਅਧੀਨ ਬਣਾਓ. ਦਸ ਵੈਲੀਡੇਟਰ ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਜਾਰੀ ਕਰੋ. ਯਾਦਦਾਸ਼ਤ ਨੂੰ ਡੇਟਾਬੇਸ ਨਹੀਂ, ਨੀਤੀਗਤ ਫ਼ੈਸਲਿਆਂ ਵਾਂਗ ਵਰਤੋ. ਅਤੇ ਬਹੁ-ਏਜੰਟ ਪ੍ਰਬੰਧ ਅਪਣਾਉਂਦੇ ਸਮੇਂ ਵੀਹ ਦੀ ਬਜਾਏ ਦੋ ਏਜੰਟਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ. ਇਹ ਨਿਯਮ ਨਹੀਂ, ਸਗੋਂ ਉਹ ਤਰੀਕੇ ਹਨ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਦੀ ਕਸੌਟੀ ਉੱਤੇ ਖਰੇ ਉਤਰੇ ਹਨ.