ai-agents-for-beginners

AI ਏਜੰਟਸ ਇਨ ਪ੍ਰੋਡਕਸ਼ਨ: ਨਿਰੀਖਣਯੋਗਤਾ ਅਤੇ ਮੁਲਾਂਕਣ

ਉਤਪਾਦਨ ਵਿੱਚ ਏਆਈ ਏਜੰਟ

ਜਿਵੇਂ ਜੇ ਐਆਈ ਏਜੰਟ ਪ੍ਰਯੋਗਾਤਮਕ ਪ੍ਰੋਟੋਟਾਈਪਾਂ ਤੋਂ ਅਸਲ-ਦੁਨੀਆ ਦੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵੱਲ ਵਧਦੇ ਹਨ, ਉਹਨਾਂ ਦੇ ਵਿਹਾਰ ਨੂੰ ਸਮਝਣ, ਉਨ੍ਹਾਂ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਦੇ ਆਉਟਪੁੱਟਾਂ ਦਾ ਵਿਧੀਗਤ ਤੌਰ ‘ਤੇ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੀ ਹੈ।

ਲਰਨਿੰਗ ਲਕ਼ਸ਼

ਇਸ ਪਾਠ ਨੂੰ ਪੂਰਾ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਜਾਣੋੋਗੇ/ਸਮਝੋਗੇ:

ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇਹ ਗਿਆਨ ਦਿੱਤਾ ਜਾਵੇ ਤਾਂ ਜੋ ਤੁਸੀਂ ਆਪਣੇ “ਬਲੈਕ ਬਾਕਸ” ਏਜੰਟਾਂ ਨੂੰ ਪਾਰਦਰਸ਼ੀ, ਪ੍ਰਬੰਧਨਯੋਗ, ਅਤੇ ਭਰੋਸੇਯੋਗ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਬਦਲ ਸਕੋ।

Note: ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਏਆਈ ਏਜੰਟ ਸੁਰੱਖਿਅਤ ਅਤੇ ਭਰੋਸੇਯੋਗ ਹੋਣ। ਇਸਦੇ ਲਈ Building Trustworthy AI Agents ਪਾਠ ਨੂੰ ਵੀ ਦੇਖੋ।

ਟਰੇਸ ਅਤੇ ਸਪੈਨ

ਨਿਰੀਖਣਯੋਗਤਾ ਟੂਲਾਂ ਜਿਵੇਂ Langfuse ਜਾਂ Microsoft Foundry ਆਮਤੌਰ ‘ਤੇ ਏਜੰਟ ਰਨਜ਼ ਨੂੰ ਟਰੇਸ ਅਤੇ ਸਪੈਨ ਵਜੋਂ ਦਰਸਾਉਂਦੇ ਹਨ।

Langfuse ਵਿੱਚ ਟਰੇਸ ਟਰੀ

ਨਿਰੀਖਣਯੋਗਤਾ ਤੋਂ ਬਿਨਾਂ, ਇੱਕ ਏਆਈ ਏਜੰਟ “ਬਲੈਕ ਬਾਕਸ” ਵਰਗਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ — ਇਸਦੀ ਅੰਦਰੂਨੀ ਸਥਿਤੀ ਅਤੇ ਤਰਕ opaque ਹੁੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦੀ ਨਿਦਾਨੀ ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਅਦਲ-ਬਦਲ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਨਿਰੀਖਣਯੋਗਤਾ ਨਾਲ, ਏਜੰਟ “ਪਾਰਦਰਸ਼ੀ ਡੱਬੀਆਂ” ਬਣ ਜਾਂਦੇ ਹਨ, ਜੋ ਭਰੋਸਾ ਬਣਾਉਣ ਅਤੇ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਅਹੰਕਾਰਪੂਰਕ ਪਾਰਦਰਸ਼ਤਾ ਦਿੰਦੇ ਹਨ ਕਿ ਉਹ ਉਦੇਸ਼ ਅਨੁਸਾਰ ਕੰਮ ਕਰ ਰਹੇ ਹਨ।

ਉਤਪਾਦਨ ਵਾਤਾਵਰਨਾਂ ਵਿੱਚ ਨਿਰੀਖਣਯੋਗਤਾ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਏਆਈ ਏਜੰਟਾਂ ਨੂੰ ਉਤਪਾਦਨ ਵਾਤਾਵਰਨਾਂ ਵਿੱਚ ਲਿਜਾਣਾ ਨਵੇਂ ਚੁਣੌਤੀਆਂ ਅਤੇ ਲੋੜਾਂ ਲਿਆਉਂਦਾ ਹੈ। ਨਿਰੀਖਣਯੋਗਤਾ ਹੁਣ “ਵਧੀਆ-ਹੋਣਾ” ਨਹੀਂ ਰਹਿ, ਬਲਕੀ ਇੱਕ ਅਹੰਕਾਰਪੂਰਕ ਸਮਰੱਥਾ ਬਣ ਗਈ ਹੈ:

ਟਰੈਕ ਕਰਨ ਯੋਗ ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ

ਏਜੰਟ ਵਿਹਾਰ ਦੀ ਨਿਗਰਾਨੀ ਅਤੇ ਸਮਝ ਲਈ, ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਸਿਗਨਲ ਟ੍ਰੈਕ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਜਦ ਕਿ ਵਿਸ਼ੇਸ਼ ਮੈਟ੍ਰਿਕਸ ਏਜੰਟ ਦੇ ਉਦੇਸ਼ ਤੇ ਨਿਰਭਰ ਕਰ ਸਕਦੇ ਹਨ, ਕੁਝ ਆਮ ਤੌਰ ‘ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ।

ਇਹاں ਕੁਝ ਸਭ ਤੋਂ ਆਮ ਮੈਟ੍ਰਿਕਸ ਦਿੱਤੇ ਗਏ ਹਨ ਜੋ ਨਿਰੀਖਣਯੋਗਤਾ ਟੂਲਾਂ ਵਲੋਂ ਨਿਗਰਾਨੀ ਕੀਤੇ ਜਾਂਦੇ ਹਨ:

