ਪ੍ਰੋਡਕਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ AI Agent Playground ਬਣਾਉਣਾ

ਇੱਕ ਕੋਡਿੰਗ ਏਜੰਟ ਨੇ ਇੱਕ ਵਾਰ ਉਸ ਡਾਟਾਬੇਸ 'ਤੇ ਇੱਕ ਕਲੀਨਅੱਪ ਸਕ੍ਰਿਪਟ ਚਲਾਈ ਜਿਸਨੂੰ ਉਹ ਸਟੇਜਿੰਗ (staging) ਡਾਟਾਬੇਸ ਸਮਝ ਰਿਹਾ ਸੀ। ਅਸਲ ਵਿੱਚ ਉਹ ਪ੍ਰੋਡਕਸ਼ਨ (production) ਸੀ। ਏਜੰਟ ਨੇ ਚਾਰ ਮਹੀਨਿਆਂ ਦੇ ਗਾਹਕਾਂ ਦੇ ਆਰਡਰ ਡਿਲੀਟ ਕਰ ਦਿੱਤੇ ਕਿਉਂਕਿ ਉਸਨੇ ਗਲਤ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲਜ਼ (credentials) ਨਾਲ ਉਹੀ ਕੀਤਾ ਜੋ ਉਸਨੂੰ ਦੱਸਿਆ ਗਿਆ ਸੀ।

ਇਹ ਅਸਫਲਤਾ ਏਜੰਟਾਂ ਤੋਂ ਬਚਣ ਦਾ ਕਾਰਨ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਪਲੇਗਰਾਊਂਡ (playground) ਬਣਾਉਣ ਦਾ ਕਾਰਨ ਹੈ।

ਤੁਸੀਂ ਕਿਸੇ ਨਵੇਂ ਇੰਜੀਨੀਅਰ ਨੂੰ ਉਸਦੇ ਪਹਿਲੇ ਦਿਨ ਹੀ ਪ੍ਰੋਡਕਸ਼ਨ ਡਾਟਾਬੇਸ ਦੀ ਪਹੁੰਚ (access) ਨਹੀਂ ਦਿੰਦੇ। ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸਟੇਜਿੰਗ ਵਾਤਾਵਰਣ, ਸਿਰਫ਼ ਪੜ੍ਹਨ ਵਾਲੀ (read-only) ਪਹੁੰਚ ਅਤੇ ਨਿਗਰਾਨੀ ਵਾਲੇ ਕੰਮ ਦਿੰਦੇ ਹੋ। ਏਜੰਟਾਂ ਨੂੰ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਦੀ ਓਨਬੋਰਡਿੰਗ (onboarding) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਉਹ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਹਜ਼ਾਰਾਂ ਕਾਰਵਾਈਆਂ ਕਰ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਪਲੇਗਰਾਊਂਡ ਨੂੰ ਛੱਡਣ ਦੀ ਕੀਮਤ ਹਜ਼ਾਰ ਗੁਣਾ ਜ਼ਿਆਦਾ ਹੋ ਸਕਦੀ ਹੈ।

ਇੱਕ ਅਸਲੀ ਪਲੇਗਰਾਊਂਡ ਨੂੰ ਤਿੰਨ ਕੰਮ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ:

  • ਏਜੰਟ ਨੂੰ ਉਸਦੇ ਪੂਰੇ ਡੈਸੀਜ਼ਨ ਲੂਪ (decision loop) ਨੂੰ ਚਲਾਉਣ ਦਿਓ।
  • ਸਾਰੇ ਸਾਈਡ ਇਫੈਕਟਸ (side effects) ਨੂੰ ਅਸਲ ਸਿਸਟਮਾਂ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਰੋਕੋ।
  • ਜਾਂਚ ਲਈ ਸਭ ਕੁਝ ਰਿਕਾਰਡ ਕਰੋ।

ਸਿਰਫ਼ ਪ੍ਰੋਂਪਟ (prompt) ਦਾ ਟੈਸਟ ਨਾ ਕਰੋ। ਪ੍ਰੋਂਪਟ ਦਾ ਟੈਸਟ ਕਰਨ ਦਾ ਮਤਲਬ ਹੈ ਇੱਕ ਸਵਾਲ ਪੁੱਛਣਾ ਅਤੇ ਜਵਾਬ ਪੜ੍ਹਨਾ। ਇੱਕ ਏਜੰਟ ਦਾ ਵਿਵਹਾਰ ਟੂਲ ਕਾਲਜ਼ (tool calls) ਦੀ ਇੱਕ ਲੜੀ ਹੁੰਦਾ ਹੈ। ਅਸਲੀ ਅਸਫਲਤਾਵਾਂ ਲੂਪ ਦੇ ਵਿਚਕਾਰ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਕੋਈ ਟੂਲ ਅਣਕਿਆਸੇ ਡੇਟਾ ਵਾਪਸ ਕਰਦਾ ਹੈ।

