ਤੁਹਾਡੀ CI ਪਾਸ ਹੋ ਗਈ। ਤੁਹਾਡਾ Agent ਅਜੇ Operator-Ready ਨਹੀਂ ਹੈ

ਅਸੀਂ ਪਿਛਲੀ ਤਿਮਾਹੀ ਵਿੱਚ ਇੱਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ document agent ਭੇਜਿਆ ਸੀ।

ਸਾਡੇ test suite ਨੇ 94% pass rate ਦਿਖਾਇਆ।

ਪਾਇਲਟ ਦੇ ਤਿੰਨ ਹਫ਼ਤਿਆਂ ਬਾਅਦ, agent ਨੇ ਉਹਨਾਂ invoices ਲਈ refunds ਦੇਣੇ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹ ਪੜ੍ਹ ਨਹੀਂ ਸਕਿਆ। ਇਸਨੇ ਇਹ ਚੁੱਪਚਾਪ ਕੀਤਾ। ਕੋਈ error ਜਾਂ logs ਨਹੀਂ ਸਨ। Agent ਨੇ ਸਿਰਫ਼ ਗਲਤ ਜਵਾਬ ਦਿੱਤੇ ਜੋ ਦੇਖਣ ਵਿੱਚ ਸਹੀ ਲੱਗ ਰਹੇ ਸਨ।

ਸਾਡੀ CI ਪੂਰੇ ਸਮੇਂ 'green' ਰਹੀ।

ਸਮੱਸਿਆ model ਜਾਂ prompt ਦੀ ਨਹੀਂ ਸੀ। ਸਮੱਸਿਆ ਉਸ 6% ਡੇਟਾ ਦੀ ਸੀ ਜਿਸਦਾ ਅਸੀਂ ਟੈਸਟ ਨਹੀਂ ਕੀਤਾ ਸੀ। ਉਹ 6% ਡੇਟਾ operator ਤੋਂ ਆਉਣ ਵਾਲਾ ਪਹਿਲਾ ਅਸਲੀ ਡੇਟਾ ਸੀ।

ਇਹ ਕੋਈ edge case ਨਹੀਂ ਹੈ। ਇਹ operator-ready ਹੋਣ ਦੀ ਪਰਿਭਾਸ਼ਾ ਹੈ।

Production-ready ਬਾਰੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ (infrastructure) ਦੀ ਗੱਲ ਕਰਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੀ ਸੇਵਾ ਚੱਲਦੀ ਰਹੇ ਅਤੇ ਲੋਡ ਨੂੰ ਸੰਭਾਲ ਸਕੇ।

Operator-ready ਵੱਖਰਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ agent ਉਸ ਵਿਅਕਤੀ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਜਿਸਨੇ ਇਸਨੂੰ ਨਹੀਂ ਬਣਾਇਆ। ਇਹ ਉਸ ਡੇਟਾ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਕੀਤਾ। ਇਹ ਅਸਲ ਨਤੀਜਿਆਂ ਵਾਲੇ ਫੈਸਲੇ ਲੈਂਦਾ ਹੈ।

ਜ਼ਿਆਦਾਤਰ test pipelines ਉਸ ਸੈੱਟ 'ਤੇ pass rate ਮਾਪਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਬਣਾਇਆ ਹੁੰਦਾ ਹੈ। ਉਹ ਇਹ ਨਹੀਂ ਮਾਪਦੇ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਅਸਲੀ ਡੇਟਾ ਤੁਹਾਡੇ test set ਤੋਂ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ।

97% validation success ਵਾਲਾ model ਸੁਣਨ ਵਿੱਚ ਚੰਗਾ ਲੱਗਦਾ ਹੈ। ਪਰ ਉਸ 3% ਨੂੰ ਦੇਖੋ ਜੋ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ।

ਜੇਕਰ ਤੁਹਾਡਾ agent retry ਦੌਰਾਨ ਗੁੰਮ ਹੋਏ ਖੇਤਰਾਂ (fields) ਨੂੰ default values ਨਾਲ ਭਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਚੁੱਪਚਾਪ ਗਲਤੀ ਕਰਨ ਵਾਲੀ ਮਸ਼ੀਨ ਬਣਾਈ ਹੈ। Schema ਪਾਸ ਹੋ ਜਾਂਦਾ ਹੈ, ਪਰ ਡੇਟਾ ਗਲਤ ਹੁੰਦਾ ਹੈ।

ਇਸਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, schema validity ਨੂੰ content confidence ਤੋਂ ਵੱਖ ਕਰੋ।

ਅਸੀਂ ਹਰ ਜਵਾਬ (response) ਵਿੱਚ ਇੱਕ confidence score ਜੋੜ ਦਿੱਤਾ। ਹੁਣ ਘੱਟ confidence ਹੋਣ 'ਤੇ retry ਕਰਨ ਦੀ ਬਜਾਏ ਮਨੁੱਖੀ ਸਮੀਖਿਆ (human review) ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਸ ਬਦਲਾਅ ਨੇ ਸਾਡੀਆਂ ਪਹਿਲੀਆਂ 18 ਘਟਨਾਵਾਂ ਵਿੱਚੋਂ 14 ਨੂੰ ਫੜ ਲਿਆ।

