ನೀವು ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆಯೊಂದಿಗೆ (artificial intelligence) ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಎಲ್ಲರೂ ಒಂದೇ ವಿಷಯದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಾರೆ: ಅದುವೇ 'model'. ಸರಿಯಾದ ಮಾಡೆಲ್ ಅನ್ನು ಆರಿಸಿ, ಆಗ ಉಳಿದೆಲ್ಲವೂ ಸುಲಭವಾಗುತ್ತದೆ ಎಂದು ಅವರು ಹೇಳುತ್ತಾರೆ. ನನ್ನ ಸ್ವಂತ ಪ್ರಯೋಗಗಳ ಕೆಲವು ವಾರಗಳ ನಂತರ, ಅದು ಕೇವಲ ನಿಜವಲ್ಲ ಎಂದು ನಾನು ಹೇಳಬಲ್ಲೆ. ಲಭ್ಯವಿರುವ ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿಗಳ (large language models) ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುವುದು ಮುಖ್ಯವಾಗಿದ್ದರೂ, ಅದು ಕೆಲಸದ ಕೇವಲ ಇಪ್ಪತ್ತು ಪ್ರತಿಶತ ಮಾತ್ರ. ಉಳಿದದ್ದು ಸಿಸ್ಟಮ್ಸ್ ಕೆಲಸ (systems work). ಇದು ಪ್ಲಂಬಿಂಗ್, ಕಲೆ ಮತ್ತು ನಿರಂತರ ಪರೀಕ್ಷೆಯ ಕೆಲಸ. ಈ ಅರಿವು ನನಗೆ ಮೊದಲೇ ಲಭ್ಯವಾಯಿತು ಮತ್ತು ಅಂದಿನಿಂದ ನಾನು ಪ್ರತಿಯೊಂದು ಪ್ರಾಜೆಕ್ಟ್ಗೆ ಹೋಗುವ ವಿಧಾನವನ್ನೇ ಬದಲಿಸಿಕೊಂಡೆ.
ಮಾಡೆಲ್ ಕೇವಲ ಆರಂಭವಷ್ಟೇ
ಆರಂಭಿಕರು ಮಾಡೆಲ್ಗಳ ಬಗ್ಗೆ ಅತಿಯಾಗಿ ಯಾಕೆ ಆಸಕ್ತಿ ತೋರಿಸುತ್ತಾರೆ ಎಂಬುದು ಸುಲಭವಾಗಿ ಅರ್ಥವಾಗುತ್ತದೆ. ಹೊಸ ಬಿಡುಗಡೆಗಳ ನೋಟ್ಸ್ (release notes) ಉತ್ತಮ ತರ್ಕ (reasoning), ದೊಡ್ಡ ಕಾನ್ಟೆಕ್ಸ್ಟ್ ವಿಂಡೋಗಳು (context windows) ಮತ್ತು ಸ್ವಚ್ಛವಾದ ಔಟ್ಪುಟ್ಗಳನ್ನು ಭರವಸೆ ನೀಡುತ್ತವೆ. ಆ ಸುಧಾರಣೆಗಳು ನಿಜವಾಗಿಯೂ ಇವೆ, ಆದರೆ ಅವು ಸಾಮಾನ್ಯ ಉದ್ದೇಶಕ್ಕಾಗಿ ಮಾತ್ರ. ಅತ್ಯಾಧುನಿಕ ಮಾಡೆಲ್ ನಿಮ್ಮ ಕಂಪನಿಯ ರಿಫಂಡ್ ನೀತಿಯನ್ನು ತಾನಾಗಿಯೇ ತಿಳಿಯುವುದಿಲ್ಲ. ನೀವು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ಹೇಳದ ಹೊರತು ಅದು ನಿಮ್ಮ ಮೊಬೈಲ್ ಆಪ್ಗಾಗಿ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ನಿಖರವಾಗಿ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡುವುದಿಲ್ಲ. ಅದು ಶೂನ್ಯದಿಂದ ಲೈವ್ ಇನ್ವೆಂಟರಿ ಡೇಟಾವನ್ನು ತರಲು ಸಾಧ್ಯವಿಲ್ಲ.
ನಾನು ಇದನ್ನು ಕಷ್ಟಪಟ್ಟು ಕಲಿತೆ. ನನ್ನ ಮೊದಲ ಪ್ರೊಟೊಟೈಪ್ (prototype) ಒಂದು ಸಮರ್ಥ ಮಾಡೆಲ್ ಅನ್ನು ಬಳಸುತ್ತಿತ್ತು ಮತ್ತು ಸುಂದರವಾದ, ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಕೂಡಿದ ಪ್ಯಾರಾಗ್ರಾಫ್ಗಳನ್ನು ನೀಡುತ್ತಿತ್ತು, ಆದರೆ ಅವು ಕೆಲವೊಮ್ಮೆ ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಾಗಿದ್ದವು. ಮಾಡೆಲ್ ಧ್ವನಿಯನ್ನು (tone) ಕರಗತ ಮಾಡಿಕೊಂಡಿದ್ದರಿಂದ ಪಠ್ಯವು ವೃತ್ತಿಪರವಾಗಿ ಕೇಳಿಸುತ್ತಿತ್ತು, ಆದರೆ ಅದಕ್ಕೆ ಇತ್ತೀಚಿನ ಮಾಹಿತಿಯ ಪ್ರವೇಶವಿರಲಿಲ್ಲ. ನಾನು ಡೇಟಾ ಪೈಪ್ಲೈನ್ಗಳು (data pipelines) ಮತ್ತು ಕಾನ್ಟೆಕ್ಸ್ಟ್ ಇಂಜೆಕ್ಷನ್ (context injection) ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕಿದ್ದ ಸಮಯದಲ್ಲಿ, ಮಾಡೆಲ್ ಬೆಂಚ್ಮಾರ್ಕ್ಗಳನ್ನು ಹೋಲಿಕೆ ಮಾಡಲು ದಿನಗಟ್ಟಲೆ ಕಳೆಯುತ್ತಿದ್ದೆ. ಮಾಡೆಲ್ ಕೆಟ್ಟದ್ದಾಗಿರಲಿಲ್ಲ. ಅದರ ಸುತ್ತಲಿನ ಸಿಸ್ಟಮ್ ಅಪೂರ್ಣವಾಗಿತ್ತು. ನೀವು ಕೇವಲ ಡೆಮೋಗಳಿಂದ ಜನರು ನಿಜವಾಗಿಯೂ ಅವಲಂಬಿಸುವ ಸಾಫ್ಟ್ವೇರ್ಗೆ ಬದಲಾದಾಗ, ಈ ವ್ಯತ್ಯಾಸವೇ ಎಲ್ಲವೂ.
ಪ್ರಾಂಪ್ಟ್ಗಳು ಕೋಡ್ ಆಗಿವೆ, ಸಲಹೆಗಳಲ್ಲ
ಯಾವುದೇ ವಿಶ್ವಾಸಾರ್ಹ AI ಅಪ್ಲಿಕೇಶನ್ನ ಹೃದಯಭಾಗದಲ್ಲಿ ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಪ್ರಾಂಪ್ಟ್ಗಳು (prompts) ಇರುತ್ತವೆ. ಆರಂಭದಲ್ಲಿ, ನಾನು ಪ್ರಾಂಪ್ಟ್ಗಳನ್ನು ಸರ್ಚ್ ಕ್ವೆರಿಗಳಂತೆ (search queries)—ಅಂದರೆ ಚಿಕ್ಕದಾಗಿ, ಸಾಧಾರಣವಾಗಿ ಮತ್ತು ಆಶಾವಾದಿಯಾಗಿ ಪರಿಗಣಿಸುತ್ತಿದ್ದೆ. ನಾನು ಮಾಡೆಲ್ಗೆ "ಇದನ್ನು ಸಾರಾಂಶ ಮಾಡಿ" ಅಥವಾ "ಸಹಾಯ ಮಾಡಿ" ಎಂದು ಕೇಳುತ್ತಿದ್ದೆ ಮತ್ತು ಉತ್ತಮ ಫಲಿತಾಂಶಕ್ಕಾಗಿ ಕಾಯುತ್ತಿದ್ದೆ. ಫಲಿತಾಂಶಗಳು ಉಪಯುಕ್ತ ಮತ್ತು ಅಪ್ರಸ್ತುತಗಳ ನಡುವೆ ಅತಿಯಾಗಿ ಏರಿಳಿತವಾಗುತ್ತಿದ್ದವು ಮತ್ತು ಅದಕ್ಕೆ ಕಾರಣವೇನು ಎಂಬುದು ನನಗೆ ತಿಳಿದಿರಲಿಲ್ಲ.
ಈಗ ನಾನು ಪ್ರಾಂಪ್ಟ್ಗಳನ್ನು ಲೈಟ್ವೇಯಿಟ್ ಪ್ರೋಗ್ರಾಂಗಳಂತೆ (lightweight programs) ಪರಿಗಣಿಸುತ್ತೇನೆ. ಒಂದು ಉತ್ತಮ ಪ್ರಾಂಪ್ಟ್ ಪಾತ್ರವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಔಟ್ಪುಟ್ ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ, ಅಗತ್ಯವಿದ್ದಾಗ ಉದಾಹರಣೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ಮಿತಿಗಳನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ. ನನಗೆ JSON ಬೇಕಿದ್ದರೆ, ನಾನು JSON ಅನ್ನು ಕೇಳುತ್ತೇನೆ ಮತ್ತು ಅದರ ಸ್ಕೀಮಾವನ್ನು (schema) ತೋರಿಸುತ್ತೇನೆ. ನನಗೆ ಸಂಕ್ಷಿಪ್ತ ಉತ್ತರ ಬೇಕಿದ್ದರೆ, ನಾನು ಉದ್ದವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಮಿತಿಗೊಳಿಸುತ್ತೇನೆ ಮತ್ತು ಪೀಠಿಕೆಯನ್ನು (preamble) ನಿಷೇಧಿಸುತ್ತೇನೆ. ಪುನರಾವರ್ತನೆ (Iteration) ಮುಖ್ಯವಾಗುತ್ತದೆ. ನಾನು ಪ್ರಾಂಪ್ಟ್ಗಳು ಮತ್ತು ಅವುಗಳ ಔಟ್ಪುಟ್ಗಳ ಲಾಗ್ ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತೇನೆ ಮತ್ತು ಒಂದೊಮ್ಮೆ ಒಂದು ವೇರಿಯೇಬಲ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತೇನೆ. ಪ್ರಾಂಪ್ಟ್ನಲ್ಲಿರುವ ಒಂದು ಅಸ್ಪಷ್ಟ ವಿಶೇಷಣವು ಇಡೀ ವರ್ಕ್ಫ್ಲೋದ (workflow) ನಡವಳಿಕೆಯನ್ನು ಬದಲಾಯಿಸಬಹುದು. ಆ ಸೂಕ್ಷ್ಮತೆಯು ಕಟ್ಟುನಿಟ್ಟಾದ ಕ್ರಮವನ್ನು ಬಯಸುತ್ತದೆಯೇ ಹೊರತು ಊಹಾಪೋಹವನ್ನಲ್ಲ.
ಕಸ ಹಾಕಿದರೆ ಕಸವೇ ಹೊರಬರುತ್ತದೆ (Garbage In, Garbage Out)
ಅನೇಕ AI ಪ್ರಾಜೆಕ್ಟ್ಗಳು ನಿಧಾನವಾಗಿ ವಿಫಲವಾಗುವುದು ಡೇಟಾ ರಿಟ್ರಿೀವಲ್ (data retrieval) ಸರಿಯಾಗಿ ಇಲ್ಲದಿದ್ದಾಗ. ಮಾಡೆಲ್ಗಳಿಗೆ ಖಾಸಗಿ ಅಥವಾ ಪ್ರಸ್ತುತ ಡೇಟಾವನ್ನು ನೀಡಲು 'ರಿಟ್ರಿೀವಲ್-ಆಗ್ಮೆಂಟೆಡ್ ಜನರೇಷನ್' (Retrieval-Augmented Generation) ಅಥವಾ RAG ಪ್ರಮಾಣಿತ ಮಾದರಿಯಾಗಿದೆ. ಇದರ ಕಲ್ಪನೆ ಸರಳವಾಗಿದೆ: ಸಂಬಂಧಿತ ದಾಖಲೆಗಳನ್ನು ಪಡೆದುಕೊಳ್ಳಿ, ಅವುಗಳನ್ನು ಮಾಡೆಲ್ನ ಕಾನ್ಟೆಕ್ಸ್ಟ್ ವಿಂಡೋಗೆ ಹಾಕಿ ಮತ್ತು ಮಾಡೆಲ್ ಸತ್ಯಗಳ ಮೇಲೆ ತರ್ಕ ಮಾಡಲಿ. ಆದರೆ ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ.
ಸಂಬಂಧವಿಲ್ಲದ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತಿದ್ದ ಒಂದು ಸರಳ ನೌಲೆಡ್ಜ್ ಬೇಸ್ ಅನ್ನು (knowledge base) ಡಿಬಗ್ ಮಾಡಲು ನಾನು ಸಮಯ ವ್ಯಯಿಸಿದೆ. ಮಾಡೆಲ್ ಸರಿಯಾಗಿತ್ತು. ರಿಟ್ರಿೀವಲ್ ಲೇಯರ್ (retrieval layer) ವಿಫಲವಾಗುತ್ತಿತ್ತು. ನನ್ನ ಚಂಕ್ಗಳು (chunks) ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದ್ದವು ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಕಾನ್ಟೆಕ್ಸ್ಟ್ ಇರಲಿಲ್ಲ. ಡ್ಯುಪ್ಲಿಕೇಟ್ ಹೆಡರ್ಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸದೆ ನನ್ನ ಎಂಬೆಡ್ಡಿಂಗ್ಗಳನ್ನು (embeddings) ಸೃಷ್ಟಿಸಲಾಗಿತ್ತು. ಸಿಮಿಲಾರಿಟಿ ಸರ್ಚ್ (similarity search) ತಾಂತ್ರಿಕವಾಗಿ ಹತ್ತಿರವಿರುವ ಆದರೆ ತಪ್ಪು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವ ಪಠ್ಯವನ್ನು ಕಂಡುಕೊಂಡಿತು. ಇದನ್ನು ಸರಿಪಡಿಸಬೇಕೆಂದರೆ ಚಂಕಿಂಗ್ ಸ್ಟ್ರಾಟಜಿ (chunking strategy) ಬಗ್ಗೆ ಮರುಚಿಂತನೆ ಮಾಡುವುದು, ಮೆಟಾಡೇಟಾ ಫಿಲ್ಟರ್ಗಳನ್ನು ಸೇರಿಸುವುದು ಮತ್ತು ರೀ-ರ್ಯಾಂಕಿಂಗ್ ಹಂತವನ್ನು ಪರಿಚಯಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ರಿಟ್ರಿೀವಲ್ ಸ್ಥಿರವಾದ ನಂತರ, ಮಾಡೆಲ್ನ ಉತ್ತರಗಳು ತಕ್ಷಣವೇ ಸುಧಾರಿಸಿದವು. ಪಾಠ ಸ್ಪಷ್ಟವಾಗಿತ್ತು: ನೀವು ಉತ್ತಮ ಮಾಡೆಲ್ ಬಳಸಿ ಕೆಟ್ಟ ಡೇಟಾ ರಿಟ್ರಿವಲ್ ಅನ್ನು ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ನೀವು ಪೈಪ್ಲೈನ್ ಅನ್ನು ಸರಿಯಾಗಿ ನಿರ್ಮಿಸಬೇಕು.
ನೀವು ಅಳೆಯದಿದ್ದನ್ನು ಸುಧಾರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ
ನಿರಂತರ ಮೌಲ್ಯಮಾಪನವು (evaluation) ಪ್ರಯೋಗಗಳನ್ನು ಉತ್ಪನ್ನಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸುವ ಅಭ್ಯಾಸವಾಗಿದೆ. ನಾನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನಾನು ಕೇವಲ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ (vibe) ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತಿದ್ದೆ. ನಾನು ಐದು ಔಟ್ಪುಟ್ಗಳನ್ನು ಓದುತ್ತಿದ್ದೆ, ಸಮ್ಮತಿಸುತ್ತಿದ್ದೆ ಮತ್ತು ಮುಂದೆ ಹೋಗುತ್ತಿದ್ದೆ. ಬಳಕೆದಾರರು ಆರನೇ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಿ ಏನಾದರೂ ವಿಚಿತ್ರವಾದ ಉತ್ತರ ಪಡೆದರೆ ಮಾತ್ರ ಇದು ಸಮಸ್ಯೆಯಾಗುತ್ತದೆ.
ಈಗ ನಾನು ಪ್ರತಿಯೊಂದು ಫೀಚರ್ಗಾಗಿ ಸಣ್ಣ ಮೌಲ್ಯಮಾಪನ ಸೆಟ್ಗಳನ್ನು (evaluation sets) ನಿರ್ಮಿಸುತ್ತೇನೆ. ನಾನು ನೈಜ ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇನೆ, ನಿರೀಕ್ಷಿತ ನಡವಳಿಕೆಯನ್ನು ಗುರುತಿಸುತ್ತೇನೆ ಮತ್ತು ಅವುಗಳ ವಿರುದ್ಧ ಸ್ವಯಂಚಾಲಿತ ಪರಿಶೀಲನೆಗಳನ್ನು ನಡೆಸುತ್ತೇನೆ. ನಾನು 'ಡ್ರಿಫ್ಟ್' (drift) ಬಗ್ಗೆ ಗಮನಿಸುತ್ತೇನೆ: ಕಳೆದ ತಿಂಗಳು ಕೆಲಸ ಮಾಡಿದ ಪ್ರಾಂಪ್ಟ್ ಮಾಡೆಲ್ ಅಪ್ಡೇಟ್ ಆದ ನಂತರ ಅಥವಾ ಮೂಲ ಡೇಟಾ ಬದಲಾದ ನಂತರ ಕ್ಷೀಣಿಸಬಹುದು. ನಾನು ಶೈಲಿಯ ಮೌಲ್ಯಮಾಪನವನ್ನು ಸತ್ಯಾಸತ್ಯತೆಯ ಮೌಲ್ಯಮಾಪನದಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತೇನೆ. ವೃತ್ತಿಪರವಾಗಿ ಕಾಣುವುದು ಒಳ್ಳೆಯದು; ಆದರೆ ಸರಿಯಾಗಿರುವುದು ಕಡ್ಡಾಯ. ಈ ಲೂಪ್ ಇಲ್ಲದೆ, ನೀವು ಕೇವಲ ಭರವಸೆಯ ಮೇಲೆ ಉತ್ಪನ್ನವನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತೀರಿ, ಮತ್ತು ಭರವಸೆಯು ಪರೀಕ್ಷಾ ತಂತ್ರವಲ್ಲ.
ಯಂತ್ರದ ಮಿತಿಗಳನ್ನು ತಿಳಿಯಿರಿ
Understanding model limits has saved me from overpromising and underdelivering. These systems have genuine constraints. Context windows are larger than they used to be, but they still have ceilings, and stuffing them full degrades performance at the edges. Models hallucinate, especially on niche topics where training data is thin. They struggle with precise arithmetic and certain types of multi-step logic. They are sensitive to phrasing.
Cost and speed are limits too. A model that generates perfect prose in ten seconds might be unusable in a real-time chat interface. I now map features to latency budgets early. If a task needs sub-second response, I may precompute answers, cache aggressively, or use a smaller model for the first draft and a larger one only for refinement. Working within constraints is standard engineering. AI is no different.
Building for Real People
I am currently studying LLM applications and software engineering with a simple goal: build tools people use every day. That sounds obvious, but the gap between a cool prototype and a daily-use tool is massive. A demo can tolerate a forty-second pause and a verbose answer. A person trying to finish a task before a meeting cannot.
Daily-use tools need error handling, fallbacks, and clear UI when the model is uncertain. They need to integrate with existing workflows rather than forcing new ones. I think about edge cases now: what happens when the model refuses to answer, when the context overflows, or when the API times out? Shipping AI software means answering those questions with code, not just optimism.
Let's Share What We Learn
I want to connect with other developers who are navigating the same path. The field moves quickly, and the best practices are still being written. No one has all the answers. Whether you are wrestling with prompt design, fighting retrieval pipelines, or figuring out how to evaluate outputs at scale, the problems are better solved together.
Let us share what we learn. Not polished conference talks, but the messy middle. The broken pipelines, the prompt tweaks that finally worked, the evaluation tests that caught a bug before launch. That granular, honest exchange is what turns individual experiments into a shared body of knowledge.
The Real Takeaway
If you are starting out with AI development, spend less time searching for the