ਹਰ ਪ੍ਰੋਡਕਟ ਰੋਡਮੈਪ ਵਿੱਚ ਇੱਕ ਬੁਲੇਟ ਪੁਆਇੰਟ ਹੁੰਦਾ ਹੈ ਜੋ "AI Agent" ਕਹਿੰਦਾ ਹੈ। ਇਹ ਸ਼ਬਦ ਤਰੱਕੀ ਵਾਂਗ ਲੱਗਦਾ ਹੈ। ਇਹ ਲੀਡਰਸ਼ਿਪ ਨੂੰ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਟੀਮ ਭਵਿੱਖ ਬਣਾ ਰਹੀ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਵਰਤਮਾਨ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖ ਰਹੀ ਹੈ। ਪਰ ਇੱਥੇ ਉਹ ਅਸਾਧਾਰਨ ਸੱਚਾਈ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਡੈਮੋ ਵੀਡੀਓਜ਼ ਤੁਹਾਨੂੰ ਨਹੀਂ ਦਿਖਾਉਂਦੀਆਂ: ਇੱਕ ਏਜੰਟ ਕਿਸੇ ਕੰਮ ਨੂੰ ਖਤਮ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਮਹਿੰਗਾ ਅਤੇ ਸਭ ਤੋਂ ਘੱਟ ਭਵਿੱਖਬਾਣੀਯੋਗ ਤਰੀਕਾ ਹੈ। ਬਹੁਤੇ ਵਪਾਰਕ ਕੰਮਾਂ ਲਈ, ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗਲਤ ਸਾਧਨ ਹੈ। ਸਭ ਤੋਂ ਵਧੀਆ ਇੰਜੀਨੀਅਰ ਉਹ ਨਹੀਂ ਹਨ ਜੋ ਇੱਕ ਬਣਾਉਣ ਲਈ ਕਾਹਲੀ ਕਰਦੇ ਹਨ। ਉਹ ਉਹ ਹਨ ਜੋ ਜਾਣਦੇ ਹਨ ਕਿ ਕਦੋਂ ਰੁਕਣਾ ਹੈ।
ਕਲਾਸੀਫਿਕੇਸ਼ਨ ਦਾ ਜਾਲ (The Classification Trap)
ਕਿਸੇ ਟੀਮ ਨੂੰ ਆਪਣਾ ਪਹਿਲਾ ਏਜੰਟ ਤਿਆਰ ਕਰਦੇ ਹੋਏ ਦੇਖੋ, ਅਤੇ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਅਜਿਹਾ ਦੇਖੋਗੇ। ਇੱਕ ਸਪੋਰਟ ਈਮੇਲ ਆਉਂਦੀ ਹੈ। ਇੱਕ Large Language Model ਵਿਸ਼ੇ (subject) ਅਤੇ ਬਾਡੀ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਬਿਲਿੰਗ ਦਾ ਸਵਾਲ ਹੈ ਜਾਂ ਕੋਈ ਤਕਨੀਕੀ ਬੱਗ (technical bug), ਅਤੇ ਇਸਨੂੰ ਸਹੀ ਕਿਊ (queue) ਵਿੱਚ ਪਾ ਦਿੰਦਾ ਹੈ। ਟੀਮ ਇਸਨੂੰ ਇੱਕ ਏਜੰਟ ਕਹਿੰਦੀ ਹੈ। ਇਹ ਨਹੀਂ ਹੈ।
ਉਨ੍ਹਾਂ ਨੇ ਜੋ ਬਣਾਇਆ ਹੈ ਉਹ ਇੱਕ ਡਿਟਰਮਨਿਸਟਿਕ ਫਲੋ (deterministic flow) ਹੈ ਜਿਸ ਦੇ ਅੰਦਰ ਇੱਕ ਸਿੰਗਲ ਮਾਡਲ ਕਾਲ ਹੈ। ਕਦਮ ਨਿਸ਼ਚਿਤ ਹਨ: ਈਮੇਲ ਪ੍ਰਾਪਤ ਕਰੋ, ਮਾਡਲ ਨੂੰ ਕਾਲ ਕਰੋ, ਕਿਊ ਵਿੱਚ ਰੂਟ ਕਰੋ। ਇਸ ਵਿੱਚ ਕੋਈ ਲੂਪ (loop) ਨਹੀਂ ਹੈ, ਕੋਈ ਟੂਲ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਹੈ, ਕੋਈ ਅਜਿਹਾ ਪਲ ਨਹੀਂ ਹੈ ਜਿੱਥੇ ਸਿਸਟਮ ਆਪਣੀ ਯੋਜਨਾ 'ਤੇ ਮੁੜ ਵਿਚਾਰ ਕਰਨ ਲਈ ਰੁਕਦਾ ਹੈ ਕਿਉਂਕਿ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਅਸਫਲ ਰਹੀ ਸੀ। ਇਹ ਕੋਈ ਗਿਆਨ ਅਧਾਰ (knowledge base) ਨਹੀਂ ਸਰੋਥਦਾ, ਕੋਡ ਨਹੀਂ ਲਿਖਦਾ, ਜਾਂ ਰਸਤੇ ਵਿੱਚ ਆਰਡਰ ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਇੱਕ ਫੈਸਲਾ ਲੈਂਦਾ ਹੈ ਅਤੇ ਅੱਗੇ ਵਧ ਜਾਂਦਾ ਹੈ। ਉਸ ਸਿੰਗਲ ਕਾਲ ਨੂੰ ਮਾਈਕਰੋਸਰਵਿਸ (microservice) ਵਿੱਚ ਲਪੇਟਣ ਨਾਲ ਇਹ ਏਜੰਟ ਨਹੀਂ ਬਣ ਜਾਂਦਾ।
ਇੱਕ ਫਲੋ ਨੂੰ ਏਜੰਟ ਸਮਝਣ ਦੀ ਅਸਲ ਕੀਮਤ ਸਿਰਫ਼ ਵਾਧੂ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਨਾਨ-ਡਿਟਰਮਨਿਸਮ (non-determinism) ਹੈ ਜੋ ਤੁਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਫਾਇਦੇ ਦੇ ਬੁਲਾ ਲਿਆ ਹੈ। ਉਹੀ ਈਮੇਲ ਮੰਗਲਵਾਰ ਸਵੇਰ ਦੇ ਮੁਕਾਬਲੇ ਬੁੱਧਵਾਰ ਦੁਪਹਿਰ ਨੂੰ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਰੂਟ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਟੈਂਪਰੇਚਰ (temperature) ਜ਼ੀਰੋ ਨਹੀਂ ਹੈ ਜਾਂ ਪ੍ਰੋਂਪਟ (prompt) ਬਦਲ ਗਿਆ ਹੈ। ਤੁਸੀਂ ਲੇਟੈਂਸੀ (latency), ਟੋਕਨ ਲਾਗਤ, ਅਤੇ ਇਵੈਲੂਏਸ਼ਨ ਓਵਰਹੈੱਡ ਲਈ ਏਜੰਟ ਵਾਲੀਆਂ ਕੀਮਤਾਂ ਅਦਾ ਕਰਦੇ ਹੋ, ਜਦੋਂ ਕਿ ਇੱਕ ਕਲਾਸੀਫਿਕੇਸ਼ਨ ਸਟੈਪ ਵਾਲਾ ਫਲੋ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਸਸਤੇ ਵਿੱਚ ਹੱਲ ਕਰ ਦਿੰਦਾ ਹੈ।
ਲੜੀ ਦੇ ਹੇਠਲੇ ਪੱਧਰ ਤੋਂ ਕੰਮ ਸ਼ੁਰੂ ਕਰੋ
ਜ਼ਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਦੇ ਸਰਲ ਰੂਪ ਹੁੰਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਨੂੰ ਉਨੀ ਹੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਦੇ ਹਨ। ਇਸਨੂੰ ਇੱਕ ਲੜੀ ਵਾਂਗ ਸਮਝੋ, ਅਤੇ ਹੇਠਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ।
ਪ੍ਰਕਿਰਿਆ (Process) ਨੂੰ ਠੀਕ ਕਰੋ। ਕਈ ਵਾਰ ਕੰਮ ਸਿਰਫ਼ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਦੋ ਸਿਸਟਮ ਅਸਹਿਮਤ ਹੁੰਦੇ ਹਨ। ਤੁਹਾਡੇ CRM ਵਿੱਚ ਇੱਕ ਗਾਹਕ ਰਿਕਾਰਡ ਤੁਹਾਡੇ ਟਿਕਟਿੰਗ ਪਲੇਟਫਾਰਮ ਨਾਲ ਸਿੰਕ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਹਰ ਸਵੇਰ ਇੱਕ ਇਨਸਾਨ ਨੂੰ ਮੈਨੂਅਲੀ ਇਸ ਪਾੜੇ ਨੂੰ ਭਰਨਾ ਪੈਂਦਾ ਹੈ। ਉਸ ਪਾੜੇ ਨੂੰ ਏਜੰਟ ਨਾਲ ਆਟੋਮੇਟ ਨਾ ਕਰੋ। ਇਸਨੂੰ ਖਤਮ ਕਰੋ। ਜੇਕਰ ਡਾਟਾ ਪਾਈਪਲਾਈਨ ਸਹੀ ਹੁੰਦੀ, ਤਾਂ ਇਹ ਕੰਮ ਖਤਮ ਹੋ ਜਾਂਦਾ।
ਕੁਐਰੀ (Query) ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਜਵਾਬ ਇੱਕ ਸਧਾਰਨ ਲੁੱਕਅੱਪ ਜਾਂ ਐਗਰੀਗੇਸ਼ਨ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਲਵੋ। "ਪਿਛਲੇ ਮੰਗਲਵਾਰ ਅਸੀਂ ਕਿੰਨੇ ਰਿਫੰਡ ਪ੍ਰੋਸੈਸ ਕੀਤੇ?" ਲਈ ਤਰਕ (reasoning) ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ SQL ਦੀ ਲੋੜ ਹੈ। ਇੱਕ ਏਜੰਟ ਜੋ ਕੁਦਰਤੀ ਭਾਸ਼ਾ (natural language) ਨੂੰ SQL ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਸੁਣਨ ਵਿੱਚ ਵਧੀਆ ਲੱਗਦਾ ਹੈ, ਪਰ ਫਿਰ ਤੁਹਾਨੂੰ ਅਹਿਸਾਸ ਹੁੰਦਾ ਹੈ ਕਿ ਇਸਦੀ ਰੱਖ-ਰਖਾਅ ਦਾ ਬੋਝ ਉਨ੍ਹਾਂ ਤਿੰਨ ਦਸਤਾਵੇਜ਼ੀ ਕੁਐਰੀਆਂ ਨੂੰ ਲਿਖਣ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਚਲਾਉਂਦੀ ਹੈ।
ਇੱਕ ਡਿਟਰਮਨਿਸਟਿਕ ਫਲੋ ਬਣਾਓ। ਜਦੋਂ ਨਿਯਮ ਨਿਸ਼ਚਿਤ ਹੁੰਦੇ ਹਨ ਅਤੇ ਨਤੀਜਾ ਦੁਹਰਾਉਣਯੋਗ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਪੱਸ਼ਟ ਲੌਜਿਕ (logic) ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਆਰਡਰ ਦੀ ਕੀਮਤ ਇੱਕ ਸੀਮਾ ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਫਾਈਨੈਂਸ ਨੂੰ ਭੇਜੋ। ਜੇਕਰ ਕੋਈ ਯੂਜ਼ਰ ਤਿਰਤੀ ਦਿਨਾਂ ਲਈ ਗੈਰ-ਸਰਗਰਮ ਹੈ, ਤਾਂ ਰੀ-ਇੰਗੇਜਮੈਂਟ ਈਮੇਲ ਭੇਜੋ। ਕੋਡ ਇਸਨੂੰ ਜ਼ੀਰੋ ਵੇਰੀਐਂਸ (variance) ਅਤੇ ਪੂਰੀ ਦੇਖ ਰੱਖ (observability) ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਦਾ ਯੂਨਿਟ-ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਕਿਸੇ 'ਵਾਈਬ' (vibe) ਦਾ ਯੂਨਿਟ-ਟੈਸਟ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਇੱਕ ਮਾਡਲ ਕਾਲ ਵਾਲੇ ਫਲੋ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਹ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਕਲਾਸੀਫਿਕੇਸ਼ਨ, ਸੈਂਟੀਮੈਂਟ ਟੈਗਿੰਗ, ਜਾਂ ਡਾਟਾ ਐਕਸਟਰੈਕਸ਼ਨ ਹੁੰਦਾ ਹੈ। ਮਾਡਲ ਇੱਕ ਸਖ਼ਤ ਸਕ੍ਰਿਪਟ ਦੇ ਅੰਦਰ ਇੱਕ ਸਿੰਗਲ ਫੈਸਲਾ ਲੈਂਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਇਨਵੌਇਸ ਨੰਬਰ ਕੱਢਦੇ ਹੋ, ਅਤੇ ਇਸਨੂੰ ਡਾਟਾਬੇਸ ਵਿੱਚ ਲਿਖਦੇ ਹੋ। ਆਲੇ-ਦੁਆਲੇ ਦੇ ਕਦਮ ਹਾਰਡਕੋਡਡ (hardcoded) ਹੁੰਦੇ ਹਨ। ਮਾਡਲ ਇਹ ਨਹੀਂ ਚੁਣਦਾ ਕਿ ਅੱਗੇ ਕੀ ਕਰਨਾ ਹੈ; ਇਹ ਸਿਰਫ਼ ਉਸਨੂੰ ਲੇਬਲ ਕਰਦਾ ਹੈ ਜੋ ਇਹ ਦੇਖਦਾ ਹੈ। ਇਹ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਪੈਟਰਨ ਹੈ, ਪਰ ਇਹ ਅਜੇ ਵੀ ਇੱਕ ਫਲੋ ਹੈ।
ਏਜੰਟ ਨੂੰ ਆਖਰੀ ਵਿੱਚ ਬਣਾਓ। ਇਹ ਕਦਮ ਉਹਨਾਂ ਕੰਮਾਂ ਲਈ ਰੱਖੋ ਜਿੱਥੇ ਅਗਲਾ ਕਦਮ ਸੱਚਮੁੱਚ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਮਾਡਲ ਰਨ ਦੇ ਦੌਰਾਨ ਕੀ ਖੋਜਦਾ ਹੈ। ਜੇਕਰ ਸਿਸਟਮ ਨੂੰ ਇੱਕ ਈਮੇਲ ਪੜ੍ਹਨੀ ਪਵੇ, ਇਹ ਅਹਿਸਾਸ ਕਰਨਾ ਪਵੇ ਕਿ ਇਸਨੂੰ ਲੌਜਿਸਟਿਕਸ API ਵਿੱਚ ਸ਼ਿਪਮੈਂਟ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ, ਇਹ ਪਤਾ ਲੱਗੇ ਕਿ ਸ਼ਿਪਮੈਂਟ ਵਿੱਚ ਦੇਰੀ ਹੋ ਰਹੀ ਹੈ, ਅਤੇ ਫਿਰ ਉਸ ਤਾਜ਼ਾ ਡਾਟਾ ਦੇ ਅਧਾਰ 'ਤੇ ਇੱਕ ਕਸਟਮ ਜਵਾਬ ਤਿਆਰ ਕਰਨਾ ਪਵੇ, ਤਾਂ ਤੁਸੀਂ ਏਜੰਟ ਦੇ ਖੇਤਰ ਵਿੱਚ ਹੋ। ਇਸ ਰਸਤੇ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਨਹੀਂ ਤਿਆਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਕਿਉਂਕਿ ਮਾਡਲ ਹਰ ਨਵੇਂ ਤੱਥ ਤੋਂ ਬਾਅਦ ਕੀ ਕਰਨਾ ਹੈ, ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ।
ਵ੍ਹਾਈਟਬੋਰਡ ਟੈਸਟ (The Whiteboard Test)
ਮੀਟਿੰਗ ਵਿੱਚ ਬਹਿਸ ਨੂੰ ਸੁਲਝਾਉਣ ਦਾ ਇੱਕ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ। ਆਪਣੀ ਟੀਮ ਨੂੰ ਵ੍ਹਾਈਟਬੋਰਡ 'ਤੇ ਫੈਸਲੇ ਦੀਆਂ ਸ਼ਾਖਾਵਾਂ (decision branches) ਬਣਾਉਣ ਲਈ ਕਹੋ।
ਜੇਕਰ ਤੁਸੀਂ ਮਾਡਲ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਰਸਤੇ ਨੂੰ ਮੈਪ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਫਲੋ ਬਣਾਓ। ਡਾਇਮੰਡ ਸ਼ੇਪ ਬਣਾਓ, if-statements ਲ