ਜਦੋਂ ਕੋਈ AI agent ਆਪਣੇ ਖੁਦ ਦੇ credentials ਨਾਲ ਸਿੱਧਾ ਬਾਹਰੀ ਸੇਵਾਵਾਂ (external services) ਨਾਲ ਸੰਪਰਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਕਰਮਚਾਰੀ ਸਾਫਟਵੇਅਰ ਦੀ ਬਜਾਏ ਇੱਕ ਅਜਿਹੇ ਕੰਟਰੈਕਟਰ ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ ਜਿਸ ਕੋਲ ਕਾਰਪੋਰੇਟ ਕਾਰਡ ਹੈ ਪਰ ਕੋਈ ਸੁਪਰਵਾਈਜ਼ਰ ਨਹੀਂ। ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਦੇਖ ਸਕਦੇ ਕਿ ਉਸਨੇ ਕਿਸ ਚੀਜ਼ ਨੂੰ ਛੂਹਿਆ, ਕਿਸ ਨੇ ਪਹੁੰਚ (access) ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ, ਜਾਂ ਕੋਈ ਇੱਕ ਗੱਲਬਾਤ ਦੂਜੀ ਨਾਲੋਂ ਦਸ ਗੁਣਾ ਮਹਿੰਗੀ ਕਿਉਂ ਰਹੀ। ਲੌਗਸ (logs) ਦਰਜਨਾਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਖਿੰਡ ਜਾਂਦੇ ਹਨ। ਸਵਾਲ ਵਧਦੇ ਜਾਂਦੇ ਹਨ।
Agent ਨੇ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ tool ਵਰਤਿਆ? ਉਸਨੂੰ ਉਸ ਡਾਟਾਬੇਸ (database) ਨੂੰ ਛੂਹਣ ਦੀ ਇਜਾਜ਼ਤ ਕਿਸਨੇ ਦਿੱਤੀ? ਮੰਗਲਵਾਰ ਦਾ ਰਨ ਚਾਲੀ ਹਜ਼ਾਰ tokens ਕਿਉਂ ਖ਼ਤਮ ਕਰ ਗਿਆ ਜਦੋਂ ਕਿ ਸੋਮਵਾਰ ਵਿੱਚ ਸਿਰਫ਼ ਪੰਜ ਵਰਤੇ ਗਏ ਸਨ? ਅਸੀਂ ਅਸਲ ਵਿੱਚ ਕਿੰਨਾ ਖ਼ਰਚ ਕੀਤਾ?
ਯੂਜ਼ਰਸ, ਮਾਡਲਸ ਅਤੇ ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਕੇਂਦਰੀ ਕੰਟਰੋਲ ਲੇਅਰ (central control layer) ਤੋਂ ਬਿਨਾਂ, ਇਹ ਸਵਾਲ ਅਣਸੁਲਝੇ ਰਹਿ ਜਾਂਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਇੱਕ ਅਜਿਹੇ ਸਿੰਗਲ ਪਲੇਨ ਦੀ ਲੋੜ ਹੈ ਜੋ ਹਰ ਕਨੈਕਸ਼ਨ ਨੂੰ ਇੱਕ ਵਾਰ ਰਜਿਸਟਰ ਕਰੇ, ਸਿਰਫ਼ ਉਹਨਾਂ ਸੀਮਤ ਫੰਕਸ਼ਨਾਂ (functions) ਨੂੰ ਪ੍ਰਗਟ ਕਰੇ ਜਿਨ੍ਹਾਂ ਦੀ ਇੱਕ agent ਨੂੰ ਸੱਚਮੁੱਚ ਲੋੜ ਹੈ, ਅਤੇ ਹਰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ (execution) ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰਿਕਾਰਡ ਕਰੇ। ਇਹ ਲੇਖ deco Studio ਨੂੰ ਉਸ ਲੋਕਲ ਕੰਟਰੋਲ ਪਲੇਨ ਵਜੋਂ ਵਰਤਦੇ ਹੋਏ ਇੱਕ ਉੱਨਤ ਲੈਬ (advanced lab) ਬਾਰੇ ਦੱਸਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਸੈੱਟਅੱਪ ਕਰੋਗੇ, ਇੱਕ ਸੁਰੱਖਿਅਤ Model Context Protocol server ਨੂੰ ਕਨੈਕਟ ਕਰੋਗੇ, ਸਿਰਫ਼ ਇੱਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਫੰਕਸ਼ਨ ਨੂੰ ਪ੍ਰਗਟ ਕਰੋਗੇ, ਅਤੇ ਦੇਖੋਗੇ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ agent ਆਪਣੀ ਸੀਮਾ ਤੋਂ ਬਾਹਰ ਜਾਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।
ਖਿੰਡੇ ਹੋਏ Credentials ਦੀ ਸਮੱਸਿਆ
ਇੱਕ ਆਮ ਟੀਮ ਸੈੱਟਅੱਪ ਦੀ ਕਲਪਨਾ ਕਰੋ। ਇੱਕ ਡਿਵੈਲਪਰ ਇੱਕ ਨਿੱਜੀ ਕੀ (personal key) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ agent ਨੂੰ search API ਨਾਲ ਜੋੜਦਾ ਹੈ। ਦੂਜਾ ਉਸੇ agent ਨੂੰ production database ਨਾਲ ਜੋੜ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਡੈਮੋ ਨੁਕਸਾਨਦੇਹ ਨਹੀਂ ਲੱਗ ਰਿਹਾ ਸੀ। ਤੀਜਾ ਇੱਕ billing lookup tool ਜੋੜਦਾ ਹੈ ਤਾਂ ਜੋ agent "invoices ਵਿੱਚ ਮਦਦ" ਕਰ ਸਕੇ। ਹਰ ਕਨੈਕਸ਼ਨ ਦੂਜਿਆਂ ਲਈ ਅਦਿੱਖ ਹੈ। ਹੁਣ agent ਕੋਲ search, production data, ਅਤੇ ਵਿੱਤੀ ਰਿਕਾਰਡਾਂ ਤੱਕ ਸਿੱਧੀ ਪਹੁੰਚ ਹੈ, ਪਰ ਟੀਮ ਕੋਲ ਇਸ ਗੱਲ ਦੀ ਕੋਈ ਇਕਜੁੱਟ ਸੂਚੀ ਨਹੀਂ ਹੈ ਕਿ ਕੀ ਚਾਲੂ (live) ਹੈ।
ਜਦੋਂ credentials agent ਦੇ ਅੰਦਰ ਹੁੰਦੇ ਹਨ, ਤਾਂ governance ਟੁੱਟ ਜਾਂਦੀ ਹੈ। ਤੁਸੀਂ ਕੇਂਦਰੀ ਤੌਰ 'ਤੇ access ਵਾਪਸ ਨਹੀਂ ਲੈ ਸਕਦੇ ਕਿਉਂਕਿ key agent ਦੀ ਮੈਮੋਰੀ ਜਾਂ ਉਸਦੀ local environment file ਵਿੱਚ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਵਰਤੋਂ ਦੀ audit ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿਉਂਕਿ ਬਾਹਰੀ ਸੇਵਾ ਸਿਰਫ਼ ਇੱਕ ਅਗਿਆਤ (anonymous) ਆਟੋਮੇਟਿਡ ਕਲਾਇੰਟ ਤੋਂ API call ਦੇਖਦੀ ਹੈ। ਖ਼ਰਚੇ ਦਾ ਅਚਾਨਕ ਵਾਧਾ ਕਈ ਦਿਨਾਂ ਬਾਅਦ cloud bill ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਉਦੋਂ ਤੱਕ ਕਿਸੇ ਨੂੰ ਯਾਦ ਨਹੀਂ ਰਹਿੰਦਾ ਕਿ ਕਿਸ prompt ਨੇ ਇਸ ਵਾਧੇ ਨੂੰ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ।
deco Studio ਵਿੱਚ ਆਪਣਾ Control Plane ਬਣਾਉਣਾ
deco Studio ਇੱਕ ਲੋਕਲ ਹੱਬ (local hub) ਵਜੋਂ ਕੰਮ ਕਰਕੇ ਇਸ ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਆਪਣੀ ਮਸ਼ੀਨ 'ਤੇ ਚਲਾਉਂਦੇ ਹੋ, ਅਤੇ ਇਹ ਉਹ ਇਕਲੌਤੀ ਜਗ੍ਹਾ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿੱਥੇ configurations ਰਹਿੰਦੀਆਂ ਹਨ। API keys ਅਤੇ tool definitions ਨੂੰ ਵੱਖ-ਵੱਖ agents ਵਿੱਚ ਖਿੰਡਾਉਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ Studio ਦੇ ਅੰਦਰ ਇੱਕ ਵਾਰ ਕਨੈਕਸ਼ਨ ਰਜਿਸਟਰ ਕਰਦੇ ਹੋ। ਫਿਰ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰਦੇ ਹੋ ਕਿ ਹਰ agent ਕਿਹੜੇ ਫੰਕਸ਼ਨ ਦੇਖ ਸਕਦਾ ਹੈ।
ਇਸਨੂੰ ਇੱਕ switchboard ਲਗਾਉਣ ਵਾਂਗ ਸਮਝੋ। ਸਾਰੀਆਂ ਤਾਰਾਂ ਇੱਕ ਕਮਰੇ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਚੁਣਦੇ ਹੋ ਕਿ ਕਿਹੜੀਆਂ ਲਾਈਨਾਂ ਕਿਹੜੇ ਵਿਭਾਗਾਂ ਨਾਲ ਜੁੜਦੀਆਂ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਹਰ ਕਾਲ ਦਾ ਰਿਕਾਰਡ ਰੱਖਦੇ ਹੋ।
deco Studio ਨੂੰ ਲੋਕਲ ਤੌਰ 'ਤੇ ਚਲਾ ਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਇਹ ਚੱਲ ਪਵੇ, ਤਾਂ ਤੁਸੀਂ configuration ਨੂੰ ਕੇਂਦਰੀਕ੍ਰਿਤ (centralize) ਕਰਦੇ ਹੋ। ਹਰ agent ਜੋ ਕਿਸੇ tool ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਉਸਨੂੰ ਹੁਣ ਸਿੱਧਾ ਬਾਹਰੀ ਸੇਵਾ ਦੀ ਬਜਾਏ control plane ਨੂੰ ਪੁੱਛਣਾ ਪਵੇਗਾ। ਇਹ ਤੁਰੰਤ ਇੱਕ ਅਜਿਹਾ chokepoint ਬਣਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, filter ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ log ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਸੁਰੱਖਿਅਤ MCP Server ਨੂੰ ਕਨੈਕਟ ਕਰਨਾ
ਇਸ ਲੈਬ ਵਿੱਚ, ਤੁਸੀਂ ਇੱਕ Model Context Protocol server ਨੂੰ ਕਨੈਕਟ ਕਰਦੇ ਹੋ। MCP ਮਾਡਲਸ ਨੂੰ ਬਾਹਰੀ tools ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਇੱਕ open standard ਹੈ, ਪਰ standards ਸੁਰੱਖਿਆ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੇ। ਇੱਥੇ ਮਹੱਤਵਪੂਰਨ ਕਦਮ ਚੋਣ (selectivity) ਹੈ। ਤੁਸੀਂ ਸਰਵਰ ਦੁਆਰਾ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਹਰ endpoint ਨੂੰ ਅੰਨ੍ਹੇਵਾਹ ਪ੍ਰਗਟ ਨਹੀਂ ਕਰਦੇ। ਤੁਸੀਂ deco Studio ਵਿੱਚ ਸਰਵਰ ਨੂੰ ਰਜਿਸਟਰ ਕਰਦੇ ਹੋ, ਫਿਰ ਆਪਣੇ test agent ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਫੰਕਸ਼ਨ ਪ੍ਰਗਟ ਕਰਦੇ ਹੋ।
ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡਾ MCP server ਦਸ ਫੰਕਸ਼ਨ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ: file read, file write, database query, network fetch, ਅਤੇ ਹੋਰ। ਤੁਸੀਂ ਇੱਕ ਨੁਕਸਾਨ ਰਹਿਤ ਕਾਰਜ ਚੁਣਦੇ ਹੋ, ਸ਼ਾਇਦ ਇੱਕ sandboxed calculator ਜਾਂ synthetic data ਦੇ ਵਿਰੁੱਧ ਇੱਕ read-only lookup, ਅਤੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਉਸਨੂੰ ਹੀ ਪ੍ਰਗਟ ਕਰਦੇ ਹੋ। ਬਾਕੀ ਨੌਂ agent ਲਈ ਅਦਿੱਖ ਹੋ ਜਾਂਦੇ ਹਨ। ਜੇਕਰ agent ਉਹਨਾਂ ਲਈ ਪੁੱਛਦਾ ਹੈ, ਤਾਂ control plane ਸਖ਼ਤ ਇਨਕਾਰ (hard refusal) ਕਰ ਦਿੰਦਾ ਹੈ।
ਇਹ 'principle of least privilege' ਨੂੰ ਮਕੈਨੀਕਲ ਬਣਾਉਣ ਵਰਗਾ ਹੈ। Agent ਨੂੰ ਸਮਰੱਥਾ (capability) ਕਿਸੇ ਨਿਮਰਤਾ ਵਾਲੇ ਨਿਰਦੇਸ਼ ਰਾਹੀਂ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ software boundary ਰਾਹੀਂ ਮਿਲਦੀ ਹੈ।
ਸੀਮਾ ਦੀ ਜਾਂਚ ਕਰਨਾ
ਇੱਕ test agent ਬਣਾਓ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ deco Studio control plane ਵੱਲ ਮੋੜੋ। ਇਸਨੂੰ ਅਜਿਹਾ ਕੰਮ ਦਿਓ ਜਿਸ ਲਈ ਇੱਕੋ ਇੱਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਫੰਕਸ਼ਨ ਦੀ ਲੋੜ ਹੋਵੇ। ਇਸਨੂੰ ਸਫਲ ਹੁੰਦੇ ਹੋਏ ਦੇਖੋ। Studio ਦੇ ਅੰਦਰ ਲੌਗਸ ਮਾਡਲ ਦੀ ਬੇਨਤੀ (model request), control plane ਰਾਹੀਂ tool call ਦੀ ਰੂਟਿੰਗ, ਫੰਕਸ਼ਨ ਦੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ, ਅਤੇ ਮਾਡਲ ਕੋਲ ਵਾਪਸ ਆ ਰਹੇ ਨਤੀਜੇ ਨੂੰ ਦਿਖਾਉਣਗੇ। ਤੁਸੀਂ ਪੂਰੇ ਰਸਤੇ ਨੂੰ ਇੱਕ ਲਗਾਤਾਰ trace ਵਿੱਚ ਪੜ੍ਹ ਸਕਦੇ ਹੋ।
ਹੁਣ ਏਜੰਟ ਨੂੰ ਦੂਜਾ ਕੰਮ ਦਿਓ ਜਿਸ ਲਈ ਇੱਕ ਅਜਿਹਾ ਫੰਕਸ਼ਨ ਚਾਹੀਦਾ ਹੋਵੇ ਜੋ ਤੁਸੀਂ ਜਾਣਬੁੱਝ ਕੇ ਬਾਹਰ ਰੱਖਿਆ ਹੈ। ਏਜੰਟ ਇਸ ਸੀਮਾ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਜਾਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਇਹ ਭੁਲੇਖਾ ਖਾ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਟੂਲ ਮੌਜੂਦ ਹੈ। ਚਾਹੇ ਕੁਝ ਵੀ ਹੋਵੇ, ਕਾਲ ਕੰਟਰੋਲ ਪਲੇਨ (control plane) ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ, ਅਲਾਉਲਿਸਟ (allowlist) ਇਸ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਕਾਰਜਵਿਧੀ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦੀ ਹੈ। ਉਹ ਫੇਲ੍ਹ ਹੋਣਾ ਹੀ ਤੁਹਾਡਾ ਸਬੂਤ ਹੈ ਕਿ ਸੀਮਾ ਸੌਫਟਵੇਅਰ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤੀ ਗਈ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ।
ਪਹਿਲਾਂ ਇਹ ਕੰਮ ਸਿੰਥੈਟਿਕ (synthetic) ਟਾਸਕਾਂ ਨਾਲ ਕਰੋ। ਜਨਰੇਟ ਕੀਤੇ ਗਏ ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲਾਂ ਨਾਲ ਭਰਿਆ ਇੱਕ ਫੇਕ ਡਾਟਾਬੇਸ ਬਣਾਓ। ਏਜੰਟ ਨੂੰ ਇਸ ਦੀ ਕੁਐਰੀ (query) ਕਰਨ ਦਿਓ। ਅਲਾਉਲਿਸਟ ਅਤੇ ਰੱਦ ਕੀਤੇ ਗਏ ਕੰਮਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਸਿਰਫ ਉਦੋਂ ਹੀ ਏਜੰਟ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮਾਂ ਵੱਲ ਮੋੜਨ ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ ਸੀਮਾ 'ਤੇ ਭਰੋਸਾ ਕਰ ਲੈਂਦੇ ਹੋ। ਕੰਧ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਡੇਟਾ ਵੱਲ ਭੱਜਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਭੇਦ (secrets) ਲੀਕ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਰਨ (Run) ਦੇ ਪੂਰੇ ਰਸਤੇ ਨੂੰ ਪੜ੍ਹਨਾ
deco Studio ਤੁਹਾਨੂੰ ਕਾਰਜਵਿਧੀ ਦੀ ਹਰ ਪਰਤ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਕੱਚੀ ਮਾਡਲ ਰਿਕਵੈਸਟ ਦੇਖਦੇ ਹੋ: ਪ੍ਰੋਂਪਟ (prompt), ਕੰਟੈਕਸਟ ਵਿੰਡੋ (context window), ਫਾਰਮੈਟਿੰਗ। ਤੁਸੀਂ ਉਹ ਟੂਲ ਕਾਲ ਦੇਖਦੇ ਹੋ ਜੋ ਮਾਡਲ ਨੇ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਸੀ। ਤੁਸੀਂ ਕੰਟਰੋਲ ਪਲੇਨ ਦੁਆਰਾ ਉਸ ਕਾਲ ਨੂੰ ਰੂਟ ਕਰਨਾ, ਫੰਕਸ਼ਨ ਨੂੰ ਚਲਾਉਣਾ, ਅਤੇ ਪੇਲੋਡ (payload) ਵਾਪਸ ਆਉਣਾ ਦੇਖਦੇ ਹੋ। ਅੰਤ ਵਿੱਚ, ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਮਾਡਲ ਉਸ ਨਤੀਜੇ ਦੀ ਵਰਤੋਂ ਆਪਣਾ ਜਵਾਬ ਬਣਾਉਣ ਲਈ ਕਿਵੇਂ ਕਰਦਾ ਹੈ।
ਇਹ ਦਿੱਖ (visibility) ਬੁਨਿਆਦੀ ਆਡਿਟ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਟੂਲ ਕਿਉਂ ਚੱਲਿਆ ਕਿਉਂਕਿ ਕੰਟਰੋਲ ਪਲੇਨ ਨੇ ਇਸ ਨੂੰ ਲੌਗ ਕੀਤਾ ਸੀ। ਤੁਹਾਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਸ ਨੇ ਪਹੁੰਚ ਦਿੱਤੀ ਕਿਉਂਕਿ ਕੌਂਫਿਗਰੇਸ਼ਨ ਰਿਕਾਰਡ ਇੱਕ ਸਥਾਨਕ ਰਜਿਸਟਰੀ ਵਿੱਚ ਹਨ। ਤੁਹਾਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਰਨ ਮਹਿੰਗਾ ਕਿਉਂ ਸੀ ਕਿਉਂਕਿ ਤੁਸੀਂ ਟੋਕਨਾਂ ਦੀ ਗਿਣਤੀ ਕਰ ਸਕਦੇ ਹੋ।
ਜੋ ਮਹੱਤਵਪੂਰਨ ਹੈ ਉਸ ਦੀ ਗਿਣਤੀ ਕਰਨਾ
ਹਰ ਰਨ ਲਈ, ਚਾਰ ਖਾਸ ਮੈਟ੍ਰਿਕਸ (metrics) ਨੂੰ ਟਰੈਕ ਕਰੋ। ਪਹਿਲਾ, ਇਨਪੁਟ ਅਤੇ ਆਉਟਪੁਟ ਟੋਕਨ। ਇਹ ਮਾਡਲ ਦੀ ਲਾਗਤ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਨੂੰ ਸਹੀ ਗਿਣਤੀ ਦੀ ਲੋੜ ਹੈ, ਅੰਦਾਜ਼ੇ ਦੀ ਨਹੀਂ। ਦੂਜਾ, ਮਾਡਲ ਲੇਟੈਂਸੀ (latency) ਨੂੰ ਟੂਲ ਲੇਟੈਂਸੀ ਤੋਂ ਵੱਖਰਾ ਕਰੋ। ਤੁਹਾਡੇ ਪ੍ਰੋਂਪਟ ਅਤੇ ਮਾਡਲ ਦੇ ਜਵਾਬ ਦੇ ਵਿਚਕਾਰ ਦਾ ਸਮਾਂ ਉਸ ਸਮੇਂ ਤੋਂ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ ਜੋ ਬਾਹਰੀ ਸੇਵਾ ਨੂੰ ਟੂਲ ਕਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਲੱਗਦਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚ ਉਲਝਣ ਨਾਲ ਗਲਤ ਨਤੀਜੇ ਨਿਕਲ ਸਕਦੇ ਹਨ। ਤੀਜਾ, ਪ੍ਰਮਾਣਿਤ ਪ੍ਰੋਵਾਈਡਰ ਦਰਾਂ ਦੇ ਅਧਾਰ 'ਤੇ ਲਾਗਤ ਦੀ ਗਣਨਾ ਕਰੋ। ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ। ਆਪਣੇ ਪ੍ਰੋਵਾਈਡਰ ਦੀ ਪ੍ਰਾਈਸਿੰਗ ਸ਼ੀਟ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਇਸ ਨੂੰ ਮਾਪੇ ਗਏ ਟੋਕਨਾਂ ਨਾਲ ਮਿਲਾਓ। ਚੌਥਾ, ਸਫਲ ਕਾਲਾਂ ਦੀ ਤੁਲਨਾ ਰੱਦ ਕੀਤੇ ਗਏ ਅਣਅਧਿਕਾਰਤ ਕਾਲਾਂ ਨਾਲ ਕਰੋ। ਰੱਦ ਹੋਣ ਦੀ ਉੱਚ ਗਿਣਤੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ ਏਜੰਟ ਸੀਮਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਤੁਹਾਡੀ ਅਲਾਉਲਿਸਟ ਜਾਇਜ਼ ਲੋੜਾਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ।
ਇਹ ਅੰਕੜੇ ਏਜੰਟ ਦੇ ਕੰਮਕਾਜ ਨੂੰ ਇੱਕ ਬਲੈਕ-ਬਾਕਸ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਇੱਕ ਨਿਰੀਖਣਯੋਗ (observable) ਸਿਸਟਮ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਤੁਸੀਂ ਬਜਟ ਬਣਾ ਸਕਦੇ ਹੋ, ਅਨੁਕੂਲਿਤ (optimize) ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਸਮਝਾ ਸਕਦੇ ਹੋ।
ਸਥਾਨਕ ਕੰਟਰੋਲ ਅਤੇ ਸਥਾਨਕ ਕਾਰਜਵਿਧੀ (Local Execution) ਵਿਚਕਾਰ ਅੰਤਰ
ਇੱਥੇ ਇੱਕ ਅਜਿਹਾ ਸਬਕ ਹੈ ਜੋ ਸਾਵਧਾਨ ਬਿਲਡਰਾਂ ਨੂੰ ਵੀ ਗੁਮਰਾਹ ਕਰ ਦਿੰਦਾ ਹੈ। ਆਪਣੀ ਮਸ਼ੀਨ 'ਤੇ deco Studio ਚਲਾਉਣ ਨਾਲ ਤੁਹਾਨੂੰ ਕੌਂਫਿਗਰੇਸ਼ਨ 'ਤੇ ਸਥਾਨਕ ਕੰਟਰੋਲ ਮਿਲਦਾ ਹੈ, ਪਰ ਇਹ ਮਾਡਲ ਦੀ ਖੁਦ ਸਥਾਨਕ ਕਾਰਜਵਿਧੀ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ। ਜੇਕਰ ਤੁਸੀਂ ਏਜੰਟ ਨੂੰ OpenAI, Anthropic, ਜਾਂ ਕਿਸੇ ਹੋਸਟਡ API ਵਰਗੇ ਬਾਹਰੀ ਪ੍ਰੋਵਾਈਡਰ ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਕੌਂਫਿਗ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਪ੍ਰੋਂਪਟ ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਚਲੇ ਜਾਂਦੇ ਹਨ। ਸਟੂਡੀਓ ਗੇਟ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ, ਪਰ ਡੇਟਾ ਅਜੇ ਵੀ ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਲੰਘਦਾ ਹੈ।
ਹਮੇਸ਼ਾ ਇਹਨਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਟਰੈਕ ਕਰੋ। ਜਾਣੋ ਕਿ ਪਾਈਪਲਾਈਨ ਦੇ ਕਿਹੜੇ ਹਿੱਸੇ localhost 'ਤੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਹਿੱਸੇ ਕਿਸੇ ਹੋਰ ਦੇ ਸਰਵਰ 'ਤੇ ਜਾਂਦੇ ਹਨ। ਜੇਕਰ ਤੁਹਾਡਾ ਡੇਟਾ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ, ਤਾਂ ਟੂਲ ਲੇਅਰ ਦਾ ਸਥਾਨਕ ਕੰਟਰੋਲ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਮਾਡਲ ਇਨਫਰੈਂਸ (inference) ਕਿੱਥੇ ਹੁੰਦਾ ਹੈ। ਸਥਾਨਕ ਡੈਸ਼ਬੋਰਡ ਦੇ ਆਰਾਮ ਨੂੰ ਰਿਮੋਟ ਮਾਡਲ ਦੀ ਅਸਲੀਅਤ ਨਾਲ ਨਾ ਮਿਲਾਓ।
ਹਦਾਇਤਾਂ ਅਧਿਕਾਰ (Authorization) ਨਹੀਂ ਹਨ
ਇੱਕ ਖ਼ਤਰਨਾਕ ਸ਼ਾਰਟਕੱਟ ਪ੍ਰੋਂਪਟਿੰਗ ਰਾਹੀਂ ਏਜੰਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਹੈ। ਮਾਡਲ ਨੂੰ ਇਹ ਕਹਿਣਾ ਕਿ, "ਕਦੇ ਵੀ ਡਿਲੀਟ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਨਾ ਕਰੋ," ਕੋਈ ਸੁਰੱਖਿਆ ਕੰਟਰੋਲ ਨਹੀਂ ਹੈ। ਇਹ ਸਿਰਫ ਇੱਕ ਸੁਝਾਅ ਹੈ। ਮਾਡਲ ਹਦਾਇਤਾਂ ਦਾ ਗਲਤ ਅਰਥ ਕੱਢ ਸਕਦੇ ਹਨ, ਜੇਲਬ੍ਰੇਕ ਪ੍ਰੋਂਪਟ ਕਰ ਸਕਦੇ ਹਨ, ਜਾਂ ਸਿਰਫ ਤਰਕ ਦੀਆਂ ਗਲਤੀਆਂ ਕਰ ਸਕਦੇ ਹਨ। ਅਸਲੀ ਸੁਰੱਖਿਆ ਸੌਫਟਵੇਅਰ ਸੀਮਾ 'ਤੇ ਹੁੰਦੀ ਹੈ।
ਕਿਹੜੇ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਕਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਹ ਸਹੀ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ deco Studio ਦੇ ਅੰਦਰ ਅਲਾਉਲਿਸਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਕੰਟਰੋਲ ਪਲੇਨ ਦੇ ਅੰਦਰ ਸਰਵਰ-ਸਾਈਡ ਚੈਕਸ ਨਾਲ ਉਹਨਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰੋ। ਏ
ਵਿਕਲਪਿਕ ਸਿੱਖਣ ਭਾਈਚਾਰਾ: ਟੈਲੀਗ੍ਰਾਮ 'ਤੇ GyaanSetu AI