GLM-5.3 “thinking: disabled” ಫ್ಲಾಗ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿದೆ, ಆದ್ದರಿಂದ {"thinking":{"type":"disabled"}} ಅನ್ನು ಬಳಸುವ ಯಾವುದೇ ಸಂಯೋಜನೆಯು (integration) ಈಗ ಪ್ರತಿಕ್ರಿಯೆಯ ಬದಲಿಗೆ ದೋಷವನ್ನು (error) ನೀಡುತ್ತದೆ. ಈ ಬದಲಾವಣೆಯು ರಾತ್ರೋರಾತ್ರಿ ಡಜನ್‌ಗಟ್ಟಲೆ ಟೆಸ್ಟ್ ಸೂಟ್‌ಗಳನ್ನು ಹಾಳುಮಾಡಿತು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಚಾಲನೆಯಲ್ಲಿಡಲು ಡೆವಲಪರ್‌ಗಳು ಕೇವಲ ಒಂದು ಸಾಲಿನ ಕೋಡ್ ಅನ್ನು ಮರುಬರೆಯುವಂತೆ ಮಾಡುತ್ತದೆ.

ಈ ಬದಲಾವಣೆಯ ಮಹತ್ವವೇನು

GLM-5.2 ನಲ್ಲಿ, ಸಣ್ಣಪುಟ್ಟ ಪ್ರಾಂಪ್ಟ್‌ಗಳಿಗಾಗಿ ಥಿಂಕಿಂಗ್ ಮೋಡ್ ಅನ್ನು ಆಫ್ ಮಾಡಲು API ಅನುಮತಿಸುತ್ತಿತ್ತು. ಆ ಆಯ್ಕೆಯು ಆಟೊಮೇಷನ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು, ಬ್ಯಾಚ್-ಪ್ರೊಸೆಸಿಂಗ್ ಪೈಪ್‌ಲೈನ್‌ಗಳು ಮತ್ತು ಲೋ-ಲ್ಯಾಟೆನ್ಸಿ ಬಾಟ್‌ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ ಮಾದರಿಯಾಗಿತ್ತು. GLM-5.3 ಆ ಫ್ಲಾಗ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕಿ, low, high ಮತ್ತು max ಎಂಬ ಮೂರು ಎಫರ್ಟ್ (effort) ಮಟ್ಟಗಳನ್ನು ಪರಿಚಯಿಸಿದೆ—ಇದರಲ್ಲಿ max ಡಿಫಾಲ್ಟ್ ಆಗಿದೆ. ಹೊಸ ಮಾಡೆಲ್ ಯಾವಾಗಲೂ ರೀಸನಿಂಗ್ ಟ್ರೇಸ್ (reasoning trace) ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ; ಇದನ್ನು ಇನ್ನು ಮುಂದೆ ಸಂಪೂರ್ಣವಾಗಿ ನಿಲ್ಲಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಏನು ಹಾಳಾಯಿತು ಮತ್ತು ಅದು ಹೇಗೆ ಹರಡುತ್ತದೆ

ರಿಕ್ವೆಸ್ಟ್ ಬಾಡಿಯಲ್ಲಿ "type":"disabled" ಇದ್ದಾಗ, ಸರ್ವರ್ ಪೇಲೋಡ್ ಅನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಫೇಲ್ಯೂರ್ ರೆಸ್ಪಾನ್ಸ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ಯಾವುದೇ ಅಥೆಂಟಿಕೇಶನ್ ಅಥವಾ ಸಿಂಟ್ಯಾಕ್ಸ್ ದೋಷಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪೂರ್ಣ ರಿಗ್ರೆಷನ್ ರನ್ (regression run) ವಿಫಲವಾಗುವವರೆಗೆ ಸಮಸ್ಯೆಯನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಕಷ್ಟವಾಗಬಹುದು. ಅನೇಕ ಕೋಡ್‌ಬೇಸ್‌ಗಳಲ್ಲಿ ಈ ಫ್ಲಾಗ್ ಒಂದೇ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಹೆಲ್ಪರ್ ಫಂಕ್ಷನ್‌ನಲ್ಲಿ ಇರುವುದರಿಂದ, ಇದರ ಪರಿಣಾಮವು ದೊಡ್ಡ ಟೆಸ್ಟ್ ಸೂಟ್‌ಗಳು ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳ ಮೇಲೆ ಸಮಾನವಾಗಿ ಹರಡಿತು.

