ਓਪਨ-ਵੇਟ (open-weight) ਲਾਰਜ ਲੈਂਗੂਏਜ ਮਾਡਲਾਂ ਨੇ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਦੇ AI ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਬਾਰੇ ਸੋਚਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਹੈ। ਕਲੋਜ਼ਡ (closed) APIs ਦੇ ਉਲਟ, ਜਿੱਥੇ ਪ੍ਰੋਵਾਈਡਰ ਹਾਰਡਵੇਅਰ, ਮਾਡਲ ਵੇਟਸ (model weights), ਅਤੇ ਰਿਲੀਜ਼ ਸ਼ਡਿਊਲ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦਾ ਹੈ, ਓਪਨ-ਵੇਟ ਮਾਡਲ ਉਹ ਫੈਸਲੇ ਵਾਪਸ ਤੁਹਾਡੇ ਹੱਥ ਵਿੱਚ ਦੇ ਦਿੰਦੇ ਹਨ। ਤੁਸੀਂ ਚੁਣਦੇ ਹੋ ਕਿ ਮਾਡਲ ਕਿੱਥੇ ਰਹੇਗਾ, ਇਸ ਨੂੰ ਕਿਵੇਂ ਟਿਊਨ ਕੀਤਾ ਜਾਵੇਗਾ, ਅਤੇ ਕਦੋਂ—ਜੇ ਕਦੇ—ਤੁਸੀਂ ਨਵੇਂ ਚੈੱਕਪੁਆਇੰਟ (checkpoint) 'ਤੇ ਅਪਡੇਟ ਕਰੋਗੇ। ਮਾਲਕੀ ਦਾ ਇਹ ਪੱਧਰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ, ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦਾ ਕੰਮ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤੁਹਾਡੇ ਮੋਢਿਆਂ 'ਤੇ ਹੁੰਦਾ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ OpenAI ਦੇ GPT-4 ਜਾਂ Anthropic ਦੇ Claude ਵਰਗੇ ਮੈਨੇਜਡ (managed) API ਤੋਂ ਆ ਰਹੇ ਹੋ, ਤਾਂ ਚੰਗੀ ਖ਼ਬਰ ਇਹ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੇ ਓਪਨ-ਵੇਟ ਹੋਸਟਿੰਗ ਪ੍ਰੋਵਾਈਡਰ ਅਤੇ ਇਨਫਰੈਂਸ ਇੰਜਣ (inference engines) ਹੁਣ ਇੱਕੋ ਭਾਸ਼ਾ ਬੋਲਦੇ ਹਨ: HTTP POST, JSON payloads, ਅਤੇ bearer token authentication। ਇਸਦੀ ਕਾਰਜ ਪ੍ਰਣਾਲੀ ਜਾਣੀ-ਪਛਾਣੀ ਲੱਗਦੀ ਹੈ, ਪਰ ਵੇਰਵੇ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਪ੍ਰੋਵਾਈਡਰ ਨਹੀਂ, ਸਗੋਂ ਤੁਸੀਂ ਭਰੋਸੇਯੋਗਤਾ, ਲਾਗਤ ਨਿਯੰਤਰਣ (cost control), ਅਤੇ ਵਿਵਹਾਰ ਨੂੰ ਰੂਪ ਦੇਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋ।

API ਕਾਲ ਦੇ ਮੁੱਢਲੇ ਸਿਧਾਂਤ

ਇਸਦੇ ਮੂਲ ਵਿੱਚ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਇੱਕ POST request ਹੈ। ਤੁਸੀਂ Authorization header ਵਿੱਚ ਇੱਕ ਸਟੈਂਡਰਡ bearer token ਨਾਲ ਪ੍ਰਮਾਣਿਕਤਾ (authenticate) ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ। Body ਇੱਕ JSON object ਹੈ, ਅਤੇ ਇਸਦਾ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਫੀਲਡ messages array ਹੈ। ਉਹ array ਜਾਣੇ-ਪਛਾਣੇ ਚੈਟ ਫਾਰਮੈਟ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ: system, user, ਅਤੇ assistant ਰੋਲ ਦਾ ਵਾਰੀ-ਵਾਰੀ ਆਉਣਾ।