ਲੇਟੈਂਸੀ: ਏਜੰਟ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ? ਲੰਬੇ ਇੰਤਜ਼ਾਰ ਦੇ ਸਮੇਂ ਯੂਜ਼ਰ ਅਨੁਭਵ ‘ਤੇ ਨਕਾਰਾਤਮਕ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ। ਤੁਸੀਂ ਟਰੇਸ ਕਰਕੇ ਟਾਸਕਾਂ ਅਤੇ ਵਿਅਕਤੀਗਤ ਕਦਮਾਂ ਦੀ ਲੇਟੈਂਸੀ ਮਾਪੋ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਐਜੰਟ ਜੋ ਸਾਰੀਆਂ ਮਾਡਲ ਕਾਲਾਂ ਲਈ 20 ਸਕਿੰਟ ਲੈਂਦਾ ਹੈ ਉਸ ਨੂੰ ਤੇਜ਼ ਮਾਡਲ ਵਰਤਕੇ ਜਾਂ ਮਾਡਲ ਕਾਲਾਂ ਨੂੰ ਸਮਾਂਤਰ ਚਲਾਕੇ ਤੇਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਲਾਗਤਾਂ: ਹਰ ਏਜੰਟ ਰਨ ਦੀ ਲਾਗਤ ਕੀ ਹੈ? ਏਆਈ ਏਜੰਟ LLM ਕਾਲਾਂ ਜਾਂ ਬਾਹਰੀ APIs ‘ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਜੋ ਟੋਕਨ ਜਾਂ ਕਾਲ ਦੇ ਅਨੁਸਾਰ ਬਿੱਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਅਕਸਰ ਟੂਲਾਂ ਦੀ ਵਰਤੋਂ ਜਾਂ ਕਈ ਪ੍ਰਾਂਪਟ ਲਾਗਤਾਂ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਵਾਧਾ ਕਰ ਸਕਦੇ ਹਨ। ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ ਇੱਕ ਏਜੰਟ ਮਾਰਜਿਨਲ ਗੁਣਵੱਤਾ ਸੁਧਾਰ ਲਈ LLM ਨੂੰ ਪੰਜ ਵਾਰ ਕਾਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਚੇਤਣਾ ਕੀਤੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਕੀ ਇਹ ਲਾਗਤ ਵਾਜਿਬ ਹੈ ਜਾਂ ਕੀ ਤੁਸੀਂ ਕਾਲਾਂ ਦੀ ਗਿਣਤੀ ਘਟਾ ਕੇ ਜਾਂ ਸਸਤੇ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਗਤ ਘਟਾ ਸਕਦੇ ਹੋ। ਰੀਅਲ-ਟਾਈਮ ਨਿਰੀਖਣ ਅਚਾਨਕ ਉਥਲੇ ਵਾਧਿਆਂ (ਉਦਾਹਰਨ ਲਈ, ਬੱਗ ਕਾਰਨ ਬੇਹੱਦ API ਲੂਪ) ਦੀ ਪਛਾਣ ਵਿਚ ਵੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।

ਰਿਕuest ਐਰਰਸ: ਕਿੰਨੀਆਂ ਰਿਕਵੇਸਟਾਂ ਫੇਲ ਹੋਈਆਂ? ਇਹ ਵਿੱਚ API ਐਰਰ ਜਾਂ ਫੇਲ ਹੋਈ ਟੂਲ ਕਾਲਾਂ ਸ਼ਾਮਿਲ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਉਤਪਾਦਨ ਵਿੱਚ ਆਪਣੇ ਏਜੰਟ ਨੂੰ ਇਨ੍ਹਾਂ ਤਰ੍ਹਾਂ ਦੀਆਂ ਸ਼ਰਤਾਂ ਦੇ ਖਿਲਾਫ ਜ਼ਿਆਦਾ ਮਜ਼ਬੂਤ ਬਣਾਉਣ ਲਈ, ਤੁਸੀਂ ਫੌਲਬੈਕ ਜਾਂ ਰੀਟਰਾਈ ਸੈਟਅੱਪ ਕਰ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, ਜੇ LLM ਪ੍ਰਦਾਤਾ A ਡਾਊਨ ਹੋ ਜਾਵੇ, ਤਾਂ ਤੁਸੀਂ ਬੈਕਅੱਪ ਵਜੋਂ LLM ਪ੍ਰਦਾਤਾ B ‘ਤੇ ਸਵਿੱਚ ਕਰ ਸਕਦੇ ਹੋ।

ਯੂਜ਼ਰ ਫੀਡਬੈਕ: ਸਿੱਧੀ ਯੂਜ਼ਰ ਮੂਲਾਂਕਣ ਲਾਗੂ ਕਰਨ ਨਾਲ ਕੀਮਤੀ ਜਾਣਕਾਰੀਆਂ ਮਿਲਦੀਆਂ ਹਨ। ਇਹ ਸਪੱਸ਼ਟ ਰੇਟਿੰਗਾਂ (👍thumbs-up/👎down, ⭐1-5 ਸਿਤਾਰੇ) ਜਾਂ ਲਿਖਤੀ ਟਿੱਪਣੀਆਂ ਸ਼ਾਮਿਲ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਲਗਾਤਾਰ ਨਕਾਰਾਤਮਕ ਫੀਡਬੈਕ ਤੁਹਾਨੂੰ ਸਚੇਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇਸ਼ਾਰਾ ਹੈ ਕਿ ਏਜੰਟ ਉਮੀਦ ਅਨੁਸਾਰ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ।

ਅਪਰੋਕਸ਼ ਯੂਜ਼ਰ ਫੀਡਬੈਕ: ਯੂਜ਼ਰ ਦੇ ਵਰਤਾਰਿਆਂ ਤੋਂ ਬਿਨਾਂ ਸਪੱਸ਼ਟ ਰੇਟਿੰਗਾਂ ਦੇ ਵੀ ਅਪਰੋਕਸ਼ ਫੀਡਬੈਕ ਮਿਲਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਤੁਰੰਤ ਪ੍ਰਸ਼ਨ ਨੂੰ ਮੁੜ-ਵਿਆਖਿਆ ਕਰਨਾ, ਦੁਹਰਾਏ ਗਏ ਪ੍ਰਸ਼ਨ ਜਾਂ ਰੀਟ੍ਰਾਈ ਬਟਨ ‘ਤੇ ਕਲਿੱਕ ਕਰਨਾ ਸ਼ਾਮਿਲ ਹੋ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਕਿ ਯੂਜ਼ਰ ਇੱਕੋ ਹੀ ਪ੍ਰਸ਼ਨ ਬਾਰ-ਬਾਰ ਪੁੱਛਦੇ ਹਨ, ਤਾਂ ਇਹ ਇੱਕ ਨਿਸ਼ਾਨ ਹੈ ਕਿ ਏਜੰਟ ਉਮੀਦ ਅਨੁਸਾਰ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ।

