Most engineering teams still evaluate AI agents the same way they grade math homework. They look at the final output. If

ਜ਼ਿਆਦਾਤਰ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਅਜੇ ਵੀ AI agents ਦਾ ਮੁਲਾਂਕਣ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਕਰਦੀਆਂ ਹਨ ਜਿਸ ਤਰ੍ਹਾਂ ਉਹ ਗਣਿਤ ਦੇ ਹੋਮਵਰਕ ਨੂੰ ਗ੍ਰੇਡ ਕਰਦੇ ਹਨ। ਉਹ ਸਿਰਫ਼ ਅੰਤਿਮ ਆਉਟਪੁੱਟ (output) ਨੂੰ ਦੇਖਦੇ ਹਨ। ਜੇਕਰ ਜਵਾਬ ਸਹੀ ਹੈ, ਤਾਂ ਉਹ ਰਿਲੀਜ਼ ਨੂੰ ਹਰੀ ਝੰਡੀ ਦੇ ਦਿੰਦੇ ਹਨ ਅਤੇ ਅੱਗੇ ਵਧ ਜਾਂਦੇ ਹਨ। ਇਹ ਇੱਕ ਖ਼ਤਰਨਾਕ ਸ਼ਾਰਟਕੱਟ ਹੈ। ਇੱਕ ਸਹੀ ਜਵਾਬ ਇੱਕ ਡੂੰਘੇ ਤੌਰ 'ਤੇ ਖ਼ਰਾਬ ਸਿਸਟਮ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ।

ਅਸਲੀ ਕਹਾਣੀ ਉਸ ਰਸਤੇ ਵਿੱਚ ਹੁੰਦੀ ਹੈ ਜਿਸ ਰਾਹੀਂ agent ਉੱਥੇ ਪਹੁੰਚਿਆ। ਉਸ ਰਸਤੇ ਨੂੰ agent trajectory ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਹਰ tool call, ਹਰ routing decision, ਅਤੇ ਹਰ ਉਹ ਰੁਕਾਵਟ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ agent ਮੁੜ ਵਿਚਾਰ ਕਰਨ ਲਈ ਰੁਕਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ agent ਦੇ ਰਸਤੇ ਵਿੱਚ ਰੱਖੇ 'bread crumbs' (ਨਿਸ਼ਾਨਾਂ) ਵਾਂਗ ਸਮਝ ਸਕਦੇ ਹੋ। ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਮੰਜ਼ਿਲ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਰਸਤੇ ਵਿੱਚ ਖਿੰਡੇ ਹੋਏ ਸਾਰੇ ਚੇਤਾਵਨੀ ਦੇ ਸੰਕੇਤਾਂ ਨੂੰ ਗੁਆ ਦਿੰਦੇ ਹੋ।

ਉਲਝੇ ਹੋਏ ਰਸਤਿਆਂ ਦੀ ਸਮੱਸਿਆ

ਇੱਕ agent ਇੱਕ ਨਸ਼ੇੜੀ ਡਰਾਈਵਰ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦੇ ਹੋਏ ਵੀ ਸਹੀ ਜਵਾਬ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਇਹ ਗਲਤ tools ਰਾਹੀਂ ਭਟਕਦਾ ਹੈ, router ਵੱਲ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਕੁਝ ਸਹੀ ਲੱਭਣ ਤੋਂ ਪਹਿਲਾਂ ਵਾਰ-ਵਾਰ ਇੱਕੋ ਜਿਹੀ ਸੋਚ (reasoning) ਦੇ ਚੱਕਰ ਵਿੱਚ ਫਸਿਆ ਰਹਿੰਦਾ ਹੈ। ਉਪਭੋਗਤਾ (user) ਨੂੰ ਇੱਕ ਸਾਫ਼ ਨਤੀਜਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਪਰ ਪਰਦੇ ਦੇ ਪਿੱਛੇ, ਸਿਸਟਮ ਸਰੋਤਾਂ (resources) ਨੂੰ ਬਰਬਾਦ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਜੋਖਮ ਵਧਾ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।

ਅਸਲ ਵਿੱਚ ਅਭਿਆਸ ਵਿੱਚ ਇਹ ਉਲਝਣ ਕਿਹੋ ਜਿਹੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ?

ਪਹਿਲਾਂ, ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੇ tool call ਦੀ ਸਮੱਸਿਆ ਹੈ। Agent ਤੁਹਾਡੇ customer database ਨੂੰ query ਕਰਦਾ ਹੈ, ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਪੰਜ ਸੈਕੰਡ ਬਾਅਦ ਉਸਨੂੰ ਭੁੱਲ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਉਹੀ ਰਿਕਾਰਡ ਬਿਲਕੁਲ ਉਹੀ parameters ਨਾਲ ਦੁਬਾਰਾ query ਕਰਦਾ ਹੈ। ਇਹ ਡਾਟਾ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ। ਇਹ trajectory ਦੀ ਸਮੱਸਿਆ ਹੈ। Agent state ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ, ਇਸ ਲਈ ਇਹ ਕੰਮ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਹੈ।

