ਕੰਟੈਕਸਟ ਵਿੰਡੋਜ਼ (Context Windows) ਬਹੁਤ ਵੱਡੀਆਂ ਹੁੰਦੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ
ਲੋਕ ਹਰ ਚੀਜ਼ ਲਈ 'ਏਜੰਟ' (agent) ਸ਼ਬਦ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।
ਇੱਕ ਫੰਕਸ਼ਨ ਜੋ ਕਿਸੇ ਟੂਲ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਉਹ ਇੱਕ ਏਜੰਟ ਹੈ। ਯਾਦਦਾਸ਼ਤ ਵਾਲਾ ਇੱਕ ਚੈਟਬੋਟ ਇੱਕ ਏਜੰਟ ਹੈ। ਲੂਪ ਵਾਲਾ ਇੱਕ ਸਕ੍ਰਿਪਟ ਇੱਕ ਏਜੰਟ ਹੈ।
ਇਹ ਗਲਤੀ ਮਾੜੀ ਇੰਜੀਨੀਅਰਿੰਗ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ। ਟੀਮਾਂ ਸਧਾਰਨ ਕੰਮਾਂ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਇੰਜੀਨੀਅਰਿੰਗ (over-engineer) ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਗੁੰਝਲਦਾਰ ਕੰਮਾਂ ਲਈ ਬਹੁਤ ਘੱਟ (under-engineer)। ਮੈਂ ਦੇਖਦਾ ਹਾਂ ਕਿ ਟੀਮਾਂ ਉਹਨਾਂ ਵਰਕਫਲੋਜ਼ ਲਈ ਏਜੰਟ ਆਰਕੈਸਟ੍ਰੇਸ਼ਨ (agent orchestration) 'ਤੇ ਹਫ਼ਤੇ ਬਿਤਾਉਂਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਚੰਗੇ ਪ੍ਰੋਂਪਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਇੱਥੇ ਇੱਕ ਅਸਲੀ ਏਜੰਟ ਦੀ ਮੇਰੀ ਪਰਿਭਾਸ਼ਾ ਹੈ।
ਇੱਕ ਏਜੰਟ ਦਾ ਇੱਕ ਉਦੇਸ਼ ਹੁੰਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਅੱਗੇ ਕੀ ਕਰਨਾ ਹੈ। ਇਹ ਅਸਫਲਤਾਵਾਂ (failures) ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। ਇਸਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕਦੋਂ ਰੁਕਣਾ ਹੈ।
ਇਹਨਾਂ ਬੈਂਚਮਾਰਕਸ ਦੀ ਵਰਤੋਂ ਕਰੋ:
- ਜੇਕਰ ਇੱਕ ਇਨਸਾਨ ਨੂੰ ਹਰ ਕਦਮ 'ਤੇ ਮਾਰਗਦਰਸ਼ਨ ਕਰਨਾ ਪਵੇ, ਤਾਂ ਇਹ ਇੱਕ ਚੈਟ ਇੰਟਰਫੇਸ ਹੈ।
- ਜੇਕਰ ਸਿਸਟਮ ਇੱਕ ਅਸਫਲ ਟੂਲ ਕਾਲ ਤੋਂ ਉੱਭਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਏਜੰਟ ਵੱਲ ਵਧ ਰਿਹਾ ਹੈ।
- ਜੇਕਰ ਸਿਸਟਮ ਇੱਕ ਟੀਚੇ ਨੂੰ ਕੰਮਾਂ (tasks) ਵਿੱਚ ਵੰਡਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸੌਂਪਦਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਅਸਲੀ ਏਜੰਟ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਸਫਲ ਏਜੰਟ ਸੀਮਤ (narrow) ਹੁੰਦੇ ਹਨ। ਉਹ ਇੱਕ ਕੰਮ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਦੇ ਹਨ। ਉਹ ਕਸਟਮਰ ਸਪੋਰਟ ਟ੍ਰਾਇਜ (triage) ਜਾਂ ਦਸਤਾਵੇਜ਼ ਕੱਢਣ (document extraction) ਦਾ ਕੰਮ ਕਰਦੇ ਹਨ। ਉਹ ਆਮ ਰੀਜ਼ਨਿੰਗ ਇੰਜਣ (general reasoning engines) ਨਹੀਂ ਹੁੰਦੇ।
ਸਫਲ ਟੀਮਾਂ ਇਹਨਾਂ ਤਿੰਨ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੀਆਂ ਹਨ:
- ਟੂਲ ਡਿਜ਼ਾਈਨ: ਇੰਟਰਫੇਸ ਕਿੰਨਾ ਸਾਫ਼ ਹੈ?
- ਅਸਫਲਤਾ ਨੂੰ ਸੰਭਾਲਣਾ (Failure handling): ਜਦੋਂ ਕੋਈ ਟੂਲ ਕੁਝ ਵੀ ਵਾਪਸ ਨਹੀਂ ਦਿੰਦਾ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?
- ਆਬਜ਼ਰਵੇਬਿਲਟੀ (Observability): ਕੀ ਤੁਸੀਂ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਏਜੰਟ ਨੇ ਕੋਈ ਫੈਸਲਾ ਕਿਉਂ ਲਿਆ?
ਅਸਫਲ ਟੀਮਾਂ ਸਿਰਫ਼ ਇੱਕ ਮਾਡਲ ਨੂੰ ਨਵੇਂ ਮਾਡਲ ਨਾਲ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਬਿਹਤਰ ਨਤੀਜਿਆਂ ਦੀ ਉਮੀਦ ਕਰਦੀਆਂ ਹਨ। ਉਹ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀਆਂ ਹਨ।
LangChain ਜਾਂ CrewAI ਵਰਗੇ ਫਰੇਮਵਰਕ ਹਰ ਮਹੀਨੇ ਬਦਲਦੇ ਹਨ। ਫਰੇਮਵਰਕ ਨਾਲੋਂ ਪੈਟਰਨ (pattern) ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਇਹਨਾਂ ਪੈਟਰਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ:
- ਪਹਿਲਾਂ ਯੋਜਨਾ ਬਣਾਓ ਫਿਰ ਅਮਲ ਕਰੋ: ਰੀਜ਼ਨਿੰਗ ਸਟੈਪ ਨੂੰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਟੈਪ ਤੋਂ ਵੱਖ ਕਰੋ।
- ਰੀਟ੍ਰੀਵਲ (retrieval) ਨੂੰ ਰੀਜ਼ਨਿੰਗ ਤੋਂ ਵੱਖ ਕਰੋ: ਕੰਟੈਕਸਟ ਪ੍ਰਾਪਤ ਕਰਨਾ ਉਸਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲੋਂ ਵੱਖਰਾ ਕੰਮ ਹੈ।
- ਸਪੱਸ਼ਟ ਹੈਂਡਆਫ (Explicit handoffs): ਜਦੋਂ ਇੱਕ ਏਜੰਟ ਦੂਜੇ ਨੂੰ ਕੰਮ ਸੌਂਪਦਾ ਹੈ ਤਾਂ ਸਟ੍ਰਕਚਰਡ ਲੌਗਸ (structured logs) ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਫਰੇਮਵਰਕ ਸਿਰਫ਼ ਇੱਕ ਸਕੈਫੋਲਡਿੰਗ (scaffolding) ਹੈ। ਆਰਕੀਟੈਕਚਰ ਇਮਾਰਤ ਹੈ।
RAG ਸਟੈਂਡਰਡ ਹੈ, ਪਰ ਚੰਕਿੰਗ (chunking) ਅਕਸਰ ਖਰਾਬ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਵੰਡਦੇ ਹੋ, ਤਾਂ ਮਾਡਲ ਕੰਟੈਕਸਟ ਗੁਆ ਲੈਂਦਾ ਹੈ। ਇਸ ਨਾਲ ਹੈਲੂਸੀਨੇਸ਼ਨ (hallucinations) ਹੁੰਦੀਆਂ ਹਨ।
ਜੇਕਰ ਤੁਹਾਡੇ RAG ਨਤੀਜੇ ਬੇਕਾਰ ਹਨ, ਤਾਂ ਆਪਣੀ ਚੰਕਿੰਗ ਅਤੇ ਮੈਟਾਡਾਟਾ (metadata) ਦੀ ਜਾਂਚ ਕਰੋ। ਮਾਡਲ ਸ਼ਾਇਦ ਹੀ ਕਦੇ ਸਮੱਸਿਆ ਹੁੰਦਾ ਹੈ।
ਮਾਡਲ ਬਿਹਤਰ ਹੋਣਗੇ। ਕੰਟੈਕਸਟ ਵਿੰਡੋਜ਼ ਵਧਣਗੀਆਂ। ਟੋਕਨ ਦੀਆਂ ਲਾਗਤਾਂ ਘਟਣਗੀਆਂ।
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅਸਲੀ ਇੰਜੀਨੀਅਰਿੰਗ ਚੁਣੌਤੀ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰਦਾ। ਤੁਹਾਨੂੰ ਅਜਿਹੇ ਸਿਸਟਮ ਬਣਾਉਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਦੇਖਣ ਵੇਲੇ ਨਾ ਹੋਣ 'ਤੇ ਵੀ ਸਹੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ।
ਗਵਰਨੈਂਸ (governance), ਆਬਜ਼ਰਵੇਬਿਲਟੀ (observability), ਅਤੇ ਭਰੋਸੇਯੋਗ ਟੂਲ ਦੀ ਵਰਤੋਂ 'ਤੇ ਧਿਆਨ ਦਿਓ। ਸਭ ਤੋਂ ਵਧੀਆ ਇੰਜੀਨੀਅਰ ਮਾਡਲ ਖੋਜਕਰਤਾ (researchers) ਨਹੀਂ ਹੋਣਗੇ। ਉਹ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨਰ ਹੋਣਗੇ ਜੋ ਭਰੋਸੇਯੋਗ AI ਬਣਾਉਂਦੇ ਹਨ।
Source: https://dev.to/aibughunter/context-windows-are-getting-huge-heres-why-that-changes-everything-2jlh