ਸਹੀਤਾ (Accuracy): ਏਜੰਟ ਕਿੰਨੀ ਵਾਰ ਸਹੀ ਜਾਂ ਚਾਹੁਣੇ ਆਉਟਪੁੱਟ ਦਿੰਦਾ ਹੈ? ਸਹੀਤਾ ਦੀ ਪਰਿਭਾਸ਼ਾ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਸਮੱਸਿਆ-ਸੁਲਝਾਉਣ ਦੀ ਸਹੀਤਾ, ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤੀ ਦੀ ਸਹੀਤਾ, ਯੂਜ਼ਰ ਸੱਖਤੀਜੇ). ਪਹਿਲਾ ਕਦਮ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਏਜੰਟ ਲਈ ਸਫਲਤਾ ਕਿਸ ਤਰ੍ਹਾਂ ਦਿੱਖਦੀ ਹੈ। ਤੁਸੀਂ ਆਟੋਮੇਟਿਕ ਚੈੱਕਾਂ, ਮੁਲਾਂਕਣ ਸਕੋਰਨਾਂ ਜਾਂ ਟਾਸਕ ਪੂਰੇ ਹੋਣ ਦੇ ਲੇਬਲਾਂ ਰਾਹੀਂ ਸਹੀਤਾ ਟ੍ਰੈਕ ਕਰ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਵਜੋਂ, ਟਰੇਸਾਂ ਨੂੰ “ਸਫਲ” ਜਾਂ “ਫੇਲ” ਵਜੋਂ ਮਾਰਕ ਕਰਨਾ।

ਆਟੋਮੇਟਡ ਮੁਲਾਂਕਣ ਮੈਟ੍ਰਿਕਸ: ਤੁਸੀਂ ਆਟੋਮੇਟਿਕ ਇਵਲਸ ਵੀ ਸੈਟਅੱਪ ਕਰ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਇੱਕ LLM ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਏਜੰਟ ਦੇ ਆਉਟਪੁੱਟ ਨੂੰ ਸਕੋਰ ਕਰਵਾ ਸਕਦੇ ਹੋ — ਜਿਵੇਂ ਕਿ ਉਹ ਮਦਦਗਾਰ, ਸਹੀ, ਜਾਂ ਨਹੀਂ ਹੈ। ਕਈ ਖੁੱਲੇ ਸੋਰਸ 라이ਬ੍ਰੇਰੀਆਂ ਵੀ ਮੌਜੂਦ ਹਨ ਜੋ ਏਜੰਟ ਦੇ ਵੱਖ-ਵੱਖ ਪਹਿਲੂਆਂ ਨੂੰ ਸਕੋਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਵਜੋਂ, RAG ਏਜੰਟਾਂ ਲਈ RAGAS ਜਾਂ ਨੁਕਸਾਨਦੇਹ ਭਾਸ਼ਾ ਜਾਂ ਪ੍ਰਾਂਪਟ ਇੰਜੈਕਸ਼ਨ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ LLM Guard

ਅਸਲ ਅਮਲ ਵਿੱਚ, ਇਹਨਾਂ ਮੈਟ੍ਰਿਕਸ ਦਾ ਸੰਗਮ ਏਕ ਏਆਈ ਏਜੰਟ ਦੀ ਸਿਹਤ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਕਵਰੇਜ ਦਿੰਦਾ ਹੈ। ਇਸ ਅਧਿਆਇ ਦੇ example notebook ਵਿੱਚ ਅਸੀਂ ਤੁਹਾਨੂੰ ਦਿਖਾਵਾਂਗੇ ਕਿ ਇਹ ਮੈਟ੍ਰਿਕਸ ਅਸਲ ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ ਪਰ ਪਹਿਲਾਂ, ਅਸੀਂ ਸਿੱਖਾਂਗੇ ਕਿ ਆਮ ਤੌਰ ‘ਤੇ ਇੱਕ ਮੁਲਾਂਕਣ ਵਰਕਫਲੋ কਿਵੇਂ ਹੁੰਦਾ ਹੈ।

ਆਪਣੇ ਏਜੰਟ ਨੂੰ ਇੰਸਟਰੂਮੈਂਟ ਕਰੋ

ਟਰੇਸਿੰਗ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਆਪਣੇ ਕੋਡ ਨੂੰ ਇੰਸਟਰੂਮੈਂਟ کرنا ਪਏਗਾ। ਲਕ਼ਸ਼ ਇਹ ਹੈ ਕਿ ਏਜੰਟ ਕੋਡ ਨੂੰ ਇੰਸਟਰੂਮੈਂਟ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਜੋ ਉਹ ਟਰੇਸ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਜਾਰੀ ਕਰ ਸਕੇ ਜੋ ਕਿਸੇ ਨਿਰੀਖਣਯੋਗਤਾ ਪਲੇਟਫਾਰਮ ਦੁਆਰਾ ਕੈਪਚਰ, ਪ੍ਰੋਸੈਸ ਅਤੇ ਵਿਜ਼ੁਅਲਾਈਜ਼ ਕੀਤੇ ਜਾ ਸਕਣ।

OpenTelemetry (OTel): OpenTelemetry LLM ਨਿਰੀਖਣਯੋਗਤਾ ਲਈ ਇੱਕ ਉਦਯੋਗ ਮਿਆਰ ਵਜੋਂ ਉਭਰਿਆ ਹੈ। ਇਹ ਟੈਲੀਮੇਟਰੀ ਡੇਟਾ ਜਨਰੇਟ, ਇਕੱਠਾ ਅਤੇ ਐਕਸਪੋਰਟ ਕਰਨ ਲਈ APIs, SDKs, ਅਤੇ ਟੂਲਾਂ ਦਾ ਸੈੱਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਕਈ ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਲਾਇਬ੍ਰੇਰੀਆਂ ਮੌਜੂਦ ਹਨ ਜੋ ਮੌਜੂਦਾ ਏਜੰਟ ਫਰੇਮਵਰਕਾਂ ਨੂੰ ਰੈਪ ਕਰਦੀਆਂ ਹਨ ਅਤੇ OpenTelemetry ਸਪੈਨਾਂ ਨੂੰ ਨਿਰੀਖਣਯੋਗਤਾ ਟੂਲ ਵੱਲ ਐਕਸਪੋਰਟ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ। Microsoft Agent Framework OpenTelemetry ਨਾਲ ਨੈਟਿਵ ਤੌਰ ‘ਤੇ ਇੰਟਿਗ੍ਰੇਟ ਹੁੰਦਾ ਹੈ। ਹੇਠਾਂ ਇੱਕ MAF ਏਜੰਟ ਨੂੰ ਇੰਸਟਰੂਮੈਂਟ ਕਰਨ ਦਾ ਉਦਾਹਰਨ ਦਿੱਤਾ ਗਿਆ ਹੈ:

