ನಿಮಗೆ ಬೇಕಾದ LLM ಬೆಂಚ್‌ಮಾರ್ಕ್ ಸ್ಕೋರ್ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ

ಹೆಚ್ಚಿನ LLM ಲೀಡರ್‌ಬೋರ್ಡ್‌ಗಳು ನಿಮಗೆ ಸುಳ್ಳು ಹೇಳುತ್ತವೆ.

ಕಳೆದ ತಿಂಗಳು ನಾನು ಒಂದು ಏಜೆಂಟಿಕ್ ಪೈಪ್‌ಲೈನ್ (agentic pipeline) ಗಾಗಿ ಮಾಡೆಲ್‌ಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದೆ. ನನಗೆ ಕೋಡ್ ಜನರೇಷನ್ ಮತ್ತು ಮಲ್ಟಿ-ಸ್ಟೆಪ್ ರೀಸನಿಂಗ್ (multi-step reasoning) ಅಗತ್ಯವಿತ್ತು. ನಾನು ಜನಪ್ರಿಯ ಲೀಡರ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿರುವ ಟಾಪ್ ಮಾಡೆಲ್ ಅನ್ನು ಆರಿಸಿದೆ. ಅದನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದೆ. ಆದರೆ ಅದು ಮೂಲಭೂತ ಟೂಲ್-ಬಳಕೆಯ (tool-use) ಕಾರ್ಯಗಳಲ್ಲಿ ವಿಫಲವಾಯಿತು.

ಲೀಡರ್‌ಬೋರ್ಡ್ ಸ್ಕೋರ್ ನಿಜವಾಗಿತ್ತು. ಆದರೆ ಅದು ನನ್ನ ಕೆಲಸಕ್ಕೆ ಪ್ರಯೋಜನಕಾರಿಯಾಗಿರಲಿಲ್ಲ.

ಸಾರ್ವಜನಿಕ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳು ಮಾಡೆಲ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸುತ್ತವೆ. ಆದರೆ ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ (production), ನೀವು ಏಜೆಂಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತೀರಿ. ಏಜೆಂಟ್‌ಗಳು ಟೂಲ್‌ಗಳನ್ನು ಕರೆಯುತ್ತವೆ, ವೆಬ್‌ನಲ್ಲಿ ಹುಡುಕುತ್ತವೆ ಮತ್ತು ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತವೆ. ಪ್ರಮಾಣಿತ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳು ಇದನ್ನು ಅಳೆಯುವುದಿಲ್ಲ.

LXT ವರದಿಗಳು ದೊಡ್ಡ ಅಂತರವನ್ನು ತೋರಿಸುತ್ತವೆ. ಫೆಬ್ರವರಿ 2026 ರಲ್ಲಿ, ಟೂಲ್ ಪ್ರವೇಶದೊಂದಿಗೆ (tool access), ಸ್ಕೋರ್‌ಗಳು ಹೀಗಿದ್ದವು:

• Claude Opus 4.6: 53.1% • GPT-5.3 Codex: 36% • GLM-5: 32%

ಟೂಲ್ ಪ್ರವೇಶವಿಲ್ಲದೆ, ಈ ಸ್ಕೋರ್‌ಗಳು ಕುಸಿಯುತ್ತವೆ. ಏಜೆಂಟ್‌ಗಳಿಗೆ ಟೂಲ್-ಸಹಾಯಿತ (tool-assisted) ಮತ್ತು ಟೂಲ್-ರಹಿತ (non-tool) ಸ್ಕೋರ್‌ಗಳ ನಡುವಿನ ಅಂತರವು ಮಾತ್ರ ಮುಖ್ಯವಾದ ಮೆಟ್ರಿಕ್ ಆಗಿದೆ.

ಟ್ರಿವಿಯಾ ಅಥವಾ ಸ್ಟ್ಯಾಟಿಕ್ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಗೆಲ್ಲುವ ಮಾಡೆಲ್‌ಗಳು ಹೆಚ್ಚಾಗಿ ಒಂದು ಸಿಂಗಲ್ ಫಂಕ್ಷನ್ ಕಾಲ್ (function call) ಬರೆಯುವಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ.

ನೀವು ಏಜೆಂಟ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ಈ ಮೂರು ಕ್ಷೇತ್ರಗಳ ಮೇಲೆ ಗಮನಹರಿಸಿ:

  1. ಟೂಲ್ ಕಾಲ್ ವಿಶ್ವಾಸಾರ್ಹತೆ (Tool call reliability). ಏಜೆಂಟ್ ಗಮನ ಬೇರೆಡೆ ಹೋದಾಗಲೂ ಮಾಡೆಲ್ ಕರೆಗಳನ್ನು ಸರಿಯಾಗಿ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಲಿತೇ? ಅದು ದೋಷಗಳಿಂದ ಚೇತರಿಸಿಕೊಳ್ಳಬಲ್ಲದೇ?
  2. ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ ಎಕನಾಮಿಕ್ಸ್ (Context window economics). ಕೆಲವು ಟೂಲ್ ಸೆಟಪ್‌ಗಳು 10x ರಿಂದ 32x ಹೆಚ್ಚು ಟೋಕನ್‌ಗಳ ವೆಚ್ಚವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಪ್ರತಿ ಕರೆಯಲ್ಲೂ ನಿಮ್ಮ ಬಜೆಟ್ ಖರ್ಚಾದರೆ, ದೊಡ್ಡ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ ವ್ಯರ್ಥವಾಗುತ್ತದೆ.
  3. ಮಲ್ಟಿ-ಸ್ಟೆಪ್ ಪ್ಲಾನಿಂಗ್ (Multi-step planning). ಮಾಡೆಲ್ 5-ಹಂತದ ಯೋಜನೆಯನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬಲ್ಲದೇ? ಅನೇಕ ಮಾಡೆಲ್‌ಗಳು 3ನೇ ಹಂತದ ವೇಳೆಗೆ ದಾರಿಯನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತವೆ.

ಸಾರ್ವಜನಿಕ ಲೀಡರ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ನಿಮ್ಮ ಏಕೈಕ ಮಾರ್ಗದರ್ಶಿಯಾಗಿ ಬಳಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಬದಲಾಗಿ ಇದನ್ನು ಮಾಡಿ:

• ಮಿನಿ-ಬೆಂಚ್‌ಮಾರ್ಕ್ ನಡೆಸಲು (Run a mini-benchmark). ನಿಮ್ಮ ಸ್ವಂತ ಲಾಗ್‌ಗಳಿಂದ 20 ರಿಂದ 50 ನೈಜ ಟೂಲ್ ಕರೆಗಳನ್ನು ಬಳಸಿ. ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಸ್ಕೀಮಾದ ಮೇಲೆ ನಿಖರತೆಯನ್ನು ಅಳೆಯಿರಿ. • ದೋಷದ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ (Test error conditions). ಒಂದು ಟೂಲ್ ದೋಷ ಅಥವಾ ಖಾಲಿ ಡೇಟಾವನ್ನು ನೀಡಿದಾಗ ಮಾಡೆಲ್ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂದು ನೋಡಿ. • ಪ್ರತಿ ಕಾರ್ಯದ ವೆಚ್ಚವನ್ನು ಅಳೆಯಿರಿ (Measure cost per task). 5% ಉತ್ತಮವಾಗಿರುವ ಆದರೆ 3x ಹೆಚ್ಚು ದುಬಾರಿಯಾದ ಮಾಡೆಲ್ ಹೆಚ್ಚಾಗಿ ತಪ್ಪು ಆಯ್ಕೆಯಾಗುತ್ತದೆ. • ವಿಶೇಷ ಲೀಡರ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ಬಳಸಿ. ಒಟ್ಟಾರೆ ರ‍್ಯಾಂಕಿಂಗ್‌ಗಳ ಬದಲಾಗಿ BenchLM.ai ನಲ್ಲಿ ಟೂಲ್-ಬಳಕೆ ಮತ್ತು ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ಸ್ಕೋರ್‌ಗಳನ್ನು ನೋಡಿ.

#3 ರ ರ‍್ಯಾಂಕ್ ಪಡೆದ ಮಾಡೆಲ್ ಒಂದೇ ಪ್ರಾಂಪ್ಟ್‌ಗೆ ಪರಿಪೂರ್ಣವಾಗಿರಬಹುದು. ಆದರೆ ಅದು ಏಜೆಂಟ್‌ಗೆ ವಿಪತ್ತಾಗಬಹುದು.

ನಿಮ್ಮ ಸ್ವಂತ ಟೂಲ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಒಂದು ಮಧ್ಯಾಹ್ನವನ್ನು ಮೀಸಲಿಡಿ. ಇದು ನಂತರದ ಒಂದು ವಾರದ ಡಿಬಗ್ಗಿಂಗ್ (debugging) ಸಮಯವನ್ನು ಉಳಿಸುತ್ತದೆ.

ನೀವು ನಿಮ್ಮ ಮಾಡೆಲ್‌ಗಳನ್ನು ಹೇಗೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತಿದ್ದೀರಿ? ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿ ತಿಳಿಸಿ.