ನಮ್ಮ 3 ವರ್ಷ ಹಳೆಯ ಫಿನ್‌ಟೆಕ್ ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿ AI ಭ್ರಮೆಗಳನ್ನು (hallucinating) ಮಾಡುವುದನ್ನು ನಾನು ಹೇಗೆ ತಡೆದೆ

AI ಕೋಡಿಂಗ್ ಪರಿಕರಗಳು ನೈಜ ಪ್ರೊಡಕ್ಷನ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ. ಅವು ಹೊಸ ಕೋಡ್ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಆದರೆ ಇತಿಹಾಸವಿರುವ ಹಳೆಯ ಕೋಡ್‌ಬೇಸ್‌ಗಳ ಮೇಲೆ ವಿಫಲವಾಗುತ್ತವೆ.

ನಮ್ಮ ಫಿನ್‌ಟೆಕ್ ಪ್ರಾಜೆಕ್ಟ್ ಮೂಲಕ ನಾನು ಇದನ್ನು ಕಷ್ಟಪಟ್ಟು ಕಲಿತೆ. ನಮ್ಮಲ್ಲಿ ಎರಡು React ಫ್ರಂಟ್‌ಎಂಡ್‌ಗಳು, ಒಂದು ಅಡ್ಮಿನ್ ಪ್ಯಾನಲ್ ಮತ್ತು ಒಂದು FastAPI ಬ್ಯಾಕೆಂಡ್ ಇದೆ. ನಮ್ಮ ಡೇಟಾಬೇಸ್ ಸಂಕೀರ್ಣವಾಗಿದೆ. ಇದು ಸೂಕ್ಷ್ಮ ಹಣಕಾಸು ಮತ್ತು ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಹೊಂದಿದೆ.

ನಾವು ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡಲು AI ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿದೆವು. ಅದು ತಕ್ಷಣವೇ ವಿಫಲವಾಯಿತು.

ನಾನು AI ಗೆ ಒಂದು contacts ಟೇಬಲ್ ರಚಿಸಲು ಕೇಳಿದೆ. ಅದು ಹೆಸರುಗಳು ಮತ್ತು ಇಮೇಲ್‌ಗಳಿಗಾಗಿ ಹೊಸ ಕಾಲಮ್‌ಗಳನ್ನು ರಚಿಸಿತು. ಈ ಕಾಲಮ್‌ಗಳು ಈಗಾಗಲೇ ನಮ್ಮ users ಟೇಬಲ್‌ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದವು. AI ಫಾರಿನ್ ಕೀ (foreign key) ಬಳಸುವ ಬದಲು ಡೇಟಾವನ್ನು ಡೂಪ್ಲಿಕೇಟ್ ಮಾಡಿತು. ನಮ್ಮ users ಟೇಬಲ್ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂಬ ಅರಿವೇ ಅದಕ್ಕೆ ಇರಲಿಲ್ಲ.

AI ಉತ್ತಮ ಕೋಡ್ ಬರೆಯುವಂತೆ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ಕೇಳುವುದನ್ನು ನಾನು ನಿಲ್ಲಿಸಿದೆ. ಉತ್ತಮ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು AI ಗೆ ಏನು ತಿಳಿಯಬೇಕು ಎಂದು ಕೇಳಲು ಪ್ರಾರಂಭಿಸಿದೆ.

ನೀವು ನೀಡುವ ಸಂದರ್ಭಕ್ಕೆ (context) ಅನುಗುಣವಾಗಿ ಮಾತ್ರ AI ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಾವು ನಮ್ಮ ಸಂದರ್ಭವನ್ನು ಸ್ಪಷ್ಟ ಮತ್ತು ಅಧಿಕೃತವಾಗಿಸಿದೆವು. ನಾವು ನಿರ್ಮಿಸಿದ ವ್ಯವಸ್ಥೆ ಇಲ್ಲಿದೆ:

• ADR Files: ನಾವು docs/adrs/ ಫೋಲ್ಡರ್ ಅನ್ನು ರಚಿಸಿದೆವು. ಈ ಫೈಲ್‌ಗಳು ನಾವು ಏಕೆ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಎಂಬುದನ್ನು ದಾಖಲಿಸುತ್ತವೆ. ಒಂದು ಫೈಲ್ (ADR-001) AI ಗೆ ಹೀಗೆ ಹೇಳುತ್ತದೆ: "ಮೊದಲು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಟೇಬಲ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಫಾರಿನ್ ಕೀಗಳನ್ನು ಬಳಸಿ. ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಎಂದಿಗೂ ಡೂಪ್ಲಿಕೇಟ್ ಮಾಡಬೇಡಿ."

• context.md: ಈ ಫೈಲ್ ನಮ್ಮ ನಿರ್ದಿಷ್ಟ ಪದಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ನಮ್ಮ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ವಿವಿಧ ಪರಿಕಲ್ಪನೆಗಳು ಒಂದಕ್ಕೊಂದು ಹೇಗೆ ಸಂಬಂಧಿಸಿವೆ ಎಂಬುದನ್ನು ಇದು AI ಗೆ ತಿಳಿಸುತ್ತದೆ.

• plot.md: ಇದು ಹೈ-ಲೆವೆಲ್ ಮ್ಯಾಪ್ ಆಗಿದೆ. ನಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನ ವಿವಿಧ ಭಾಗಗಳು ಹೇಗೆ ಸಂಪರ್ಕ ಹೊಂದಿವೆ ಎಂಬುದನ್ನು ಇದು ತೋರಿಸುತ್ತದೆ.