ਇੱਥੇ ਇੱਕ ਮਿਨੀਮਲ ਰਿਕਵੈਸਟ ਸਟ੍ਰਕਚਰ ਦਿੱਤਾ ਗਿਆ ਹੈ:

  • Authorization header ਨੂੰ Bearer <your-token> 'ਤੇ ਸੈੱਟ ਕਰੋ।
  • ਇੱਕ JSON payload ਭੇਜੋ ਜਿਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇੱਕ model identifier ਅਤੇ messages ਦੀ ਲਿਸਟ ਹੋਵੇ।
  • ਜੇਕਰ ਤੁਸੀਂ deterministic ਜਾਂ creative ਕੰਟਰੋਲ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ max_tokens ਅਤੇ temperature ਸ਼ਾਮਲ ਕਰੋ।

ਜਵਾਬ (response) ਇੱਕ choices array ਅਤੇ ਇੱਕ usage object ਦੇ ਨਾਲ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਉਸ usage ਬਲਾਕ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਾ ਕਰੋ। ਇਸ ਵਿੱਚ prompt_tokens, completion_tokens, ਅਤੇ ਕੁੱਲ (total) ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ self-hosting ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਤੁਹਾਡੇ ਲਈ ਸੰਕੇਤ ਹੈ ਕਿ ਕੋਈ ਖਾਸ ਯੂਜ਼ਰ ਇੰਟਰੈਕਸ਼ਨ ਮਹਿੰਗੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਤੀਜੀ-ਪਾਰਟੀ (third-party) ਇਨਫਰੈਂਸ ਪ੍ਰੋਵਾਈਡਰ ਨੂੰ ਭੁਗਤਾਨ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਤੁਹਾਡਾ ਬਿਲਿੰਗ ਡੇਟਾ ਹੈ। ਚਾਹੇ ਜੋ ਵੀ ਹੋਵੇ, ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਹੀ ਇਸਦਾ log ਰੱਖੋ।

Streaming ਅਤੇ ਤੁਹਾਨੂੰ ਇਸਦੀ ਵਰਤੋਂ ਕਿਉਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ

ਕੋਈ ਵੀ ਟੈਕਸਟ ਦਾ ਇੱਕ ਟੁਕੜਾ ਦਿਖਾਈ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਸੈਕਿੰਡ ਤੱਕ loading spinner ਨੂੰ ਦੇਖਣਾ ਪਸੰਦ ਨਹੀਂ ਕਰਦਾ। Streaming ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ। ਮਾਡਲ ਦੇ ਪੂਰੀ completion ਨੂੰ ਖਤਮ ਕਰਨ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਸਰਵਰ tokens ਨੂੰ ਜਿਵੇਂ ਹੀ ਉਹ ਬਣਦੇ ਹਨ, ਭੇਜਦਾ ਰਹਿੰਦਾ ਹੈ। ਤੁਹਾਡਾ client Server-Sent Events ਜਾਂ chunked HTTP responses ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਸ਼ਬਦਾਂ ਨੂੰ ਆਉਂਦੇ ਹੀ ਰੈਂਡਰ (render) ਕਰ ਸਕਦਾ ਹੈ।

ਆਪਣੇ JSON payload ਵਿੱਚ stream: true ਫਲੈਗ ਸੈੱਟ ਕਰਕੇ streaming ਨੂੰ ਚਾਲੂ ਕਰੋ। Client side 'ਤੇ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ stream ਨੂੰ ਲਾਈਨ-ਦਰ-ਲਾਈਨ parse ਕਰੋਗੇ, data: prefixes 'ਤੇ ਨਜ਼ਰ ਰੱਖਦੇ ਹੋਏ। ਜੇਕਰ stream ਦੇ ਵਿਚਕਾਰ ਕਨੈਕਸ਼ਨ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰਨ ਜਾਂ non-streaming retry 'ਤੇ ਵਾਪਸ ਜਾਣ ਲਈ ਤਿਆਰ ਰਹੋ। ਤੁਹਾਡੀ ਚੈਟ ਐਪ ਦੀ perceived latency ਬਹੁਤ ਘੱਟ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਉਹਨਾਂ ਦੇ ਨਾਲ ਸੋਚ ਰਿਹਾ ਹੈ, ਨਾ ਕਿ ਉਹਨਾਂ ਦੀ ਬੇਨਤੀ ਨੂੰ batch-processing ਕਰ ਰਿਹਾ ਹੈ।

