ನಾನು ನನ್ನ ವೆಬ್ಸೈಟ್ನಲ್ಲಿ ಡಿಜಿಟಲ್ ಟ್ವಿನ್ (digital twin) ಅನ್ನು ನಡೆಸುತ್ತಿದ್ದೇನೆ. ಇದು ನನ್ನ ಜೀವನ ಮತ್ತು ಕೌಶಲಗಳ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ನಾನು ಅದಕ್ಕೆ ಒಂದು ಕಟ್ಟುನಿಟ್ಟಿನ ನಿಯಮವನ್ನು ನೀಡಿದ್ದೇನೆ: ಎಂದಿಗೂ ಸುಳ್ಳು ಅಥವಾ ಕಲ್ಪಿತ ವಿಷಯಗಳನ್ನು ಹೇಳಬಾರದು. ನನಗೆ ಇಲ್ಲದ ಯಾವುದಾದರೂ ಕೌಶಲದ ಬಗ್ಗೆ ಯಾರಾದರೂ ಕೇಳಿದರೆ, ಅದು ತನಗೆ ತಿಳಿಯದು ಎಂದು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕು. ತಿಂಗಳುಗಟ್ಟಲೆ, ಈ ವ್ಯವಸ್ಥೆಯು ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ನಾನು ನಂಬಿದ್ದೆ. ನಾನು ಆಗಾಗ ಕೈಯಿಂದ ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದೆ ಮತ್ತು ಉತ್ತರಗಳು ಸರಿಯಾಗಿಯೇ ಕಾಣುತ್ತಿದ್ದವು. ನಂತರ ನಾನು ಒಂದು ಸರಿಯಾದ ಮೌಲ್ಯಮಾಪನ ವ್ಯವಸ್ಥೆಯನ್ನು (evaluation harness) ನಿರ್ಮಿಸಿದೆ. ಅಂಕಿಅಂಶಗಳು ಕಠಿಣ ಸತ್ಯವನ್ನು ಎದುರಿಸಿದವು. 35 ಪ್ರಶ್ನೆಗಳಲ್ಲಿ, ಒಂಬತ್ತು ಪ್ರಶ್ನೆಗಳಿಗೆ ಸಂಪೂರ್ಣ ಸುಳ್ಳು ಉತ್ತರಗಳಿದ್ದವು. ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಎಂಟು ಪ್ರಶ್ನೆಗಳಲ್ಲಿ, ಮಾಡೆಲ್ ಕೇವಲ ನಾಲ್ಕಕ್ಕೆ ಮಾತ್ರ ನಿರಾಕರಿಸಿತು. ನನ್ನ 'ಆಂಟಿ-ಹ್ಯಾಲ್ಯುಸಿನೇಶನ್' (anti-hallucination) ಪ್ರಾಂಪ್ಟ್ ಸುಮಾರು ಕಾಲು ಭಾಗದಷ್ಟು ಸಮಯ ವಿಫಲವಾಯಿತು. ನಾನು ತನ್ನ ಬಳಕೆದಾರರಿಗೆ ಸುಳ್ಳು ಹೇಳುವ ಉತ್ಪನ್ನವನ್ನೇ ಬಿಡುಗಡೆ ಮಾಡುತ್ತಿದ್ದೆ.
ಅತ್ಯಂತ ಸರಳವಾದ ರಿಟ್ರಿವಲ್ ಸೆಟಪ್ (Retrieval Setup)
ನಾನು Pinecone ಅಥವಾ ಯಾವುದೇ ಭಾರೀ ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸಲಿಲ್ಲ. ಇಡೀ ಸೆಟಪ್ ಒಂದು ಸಾಮಾನ್ಯ JSON ಫೈಲ್ ಮೇಲೆ ಆಧಾರಿತವಾಗಿದೆ. ನನ್ನ ಕೋಡ್ ನನ್ನ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ವಿಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತದೆ. ಪ್ರಶ್ನೆ ಬಂದಾಗ, ಸಿಸ್ಟಮ್ ಪ್ರಶ್ನೆ ಮತ್ತು ಪಠ್ಯದ ಪ್ರತಿಯೊಂದು ಭಾಗದ ನಡುವಿನ 'ಕೋಸೈನ್ ಸಿಮಿಲಾರಿಟಿ'ಯನ್ನು (cosine similarity) ಲೆಕ್ಕಹಾಕುತ್ತದೆ, ಅತ್ಯಂತ ಹತ್ತಿರದ ಹೊಂದಾಣಿಕೆಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರಾಂಪ್ಟ್ಗೆ ಸಂದರ್ಭದ (context) ರೂಪದಲ್ಲಿ ಸೇರಿಸುತ್ತದೆ. ನಂತರ ಮಾಡೆಲ್ ಆ ವಿಂಡೋದಲ್ಲಿ ಕಂಡದ್ದರ ಮೇಲೆ ಮಾತ್ರ ಆಧಾರಿತವಾಗಿ ಉತ್ತರವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಸೀಮಿತ ಮಾಹಿತಿಯನ್ನು ನೀಡುವ ಸಣ್ಣ ವೈಯಕ್ತಿಕ ಸೈಟ್ಗೆ, ಈ ವಿಧಾನವು ವೇಗವಾಗಿದೆ ಮತ್ತು ವೆಚ್ಚವೂ ಬಹಳ ಕಡಿಮೆ. ಇಲ್ಲಿ ರಿಮೋಟ್ ವೆಕ್ಟರ್ ಸ್ಟೋರ್ಗೆ ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕದ ಅಗತ್ಯವಿಲ್ಲ, ಇಂಡೆಕ್ಸಿಂಗ್ ಹೊರೆ ಇಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆಗಳ ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ಫೈಲ್ ಅನ್ನು ಓದುತ್ತೀರಿ, ಭಾಗಗಳಿಗೆ ಸ್ಕೋರ್ ನೀಡುತ್ತೀರಿ, ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತೀರಿ ಮತ್ತು ಕೆಲಸ ಮುಗಿಯುತ್ತದೆ. ಆದರೆ ಬ್ಯಾಕೆಂಡ್ನಲ್ಲಿನ ಸರಳತೆಯು ಔಟ್ಪುಟ್ನಲ್ಲಿನ ಪ್ರಾಮಾಣಿಕತೆಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಮಾಡೆಲ್ ಸ್ವತಃ ಕಲ್ಪಿಸಿಕೊಳ್ಳಲು (improvise) ನಿರ್ಧರಿಸಿದಾಗ, ಒಂದು ಲೈಟ್ವೇಟ್ ಪೈಪ್ಲೈನ್ ಕೂಡ ಗಂಭೀರ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು. "ಇಲ್ಲಿ ಸಂದರ್ಭವಿದೆ" ಮತ್ತು "ಇದರ ಬಗ್ಗೆ ನಾನು ಏನು ಹೇಳುತ್ತೇನೆ" ಎಂಬ ಎರಡರ ನಡುವಿನ ಅಂತರವೇ ಹ್ಯಾಲ್ಯುಸಿನೇಶನ್ಗಳು (hallucinations) ಹುಟ್ಟುವ ಜಾಗ. ನೀವು ಮಾಡೆಲ್ಗೆ ನಿಮ್ಮ ಕೆಲಸದ ಇತಿಹಾಸದ ಬಗ್ಗೆ ಒಂದು ಪ್ಯಾರಾಗ್ರಾಫ್ ನೀಡಿದರೂ ಸಹ, ನೀವು ಎಂದಿಗೂ ಬಳಸದ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯ ಬಗ್ಗೆ ಅದು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಸುಳ್ಳು ಹೇಳಬಹುದು.
ನನ್ನ ವಿಶ್ವಾಸವನ್ನು ಕುಸಿಯುವಂತೆ ಮಾಡಿದ ಅಂಕಿಅಂಶಗಳು
ತಿಂಗಳುಗಟ್ಟಲೆ, ನಾನು ಕೈಯಿಂದ ಆಗಾಗ ಪರೀಕ್ಷಿಸುವುದನ್ನೇ ಸಾಕಿದೆ ಎಂದು ಭಾವಿಸಿದ್ದೆ. ನಾನು ಚಾಟ್ ತೆರೆಯುತ್ತಿದ್ದೆ, ನನಗೆ ಈಗಾಗಲೇ ಉತ್ತರ ತಿಳಿದಿರುವ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುತ್ತಿದ್ದೆ ಮತ್ತು ಉತ್ತರ ಸರಿಯಾಗಿದ್ದಾಗ ತೃಪ್ತಿಯಾಗುತ್ತಿದ್ದೆ. ಅದೇ ನನ್ನ ಪರೀಕ್ಷಾ ತಂತ್ರವಾಗಿತ್ತು. ನಾನು ಸ್ವತಃ ಅದನ್ನು ಬಳಸುತ್ತಿದ್ದರಿಂದ ಅದು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಪರೀಕ್ಷೆಯಂತೆ ಅನಿಸುತ್ತಿತ್ತು. ಆದರೆ ಅದು ಅಷ್ಟಾಗಿ ಪೂರ್ಣವಾಗಿರಲಿಲ್ಲ.
ನಾನು ವ್ಯವಸ್ಥಿತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೌಲ್ಯಮಾಪನ ವ್ಯವಸ್ಥೆಯನ್ನು (evaluation harness) ಬರೆದಾಗ, ಪರಿಸ್ಥಿತಿ ಬದಲಾಯಿತು. ಟೆಸ್ಟ್ ಸೂಟ್ ಡಿಜಿಟಲ್ ಟ್ವಿನ್ಗೆ 35 ಪ್ರಶ್ನೆಗಳನ್ನು 던ಿಸಿತು. ಒಂಬತ್ತು ಉತ್ತರಗಳಲ್ಲಿ ಸುಳ್ಳುಗಳಿದ್ದವು. ನನ್ನ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಎಲ್ಲಿಯೂ ಉತ್ತರ ಇಲ್ಲದ ಎಂಟು ಪ್ರಶ್ನೆಗಳನ್ನು ನಾನು ಸೇರಿಸಿದ್ದೆ. ಮಾಡೆಲ್ ಅವೆಲ್ಲವನ್ನೂ ನಿರಾಕರಿಸಬೇಕಿತ್ತು. ಆದರೆ ಅದು ಕೇವಲ ನಾಲ್ಕನ್ನು ಮಾತ್ರ ನಿರಾಕರಿಸಿತು. ಎಂದಿಗೂ ಸುಳ್ಳು ಹೇಳಬಾರದು ಎಂಬ ಕಟ್ಟುನಿಟ್ಟಿನ ಸೂಚನೆಗಳನ್ನು ಒಳಗೊಂಡಿದ್ದ ನನ್ನ 'ಆಂಟಿ-ಹ್ಯಾಲ್ಯುಸಿನೇಶನ್' ಪ್ರಾಂಪ್ಟ್ ಸುಮಾರು ಶೇಕಡಾ 25 ರಷ್ಟು ಬಾರಿ ವಿಫಲವಾಯಿತು. ನಾಲ್ಕರಲ್ಲಿ ಒಂದು ಬಾರಿ. ಇದು ಕೇವಲ ಸಣ್ಣ ತಪ್ಪು ಅಲ್ಲ. ಇದು ಒಂದು ಕೆಟ್ಟುಹೋದ ಉತ್ಪನ್ನ.
ಸುಲಭವಾದ ಪ್ರಶ್ನೆಗಳ ಮೂಲಕ ಪರೀಕ್ಷಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ
ನಿಮ್ಮ ಸ್ವಂತ ಉತ್ಪನ್ನವನ್ನು ಕೇವಲ ಬಳಸುವ ಮೂಲಕ ನೀವು ದೋಷಗಳನ್ನು (bugs) ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅದನ್ನು ಕೆಡಿಸಲು ಪ್ರಯತ್ನಿಸುವುದರಿಂದ ಮಾತ್ರ ನೀವು ದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು. ನನ್ನ ಕೈಯಿಂದ ಮಾಡಿದ ಪರೀಕ್ಷೆಗಳು ತುಂಬಾ ಸರಳವಾಗಿದ್ದವು. ನನಗೆ ನಿಖರವಾದ ಉತ್ತರ ತಿಳಿದಿರುವ ಪ್ರಶ್ನೆಗಳನ್ನು ಮಾತ್ರ ನಾನು ಕೇಳುತ್ತಿದ್ದೆ, ಅಂದರೆ ನಾನು ಅರಿವಿಲ್ಲದೆಯೇ ಮಾಡೆಲ್ ಅನ್ನು ಸುರಕ್ಷಿತ ಹಾದಿಯಲ್ಲೇ ನಡೆಸುತ್ತಿದ್ದೆ. ನಾನು ಗಡಿಗಳನ್ನು ಪರೀಕ್ಷಿಸಲಿಲ್ಲ. ನನಗೆ ಬೇಕಾದ ಕೌಶಲಗಳ ಬಗ್ಗೆ ಅಥವಾ ಎಂದಿಗೂ ನಡೆಯದ ಅನುಭವಗಳ ಬಗ್ಗೆ ನಾನು ಎಂದಿಗೂ ಕೇಳಲಿಲ್ಲ.
ನೈಜ ಪರೀಕ್ಷೆಗೆ ವಿರೋಧಾತ್ಮಕ ಉದ್ದೇಶ (adversarial intent) ಬೇಕು. AI ವಿಫಲವಾಗುವಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಪ್ರಶ್ನೆಗಳನ್ನು ನೀವು ಸೃಷ್ಟಿಸಬೇಕು. ಭೇಟಿ ನೀಡುವವರ ಮುಂದೆ ತಪ್ಪು ಮಾಡದಂತೆ, ಪ್ರಯೋಗಾಲಯದಲ್ಲೇ ಅದು ತಪ್ಪು ಮಾಡುವಂತೆ ನೀವು ನೋಡಿಕೊಳ್ಳಬೇಕು. ನೀವು ಈಗಾಗಲೇ ನಂಬಿರುವ ವಿಷಯಗಳನ್ನು ದೃಢೀಕರಿಸುವ ಟೆಸ್ಟ್ ಸೂಟ್ ಕೇವಲ ಒಂದು ಪ್ರದರ್ಶನವಷ್ಟೇ. ನೀವು ಸಕ್ರಿಯವಾಗಿ ಎಡ್ಜ್ ಕೇಸ್ಗಳನ್ನು (edge cases) ಮತ್ತು ಟ್ರ್ಯಾಪ್ ಪ್ರಶ್ನೆಗಳನ್ನು (trap questions) ಸೃಷ್ಟಿಸುತ್ತಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಪರೀಕ್ಷಿಸುತ್ತಿಲ್ಲ ಎಂದರ್ಥ. ನೀವು ಕೇವಲ ಭರವಸೆ ಇಡುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ.
ಪ್ರಮುಖವಾದ ಎರಡು ತಪ್ಪುಗಳು
ಪ್ರಾಂಪ್ಟಿಂಗ್ (Prompting) ಎಂಬುದು ಗ್ಯಾರಂಟಿಯಲ್ಲ. AI ಹ್ಯಾಲ್ಯುಸಿನೇಟ್ ಮಾಡಬಾರದು ಎಂದು ಹೇಳುವ ಸುದೀರ್ಘವಾದ, ವಿವರವಾದ ಸೂಚನೆಯು ಕೇವಲ ಆದೇಶದ ರೂಪದಲ್ಲಿರುವ ಒಂದು ಸಲಹೆಯಷ್ಟೇ. ಮಾಡೆಲ್ ಹೆಚ್ಚಿನ ಸಮಯ ಅದನ್ನು ಪಾಲಿಸಬಹುದು, ಆದರೆ ಅಂಕಿಅಂಶಗಳ ಒತ್ತಡವು ಅದನ್ನು ಬೇರೆಡೆಗೆ ತಳ್ಳಿದ ತಕ್ಷಣ ಅದು ಆ ಸೂಚನೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ಟೆಂಪರೇಚರ್ (Temperature), ಟೋಕನ್ ಪ್ರೊಬಬಿಲಿಟಿ (token probability) ಮತ್ತು ತರಬೇತಿ ಡೇಟಾದ ಸ್ವರೂಪವು ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ನಲ್ಲಿರುವ ಒಂದು ವಾಕ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಪ್ರಭಾವ ಬೀರುತ್ತವೆ. ನೀವು ವಿಧೇಯತೆಯನ್ನು ಡೇಟಾ ಮೂಲಕ ಅಳೆಯಬೇಕು, ಭರವಸೆಯ ಮೂಲಕವಲ್ಲ. ಬಲವಾದ ಸೂಚನೆಯು ದೃಢೀಕರಿಸಲ್ಪಟ್ಟ ಸತ್ಯವಲ್ಲ. ಅದು ಕೇವಲ ಒಂದು ವಿನಂತಿ, ಮತ್ತು ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು. ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಸುರಕ್ಷತಾ ತಂತ್ರವು ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಬಲವಾಗಿ ಬರೆಯುವುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದರೆ, ನೀವು ಟಿಶ್ಯೂ ಪೇಪರ್ನಿಂದ ರಕ್ಷಣಾ ಕವಚವನ್ನು ನಿರ್ಮಿಸಿದಂತೆ. ಮಾಡೆಲ್ ಎಷ್ಟು ಬಾರಿ ವಿಧೇಯತೆಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಯಾವ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಮತ್ತು ಅದು ವಿಫಲವಾದಾಗ ಏಕೆ ವಿಫಲವಾಯಿತು ಎಂಬುದನ್ನು ಲೆಕ್ಕಹಾಕುವ ಮೌಲ್ಯಮಾಪನ ವ್ಯವಸ್ಥೆ (eval harness) ನಿಮಗೆ ಬೇಕು. ಅಂಕಿಅಂಶಗಳಿಗೆ ನಿಮ್ಮ ಮಾತಿನ ಶೈಲಿಯ ಬಗ್ಗೆ ಕಾಳಜಿಯಿಲ್ಲ.
ಮೌಲ್ಯಮಾಪನ ಲೂಪ್ ದೋಷಪೂರಿತವಾಗಿತ್ತು. ಇದು ನನ್ನನ್ನು ಬಹುತೇಕ ಸಿಲುಕಿಸಬಲ್ಲಿದ್ದ ಒಂದು ಸೂಕ್ಷ್ಮ ಬಲೆ. ನನ್ನ ಮೂಲ ಪರೀಕ್ಷಾ ಸಾಧನವು ರಿಟ್ರಿವಲ್ (retrieval) ಪ್ರಕ್ರಿಯೆಯನ್ನು ಎರಡು ಬಾರಿ ನಡೆಸಿತು. ಮೊದಲನೆಯ ಬಾರಿ, ಗ್ರೌಂಡ್ ಟ್ರೂತ್ (ground truth) ಜೊತೆಗೆ ಹೋಲಿಕೆ ಮಾಡಲು ಸಂದರ್ಭವನ್ನು (context) ಪಡೆಯಿತು. ಎರಡನೆಯ ಬಾರಿ, ವಾಸ್ತವಿಕ ಉತ್ತರ ತಯಾರಿಕೆಗಾಗಿ ಸಂದರ್ಭವನ್ನು ಪಡೆಯಿತು. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಇದರರ್ಥ ತೀರ್ಪುಗಾರನು ನೋಡಿದ ಚಂಕ್ಗಳು (chunks) ಮಾದರಿಯು (model) ನೋಡಿದ ಚಂಕ್ಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿರಬಹುದು ಎಂದರ್ಥ. AI ಗೆ ಎಂದಿಗೂ ಸಿಗದ ಡೇಟಾವನ್ನು ಆಧರಿಸಿ ತೀರ್ಪುಗಾರನು ಉತ್ತರವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತಿದ್ದನು. ತಪ್ಪು ಇನ್ಪುಟ್ಗೆ ಅಂಕ ನೀಡುವ ಮೌಲ್ಯಮಾಪನವು, ಮೌಲ್ಯಮಾಪನ ಮಾಡದಿರುವುದಕ್ಕಿಂತಲೂ ಕೆಟ್ಟದ್ದಾಗಿದೆ. ಇದು ನಿಮಗೆ ಸುಳ್ಳು ಭರವಸೆಯನ್ನು ನೀಡುತ್ತದೆ. ನೀವು ಸ್ಕೋರ್ ಅನ್ನು ನೋಡುತ್ತೀರಿ, ಹೆಚ್ಚಿನ ಪಾಸ್ ರೇಟ್ ಅನ್ನು ಕಾಣುತ್ತೀರಿ ಮತ್ತು ನಿರಾಳರಾಗುತ್ತೀರಿ. ಈ ಮಧ್ಯೆ ನಿಮ್ಮ ಬಳಕೆದಾರರು