AI Agent Demos ਦੇ ਪਿੱਛੇ ਦਾ ਕੌੜਾ ਸੱਚ

LinkedIn 'ਤੇ ਭਰਪੂਰ ਮਿਲ ਰਹੇ ਜ਼ਿਆਦਾਤਰ AI-agent demos ਅਸਲੀ agents ਨਹੀਂ ਹਨ। ਮੈਂ ਆਪਣਾ ਦਿਨ ਰਿਸਰਚ ਪੇਪਰ ਪੜ੍ਹਨ ਅਤੇ ਉਹਨਾਂ ਇੰਜੀਨੀਅਰਾਂ ਨਾਲ ਗੱਲ ਕਰਨ ਵਿੱਚ ਬਿਤਾਉਂਦਾ ਹਾਂ ਜੋ ਉਤਪਾਦ (products) ਤਿਆਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਮੈਂ ਦੇਖ ਰਿਹਾ ਹਾਂ ਕਿ ਚਮਕਦਾਰ demos ਅਤੇ production-ready systems ਦੇ ਵਿਚਕਾਰ ਦਾ ਪਾੜਾ ਵਧ ਰਿਹਾ ਹੈ। ਜੋ ਡਿਵੈਲਪਰ ਸਿਰਫ਼ ਹਾਈਪ (hype) ਦੇ ਪਿੱਛੇ ਭੱਜਦੇ ਹਨ, ਉਹ ਅੰਤ ਵਿੱਚ ਅਜਿਹੇ ਟੂਲ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਕਮਜ਼ੋਰ ਅਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ (over-engineered) ਹੁੰਦੇ ਹਨ।

ਹਾਈਪ (hype) ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ

“Agent” ਇੱਕ ਅਜਿਹਾ ਬਜ਼ਵਰਡ (buzzword) ਬਣ ਗਿਆ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਵੀ ਕਿਸੇ ਸਕ੍ਰਿਪਟ, ਚੈਟਬੋਟ, ਜਾਂ ਕਿਸੇ ਸਧਾਰਨ ਫੰਕਸ਼ਨ ਨਾਲ ਜੋੜ ਸਕਦਾ ਹੈ ਜੋ ਕਿਸੇ ਬਾਹਰੀ ਟੂਲ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ। ਨਤੀਜਾ: ਅਜਿਹੇ demos ਜੋ ਸਕ੍ਰੀਨ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗਦੇ ਹਨ ਪਰ ਇੱਕ ਆਟੋਨੋਮਸ (autonomous) ਸਿਸਟਮ ਦੇ ਮੁੱਖ ਗੁਣਾਂ ਦੀ ਘਾਟ ਰੱਖਦੇ ਹਨ—ਜਿਵੇਂ ਕਿ ਇੱਕ ਸਪੱਸ਼ਟ ਉਦੇਸ਼, ਅਗਲੇ ਕਦਮ ਦਾ ਫੈਸਲਾ ਲੈਣ ਦੀ ਯੋਗਤਾ, ਅਤੇ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਸਮਰੱਥਾ। ਜਦੋਂ ਟੀਮਾਂ ਇੱਕ ਚਮਕਦਾਰ demo ਨੂੰ ਤਿਆਰ-ਸ਼ੁਦਾ ਹੱਲ (ready-made solution) ਸਮਝ ਲੈਂਦੀਆਂ ਹਨ, ਤਾਂ ਉਹ ਜਾਂ ਤਾਂ ਸਧਾਰਨ ਕੰਮਾਂ ਲਈ ਬੇਲੋੜੀ ਤਿਆਰੀ ਵਿੱਚ ਆਪਣੀ ਮਿਹਨਤ ਬਰਬਾਦ ਕਰਦੀਆਂ ਹਨ ਜਾਂ ਗੁੰਝਲਦਾਰ ਵਰਕਫਲੋਅ ਲਈ ਕਮਜ਼ੋਰ ਪਾਈਪਲਾਈਨਾਂ ਤਿਆਰ ਕਰਦੀਆਂ ਹਨ।

