ನಿಜವಾಗಿಯೂ ಕೆಲಸ ಮಾಡುವ AI ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನಿರ್ಮಿಸುವುದು ಎಂದರೆ ಕೇವಲ ಪರಿಪೂರ್ಣ ಪ್ರಾಂಪ್ಟ್ (prompt) ತಯಾರಿಸುವುದಲ್ಲ, ಬದಲಾಗಿ ನೀವು ಮಾಡೆಲ್ಗೆ ನೀಡುವ ಮಾಹಿತಿಯನ್ನು ನಿಯಂತ್ರಿಸುವುದರ ಬಗ್ಗೆ ಹೆಚ್ಚು ಇರುತ್ತದೆ. ನೀವು ಎಂದಾದರೂ ಅಸಿಸ್ಟೆಂಟ್ ಜೊತೆ ದೀರ್ಘಕಾಲ ಚಾಟ್ ಮಾಡಿದಾಗ, ಹತ್ತು ನಿಮಿಷಗಳ ಹಿಂದೆ ನೀವು ಹೇಳಿದ ವಿಷಯವನ್ನು ಅದು ಮರೆತುಹೋಯಿತು ಎಂದು ಅರಿವಾದರೆ, ಕಾನ್ಟೆಕ್ಸ್ ಇಂಜಿನಿಯರಿಂಗ್ (context engineering) ವಿಫಲವಾದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಈಗಾಗಲೇ ಅನುಭವಿಸಿರುತ್ತೀರಿ. AI ಗೆ ಕೆಟ್ಟ ನೆನಪಿದೆ ಎಂದು ಭಾವಿಸುವುದು ಸುಲಭ. ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ, ನೀವು ಕಾನ್ಟೆಕ್ಸ್ ವಿಂಡೋ (context window) ನ ಕಠಿಣ ಮಿತಿಗಳನ್ನು ತಲುಪಿರುತ್ತೀರಿ.
ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಸ್ಪಂದಿಸುವ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸಲು, ನೀವು ಮೂರು ಮೂಲಭೂತ ಅಂಶಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ: ಟೋಕನ್ಗಳು (tokens), ಕಾನ್ಟೆಕ್ಸ್ ವಿಂಡೋಗಳು (context windows), ಮತ್ತು ಕಾನ್ಟೆಕ್ಸ್ ಹಾಗೂ ಮೆಮೊರಿ ನಡುವಿನ ವ್ಯತ್ಯಾಸ.
ಟೋಕನ್ಗಳೇ ನಿಜವಾದ ಕರೆನ್ಸಿ
ಟೋಕನ್ ಎಂದರೆ ಒಂದು ಪದವಲ್ಲ. ನೀವು ಮಾಡೆಲ್ಗೆ ಪಠ್ಯವನ್ನು ಕಳುಹಿಸಿದಾಗ, ಟೋಕಿನೈಜರ್ (tokenizer) ಅದನ್ನು ಸಣ್ಣ ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತದೆ. "cat" ಅಥವಾ "the" ನಂತಹ ಚಿಕ್ಕ ಸಾಮಾನ್ಯ ಪದಗಳು ತಲಾ ಒಂದು ಟೋಕನ್ ಆಗಿರಬಹುದು. "internationalization" ನಂತಹ ದಟ್ಟವಾದ ತಾಂತ್ರಿಕ ಪದವನ್ನು ಹಲವಾರು ಭಾಗಗಳಾಗಿ ಕತ್ತರಿಸಲಾಗುತ್ತದೆ. ವಿರಾಮಚಿಹ್ನೆಗಳು, ಜಾಗಗಳು (spaces) ಮತ್ತು ವಿಶೇಷ ಅಕ್ಷರಗಳೂ ಸಹ ಎಣಿಕೆಗೆ ಒಳಪಡುತ್ತವೆ. ಇದು ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ಟೋಕನ್ಗಳು ಎಲ್ಲವನ್ನೂ ನಿರ್ಧರಿಸುತ್ತವೆ: ನಿಮ್ಮ API ಬಿಲ್, ಪ್ರತಿಕ್ರಿಯೆಯ ವೇಗ ಮತ್ತು ಔಟ್ಪುಟ್ನ ಗುಣಮಟ್ಟ.
ವೆಚ್ಚವನ್ನು ಅಳೆಯಲು ಕೇವಲ ಪದಗಳನ್ನು ಎಣಿಸುವ ಡೆವಲಪರ್ ಅರಿಯದೆ ಕೆಲಸ ಮಾಡುತ್ತಿರುತ್ತಾರೆ. ಕೋಡ್ ಬ್ರಾಕೆಟ್ಗಳು ಮತ್ತು ಉದ್ದವಾದ ವೇರಿಯಬಲ್ ಹೆಸರುಗಳಿಂದ ತುಂಬಿದ ನೂರು ಪದಗಳ ಪ್ರಾಂಪ್ಟ್ ಅನಿರೀಕ್ಷಿತವಾಗಿ ಹೆಚ್ಚಿನ ಟೋಕನ್ಗಳನ್ನು ಬಳಸಬಹುದು. ಅದಕ್ಕಾಗಿಯೇ ಟೋಕಿನೈಜರ್ಗಳು ಸ್ವತಂತ್ರ ಸಾಧನಗಳಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. ನೀವು ಯಾವುದೇ ಫೀಚರ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಮೊದಲು, ನಿಮ್ಮ ಸಾಮಾನ್ಯ ಪೇಲೋಡ್ಗಳನ್ನು (payloads) ಒಂದರ ಮೂಲಕ ರನ್ ಮಾಡಿ. ಸಿಸ್ಟಮ್ ಸೂಚನೆಗಳು, ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಬಾಯ್ಲರ್ ಪ್ಲೇಟ್ ಮತ್ತು ಚಾಟ್ ಇತಿಹಾಸವು ನಿಜವಾದ ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗಿಂತ ಹೆಚ್ಚಿನ ಬಜೆಟ್ ಅನ್ನು ಬಳಸುತ್ತವೆ ಎಂಬುದನ್ನು ನೀವು ಆಗಾಗ್ಗೆ ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ. ಮೊದಲ ದಿನದಿಂದಲೇ ಟೋಕನ್ಗಳನ್ನು ಒಂದು ಅಪರೂಪದ ಸಂಪನ್ಮೂಲವಾಗಿ ಪರಿಗಣಿಸಿ.
ಕಾನ್ಟೆಕ್ಸ್ ವಿಂಡೋ ಎಂಬುದು ಒಂದು ನಿಗದಿತ ವೈಟ್ಬೋರ್ಡ್ ಇದ್ದಂತೆ
ಕಾನ್ಟೆಕ್ಸ್ ವಿಂಡೋ ಎಂದರೆ ಒಂದು ರಿಕ್ವೆಸ್ಟ್ನಲ್ಲಿ ಮಾಡೆಲ್ ನೋಡಬಹುದಾದ ಒಟ್ಟು ಮಾಹಿತಿಯ ಪ್ರಮಾಣ. ಇದನ್ನು ನಿಗದಿತ ಅಳತೆಯ ವೈಟ್ಬೋರ್ಡ್ ಎಂದು ಭಾವಿಸಿ. ನೀವು ಇದನ್ನು ಸಿಸ್ಟಮ್ ನಿಯಮಗಳು, ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸ, ಪಡೆಯಲಾದ ದಾಖಲೆಗಳು ಮತ್ತು ಪ್ರಸ್ತುತ ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ತುಂಬಬಹುದು. ಆದರೆ ಒಮ್ಮೆ ಮೇಲ್ಮೈ ತುಂಬಿದ ನಂತರ, ಯಾವುದಾದರೂ ಒಂದು ಬದಲಾಗಲೇಬೇಕು. ಹಳೆಯ ಟಿಪ್ಪಣಿಗಳನ್ನು ಅಳಿಸಬೇಕು, ಫೋಟೋ ತೆಗೆದು ಸಾರಾಂಶ ಮಾಡಬೇಕು ಅಥವಾ ಬೋರ್ಡ್ ಸರಳವಾಗಿ ತುಂಬಿ ಹೋಗುತ್ತದೆ.
ಆಧುನಿಕ ಮಾಡೆಲ್ಗಳು ಕೆಲವು ಸಾವಿರ ಟೋಕನ್ಗಳಿಂದ ಹಿಡಿದು ನೂರಾರು ಸಾವಿರಗಳವರೆಗೆ ಕಾನ್ಟೆಕ್ಸ್ ವಿಂಡೋಗಳನ್ನು ಹೊಂದಿವೆ ಎಂದು ಜಾಹೀರಾತು ನೀಡುತ್ತವೆ. ದೊಡ್ಡ ವಿಂಡೋವನ್ನು ಅನ್ಲಿಮಿಟೆಡ್ ಸ್ಟೋರೇಜ್ ಎಂದು ಪರಿಗಣಿಸುವುದು ಆಕರ್ಷಕವಾಗಿ ಕಾಣಬಹುದು. ಆದರೆ ಅದು ಅನ್ಲಿಮಿಟೆಡ್ ಅಲ್ಲ. ವೈಟ್ಬೋರ್ಡ್ಗೆ ಇಂದಿಗೂ ಅಂಚುಗಳಿರುತ್ತವೆ. ಇತಿಹಾಸವು ಮಿತಿಯನ್ನು ಮೀರಿದಾಗ, ಅಪ್ಲಿಕೇಶನ್ ಹಳೆಯ ಸಂದೇಶಗಳನ್ನು ಬಿಡಬೇಕಾಗುತ್ತದೆ ಅಥವಾ ಅವುಗಳನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ (compress). ಈ ಮಿತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ನೀವು ವಿಂಡೋವನ್ನು ಡೇಟಾಬೇಸ್ನಂತೆ ನೋಡುವ ಬದಲು, ಅದನ್ನು ಒಂದು ಸಕ್ರಿಯ ಕೆಲಸದ ಸ್ಥಳದಂತೆ (active workspace) ನೋಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಕಾನ್ಟೆಕ್ಸ್ ಎಂದರೆ ಮೆಮೊರಿ ಅಲ್ಲ
ಅನುಭವಿ ನಿರ್ಮಾತೃಗಳನ್ನೂ ಸಹ ಗೊಂದಲಕ್ಕೀಡುಮಾಡುವ ವ್ಯತ್ಯಾಸವಿದು. ಮಾಡೆಲ್ ಸ್ವತಃ ಸ್ಟೇಟ್ಲೆಸ್ (stateless). ಅದು ನಿನ್ನೆ, ಕಳೆದ ವಾರ ಅಥವಾ ಬೇರೆ ಸೆಶನ್ನಲ್ಲಿ ಹತ್ತು ನಿಮಿಷಗಳ ಹಿಂದೆ ನೀವು ಯಾರೆಂದು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದಿಲ್ಲ. ಒಂದು AI ನಿಮಗೆ JavaScript ಗಿಂತ Python ಇಷ್ಟ ಎಂದು ಅಥವಾ ನಿಮಗೆ ಸಂಕ್ಷಿಪ್ತ ಉತ್ತರಗಳು ಇಷ್ಟ ಎಂದು ನೆನಪಿಸಿಕೊಂಡರೆ, ಆ ಮೆಮೊರಿ ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್ನಲ್ಲಿ ಇರುತ್ತದೆ, ಮಾಡೆಲ್ನಲ್ಲಿ ಅಲ್ಲ.
ಅಪ್ಲಿಕೇಶನ್ ಆ ಸತ್ಯಗಳನ್ನು ಡೇಟಾಬೇಸ್, ಕ್ಯಾಶ್ ಅಥವಾ ಮೆಮೊರಿ ಸ್ಟೋರ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಹೊಸ ರಿಕ್ವೆಸ್ಟ್ನಲ್ಲಿ, ಅದು ಸಂಬಂಧಿತ ಪ್ರೊಫೈಲ್ ಡೇಟಾವನ್ನು ಮತ್ತೆ ಪ್ರಾಂಪ್ಟ್ಗೆ ಸೇರಿಸುತ್ತದೆ. ಮಾಡೆಲ್ ಕೇವಲ ಮೊದಲ ಅಂಕಣದ ಸಾಲುಗಳನ್ನು ಒಳಗೊಂಡ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಓದುತ್ತಿದೆ ಅಷ್ಟೆ. ಅದಕ್ಕೆ ಯಾವುದೇ ಶಾಶ್ವತ ಅಸ್ತಿತ್ವವಿಲ್ಲ. ಒಮ್ಮೆ ನೀವು ಈ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ಬದಲಾಗುತ್ತದೆ. ನೀವು ಮಾಡೆಲ್ ನೆನಪಿಟ್ಟುಕೊಳ್ಳಲಿ ಎಂದು ಕೇಳುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಸರಿಯಾದ ಸಮಯದಲ್ಲಿ ಸರಿಯಾದ ಕಾನ್ಟೆಕ್ಸ್ ಅನ್ನು ಪಡೆಯುವ ವ್ಯವಸ್ಥೆಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ.
ಹೆಚ್ಚಿನ ಕಾನ್ಟೆಕ್ಸ್ ಏಕೆ ವಿಫಲವಾಗಬಹುದು
ಹೆಚ್ಚಿನ ಹಿನ್ನೆಲೆ ಮಾಹಿತಿ ನೀಡಿದರೆ ಉತ್ತಮ ಉತ್ತರಗಳು ಸಿಗುತ್ತವೆ ಎಂಬುದು ಸಾಮಾನ್ಯ ಜ್ಞಾನ. ಆದರೆ ಹೆಚ್ಚಾಗಿ ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ನಡೆಯುತ್ತದೆ. ಅತಿಯಾದ ಕಾನ್ಟೆಕ್ಸ್ ಗೊಂದಲವನ್ನು (noise) ಸೃಷ್ಟಿಸುತ್ತದೆ. ನಿಮಗೆ ಕೇವಲ ಒಂದು ಫಂಕ್ಷನ್ ಸರಿಪಡಿಸಬೇಕಿದ್ದಾಗ ನೀವು ಇಡೀ ಕೋಡ್ ಬೇಸ್ ಅನ್ನು ಮಾಡೆಲ್ಗೆ ನೀಡಿದರೆ, ಅದು ಅಸ್ತವ್ಯಸ್ತತೆಯ ನಡುವೆ ಸರಿಯಾದ ಮಾಹಿತಿಯನ್ನು ಹುಡುಕಲು ಒತ್ತಾಯಿಸಿದಂತಾಗುತ್ತದೆ. ಸಂಶೋಧಕರು "Lost in the Middle" ಪರಿಣಾಮವನ್ನು ಗುರುತಿಸಿದ್ದಾರೆ: ಮಾಡೆಲ್ಗಳು ಪ್ರಾಂಪ್ಟ್ನ ಆರಂಭ ಮತ್ತು ಅಂತ್ಯದ ವಿವರಗಳಿಗೆ ಹೆಚ್ಚು ಗಮನ ನೀಡುತ್ತವೆ, ಆದರೆ ಮಧ್ಯದಲ್ಲಿ ಹೂತುಹೋಗಿರುವ ಮಾಹಿತಿಯನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು ಅಥವಾ ಅದರ ತೀವ್ರತೆ ಕಡಿಮೆಯಾಗಬಹುದು. ಇದು ನೀವು ಚತುರ ಪದಬಳಕೆಯಿಂದ ಸರಿಪಡಿಸಬಹುದಾದ ಬಗ್ ಅಲ್ಲ. ಇದು ಟ್ರಾನ್ಸ್ಫಾರ್ಮರ್ ಆಧಾರಿತ ಆರ್ಕಿಟೆಕ್ಚರ್ಗಳಲ್ಲಿರುವ ಒಂದು ರಚನಾತ್ಮಕ ನಡವಳಿಕೆಯಾಗಿದೆ.
ಅತಿಯಾದ ಪ್ರಾಂಪ್ಟ್ಗಳು ನಿಮ್ಮ ವೆಚ್ಚ ಮತ್ತು ವೇಗದ ಮೇಲೆ ನೇರ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ. ಪ್ರತಿ ಹೆಚ್ಚುವರಿ ಟೋಕನ್ ಸಂಸ್ಕರಣೆಯನ್ನು (computation) ಬಯಸುತ್ತದೆ. ಇದರಿಂದ ವಿಳಂಬ (latency) ಹೆಚ್ಚಾಗುತ್ತದೆ, ವೆಚ್ಚ ಏರುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರ ತಾಳ್ಮೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಅಪ್ರಸ್ತುತ ದಾಖಲೆಗಳಿಂದ ತುಂಬಿದ ಪ್ರಾಂಪ್ಟ್ ವಿರೋಧಾಭಾಸಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ, ಮಾಡೆಲ್ ಅನ್ನು ಅಪ್ರಸ್ತುತ ವಿವರಗಳಿಂದ ವಿಚಲಿತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯು ತಪ್ಪು ಸಮಸ್ಯೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ಪ್ರಮಾಣವು ನಿಖರತೆಯ ಶತ್ರುವಾಗಿದೆ.
ಉತ್ತಮ ಕಾನ್ಟೆಕ್ಸ್ ಅನ್ನು ಹೇಗೆ ಇಂಜಿನಿಯರ್ ಮಾಡುವುದು
ಉತ್ತಮ ಕಾನ್ಟೆಕ್ಸ್ ಇಂಜಿನಿಯರಿಂಗ್ ಎನ್ನುವುದು ಕಠಿಣವಾದ ಎಡಿಟಿಂಗ್ನ ಒಂದು ಅಭ್ಯಾಸವಾಗಿದೆ. ಅದನ್ನು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು ಹೇಗೆ ಎಂಬುದು ಇಲ್ಲಿದೆ.
ಕೆಲಸಕ್ಕೆ ಅಗತ್ಯವಿರುವಿದ್ದನ್ನು ಮಾತ್ರ ಕಳುಹಿಸಿ. ಬಳಕೆದಾರರು ನಿಮ್ಮ ಮರುಪಾವತಿ ನೀತಿಯನ್ನು (refund policy) ಕೇಳಿದರೆ, ಉದ್ಯೋಗಿ ಕೈಪಿಡಿ, API ದಾಖಲೆಗಳು ಮತ್ತು ಕಳೆದ ತ್ರೈಮಾಸಿಕದ ಮಾರ್ಕೆಟಿಂಗ್ ಪ್ರತಿಯನ್ನು ಸೇರಿಸಬೇಡಿ. ಸಮಗ್ರತೆಗಿಂತ ಪ್ರಸ್ತುತತೆಯೇ ಮುಖ್ಯ.
ಪ್ರಸ್ತುತ ದಾಖಲೆಗಳನ್ನು ಪಡೆಯಲು RAG ಬಳಸಿ. Retrieval-Augmented Generation ನಿಮಗೆ ದೊಡ್ಡ ಜ್ಞಾನದ ತಳಪದಿಯನ್ನು (knowledge base) ಹುಡುಕಲು ಮತ್ತು ಅತ್ಯಂತ ಹೆಚ್ಚು ಹೊಂದಿಕೆಯಾಗುವ ಭಾಗಗಳನ್ನು ಮಾತ್ರ ಪ್ರಾಂಪ್ಟ್ಗೆ ಸೇರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಸಾವಿರ ಪುಟಗಳ ಮ್ಯಾನುಯಲ್ ಅನ್ನು ವಿಂಡೋಗೆ ಹಾಕುವ ಬದಲು, ನಿಮ್ಮ ದಾಖಲೆಗಳನ್ನು ಎಂಬೆಡ್ (embed) ಮಾಡಿ, ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗೆ ವಿರುದ್ಧವಾಗಿ ಸೆಮ್ಯಾಂಟಿಕ್ ಸರ್ಚ್ (semantic search) ನಡೆಸಿ, ಅತ್ಯಂತ ಪ್ರಸ್ತುತವಾದ ಮೂರು ಪ್ಯಾರಾಗ್ರಾಫ್ಗಳನ್ನು ಸೇರಿಸಿ. ಇದರಿಂದ ಮಾಡೆಲ್ಗೆ ಬೇಕಾದ ಮಾಹಿತಿ ನಿಖರವಾಗಿ ಸಿಗುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಟೋಕನ್ ಬಜೆಟ್ ಕೂಡ ಉಳಿತಾಯವಾಗುತ್ತದೆ.
ಹಳೆಯ ಸಂಭಾಷಣೆಗಳನ್ನು ಸಾರಾಂಶಗೊಳಿಸಿ. ಪೂರ್ಣ ಚಾಟ್ ಟ್ರಾನ್ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ದುಬಾರಿ ಮತ್ತು ಗೊಂದಲಮಯವಾಗಿರುತ್ತವೆ. ದೀರ್ಘ ಸಂದೇಶ ಇತಿಹಾಸದ ಬದಲಿಗೆ ಸಂಕ್ಷಿಪ್ತ ಸಾರಾಂಶಗಳನ್ನು ಬಳಸಿ. ಉದಾಹರಣೆಗೆ, ಮಾಡೆಲ್ಗೆ ಮೂವತ್ತು ಸಂದೇಶಗಳನ್ನು ನೀಡುವ ಬದಲು, ಒಂದು ಪ್ಯಾರಾಗ್ರಾಫ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಿ: "ಬಳಕೆದಾರರು Django ನಿಯೋಜನೆ (deployment) ಬಗ್ಗೆ ಕೇಳಿದರು, ಸ್ಟ್ಯಾಟಿಕ್ ಫೈಲ್ಸ್ ದೋಷ ಎದುರಿಸಿದರು ಮತ್ತು ಅನುಮತಿಗಳನ್ನು (permissions) ಸರಿಪಡಿಸಿದರು. ಪ್ರಸ್ತುತ ಸಮಸ್ಯೆ Postgres 14 ನಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಮೈಗ್ರೇಶನ್ ವಿಫಲವಾಗುತ್ತಿರುವುದು." ಈ ಸಾರಾಂಶವು ವೈಟ್ಬೋರ್ಡ್ ಅನ್ನು ಗೊಂದಲಕ್ಕೀಡು ಮಾಡದೆ ಸ್ಥಿತಿಯನ್ನು (state) ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ.
ದೀರ್ಘಾವಧಿಯ ನೆನಪನ್ನು ಸಕ್ರಿಯ ಚಾಟ್ನಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ. ಬಳಕೆದಾರರ ಆದ್ಯತೆಗಳು, ಪ್ರಾಜೆಕ್ಟ್ ಸೆಟ್ಟಿಂಗ್ಗಳು ಮತ್ತು ಖಾತೆ ಇತಿಹಾಸವು ಬಾಹ್ಯ ಮೆಮೊರಿ ಸ್ಟೋರ್ನಲ್ಲಿರಬೇಕು. ಆ ಸ್ಟೋರ್ ಅನ್ನು ಆಯ್ದುಕೊಂಡಂತೆ (selectively) ಪ್ರಶ್ನಿಸಿ. ಲೈವ್ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋವು ಕೇವಲ ತಕ್ಷಣದ ಕೆಲಸ ಮತ್ತು ನಿರಂತರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಅಗತ್ಯವಿರುವ ಅತ್ಯಂತ ಸಂಕ್ಷಿಪ್ತ ವೈಯಕ್ತಿಕ ಸಂದರ್ಭವನ್ನು ಮಾತ್ರ ಹೊಂದಿರಬೇಕು.
ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಟೋಕನ್ ಬಳಕೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ. ಲೇಟೆನ್ಸಿ ಏರಿಕೆಗಳು (latency spikes) ಹೆಚ್ಚಾಗಿ ಕಾಂಟೆಕ್ಸ್ಟ್ ಅತಿಯಾಗಿರುವುದಕ್ಕೆ (context bloat) ಕಾರಣವಾಗುತ್ತವೆ. ವಿನಂತಿಗಳು ನಿಮ್ಮ ಮಾಡೆಲ್ನ ಮಿತಿಯನ್ನು ತಲುಪಿದಾಗ ಅಲರ್ಟ್ಗಳನ್ನು ಹೊಂದಿಸಿ. ಅನಗತ್ಯ ಮಾಹಿತಿ ಇರುವ ಪ್ರಾಂಪ್ಟ್ಗಳನ್ನು ಗುರುತಿಸಲು ಲಾಗ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಆಪ್ಟಿಮೈಸೇಶನ್ ಯಾವಾಗಲೂ ಒಂದೇ ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ: ಕೆಲಸಕ್ಕೆ ತೊಂದರೆಯಾಗದಂತೆ ನಾವು ಏನನ್ನು ತೆಗೆದುಹಾಕಬಹುದು?
ನಿಜವಾದ ಸಾರಾಂಶ
ಅತ್ಯುತ್ತಮ AI ಅಪ್ಲಿಕೇಶನ್ಗಳು ದೊಡ್ಡ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋಗಳನ್ನು ಹೊಂದಿದ್ದವು ಎಂಬ ಕಾರಣಕ್ಕೆ ಗೆಲ್ಲುವುದಿಲ್ಲ. ಅವು ಕಾಂಟೆಕ್ಸ್ಟ್ ಅನ್ನು ಶಿಸ್ತಿನಿಂದ ನಿರ್ವಹಿಸುವುದರಿಂದ ಗೆಲ್ಲುತ್ತವೆ. ಒಂದು ದೊಡ್ಡ ವೈಟ್ಬೋರ್ಡ್ ಮೇಲೆ ಅಸ್ತವ್ಯಸ್ತವಾಗಿ ಬರೆದಿದ್ದರೆ ಅದು ಪ್ರಯೋಜನವಿಲ್ಲದಂತಾಗುತ್ತದೆ. ಮಾಹಿತಿ ಪಡೆಯುವ (retrieve), ಸಾರಾಂಶಗೊಳಿಸುವ (summarize) ಮತ್ತು ಫಿಲ್ಟರ್ ಮಾಡುವ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸಿ. ಇದರಿಂದ ನಿಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ವೇಗವಾಗಿ ಉತ್ತರಗಳು ಸಿಗುತ್ತವೆ, ನಿಮ್ಮ ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ವೆಚ್ಚಗಳು ಮುನ್ಸೂಚನೆಗೆ ಅನುಗುಣವಾಗಿರುತ್ತವೆ ಮತ್ತು ನಿಮ್ಮ ಮಾಡೆಲ್ಗಳು ಅಂತಿಮವಾಗಿ ನಿಜವಾಗಿಯೂ ಮುಖ್ಯವಾದ ವಿಷಯಗಳ ಮೇಲೆ ಗಮನ ಹರಿಸುತ್ತವೆ.
Source: AI Context Engineering: Tokens, Context Windows, & Memory
Community: GyaanSetu AI on Telegram