from agent_framework.observability import get_tracer, get_meter

tracer = get_tracer()
meter = get_meter()

with tracer.start_as_current_span("agent_run"):
    # ਏਜੰਟ ਦੀ ਕਾਰਵਾਈ ਆਪਣੇ ਆਪ ਟਰੇਸ ਕੀਤੀ ਜਾਂਦੀ ਹੈ
    pass

ਇਸ ਅਧਿਆਇ ਵਿੱਚ ਦਿੱਤਾ example notebook ਤੁਹਾਨੂੰ ਦਿਖਾਏਗਾ ਕਿ ਆਪਣਾ MAF ਏਜੰਟ ਕਿਵੇਂ ਇੰਸਟਰੂਮੈਂਟ ਕਰਨਾ ਹੈ।

ਮੈਨੂਅਲ ਸਪੈਨ ਬਣਾਉਣਾ: ਜਦ ਕਿ ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਲਾਇਬ੍ਰੇਰੀਆਂ ਇੱਕ ਚੰਗਾ ਬੇਸਲਾਈਨ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ, ਅਕਸਰ ਉਨ੍ਹਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਹੋਰ ਵਿਸਤ੍ਰਿਤ ਜਾਂ ਕਸਟਮ ਜਾਣਕਾਰੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਮੈਨੂਅਲ ਤੌਰ ‘ਤੇ ਸਪੈਨ ਬਣਾਕੇ ਕਸਟਮ ਐਪਲੀਕੇਸ਼ਨ ਲੋਜਿਕ ਸ਼ਾਮਿਲ ਕਰ ਸਕਦੇ ਹੋ। ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਤੁਸੀਂ ਆਟੋਮੈਟਿਕ ਜਾਂ ਮੈਨੂਅਲ ਬਣਾਏ ਸਪੈਨਾਂ ਨੂੰ ਕਸਟਮ ਐਟ੍ਰਿਬਿਊਟਸ (ਜਿਨ੍ਹਾਂ ਨੂੰ ਟੈਗ ਜਾਂ ਮੈਟਾਡੇਟਾ ਵੀ ਕਹਿੰਦੇ ਹਨ) ਨਾਲ ਸੁਧਾਰ ਸਕਦੇ ਹੋ। ਇਹ ਐਟ੍ਰਿਬਿਊਟਸ ਬਿਜ਼ਨਸ-ਨਿਰਧਾਰਿਤ ਡੇਟਾ, ਮੱਧਵਰਤੀ ਗਣਨਾਵਾਂ, ਜਾਂ ਕੋਈ ਵੀ ਸੰਦਰਭ ਸ਼ਾਮਿਲ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਡੇਬੱਗਿੰਗ ਜਾਂ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਉਪਯੋਗੀ ਹੋ ਸਕਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ user_id, session_id, or model_version.

Langfuse Python SDK ਦੇ ਨਾਲ ਮੈਨੂਅਲ ਤੌਰ ‘ਤੇ ਟਰੇਸ ਅਤੇ ਸਪੈਨ ਬਣਾਉਣ ਦਾ ਉਦਾਹਰਨ:

from langfuse import get_client
 
langfuse = get_client()
 
span = langfuse.start_span(name="my-span")
 
span.end()

ਏਜੰਟ ਮੁਲਾਂਕਣ

ਨਿਰੀਖਣਯੋਗਤਾ ਸਾਨੂੰ ਮੈਟ੍ਰਿਕਸ ਦਿੰਦਾ ਹੈ, ਪਰ ਮੁਲਾਂਕਣ ਉਹ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜਿਸ ਵਿੱਚ ਉਸ ਡੇਟਾ (ਅਤੇ ਟੈਸਟਾਂ) ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾ ਕਿ ਇਹ ਪਤਾ ਲੱਗ ਸਕੇ ਕਿ ਏਆਈ ਏਜੰਟ ਕਿੰਨਾ ਚੰਗਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਕਿਵੇਂ ਸੁਧਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਉਹ ਟਰੇਸ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਹੁੰਦੇ ਹਨ, ਤੁਸੀਂ ਉਹਨਾ ਨੂੰ ਏਜੰਟ ਦਾ ਮੂਲਾਂਕਣ ਕਰਨ ਅਤੇ ਫੈਸਲੇ ਲੈਣ ਲਈ ਕਿਵੇਂ ਵਰਤੋਗੇ?

ਨਿਯਮਤ ਮੁਲਾਂਕਣ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਏਆਈ ਏਜੰਟ ਅਕਸਰ ਗੈਰ-ਨਿਰਧਾਰਤਤਮਕ ਹੁੰਦੇ ਹਨ ਅਤੇ ਵਿਕਸਤ ਹੋ ਸਕਦੇ ਹਨ (ਅਪਡੇਟਾਂ ਜਾਂ ਮਾਡਲ ਵਿਵਹਾਰ ਦੇ ਡ੍ਰਿਫਟ ਹੋਣ ਰਾਹੀਂ) – ਬਿਨਾਂ ਮੁਲਾਂਕਣ ਦੇ, ਤੁਸੀਂ ਨਹੀਂ ਜਾਣ ਸਕੋਗੇ ਕਿ ਤੁਹਾਡਾ “ਸਮਾਰਟ ਏਜੰਟ” ਦਰਅਸਲ ਆਪਣਾ ਕੰਮ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਇਸ ਵਿੱਚ ਕੋਈ ਪਿੱਛੇਹਟ ਹੋਈ ਹੈ।

ਏਆਈ ਏਜੰਟਾਂ ਲਈ ਮੁਲਾਂਕਣ ਦੇ ਦੋ ਵਰਗ ਹਨ: ਆਨਲਾਈਨ ਮੁਲਾਂਕਣ ਅਤੇ ਆਫਲਾਈਨ ਮੁਲਾਂਕਣ। ਦੋਹਾਂ ਦੀਆਂ ਆਪਣੀਆਂ ਕੀਮਤਾਂ ਹਨ ਅਤੇ ਉਹ ਇੱਕ ਦੂਜੇ ਦੀ ਪੂਰਤੀ ਕਰਦੇ ਹਨ। ਅਸੀਂ ਆਮ ਤੌਰ ‘ਤੇ ਆਫਲਾਈਨ ਮੁਲਾਂਕਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਇਹ ਕਿਸੇ ਵੀ ਏਜੰਟ ਨੂੰ ਡਿਪਲੌਇ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਘੱਟੋ-ਘੱਟ ਲੋੜੀਂਦਾ ਕਦਮ ਹੈ।