• ಕಟ್ಟುನಿಟ್ಟಿನ ನಿಯಮಗಳು (Strict Rules): docs ಡೈರೆಕ್ಟರಿಯೇ ಅಂತಿಮ ಅಧಿಕಾರ ಎಂದು ನಾವು AI ಗೆ ತಿಳಿಸಿದೆವು. ಅದು ಈ ನಿಯಮಗಳನ್ನು ಕ್ರಮಬದ್ಧವಾಗಿ ಅನುಸರಿಸಬೇಕು.

• ಕಡ್ಡಾಯ ಪರೀಕ್ಷೆಗಳು (Mandatory Tests): ಪ್ರತಿಯೊಂದು ಹೊಸ API ರೂಟ್ ಕೂಡ ಟೆಸ್ಟ್ ಕೇಸ್‌ಗಳನ್ನು ಹೊಂದಿರಲೇಬೇಕು.

ಈ ವ್ಯವಸ್ಥೆಯು AI ಅನ್ನು ಊಹಿಸಬಹುದಾದಂತೆ (predictable) ಮಾಡುತ್ತದೆ.

ಒಮ್ಮೆ, AI ಒಂದು shared function ಅನ್ನು ಬದಲಾಯಿಸಿತು, ಇದರಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ನ ಎಂಟು ಇತರ ಭಾಗಗಳು ಕೆಟ್ಟುಹೋದವು. ನಮ್ಮ ಬಳಿ ಟೆಸ್ಟ್‌ಗಳು ಇದ್ದ ಕಾರಣ, AI ವಿಫಲತೆಗಳನ್ನು ಗುರುತಿಸಿತು. ಹಳೆಯ ಮತ್ತು ಹೊಸ ಅವಶ್ಯಕತೆಗಳೆರಡನ್ನೂ ನಿಭಾಯಿಸುವ ಫಂಕ್ಷನ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ರಚಿಸುವ ಮೂಲಕ ಅದು ತನ್ನ ತಪ್ಪನ್ನು ತಾನೇ ಸರಿಪಡಿಸಿಕೊಂಡಿತು. ಟೆಸ್ಟ್‌ಗಳಿಲ್ಲದಿದ್ದರೆ, ಆ ಬಗ್ ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ತಲುಪುತ್ತಿತ್ತು.

ನಿಮ್ಮ ಕೋಡ್‌ಬೇಸ್ ತಿಳಿಯದಿದ್ದಕ್ಕಾಗಿ AI ಅನ್ನು ದೂಷಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಅದನ್ನು ಹೊಸದಾಗಿ ಕೆಲಸಕ್ಕೆ ಸೇರಿದ ಉದ್ಯೋಗಿಯಂತೆ ಪರಿಗಣಿಸಿ. ನಿಮ್ಮ ನಿಯಮಗಳು ತಿಳಿಯದಿದ್ದಕ್ಕಾಗಿ ನೀವು ಹೊಸ ಉದ್ಯೋಗಿಯನ್ನು ದೂಷಿಸುವುದಿಲ್ಲ. ಬದಲಾಗಿ ನೀವು ಅವರಿಗೆ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಮತ್ತು ಆನ್‌ಬೋರ್ಡಿಂಗ್ ನೀಡುತ್ತೀರಿ.

ನಮ್ಮ ರಚನೆ ಹೀಗಿದೆ:

docs/

  • context.md (ಪದಗಳು ಮತ್ತು ಸಂಪರ್ಕಗಳು)
  • plot.md (ಹೈ-ಲೆವೆಲ್ ಮ್ಯಾಪ್)
  • adr/ (ಟೇಬಲ್ ರಚನೆ ಅಥವಾ API ರಚನೆಯಂತಹ ನಿರ್ದಿಷ್ಟ ನಿಯಮಗಳು)

ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋಗಾಗಿ ಮೂರು ಸಲಹೆಗಳು:

  • ನಿಮ್ಮ ADRಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟವಾಗಿರಿ. ಅಸ್ಪಷ್ಟ ಸಲಹೆಗಳ ಬದಲಿಗೆ ಸ್ಪಷ್ಟ ಸೂಚನೆಗಳನ್ನು ಬಳಸಿ.
  • ಡಾಕ್ಸ್ ಅನ್ನು ಅಧಿಕೃತವಾಗಿಸಿ. ಈ ನಿಯಮಗಳೇ ಮೊದಲ ಆದ್ಯತೆ ಎಂದು AI ಗೆ ತಿಳಿಸಿ.
  • ತಪ್ಪುಗಳನ್ನು ನಿಯಮಗಳನ್ನಾಗಿ ಪರಿವರ್ತಿಸಿ. ಪ್ರತಿ ಬಾರಿ AI ವಿಫಲವಾದಾಗಲೂ, ಅದನ್ನು ತಡೆಯಲು ಹೊಸ ADR ಅನ್ನು ರಚಿಸಿ.

ಇದು AI ಅನ್ನು ಪರಿಪೂರ್ಣವಾಗಿಸುವುದಿಲ್ಲ. ಆದರೆ ಅದನ್ನು ಸ್ಥಿರವಾಗಿಸುತ್ತದೆ (consistent).

Source: https://dev.to/jaskiratanand/how-i-made-ai-stop-hallucinating-on-our-3-year-old-fintech-codebase-3g0h

Optional learning community: https://t.me/GyaanSetuAi