ਮੈਂ ਸੋਚਦਾ ਸੀ ਕਿ ਇੱਕ AI agent ਬਣਾਉਣਾ ਮੂਲ ਰੂਪ ਵਿੱਚ ਇੱਕ chatbot ਨੂੰ prompt ਕਰਨ ਦੇ ਬਰਾਬਰ ਹੈ। ਤੁਸੀਂ ਸਵਾਲ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪੇਸ਼ ਕਰਦੇ ਹੋ, ਮਾਡਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ ਕੰਮ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਫਿਰ ਮੈਂ ਕੁਝ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਾਂਚ ਕੀਤੀਆਂ। ਹਕੀਕਤ ਬਹੁਤ ਸਖ਼ਤ ਸੀ। ਇੱਕ LLM agent ਨਹੀਂ ਹੈ। ਇੱਕ LLM ਅਗਲੇ token ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦਾ ਹੈ। ਉਹ loop ਹੀ agent ਬਣਾਉਂਦਾ ਹੈ।

ਚਾਹ ਬਣਾਉਣ ਬਾਰੇ ਸੋਚੋ। ਤੁਸੀਂ make_tea() ਨਾਮ ਦਾ ਕੋਈ ਇੱਕ command ਨਹੀਂ ਚਲਾਉਂਦੇ ਅਤੇ ਚਲੇ ਜਾਂਦੇ ਹੋ। ਤੁਸੀਂ ਕੇਟਲ ਭਰਦੇ ਹੋ, ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਕਿ ਟੈਪ ਦਾ ਪ੍ਰੈਸ਼ਰ ਘੱਟ ਹੈ, ਉਡੀਕ ਕਰਦੇ ਹੋ, ਉਸਨੂੰ ਚਾਲੂ ਕਰਦੇ ਹੋ, ਦੇਖਦੇ ਹੋ ਕਿ ਸਵਿੱਚ ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ, ਦੂਜੇ ਬਰਨਰ 'ਤੇ ਜਾਂਦੇ ਹੋ, ਭਾਫ਼ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹੋ, ਚਾਹ ਪਾਉਂਦੇ ਹੋ, ਚੱਖਦੇ ਹੋ, ਅਤੇ ਸ਼ਾਇਦ ਸ਼ਹਿਦ ਪਾਉਂਦੇ ਹੋ ਕਿਉਂਕਿ ਪੱਤੇ ਬਹੁਤ ਦੇਰ ਤੱਕ ਭਿੱਜੇ ਰਹੇ ਸਨ। ਟੀਚਾ ਕਦੇ ਨਹੀਂ ਬਦਲਦਾ, ਪਰ ਕਦਮ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ। ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ, ਅਨੁਕੂਲਿਤ ਕਰਦੇ ਹੋ, ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ। AI agents ਬਿਲਕੁਲ ਇਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੇ ਹਨ।

ਉਹ ਚੱਕਰ ਜੋ Agency ਬਣਾਉਂਦਾ ਹੈ