ਅਸਲ-ਦੁਨੀਆ ਦੇ ਵਰਕਫਲੋ (Workflows) ਲਈ Function Calling

ਇੱਕ ਮਾਡਲ ਜੋ ਸਿਰਫ਼ ਸਾਦਾ ਟੈਕਸਟ ਵਾਪਸ ਕਰਦਾ ਹੈ ਉਹ ਉਪਯੋਗੀ ਹੈ, ਪਰ ਇੱਕ ਮਾਡਲ ਜੋ tools ਨੂੰ ਕਾਲ (invoke) ਕਰ ਸਕਦਾ ਹੈ ਉਹ ਕਿਤੇ ਜ਼ਿਆਦਾ ਉਪਯੋਗੀ ਹੈ। Function calling ਤੁਹਾਨੂੰ ਉਪਲਬਧ ਕਾਰਜਾਂ (operations) ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲਾ ਇੱਕ JSON schema ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ—ਜਿਵੇਂ ਕਿ search_orders ਜਾਂ update_profile—ਅਤੇ ਮਾਡਲ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਦੋਂ ਕਰਨੀ ਹੈ। ਯੂਜ਼ਰ ਨੂੰ ਫਾਲੋ-ਅੱਪ ਸਵਾਲ ਪੁੱਛਣ ਦੀ ਬਜਾਏ, ਇਹ ਗੱਲਬਾਤ ਵਿੱਚੋਂ ਕੱਢੇ ਗਏ arguments ਦੇ ਨਾਲ ਇੱਕ structured function call ਜਾਰੀ ਕਰਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਕੋਈ ਯੂਜ਼ਰ ਪੁੱਛਦਾ ਹੈ, “ਮੇਰਾ ਆਖਰੀ ਆਰਡਰ ਕੀ ਸੀ?”, ਤਾਂ ਤੁਹਾਡਾ schema limit ਪੈਰਾਮੀਟਰ ਦੇ ਨਾਲ ਇੱਕ get_recent_orders ਫੰਕਸ਼ਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦਾ ਹੈ। ਮਾਡਲ ਇੱਕ tool call ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤੁਹਾਡਾ backend ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਵਿਰੁੱਧ ਕੁਐਰੀ (query) ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਨਤੀਜੇ ਨੂੰ ਇੱਕ function response message ਵਜੋਂ ਮਾਡਲ ਨੂੰ ਵਾਪਸ ਭੇਜਦੇ ਹੋ। ਫਿਰ ਮਾਡਲ ਇੱਕ natural-language ਜਵਾਬ ਤਿਆਰ ਕਰਦਾ ਹੈ।

ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ:

  • ਆਪਣੇ payload ਵਿੱਚ ਇੱਕ tools ਜਾਂ functions array ਪ੍ਰਦਾਨ ਕਰੋ।
  • ਹਰੇਕ tool ਨੂੰ name, description, ਅਤੇ parameters schema ਦੇ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।
  • tool-calls finish reason ਜਾਂ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਕਿਸੇ ਸੰਕੇਤ ਲਈ response ਦੀ ਜਾਂਚ ਕਰੋ।
  • ਆਪਣੇ backend ਵਿੱਚ ਸਖ਼ਤ validation ਦੇ ਨਾਲ ਫੰਕਸ਼ਨ ਨੂੰ ਚਲਾਓ। ਕਦੇ ਵੀ raw model outputs 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ ਕਿ ਉਹ ਬਿਨਾਂ sanitization ਦੇ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਤੱਕ ਪਹੁੰਚਣਗੇ।
  • ਫੰਕਸ਼ਨ ਦੇ ਨਤੀਜੇ ਨੂੰ message history ਵਿੱਚ ਜੋੜੋ ਅਤੇ ਇੱਕ follow-up request ਭੇਜੋ ਤਾਂ ਜੋ ਮਾਡਲ ਅੰਤਿਮ ਜਵਾਬ ਦੇ ਸਕੇ।

