ਆਟੋਮੇਟਡ ਵਰਕਫਲੋਜ਼ ਵਿੱਚ LLM ਈਮੇਲਾਂ ਨੂੰ ਅਲੱਗ ਕਰਨਾ

ਜਦੋਂ ਇੱਕ LLM ਏਜੰਟ ਈਮੇਲਾਂ ਭੇਜਣਾ ਜਾਂ ਟਿਕਟਾਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਹੁਣ ਇਹ ਸਿਰਫ਼ ਇਸ ਬਾਰੇ ਨਹੀਂ ਰਿਹਾ ਕਿ ਤੁਹਾਡਾ ਪ੍ਰੋਂਪਟ (prompt) ਕੰਮ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਹੁਣ, ਤੁਹਾਡਾ ਸਿਸਟਮ ਤਿੰਨ ਪਰਤਾਂ (layers) 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ: ਫੈਸਲਾ (decision), ਅਮਲ (execution), ਅਤੇ ਤਸਦੀਕ (verification)।

ਜੇਕਰ ਤੁਸੀਂ ਇਹਨਾਂ ਪਰਤਾਂ ਨੂੰ ਮਿਲਾ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਇਹ ਸਮਝਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਆਵੇਗੀ ਕਿ ਏਜੰਟ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਕੀਤਾ ਸੀ।

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

ਇੱਕ ਸਥਿਰ ਡਿਜ਼ਾਈਨ ਇਕੱਠੇ ਸਾਰੀ ਬੁੱਧੀ (intelligence) ਦਾ ਟੈਸਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਦੀ ਬਜਾਏ, ਆਪਣੇ ਸਿਸਟਮ ਨੂੰ ਛੋਟੇ ਕੰਟਰੈਕਟਾਂ (contracts) ਵਿੱਚ ਵੰਡੋ:

  • ਇਨਪੁਟ ਕੰਟਰੈਕਟ (Input Contract): ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਏਜੰਟ ਕਿਹੜਾ ਡੇਟਾ ਵਰਤਦਾ ਹੈ ਅਤੇ ਉਹ ਕਿਹੜੇ ਕਾਰਜਾਂ ਦੀ ਬੇਨਤੀ ਕਰ ਸਕਦਾ ਹੈ।
  • ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਕੰਟਰੈਕਟ (Execution Contract): ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਇੱਕ ਕਾਰਜ ਕਿਸੇ ਖਾਸ ਈਮੇਲ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ।
  • ਆਬਜ਼ਰਵੇਬਿਲਟੀ ਕੰਟਰੈਕਟ (Observability Contract): ਲੌਗਸ (logs), ਪ੍ਰਾਪਤ ਕੀਤੇ ਸੰਦੇਸ਼ਾਂ ਅਤੇ ਸਿਸਟਮ ਦੀ ਅੰਤਿਮ ਸਥਿਤੀ ਨੂੰ ਜੋੜੋ।

ਈਮੇਲ ਲੌਜਿਕ ਨੂੰ ਫ੍ਰੀ ਪ੍ਰੋਂਪਟ (free prompt) ਤੋਂ ਬਾਹਰ ਰੱਖੋ। LLM "send_followup_email" ਵਰਗੇ ਕਾਰਜ ਦਾ ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਮਾਡਲ ਨੂੰ ਹੈਡਰ (headers), ਪ੍ਰਾਪਤਕਰਤਾ (recipients), ਜਾਂ ਰੀਟ੍ਰਾਈ ਪਾਲਿਸੀਆਂ (retry policies) ਦਾ ਫੈਸਲਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਲਈ ਡਿਟਰਮਿਨਿਸਟਿਕ ਕੋਡ (deterministic code) ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਇਹ ਪਹੁੰਚ ਸੰਚਾਲਨ ਜੋਖਮ (operational risk) ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ। LLM ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ, ਸਿਸਟਮ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਐਗਜ਼ੀਕਿਊਟਰ ਭੇਜਦਾ ਹੈ।