ਤੁਹਾਨੂੰ ਮਾਡਲ ਨੂੰ ਸੈਂਡਬਾਕਸ (sandbox) ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਐਗਜ਼ੀਕਿਊਟਰ (executor) ਨੂੰ ਸੈਂਡਬਾਕਸ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਇੱਕ ਅਜਿਹੀ ਸੀਮ (seam) ਬਣਾਓ ਜਿੱਥੇ ਟੂਲ ਕਾਲਜ਼ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਬਦਲਦੇ ਹਨ। ਇੱਕ ਅਜਿਹਾ ਪਲੇਗਰਾਊਂਡ ਐਗਜ਼ੀਕਿਊਟਰ ਵਰਤੋ ਜੋ ਲਾਈਵ ਐਗਜ਼ੀਕਿਊਟਰ ਦੀ ਬਜਾਏ ਮੌਕਸ (mocks) ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੋਵੇ। ਏਜੰਟ ਲੂਪ ਨੂੰ ਇਸ ਅੰਤਰ ਦਾ ਪਤਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਜੇਕਰ ਤੁਹਾਡਾ ਏਜੰਟ ਸਿੱਧਾ ਡਾਟਾਬੇਸ ਕਲਾਇੰਟ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਸੀਮ ਅਤੇ ਕੋਈ ਸੁਰੱਖਿਆ ਨਹੀਂ ਹੈ।

ਤਿੰਨ ਖਾਸ ਖੇਤਰਾਂ ਦਾ ਟੈਸਟ ਕਰੋ:

  • ਵਿਵਹਾਰ (Behavior): ਕੀ ਏਜੰਟ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਸਹੀ ਟੂਲ ਚੁਣਦਾ ਹੈ?
  • ਟੂਲ ਕਾਲਜ਼ (Tool calls): ਕੀ ਆਰਗੂਮੈਂਟਸ ਸਹੀ ਹਨ ਅਤੇ ਸੁਰੱਖਿਅਤ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਹਨ?
  • ਅਸਫਲਤਾ ਦੇ ਮੋਡ (Failure modes): ਜਦੋਂ ਕੋਈ API ਟਾਈਮ ਆਊਟ ਹੋ ਜਾਂਦਾ ਹੈ ਜਾਂ ਗਲਤ ਡੇਟਾ ਵਾਪਸ ਕਰਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

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

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

ਯਾਦ ਰੱਖੋ ਕਿ ਏਜੰਟ ਨਾਨ-ਡਿਟਰਮਿਨਿਸਟਿਕ (non-deterministic) ਹੁੰਦੇ ਹਨ। ਇੱਕ ਟੈਸਟ ਜੋ ਇੱਕ ਵਾਰ ਪਾਸ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਏਜੰਟ ਭਰੋਸੇਯੋਗ ਹੈ। ਤੁਹਾਨੂੰ ਇੱਕੋ ਕੰਮ ਨੂੰ ਕਈ ਵਾਰ ਚਲਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਏਜੰਟ 10 ਵਿੱਚੋਂ 7 ਵਾਰ ਪਾਸ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਤੁਹਾਡੇ ਲਗਭਗ 30% ਅਸਲ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਅਸਫਲ ਹੋਵੇਗਾ। ਇਕਸਾਰਤਾ (Consistency) ਤੁਹਾਡਾ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਮਾਪਦੰਡ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਵਿਰੋਧੀ ਟੂਲ ਆਊਟਪੁੱਟ (adversarial tool outputs) ਤੋਂ ਬਚਾਅ ਕਰੋ। ਇੱਕ ਏਜੰਟ ਟੂਲ ਡੇਟਾ ਨੂੰ ਹਦਾਇਤਾਂ ਵਜੋਂ ਲੈਂਦਾ ਹੈ। ਇੱਕ ਮਾੜਾ ਯੂਜ਼ਰ ਏਜੰਟ ਨੂੰ ਗੁਆਚਾਉਣ ਲਈ ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ (prompt injection) ਨਾਲ ਡਾਟਾਬੇਸ ਵਿੱਚ ਗਲਤ ਡੇਟਾ ਭਰ ਸਕਦਾ ਹੈ। ਪਲੇਗਰਾਊਂਡ ਵਿੱਚ ਹਾਸਲ (hostile) ਪੇਲੋਡ (payloads) ਦੇ ਕੇ ਆਪਣੇ ਏਜੰਟ ਦਾ ਟੈਸਟ ਕਰੋ।

ਇੱਕ ਗ੍ਰੈਜੂਏਸ਼ਨ ਪਾਥ (graduation path) ਬਣਾਓ, ਲਾਂਚ ਬਟਨ ਨਹੀਂ:

  • ਮੌਕਸ (mocks) ਅਤੇ ਪੂਰੇ ਸੈਂਡਬਾਕਸਿੰਗ (sandboxing) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।
  • ਕਈ ਰਨਾਂ ਵਿੱਚ ਇਕਸਾਰਤਾ ਲਈ ਟੈਸਟ ਕਰੋ।
  • ਵਿਰੋਧੀ ਇਨਪੁੱਟਸ (adversarial inputs) ਦੇ ਵਿਰੁੱਧ ਟੈਸਟ ਕਰੋ।
  • ਪ੍ਰੋਡਕਸ਼ਨ ਵਰਗੇ ਡੇਟਾ ਦੇ ਵਿਰੁੱਧ ਡ੍ਰਾਈ-ਰਨ (dry-run) ਮੋਡ ਵੱਲ ਵਧੋ।
  • ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਸੀਮਤ, ਗੇਟਡ ਅਤੇ ਨਿਗਰਾਨੀ ਵਾਲੀ ਪਹੁੰਚ ਦਿਓ।

ਆਪਣੇ ਏਜੰਟ ਨੂੰ ਸਸਤੇ ਵਿੱਚ ਗਲਤ ਹੋਣ ਲਈ ਇੱਕ ਜਗ੍ਹਾ ਦਿਓ। ਫਿਰ ਇਹ ਉੱਥੇ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ।

Source: https://dev.to/nazar_boyko/building-an-ai-agent-playground-before-giving-it-production-access-4glh

Optional learning community: https://t.me/GyaanSetuAi