ನಿಖರವಾದ ಕೋಡ್ ಬದಲಾವಣೆ

ಹಳೆಯ ಪೇಲೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸಿ:

extra_body = {"thinking": {"type": "disabled"}}

GLM-5.3-ಅನುಗುಣ ಆವೃತ್ತಿಯೊಂದಿಗೆ:

extra_body = {"thinking": {"type": "enabled", "effort": "low"}}

"type":"enabled" ಕೀಯು ರೀಸನಿಂಗ್ ಇಂಜಿನ್ ಅನ್ನು ಮರು-ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು "effort":"low" ಎಂಬುದು ಹೊಸ ಮಾಡೆಲ್ ಎಷ್ಟು ಸಾಧ್ಯವೋ ಅಷ್ಟು ಹಳೆಯ ಡಿಸೇಬಲ್ಡ್ ಮೋಡ್‌ನ ವೇಗವನ್ನು ಅನುಕರಿಸುತ್ತದೆ.

ಕಾರ್ಯಕ್ಷಮತೆಯ ಪರಿಣಾಮಗಳು

ಲೋ-ಎಫರ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ನೊಂದಿಗೆ ಅದೇ ಕೋಡ್-ರಿವ್ಯೂ ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ರನ್ ಮಾಡುವುದರಿಂದ "ಹಳೆಯ ವೇಗಕ್ಕೆ ಹತ್ತಿರವಿರುವ" ಫಲಿತಾಂಶಗಳು ಸಿಗುತ್ತವೆ, ಆದರೆ ಅವು ಅಚ್ಚುಕಟ್ಟಾಗಿ ಒಂದೇ ಆಗಿರುವುದಿಲ್ಲ. ಮಾಡೆಲ್ ಇನ್ನೂ ರೀಸನಿಂಗ್ ಟ್ರೇಸ್ ಅನ್ನು ನೀಡುತ್ತದೆ, ಇದು ಕೆಲವು ಹೆಚ್ಚುವರಿ ಟೋಕನ್‌ಗಳನ್ನು ಮತ್ತು ಸ್ವಲ್ಪ ಮಟ್ಟದ ಲ್ಯಾಟೆನ್ಸಿ ಹೆಚ್ಚಳವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ ಅಥವಾ ಲ್ಯಾಟೆನ್ಸಿ-ಕ್ರಿಟಿಕಲ್ ಕೆಲಸಗಳಲ್ಲಿ, ಈ ಓವರ್‌ಹೆಡ್ ಸ್ವೀಕಾರಾರ್ಹವಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಿಮ್ಮ ಸ್ವಂತ ಡೇಟಾವನ್ನು ಬೆಂಚ್‌ಮಾರ್ಕ್ ಮಾಡಿಕೊಳ್ಳಬೇಕು.

ವೆಚ್ಚದ ಹೊರತಾಗಿಯೂ ಏಕೆ ಮೈಗ್ರೇಟ್ ಮಾಡಬೇಕು

GLM-5.3 ತನ್ನ ಹಿಂದಿನ ಮಾಡೆಲ್‌ನ 744-ಬಿಲಿಯನ್ ಪ್ಯಾರಾಮೀಟರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಉಳಿಸಿಕೊಂಡಿದೆ ಆದರೆ ಕೋಡಿಂಗ್ ಮತ್ತು ಏಜೆಂಟಿಕ್ ಕಾರ್ಯಗಳ ಮೇಲೆ ಹೆಚ್ಚು ಗಮನ ಹರಿಸುತ್ತದೆ. ಸ್ವತಂತ್ರ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳು (Terminal-Bench 3.0) ಸ್ಕೋರ್‌ಗಳಲ್ಲಿ ಗಮನಾರ್ಹ ಏರಿಕೆಯನ್ನು ತೋರಿಸುತ್ತವೆ ಮತ್ತು ಆಂತರಿಕ ಪರೀಕ್ಷೆಗಳು ಹಲವಾರು ಫೈಲ್‌ಗಳಲ್ಲಿ ಲಾಜಿಕ್ ದೋಷಗಳನ್ನು ಉತ್ತಮವಾಗಿ ಪತ್ತೆಹಚ್ಚುತ್ತವೆ ಎಂದು ವರದಿ ಮಾಡಿವೆ. ಸಂಕೀರ್ಣ ಕೋಡ್ ವಿಶ್ಲೇಷಣೆಗಾಗಿ ಮಾಡೆಲ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ತಂಡಗಳಿಗೆ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಲಾಭಗಳು ಟೋಕನ್ ಬಳಕೆಯ ಸಣ್ಣ ಹೆಚ್ಚಳಕ್ಕಿಂತ ಹೆಚ್ಚಿರಬಹುದು.