ਤੁਹਾਡਾ test set ਉਹ ਕਵਰ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸੋਚਿਆ ਸੀ। Operator ਦਾ ਡੇਟਾ ਉਹ ਕਵਰ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਤੋਂ ਰਹਿ ਗਿਆ ਸੀ।

ਸਾਡੇ ਮਾਮਲੇ ਵਿੱਚ, ਅਸੀਂ ਸਿੰਗਲ-ਪੇਜ ਇਨਵੌਇਸਾਂ (invoices) ਦਾ ਟੈਸਟ ਕੀਤਾ ਸੀ। Operator ਨੇ ਸਕੈਨ ਕੀਤੇ ਹੋਏ PDFs ਵਾਲੇ ਮਲਟੀ-ਪੇਜ ਇਨਵੌਇਸਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। Agent ਨਵੇਂ ਫਾਰਮੈਟ 'ਤੇ ਫੇਲ ਹੋ ਗਿਆ।

ਸਿਰਫ਼ parser ਨੂੰ ਠੀਕ ਨਾ ਕਰੋ। ਲਾਈਵ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲੀ operator ਦੇ ਡੇਟਾ ਦੇ ਵਿਰੁੱਧ ਟੈਸਟ ਕਰੋ।

ਕਿਸੇ ਵੀ ਹੈਂਡਓਵਰ (handoff) ਤੋਂ ਪਹਿਲਾਂ, ਹੁਣ ਅਸੀਂ operator ਦੇ ਆਪਣੇ ਡੇਟਾ ਤੋਂ 50 ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਮੰਗ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ synthetic data ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ। ਅਸੀਂ ਉਹਨਾਂ ਦਾ ਡੇਟਾ ਵਰਤਦੇ ਹਾਂ।

ਤੁਹਾਨੂੰ ਇੱਕ ਮੁਕੰਮਲ audit trail ਦੀ ਵੀ ਲੋੜ ਹੈ। ਸਿਰਫ਼ ਇਹ log ਨਾ ਕਰੋ ਕਿ model ਨੇ ਕੀ ਵਾਪਸ ਦਿੱਤਾ। ਇਹ ਵੀ log ਕਰੋ ਕਿ model ਨੇ ਕੀ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ।

ਇੱਕ ਘੱਟੋ-ਘੱਟ audit trail ਲਈ ਲੋੜ ਹੈ:

  • field-level confidence scores ਦੇ ਨਾਲ output
  • ਇੱਕ fallback indicator ਜੋ ਦਿਖਾਵੇ ਕਿ ਕੀ agent ਨੇ retry ਕੀਤਾ ਸੀ
  • ਸਹੀ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ (replay) ਲਈ ਇੱਕ input hash
  • ਵਰਤਿਆ ਗਿਆ ਖਾਸ model ਅਤੇ prompt version

ਇੱਕ agent ਨੂੰ operator ਨੂੰ ਸੌਂਪਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹਨਾਂ ਪੰਜ ਚੀਜ਼ਾਂ ਦੀ ਜਾਂਚ ਕਰੋ:

  • Operator ਦੇ ਅਸਲੀ ਡੇਟਾ ਤੋਂ 50+ ਸੈਂਪਲ ਚਲਾਓ।
  • ਉਹਨਾਂ outputs ਲਈ logs ਵਿੱਚ ਖੋਜ ਕਰੋ ਜੋ schema ਚੈੱਕਾਂ ਵਿੱਚੋਂ ਲੰਘ ਗਏ ਪਰ downstream errors ਦਾ ਕਾਰਨ ਬਣੇ।
  • ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ agent ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੋ ਜਾਵੇ, ਗਲਤ (malformed) inputs ਦਿਓ।
  • ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ 5 ਮਿੰਟਾਂ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਇੱਕ ਖਾਸ ਦਸਤਾਵੇਜ਼ ਨਾਲ ਕੀ ਹੋਇਆ ਸੀ।
  • ਚੈੱਕ ਕਰੋ ਕਿ agent ਕੋਲ ਘੱਟੋ-ਘੱਟ ਸੰਭਵ permissions ਹਨ।

ਸਾਡਾ test pass rate 94% ਸੀ। ਪਹਿਲੇ ਮਹੀਨੇ ਵਿੱਚ ਸਾਡੀ error rate 8% ਸੀ।

ਜਦੋਂ ਅਸੀਂ confidence scores, ਅਸਲ-ਦੁਨੀਆ ਦੀ ਟੈਸਟਿੰਗ, ਅਤੇ ਬਿਹਤਰ logs ਜੋੜੇ, ਤਾਂ error rate ਘਟ ਕੇ 1.4% ਰਹਿ ਗਈ।

ਟੈਸਟ ਸਕੋਰ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ। ਟੈਸਟ ਦਾ ਦਾਇਰਾ (scope) ਸਮੱਸਿਆ ਸੀ।

Source: https://dev.to/ethanwritesai/our-ci-passed-your-agent-isnt-operator-ready-2mfn

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