ನಾವು 96% ಟೋಕನ್ ಉಳಿತಾಯವನ್ನು ಏಕೆ ತಿರಸ್ಕರಿಸಿದೆವು

ಟೋಕನ್‌ಗಳಲ್ಲಿ 96% ಉಳಿತಾಯ ಮಾಡುವ ಒಂದು MCP server ಅನ್ನು ನಾವು ಕಂಡುಕೊಂಡೆವು. ಇದು ಕೇವಲ ಒಂದು tool ಅನ್ನು ಬಳಸುತ್ತದೆ: execute_code. ನಿರ್ದಿಷ್ಟ ಫಂಕ್ಷನ್‌ಗಳನ್ನು (functions) ಕರೆಯುವ ಬದಲಿಗೆ, ಏಜೆಂಟ್ ಡೇಟಾವನ್ನು ಪಡೆಯಲು JavaScript ಅನ್ನು ಬರೆಯುತ್ತದೆ.

ಕಾಗದದ ಮೇಲೆ ಇದು ಗೆಲ್ಲುತ್ತದೆ. ಸಂಕೀರ್ಣ ಕಾರ್ಯಗಳಿಗಾಗಿ, ದಕ್ಷತೆಯ ವಿಷಯದಲ್ಲಿ tool-calling ಗಿಂತ code execution ಉತ್ತಮವಾಗಿದೆ.

ಆದರೆ ನಾವು ಅದನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಲಿಲ್ಲ. ಬದಲಿಗೆ ನಾವು ನಮ್ಮ ಪ್ರತ್ಯೇಕವಾದ, ಹೆಸರಿಡಲಾದ tools ಅನ್ನು ಹಾಗೆಯೇ ಇರಿಸಿಕೊಂಡೆವು.

ನಮ್ಮ ಏಜೆಂಟ್‌ಗೆ ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣುವ ಆಯ್ಕೆಯು ಏಕೆ ತಪ್ಪು ಆಯ್ಕೆಯಾಯಿತು ಎಂಬ ಕಾರಣ ಇಲ್ಲಿದೆ.

ಗುರಿಯು ವಿನ್ಯಾಸವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ

ಹೆಚ್ಚಿನ ಜನರು ಚಾಟ್ ವಿಂಡೋದಲ್ಲಿರುವ frontier models ಗಾಗಿ ನಿರ್ಮಿಸುತ್ತಾರೆ. ಆ ಮಾದರಿಗಳು (models) ದೊಡ್ಡ ಪ್ರಮಾಣದ ಟೋಕನ್ ಬಜೆಟ್ ಹೊಂದಿವೆ. ಅವುಗಳಿಗೆ, code execution ಅತ್ಯುತ್ತಮವಾದುದು.

ನಾವು ದೋಣಿಯಲ್ಲಿದ್ದಾಗ ಬಳಸುವ ಸಣ್ಣ ಲೋಕಲ್ ಮಾಡೆಲ್ (Hermes 3 8B) ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ voice-first ಏಜೆಂಟ್‌ಗಾಗಿ ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ.

ಸಣ್ಣ ಮಾಡೆಲ್‌ಗೆ, ಮಿತಿ ಟೋಕನ್‌ಗಳಲ್ಲ. ಮಿತಿಯು ವಿಶ್ವಾಸಾರ್ಹತೆ (reliability).

ಒಂದು ಸಣ್ಣ ಮಾಡೆಲ್ ಸರಳವಾದ tool ಅನ್ನು ಕರೆಯಲು ಕಷ್ಟಪಡುತ್ತಿದ್ದರೆ, ಅದಕ್ಕೆ ಸರಿಯಾದ JavaScript ಬರೆಯಲು ಹೇಳುವುದು ಇನ್ನೂ ಕಷ್ಟದ ಕೆಲಸವಾಗಿದೆ. execute_code ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಬದಲಿಗೆ ಟೋಕನ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ. ಆ ಬದಲಾವಣೆಯನ್ನು ನಮಗೆ ಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ.

Last-Mile ಸಮಸ್ಯೆ

Code execution ಕೆಲಸದ "last mile" ಅನ್ನು ಏಜೆಂಟ್ ಮೇಲೆ ಹಾಕುತ್ತದೆ. ಏಜೆಂಟ್ ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡಲೇಬೇಕು:

• ಡೇಟಾವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವುದು
• ಫಲಿತಾಂಶಗಳನ್ನು ವಿಂಗಡಿಸುವುದು
• ಔಟ್‌ಪುಟ್ ಅನ್ನು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡುವುದು

ನಮ್ಮ tools ಈ ಕೆಲಸವನ್ನು ಸರ್ವರ್‌ನ ಒಳಗಡೆಯೇ ಮಾಡುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಬ್ಯಾಟರಿ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಕೇಳಿದಾಗ, ನಮ್ಮ tool text-to-speech ಗಾಗಿ ಸಿದ್ಧವಾಗಿರುವ string ಅನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಕೇವಲ ಅಂಕಿಅಂಶಗಳ ಬದಲಿಗೆ "68 percent, 12.8 volts" ಎಂದು ಹೇಳುತ್ತದೆ.

ನಾವು execute_code ಬಳಸಿದರೆ, ಆ ಮಾತನ್ನು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಲು ಏಜೆಂಟ್ ತಾನೇ ಲಾಜಿಕ್ ಬರೆಯಬೇಕಾಗುತ್ತದೆ. ಸಣ್ಣ ಮಾಡೆಲ್‌ಗಳು ಇದರಲ್ಲಿ ಪದೇ ಪದೇ ವಿಫಲವಾಗುತ್ತವೆ.

Absence ನಿಯಮ

ದೋಣಿಯಲ್ಲಿರುವಾಗ, ಸೆನ್ಸರ್‌ಗಳು ಆಫ್ ಲೈನ್ ಆಗಬಹುದು. ನಮ್ಮ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಇಲ್ಲದ ಸೆನ್ಸರ್ ಒಂದು ಕ್ಲೀನ್ null ಅನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಯಶಸ್ವಿ ಕರೆಯಾಗಿದೆ (successful call).

Code execution ಮಾಡೆಲ್‌ನಲ್ಲಿ, ಇಲ್ಲದ ಸೆನ್ಸರ್ ಹೆಚ್ಚಾಗಿ error ಅನ್ನು ನೀಡುತ್ತದೆ. ಒಂದು ಸಣ್ಣ ಮಾಡೆಲ್ ಕೆಲವು ತಪ್ಪು ದಾರಿಗಳನ್ನು ಅಂದಾಜಿಸಿದರೆ, ಅದು error ಮಿತಿಗಳನ್ನು ತಲುಪಿ ಏಜೆಂಟ್ ಅನ್ನು ಸ್ಥಗಿತಗೊಳಿಸುತ್ತದೆ. ಹೆಸರಿಡಲಾದ tools ನಮಗೆ absence ಅನ್ನು ತಪ್ಪಲ್ಲದೆ, ಯಶಸ್ಸನ್ನಾಗಿ ಪರಿಗಣಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತವೆ.

Adopt-vs-Build ಪರಿಶೀಲನಾ ಪಟ್ಟಿ

ನೀವು MCP server ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವ ಅಥವಾ ನಿರ್ಮಿಸುವ ಮೊದಲು, ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ:

• ಗುರಿ ಏಜೆಂಟ್ ಯಾರು? (Frontier model vs. Small local model) • ಮುಖ್ಯ ಮಿತಿ ಯಾವುದು? (Tokens vs. Reliability) • Last mile ಕೆಲಸವನ್ನು ಯಾರು ಮಾಡುತ್ತಾರೆ? (Tool ಡೇಟಾವನ್ನು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡುತ್ತದೆಯೇ ಅಥವಾ ಏಜೆಂಟ್ ಮಾಡುತ್ತದೆಯೇ?) • Absence ಅನ್ನು ಅದು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ? (ಇಲ್ಲದ ಮೌಲ್ಯವು error ಆಗಿದೆಯೇ ಅಥವಾ null ಆಗಿದೆಯೇ?) • ನಿರ್ವಹಣಾ ವೆಚ್ಚ ಎಷ್ಟು? (ನೀವು ಬಳಕೆಯಾಗದ codebase ಅನ್ನು ವಹಿಸಿಕೊಳ್ಳುತ್ತಿದ್ದೀರಾ?)

ನಾವು ಆ ಇತರ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಿಲ್ಲ. ಅದರ ಆಲೋಚನೆಗಳನ್ನು ನಾವು ಪಡೆದುಕೊಂಡೆವು. ಅವರ alarm handling ಮತ್ತು path discovery ಲಾಜಿಕ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ನಮ್ಮ roadmap ಗೆ ಸೇರಿಸಿಕೊಂಡೆವು.

ದಕ್ಷತೆ (Efficiency) ಉತ್ತಮವಾಗಿದೆ, ಆದರೆ ನೀವು ನೀರಿನಲ್ಲಿ ಇದ್ದಾಗ ವಿಶ್ವಾಸಾರ್ಹತೆ (reliability) ಅತ್ಯಗತ್ಯ.

Source: https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae

Optional learning community: https://t.me/GyaanSetuAi