ਫਿਰ 'wrong-tool-first' ਪੈਟਰਨ ਹੁੰਦਾ ਹੈ। ਇੱਕ coding agent ਉਸ function definition ਲਈ ਵੈੱਬ 'ਤੇ ਖੋਜ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ local repository ਵਿੱਚ ਮੌਜੂਦ ਹੈ। ਜਾਂ ਇੱਕ support agent billing API ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਉਪਭੋਗਤਾ ਦੇ ਸਵਾਲ ਲਈ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ account settings tool ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਹਰ ਗਲਤ ਚੋਣ tokens ਖ਼ਰਚ ਕਰਦੀ ਹੈ, latency ਵਧਾਉਂਦੀ ਹੈ, ਅਤੇ ਇਸ ਗੱਲ ਦੀ ਸੰਭਾਵਨਾ ਵਧਾਉਂਦੀ ਹੈ ਕਿ ਅਸਲੀ ਕੰਮ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ context limits ਖ਼ਤਮ ਹੋ ਜਾਣ।

Router loops ਇੱਕ ਹੋਰ ਚੇਤਾਵਨੀ ਦਾ ਸੰਕੇਤ (red flag) ਹਨ। Decision node ਫੈਸਲਾ ਨਹੀਂ ਲੈ ਪਾਉਂਦਾ। ਇਹ ਕੰਮ ਨੂੰ branch A ਨੂੰ ਭੇਜਦਾ ਹੈ, ਫਿਰ ਆਪਣਾ ਮਨ ਬਦਲ ਲੈਂਦਾ ਹੈ, ਇਸਨੂੰ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ, branch B ਨੂੰ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਬਿਨਾਂ ਕਿਸੇ ਕਾਰਨ ਇੱਕ general-purpose fallback node ਰਾਹੀਂ ਰੂਟ ਕਰਦਾ ਹੈ। ਹਰ loop ਇੱਕ network hop ਅਤੇ ਅੰਤਿਮ debug log ਵਿੱਚ ਉਲਝਣ ਦੀ ਇੱਕ ਹੋਰ ਪਰਤ ਜੋੜਦਾ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਵਾਰ-ਵਾਰ ਵਿਸ਼ਲੇਸ਼ਣ (repeated analysis) ਹੁੰਦਾ ਹੈ। Agent ਉਸਨੂੰ ਸਥਾਪਿਤ ਮੰਨਣ ਦੀ ਬਜਾਏ ਹਰ ਕਦਮ 'ਤੇ ਉਹੀ ਸਿੱਟਾ ਦੁਬਾਰਾ ਕੱਢਦਾ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਤਰਖਾਣ ਵਾਂਗ ਹੈ ਜੋ ਹਰ ਕਟਾਈ ਤੋਂ ਪਹਿਲਾਂ ਬੋਰਡ ਨੂੰ ਦਸ ਵਾਰ ਮਾਪਦਾ ਹੈ। ਪਹਿਲਾ ਮਾਪ ਸਹੀ ਸੀ। ਅਗਲੇ ਨੌਂ ਮਾਪ ਬੇਕਾਰ ਦੀ ਹਲਚਲ ਹਨ।

ਇਹ ਵਾਧੂ ਕਦਮ ਅਸਲ ਨਤੀਜੇ ਲਿਆਉਂਦੇ ਹਨ। Latency ਵਧਦੀ ਜਾਂਦੀ ਹੈ। ਇੱਕ synchronous chat interface ਵਿੱਚ, ਤਿੰਨ ਵਾਧੂ ਸੈਕੰਡ ਇੱਕ ਜੀਵਨ ਵਾਂਗ ਲੱਗਦੇ ਹਨ। ਵੱਡੇ ਪੱਧਰ 'ਤੇ, ਉਹ ਸੈਕੰਡ compute 'ਤੇ ਹਜ਼ਾਰਾਂ ਡਾਲਰਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਅਸਫਲਤਾ ਦਾ ਜੋਖਮ ਵੀ ਵਧਦਾ ਹੈ। ਹਰ ਬੇਲੋੜਾ hop ਇੱਕ ਬਾਹਰੀ API ਦੇ time out ਹੋਣ, context window ਦੇ overflow ਹੋਣ, ਜਾਂ race condition ਦੇ ਸਾਹਮਣੇ ਆਉਣ ਦਾ ਇੱਕ ਹੋਰ ਮੌਕਾ ਹੈ। ਅਤੇ ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਤਾਂ ਉਸ trace ਨੂੰ debug ਕਰਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ ਜੋ ਸਪੈਗੇਟੀ (spaghetti) ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਇਹ ਸਮਝਣ ਲਈ ਘੰਟਿਆਂ ਬਿਤਾਓਗੇ ਕਿ agent ਨੇ ਸੱਤਵਾਂ ਕਦਮ ਕਿਉਂ ਚੁੱਕਿਆ, ਪਰ ਅੰਤ ਵਿੱਚ ਤੁਹਾਨੂੰ ਅਹਿਸਾਸ ਹੋਵੇਗਾ ਕਿ ਸੱਤਵਾਂ ਕਦਮ ਕਦੇ ਹੋਣਾ ਹੀ ਨਹੀਂ ਚਾਹੀਦਾ ਸੀ।