ਆਫਲਾਈਨ ਮੁਲਾਂਕਣ

Langfuse ਵਿੱਚ ਡੇਟਾਸੈਟ ਆਈਟਮ

ਇਸ ਵਿੱਚ ਏਜੰਟ ਨੂੰ ਇੱਕ ਨਿਯੰਤ੍ਰਿਤ ਸੈਟਿੰਗ ਵਿੱਚ ਮੁਲਾਂਕਣ ਕਰਨਾ ਸ਼ਾਮਿਲ ਹੈ, ਆਮ ਤੌਰ ‘ਤੇ ਟੈਸਟ ਡੇਟਾਸੈਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਨਾ ਕਿ ਲਾਈਵ ਯੂਜ਼ਰ ਪੁੱਛਤਾਛਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ। ਤੁਸੀਂ ਸੰਭਾਲੇ ਗਏ ਡੇਟਾਸੈਟ ਵਰਤਦੇ ਹੋ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਉਮੀਦ ਕੀਤੀ ਆਉਟਪੁੱਟ ਜਾਂ ਸਹੀ ਵਿਹਾਰ ਕੀ ਹੈ, ਅਤੇ ਫਿਰ ਆਪਣੇ ਏਜੰਟ ਨੂੰ ਉਹਨਾਂ ’ਤੇ ਚਲਾਉਂਦੇ ਹੋ।

ਉਦਾਹਰਨ ਲਈ, ਜੇ ਤੁਸੀਂ ਇੱਕ ਗਣਿਤ ਸ਼ਬਦ-ਸਮੱਸਿਆ ਏਜੰਟ ਬਣਾਇਆ ਹੈ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ 100 ਸਮੱਸਿਆਵਾਂ ਵਾਲਾ test dataset ਹੋਵੇ ਜਿਸ ਦੇ ਜਾਣੇ-ਪਛਾਣੇ ਜਵਾਬ ਹਨ। ਆਫਲਾਈਨ ਮੁਲਾਂਕਣ ਅਕਸਰ ਵਿਕਾਸ ਦੌਰਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਅਤੇ CI/CD ਪਾਈਪਲਾਈਨਾਂ ਦਾ ਹਿੱਸਾ ਹੋ ਸਕਦਾ ਹੈ) ਤਾਂ ਕਿ ਸੁਧਾਰ ਜਾਂ ਰਿਗ੍ਰੈਸ਼ਨ ਤੋਂ ਬਚਾਅ ਚੈੱਕ ਕੀਤਾ ਜਾ ਸਕੇ। ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਇਹ ਦੋਹਰਯੋਗ ਹੈ ਅਤੇ ਤੁਸੀਂ ਸਪਸ਼ਟ ਸਹੀਤਾ ਮੈਟ੍ਰਿਕਸ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕੋਲ ਗ੍ਰਾਉਂਡ-ਟ੍ਰੂਥ ਹੈ। ਤੁਸੀਂ ਯੂਜ਼ਰ ਪੁੱਛਤਾਛਾਂ ਦੀ ਨਕਲ ਵੀ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਏਜੰਟ ਦੇ ਜਵਾਬਾਂ ਨੂੰ ਆਦਰਸ਼ ਜਵਾਬਾਂ ਦੇ ਖਿਲਾਫ ਮਾਪ ਸਕਦੇ ਹੋ ਜਾਂ ਉਪਰੋਕਤ ਆਟੋਮੇਟਡ ਮੈਟ੍ਰਿਕਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।

ਆਫਲਾਈਨ ਇਵਲ ਦਾ ਮੁੱਖ ਚੁਣੌਤੀ ਇਹ ਹੈ ਕਿ ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰਨਾ ਕਿ ਤੁਹਾਡਾ ਟੈਸਟ ਡੇਟਾਸੈਟ ਵਿਸ਼ਤ੍ਰਿਤ ਹੈ ਅਤੇ ਸਬੰਧਤ ਰਹਿੰਦਾ ਹੈ – ਏਜੰਟ ਇੱਕ ਨਿਸ਼ਚਿਤ ਟੈਸਟ ਸੈਟ ‘ਤੇ ਚੰਗਾ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਉਤਪਾਦਨ ਵਿੱਚ ਬਹੁਤ ਵੱਖ-ਵੱਖ ਪ੍ਰਸ਼ਨਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ, ਤੁਹਾਨੂੰ ਟੈਸਟ ਸੈਟਾਂ ਨੂੰ ਨਵੇਂ ਐਜ-ਕੇਸਾਂ ਅਤੇ ਅਸਲ-ਦੁਨੀਆ ਦੇ ਉਦਾਹਰਨਾਂ ਨਾਲ ਅਪਡੇਟ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਛੋਟੇ “ਸਮੋਕ ਟੈਸਟ” ਕੇਸਾਂ ਅਤੇ ਵੱਡੇ ਮੁਲਾਂਕਣ ਸੈੱਟਾਂ ਦਾ ਮਿਕਸ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ: ਛੋਟੇ ਸੈੱਟ ਤੁਰੰਤ ਜਾਂਚਾਂ ਲਈ ਅਤੇ ਵੱਡੇ ਸੈੱਟ ਵਿਆਪਕ ਪ੍ਰਦਰਸ਼ਨ ਮੈਟ੍ਰਿਕਸ ਲਈ।

ਆਨਲਾਈਨ ਮੁਲਾਂਕਣ

ਨਿਰੀਖਣਯੋਗਤਾ ਮੈਟ੍ਰਿਕਸ ਓਵਰਵਿਊ

ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਏਜੰਟ ਨੂੰ ਲਾਈਵ, ਅਸਲ-ਦੁਨੀਆ ਵਾਤਾਵਰਨ ਵਿੱਚ ਜਾਂਚਿਆ ਜਾਵੇ, ਯਾਨੀ ਉਤਪਾਦਨ ਵਿੱਚ ਅਸਲ ਵਰਤੋਂ ਦੌਰਾਨ। ਆਨਲਾਈਨ ਮੁਲਾਂਕਣ ਵਿਚ ਰੀਅਲ ਯੂਜ਼ਰ ਇੰਟਰੈਕਸ਼ਨਾਂ ‘ਤੇ ਏਜੰਟ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਨਿਰੰਤਰ ਨਿਗਰਾਨੀ ਅਤੇ ਨਤੀਜਿਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ।