ਸਪਸ਼ਟ ਦਿੱਖ ਬਣਾਈ ਰੱਖਣ ਲਈ, ਇਹਨਾਂ ਚਾਰ ਸੰਕੇਤਾਂ (signals) 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ:

  • ਏਜੰਟ ਦੁਆਰਾ ਲਿਆ ਗਿਆ ਫੈਸਲਾ ਅਤੇ ਵਰਤਿਆ ਗਿਆ ਸੰਦਰਭ (context)।
  • ਈਮੇਲ ਐਗਜ਼ੀਕਿਊਟਰ ਨੂੰ ਭੇਜੀ ਗਈ ਅੰਤਿਮ ਕਮਾਂਡ।
  • ਇੱਕ ਅਲੱਗ ਇਨਬਾਕਸ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਸੰਦੇਸ਼।
  • ਕਿਸੇ ਲਿੰਕ 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਜਾਂ ਕਿਸੇ ਕਾਰਜ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਬਾਅਦ ਅੰਤਿਮ ਪ੍ਰਭਾਵ।

ਸ਼ੁਰੂਆਤੀ ਘਟਨਾ ਤੋਂ ਲੈ ਕੇ ਅੰਤਿਮ ਕਲਿੱਕ ਤੱਕ ਇੱਕ ਸਾਂਝਾ trace_id ਵਰਤੋ। ਇਹ ਤੁਹਾਨੂੰ ਗਲਤੀਆਂ ਨੂੰ ਜਲਦੀ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗ ਜਾਵੇਗਾ ਕਿ ਅਸਫਲਤਾ ਮਾਡਲ, ਟੂਲ ਪਾਲਿਸੀ, ਜਾਂ ਵਰਕਰ ਵਿੱਚ ਹੋਈ ਹੈ।

ਬਿਹਤਰ ਆਟੋਮੇਸ਼ਨ ਲਈ ਇਸ ਚੈੱਕਲਿਸਟ ਦੀ ਪਾਲਣਾ ਕਰੋ:

  • ਹਰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦਾ ਆਪਣਾ trace_id ਹੁੰਦਾ ਹੈ।
  • LLM ਸਿਰਫ਼ ਇੱਕ ਵੈਧ ਸਕੀਮਾ (valid schema) ਦੇ ਅੰਦਰ ਹੀ ਕਾਰਜਾਂ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ।
  • ਈਮੇਲ ਐਗਜ਼ੀਕਿਊਟਰ ਪ੍ਰਾਪਤਕਰਤਾ ਅਤੇ ਟੈਂਪਲੇਟ ਦੀ ਮੁੜ-ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ।
  • ਹਰ ਟੈਸਟ ਸਥਿਤੀ (scenario) ਆਪਣੇ ਅਲੱਗ ਇਨਬਾਕਸ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ।
  • ਅੰਤਿਮ ਕਲਿੱਕ ਉਮੀਦ ਕੀਤੇ ਸਟੇਟ ਚੇਂਜ (state change) ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ।
  • ਲੌਗਸ ਤੁਹਾਨੂੰ ਅੰਦਾਜ਼ਾ ਲਗਾਏ ਬਿਨਾਂ ਕੇਸ ਦੀ ਪਾਲਣਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ।

ਇਹਨਾਂ ਕਦਮਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਨਾਲ ਥੋੜ੍ਹਾ ਹੋਰ ਕੰਮ ਵਧ ਜਾਂਦਾ ਹੈ। ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਕੁਝ ਕੀਮਤੀ ਦਿੰਦਾ ਹੈ: ਇਹ ਦੱਸਣ ਦੀ ਯੋਗਤਾ ਕਿ ਈਮੇਲ ਕਿਉਂ ਭੇਜੀ ਗਈ ਸੀ ਜਾਂ ਇਹ ਕਿਉਂ ਅਸਫਲ ਰਹੀ।

ਸਰੋਤ: https://dev.to/silviutech/como-aislar-emails-de-agentes-llm-en-flujos-automatizados-sin-perder-trazabilidad-26ac

ਵਿਕਲਪਿਕ ਸਿੱਖਣ ਭਾਈਚਾਰਾ: https://t.me/GyaanSetuAi