ನೀವು ನೂರಾರು ಪುಟಗಳ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಅನ್ನು ಪ್ರಾಂಪ್ಟ್ಗೆ ಪೇಸ್ಟ್ ಮಾಡಿ ಒಂದು ಸರಳ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುತ್ತೀರಿ. ಆದರೆ ಉತ್ತರ ತಪ್ಪಾಗಿ ಬರುತ್ತದೆ. ಅಥವಾ ನೀವು ಮೇಲ್ಭಾಗದಲ್ಲಿ ನೀಡಿದ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ನಿಯಮವನ್ನು ಅದು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ನೀವು ಅದಕ್ಕೆ ಎಲ್ಲವನ್ನೂ ನೀಡಿದ್ದೀರಿ. ಅದು ಕೆಲಸ ಮಾಡಬೇಕಿತ್ತು. ಆದರೆ ಅದು ಮಾಡಲಿಲ್ಲ.
ಇದು 'ಕಾಂಟೆಕ್ಸ್ಟ್ ಟ್ರ್ಯಾಪ್' (context trap). ಹೆಚ್ಚಿನ ಡೆವಲಪರ್ಗಳು AI ಗೆ ಹೆಚ್ಚು ಮಾಹಿತಿಯನ್ನು ನೀಡಿದರೆ ತಾನಾಗಿಯೇ ಉತ್ತಮ ಫಲಿತಾಂಶಗಳು ಸಿಗುತ್ತವೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ಇದರ ವಿರುದ್ಧವೇ ನಡೆಯುತ್ತದೆ. ವಿಶ್ವಾಸಾರ್ಹ AI ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಮೂರು ಪ್ರಮುಖ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅಗತ್ಯವಾಗಿದೆ: ಮಾಡೆಲ್ಗಳು ಪಠ್ಯವನ್ನು ಹೇಗೆ ಎಣಿಸುತ್ತವೆ, ಅವು ಏಕಕಾಲದಲ್ಲಿ ಎಷ್ಟು ಮಾಹಿತಿಯನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬಲ್ಲವು ಮತ್ತು ಸಂಭಾಷಣೆ ಮುಗಿದ ನಂತರ ಮಾಹಿತಿಗೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದು.
ಟೋಕನ್ಗಳು: ನಿಜವಾದ ಕರೆನ್ಸಿ
ಟೋಕನ್ ಎಂಬುದು ಭಾಷಾ ಮಾಡೆಲ್ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಅತ್ಯಂತ ಚಿಕ್ಕ ಘಟಕವಾಗಿದೆ. ಇದು ಒಂದು ಅಕ್ಷರ, ಪದದ ಒಂದು ಭಾಗ ಅಥವಾ ಒಂದು ಪೂರ್ಣ ಪದವಾಗಿರಬಹುದು. "purchase" ಎಂಬ ಪದವು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ಟೋಕನ್ಗಳಾಗಿ ವಿಭಜನೆಯಾಗುತ್ತದೆ, ಆದರೆ "cat" ನಂತಹ ಚಿಕ್ಕ ಪದವು ಒಂದೇ ಟೋಕನ್ ಆಗಿ ಉಳಿಯುತ್ತದೆ. ವಿರಾಮಚಿಹ್ನೆಗಳು ಮತ್ತು ಖಾಲಿ ಜಾಗಗಳು (spaces) ಕೂಡ ಟೋಕನ್ಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಕೋಡ್ (Code) ವಿಷಯದಲ್ಲಿ ಇದು ಹೆಚ್ಚು ಪ್ರಭಾವ ಬೀರುತ್ತದೆ. ನೆಸ್ಟೆಡ್ ಇಂಡೆಂಟೇಶನ್ (nested indentation) ಮತ್ತು ವಿಶೇಷ ಅಕ್ಷರಗಳನ್ನು ಹೊಂದಿರುವ Python ಕೋಡ್ನ ಒಂದು ಬ್ಲಾಕ್, ನೀವು ಊಹಿಸಿದ್ದಕ್ಕಿಂತ ಮೂರು ಅಥವಾ ನಾಲ್ಕು ಪಟ್ಟು ಹೆಚ್ಚು ಟೋಕನ್ಗಳನ್ನು ಬಳಸಬಹುದು.
ಇದನ್ನು ನಿರ್ಮಿಸುವವರು (builders) ಏಕೆ ಗಮನಿಸಬೇಕು? API ಬೆಲೆಯು ಪ್ರತಿ ಟೋಕನ್ಗೆ ನಿರ್ಧರಿಸಲ್ಪಡುತ್ತದೆ. ಪ್ರೊಸೆಸಿಂಗ್ ಸಮಯವೂ ಕೂಡ ಹಾಗೆಯೇ ಇರುತ್ತದೆ. ಎರಡು ಪುಟಗಳ ಪಠ್ಯದಂತೆ ಕಾಣುವ ಪ್ರಾಂಪ್ಟ್, ಅದರ ಒಳಗಿರುವ ವಿಷಯದ ಆಧಾರದ ಮೇಲೆ ಕೇವಲ ಕೆಲವು ಪೈಸೆ ಅಥವಾ ಡಾಲರ್ಗಳ ಬೆಲೆಯನ್ನು ಹೊಂದಿರಬಹುದು. ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದೇನೆಂದರೆ, ವಿನಿಮಯದ ಎರಡೂ ಕಡೆ ಟೋಕನ್ಗಳು ಹೆಚ್ಚಾಗುತ್ತವೆ. ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಟೋಕನ್ಗೂ ನೀವು ಹಣ ಪಾವತಿಸುತ್ತೀರಿ ಮತ್ತು ಮಾಡೆಲ್ ನೀಡುವ ಪ್ರತಿಯೊಂದು ಟೋಕನ್ಗೂ ನೀವು ಹಣ ಪಾವತಿಸುತ್ತೀರಿ. ನಿಯಂತ್ರಣವಿಲ್ಲದ ಕಾಂಟೆಕ್ಸ್ಟ್ ಬೆಳವಣಿಗೆಯು ನಿಮ್ಮ ಲಾಭದ ಪ್ರಮಾಣವನ್ನು (margins) ನಿಧಾನವಾಗಿ ಕುಗ್ಗಿಸುತ್ತದೆ.
ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ ಒಂದು ವೈಟ್ಬೋರ್ಡ್ ಇದ್ದಂತೆ
ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ (Context window) ಎಂಬುದು ಒಂದು ಮಾಡೆಲ್ ಒಂದೇ ಬಾರಿಗೆ ಎಷ್ಟು ಮಾಹಿತಿಯನ್ನು ನೋಡಬಲ್ಲದು ಎಂಬುದರ ಮಿತಿಯನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಒಂದು ಸಣ್ಣ ಕೋಣೆಯಲ್ಲಿ ನೇತುಹಾಕಲಾದ ವೈಟ್ಬೋರ್ಡ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನೀವು ಅದನ್ನು ಸಿಸ್ಟಮ್ ಇನ್ಸ್ಟ್ರಕ್ಷನ್ಗಳು, ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗಳು, ಪಡೆದ ದಾಖಲೆಗಳು ಮತ್ತು ಹಿಂದಿನ ಸಂಭಾಷಣೆಗಳಿಂದ ತುಂಬಿಸಬಹುದು. ಆದರೆ ಆ ಬೋರ್ಡ್ನ ಗಾತ್ರ ಎಂದಿಗೂ ಬೆಳೆಯುವುದಿಲ್ಲ. ಹೊಸ ಪಠ್ಯ ಬಂದಾಗ, ಹಳೆಯ ಪಠ್ಯವು ಬೋರ್ಡ್ನ ಅಂಚಿನಿಂದ ಹೊರಬರುತ್ತದೆ.
ಇದು ಮುಖ್ಯವಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಮಾಡೆಲ್ಗಳು ಮಾಹಿತಿಯನ್ನು ಬಿಡಲು (dropping content) ಪ್ರಾರಂಭಿಸಿದಾಗ ನಿಮಗೆ ಎಚ್ಚರಿಕೆ ನೀಡುವುದಿಲ್ಲ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಇನ್ಸ್ಟ್ರಕ್ಷನ್ ಒಂದು ಸುದೀರ್ಘ ಸಂಭಾಷಣೆಯ ಮೇಲ್ಭಾಗದಲ್ಲಿದ್ದರೆ ಮತ್ತು ನೀವು ಸತತವಾಗಿ ಸಂದೇಶಗಳನ್ನು ಸೇರಿಸುತ್ತಾ ಹೋದರೆ, ಆ ಇನ್ಸ್ಟ್ರಕ್ಷನ್ ಅಂತಿಮವಾಗಿ ದೃಷ್ಟಿಯಿಂದ ಹೊರಗುಳಿಯುತ್ತದೆ. ಆಗ ಮಾಡೆಲ್ ತನ್ನ ಮೂಲ (default) ವರ್ತನೆಗೆ ಮರಳಬಹುದು, ನಿಮ್ಮ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ನಿಯಮಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು ಅಥವಾ ಹಿಂದಿನ ಸೂಚನೆಗಳಿಗೆ ವಿರುದ್ಧವಾಗಿ ವರ್ತಿಸಬಹುದು. ವಿವಿಧ ಮಾಡೆಲ್ಗಳು ವಿಭಿನ್ನ ಮಿತಿಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ; ಕೆಲವು ಸಾವಿರಾರು ಟೋಕನ್ಗಳನ್ನು ನಿರ್ವಹಿಸಿದರೆ, ಇನ್ನು ಕೆಲವು ಲಕ್ಷಾಂತರ ಟೋಕನ್ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ, ಆದರೆ ಕಾರ್ಯವಿಧಾನ ಮಾತ್ರ ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಇನ್ಪುಟ್ ಮತ್ತು ಔಟ್ಪುಟ್ ಎರಡೂ ಒಂದೇ ಬಜೆಟ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ. ಎರಡು ಸಾವಿರ ಟೋಕನ್ಗಳ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುವ ಮಾಡೆಲ್ ಬಳಿ, ನೀವು ಹೇಳಿದ ವಿಷಯವನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಲು ಎರಡು ಸಾವಿರ ಕಡಿಮೆ ಟೋಕನ್ಗಳು ಮಾತ್ರ ಲಭ್ಯವಿರುತ್ತವೆ.
ಮೆಮೊರಿ ಎಂಬುದು ಒಂದು ಹ್ಯಾಕ್, ಫೀಚರ್ ಅಲ್ಲ
ಇನ್ಫರೆನ್ಸ್ (inference) ಸಮಯದಲ್ಲಿ ಮಾಡೆಲ್ ತೂಕದ (weights) ಒಳಗಡೆ ಯಾವುದೇ ಶಾಶ್ವತ ಮೆಮೊರಿ ಇರುವುದಿಲ್ಲ. ಇಲ್ಲವೇ ಇಲ್ಲ. ನೀವು ಟ್ಯಾಬ್ ಅನ್ನು ಮುಚ್ಚಿ ನಾಳೆ ಮರಳಿ ಬಂದಾಗ, ಮಾಡೆಲ್ ನಿಮ್ಮನ್ನು ಗುರುತಿಸುವುದಿಲ್ಲ. ಪ್ರತಿಯೊಂದು API ಕರೆಯು ಒಂದು 'ಕೋಲ್ಡ್ ಸ್ಟಾರ್ಟ್' (cold start) ಇದ್ದಂತೆ.
ಮೆಮೊರಿ ಎಂದು ನಿಮಗೆ ಅನಿಸುವುದು ಕೇವಲ ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್ನ ಚಾಣಾಕ್ಷ ಬುಕ್ಕೀಪಿಂಗ್ (bookkeeping) ಮಾತ್ರ. ಫ್ರಂಟ್ಎಂಡ್ ನಿಮ್ಮ ಸಂದೇಶಗಳನ್ನು ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ನೀವು ಹೊಸ ಪ್ರಶ್ನೆಯನ್ನು ಕಳುಹಿಸಿದಾಗ, ಸಾಫ್ಟ್ವೇರ್ ಸಂಬಂಧಿತ ಇತಿಹಾಸವನ್ನು (history) ಪಡೆದು, ಅದನ್ನು ಹೊಸ ಪ್ರಾಂಪ್ಟ್ಗೆ ಜೋಡಿಸಿ, ಇಡೀ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಮಾಡೆಲ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಮಾಡೆಲ್ಗೆ ಇದರ ಬಗ್ಗೆ ಯಾವುದೇ ಅರಿವಿರುವುದಿಲ್ಲ.
ಉತ್ಪನ್ನ ತಂಡಗಳಿಗೆ (product teams) ಈ ವ್ಯತ್ಯಾಸವು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ. ಬಳಕೆದಾರರ ಆದ್ಯತೆಗಳನ್ನು "ನೆನಪಿಟ್ಟುಕೊಳ್ಳಲು" ನೀವು ಮಾಡೆಲ್ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಿದ್ದರೆ, ನೀವು ಮರಳಿನ ಮೇಲೆ ಕಟ್ಟಡ ಕಟ್ಟುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ. ನೀವು ಸ್ವತಃ ಸ್ಟೇಟ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ (state management) ಅನ್ನು ನಿರ್ಮಿಸಬೇಕಾಗುತ್ತದೆ. ಯಾವುದನ್ನು ಕ್ಯಾಶ್ (cache) ಮಾಡಬೇಕು ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ರಿಫ್ರೆಶ್ ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ನೀವೇ ನಿರ್ಧರಿಸಬೇಕು. ಮತ್ತು ನೀವು ಮರಳಿ ಕಳುಹಿಸುವ ಇತಿಹಾಸದ ಪ್ರತಿಯೊಂದು ಬೈಟ್ ಕೂಡ ನಿಮ್ಮ ವೈಟ್ಬೋರ್ಡ್ ಜಾಗವನ್ನು ಬಳಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ.
ಕಾಂಟೆಕ್ಸ್ಟ್ ಯಾವಾಗ ಶಬ್ದವಾಗಿ (noise) ಬದಲಾಗುತ್ತದೆ
ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಅತಿಯಾಗಿ ತುಂಬುವುದು ಅನಿರೀಕ್ಷಿತ ಪರಿಣಾಮಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಶಬ್ದವು (Noise) ಸಿಗ್ನಲ್ ಅನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ. ನೀವು ಕೇವಲ ಒಂದು ಬಗ್ ಬಗ್ಗೆ ಕೇಳಲು ಇಡೀ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ನೀಡಿದರೆ, ಮಾಡೆಲ್ 'ನೀಡಲ್-ಇನ್-ಎ-ಹೇಸ್ಟಾಕ್' (needle-in-a-haystack) ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತದೆ. ಅದು ತಪ್ಪು ಫೈಲ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಬಹುದು, ಬಳಕೆಯಲ್ಲಿಲ್ಲದ (dead code) ಕೋಡ್ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಸೂಚಿಸಬಹುದು ಅಥವಾ ಅದಕ್ಕೆ ಸಾಧ್ಯವಾಗದ ಕಾರಣ ಸಾಮಾನ್ಯವಾದ ಉತ್ತರವನ್ನು ನೀಡಬಹುದು...