ਉਦਾਹਰਨ ਵਜੋਂ, ਤੁਸੀਂ ਲਾਈਵ ਟ੍ਰੈਫਿਕ ‘ਤੇ ਸਫਲਤਾ ਦਰਾਂ, ਯੂਜ਼ਰ ਸੰਤੁਸ਼ਟੀ ਸਕੋਰ, ਜਾਂ ਹੋਰ ਮੈਟ੍ਰਿਕਸ ਟ੍ਰੈਕ ਕਰ ਸਕਦੇ ਹੋ। ਆਨਲਾਈਨ ਮੁਲਾਂਕਣ ਦਾ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਇਹ ਉਹ ਚੀਜ਼ਾਂ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਲੈਬ ਸੈਟਿੰਗ ਵਿੱਚ ਪਹਿਰ ਨਹੀਂ ਸਕਦੇ – ਤੁਸੀਂ ਸਮੇਂ ਦੇ ਨਾਲ ਮਾਡਲ ਡ੍ਰਿਫਟ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ (ਜੇ ਐਜੰਟ ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਇੰਪੁੱਟ ਪੈਟਰਨ ਬਦਲਣ ਨਾਲ ਘਟ ਰਹੀ ਹੋਵੇ) ਅਤੇ ਅਣਉਮੀਦਿਤ ਪ੍ਰਸ਼ਨਾਂ ਜਾਂ ਸਥਿਤੀਆਂ ਨੂੰ ਫੜ ਸਕਦੇ ਹੋ ਜੋ ਤੁਹਾਡੇ ਟੈਸਟ ਡੇਟਾ ਵਿੱਚ ਨਹੀਂ ਸਨ। ਇਹ ਅਸਲ ਤਸਵੀਰ ਦਿੰਦਾ ਹੈ ਕਿ ਏਜੰਟ ਜੰਗਲ ਵਿੱਚ ਕਿਵੇਂ ਬਰਤਾਅ ਕਰਦਾ ਹੈ।

ਆਨਲਾਈਨ ਮੁਲਾਂਕਣ ਅਕਸਰ ਅਪਰੋਕਸ਼ ਅਤੇ ਸਪਸ਼ਟ ਯੂਜ਼ਰ ਫੀਡਬੈਕ ਇਕੱਠਾ ਕਰਨ, ਅਤੇ ਸੰਭਵ ਹੈ ਕਿ ਸ਼ੈੱਡੋ ਟੈਸਟਾਂ ਜਾਂ A/B ਟੈਸਟ ਚਲਾਉਂਦਾ ਹੈ (ਜਿੱਥੇ ਏਜੰਟ ਦਾ ਨਵਾਂ ਸੰਸਕਰਣ ਪੁਰਾਣੇ ਦੇ ਨਾਲ ਤੁਲਨਾ ਲਈ ਸਮਾਂਤਰ ਚੱਲਦਾ ਹੈ)। ਚੁਣੌਤੀ ਇਹ ਹੈ ਕਿ ਲਾਈਵ ਇੰਟਰੈਕਸ਼ਨਾਂ ਲਈ ਭਰੋਸੇਯੋਗ ਲੇਬਲ ਜਾਂ ਸਕੋਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ – ਤੁਸੀਂ ਯੂਜ਼ਰ ਫੀਡਬੈਕ ਜਾਂ ਡਾਉਨਸਟ੍ਰੀਮ ਮੈਟ੍ਰਿਕਸ (ਜਿਵੇਂ ਕਿ ਕੀ ਯੂਜ਼ਰ ਨੇ ਨਤਾਜ਼ੇ ‘ਤੇ ਕਲਿੱਕ ਕੀਤਾ) ‘ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦੇ ਹੋ।

ਦੋਹਾਂ ਦਾ ਮਿਲਾਪ

ਆਨਲਾਈਨ ਅਤੇ ਆਫਲਾਈਨ ਮੁਲਾਂਕਣ ਪਰਸਪਰ ਵਿਰੋਧੀ ਨਹੀਂ ਹਨ; ਉਹ ਬਹੁਤ ਪੂਰੇ-ਕਰਮਕ ਹਨ। ਆਨਲਾਈਨ ਨਿਰੀਖਣ (ਉਦਾਹਰਨ ਲਈ, ਉਹ ਨਵੇਂ ਕਿਸਮ ਦੇ ਯੂਜ਼ਰ ਪ੍ਰਸ਼ਨ ਜਿੱਥੇ ਏਜੰਟ ਖਰਾਬ ਪ੍ਰਦਰਸ਼ਨ ਕਰ ਰਿਹਾ ਹੈ) ਤੋਂ ਮਿਲੀਆਂ ਜਾਣਕਾਰੀਆਂ ਆਫਲਾਈਨ ਟੈਸਟ ਡੇਟਾਸੈਟਾਂ ਨੂੰ ਵਧਾਉਣ ਅਤੇ ਸੁਧਾਰਨ ਲਈ ਵਰਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਉਲਟ, ਜੋ ਏਜੰਟ ਆਫਲਾਈਨ ਟੈਸਟਾਂ ਵਿੱਚ ਚੰਗਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਵੱਧ ਭਰੋਸੇਯੋਗਤਾਪੂਰਵਕ ਡਿਪਲੌਇ ਕੀਤਾ ਅਤੇ ਆਨਲਾਈਨ ਨਿਰੀਖਣ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਵਾਸਤਵ ਵਿੱਚ, ਕਈ ਟੀਮਾਂ ਇੱਕ ਲੂਪ ਅਪਣਾਉਂਦੀਆਂ ਹਨ:

ਆਫਲਾਈਨ ਦਾ ਮੁਲਾਂਕਣ -> ਡਿਪਲੌਇ -> ਆਨਲਾਈਨ ਨਿਰੀਖਣ -> ਨਵੇਂ ਫੇਲਿਅਰ ਮਾਮਲੇ ਇਕੱਠੇ ਕਰੋ -> ਆਫਲਾਈਨ ਡੇਟਾਸੈਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ -> ਏਜੰਟ ਨੂੰ ਸੁਧਾਰੋ -> ਦੁਹਰਾਓ.

ਆਮ ਸਮੱਸਿਆਵਾਂ