ನೀವು ನಿರ್ಲಕ್ಷಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದ ಹೊಂದಾಣಿಕೆ (trade-off)

ಒಂದು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ನಿಜವಾಗಿಯೂ 'ಜೀರೋ-ಥಿಂಕಿಂಗ್' ಪ್ರತಿಕ್ರಿಯೆಗಳ ಅಗತ್ಯವಿದ್ದರೆ—ಉದಾಹರಣೆಗೆ, ಪ್ಯೂರ್ ಟೋಕನ್-ಕಂಪ್ಲೀಷನ್ ಸೇವೆ—GLM-5.3 ನಲ್ಲಿ ಈಗ ಅದಕ್ಕೆ ಯಾವುದೇ ನೇರ ಆಯ್ಕೆಯಿಲ್ಲ. ಡೆವಲಪರ್‌ಗಳು ಹೆಚ್ಚುವರಿ ರೀಸನಿಂಗ್ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕು ಅಥವಾ ಇನ್ನೂ ಡಿಸೇಬಲ್ಡ್ ಮೋಡ್ ನೀಡುವ ಬೇರೆ ಮಾಡೆಲ್‌ಗೆ ಬದಲಾಗಬೇಕು.

ಮುಂದೆ ಗಮನಿಸಬೇಕಾದವುಗಳು

  • Latency monitoring: ಪೇಲೋಡ್ ಬದಲಾವಣೆಯ ನಂತರ, ರಿಗ್ರೆಷನ್‌ಗಳನ್ನು ಮೊದಲೇ ಪತ್ತೆಹಚ್ಚಲು ರೆಸ್ಪಾನ್ಸ್ ಸಮಯ ಮತ್ತು ಟೋಕನ್ ಸಂಖ್ಯೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ.
  • Effort tuning: ಕೆಲವು ಕೆಲಸಗಳು ಹೆಚ್ಚಿನ ದಂಡವಿಲ್ಲದೆ “high” ಎಫರ್ಟ್‌ನಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯಬಹುದು, ಆದ್ದರಿಂದ ಲೋ ಸೆಟ್ಟಿಂಗ್‌ಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಪ್ರಯೋಗಿಸಿ ನೋಡಿ.
  • Future deprecations: ಒಂದೇ ಫ್ಲಾಗ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿದ್ದು, API ಇನ್ನು ಹೆಚ್ಚಿನ ಏಕೀಕರಣಗಳನ್ನು (consolidations) ನೋಡಬಹುದು ಎಂದು ಸೂಚಿಸುತ್ತದೆ; ಮುಂಬರುವ ರಿಲೀಸ್ ನೋಟ್ಸ್‌ಗಳ ಮೇಲೆ ಕಣ್ಣಿಡಿ.

Bottom line: thinking ಪೇಲೋಡ್ ಅನ್ನು {"type":"enabled","effort":"low"} ಗೆ ಅಪ್‌ಡೇಟ್ ಮಾಡುವುದರಿಂದ GLM-5.3 ನೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದು. ನಿಮ್ಮ ಪೈಪ್‌ಲೈನ್‌ಗಳಲ್ಲಿ ಲ್ಯಾಟೆನ್ಸಿ ಮತ್ತು ಟೋಕನ್ ಬಳಕೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಸುಧಾರಿತ ಕೋಡಿಂಗ್ ಸಾಮರ್ಥ್ಯಗಳು ಅನಿವಾರ್ಯವಾದ ರೀಸನಿಂಗ್ ಟ್ರೇಸ್ ಅನ್ನು ಸಮರ್ಥಿಸುತ್ತವೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ.

ಚರ್ಚೆ ಮತ್ತು ಸಮುದಾಯದ ಬೆಂಬಲವು GyaanSetu AI ಟೆಲಿಗ್ರಾಮ್ ಚಾನಲ್‌ನಲ್ಲಿ ಲಭ್ಯವಿದೆ.