ਇਹ loop ਕੋਈ ਅਮੂਰਤ ਸਿਧਾਂਤ ਨਹੀਂ ਹੈ। ਇਹ ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਸਿਸਟਮ ਦੀ ਕਾਰਜਸ਼ੀਲ ਦਿਲ ਦੀ ਧੜਕਣ ਹੈ ਜੋ ਤੁਹਾਡੇ ਵੱਲੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ ਇਹ ਅਭਿਆਸ ਵਿੱਚ ਅਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

  • Think: ਮਾਡਲ ਟੀਚੇ ਬਾਰੇ ਸੋਚਦਾ ਹੈ ਅਤੇ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਉਸਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਉਪਭੋਗਤਾ ਪੁੱਛਦਾ ਹੈ, "ਕੀ ਮੈਨੂੰ ਕੱਲ੍ਹ Portland ਜਾਣ ਲਈ ਛਤਰੀ ਲੈ ਕੇ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ?" ਮਾਡਲ ਪਛਾਣਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਮੌਸਮ ਦੇ ਅਨੁਮਾਨ ਅਤੇ ਇੱਕ ਸਥਾਨ ਦੀ ਲੋੜ ਹੈ।
  • Act: ਮਾਡਲ ਇੱਕ tool ਨੂੰ ਬੁਲਾਉਂਦਾ ਹੈ। ਇਹ "Portland" ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਇੱਕ geocoding API ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਕੋਆਰਡੀਨੇਟਸ ਦੇ ਨਾਲ ਇੱਕ weather endpoint 'ਤੇ ਜਾ ਸਕਦਾ ਹੈ।
  • Observe: ਮਾਡਲ tool ਦੇ ਆਉਟਪੁੱਟ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ। ਕੀ API ਨੇ JSON forecast, 403 error, ਜਾਂ HTML maintenance page ਵਾਪਸ ਕੀਤਾ?
  • Update: ਜੋ ਉਹ ਦੇਖਦਾ ਹੈ ਉਸ ਦੇ ਅਧਾਰ 'ਤੇ, ਮਾਡਲ ਆਪਣੀ ਯੋਜਨਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦਾ ਹੈ। ਜੇਕਰ geocoder ਨੇ Portland, Oregon ਦੀ ਬਜਾਏ Portland, Maine ਵਾਪਸ ਕੀਤਾ ਹੈ, ਤਾਂ ਮਾਡਲ ਨੂੰ ਅਸਪਸ਼ਟਤਾ ਨੂੰ ਦੂਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ API ਡਾਊਨ ਹੈ, ਤਾਂ ਇਹ ਬੈਕਅੱਪ ਸਰੋਤ 'ਤੇ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਪੁੱਛ ਸਕਦਾ ਹੈ।
  • Think Again: ਨਵੇਂ ਸੰਦਰਭ (context) ਦੇ ਨਾਲ ਚੱਕਰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।

ਇਹ ਪੰਜ ਵੱਖਰੇ ਫੰਕਸ਼ਨ ਨਹੀਂ ਹਨ ਜੋ ਤੁਸੀਂ ਇੱਕ ਵਾਰ ਲਿਖਦੇ ਹੋ ਅਤੇ ਭੁੱਲ ਜਾਂਦੇ ਹੋ। ਇਹ ਇੱਕ ਨਿਰੰਤਰ ਇੰਜਣ ਹੈ ਜੋ ਉਦੋਂ ਤੱਕ ਚਲਦਾ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਟੀਚਾ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੋ ਜਾਂਦਾ ਜਾਂ ਕੋਈ hard stop ਨਹੀਂ ਲੱਗ ਜਾਂਦਾ। ਮਾਡਲ ਕਿਸੇ ਸਕ੍ਰਿਪਟ ਵਾਂਗ ਕੋਡ ਨੂੰ ਨਹੀਂ ਚਲਾ ਰਿਹਾ ਹੈ। ਇਹ ਦੁਨੀਆ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਸੋਚ ਰਿਹਾ ਹੈ, ਇੱਕ ਕਾਰਵਾਈ ਚੁਣ ਰਿਹਾ ਹੈ, ਨਤੀਜੇ ਨੂੰ ਪੜ੍ਹ ਰਿਹਾ ਹੈ, ਅਤੇ ਫੈਸਲਾ ਕਰ ਰਿਹਾ ਹੈ ਕਿ ਅੱਗੇ ਕੀ ਆਵੇਗਾ। ਇਹ ਇੱਕ ਸ਼ਾਨਦਾਰ autocomplete ਅਤੇ ਕੰਮ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਾਲੇ agent ਦੇ ਵਿਚਕਾਰ ਦਾ ਅੰਤਰ ਹੈ।

ਸਾਰੇ Frameworks ਇੱਕੋ ਜਿਹੇ ਕਿਉਂ ਲੱਗਦੇ ਹਨ

ਜੇਕਰ ਤੁਸੀਂ LangGraph, CrewAI, ਜਾਂ AutoGen ਨਾਲ ਸਮਾਂ ਬਿਤਾਇਆ ਹੈ, ਤਾਂ ਸ਼ਾਇਦ ਤੁਸੀਂ ਮਹਿਸੂਸ ਕੀਤਾ ਹੋਵੇਗਾ ਕਿ ਉਹ ਇੱਕੋ ਜਿਹੇ ਲੱਗਣ ਲੱਗ ਪਏ ਹਨ। LangGraph ਵਹਾਅ (flow) ਨੂੰ nodes ਅਤੇ edges ਦੇ ਇੱਕ ਸਥਾਈ ਗ੍ਰਾਫ ਵਜੋਂ ਮਾਡਲ ਕਰਦਾ ਹੈ। CrewAI agents ਨੂੰ ਭੂਮਿਕਾਵਾਂ (roles) ਅਤੇ crews ਵਿੱਚ ਸੰਗਠਿਤ ਕਰਦਾ ਹੈ। AutoGen multi-agent ਗੱਲਬਾਤ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦਾ ਹੈ। ਵੱਖਰੀ ਪੈਕੇਜਿੰਗ, ਇੱਕੋ ਜਿਹਾ ਢਾਂਚਾ।