ਜਦੋਂ ਤੁਸੀਂ ਏਆਈ ਏਜੰਟਾਂ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਡਿਪਲੌਇ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਵੱਖ-ਵੱਖ ਚੁਣੌਤੀਆਂ ਦਾ ਸਾਹਮਣਾ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਥੇ ਕੁਝ ਆਮ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸੰਭਾਵਿਤ ਹੱਲ ਦਿੱਤੇ ਗਏ ਹਨ:

ਸਮੱਸਿਆ ਸੰਭਾਵਿਤ ਹੱਲ
AI ਏਜੰਟ ਟਾਸਕ ਲਗਾਤਾਰ ਨਹੀਂ ਕਰ ਰਿਹਾ - AI ਏਜੰਟ ਨੂੰ ਦਿੱਤਾ ਗਿਆ ਪ੍ਰਾਂਪਟ ਸੁਧਾਰੋ; ਉਦੇਸ਼ ਸਪੱਸ਼ਟ ਰੱਖੋ।
- ਪਛਾਣੋ ਕਿ ਕਿੱਥੇ ਟਾਸਕਾਂ ਨੂੰ ਛੋਟੇ-ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡ ਕੇ ਕਈ ਏਜੰਟਾਂ ਨਾਲ ਸੰਭਾਲਣਾ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ।
AI ਏਜੰਟ ਲਗਾਤਾਰ ਲੂਪ ਵਿੱਚ ਫਸ ਰਿਹਾ ਹੈ - ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਸਪੱਸ਼ਟ ਸਮਾਪਤੀ ਸ਼ਰਤਾਂ ਹਨ ਤਾਂ ਕਿ ਏਜੰਟ ਨੂੰ ਪਤਾ ਲੱਗੇ ਕਿ ਪ੍ਰਕਿਰਿਆ ਕਦੋਂ ਰੁਕਣੀ ਹੈ।
- ਜਟਿਲ ਟਾਸਕਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤਰਕ ਅਤੇ ਯੋਜਨਾ ਦੀ ਲੋੜ ਹੈ, ਉਹਨਾਂ ਲਈ ਰੀਜ਼ਨਿੰਗ-ਖਾਸ ਵੱਡਾ ਮਾਡਲ ਵਰਤੋਂ।
AI ਏਜੰਟ ਦੇ ਟੂਲ ਕਾਲਾਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਕਰ ਰਹੀਆਂ - ਏਜੰਟ ਸਿਸਟਮ ਦੇ ਬਾਹਰ ਟੂਲ ਦੇ ਆਉਟਪੁੱਟ ਦੀ ਟੈਸਟ ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਕਰੋ।
- ਪਰਿਭਾਸ਼ਿਤ ਪੈਰਾਮੀਟਰਾਂ, ਪ੍ਰਾਂਪਟਾਂ ਅਤੇ ਟੂਲਾਂ ਦੇ ਨਾਮਾਂ ਨੂੰ ਸੁਧਾਰੋ।
ਮਲਟੀ-ਏਜੰਟ ਸਿਸਟਮ ਲਗਾਤਾਰ ਨਹੀਂ ਚੱਲ ਰਿਹਾ - ਹਰ ਏਜੰਟ ਨੂੰ ਦਿੱਤੇ ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਸੁਧਾਰੋ ਤਾਂ ਜੋ ਉਹ ਵਿਸ਼ੇਸ਼ ਅਤੇ ਇਕ ਦੂਜੇ ਤੋਂ ਵੱਖਰੇ ਹੋਣ।
- ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਨ ਲਈ ਕਿ ਕਿਹੜਾ ਏਜੰਟ ਸਹੀ ਹੈ, “routing” ਜਾਂ ਕੰਟਰੋਲਰ ਏਜੰਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਹਾਇਰਾਰਕੀਕਲ ਸਿਸਟਮ ਬਣਾਓ।

ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਈ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਨਿਰੀਖਣਯੋਗਤਾ ਲਾਗੂ ਹੋਣ ਨਾਲ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਪਛਾਣਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਜਿਨ੍ਹਾਂ ਟਰੇਸਾਂ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਦਾ ਅਸੀਂ ਜ਼ਿਕਰ ਕੀਤਾ, ਉਹ ਏਜੰਟ ਵਰਕਫਲੋ ਵਿੱਚ ਠੀਕ ਕਿੱਥੇ ਸਮੱਸਿਆ ਆ ਰਹੀ ਹੈ, ਇਹ ਨਿਸ਼ਚਿਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਡੇਬੱਗਿੰਗ ਅਤੇ ਅਪਟਿਮਾਈਜ਼ੇਸ਼ਨ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣ ਜਾਂਦੇ ਹਨ।

ਲਾਗਤਾਂ ਦਾ ਪ੍ਰਬੰਧ

ਇੱਥੇ ਕੁਝ ਰਣਨੀਤੀਆਂ ਹਨ ਜੋ AI ਏਜੰਟਾਂ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਤਾਇਨਾਤ ਕਰਨ ਦੀਆਂ ਲਾਗਤਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਵਰਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ:

ਛੋਟੇ ਮਾਡਲਾਂ ਦੀ ਵਰਤੋਂ: Small Language Models (SLMs) ਕੁਝ ਏਜੈਂਟਿਕ ਉਪਯੋਗ ਕੇਸਾਂ ਵਿੱਚ ਚੰਗਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਲਾਗਤਾਂ ਨੂੰ ਮਹੱਤਵਪੂਰਕ ਤੌਰ ‘ਤੇ ਘਟਾ ਦੇਣਗੇ। ਜਿਵੇਂ ਪਹਿਲਾਂ ਦੱਸਿਆ ਗਿਆ, ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਅਤੇ ਵੱਡੇ ਮਾਡਲਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰਨ ਲਈ ਇੱਕ ਇਵੈਲੂਏਸ਼ਨ ਪ੍ਰਣਾਲੀ ਬਣਾਉਣਾ ਇਹ ਸਮਝਣ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੇਸ ਵਿੱਚ SLM ਕਿਵੇਂ ਕੰਮ ਕਰੇਗਾ। ਸਧਾਰਣ ਕੰਮਾਂ ਲਈ ਜਿਵੇਂ ਇਰਾਦੇ ਦੀ ਵਰਗੀਕਰਨ (intent classification) ਜਾਂ ਪੈਰਾਮੀਟਰ ਨਿਕਾਸ (parameter extraction) ਲਈ SLMs ਦੀ ਵਰਤੋਂ ਕਰਨ ਬਾਰੇ ਸੋਚੋ, ਜਦਕਿ ਜਟਿਲ ਤਰਕ-ਵਿਚਾਰ ਲਈ ਵੱਡੇ ਮਾਡਲ ਰੱਖੋ।