ਉਹ ਚੈੱਕਲਿਸਟ ਜੋ ਅਸਲੀ ਨੂੰ ਚਮਕਦਾਰ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ

ਇਹ ਵਿਸ਼ਲੇਸ਼ਣ ਤਿੰਨ ਤੇਜ਼ ਸਵਾਲਾਂ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਜੋ ਇੱਕ ਡਿਵੈਲਪਰ ਨੂੰ ਅਸਲੀ agent ਦੀ ਪਛਾਣ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ:

  • ਕੀ ਸਿਸਟਮ ਨੂੰ ਹਰ ਕਦਮ 'ਤੇ ਮਨੁੱਖੀ ਮਾਰਗਦਰਸ਼ਨ ਦੀ ਲੋੜ ਹੈ? ਜੇਕਰ ਹਾਂ, ਤਾਂ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਚੈਟ ਇੰਟਰਫੇਸ ਹੈ, ਆਟੋਨੋਮਸ agent ਨਹੀਂ।

  • ਕੀ ਸਿਸਟਮ ਕਿਸੇ ਫੇਲ ਹੋਏ tool call ਤੋਂ ਉਭਰ ਸਕਦਾ ਹੈ? ਇੱਕ agent ਨੂੰ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਹੈ, ਕਿਸੇ ਵਿਕਲਪ ਵੱਲ ਜਾਣਾ ਹੈ, ਜਾਂ ਸਲੀਕੇ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਰੋਕਣਾ ਹੈ।

  • ਕੀ ਸਿਸਟਮ ਇੱਕ ਉੱਚ-ਪੱਧਰੀ ਉਦੇਸ਼ ਨੂੰ ਉਪ-ਕਾਰਜਾਂ (subtasks) ਵਿੱਚ ਵੰਡਦਾ ਹੈ? ਅਸਲੀ agents ਇੱਕ ਨਿਰਧਾਰਤ ਸਕ੍ਰਿਪਟ ਦੀ ਪਾਲਣਾ ਕਰਨ ਦੀ ਬਜਾਏ ਉਦੇਸ਼ਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਦੇ ਹਨ ਅਤੇ ਕੰਮ ਦਾ ਸ਼ਡਿਊਲ ਬਣਾਉਂਦੇ ਹਨ।

ਸਫਲ ਟੀਮਾਂ ਅਸਲ ਵਿੱਚ ਕਿਸ ਚੀਜ਼ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੀਆਂ ਹਨ

ਮੈਂ ਦੇਖਿਆ ਹੈ ਕਿ ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਕਰਨ ਵਾਲੇ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮੂਹ ਨਵੇਂ ਮਾਡਲ ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ ਅਤੇ ਤਿੰਨ ਡਿਜ਼ਾਈਨ ਸਤੰਭਾਂ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦੇ ਹਨ:

Tool design

Agents well-defined interfaces ਰਾਹੀਂ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ। ਇੱਕ ਸਾਫ਼ API surface agent ਲਈ inputs, outputs, ਅਤੇ error codes ਬਾਰੇ ਸੋਚਣਾ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ। ਫਰੇਮਵਰਕ ਦੀ ਚੋਣ—LangChain, CrewAI, ਜਾਂ ਕੋਈ ਆਪਣੀ ਲਾਇਬ੍ਰੇਰੀ—ਡਿਟਰਮਿਨਿਸਟਿਕ (deterministic), versioned endpoints ਪ੍ਰਦਾਨ ਕਰਨ ਦੇ ਅਨੁਸ਼ਾਸਨ ਨਾਲੋਂ ਬਹੁਤ ਘੱਟ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ।

Failure handling

ਹਰ ਬਾਹਰੀ ਕਾਲ ਫੇਲ੍ਹ ਹੋ ਸਕਦੀ ਹੈ। ਇੱਕ agent ਕੋਲ timeouts, retries, circuit-breaking, ਅਤੇ fallback strategies ਲਈ ਨੀਤੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਇਹਨਾਂ ਤੋਂ ਬਿਨਾਂ, ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਖਰਾਬੀ ਇੱਕ ਅਜਿਹੀ ਗੱਲਬਾਤ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ ਜੋ ਮਾਡਲ ਦੀ ਸੀਮਾ ਲੱਗਣ ਦੀ ਬਜਾਏ ਸਿਸਟਮ ਦੀ ਸਮੱਸਿਆ ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।

Observability

ਜਦੋਂ ਇੱਕ agent ਕੋਈ ਫੈਸਲਾ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇੱਕ ਅਜਿਹੇ trace ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਤਰਕ ਦਾ ਕਦਮ (reasoning step), ਵਰਤਿਆ ਗਿਆ ਟੂਲ, ਅਤੇ ਨਤੀਜਾ ਦਿਖਾਵੇ। Structured logs ਜਾਂ event streams ਆਪਰੇਟਰਾਂ ਨੂੰ ਇੱਕ ਸੈਸ਼ਨ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ, ਗਲਤ ਜਵਾਬ ਦੇ ਕਾਰਨ ਦਾ ਪਤਾ ਲਗਾਉਣ, ਅਤੇ prompting ਜਾਂ tool configuration ਨੂੰ ਸੁਧਾਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ।

ਉਹ ਪੈਟਰਨ ਜੋ ਕਿਸੇ ਵੀ ਫਰੇਮਵਰਕ ਤੋਂ ਵੱਧ ਸਮੇਂ ਤੱਕ ਟਿਕਦੇ ਹਨ

ਫਰੇਮਵਰਕ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਸਿਤ ਹੁੰਦੇ ਹਨ—LangChain ਅਤੇ CrewAI ਲਗਭਗ ਹਰ ਮਹੀਨੇ ਬਦਲਾਅ (breaking changes) ਲਿਆਉਂਦੇ ਹਨ। ਵਿਸ਼ਲੇਸ਼ਣ ਦਾ ਤਰਕ ਹੈ ਕਿ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਬਜਾਏ ਪੈਟਰਨਾਂ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਹੇਠਾਂ ਉਹ ਵਾਰ-ਵਾਰ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਢਾਂਚੇ ਹਨ ਜੋ version upgrades ਤੋਂ ਬਾਅਦ ਵੀ ਬਣੇ ਰਹਿੰਦੇ ਹਨ:

  • Plan-then-execute ਤਰਕ ਦੇ ਪੜਾਅ (ਜਿਵੇਂ ਕਿ “ਮੈਨੂੰ ਅੱਗੇ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?”) ਨੂੰ ਐਕਸ਼ਨ ਪੜਾਅ (ਜਿਵੇਂ ਕਿ “billing API ਨੂੰ ਕਾਲ ਕਰੋ”) ਤੋਂ ਵੱਖ ਕਰੋ। ਇਹ prompt ਦੀ ਲੰਬਾਈ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ਦੇ ਆਉਟਪੁੱਟ ਨੂੰ deterministic ਰੱਖਦਾ ਹੈ।

  • Separate retrieval from reasoning ਕੰਟੈਕਸਟ ਪ੍ਰਾਪਤ ਕਰਨਾ (ਜਿਵੇਂ ਕਿ knowledge base ਨੂੰ ਖੋਜਣਾ, ਦਸਤਾਵੇਜ਼ ਲੋਡ ਕਰਨਾ) ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਉਸ ਕੰਟੈਕਸਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲੋਂ ਵੱਖਰਾ ਕੰਮ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ prompt ਦਾ ਆਕਾਰ ਵਧ ਜਾਂਦਾ ਹੈ ਅਤੇ ਖਰਾਬੀਆਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।

  • Explicit handoffs ਜਦੋਂ ਇੱਕ agent ਦੂਜੇ ਨੂੰ ਕੰਮ ਸੌਂਪਦਾ ਹੈ—ਮੰਨ ਲਓ ਇੱਕ planner ਕਿਸੇ data-fetcher ਨੂੰ subtask ਸੌਂਪ ਰਿਹਾ ਹੈ—ਤਾਂ ਇੱਕ structured handoff format (JSON ਜਾਂ ਇੱਕ ਨਿਰਧਾਰਤ schema) ਦੀ ਵਰਤੋਂ ਕਰੋ। ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ agent ਕਾਰਵਾਈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ payload ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ, ਜੋ ਮਜ਼ਬੂਤੀ (robustness) ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ।

ਇੱਕ ਆਮ ਗਲਤੀ: RAG chunking

Retrieval-augmented generation (RAG) ਸਿਸਟਮ ਅਕਸਰ ਉਦੋਂ ਭਾਸ਼ਾ ਮਾਡਲ (language model) ਨੂੰ ਦੋਸ਼ੀ ਠਹਿਰਾਉਂਦੇ ਹਨ ਜਦੋਂ ਜਵਾਬ ਵਿਸ਼ੇ ਤੋਂ ਬਾਹਰ ਹੁੰਦੇ ਹਨ। ਵਿਸ਼ਲੇਸ਼ਣ ਦੱਸਦਾ ਹੈ ਕਿ ਅਸਲ ਦੋਸ਼ ਅਕਸਰ chunking strategy ਦਾ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਅਜਿਹੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡਣਾ ਜੋ ਵਾਕਾਂ ਨੂੰ ਕੱਟ ਦਿੰਦੇ ਹਨ ਜਾਂ ਅਰਥਪੂਰਨ ਸੀਮਾਵਾਂ (semantic boundaries) ਨੂੰ ਗੁਆ ਦਿੰਦੇ ਹਨ, ਮਾਡਲ ਨੂੰ ਉਸ ਕੰਟੈਕਸਟ ਤੋਂ ਵਾਂਝਾ ਕਰ ਦਿੰਦਾ ਹੈ ਜਿਸਦੀ ਉਸਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਮੈਟਾਡਾਟਾ ਟੈਗਸ, overlap windows, ਅਤੇ chunk size ਨੂੰ ਠੀਕ ਕਰਨ ਨਾਲ ਮਾਡਲ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਸੁਧਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਸਿੱਖਿਆ (Takeaway)

ਜੇਕਰ ਤੁਸੀਂ ਅਜਿਹਾ AI ਸਿਸਟਮ ਬਣਾ ਰਹੇ ਹੋ ਜਿਸਨੂੰ ਆਪਣੇ ਆਪ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਸਫਲਤਾ ਨੂੰ ਇਸ ਗੱਲ ਨਾਲ ਨਾ ਮਾਪੋ ਕਿ LinkedIn 'ਤੇ demo ਕਿੰਨਾ ਸ਼ਾਨਦਾਰ ਦਿਖਦਾ ਹੈ। ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡਾ ਕੋਡ ਉਦੇਸ਼ਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡ ਸਕਦਾ ਹੈ, tool failures ਤੋਂ ਬਚ ਸਕਦਾ ਹੈ, ਅਤੇ debugging ਲਈ ਇੱਕ ਸਪੱਸ਼ਟ ਰਸਤਾ ਛੱਡ ਸਕਦਾ ਹੈ। ਉਹ ਤਿੰਨ ਇੰਜੀਨੀਅਰਿੰਗ ਆਦਤਾਂ—ਸੋਚ-ਸਮਝ ਕੇ ਟੂਲ ਡਿਜ਼ਾਈਨ ਕਰਨਾ, ਅਨੁਸ਼ਾਸਿਤ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸੰਭਾਲਣਾ, ਅਤੇ ਫੁੱਲ-ਸਟੈਕ ਆਬਜ਼ਰਵੇਬਿਲਟੀ—ਇੱਕ ਚਮਕਦਾਰ ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ agent ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।