ਇਹ ਪੈਟਰਨ generative text ਅਤੇ deterministic systems ਵਿਚਕਾਰਲੀ ਦੂਰੀ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ। ਤੁਹਾਡਾ AI ਬਿਨਾਂ ਹਰ ਬ੍ਰਾਂਚ ਨੂੰ hard-code ਕੀਤੇ ਕੈਲੰਡਰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, APIs ਨੂੰ query ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ webhooks ਨੂੰ trigger ਕਰ ਸਕਦਾ ਹੈ।

Production ਲਈ ਹਾਰਡਨਿੰਗ (Hardening)

Production ਵਿੱਚ ਓਪਨ-ਵੇਟ ਮਾਡਲਾਂ ਨੂੰ ਚਲਾਉਣਾ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ distributed system ਵਾਂਗ ਹੀ ਅਸਫਲਤਾ ਦੇ ਮੋਡਾਂ (failure modes) ਦੇ ਸਾਹਮਣੇ ਲਿਆਉਂਦਾ ਹੈ, ਨਾਲ ਹੀ ਕੁਝ ਵਿਲੱਖਣ ਮੋਡ ਵੀ ਹੁੰਦੇ ਹਨ। Model inference compute-intensive ਹੁੰਦਾ ਹੈ, ਅਤੇ endpoints ਲੋਡ ਹੇਠ ਟੁੱਟ ਸਕਦੇ ਹਨ। ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਥਿਰ ਰੱਖਣ ਦਾ ਤਰੀਕਾ ਇੱਥੇ ਦਿੱਤਾ ਗਿਆ ਹੈ।

Errors ਅਤੇ Retries

  • 429 Too Many Requests: ਇਹ ਇੱਕ ਰੇਟ-ਲਿਮਿਟ ਸਿਗਨਲ ਹੈ। ਜਿੱਟਰ (jitter) ਦੇ ਨਾਲ ਐਕਸਪੋਨੈਂਸ਼ੀਅਲ ਬੈਕਆਫ (exponential backoff) ਲਾਗੂ ਕਰੋ। ਇੱਕ ਛੋਟੀ ਦੇਰੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਵਾਰ-ਵਾਰ 429 ਹੋਣ 'ਤੇ ਇਸਨੂੰ ਦੁੱਗਣਾ ਕਰੋ, ਅਤੇ ਇਸਨੂੰ ਕੁਝ ਸਕਿੰਟਾਂ ਤੱਕ ਸੀਮਤ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਰਵਰ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਬੋਝ ਨਾ ਪਾਓ।
  • 5xx Server Errors: ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਅਸਥਾਈ ਹੁੰਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਜੇਕਰ ਤੁਸੀਂ GPU ਵਰਕਰਾਂ ਦੇ ਪੂਲ ਨੂੰ ਰੂਟ ਕਰ ਰਹੇ ਹੋ। ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ (retry) ਕਰੋ, ਪਰ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਗਿਣਤੀ 'ਤੇ ਇੱਕ ਸਖ਼ਤ ਸੀਮਾ ਲਗਾਓ—ਤਿੰਨ ਇੱਕ ਆਮ ਡਿਫੌਲਟ ਹੈ।
  • 4xx Client Errors: ਇਹਨਾਂ ਨੂੰ ਅੰਨ੍ਹੇਵਾਹ ਰੀਟ੍ਰਾਈ ਨਾ ਕਰੋ। 400 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ payload ਗਲਤ ਹੈ, 401 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ ਟੋਕਨ ਗਲਤ ਹੈ, ਅਤੇ 404 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਸ ਐਂਡਪੁਆਇੰਟ 'ਤੇ ਮਾਡਲ ID ਮੌਜੂਦ ਨਹੀਂ ਹੈ। ਲੂਪ ਕਰਨ ਦੀ ਬਜਾਏ ਰਿਕੁਐਸ ਨੂੰ ਠੀਕ ਕਰੋ।

