ਚਾਰ ਆਟੋਨੋਮਸ AI agents ਹੁਣ ਇੱਕ ਸਾਫਟਵੇਅਰ ਗਲਿੱਚ (glitch) ਦੀ ਪਛਾਣ ਕਰ ਸਕਦੇ ਹਨ, ਖਰਾਬ ਕੋਡ ਨੂੰ ਐਡਿਟ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਫਿਕਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹਨ—ਇਹ ਸਭ ਇੱਕ ਮਿੰਟ ਤੋਂ ਵੀ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਹੋ ਜਾਂਦਾ ਹੈ, SigNoz hackathon ਲਈ ਬਣਾਏ ਗਏ ਇੱਕ ਨਵੇਂ observability-driven workflow ਦੀ ਮਦਦ ਨਾਲ।
AgentOps ਨਾਮ ਦਾ ਇਹ ਸਿਸਟਮ, SigNoz ਵਿੱਚ error spikes 'ਤੇ ਨਜ਼ਰ ਰੱਖਦਾ ਹੈ, ਸਬੰਧਤ logs ਅਤੇ traces ਕੱਢਦਾ ਹੈ, ਜ਼ਿੰਮੇਵਾਰ ਫਾਈਲ ਅਤੇ ਲਾਈਨ ਦੀ ਸਹੀ ਪਛਾਣ ਕਰਦਾ ਹੈ, sandbox ਵਿੱਚ source ਨੂੰ ਐਡਿਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਇਹ proving ਕਰਨ ਲਈ ਕਿ bug ਖਤਮ ਹੋ ਗਿਆ ਹੈ, request ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਂਦਾ ਹੈ। ਹਰ ਪੂਰਾ ਚੱਕਰ (cycle) 30-60 ਸੈਕਿੰਡ ਵਿੱਚ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਬਿਨਾਂ ਕਿਸੇ ਮਨੁੱਖੀ prompt ਦੇ ਚੱਲਦੀ ਹੈ।
AI agents ਲਈ observability ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਰਵਾਇਤੀ SRE ਅਭਿਆਸ logs, metrics ਅਤੇ distributed traces ਨੂੰ ਇੱਕ service ਦੀਆਂ ਅੱਖਾਂ ਵਜੋਂ ਮੰਨਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ request ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਇੰਜੀਨੀਅਰ offending component ਤੱਕ trace ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ। ਇਹੀ ਸਿਧਾਂਤ ਹੁਣ AgentOps ਨੂੰ ਚਲਾ ਰਿਹਾ ਹੈ, ਪਰ ਜਿਸ "service" ਦੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ, ਉਹ ਖੁਦ AI agent ਹੈ।
ਹਰ ਟੂਲ ਜਿਸਨੂੰ agent ਵਰਤਦਾ ਹੈ—ਚਾਹੇ ਉਹ language model call ਹੋਵੇ, file-system edit ਹੋਵੇ ਜਾਂ test runner—trace ਵਿੱਚ ਇੱਕ span ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ span ਸ਼ੁਰੂ ਹੋਣ ਦਾ ਸਮਾਂ, ਮਿਆਦ (duration) ਅਤੇ ਸਫਲਤਾ ਦੀ ਸਥਿਤੀ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ agent ਦੇਖ ਸਕੇ ਕਿ ਹਰੇਕ ਤਰਕ ਵਾਲਾ ਕਦਮ (reasoning step) ਕਿੰਨਾ ਸਮਾਂ ਲਿਆ ਅਤੇ ਕੀ ਉਹ ਸਫਲ ਰਿਹਾ। ਉਹਨਾਂ spans ਨੂੰ ਆਪਸ ਵਿੱਚ ਜੋੜ ਕੇ, agent ਆਪਣੀ ਸੋਚਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਇੱਕ ਮੁਕੰਮਲ ਤਸਵੀਰ ਬਣਾਉਂਦਾ ਹੈ, ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਜਿਵੇਂ ਕੋਈ ਇਨਸਾਨ ਮੈਨੂਅਲ ਡੀਬੱਗਿੰਗ (debugging) ਕਰਦੇ ਸਮੇਂ ਕਰਦਾ ਹੈ।
ਮੁੱਖ ਬਦਲਾਅ "reporting layer ਵਜੋਂ observability" ਤੋਂ "perception ਵਜੋਂ observability" ਵੱਲ ਹੈ। AgentOps trace data ਨੂੰ ਵਾਪਸ agents ਨੂੰ ਭੇਜਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਉਹ real time ਵਿੱਚ ਆਪਣੇ ਕੰਮਾਂ ਬਾਰੇ ਤਰਕ ਕਰ ਸਕਦੇ ਹਨ। ਇਸਦਾ ਨਤੀਜਾ ਇੱਕ ਅਜਿਹਾ ਲੂਪ (loop) ਹੈ ਜਿੱਥੇ AI ਨਾ ਸਿਰਫ਼ ਇੱਕ hypothesis ਬਣਾਉਂਦਾ ਹੈ, ਸਗੋਂ ਉਸੇ telemetry ਦੇ ਆਧਾਰ 'ਤੇ ਉਸਦੀ ਪੁਸ਼ਟੀ ਵੀ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਵਰਤੋਂ ਉਹ ਸਮੱਸਿਆ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕਰਦਾ ਹੈ।
ਚਾਰ-ਪੜਾਵੀ workflow
- Monitor – ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ watcher ਨਵੇਂ ਰਿਪੋਰਟ ਕੀਤੇ ਗਏ errors ਲਈ SigNoz ਨੂੰ ਸਕੈਨ ਕਰਦਾ ਹੈ।
- Diagnose – agent ਸਬੰਧਤ logs ਅਤੇ traces ਕੱਢਦਾ ਹੈ, stack ਨੂੰ ਕੱਢਦਾ ਹੈ, ਅਤੇ ਉਸ source file ਅਤੇ ਲਾਈਨ ਨੰਬਰ ਨੂੰ ਅਲੱਗ ਕਰਦਾ ਹੈ ਜਿਸ ਕਾਰਨ failure ਹੋਈ।
- Fix – ਇੱਕ sandboxed file-system server ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, agent ਪਛਾਣੀ ਗਈ ਲਾਈਨ 'ਤੇ ਇੱਕ patch ਲਿਖਦਾ ਹੈ। Sandbox ਸਖ਼ਤ ਅਨੁਮਤੀਆਂ (permissions) ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ ਅਤੇ ਜੇਕਰ ਐਡਿਟ ਨੀਤੀ ਦੀ ਉਲੰਘਣਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਆਪਣੇ ਆਪ ਪੁਰਾਣੀ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ (roll back) ਆ ਜਾਂਦਾ ਹੈ।
- Verify – agent patched code ਦੇ ਵਿਰੁੱਧ ਅਸਲ request ਨੂੰ ਦੁਬਾਰਾ ਭੇਜਦਾ ਹੈ। ਜੇਕਰ trace ਇੱਕ ਸਾਫ਼ ਰਨ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ fix ਨੂੰ commit ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ; ਨਹੀਂ ਤਾਂ agent ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।
ਸਾਰੇ ਪੜਾਅ agents ਦੇ ਇੱਕੋ ਸਮੂਹ ਦੁਆਰਾ ਸੰਚਾਲਿਤ (orchestrated) ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜਿੱਥੇ ਹਰ ਇੱਕ ਇੱਕ autonomous micro-service ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਪੂਰੀ ਲੜੀ OpenTelemetry-compatible spans ਰਾਹੀਂ ਦੇਖੀ ਜਾ ਸਕਦੀ ਹੈ, ਜਿਸ ਨੂੰ SigNoz ingests ਅਤੇ visualises ਕਰਦਾ ਹੈ।
ਭਰੋਸੇਯੋਗਤਾ (reliability) ਬਾਰੇ ਮਿਹਨਤ ਨਾਲ ਸਿੱਖੇ ਗਏ ਸਬਕ
Error ਦੀ ਸਪੱਸ਼ਟਤਾ
ਇੱਕ ਆਮ "failed" ਸਥਿਤੀ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ। ਟੀਮ ਨੇ ਵਿਸਤ੍ਰਿਤ (granular) ਅਸਫਲਤਾ ਦੇ ਕਾਰਨ ਜੋੜੇ ਹਨ—ਜਿਵੇਂ ਕਿ "ਗਲਤ hypothesis" ਜਾਂ "patch ਨੇ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਤੋੜ ਦਿੱਤਾ"—so ਕਿ downstream agents ਇਹ ਫੈਸਲਾ ਕਰ ਸਕਣ ਕਿ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਹੈ, ਪਿੱਛੇ ਹਟਣਾ ਹੈ ਜਾਂ ਰੋਕਣਾ ਹੈ। ਇਹ ਉਸੇ ਤਰ੍ਹਾਂ ਹੈ ਜਿਵੇਂ ਮਨੁੱਖੀ post-mortems ਮੂਲ ਕਾਰਨਾਂ (root causes) ਨੂੰ ਲੇਬਲ ਕਰਦੇ ਹਨ।
Data latency
Telemetry ਤੁਰੰਤ ਪ੍ਰਗਟ ਨਹੀਂ ਹੁੰਦੀ। Agents ਹੁਣ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਵਿਰਾਮ (pause) ਅਤੇ sanity check ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ fix ਦਾ ਦਾਅਵਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜੀਂਦੇ logs ਆ ਚੁੱਕੇ ਹਨ। ਇਸ ਸੁਰੱਖਿਆ ਦੇ ਬਿਨਾਂ, ਇੱਕ agent ਅਧੂਰੇ ਡੇਟਾ 'ਤੇ ਕਾਰਵਾਈ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਗਲਤ (false positive) ਨਤੀਜਾ ਦੇ ਸਕਦਾ ਹੈ।
ਸੁਰੱਖਿਆ ਸੀਮਾਵਾਂ (Security boundaries)
ਇੱਕ AI ਨੂੰ ਕੋਡ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣਾ privilege escalation ਦਾ ਜੋਖਮ ਹੈ। Sandbox ਇੱਕ ਸਮਰਪਿਤ filesystem server ਦੇ ਪਿੱਛੇ ਚੱਲਦਾ ਹੈ ਜੋ write scope ਨੂੰ ਸਿਰਫ target repository ਤੱਕ ਸੀਮਤ ਰੱਖਦਾ ਹੈ ਅਤੇ ਜੇਕਰ ਕੋਈ ਟੈਸਟ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਆਪਣੇ ਆਪ ਪੁਰਾਣੀ ਸਥਿਤੀ ਨੂੰ ਬਹਾਲ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ containment model AI ਦੀ ਸ਼ਕਤੀ ਨੂੰ ਕਾਬੂ ਵਿੱਚ ਰੱਖਦਾ ਹੈ।
Token limits
Large language models API tokens ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਅਤੇ ਰੋਜ਼ਾਨਾ ਕੋਟਾ ਜਾਂਚ ਦੇ ਵਿਚਕਾਰ ਹੀ ਖਤਮ ਹੋ ਸਕਦਾ ਹੈ। AgentOps ਹਰੇਕ ਘਟਨਾ (incident) ਲਈ token ਦੀ ਵਰਤੋਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸੀਮਾ (threshold) 'ਤੇ ਪਹੁੰਚਣ ਤੋਂ ਬਾਅਦ ਹੋਰ calls ਨੂੰ ਘਟਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਕੋਟਾ ਖਤਮ ਹੋਣ 'ਤੇ ਅਸਫਲ ਫਿਕਸਾਂ ਦੀ ਲੜੀ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ।
ਡੈਮੋ ਨੇ ਕੀ ਸਾਬਤ ਕੀਤਾ
ਟੀਮ ਨੇ ਇੱਕ ਬਿਲਕੁਲ ਨਵਾਂ bug ਪੈਦਾ ਕੀਤਾ ਜੋ ਕਦੇ ਵੀ codebase ਵਿੱਚ ਨਹੀਂ ਆਇਆ ਸੀ। AgentOps ਨੇ ਅਸਧਾਰਨਤਾ (anomaly) ਦਾ ਪਤਾ ਲਗਾਇਆ, ਇਸਨੂੰ ਸਹੀ ਲਾਈਨ ਤੱਕ ਟ੍ਰੇਸ ਕੀਤਾ, ਇੱਕ ਸੁਧਾਰਕ ਐਡਿਟ (corrective edit) ਤਿਆਰ ਕੀਤਾ, sandbox ਵਿੱਚ patch ਲਗਾਇਆ ਅਤੇ ਪੁਸ਼ਟੀ ਕੀਤੀ ਕਿ request ਸਫਲ ਰਹੀ—ਇਹ ਸਭ ਬਿਨਾਂ ਕਿਸੇ ਮੈਨੂਅਲ ਕੋਡ ਤਬਦੀਲੀ ਜਾਂ ਨਵੇਂ prompts ਦੇ ਹੋਇਆ। End-to-end ਸਮਾਂ ਇੱਕ ਮਿੰਟ ਤੋਂ ਘੱਟ ਰਿਹਾ, ਜੋ ਰਿਪੋਰਟ ਕੀਤੇ ਗਏ 30-60 ਸੈਕਿੰਡ ਦੇ ਸਮੇਂ ਦੇ ਬਰਾਬਰ ਸੀ।
ਵਿਰੋਧੀ ਨੁਕਤਾ: autonomy ਕੋਈ ਜਾਦੂਈ ਹੱਲ (silver bullet) ਨਹੀਂ ਹੈ
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
- ਮਾਡਲ-ਨਿਰਪੱਖ ਟੈਲੀਮੈਟਰੀ – ਜਿਵੇਂ-ਜਿਵੇਂ ਵਧੇਰੇ ਵੈਂਡਰ OpenTelemetry-ਅਨੁਕੂਲ ਸਪੈਨ (spans) ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਇਹ ਪਹੁੰਚ ਵੈਂਡਰ-ਨਿਰਪੱਖ ਹੋ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਵੱਖ-ਵੱਖ ਤਰ੍ਹਾਂ ਦੇ ਸਟੈਕਸ (stacks) ਵਿੱਚ ਇਸ ਨੂੰ ਅਪਣਾਉਣਾ ਆਸਾਨ ਹੋ ਜਾਵੇਗਾ।
- ਪਾਲਿਸੀ-ਡਰਿਵਨ ਗਾਰਡਰੇਲਜ਼ – ਕੌਂਫਿਗਰੇਬਲ ਪਾਲਿਸੀਆਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਜੋ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀਆਂ ਹਨ ਕਿ ਇੱਕ ਏਜੰਟ ਕਿਹੜੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਐਡਿਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਕਮਿਟ (commit) ਤੋਂ ਪਹਿਲਾਂ ਕਿਹੜੇ ਟੈਸਟ ਸੂਟ ਪਾਸ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਗਵਰਨੈਂਸ ਸੰਬੰਧੀ ਚਿੰਤਾਵਾਂ ਨੂੰ ਹੱਲ ਕਰੇਗੀ।
- ਲਾਗਤ-ਜਾਗਰੂਕ ਟੋਕਨ ਬਜਟਿੰਗ – ਘਟਨਾ ਦੀ ਗੰਭੀਰਤਾ ਦੇ ਅਧਾਰ 'ਤੇ ਡਾਇਨਾਮਿਕ ਟੋਕਨ ਅਲਾਟੇਸ਼ਨ ਕੋਟਾ ਖਤਮ ਹੋਣ ਤੋਂ ਰੋਕ ਸਕਦੀ ਹੈ ਅਤੇ ਨਾਲ ਹੀ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਬੱਗਾਂ (bugs) ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖ ਸਕਦੀ ਹੈ।
AgentOps ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਬੱਗ-ਫਿਕਸ ਚੱਕਰ (bug-fix cycle) ਵਿੱਚ 30-60 ਸੈਕਿੰਡ ਲੱਗ ਸਕਦੇ ਹਨ। ਇਹ ਪ੍ਰਯੋਗ ਇੱਕ ਪ੍ਰੂਫ-ਆਫ-ਕੰਸੈਪਟ (proof-of-concept) ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਆਬਜ਼ਰਵੇਬਿਲਟੀ (observability) ਦੀ ਵਰਤੋਂ ਸਵੈ-ਚਾਲਿਤ ਸਾਫਟਵੇਅਰ ਸਹਾਇਕਾਂ ਦੁਆਰਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।