LLMs ਤੁਹਾਡੇ ਕੋਡ ਵਿੱਚ ਨਹੀਂ ਜਾਂਦੇ – ਉਹ ਤੁਹਾਨੂੰ ਇੱਕ ਬੇਨਤੀ (request) ਦਿੰਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਫੰਕਸ਼ਨ ਚਲਾਉਂਦੇ ਹੋ। ਇਹ ਸਧਾਰਨ ਤੱਥ ਉਸ ਭਰਮ ਨੂੰ ਦੂਰ ਕਰਦਾ ਹੈ ਕਿ "ਮਾਡਲ ਜਾਦੂਈ ਤੌਰ 'ਤੇ ਮੇਰਾ Python routine ਕਾਲ ਕਰਦਾ ਹੈ" ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਡੀਬੱਗਿੰਗ ਅਤੇ ਸੁਰੱਖਿਆ ਬਾਰੇ ਮੁੜ ਵਿਚਾਰ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।
ਡਿਸਪੈਚ ਲੂਪ (dispatch loop), ਕਦਮ-ਦਰ-ਕਦਮ
ਜਦੋਂ ਕਿਸੇ ਲੈਂਗੂਏਜ ਮਾਡਲ (LLM) ਨੂੰ ਕਿਸੇ ਟੂਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਨਿਰਧਾਰਤ ਕ੍ਰਮ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ:
- ਯੋਜਨਾਬੰਦੀ (Planning) – ਮਾਡਲ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਕਾਰਵਾਈ ਦੀ ਲੋੜ ਹੈ (ਜਿਵੇਂ ਕਿ "ਭੁਗਤਾਨ ਵਾਪਸ ਕਰਨਾ")।
- ਬੇਨਤੀ ਤਿਆਰ ਕਰਨਾ (Generating a request) – ਇਹ ਇੱਕ ਸੰਰਚਿਤ ਟੈਕਸਟ—ਆਮ ਤੌਰ 'ਤੇ JSON—ਆਊਟਪੁੱਟ ਕਰਦਾ ਹੈ ਜੋ ਟੂਲ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ ਅਤੇ ਆਰਗੂਮੈਂਟਸ (arguments) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
- ਪਾਰਸਿੰਗ (Parsing) – ਤੁਹਾਡੀ ਐਪ ਜਾਂ ਕੋਈ ਸਹਾਇਕ ਫਰੇਮਵਰਕ ਉਸ ਟੈਕਸਟ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ।
- ਮੈਚਿੰਗ (Matching) – ਫਰੇਮਵਰਕ ਤੁਹਾਡੇ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਅਸਲ ਫੰਕਸ਼ਨਾਂ ਦੀ ਰਜਿਸਟਰੀ ਵਿੱਚ ਨਾਮ ਲੱਭਦਾ ਹੈ।
- ਵੈਲੀਡੇਸ਼ਨ (Validating) – ਇਹ ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਆਰਗੂਮੈਂਟਸ ਫੰਕਸ਼ਨ ਦੇ schema ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ ਅਤੇ ਕਾਲਰ (caller) ਅਧਿਕਾਰਤ ਹੈ ਜਾਂ ਨਹੀਂ।
- ਐਗਜ਼ੀਕਿਊਸ਼ਨ (Executing) – ਮੈਚ ਕੀਤਾ ਗਿਆ ਫੰਕਸ਼ਨ ਤੁਹਾਡੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਚੱਲਦਾ ਹੈ ਅਤੇ ਕੰਮ ਕਰਦਾ ਹੈ।
- ਵਾਪਸੀ (Returning) – ਨਤੀਜੇ ਨੂੰ ਪੈਕੇਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਗਲੀ ਸੋਚ-ਵਿਚਾਰ ਲਈ ਮਾਡਲ ਨੂੰ ਵਾਪਸ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।
LLM ਨੂੰ ਇੱਕ ਯੋਜਨਾਕਾਰ (planner), ਫਰੇਮਵਰਕ ਨੂੰ ਇੱਕ ਡਿਸਪੈਚਰ (dispatcher), ਅਤੇ ਫੰਕਸ਼ਨ ਨੂੰ ਇੱਕ ਵਰਕਰ ਵਜੋਂ ਸਮਝੋ ਜੋ ਅਸਲ ਵਿੱਚ ਡੇਟਾ ਜਾਂ ਪੈਸੇ ਨੂੰ ਹਿਲਾਉਂਦਾ ਹੈ।
"ਜਾਦੂ" ਵਾਲਾ ਭਰਮ ਕਿਉਂ ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ
ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰ ਮਾਡਲ ਆਊਟਪੁੱਟ ਦੀ ਇੱਕ ਸਿੰਗਲ ਲਾਈਨ ਦੇਖਦੇ ਹਨ ਜੋ ਫੰਕਸ਼ਨ ਕਾਲ ਵਾਂਗ ਲੱਗਦੀ ਹੈ ਅਤੇ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ ਮਾਡਲ ਨੇ ਖੁਦ ਹੀ ਕਾਰਵਾਈ ਕੀਤੀ ਹੈ। ਪ੍ਰੋਵਾਈਡਰਾਂ ਦੇ ਦਸਤਾਵੇਜ਼ਾਂ (docs) ਵਿੱਚ "tool calling" ਸ਼ਬਦ ਅਜਿਹਾ ਲੱਗਦਾ ਹੈ ਜਿਵੇਂ ਮਾਡਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਕੋਡ ਨੂੰ ਕਾਲ ਕਰ ਰਿਹਾ ਹੋਵੇ।
ਅਸਲ ਵਿੱਚ, ਮਾਡਲ ਸਿਰਫ਼ ਟੈਕਸਟ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਕਾਲ ਦਾ ਵੇਰਵਾ ਦਿੰਦਾ ਹੈ। ਤੁਹਾਡੀ ਪ੍ਰਕਿਰਿਆ ਸਾਰਾ ਭਾਰੀ ਕੰਮ ਕਰਦੀ ਹੈ—ਲੁੱਕਅੱਪ, ਟਾਈਪ ਚੈਕਿੰਗ, ਪਰਮਿਸ਼ਨ ਲਾਗੂ ਕਰਨਾ, ਅਤੇ ਐਰਰ ਹੈਂਡਲਿੰਗ।
ਫਰੇਮਵਰਕ ਜੋ ਅੰਦਰੂਨੀ ਕੰਮ (plumbing) ਨੂੰ ਛੁਪਾਉਂਦੇ ਹਨ
PydanticAI ਅਤੇ LangChain ਵਰਗੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਲੂਪ ਨੂੰ ਅਜਿਹੇ ਤਰੀਕੇ ਨਾਲ ਅਬਸਟਰੈਕਟ (abstract) ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਤੁਸੀਂ ਬਿਜ਼ਨਸ ਲੌਜਿਕ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰ ਸਕੋ। ਉਹ ਆਪਣੇ ਆਪ:
- ਆਰਗੂਮੈਂਟਸ ਦੀ ਵੈਲੀਡੇਸ਼ਨ ਕਰਦੇ ਹਨ – schema (ਜਿਵੇਂ ਕਿ Pydantic ਮਾਡਲ) ਦੇ ਵਿਰੁੱਧ।
- ਪਰਮਿਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ – ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਉਪਭੋਗਤਾ ਟੂਲ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰ ਸਕਦਾ ਹੈ।
- ਅਸਫਲਤਾ 'ਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ – ਜਦੋਂ ਕੋਈ ਟੂਲ ਐਰਰ ਵਾਪਸ ਕਰਦਾ ਹੈ ਤਾਂ ਮਾਡਲ ਕੋਲ ਵਾਪਸ ਜਾਂਦੇ ਹਨ।
- ਲਗਾਤਾਰ ਚੱਲਦੇ ਰਹਿਣ ਵਾਲੇ ਲੂਪਸ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ – ਲਗਾਤਾਰ ਟੂਲ ਕਾਲਾਂ ਨੂੰ ਸੀਮਤ ਕਰਕੇ।
- ਗੱਲਬਾਤ ਦੀ ਸਥਿਤੀ ਨੂੰ ਬਣਾਈ ਰੱਖਦੇ ਹਨ – ਟੂਲ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਸੰਵਾਦ ਵਿੱਚ ਜੋੜਦੇ ਹਨ।
ਇਹਨਾਂ ਸਹਾਇਕਾਂ ਦੇ ਬਾਵਜੂਦ, ਪੈਟਰਨ ਉਹੀ ਰਹਿੰਦਾ ਹੈ: ਮਾਡਲ ਕਦੇ ਵੀ ਕੋਡ ਨੂੰ ਐਗਜ਼ੀਕਿਊਟ ਨਹੀਂ ਕਰਦਾ।
ਪ੍ਰੋਵਾਈਡਰਾਂ ਤੋਂ ਨੇਟਿਵ (native) ਟੂਲ-ਕਾਲਿੰਗ ਸਪੋਰਟ
ਕੁਝ ਪ੍ਰੋਵਾਈਡਰ ਇੱਕ "ਨੇਟਿਵ" ਟੂਲ-ਕਾਲਿੰਗ ਇੰਟਰਫੇਸ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਜੋ ਟੂਲ ਦੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਅਤੇ ਬੇਨਤੀ ਫਾਰਮੈਟਾਂ ਨੂੰ ਸਟੈਂਡਰਡਾਈਜ਼ ਕਰਦਾ ਹੈ। ਇਹ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਪਰ ਡਿਸਪੈਚ ਸਟੈਪ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦਾ। ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਉਹ ਕੋਡ ਲਿਖਣਾ (ਜਾਂ ਇੰਪੋਰਟ ਕਰਨਾ) ਪੈਂਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਬੇਨਤੀ ਕੀਤੀ ਗਈ ਕਾਰਵਾਈ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਸਮੱਸਿਆ ਦਾ ਨਾਮ ਬਦਲਦੇ ਹੋ ਤਾਂ ਡੀਬੱਗਿੰਗ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ
"ਗੁੰਝਲਦਾਰ ਏਜੰਟ" (confused agent) ਨੂੰ ਦੋਸ਼ ਦੇਣ ਦੀ ਬਜਾਏ, ਇਹ ਕਹੋ ਕਿ "ਮਾਡਲ ਦੇ ਜਵਾਬ ਵਿੱਚ ਕੋਈ ਟੂਲ ਕਾਲ ਨਹੀਂ ਸੀ।" ਇਹ ਅੰਤਰ ਮਹੱਤਵਪੂਰਨ ਹੈ:
- No tool call – ਮਾਡਲ ਨੇ ਸਿੱਧਾ ਜਵਾਬ ਦਿੱਤਾ ਜਾਂ ਸਹੀ ਫਾਰਮੈਟ ਵਿੱਚ ਬੇਨਤੀ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ।
- Malformed request – JSON ਵਿਆਕਰਣ ਅਨੁਸਾਰ ਗਲਤ ਹੈ ਜਾਂ ਲੋੜੀਂਦੇ ਫੀਲਡ ਗੁੰਮ ਹਨ, ਇਸ ਲਈ ਡਿਸਪੈਚਰ ਇਸਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ।
- Validation failure – ਆਰਗੂਮੈਂਟਸ schema ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਜਿਸ ਨਾਲ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਐਰਰ ਆ ਜਾਂਦਾ ਹੈ।
ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਨ ਨਾਲ ਤੁਸੀਂ ਲੂਪ ਦੇ ਹਰੇਕ ਪੜਾਅ ਨੂੰ ਲੌਗ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਹ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਗਲਤੀ ਕਿੱਥੇ ਹੋਈ।
ਇੱਕ ਭਰੋਸੇਯੋਗ ਪਾਈਪਲਾਈਨ ਲਈ ਵਿਵਹਾਰਕ ਸੁਝਾਅ
- ਮਾਡਲ ਆਊਟਪੁੱਟ ਨੂੰ ਅਣਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ ਵਜੋਂ ਮੰਨੋ। ਕਿਸੇ ਵੀ ਸਾਈਡ-ਇਫੈਕਟਿੰਗ ਕੋਡ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਬੇਨਤੀ ਨੂੰ ਨਿਰਧਾਰਤ ਵੈਲੀਡੇਸ਼ਨ ਰਾਹੀਂ ਲੰਘਾਓ।
- ਕੱਚੀ ਬੇਨਤੀ (raw request) ਅਤੇ ਹਰੇਕ ਵੈਲੀਡੇਸ਼ਨ ਸਟੈਪ ਦੇ ਨਤੀਜੇ ਨੂੰ ਲੌਗ ਕਰੋ। ਇਹ ਕੁਝ ਗਲਤ ਹੋਣ 'ਤੇ ਇੱਕ ਰੀਪਲੇਅ ਕਰਨ ਯੋਗ ਟ੍ਰੇਲ ਬਣਾਉਂਦਾ ਹੈ।
- ਲਗਾਤਾਰ ਟੂਲ ਕਾਲਾਂ 'ਤੇ ਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ ਨਿਰਧਾਰਤ ਕਰੋ; ਇੱਕ ਲਗਾਤਾਰ ਚੱਲਦਾ ਰਹਿਣ ਵਾਲਾ ਲੂਪ ਸਰੋਤਾਂ (resources) ਨੂੰ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਰੇਟ ਲਿਮਿਟਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ।
- ਹਰੇਕ ਫੰਕਸ਼ਨ ਨੂੰ
try/exceptਬਲਾਕ ਵਿੱਚ ਰੱਖੋ ਜੋ ਇੱਕ ਸੰਰਚਿਤ ਐਰਰ ਆਬਜੈਕਟ ਵਾਪਸ ਕਰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਮਾਡਲ ਸਮਝ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਜਾਂ ਗ੍ਰੇਸਫੁੱਲ ਫਾਲਬੈਕ (graceful fallback) ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾ ਸਕੇ। - ਪਰਮਿਸ਼ਨ ਚੈੱਕ ਨੂੰ ਬਿਜ਼ਨਸ ਲੌਜਿਕ ਤੋਂ ਵੱਖ ਰੱਖੋ। ਫੰਕਸ਼ਨ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕਾਲਰ ਦੇ ਅਧਿਕਾਰਾਂ ਦੀ ਜਾਂਚ ਕਰੋ, ਖਾਸ ਕਰਕੇ "delete user" ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ ਕਾਰਵਾਈਆਂ ਲਈ।
- Schema-driven ਪਰਿਭਾਸ਼ਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ (ਜਿਵੇਂ ਕਿ Pydantic ਮਾਡਲ) ਤਾਂ ਜੋ ਫਰੇਮਵਰਕ ਉਸ JSON schema ਨੂੰ ਆਟੋ-ਜਨਰੇਟ ਕਰ ਸਕੇ ਜਿਸਦਾ ਮਾਡਲ ਨੂੰ ਪਾਲਣ ਦੀ ਲੋੜ ਹੈ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
ਜਿਵੇਂ-ਜਿਵੇਂ ਪ੍ਰੋਵਾਈਡਰ ਨੇਟਿਵ ਟੂਲ-ਕਾਲਿੰਗ APIs ਨੂੰ ਬਿਹਤਰ ਬਣਾ ਰਹੇ ਹਨ, ਬੇਨਤੀ ਫਾਰਮੈਟਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸਖ਼ਤ ਨਿਯਮਾਂ ਅਤੇ ਵਧੇਰੇ ਅਮੀਰ ਐਰਰ ਕੋਡਾਂ ਦੀ ਉਮੀਦ ਰੱਖੋ। ਇਹ ਤਬਦੀਲੀਆਂ ਵੈਲੀਡੇਸ਼ਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣਗੀਆਂ ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸਖ਼ਤ ਸੁਰੱਖਿਆ ਦੀਆਂ ਕੰਧਾਂ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣਗੀਆਂ। ਲਾਇਬ੍ਰੇਰੀ ਅੱਪਡੇਟਾਂ '
LLM ਇੱਕ ਉੱਨਤ ਟੈਕਸਟ ਜਨਰੇਟਰ ਹੈ, ਕੋਈ ਐਗਜ਼ੀਕਿਊਟਰ ਨਹੀਂ। ਤੁਹਾਡਾ ਕੋਡ ਹੀ ਉਹ ਇਕਲੌਤੀ ਅਧਿਕਾਰਤ ਹੈ ਜੋ ਕਾਰਜਾਂ ਨੂੰ ਅਮਲ ਵਿੱਚ ਲਿਆਉਂਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ (ਜਾਂ ਇੰਪੋਰਟ ਕੀਤਾ ਗਿਆ) ਡਿਸਪੈਚਰ ਉਹ ਗੇਟਕੀਪਰ ਹੈ ਜੋ ਉਹਨਾਂ ਕਾਰਜਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਅਧਿਕਾਰਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। ਵਰਕਫਲੋ ਨੂੰ ਮੁੜ-ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਨਾਲ "ਜਾਦੂ" ਵਾਲਾ ਭਰਮ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਡੀਬੱਗਿੰਗ ਵਧੇਰੇ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਉਹ ਸੁਰੱਖਿਆ ਅਨੁਸ਼ਾਸਨ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਹਰ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ।