ਅਸੀਂ 96% ਟੋਕਨ ਬਚਤ ਨੂੰ ਕਿਉਂ ਰੱਦ ਕਰ ਦਿੱਤਾ
ਸਾਨੂੰ ਇੱਕ MCP server ਮਿਲਿਆ ਜੋ ਟੋਕਨਾਂ 'ਤੇ 96% ਦੀ ਬਚਤ ਕਰਦਾ ਹੈ। ਇਹ ਇੱਕ ਹੀ tool ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ: execute_code। ਖਾਸ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਕਾਲ ਕਰਨ ਦੀ ਬਜਾਏ, agent ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ JavaScript ਲਿਖਦਾ ਹੈ।
ਕਾਗਜ਼ੀ ਤੌਰ 'ਤੇ, ਇਹ ਜੇਤੂ ਹੈ। ਗੁੰਝਲਦਾਰ ਕੰਮਾਂ ਲਈ, code execution ਕੁਸ਼ਲਤਾ ਲਈ tool-calling ਨੂੰ ਪਛਾੜ ਦਿੰਦਾ ਹੈ।
ਪਰ ਅਸੀਂ ਇਸਨੂੰ ਅਪਣਾਇਆ ਨਹੀਂ। ਇਸਦੀ ਬਜਾਏ ਅਸੀਂ ਆਪਣੇ ਵੱਖਰੇ, ਨਾਮ ਵਾਲੇ tools ਨੂੰ ਹੀ ਰੱਖਿਆ।
ਇੱਥੇ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਸਾਡੇ agent ਲਈ ਸਾਫ਼ ਦਿਖਣ ਵਾਲਾ ਚੋਣ ਕਿਉਂ ਗਲਤ ਚੋਣ ਸੀ।
The Target Determines the Design
ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਚੈਟ ਵਿੰਡੋ ਵਿੱਚ frontier models ਲਈ ਬਣਾਉਂਦੇ ਹਨ। ਉਹਨਾਂ ਮਾਡਲਾਂ ਕੋਲ ਟੋਕਨਾਂ ਦਾ ਬਹੁਤ ਵੱਡਾ ਬਜਟ ਹੁੰਦਾ ਹੈ। ਉਹਨਾਂ ਲਈ, code execution ਸਭ ਤੋਂ ਉੱਤਮ ਹੈ।
ਅਸੀਂ ਇੱਕ ਕਿਸ਼ਤੀ 'ਤੇ ਇੱਕ ਛੋਟੇ local model (Hermes 3 8B) 'ਤੇ voice-first agent ਲਈ ਬਣਾਉਂਦੇ ਹਾਂ।
ਇੱਕ ਛੋਟੇ ਮਾਡਲ ਲਈ, ਰੁਕਾਵਟ ਟੋਕਨ ਨਹੀਂ ਹਨ। ਰੁਕਾਵਟ ਭਰੋਸੇਯੋਗਤਾ (reliability) ਹੈ।
ਜੇਕਰ ਇੱਕ ਛੋਟਾ ਮਾਡਲ ਇੱਕ ਸਧਾਰਨ tool ਨੂੰ ਕਾਲ ਕਰਨ ਵਿੱਚ ਸੰਘਰਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਸਹੀ JavaScript ਲਿਖਣ ਲਈ ਕਹਿਣਾ ਕਿਤੇ ਜ਼ਿਆਦਾ ਔਖਾ ਕੰਮ ਹੈ। execute_code ਟੋਕਨਾਂ ਲਈ ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਸੌਦਾ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਅਜਿਹਾ ਸੌਦਾ ਨਹੀਂ ਕਰ ਸਕਦੇ।
The Last-Mile Problem
Code execution ਕੰਮ ਦੇ "last mile" ਨੂੰ agent 'ਤੇ ਸੁੱਟ ਦਿੰਦਾ ਹੈ। Agent ਨੂੰ ਇਹ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:
- ਡੇਟਾ ਨੂੰ ਫਿਲਟਰ ਕਰਨਾ
- ਨਤੀਜਿਆਂ ਨੂੰ ਸੌਰਟ ਕਰਨਾ
- ਆਉਟਪੁੱਟ ਨੂੰ ਫਾਰਮੈਟ ਕਰਨਾ
ਸਾਡੇ tools ਇਹ ਕੰਮ server ਦੇ ਅੰਦਰ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਬੈਟਰੀ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਪੁੱਛਣ ਵੇਲੇ, ਸਾਡਾ tool text-to-speech ਲਈ ਤਿਆਰ ਇੱਕ string ਵਾਪਸ ਕਰਦਾ ਹੈ। ਇਹ ਕੱਚੇ ਅੰਕਾਂ ਦੀ ਬਜਾਏ "68 percent, 12.8 volts" ਕਹਿੰਦਾ ਹੈ।
ਜੇਕਰ ਅਸੀਂ execute_code ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਤਾਂ agent ਨੂੰ ਉਸ ਭਾਸ਼ਣ ਨੂੰ ਫਾਰਮੈਟ ਕਰਨ ਲਈ ਲੌਜਿਕ ਲਿਖਣਾ ਪਵੇਗਾ। ਛੋਟੇ ਮਾਡਲ ਇਸ ਵਿੱਚ ਲਗਾਤਾਰ ਅਸਫਲ ਰਹਿੰਦੇ ਹਨ।
The Absence Rule
ਇੱਕ ਕਿਸ਼ਤੀ 'ਤੇ, sensors offline ਹੋ ਜਾਂਦੇ ਹਨ। ਸਾਡੇ ਸਿਸਟਮ ਵਿੱਚ, ਇੱਕ ਗੁੰਮ ਹੋਇਆ sensor ਇੱਕ ਸਾਫ਼ null ਵਾਪਸ ਕਰਦਾ ਹੈ। ਇਹ ਇੱਕ ਸਫਲ ਕਾਲ ਹੈ।
Code execution ਮਾਡਲ ਵਿੱਚ, ਇੱਕ ਗੁੰਮ ਹੋਇਆ sensor ਅਕਸਰ ਇੱਕ error ਦਿੰਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਛੋਟਾ ਮਾਡਲ ਕੁਝ ਗਲਤ ਰਸਤੇ ਅੰਦਾਜ਼ੇ ਨਾਲ ਚੁਣਦਾ ਹੈ, ਤਾਂ ਇਹ error limits ਨੂੰ ਤ੍ਰਿਗਰ ਕਰਦਾ ਹੈ ਅਤੇ agent ਨੂੰ ਖਰਾਬ ਕਰ ਦਿੰਦਾ ਹੈ। Named tools ਸਾਨੂੰ ਗੈਰ-ਹਾਜ਼ਰੀ ਨੂੰ ਇੱਕ ਸਫਲਤਾ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਨਾ ਕਿ ਇੱਕ ਗਲਤੀ।
Adopt-vs-Build Checklist
ਕਿਸੇ MCP server ਨੂੰ ਅਪਣਾਉਣ ਜਾਂ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਵਾਲ ਪੁੱਛੋ:
• ਟਾਰਗੇਟ agent ਕੌਣ ਹੈ? (Frontier model ਬਨਾਮ Small local model) • ਮੁੱਖ ਰੁਕਾਵਟ ਕੀ ਹੈ? (Tokens ਬਨਾਮ Reliability) • Last mile ਕੌਣ ਕਰਦਾ ਹੈ? (ਕੀ tool ਡੇਟਾ ਫਾਰਮੈਟ ਕਰਦਾ ਹੈ ਜਾਂ agent?) • ਇਹ ਗੈਰ-ਹਾਜ਼ਰੀ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਹੈ? (ਕੀ ਗੁੰਮ ਹੋਈ ਵੈਲਯੂ ਇੱਕ error ਹੈ ਜਾਂ null?) • ਰੱਖ-ਰਖਾਅ ਦੀ ਲਾਗਤ ਕੀ ਹੈ? (ਕੀ ਤੁਸੀਂ ਇੱਕ ਸੁੱਤੀ ਹੋਈ codebase ਨੂੰ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈ ਰਹੇ ਹੋ?)
ਅਸੀਂ ਦੂਜੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਹੀਂ ਕੀਤਾ। ਅਸੀਂ ਇਸਦੇ ਵਿਚਾਰਾਂ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ। ਅਸੀਂ ਉਹਨਾਂ ਦੇ alarm handling ਅਤੇ path discovery logic ਨੂੰ ਲਿਆ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ roadmap ਵਿੱਚ ਜੋੜ ਦਿੱਤਾ।
ਕੁਸ਼ਲਤਾ ਵਧੀਆ ਹੈ, ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਪਾਣੀ ਵਿੱਚ ਹੁੰਦੇ ਹੋ ਤਾਂ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।