ਉਹ ਸਮਾਨ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸਾਰੇ ਇਸੇ ਲੂਪਿੰਗ ਸਿਧਾਂਤ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ। LangGraph ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਚੱਕਰ ਨੂੰ tool calls ਅਤੇ model inferences ਦੇ ਵਿਚਕਾਰ state transitions ਵਜੋਂ ਢਾਂਚਾ ਦਿੰਦਾ ਹੈ। CrewAI ਲੂਪ ਨੂੰ role-based agents ਦੇ ਅੰਦਰ ਲਪੇਟਦਾ ਹੈ, ਪਰ ਹਰ crew ਮੈਂਬਰ ਅਜੇ ਵੀ planning, acting, ਅਤੇ observing ਦੇ ਚੱਕਰ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। AutoGen ਅਦਾਕਾਰਾਂ (actors) ਵਿਚਕਾਰ ਸੰਦੇਸ਼ਾਂ ਦਾ ਵਿਚੋਲਗੀ ਕਰਦਾ ਹੈ, ਫਿਰ ਵੀ ਹਰ ਮੋੜ ਅਜੇ ਵੀ generate, execute, reflect, ਅਤੇ route ਦਾ ਇੱਕ ਵੇਰੀਏਸ਼ਨ ਹੈ।

ਇਹ frameworks ਲੂਪ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉੱਥੇ ਹੀ agency ਹੁੰਦੀ ਹੈ। ਅਧਾਰभूत ਮਾਡਲ GPT-4, Claude, ਜਾਂ ਇੱਕ fine-tuned open-weight ਮਾਡਲ ਹੋ ਸਕਦਾ ਹੈ। ਲੂਪ ਤੋਂ ਬਿਨਾਂ, ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਬਹੁਤ ਮਹਿੰਗਾ sentence completer ਹੈ। ਲੂਪ ਦੇ ਨਾਲ, ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਅਜਿਹਾ ਸਿਸਟਮ ਹੈ ਜੋ ਕਈ ਕੋਸ਼ਿਸ਼ਾਂ ਵਿੱਚ ਇੱਕ ਉਦੇਸ਼ ਵੱਲ ਵਧ ਸਕਦਾ ਹੈ।

ਜਦੋਂ ਅਸਲ ਕੰਮ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ

ਲੋਕਲ ਡੈਮੋ ਜਾਦੂਈ ਲੱਗਦੇ ਹਨ। Production ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਜਾਦੂ ਅਤੇ ਗੜਬੜੀ ਦਾ ਸਾਹਮਣਾ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ prototyping ਤੋਂ ਅੱਗੇ ਵਧਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ AI ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਅਤੇ ਸਿਸਟਮ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ।

Tool ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਅਟਲ ਹਨ। APIs time out ਹੋ ਜਾਂਦੇ ਹਨ। ਉਹ malformed JSON ਵਾਪਸ ਕਰਦੇ ਹਨ। ਉਹ HTML ਵਿੱਚ ਲਪੇ ਹੋਏ 500 errors ਦਿੰਦੇ ਹਨ। ਜੇਕਰ ਤੁਹਾਡਾ loop ਅੰਨ੍ਹੇਵਾਹ ਹਰ tool output 'ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ agent ਸਫਲਤਾ ਦਾ ਭਰਮ (hallucinate) ਕਰੇਗਾ ਜਾਂ ਉਲਝਣ ਵਿੱਚ ਫਸ ਜਾਵੇਗਾ। ਤੁਹਾਨੂੰ ਹਰ return payload 'ਤੇ retry logic, circuit breakers, ਅਤੇ schema validation ਦੀ ਲੋੜ ਹੈ।