Timeouts and Hanging Processes

ਜਦੋਂ ਕਿਊਆਂ (queues) ਬਣ ਜਾਂਦੀਆਂ ਹਨ ਜਾਂ ਜਦੋਂ ਕੋਈ ਵਰਕਰ ਜਨਰੇਸ਼ਨ ਦੇ ਵਿਚਕਾਰ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਨਫਰੈਂਸ (inference) ਵਿੱਚ ਦੇਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਹਮੇਸ਼ਾ ਇੱਕ ਰਿਕੁਐਸ ਟਾਈਮਆਊਟ ਸੈੱਟ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡੇ HTTP ਕਲਾਇੰਟ ਦਾ ਡਿਫੌਲਟ ਇਨਫਿਨਿਟੀ (infinity) ਹੈ, ਤਾਂ ਇਸਨੂੰ ਬਦਲੋ। ਸਟੈਂਡਰਡ ਕੰਪਲੀਸ਼ਨਾਂ ਲਈ 30 ਤੋਂ 60 ਸਕਿੰਟ ਇੱਕ ਵਾਜਬ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੈ, ਅਤੇ ਹੈਲਥ ਚੈੱਕ ਲਈ ਇਸ ਤੋਂ ਘੱਟ। ਜੇਕਰ ਟਾਈਮਆਊਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਅਸਫਲਤਾ ਵਜੋਂ ਮੰਨੋ, ਇਸਨੂੰ ਲੌਗ ਕਰੋ, ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ ਨੂੰ ਇੱਕ ਸਹੀ ਐਰਰ ਦਿਖਾਉਣਾ ਹੈ ਜਾਂ ਫਾਲਬੈਕ ਮਾਡਲ 'ਤੇ ਰੀਟ੍ਰਾਈ ਕਰਨਾ ਹੈ।

Budget Control

ਟੋਕਨਾਂ ਦੀ ਗਿਣਤੀ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਪੈਸੇ ਜਾਂ GPU ਘੰਟਿਆਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਹਰ ਰਿਕੁਐਸ ਲਈ ਪ੍ਰੋਂਪਟ (prompt) ਅਤੇ ਕੰਪਲੀਸ਼ਨ (completion) ਟੋਕਨ ਦੋਵਾਂ ਨੂੰ ਲੌਗ ਕਰੋ। ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਤੀ ਉਪਭੋਗਤਾ, ਪ੍ਰਤੀ ਫੀਚਰ, ਅਤੇ ਪ੍ਰਤੀ ਮਾਡਲ ਵਰਜ਼ਨ ਦੇ ਅਨੁਸਾਰ ਟ੍ਰੈਕ ਕਰੋ। ਓਪਨ-ਵੇਟ ਮਾਡਲ ਤੁਹਾਨੂੰ ਚੈੱਕਪੁਆਇੰਟ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਪਰ ਹਰੇਕ ਚੈੱਕਪੁਆਇੰਟ ਦੀ ਆਪਣੀ ਲਾਗਤ ਪ੍ਰੋਫਾਈਲ ਅਤੇ ਕੰਟੈਕਸ-ਵਿੰਡੋ (context-window) ਦਾ ਆਕਾਰ ਹੁੰਦਾ ਹੈ। ਲੌਗਸ ਤੋਂ ਬਿਨਾਂ, ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਲੱਗੇਗਾ ਕਿ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦਾ ਕਿਹੜਾ ਹਿੱਸਾ ਕੰਪਿਊਟਿੰਗ ਸ਼ਕਤੀ (compute) ਖਰਾਬ ਕਰ ਰਿਹਾ ਹੈ।

Behavior Shaping with System Messages

ਸਿਸਟਮ ਮੈਸੇਜ ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਦੀ ਪਹਿਲੀ ਲਾਈਨ ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਟੋਨ ਸੈੱਟ ਕਰਨ, ਪਾਬੰਦੀਆਂ ਲਾਗੂ ਕਰਨ, ਅਤੇ ਉਹ ਸਟੈਟਿਕ ਕੰਟੈਕਸ (static context) ਦੇਣ ਲਈ ਕਰੋ ਜਿਸਦਾ ਹਰ ਉਪਭੋਗਤਾ ਗੱਲਬਾਤ ਨੂੰ ਸਨਮਾਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਕਿਉਂਕਿ ਓਪਨ-ਵੇਟ ਮਾਡਲ ਉਹਨਾਂ ਦੀ ਫਾਈਨ-ਟਿਊਨਿੰਗ ਅਤੇ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਦੇ ਅਨੁਸਾਰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ, ਇਸ ਫੀਲਡ ਨੂੰ ਇੱਕ ਵੇਰੀਏਬਲ ਵਜੋਂ ਮੰਨੋ ਜਿਸਦਾ ਤੁਸੀਂ A/B ਟੈਸਟ ਕਰਦੇ ਹੋ। ਇੱਕ ਅਸਪਸ਼ਟ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਅਸਪਸ਼ਟ ਉੱਤਰ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਸਪਸ਼ਟ ਪ੍ਰੋਂਪਟ ਮਾਡਲ ਨੂੰ ਸਹੀ ਰਸਤੇ 'ਤੇ ਰੱਖਦਾ ਹੈ—ਉਦਾਹਰਨ ਲਈ, ਸਹਾਇਕ (assistant) ਨੂੰ ਇਹ ਦੱਸਣਾ ਕਿ ਉਹ ਸਿਰਫ ਬਿਲਿੰਗ ਅਤੇ ਰਿਟਰਨ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਸਭ ਕੁਝ ਨਿਮਰਤਾ ਨਾਲ ਮਨ੍ਹਾ ਕਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।

Infrastructure Freedom and Data Sovereignty

ਓਪਨ-ਵੇਟ ਮਾਡਲਾਂ ਦੇ ਸ਼ਾਂਤ ਲਾਭਾਂ ਵਿੱਚੋਂ ਇੱਕ ਕਸਟਡੀ (custody) ਹੈ। ਤੁਹਾਡੇ ਪ੍ਰੋਂਪਟ ਅਤੇ ਕੰਪਲੀਸ਼ਨਾਂ ਨੂੰ ਤੁਹਾਡੇ ਵਾਤਾਵਰਣ ਤੋਂ ਬਾਹਰ ਜਾਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ ਆਨ-ਪ੍ਰੇਮਿਸ (on-premises) ਜਾਂ ਵਰਚੁਅਲ ਪ੍ਰਾਈਵੇਟ ਕਲਾਉਡ ਦੇ ਅੰਦਰ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਤੀਜੀ-ਪਾਰਟੀ ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਸਮਝੌਤਿਆਂ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੇ ਹੋ ਅਤੇ ਟ੍ਰੇਨਿੰਗ-ਡਾਟਾ ਵਿਵਾਦਾਂ ਦੇ ਖਤਰੇ ਨੂੰ ਘਟਾਉਂਦੇ ਹੋ। ਇਹ ਹੈਲਥਕੇਅਰ, ਫਾਈਨਾਂਸ, ਅਤੇ ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਖੇਤਰ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਿੱਥੇ ਡੇਟਾ ਲੀਕ ਹੋਣਾ ਇੱਕ ਕੰਪਲਾਇੰਸ (compliance) ਘਟਨਾ ਹੈ।

