ನಾನು ಬಹಳ ಚಾಣಾಕ್ಷತನ ಮಾಡುತ್ತಿದ್ದೇನೆ ಎಂದು ಭಾವಿಸಿದ್ದೆ. ನಮ್ಮ AI ಪೈಪ್ಲೈನ್ನಿಗಾಗಿ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ (context window) ನ ಸರಿಯಾಗಿ ಮೂವತ್ತು ಪ್ರತಿಶತವನ್ನು 'ಥಿಂಕಿಂಗ್ ಬಜೆಟ್' (thinking budget) ಆಗಿ ಕಾಯ್ದಿರಿಸುವ ಒಂದು ಹೆಲ್ಪರ್ ಫಂಕ್ಷನ್ ಅನ್ನು ನಾನು ಬರೆದಿದ್ದೆ. ಅದು ಅತ್ಯಂತ ಸುಲಲಿತವಾಗಿತ್ತು, ಮುನ್ಸೂಚನೆ ನೀಡುವಂತಿತ್ತು ಮತ್ತು Opus 4.5 ನಲ್ಲಿ ಅದ್ಭುತವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು. ಆದರೆ ನಾನು Opus 4.8 ಗೆ ಬದಲಾದಾಗ, ಪ್ರತಿಯೊಂದು ರಿಕ್ವೆಸ್ಟ್ ಕೂಡ 400 ಎರರ್ನೊಂದಿಗೆ ವಿಫಲವಾಯಿತು. ನನ್ನ ಎಚ್ಚರಿಕೆಯಿಂದ ರೂಪಿಸಿದ ಟೋಕನ್ ಗಣಿತವು ರಾತ್ರೋರಾತ್ರಿ ಕಸವಾಗಿ ಬದಲಾಯಿತು.
ಹಳೆಯ ಮಾದರಿಯು ಸರಳವಾಗಿತ್ತು. ನೀವು budget_tokens ಮೌಲ್ಯವನ್ನು ನಿಗದಿಪಡಿಸುತ್ತಿದ್ದಿರಿ ಮತ್ತು ಮಾಡೆಲ್ ಆ ಮಿತಿಯೊಳಗೆ ತನ್ನ ಆಲೋಚನೆಯನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತಿತ್ತು. ನಾನು 128K ಕಾಂಟೆಕ್ಸ್ಟ್ ನೀಡಿದರೆ, ನನ್ನ ಕೋಡ್ ರೀಸನಿಂಗ್ (reasoning) ಗಾಗಿ ಅಂದಾಜು 38,000 ಟೋಕನ್ಗಳನ್ನು ಮೀಸಲಿಟ್ಟು ಉಳಿದಿದ್ದನ್ನು ಉತ್ತರಕ್ಕಾಗಿ ಬಿಡುತ್ತಿತ್ತು. ಇದು ಜವಾಬ್ದಾರಿಯುತವಾಗಿತ್ತು. ಕಾರನ್ನು ವೇಗ ಮಿತಿಯೊಳಗೆ ಚಲಾಯಿಸುವುದರಂತೆ.
ಆ ಮಾಡೆಲ್ ಈಗ ಇಲ್ಲ. Opus 4.7 ಮತ್ತು 4.8 ನಂತಹ ಹೊಸ ಬಿಡುಗಡೆಗಳು ಅಡಾಪ್ಟಿವ್ ಥಿಂಕಿಂಗ್ (adaptive thinking) ಅನ್ನು ಬಳಸುತ್ತವೆ. ನೀವು ಇನ್ನು ಮುಂದೆ ಸಂಖ್ಯೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಬದಲಾಗಿ, ನೀವು ಒಂದು effort knob ಅನ್ನು ನೀಡಬೇಕಾಗುತ್ತದೆ. ಇದು ಕೇವಲ ಹೆಸರಿನ ಬದಲಾವಣೆಯಂತೆ ಕೇಳಿಸಬಹುದು, ಆದರೆ ಈ ಎರಡು ನಿಯಂತ್ರಣಗಳು ಒಂದಕ್ಕೊಂದು ಸಂಪೂರ್ಣವಾಗಿ ಭಿನ್ನವಾಗಿವೆ. budget_tokens ಮಾಡೆಲ್ ಎಷ್ಟು ಯೋಚಿಸಬೇಕು ಎಂಬುದರ ಮೇಲೆ ಕಠಿಣ ಮಿತಿಯನ್ನು ಹೇರುತ್ತಿತ್ತು. Effort ಎಂಬುದು ಮಾಡೆಲ್ ಮೂಲತಃ ಹೇಗೆ ಯೋಚಿಸುತ್ತದೆ ಮತ್ತು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಒಂದು ಗ್ಯಾಸ್ ಪಂಪ್ ಮೀಟರ್ ಇದ್ದರೆ, ಇನ್ನೊಂದು ಎಂಜಿನ್ ಮ್ಯಾಪ್ ಇದ್ದಂತೆ.
Effort ಅನ್ನು ನೈಜ ಕೆಲಸಕ್ಕೆ ಮ್ಯಾಪಿಂಗ್ ಮಾಡುವುದು
ನಿಯಂತ್ರಣ ಬದಲಾದಾಗ, ನನ್ನ ಹಳೆಯ ಅಂತಃಪ್ರಜ್ಞೆಯು ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿತು. ಪ್ರತಿ ಸೆಟ್ಟಿಂಗ್ ಕೂಡ ವಾಸ್ತವದಲ್ಲಿ ಏನನ್ನು ನೀಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಾನು ಮರುಕಲಿತುಕೊಳ್ಳಬೇಕಾಯಿತು. ಪ್ರತಿಯೊಂದು effort ಮಟ್ಟವು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಎಲ್ಲಿಗೆ ತಲುಪುತ್ತದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾನು ನಮ್ಮ ಆಂತರಿಕ ಟ್ರಾಫಿಕ್ನಲ್ಲಿ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿದೆ.
Classification and routing ಕಾರ್ಯಗಳಿಗೆ ಯಾವಾಗಲೂ low effort ಬಳಸಬೇಕು. ಇವು ವೇಗವಾದ ನಿರ್ಧಾರಗಳು. ಇದು ರಿಫಂಡ್ ವಿನಂತಿಯೇ ಅಥವಾ ಮಾರಾಟದ ಪ್ರಶ್ನೆಯೇ? ಈ ಲಾಗ್ ಎಂಟ್ರಿಯನ್ನು ಎಸ್ಕಲೇಟ್ ಮಾಡಬೇಕೇ? ಇದಕ್ಕೆ ನೀವು ಸುದೀರ್ಘ ಮಾತುಕತೆಯ ಅಗತ್ಯವಿಲ್ಲ. Low effort ವಿಳಂಬವನ್ನು (latency) ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಅತ್ಯಲ್ಪವಾಗಿರಿಸುತ್ತದೆ.
ಹೆಚ್ಚಿನ ಅಪ್ಲಿಕೇಶನ್ ಟ್ರಾಫಿಕ್, ಅಂದರೆ ಸಮ್ಮರಿಗಳು (summaries), ಮರುಬರವಣಿಗೆಗಳು (rewrites), ಸಪೋರ್ಟ್ ರಿಪ್ಲೈಗಳು ಮತ್ತು ಕಂಟೆಂಟ್ ಎಕ್ಸ್ಟ್ರಾಕ್ಷನ್ನಂತಹ ದೈನಂದಿನ ಕೆಲಸಗಳು, medium ಇಂದ high effort ಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತವೆ. ಇದು ಸಮತೋಲನದ ಬಿಂದುವಾಗಿದೆ. ಮಾಡೆಲ್ ಸುದೀರ್ಘವಾದ chain of thought ಅಗತ್ಯವಿಲ್ಲದ ಕೆಲಸಕ್ಕಾಗಿ ಟೋಕನ್ಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡದೆ, ನೈಜ ಅಸ್ಪಷ್ಟತೆಯನ್ನು ಪರಿಹರಿಸಲು ಸಾಕಷ್ಟು ಅವಕಾಶವನ್ನು ಪಡೆಯುತ್ತದೆ.
Coding ಮತ್ತು agentic loops ಕಾರ್ಯಗಳಿಗೆ xhigh effort ಅಗತ್ಯವಿದೆ. ಇಲ್ಲಿ ತಪ್ಪುಗಳು ಸಂಚಲನಗೊಳ್ಳುತ್ತವೆ (compound). ಒಂದು ಟೂಲ್-ಕಾಲಿಂಗ್ ಲೂಪ್ನ ಮೊದಲ ಹಂತದಲ್ಲಿ ಮಾಡೆಲ್ ಕೆಟ್ಟ ಯೋಜನೆಯನ್ನು ಬರೆದರೆ, ಅದು ಮುಂದಿನ ಮೂರು ಹಂತಗಳಲ್ಲಿ ಆ ಹಾನಿಯನ್ನು ಸರಿಪಡಿಸಲು ಸಮಯ ವ್ಯಯಿಸುತ್ತದೆ. ಅಥವಾ ಅದಕ್ಕಿಂತ最 ಕೆಟ್ಟದಾಗಿ, ಅದು ತಪ್ಪು ಟೂಲ್ಗಳನ್ನು ಕರೆಯಬಹುದು, ಪ್ಯಾರಾಮೀಟರ್ಗಳನ್ನು ಹ್ಯಾಲ್ಯುಸಿನೇಟ್ ಮಾಡಬಹುದು ಮತ್ತು ಬಳಕೆದಾರರನ್ನು ಹಾನಿಗೊಳಗಾದ ವರ್ಕ್ಫ್ಲೋ ನೋಡುವಂತೆ ಮಾಡಬಹುದು. ಮೊದಲೇ ಉತ್ತಮವಾದ ರೀಸನಿಂಗ್ ಇರುವುದು ಅಂತಹ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ತಡೆಯುತ್ತದೆ.
ನಿರ್ಣಾಯಕ ಕಾರ್ಯಗಳಿಗೆ (Critical tasks) max effort ನೀಡಬೇಕು. ಇದನ್ನು ಎಲ್ಲದಕ್ಕೂ ಬಳಸಬೇಡಿ. ತಪ್ಪು ಉತ್ತರವು ಯಾವುದೇ ಟೋಕನ್ ಬಿಲ್ಗಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚವನ್ನು ಉಂಟುಮಾಡುವ ಕ್ಷಣಗಳಿಗಾಗಿ ಇದನ್ನು ಮೀಸಲಿಡಿ. ಹಣಕಾಸಿನ ಹೊಂದಾಣಿಕೆಗಳು (Financial reconciliations), ಸುರಕ್ಷತಾ ತಪಾಸಣೆಗಳು, ಆರ್ಕಿಟೆಕ್ಚರ್ ನಿರ್ಧಾರಗಳು ಮತ್ತು ಮೆಡಿಕಲ್ ಟ್ರೈಯಾಜ್ (medical triage) ಇದಕ್ಕೆ ಸರಿಯಾದ ಆಯ್ಕೆಗಳು. ಒಂದು ತಪ್ಪಿನಿಂದಾಗಿ ಮನುಷ್ಯನು ಗಂಟೆಗಟ್ಟಲೆ ಆ ಗೊಂದಲವನ್ನು ಸರಿಪಡಿಸಬೇಕಾದರೆ, ಹೆಚ್ಚಿನ ಆಲೋಚನೆಗಾಗಿ ಹಣ ಪಾವತಿಸಿ.
ವೆಚ್ಚದ ಅಚ್ಚರಿ
ನನ್ನ ಮಾನಸಿಕ ಮಾದರಿಯನ್ನು (mental model) ಮುರಿಯುವ ಭಾಗ ಇಲ್ಲಿದೆ. 'max effort' ಯಾವಾಗಲೂ ನನ್ನ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸಿದ್ದೆ. ಒಂದೇ ಹಂತದಲ್ಲಿ (single turn), ಅದು ಹಾಗೆಯೇ ಮಾಡುತ್ತದೆ. ರೀಸನಿಂಗ್ ಟ್ರೇಸ್ ದೀರ್ಘವಾಗಿರುತ್ತದೆ. ಆದರೆ ಬಹು-ಹಂತದ ಏಜೆಂಟಿಕ್ ಕಾರ್ಯಗಳಲ್ಲಿ (multi-step agentic tasks), ಒಟ್ಟು ಬಿಲ್ ಹೆಚ್ಚಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
ಮಾಡೆಲ್ ಮೊದಲ ಪ್ರಯತ್ನದಲ್ಲೇ ಉತ್ತಮವಾಗಿ ಯೋಜಿಸುತ್ತದೆ. ಇದು ಕಡಿಮೆ ಟೂಲ್ ಕರೆಗಳನ್ನು ಮಾಡುತ್ತದೆ. ಇದು ತಪ್ಪು ದಾರಿಗಳಲ್ಲಿ ಅಲೆಯುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಐದು ಹಂತಗಳ ಅಗತ್ಯವಿರುವ ಡೇಟಾ ಎಕ್ಸ್ಟ್ರಾಕ್ಷನ್ ಏಜೆಂಟ್, ಕೇವಲ ಎರಡು ಹಂತಗಳಲ್ಲಿ ಮುಗಿಸುವುದನ್ನು ನಾನು ಗಮನಿಸಿದೆ, ಏಕೆಂದರೆ ಮಾಡೆಲ್ ಆರಂಭದಲ್ಲೇ ಸ್ಕೆಮಾವನ್ನು (schema) ಸರಿಯಾಗಿ ವಿಶ್ಲೇಷಿಸಲು ಸಾಕಷ್ಟು ರೀಸನಿಂಗ್ ಅವಕಾಶವನ್ನು ಹೊಂದಿತ್ತು. ನೀವು ವೆಚ್ಚವನ್ನು ಅಳೆಯುವಾಗ, ರಿಕ್ವೆಸ್ಟ್ ಅನ್ನು ನೋಡಬೇಡಿ, ಕೆಲಸದ ಪೂರ್ಣಗತಿಯನ್ನು (job completion) ನೋಡಿ. ಪ್ರತಿ ಹಂತದಲ್ಲಿ ದೊಡ್ಡ ರೀಸನಿಂಗ್ ಬಜೆಟ್ ಇರುವುದು ಒಟ್ಟಾರೆಯಾಗಿ ಕಡಿಮೆ ಹಂತಗಳನ್ನು ಸೂಚಿಸಬಹುದು.
ಬೇರೆ ಯಾವುದನ್ನೂ ಹಾಳು ಮಾಡದೆ ಹೇಗೆ ಮೈಗ್ರೇಟ್ ಮಾಡುವುದು
ನಿಮ್ಮ ಕೋಡ್ಬೇಸ್ನಲ್ಲಿ ಇನ್ನೂ budget_tokens ಬಳಕೆಯಲ್ಲಿದ್ದರೆ, ಅದರಿಂದ ಹೊರಬರಲು ಇಲ್ಲಿದೆ ನಿಖರವಾದ ಹಾದಿ. ಹಂತ ಮೂರು ಮತ್ತು ಐದನ್ನು ಬಿಡಬೇಡಿ. ನಾನು ಅವುಗಳನ್ನು ಬಿಟ್ಟಿದ್ದೆ ಮತ್ತು ಅದರಿಂದಾಗಿ ಒಂದು ಮಧ್ಯಾಹ್ನ ಡಿಬಗ್ ಮಾಡಬೇಕಾಯಿತು.
ನಿಮ್ಮ ಕೋಡ್ನಲ್ಲಿ budget_tokens ಅನ್ನು ಹುಡುಕಿ. ಪ್ರತಿಯೊಂದು ಉದಾಹರಣೆಯನ್ನು ತೆಗೆದುಹಾಕಬೇಕು. ಹೊಸ ಮಾಡೆಲ್ಗಳಲ್ಲಿ ಈ ಪ್ಯಾರಾಮೀಟರ್ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಮತ್ತು ಇದು 400 ಎರರ್ ಅನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಬಜೆಟ್ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಅಡಾಪ್ಟಿವ್ ಥಿಂಕಿಂಗ್ ಬ್ಲಾಕ್ನಿಂದ ಬದಲಾಯಿಸಿ. thinking: { type: "adaptive" } ಅನ್ನು ಬಳಸಿ.
ಪ್ರತಿ ಕಾಲ್ಗೆ ಸ್ಪಷ್ಟವಾದ effort ಮಟ್ಟದೊಂದಿಗೆ output_config ಅನ್ನು ಸೇರಿಸಿ. ನಿಮ್ಮ ಟ್ರಾಫಿಕ್ ಮಿಶ್ರಿತವಾಗಿದ್ದರೆ ಇದನ್ನು ಗ್ಲೋಬಲ್ ಡಿಫಾಲ್ಟ್ ಮೇಲೆ ಬಿಡಬೇಡಿ. ನಿಮ್ಮ ಲೈಟ್ವೇಯಟ್ ಕ್ಲಾಸಿಫಿಕೇಶನ್ ಎಂಡ್ಪಾಯಿಂಟ್ ಅಕಸ್ಮಾತ್ ನಿಮ್ಮ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ನಷ್ಟೇ effort ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಪಡೆದುಕೊಳ್ಳಬಾರದು. ಕಾಲ್ ಸೈಟ್ನಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿರಿ.
ನಿಮ್ಮ ಬಜೆಟ್ ಕ್ಯಾಲ್ಕುಲೇಶನ್ ಹೆಲ್ಪರ್ ಅನ್ನು ಡಿಲೀಟ್ ಮಾಡಿ. ನನಗೆ ಗೊತ್ತು. ಅದಕ್ಕೆ ಬಹುಶಃ ಯೂನಿಟ್ ಟೆಸ್ಟ್ಗಳಿರಬಹುದು. ನನ್ನದೂ ಇತ್ತು. ಆದರೆ ಅದು ಈಗ ಅನಗತ್ಯ ಭಾರವಾಗಿದೆ. ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗೆ ನಿಮ್ಮ ಟೋಕನ್ ಗಣಿತದ ಅಗತ್ಯವಿಲ್ಲ. ಮಾಡೆಲ್ ತನ್ನದೇ ಆದ ವೇಗವನ್ನು ತಾನೇ ನಿರ್ವಹಿಸುತ್ತದೆ.
temperature, top_p, ಮತ್ತು top_k ಅನ್ನು ತೆಗೆದುಹಾಕಿ. Opus 4.7 ಮತ್ತು 4.8 ರಲ್ಲಿ, ಈ sampling parameters 400 error ಗಳನ್ನು ನೀಡುತ್ತವೆ. ಈ ತಲೆಮಾರಿನಿಂದ (generation) ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಇವುಗಳನ್ನು ತೆಗೆದುಹಾಕಿದೆ. ನಿಮ್ಮ ಹಳೆಯ temperature-tuning ತಂತ್ರಗಳು ಇಲ್ಲಿ ಅನ್ವಯಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅವುಗಳನ್ನು ಹಾಗೆಯೇ ಬಿಡುವುದು ನಿಮ್ಮ migration ಅನ್ನು ಮೌನವಾಗಿ ಹಾಳುಮಾಡುತ್ತದೆ.
ಪ್ರತಿ ಮಾಡೆಲ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ. Opus 4.5 ಮತ್ತು 4.8 ಸಂಪೂರ್ಣವಾಗಿ ಭಿನ್ನವಾಗಿವೆ. ಒಂದು ಮಾಡೆಲ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ config ಮತ್ತೊಂದರಲ್ಲಿ ಕೆಲಸ ಮಾಡಬೇಕೆಂದಿಲ್ಲ. ನೀವು ಬಹುತೇಕ ವರ್ಷನ್ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ logic ಅನ್ನು ವಿಂಗಡಿಸಿ ಅಥವಾ ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕ backends ಎಂದು ಪರಿಗಣಿಸಿ.
UI Freeze ಅನ್ನು ಸರಿಪಡಿಸುವುದು
ನೀವು ಇದನ್ನು ನಿರ್ವಹಿಸದಿದ್ದರೆ, ಒಂದು streaming behavior ನಿಮ್ಮ ಬಳಕೆದಾರರನ್ನು ಗೊಂದಲಕ್ಕೀಡು ಮಾಡಬಹುದು. ಹೊಸ ಮಾಡೆಲ್ಗಳಲ್ಲಿ, thinking blocks ಸ್ಟ್ರೀಮ್ ಆಗುತ್ತವೆ ಆದರೆ ಪಠ್ಯವು (text) ಡಿಫಾಲ್ಟ್ ಆಗಿ ಖಾಲಿಯಾಗಿರುತ್ತದೆ. ನಿಮ್ಮ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ, ಇದು ಯಾವುದೇ ಪ್ರಗತಿ ಕಾಣಿಸದ ದೀರ್ಘವಾದ, ಅಸಹಜ ವಿರಾಮದಂತೆ ಕಾಣುತ್ತದೆ. ಆಪ್ ಹ್ಯಾಂಗ್ ಆಗಿದೆ ಎಂದು ಬಳಕೆದಾರರು ಭಾವಿಸಬಹುದು.
ಇದನ್ನು ಸರಿಪಡಿಸಲು, thinking: { type: "adaptive", display: "summarized" } ಅನ್ನು ಬಳಸಿ. ಇದು raw thought stream ಅನ್ನು ಚಾಟ್ ವಿಂಡೋಗೆ ಹಾಕದೆ, ನಿಮಗೆ ದೃಶ್ಯಮಾನ ಪ್ರಗತಿ ಸೂಚಕವನ್ನು (visible progress indicator) ನೀಡುತ್ತದೆ. ನಿಮ್ಮ frontend ಪ್ರತಿಕ್ರಿಯಿಸುವಿಕೆಯನ್ನು (responsive) ಕಾಯ್ದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಒಳಗಿನ ಪ್ರಕ್ರಿಯೆಗಳು ನಡೆಯುತ್ತಿವೆ ಎಂಬುದು ನಿಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ತಿಳಿಯುತ್ತದೆ.
ನಿಜವಾದ ಪಾಠ
ಮಾರಾಟಗಾರರು (vendor) ಎಂದಿಗೂ ಶಾಶ್ವತವಾಗಿ ಇರುತ್ತದೆ ಎಂದು ಉದ್ದೇಶಿಸದ ಒಂದು ಪ್ಯಾರಾಮೀಟರ್ ಮೇಲೆ ನಾನು ಇಡೀ abstraction layer ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೆ. ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಿಂತ ನನಗೆ tradeoff ಬಗ್ಗೆ ಹೆಚ್ಚು ತಿಳುವಳಿಕೆ ಇದೆ ಎಂದು ಭಾವಿಸಿ ನಾನು ಅವರ settings ಅನ್ನು ನನ್ನದೇ ಆದ logic ನಲ್ಲಿ ಸುತ್ತುವರೆಸಿದ್ದೆ. ಆದರೆ ಅದು ತಪ್ಪಾಗಿತ್ತು. Adaptive thinking ಒಂದು ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ ಏಕೆಂದರೆ ಮಾಡೆಲ್ ಯಾವಾಗ ತೀವ್ರವಾಗಿ ಯೋಚಿಸಬೇಕು ಮತ್ತು ಯಾವಾಗ ಸುಲಭವಾಗಿ ಮುಂದುವರಿಯಬಹುದು ಎಂಬುದನ್ನು ತಾನೇ ನಿರ್ಧರಿಸುತ್ತದೆ. ಈಗ ನನ್ನ codebase ಚಿಕ್ಕದಾಗಿದೆ. ಫಲಿತಾಂಶಗಳು ಹೆಚ್ಚು ನಿಖರವಾಗಿವೆ. ಕೆಲವೊಮ್ಮೆ ಸರಿಯಾದ ಎಂಜಿನಿಯರಿಂಗ್ ಕ್ರಮವೆಂದರೆ ಚತುರ ಕೋಡ್ ಅನ್ನು (clever code) ಅಳಿಸಿಹಾಕಿ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ತನ್ನ ಕೆಲಸವನ್ನು ಮಾಡಲು ಬಿಡುವುದು.
ನೀವು ಮೂಲ migration ನೋಟ್ಸ್ಗಳನ್ನು ಓದಲು ಬಯಸಿದರೆ, ಅವುಗಳನ್ನು ಇಲ್ಲಿ ನೋಡಬಹುದು. ಇಂತಹ ಹೆಚ್ಚಿನ ಚರ್ಚೆಗಳಿಗಾಗಿ, Telegram ನಲ್ಲಿ GyaanSetu AI ಸಮುದಾಯವನ್ನು ಸೇರಿ.