Memory ਪੁਰਾਣੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਤੁਹਾਡਾ agent ਯਾਦ ਰੱਖਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਦਾ ਪਸੰਦੀਦਾ database PostgreSQL ਹੈ, ਪਰ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਟੀਮ ਨੇ ਕੱਲ੍ਹ ਰਾਤ ਇੱਕ ਨਵੇਂ ਕਲੱਸਟਰ ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਕਰ ਲਿਆ ਹੈ। ਸੰਦਰਭ (context) ਨੂੰ ਤਾਜ਼ਾ ਕਰਨ ਜਾਂ ਖਤਮ ਕਰਨ ਦੇ ਮਕੈਨਿਜ਼ਮ ਤੋਂ ਬਿਨਾਂ, agent ਭਰੋਸੇ ਨਾਲ ਮਰੇ ਹੋਏ endpoints ਵਿਰੁੱਧ commands ਜਾਰੀ ਕਰੇਗਾ। Memory ਨੂੰ timestamps, confidence scores, ਅਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਅਵੈਧ (invalidate) ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

Infinite loops ਚੁੱਪਚਾਪ ਮਾਰਨ ਵਾਲੇ ਕਾਤਲ ਹਨ। ਇੱਕ agent ਵੈੱਬ 'ਤੇ ਸਰਚ ਕਰਦਾ ਹੈ, ਕੁਝ ਵੀ ਲਾਭਦਾਇਕ ਨਹੀਂ ਲੱਭਦਾ, ਕੁਝ ਥੋੜ੍ਹਾ ਜਿਹਾ query ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ, ਦੁਬਾਰਾ ਸਰਚ ਕਰਦਾ ਹੈ, ਕੁਝ ਨਹੀਂ ਲੱਭਦਾ, ਅਤੇ ਇਹੀ ਦੁਹਰਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ। ਬਿਨਾਂ ਕਿਸੇ maximum iteration ceiling ਜਾਂ semantic duplicate detection ਦੇ, ਇਹ ਉਪਭੋਗਤਾ ਦੇ ਇੰਤਜ਼ਾਰ ਕਰਦੇ ਸਮੇਂ tokens ਅਤੇ ਪੈਸੇ ਖ਼ਰਚ ਕਰਦਾ ਰਹੇਗਾ। ਤੁਹਾਨੂੰ guardrails ਬਣਾਉਣੇ ਪੈਣਗੇ: retries 'ਤੇ hard caps, divergence checks, ਅਤੇ human escalation paths।

ਗੈਰ-ਸੰਬੰਧਿਤ ਡਾਟਾ ਤਰਕ ਨੂੰ ਡੁਬੋ ਦਿੰਦਾ ਹੈ। Retrieval-Augmented Generation ਪਾਈਪਲਾਈਨਾਂ ਅਕਸਰ ਸੰਬੰਧਿਤ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਪੰਜਾਹ ਪੈਰਾਗ੍ਰਾਫ ਕੰਟੈਕਸਟ ਵਿੰਡੋ ਵਿੱਚ ਪਾ ਦਿੰਦੀਆਂ ਹਨ। ਏਜੰਟ ਇਸ ਬੇਕਾਰ ਜਾਣਕਾਰੀ (noise) ਕਾਰਨ ਉਲਝ ਜਾਂਦਾ ਹੈ ਅਤੇ ਗਲਤ ਟੂਲ ਚੁਣ ਲੈਂਦਾ ਹੈ ਜਾਂ ਕਿਸੇ ਪੈਰਾਮੀਟਰ ਬਾਰੇ ਗਲਤ ਜਾਣਕਾਰੀ (hallucinate) ਦੇਣ ਲੱਗ ਪੈਂਦਾ ਹੈ। ਮਾਡਲ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਟੈਕਸਟ ਨੂੰ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਫਿਲਟਰਿੰਗ, ਰੈਂਕਿੰਗ ਅਤੇ ਸੰਖੇਪ ਸਾਰ (summarisation) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਇੱਕ ਏਜੰਟ ਨੂੰ ਸਿਰਫ਼ ਬੁੱਧੀ ਦੀ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ਸਿਸਟਮ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਮੈਨੇਜਡ ਮੈਮੋਰੀ, ਸਪੱਸ਼ਟ ਸਟੇਟ ਟ੍ਰੈਕਿੰਗ, ਸਖ਼ਤ ਗਾਰਡਰੇਲਜ਼ ਅਤੇ ਦੇਖਣਯੋਗ ਟੈਲੀਮੈਟਰੀ। ਮਾਡਲ ਜਿੰਨਾ ਵਧੀਆ ਹੋਵੇਗਾ, ਉਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦਾ ਸਿਸਟਮ ਵੀ ਉਨਾ ਹੀ ਵਧੀਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਕਮਜ਼ੋਰ ਲੂਪ ਦੇ ਅੰਦਰ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਮਾਡਲ ਸਿਰਫ਼ ਵਧੇਰੇ ਸਪਸ਼ਟ ਅਸਫਲਤਾਵਾਂ ਹੀ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਕੰਮ ਨੂੰ ਪੂਰਾ ਕਰਨਾ

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

ਇਹੀ ਲਗਨ ਇੱਕ ਡੈਮੋ ਨੂੰ ਅਸਲ ਪ੍ਰੋਡਕਟ ਤੋਂ ਵੱਖਰਾ ਕਰਦੀ ਹੈ। ਇਹ ਹਰ ਕਦਮ ਤੋਂ ਸਿੱਖਣ ਦੀ ਯੋਗਤਾ ਹੈ, ਰੀਅਲ-ਟਾਈਮ ਵਿੱਚ ਮਾਡਲ ਵੇਟਸ ਨੂੰ ਅਪਡੇਟ ਕਰਕੇ ਨਹੀਂ, ਸਗੋਂ ਯੋਜਨਾ ਨੂੰ ਅਪਡੇਟ ਕਰਕੇ। ਜਦੋਂ ਤਕਨੀਕਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਤਾਂ ਏਜੰਟ ਟੀਚੇ ਨੂੰ ਸਥਿਰ ਰੱਖਦਾ ਹੈ। ਇਹੀ 'ਲੂਪਿੰਗ ਪ੍ਰਿੰਸੀਪਲ' ਦਾ ਅਸਲ ਕੰਮ ਹੈ।

ਤਾਂ ਕੀ ਭਵਿੱਖ ਵੱਡੇ ਮਾਡਲਾਂ ਦਾ ਹੈ ਜਾਂ ਬਿਹਤਰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਲੂਪਸ ਦਾ? ਸਕੇਲ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਮਦਦ ਕਰਦਾ ਹੈ। ਇੱਕ ਵਧੇਰੇ ਸਮਰੱਥ ਮਾਡਲ ਹਰੇਕ ਚੱਕਰ (cycle) ਦੇ ਅੰਦਰ ਬਿਹਤਰ ਤਰਕ ਕਰਦਾ ਹੈ। ਪਰ ਇੱਕ ਛੋਟਾ ਮਾਡਲ ਜੋ ਇੱਕ ਸਖ਼ਤ, ਦੇਖਣਯੋਗ ਅਤੇ ਮਜ਼ਬੂਤ ਲੂਪ ਦੇ ਅੰਦਰ ਚੱਲ ਰਿਹਾ ਹੈ, ਉਹ ਅਕਸਰ ਉਸ ਵਿਸ਼ਾਲ ਮਾਡਲ ਨਾਲੋਂ ਬਿਹਤਰ ਪ੍ਰਦਰਸ਼ਨ ਕਰੇਗਾ ਜਿਸ ਨੂੰ ਇੱਕੋ ਵਾਰ ਵਿੱਚ ਸਭ ਕੁਝ ਹੱਲ ਕਰਨ ਲਈ ਕਿਹਾ ਗਿਆ ਹੋਵੇ। ਲੂਪ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਅਨੁਮਾਨ ਨੂੰ ਕਾਰਵਾਈ ਵਿੱਚ ਬਦਲਦੀ ਹੈ। ਉੱਥੇ ਨਿਵੇਸ਼ ਕਰੋ।

ਸਰੋਤ: The Looping Principle: A Simple Mental Model for Understanding AI Agents

ਅਜਿਹੀਆਂ ਹੋਰ ਚਰਚਾਵਾਂ ਲਈ, Telegram 'ਤੇ GyaanSetu ਲਰਨਿੰਗ ਕਮਿਊਨਿਟੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੋ।