ਅਜਿਹੇ AI ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣਾ ਜੋ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਹ ਸਿਰਫ਼ ਇੱਕ ਸੰਪੂਰਨ ਪ੍ਰੋਂਪਟ (prompt) ਤਿਆਰ ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਉਸ ਜਾਣਕਾਰੀ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਬਾਰੇ ਹੈ ਜੋ ਤੁਸੀਂ ਮਾਡਲ ਵਿੱਚ ਭੇਜਦੇ ਹੋ। ਜੇਕਰ ਤੁਸੀਂ ਕਦੇ ਕਿਸੇ ਸਹਾਇਕ (assistant) ਨਾਲ ਲੰਬੀ ਚੈਟ ਕੀਤੀ ਹੈ ਅਤੇ ਅਚਾਨਕ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਉਹ ਤੁਹਾਡੀ ਦਸ ਮਿੰਟ ਪਹਿਲਾਂ ਕਹੀ ਗੱਲ ਭੁੱਲ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਮਹਿਸੂਸ ਕਰ ਚੁੱਕੇ ਹੋ ਕਿ ਜਦੋਂ ਕੰਟੈਕਸ ਇੰਜੀਨੀਅਰਿੰਗ (context engineering) ਅਸਫਲ ਹੁੰਦੀ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ। ਇਹ ਮੰਨ ਲੈਣਾ ਸੌਖਾ ਹੈ ਕਿ AI ਦੀ ਯਾਦਦਾਸ਼ਤ ਖਰਾਬ ਹੈ। ਅਸਲ ਵਿੱਚ, ਤੁਸੀਂ ਕੰਟੈਕਸ ਵਿੰਡੋ (context window) ਦੀਆਂ ਸਖ਼ਤ ਸੀਮਾਵਾਂ ਨਾਲ ਟਕਰਾ ਰਹੇ ਸੀ।

ਭਰੋਸੇਯੋਗ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਤਿੰਨ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ: ਟੋਕਨ (tokens), ਕੰਟੈਕਸ ਵਿੰਡੋਜ਼ (context windows), ਅਤੇ ਕੰਟੈਕਸ ਅਤੇ ਮੈਮੋਰੀ (memory) ਵਿਚਕਾਰ ਅੰਤਰ।

ਟੋਕਨ ਹੀ ਅਸਲ ਕਰੰਸੀ ਹਨ

ਇੱਕ ਟੋਕਨ ਕੋਈ ਸ਼ਬਦ ਨਹੀਂ ਹੁੰਦਾ। ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਮਾਡਲ ਨੂੰ ਟੈਕਸਟ ਭੇਜਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਟੋਕਨਾਈਜ਼ਰ (tokenizer) ਇਸਨੂੰ ਛੋਟੇ-ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦਾ ਹੈ। "cat" ਜਾਂ "the" ਵਰਗੇ ਛੋਟੇ ਆਮ ਸ਼ਬਦ ਇੱਕ-ਇੱਕ ਟੋਕਨ ਲੈ ਸਕਦੇ ਹਨ। "internationalization" ਵਰਗਾ ਗੁੰਝਲਦਾਰ ਤਕਨੀਕੀ ਸ਼ਬਦ ਕਈ ਟੋਕਨਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। ਵਿਰਾਮ ਚਿੰਨ੍ਹ (punctuation), ਸਪੇਸ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਚਰਿੱਤਰ ਵੀ ਗਿਣੇ ਜਾਂਦੇ ਹਨ। ਇਹ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਟੋਕਨ ਹੀ ਸਭ ਕੁਝ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ: ਤੁਹਾਡਾ API ਬਿੱਲ, ਜਵਾਬ ਦੀ ਰਫ਼ਤਾਰ, ਅਤੇ ਆਉਟਪੁੱਟ (output) ਦੀ ਗੁਣਵੱਤਾ।

ਉਹ ਡਿਵੈਲਪਰ ਜੋ ਸ਼ਬਦਾਂ ਨੂੰ ਗਿਣ ਕੇ ਲਾਗਤ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦਾ ਹੈ, ਉਹ ਅੰਧੇਰੇ ਵਿੱਚ ਤੈਰ ਰਿਹਾ ਹੈ। ਕੋਡ ਬ੍ਰੈਕਟਾਂ ਅਤੇ ਲੰਬੇ ਵੇਰੀਏਬਲ ਨਾਮਾਂ (variable names) ਨਾਲ ਭਰਿਆ ਇੱਕ ਸੌ ਸ਼ਬਦਾਂ ਦਾ ਪ੍ਰੋਂਪਟ ਉਮੀਦ ਤੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਖਰਚਾ ਵਧਾ ਸਕਦਾ ਹੈ। ਇਸੇ ਲਈ ਟੋਕਨਾਈਜ਼ਰ ਸੁਤੰਤਰ ਸਾਧਨਾਂ ਵਜੋਂ ਮੌਜੂਦ ਹਨ। ਕੋਈ ਫੀਚਰ ਲਾਂਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੇ ਆਮ ਪੇਲੋਡ (payloads) ਨੂੰ ਇੱਕ ਟੋਕਨਾਈਜ਼ਰ ਰਾਹੀਂ ਚਲਾ ਕੇ ਦੇਖੋ। ਤੁਸੀਂ ਅਕਸਰ ਦੇਖੋਗੇ ਕਿ ਸਿਸਟਮ ਹਦਾਇਤਾਂ, ਫਾਰਮੈਟਿੰਗ ਬੁਆਇਲਰਪਲੇਟ (boilerplate), ਅਤੇ ਚੈਟ ਇਤਿਹਾਸ ਅਸਲ ਯੂਜ਼ਰ ਕੁਐਰੀ (user query) ਨਾਲੋਂ ਤੁਹਾਡੇ ਬਜਟ ਦਾ ਵੱਧ ਹਿੱਸਾ ਖਤਮ ਕਰਦੇ ਹਨ। ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਹੀ ਟੋਕਨਾਂ ਨੂੰ ਇੱਕ ਸੀਮਤ ਸਰੋਤ ਵਜੋਂ ਮੰਨੋ।

ਕੰਟੈਕਸ ਵਿੰਡੋ ਇੱਕ ਨਿਸ਼ਚਿਤ ਵ੍ਹਾਈਟਬੋਰਡ ਵਾਂਗ ਹੈ

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

ਆਧੁਨਿਕ ਮਾਡਲ ਕੁਝ ਹਜ਼ਾਰ ਟੋਕਨਾਂ ਤੋਂ ਲੈ ਕੇ ਲੱਖਾਂ ਟੋਕਨਾਂ ਤੱਕ ਦੀਆਂ ਕੰਟੈਕਸ ਵਿੰਡੋਜ਼ ਦਾ ਦਾਅਵਾ ਕਰਦੇ ਹਨ। ਵੱਡੀ ਵਿੰਡੋ ਨੂੰ ਅਸੀਮਤ ਸਟੋਰੇਜ ਵਜੋਂ ਮੰਨਣਾ ਲ tempting (ਆਕਰਸ਼ਕ) ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਅਜਿਹਾ ਨਹੀਂ ਹੈ। ਵ੍ਹਾਈਟਬੋਰਡ ਦੀਆਂ ਵੀ ਹੱਦਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਜਦੋਂ ਇਤਿਹਾਸ ਸੀਮਾ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਪੁਰਾਣੇ ਸੁਨੇਹੇ ਡਿਲੀਟ ਕਰਨੇ ਪੈਂਦੇ ਹਨ ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਕੰਪਰੈਸ (compress) ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਇਸ ਸੀਮਾ ਨੂੰ ਸਮਝਣ ਨਾਲ ਤੁਹਾਨੂੰ ਵਿੰਡੋ ਨੂੰ ਡਾਟਾਬੇਸ ਵਜੋਂ ਦੇਖਣ ਦੀ ਬਜਾਏ ਇੱਕ ਸਰਗਰਮ ਵਰਕਸਪੇਸ (workspace) ਵਜੋਂ ਦੇਖਣ ਵਿੱਚ ਮਦਦ ਮਿਲਦੀ ਹੈ।

ਕੰਟੈਕਸ ਮੈਮੋਰੀ ਨਹੀਂ ਹੈ

ਇੱਥੇ ਇੱਕ ਅਜਿਹਾ ਅੰਤਰ ਹੈ ਜੋ ਤਜਰਬੇਕਾਰ ਬਿਲਡਰਾਂ ਨੂੰ ਵੀ ਉਲਝਾ ਦਿੰਦਾ ਹੈ। ਮਾਡਲ ਖੁਦ 'ਸਟੇਟਲੈੱਸ' (stateless) ਹੁੰਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਕੱਲ੍ਹ, ਪਿਛਲੇ ਹਫ਼ਤੇ, ਜਾਂ ਕਿਸੇ ਵੱਖਰੇ ਸੈਸ਼ਨ ਵਿੱਚ ਦਸ ਮਿੰਟ ਪਹਿਲਾਂ ਤੋਂ ਯਾਦ ਨਹੀਂ ਰੱਖਦਾ। ਜਦੋਂ ਕੋਈ AI ਅਜਿਹਾ ਲੱਗਦਾ ਹੈ ਕਿ ਉਸਨੂੰ ਯਾਦ ਹੈ ਕਿ ਤੁਸੀਂ JavaScript ਦੀ ਬਜਾਏ Python ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹੋ, ਜਾਂ ਤੁਹਾਨੂੰ ਸੰਖੇਪ ਜਵਾਬ ਪਸੰਦ ਹਨ, ਤਾਂ ਉਹ ਮੈਮੋਰੀ ਐਪਲੀਕੇਸ਼ਨ ਲੇਅਰ (application layer) ਵਿੱਚ ਹੁੰਦੀ ਹੈ, ਮਾਡਲ ਵਿੱਚ ਨਹੀਂ।

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

ਜ਼ਿਆਦਾ ਕੰਟੈਕਸ ਕਿਉਂ ਉਲਟਾ ਅਸਰ ਕਰ ਸਕਦਾ ਹੈ

ਆਮ ਅਕਲ ਕਹ

Send only what the task requires. If a user asks about your refund policy, do not include the employee handbook, the API documentation, and last quarter’s marketing copy. Relevance beats comprehensiveness.

Use RAG to retrieve relevant documents. Retrieval-Augmented Generation lets you search a large knowledge base and inject only the top-matching passages into the prompt. Instead of dumping a thousand-page manual into the window, you embed your documents, run a semantic search against the user’s query, and include the three most relevant paragraphs. The model gets exactly what it needs, and your token budget stays intact.

Summarize old conversations. Full chat transcripts are expensive and noisy. Replace lengthy message histories with running summaries. For example, instead of feeding the model thirty back-and-forth messages, store a single paragraph: "The user asked about Django deployment, encountered a static files error, and fixed permissions. The current issue is a database migration failing on Postgres 14." That summary preserves state without cluttering the whiteboard.

Separate long-term memory from active chat. User preferences, project settings, and account history belong in an external memory store. Query that store selectively. The live context window should carry only the immediate task and the briefest personal context needed to maintain continuity.

Monitor token usage in production. Latency spikes often trace directly to context bloat. Set alerts when requests approach your model’s limit. Review logs to identify prompts carrying dead weight. Optimization starts with the same question every time: what can we remove without breaking the task?

The Real Takeaway

The best AI applications do not win because they have the biggest context windows. They win because they manage context with discipline. A massive whiteboard is useless if it is covered in scribbles. Build systems that retrieve, summarize, and filter. Your users get faster answers, your infrastructure costs stay predictable, and your models finally pay attention to what actually matters.

Source: AI Context Engineering: Tokens, Context Windows, & Memory

Community: GyaanSetu AI on Telegram