ਭਾਵੇਂ ਤੁਸੀਂ ਬਾਹਰੀ ਇਨਫਰੈਂਸ ਹੋਸਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਓਪਨ ਵੇਟਸ ਤੁਹਾਨੂੰ ਪੋਰਟੇਬਿਲਟੀ (portability) ਦਿੰਦੇ ਹਨ। ਜੇਕਰ ਹੋਸਟ ਕੀਮਤਾਂ ਜਾਂ ਸ਼ਰਤਾਂ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਹੀ ਮਾਡਲ ਫਾਈਲਾਂ ਕਿਸੇ ਹੋਰ ਪ੍ਰਦਾਤਾ ਕੋਲ ਲੈ ਜਾ ਸਕਦੇ ਹੋ ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਇਨ-ਹਾਊਸ (in-house) ਲਿਆ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਕਿਸੇ ਇੱਕ API ਤੱਕ ਸੀਮਤ ਨਹੀਂ ਹੋ ਕਿਉਂਕਿ ਵੇਟਸ (weights) ਰੱਖਣ ਵਾਲੀ ਸਿਰਫ ਇੱਕ ਹੀ ਕੰਪਨੀ ਹੈ।

A Practical Starting Point

ਜੇਕਰ ਤੁਸੀਂ ਅੱਜ ਹੀ ਇੰਟੀਗ੍ਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਸਿੰਗਲ ਮਾਡਲ ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਐਂਡਪੁਆਇੰਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਆਪਣੇ HTTP ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ ਛੋਟੇ ਐਬਸਟਰੈਕਸ਼ਨ ਲੇਅਰ (abstraction layer) ਵਿੱਚ ਲਪੇਟੋ ਜੋ ਪ੍ਰਮਾਣਿਕਤਾ (authentication), ਰੀਟ੍ਰਾਈਜ਼, ਅਤੇ ਟੋਕਨ ਲੌਗਿੰਗ ਨੂੰ ਸੰਭਾਲਦਾ ਹੋਵੇ। ਇਸ ਤੋਂ ਬਾਅਦ ਸਟ੍ਰੀਮਿੰਗ (streaming) ਸ਼ਾਮਲ ਕਰੋ, ਕਿਉਂਕਿ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਦਾ ਫਾਇਦਾ ਤੁਰੰਤ ਮਿਲਦਾ ਹੈ। ਫਿਰ ਇੱਕ ਉੱਚ-ਮੁੱਲ ਵਰਕਫਲੋ ਲਈ ਇੱਕ ਫੰਕਸ਼ਨ ਕਾਲ ਪੇਸ਼ ਕਰੋ—ਸਟੇਟਸ ਲੁੱਕਅੱਪ, ਕੰਟੈਂਟ ਮੋਡਰੇਸ਼ਨ, ਜਾਂ ਫਾਰਮ ਫਿਲਿੰਗ। ਰੋਲਆਊਟ ਨੂੰ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਹਫ਼ਤੇ ਲਈ ਲੈਟੈਂਸੀ (latency), ਐਰ ਰੇਟਸ, ਅਤੇ ਟੋਕਨ ਖਰਚੇ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ।

ਓਪਨ-ਵੇਟ ਮਾਡਲਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੈਨੇਜਡ API ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸੈੱਟਅੱਪ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪਰ ਉਹ ਪਾਰਦਰਸ਼ਤਾ, ਲਚਕਤਾ ਅਤੇ ਕੰਟਰੋਲ ਨਾਲ ਉਸ ਮਿਹਨਤ ਦਾ ਫਲ ਦਿੰਦੇ ਹਨ। ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਨੂੰ ਧਿਆਨ ਨਾਲ ਬਣਾਓ, ਹਰ ਚੀਜ਼ ਨੂੰ ਇੰਸਟਰੂਮੈਂਟ (instrument) ਕਰੋ, ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ AI ਲੇਅਰ ਹੋਵੇਗੀ ਜੋ ਬਿਲਕੁਲ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਵਿਵਹਾਰ ਕਰੇਗੀ ਜਿਸਦੀ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਲੋੜ ਹੈ।

Sources and further reading