ਰਾਊਟਰ ਮਾਡਲ ਦੀ ਵਰਤੋਂ: ਇਕੋ ਜਿਹੀ ਰਣਨੀਤੀ ਇਹ ਹੈ ਕਿ ਵੱਖ-ਵੱਖ ਮਾਡਲਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਆਕਾਰਾਂ ਦੀ ਵਿਵਿਧਤਾ ਵਰਤੀ ਜਾਵੇ। ਤੁਸੀਂ LLM/SLM ਜਾਂ ਸਰਵਰਲੇਸ ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੇਚੀਦਗੀ ਦੇ ਆਧਾਰ ‘ਤੇ ਰਿਕਵੈਸਟਾਂ ਨੂੰ ਸਭ ਤੋਂ موزੂਨ ਮਾਡਲਾਂ ਵੱਲ ਰੂਟ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਲਾਗਤਾਂ ਘਟਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ ਅਤੇ ਠੀਕ ਟਾਸਕਾਂ ‘ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਯਕੀਨੀ ਬਣਾਏਗਾ। ਉਦਾਹਰਨ ਵਜੋਂ, ਸਧਾਰਣ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਛੋਟੇ, ਤੇਜ਼ ਮਾਡਲਾਂ ਵੱਲ ਰੂਟ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਜਟਿਲ ਤਰਕ ਦੇ ਟਾਸਕਾਂ ਲਈ ਮਹਿੰਗੇ ਵੱਡੇ ਮਾਡਲ ਵਰਤੋਂ।

ਰੈਸਪਾਂਸ ਕੈਚਿੰਗ: ਆਮ ਰਿਕਵੈਸਟਾਂ ਅਤੇ ਟਾਸਕਾਂ ਦੀ ਪਛਾਣ ਕਰਕੇ ਉਹਨਾਂ ਦੇ ਜਵਾਬ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਦਾਨ ਕਰਨਾ, ਜਿਸ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਤੁਹਾਡੀ ਏਜੈਂਟਿਕ ਪ੍ਰਣਾਲੀ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਨ, ਸਮਾਨ ਰਿਕਵੈਸਟਾਂ ਦੀ ਸੰਖਿਆ ਘਟਾਉਣ ਦਾ ਇੱਕ ਚੰਗਾ ਤਰੀਕਾ ਹੈ। ਤੁਸੀਂ ਇਹ ਵੀ ਇੱਕ ਫਲੋ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਬੁਨਿਆਦੀ AI ਮਾਡਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਤਾ ਲਗਾਏ ਕਿ ਕੋਈ ਰਿਕਵੈਸਟ ਤੁਹਾਡੇ ਕੇਸ਼ ਕੀਤੀਆਂ ਰਿਕਵੈਸਟਾਂ ਨਾਲ ਕਿੰਨੀ ਮਿਲਦੀ-ਜੁਲਦੀ ਹੈ। ਇਹ ਰਣਨੀਤੀ ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲਾਂ ਜਾਂ ਆਮ ਵਰਕਫਲੋਜ਼ ਲਈ ਲਾਗਤਾਂ ਨੂੰ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਘਟਾ ਸਕਦੀ ਹੈ।

ਆਓ ਵੇਖੀਏ ਕਿ ਇਹ ਅਮਲ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

In the ਇਸ ਸੈਕਸ਼ਨ ਦੀ ਉਦਾਹਰਨ ਨੋਟਬੁੱਕ, ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਅਸੀਂ ਆਪਣੇ ਏਜੰਟ ਦੀ ਨਿਗਰਾਨੀ ਅਤੇ ਮੁਲਾਂਕਣ ਲਈ observability ਟੂਲਾਂ ਦਾ ਕਿਵੇਂ ਉਪਯੋਗ ਕਰ ਸਕਦੇ ਹਾਂ।

ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ AI ਏਜੰਟਾਂ ਬਾਰੇ ਹੋਰ ਸਵਾਲ ਹਨ?

ਹੋਰ ਸਿੱਖਣ ਵਾਲਿਆਂ ਨਾਲ ਮਿਲਣ, ਆਫਿਸ ਘੰਟਿਆਂ ਵਿੱਚ ਹਾਜ਼ਰੀ ਲੈਣ ਅਤੇ ਆਪਣੇ AI ਏਜੰਟਾਂ ਸਬੰਧੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ Microsoft Foundry Discord ਨਾਲ ਜੁੜੋ।

ਪਿਛਲਾ ਪਾਠ

Metacognition ਡਿਜ਼ਾਈਨ ਪੈਟਰਨ

ਅਗਲਾ ਪਾਠ

Agentic ਪ੍ਰੋਟੋਕੋਲ


ਅਸਵੀਕਰਨ: ਇਹ ਦਸਤਾਵੇਜ਼ AI ਅਨੁਵਾਦ ਸੇਵਾ Co-op Translator (https://github.com/Azure/co-op-translator) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਨੁਵਾਦ ਕੀਤਾ ਗਿਆ ਹੈ। ਅਸੀਂ ਸ਼ੁੱਧਤਾ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ, ਪਰ ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਰੱਖੋ ਕਿ ਸਵੈਚਾਲਿਤ ਅਨੁਵਾਦਾਂ ਵਿੱਚ ਗਲਤੀਆਂ ਜਾਂ ਅਸਪਸ਼ਟਤਾਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਮੂਲ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਇਸ ਦੀ ਮੂਲ ਭਾਸ਼ਾ ਵਿੱਚ ਹੀ ਅਧਿਕਾਰਤ ਸਰੋਤ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਂ ਅਤਿ ਮਹੱਤਵਪੂਰਣ ਜਾਣਕਾਰੀ ਲਈ ਪੇਸ਼ੇਵਰ ਮਨੁੱਖੀ ਅਨੁਵਾਦ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਅਸੀਂ ਇਸ ਅਨੁਵਾਦ ਦੀ ਵਰਤੋਂ ਕਾਰਨ ਹੋਣ ਵਾਲੀਆਂ ਕਿਸੇ ਵੀ ਗਲਤਫਹਮੀਆਂ ਜਾਂ ਗਲਤ ਵਿਆਖਿਆਵਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਨਹੀਂ ਹਾਂ।