Agentic AI ROI ਦਾ ਚੁੱਪ ਰਹਿਣ ਵਾਲਾ ਕਤਲ
ਤੁਹਾਡੇ Kubernetes pods ਹਰੇ ਹਨ। ਤੁਹਾਡੀ API latency ਘੱਟ ਹੈ। ਤੁਹਾਡਾ LLM provider 99.9% uptime ਦਿਖਾ ਰਿਹਾ ਹੈ।
ਫਿਰ ਵੀ, ਤੁਹਾਡੇ ਆਟੋਮੇਟਡ ਲੋਨ ਸਿਸਟਮ ਨੇ ਸਿਰਫ਼ ਤਿੰਨ ਘੰਟਿਆਂ ਵਿੱਚ ਆਪਣਾ ਪੂਰਾ ਮਹੀਨਾਵਾਰ API ਬਜਟ ਖ਼ਤਮ ਕਰ ਦਿੱਤਾ। ਦੋ agents ਇੱਕ ਲੂਪ (loop) ਵਿੱਚ ਫਸ ਗਏ।
ਇਹ "ਸਿਹਤਮੰਦ ਪਰ ਭਰਮ (Hallucinating)" ਵਾਲਾ ਵਿਰੋਧਾਭਾਸ ਹੈ।
ਰਵਾਇਤੀ ਸਾਫਟਵੇਅਰ ਵਿੱਚ, ਇੱਕ ਸਿਸਟਮ ਜਾਂ ਤਾਂ ਚੱਲ ਰਿਹਾ ਹੁੰਦਾ ਹੈ ਜਾਂ ਬੰਦ। ਇੱਕ agentic mesh ਵਿੱਚ, ਇੱਕ ਸਿਸਟਮ ਸਿਹਤਮੰਦ ਦਿਖ ਸਕਦਾ ਹੈ ਪਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ agents ਲਈ ਸਟੈਂਡਰਡ Site Reliability Engineering (SRE) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਸੰਕੇਤਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰ ਰਹੇ ਹੋ। ਤੁਸੀਂ ਇੱਕ ਅਜਿਹੇ ਮਰੀਜ਼ ਦੇ ਦਿਲ ਦੀ ਧੜਕਣ ਨੂੰ ਮਾਪ ਰਹੇ ਹੋ ਜੋ ਅਸਲ ਵਿੱਚ ਦਿਮਾਗੀ ਤੌਰ 'ਤੇ ਮਰ ਚੁੱਕਾ ਹੈ।
ਸਟੈਂਡਰਡ ਇਨਫਰਾਸਟ੍ਰਕਚਰ agentic collapse ਨੂੰ ਰੋਕਣ ਵਿੱਚ ਕਿਉਂ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ?
ਰਵਾਇਤੀ SRE ਨਿਰਧਾਰਤ (deterministic) ਸਿਸਟਮਾਂ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਜਦੋਂ ਕੋਈ ਸਰਵਿਸ ਫੇਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ error ਦਿੰਦੀ ਹੈ। ਇਹ binary ਹੁੰਦਾ ਹੈ। Agent ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਵੱਖਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ agent crash ਨਹੀਂ ਹੁੰਦਾ। ਇਹ drift ਕਰਦਾ ਹੈ। ਇਹ time out ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਇੱਕ ਅਜਿਹਾ parameter hallucinate ਕਰਦਾ ਹੈ ਜੋ ਕਈ ਕਦਮਾਂ ਬਾਅਦ ਇੱਕ ਚੁੱਪ ਰਹਿਣ ਵਾਲੀ ਅਸਫਲਤਾ (silent failure) ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ।
ਅਸੀਂ ਸਿੰਗਲ ਬੋਟਸ ਤੋਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ agent fabrics ਵੱਲ ਜਾਣ ਦੌਰਾਨ ਇਹ ਪਾੜਾ ਦੇਖਦੇ ਹਾਂ। ਇੱਕ ਟੀਮ ਇੱਕ benchmark 'ਤੇ 95% ਸ਼ੁੱਧਤਾ (accuracy) ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ, ਪਰ ਸਿਸਟਮ production ਵਿੱਚ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ। Benchmarks ਇਹ ਮਾਪਦੇ ਹਨ ਕਿ ਕੀ ਕੋਈ ਮਾਡਲ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ। ਉਹ ਇਹ ਨਹੀਂ ਮਾਪਦੇ ਕਿ ਕੀ ਇੱਕ ਸਿਸਟਮ ਚਾਰ agents ਵਾਲੇ 12-ਕਦਮਾਂ ਦੇ workflow ਵਿੱਚ state ਨੂੰ ਬਣਾਈ ਰੱਖ ਸਕਦਾ ਹੈ।
ਤੁਹਾਨੂੰ Agent Reliability Engineering (ARE) ਦੀ ਲੋੜ ਹੈ।
ਰਵਾਇਤੀ SRE binary states ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ। ARE probability distributions ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ CPU ਅਤੇ memory ਨੂੰ ਟ੍ਰੈਕ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ agent ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਪ੍ਰਤੀ ਅੰਨ੍ਹੇ ਹੋ।
Multi-agent ਸਿਸਟਮਾਂ ਵਿੱਚ ਗਲਤੀਆਂ ਸਿਰਫ਼ ਵਧਦੀਆਂ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਉਹ ਗੁਣਾ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਕਿਉਂਕਿ agents ਦੂਜੇ agents ਦੇ output ਨੂੰ ਸੱਚ ਮੰਨਦੇ ਹਨ, ਪਹਿਲੇ ਕਦਮ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਗਲਤੀ ਪੰਜਵੇਂ ਕਦਮ ਤੱਕ ਇੱਕ ਤਬਾਹੀ ਬਣ ਜਾਂਦੀ ਹੈ।
ਆਮ ਅਸਫਲਤਾ ਦੇ ਤਰੀਕੇ (failure modes) ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
- Agentic infinite loops
- State drift
- Prompt injection cascades
- Tool-call hallucinations
ਇੱਕ ਖ਼ਤਰਨਾਕ ਉਦਾਹਰਨ: ਇੱਕ agent ਇੱਕ update tool ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ। ਇਹ ਇੱਕ ਅਜਿਹਾ parameter ਬਣਾ ਲੈਂਦਾ ਹੈ ਜੋ ਮੌਜੂਦ ਨਹੀਂ ਹੈ। API ਵਾਧੂ parameter ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦੀ ਹੈ ਅਤੇ 200 OK ਵਾਪਸ ਕਰ ਦਿੰਦੀ ਹੈ। Agent ਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਉਹ ਸਫਲ ਰਿਹਾ, ਪਰ business logic ਚੁੱਪਚਾਪ ਫੇਲ ਹੋ ਗਿਆ।
ARE "intent-action-outcome" ਲੂਪ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਸਿਰਫ਼ ਇਹ ਨਿਗਰਾਨੀ ਨਹੀਂ ਕਰਦੇ ਕਿ ਕੀ ਇੱਕ agent ਨੇ tool ਨੂੰ ਕਾਲ ਕੀਤਾ। ਤੁਸੀਂ ਇਹ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹੋ ਕਿ ਕੀ ਉਹ ਕਾਲ ਅਸਲ intent ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਸੀ ਅਤੇ ਕੀ outcome ਨੇ ਟੀਚੇ ਨੂੰ ਪ੍ਰਾਪਤ ਕੀਤਾ।
Agent Reliability Engineer (ARE) ਦੀ ਭੂਮਿਕਾ ਇਹ ਸੰਭਾਲਦੀ ਹੈ:
- Intent Analysis: ਇਹ ਪਛਾਣਨਾ ਕਿ ਕਦੋਂ ਇੱਕ agent ਟੀਚੇ ਤੋਂ ਭਟਕਦਾ ਹੈ।
- Guardrail Tuning: ਲੂਪਸ ਨੂੰ ਰੋਕਣ ਲਈ constraints ਨੂੰ ਐਡਜਸਟ ਕਰਨਾ।
- Dependability Mapping: ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਕਿ ਕਦੋਂ ਇੱਕ agent ਨੂੰ ਮਨੁੱਖ ਨੂੰ ਕੰਮ ਸੌਂਪਣਾ ਚਾਹੀਦਾ ਹੈ।
- Audit Architecture: ਅੰਦਰੂਨੀ ਤਰਕ (reasoning) ਅਤੇ state ਤਬਦੀਲੀਆਂ ਨੂੰ ਕੈਪਚਰ ਕਰਨਾ।
ਸ਼ੁੱਧਤਾ (accuracy) ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਬੰਦ ਕਰੋ। System Dependability ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ।
ਤੁਸੀਂ ਮਨੁੱਖੀ ਦਖਲਅੰਦਾਜ਼ੀ ਦੀ ਲਾਗਤ ਨੂੰ ਮਾਪ ਕੇ ਇਸ ਨੂੰ CFO ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾ ਸਕਦੇ ਹੋ। ਹਰ ਵਾਰ ਜਦੋਂ ਕੋਈ ਮਨੁੱਖ agent ਦੀ ਗਲਤੀ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ, ਉਹ ਇੱਕ reliability failure ਹੁੰਦਾ ਹੈ। ਉਹਨਾਂ ਘੰਟਿਆਂ ਨੂੰ ਆਪਣੇ ਮਾਹਰਾਂ ਦੀ ਤਨਖਾਹ ਨਾਲ ਗੁਣਾ ਕਰੋ। ਅਭਰੋਸੇਯੋਗਤਾ (unreliability) ਦੀ ਲਾਗਤ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੀ ਹੈ।
Agentic Error Budgets ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ email summarizer ਲਈ, ਤੁਹਾਡਾ error budget ਉੱਚਾ ਹੈ। ਇੱਕ ਅਜਿਹੇ ਸਿਸਟਮ ਲਈ ਜੋ $10M ਟ੍ਰਾਂਸਫਰ ਕਰਦਾ ਹੈ, ਤੁਹਾਡਾ error budget ਜ਼ੀਰੋ ਹੈ।
AI ਨੂੰ ਇੱਕ software feature ਵਜੋਂ ਨਾ ਸਮਝੋ। ਇਸਨੂੰ ਇੱਕ systemic risk ਵਜੋਂ ਲਓ। ਇਸ ਯੁੱਗ ਦੇ ਜੇਤੂਆਂ ਕੋਲ ਸਭ ਤੋਂ ਸਮਾਰਟ ਮਾਡਲ ਨਹੀਂ ਹੋਣਗੇ। ਉਹਨਾਂ ਕੋਲ ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ (dependable) ਸਿਸਟਮ ਹੋਣਗੇ।
Optional learning community: https://t.me/GyaanSetuAi