Convergence ਦਾ ਅਸਲ ਮਤਲਬ ਕੀ ਹੈ

ਜੇਕਰ trajectory ਰਸਤਾ ਹੈ, ਤਾਂ convergence ਉਸਦੀ ਕੁਸ਼ਲਤਾ (efficiency) ਦਾ ਮਾਪ ਹੈ। Convergence ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ agent ਉਪਭੋਗਤਾ ਦੀ ਬੇਨਤੀ ਅਤੇ ਸਹੀ ਹੱਲ ਦੇ ਵਿਚਕਾਰ ਸਭ ਤੋਂ ਛੋਟੇ ਵਿਹਾਰਜਨਕ ਰਸਤੇ (shortest viable route) ਨਾਲ ਕਿੰਨੀ ਨੇੜਤਾ ਨਾਲ ਚੱਲਦਾ ਹੈ।

ਇਹ accuracy ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ। Accuracy ਇੱਕ ਸਧਾਰਨ ਸਾਧਨ ਹੈ। ਇਹ ਪੁੱਛਦੀ ਹੈ ਕਿ ਕੀ ਅੰਤਿਮ ਸਥਿਤੀ ਸਹੀ ਹੈ। Convergence ਪੁੱਛਦੀ ਹੈ ਕਿ ਕੀ ਯਾਤਰਾ ਤਰਕਸੰਗਤ ਸੀ। ਉੱਚ accuracy ਅਤੇ ਘੱਟ convergence ਵਾਲਾ agent ਸਫਲਤਾ ਦੇ ਭੇਸ ਵਿੱਚ ਇੱਕ ਦੇਣਦਾਰੀ (liability) ਹੈ। ਉੱਚ convergence ਅਤੇ ਦਰਮਿਆਨੀ accuracy ਵਾਲਾ agent ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਸਦੀ reasoning ਸਾਫ਼ ਹੁੰਦੀ ਹੈ ਅਤੇ ਇਸਦੀਆਂ ਗਲਤੀਆਂ ਸੀਮਤ (localized) ਹੁੰਦੀਆਂ ਹਨ।

ਤੁਸੀਂ ਉਸ task class ਲਈ ਤੁਹਾਡੇ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਸਭ ਤੋਂ ਛੋਟੇ ਰਸਤੇ ਦੇ ਮੁਕਾਬਲੇ agent ਦੁਆਰਾ ਅਸਲ ਵਿੱਚ ਲਏ ਗਏ ਕਦਮਾਂ ਦੀ ਤੁਲਨਾ ਕਰਕੇ ਇੱਕ ਅੰਦਾਜ਼ਨ convergence score ਦੀ ਗਣਨਾ ਕਰ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਇੱਕ standard refund query ਲਈ ਬਿਲਕੁਲ ਤਿੰਨ tool calls ਦੀ ਲੋੜ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ agent ਨੇ ਨੌਂ ਵਰਤੇ ਹਨ, ਤਾਂ ਤੁਹਾਡਾ convergence ratio ਘਟ ਰਿਹਾ ਹੈ। ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੀ ਬਰਬਾਦੀ ਨੂੰ ਭਾਰ (weighting) ਦੇ ਕੇ ਇਸਨੂੰ ਹੋਰ ਬਿਹਤਰ ਬਣਾ ਸਕਦੇ ਹੋ। ਇੱਕ ਗਲਤ tool call ਦੀ ਕੀਮਤ ਇੱਕ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੇ call ਨਾਲੋਂ ਵੱਧ ਹੋ ਸਕਦੀ ਹੈ, ਜੋ tool ਦੀ latency ਅਤੇ ਕੀਮਤ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਇੱਕ router loop ਜੋ ਕੋਈ ਮੁੱਲ ਨਹੀਂ ਜੋੜਦਾ, ਸਭ ਤੋਂ ਭਾਰੀ ਜੁਰਮਾਨਾ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ architectural