ನಮ್ಮ ಕೋಡ್ಬೇಸ್ನಲ್ಲಿ AI ತಪ್ಪು ಮಾಹಿತಿ ನೀಡುವುದನ್ನು (Hallucinating) ನಾನು ಹೇಗೆ ತಡೆದೆ
AI ಕೋಡಿಂಗ್ ಪರಿಕರಗಳು ನೈಜ ಪ್ರೊಡಕ್ಷನ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ. ಅವು ಹೊಸ ಕೋಡ್ ಮೇಲೆ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಆದರೆ ಇತಿಹಾಸವಿರುವ ಹಳೆಯ ಕೋಡ್ ಮೇಲೆ ಅವು ವಿಫಲವಾಗುತ್ತವೆ.
ನಮ್ಮ ಫಿನ್ಟೆಕ್ (fintech) ಪ್ರಾಜೆಕ್ಟ್ಗೆ ಮೂರು ವರ್ಷಗಳ ಇತಿಹಾಸವಿದೆ. ಇದು ಎರಡು React ಫ್ರಂಟ್ಎಂಡ್ಗಳು, ಒಂದು ಅಡ್ಮಿನ್ ಪ್ಯಾನಲ್ ಮತ್ತು ಒಂದು FastAPI ಬ್ಯಾಕ್ಎಂಡ್ ಅನ್ನು ಹೊಂದಿದೆ. ಡೇಟಾಬೇಸ್ ಅನೇಕ ಟೇಬಲ್ಗಳು ಮತ್ತು ಹೆವಿ ಜೋಯನ್ಗಳೊಂದಿಗೆ (heavy joins) ಸಂಕೀರ್ಣವಾಗಿದೆ.
ನಾವು ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡಲು AI ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿದೆವು. ಅದು ವಿಫಲವಾಯಿತು.
ನಾನು AI ಗೆ ಒಂದು 'contacts' ಟೇಬಲ್ ರಚಿಸಲು ಕೇಳಿದೆ. ಅದು ಹೆಸರುಗಳು ಮತ್ತು ಇಮೇಲ್ಗಳಿಗಾಗಿ ಹೊಸ ಕಾಲಮ್ಗಳನ್ನು ರಚಿಸಿತು. ನಮ್ಮ 'users' ಟೇಬಲ್ನಲ್ಲಿ ಈಗಾಗಲೇ ಇವು ಇವೆ ಎಂಬುದು ಅದಕ್ಕೆ ತಿಳಿಯಲಿಲ್ಲ. ಫಾರಿನ್ ಕೀ (foreign key) ಬಳಸುವ ಬದಲು ಅದು ಡೇಟಾವನ್ನು ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಮಾಡಿತು.
AI ಮೂರ್ಖವಾಗಿರಲಿಲ್ಲ. ಅದಕ್ಕೆ ಸಂದರ್ಭದ ಮಾಹಿತಿ (context) ಇರಲಿಲ್ಲ. ಅದು ಅಪೂರ್ಣ ಮಾಹಿತಿಯೊಂದಿಗೆ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಂಡಿತು.
ಉತ್ತಮ ಕೋಡ್ ಪಡೆಯುವುದು ಹೇಗೆ ಎಂದು ಕೇಳುವುದನ್ನು ನಾನು ನಿಲ್ಲಿಸಿದೆ. ಬದಲಾಗಿ, ಉತ್ತಮ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು AI ಗೆ ಯಾವ ಸಂದರ್ಭದ ಮಾಹಿತಿ (context) ಬೇಕು ಎಂದು ಕೇಳಲು ಪ್ರಾರಂಭಿಸಿದೆ.
ನಾವು ಒಂದು ರಚನಾತ್ಮಕ ಕಾರ್ಯವಿಧಾನವನ್ನು (structured workflow) ನಿರ್ಮಿಸಿದೆವು. ನೀವು ನೀಡುವ ಸಂದರ್ಭದ ಮಾಹಿತಿಯ (context)ಷ್ಟೇ AI ಉತ್ತಮವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನಾವು ಆ ಮಾಹಿತಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನೀಡಿದೆವು.
ನಮ್ಮ ಸೆಟಪ್ ಇಲ್ಲಿದೆ:
- ADR ಡೈರೆಕ್ಟರಿ (Directory): ನಾವು Architecture Decision Records ಗಾಗಿ ಒಂದು ಫೋಲ್ಡರ್ ರಚಿಸಿದೆವು. ಈ ಫೈಲ್ಗಳು ನಾವು ನಿರ್ದಿಷ್ಟ ಆಯ್ಕೆಗಳನ್ನು ಏಕೆ ಮಾಡುತ್ತೇವೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತವೆ. ಒಂದು ಫೈಲ್ ಹೊಸ ಟೇಬಲ್ಗಳನ್ನು ರಚಿಸುವ ಮೊದಲು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಟೇಬಲ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಲು AI ಗೆ ಸೂಚಿಸುತ್ತದೆ. ಇದು ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಮಾಡುವುದನ್ನು ನಿಷೇಧಿಸುತ್ತದೆ.
- context.md: ಈ ಫೈಲ್ ನಮ್ಮ ನಿರ್ದಿಷ್ಟ ಪದಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ನಮ್ಮ ವಿಶಿಷ್ಟ ಪದಗಳು ಒಂದಕ್ಕೊಂದು ಹೇಗೆ ಸಂಬಂಧಿಸಿವೆ ಎಂಬುದನ್ನು ಇದು AI ಗೆ ತಿಳಿಸುತ್ತದೆ.
- plot.md: ಇದು ಪ್ರಾಜೆಕ್ಟ್ನ ಹೈ-ಲೆವೆಲ್ ಮ್ಯಾಪ್ ಮತ್ತು ವಿವಿಧ ಭಾಗಗಳು ಹೇಗೆ ಪರಸ್ಪರ ಸಂಬಂಧಿಸಿವೆ ಎಂಬುದನ್ನು ಒದಗಿಸುತ್ತದೆ.
- ಕಡ್ಡಾಯ ಪರೀಕ್ಷೆಗಳು (Mandatory Tests): ಪ್ರತಿಯೊಂದು ಹೊಸ API ರೂಟ್ (route) ಗೆ ಟೆಸ್ಟ್ ಕೇಸ್ಗಳು ಅಗತ್ಯವಿರುತ್ತದೆ.
ಇದು ಎಲ್ಲವನ್ನೂ ಬದಲಾಯಿಸಿತು. ಒಮ್ಮೆ, AI ಒಂದು ಶೇರ್ಡ್ ಯುಟಿಲಿಟಿ ಫಂಕ್ಷನ್ ಅನ್ನು ಬದಲಾಯಿಸಿತು. ಆ ಬದಲಾವಣೆಯು ಸಿಸ್ಟಮ್ನ ಎಂಟು ಇತರ ಭಾಗಗಳನ್ನು ಹಾಳುಮಾಡಿತು. ಟೆಸ್ಟ್ ಸೂಟ್ ಅದನ್ನು ತಕ್ಷಣವೇ ಪತ್ತೆಹಚ್ಚಿತು. AI ಆ ವೈಫಲ್ಯವನ್ನು ಗಮನಿಸಿ, ಹಳೆಯ ಮತ್ತು ಹೊಸ ಅವಶ್ಯಕತೆಗಳೆರಡನ್ನೂ ನಿಭಾಯಿಸುವ ಆವೃತ್ತಿಯನ್ನು ರಚಿಸುವ ಮೂಲಕ ತನ್ನ ತಪ್ಪನ್ನು ತಾನೇ ಸರಿಪಡಿಸಿಕೊಂಡಿತು.
ಪರೀಕ್ಷೆಗಳಿಲ್ಲದಿದ್ದರೆ, ಆ ಬಗ್ ಪ್ರೊಡಕ್ಷನ್ಗೆ ತಲುಪುತ್ತಿತ್ತು.
AI ಅನ್ನು ಒಬ್ಬ ಹೊಸ ಡೆವಲಪರ್ನಂತೆ ಪರಿಗಣಿಸಿ. ನಿಮ್ಮ ಕೋಡ್ಬೇಸ್ ತಿಳಿಯದಿದ್ದಕ್ಕಾಗಿ ನೀವು ಹೊಸ ಉದ್ಯೋಗಿಯನ್ನು ದೂಷಿಸುವುದಿಲ್ಲ. ನೀವು ಅವರಿಗೆ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಮತ್ತು ಆನ್ಬೋರ್ಡಿಂಗ್ (onboarding) ನೀಡುತ್ತೀರಿ. ನಾವು AI ಗೂ ಅದನ್ನೇ ಮಾಡಿದೆವು.
ನಮ್ಮ ರಚನೆ:
- docs/context.md: ಪ್ರಾಜೆಕ್ಟ್ ಪದಗಳು ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಸಂಬಂಧಗಳು.
- docs/plot.md: ಹೈ-ಲೆವೆಲ್ ಕೋಡ್ಬೇಸ್ ಮ್ಯಾಪ್.
- docs/adr/: ಟೇಬಲ್ ರಚನೆ ಮತ್ತು API ರಚನೆಯಂತಹ ನಿರ್ದಿಷ್ಟ ನಿಯಮಗಳು.
ನಿಮ್ಮ ತಂಡಕ್ಕಾಗಿ ಮೂರು ನಿಯಮಗಳು:
- ADRಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟವಾಗಿರಿ. ಅಸ್ಪಷ್ಟ ಸಲಹೆಗಳ ಬದಲಿಗೆ ಸ್ಪಷ್ಟ ಸೂಚನೆಗಳನ್ನು ಬಳಸಿ.
- ಡಾಕ್ಯುಮೆಂಟ್ಗಳನ್ನು ಅಧಿಕೃತವಾಗಿರಿಸಿ. ಈ ನಿಯಮಗಳೇ ಮೊದಲ ಆದ್ಯತೆ ಎಂದು AI ಗೆ ತಿಳಿಸಿ.
- ತಪ್ಪುಗಳನ್ನು ನಿಯಮಗಳನ್ನಾಗಿ ಪರಿವರ್ತಿಸಿ. ಪ್ರತಿ ಬಾರಿ AI ವಿಫಲವಾದಾಗ, ಒಂದು ಹೊಸ ADR ಬರೆಯಿರಿ.
ಈ ವ್ಯವಸ್ಥೆಯು AI ಅನ್ನು ಪರಿಪೂರ್ಣವಾಗಿಸುವುದಿಲ್ಲ. ಇದು AI ಅನ್ನು ಊಹಿಸಬಹುದಾದಂತೆ (predictable) ಮಾಡುತ್ತದೆ. AI ಸ್ಥಿರವಾಗಿರುವ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ನಾವು ಬಯಸುತ್ತೇವೆ, ಇದರಿಂದ ತಂಡವು ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡಬಹುದು.