𝗧𝗵𝗲 𝗥𝘂𝗹𝗲 𝗛𝗶𝗲𝗿𝗮𝗿𝗰𝗵𝘆 𝗧𝗿𝗮𝗽

ನಿಮ್ಮ ಟರ್ಮಿನಲ್ ಕೆಂಪು ದೋಷಗಳಿಂದ (errors) ತುಂಬಿದೆ. ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಮೂರು AI ಏಜೆಂಟ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ. ಬಳಕೆದಾರರ ದೃಢೀಕರಣದ (user authentication) ಅರ್ಥದ ಬಗ್ಗೆ ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಒಮ್ಮತ ಹೊಂದಿಲ್ಲ. 20 ನಿಮಿಷದ ಬಗ್ (bug) ನಿಯಮಗಳ ಸರಪಳಿಯಲ್ಲಿ 3 ದಿನಗಳ ಹುಡುಕಾಟವಾಗಿ ಬದಲಾಗುತ್ತದೆ.

2026ರಲ್ಲಿ AI ಏಜೆಂಟ್ ನಿರ್ವಹಣೆಯ ವಾಸ್ತವ ಇದೇ ಆಗಿದೆ.

ನೀವು AI ವ್ಯವಸ್ಥೆಗಳನ್ನು ವಿಸ್ತರಿಸುತ್ತಿದ್ದಂತೆ, ನಿಯಮಗಳ ಗುಂಪುಗಳು ಹೂಳಿನಂತೆ ಪದರ ಪದರವಾಗಿ ಸಂಗ್ರಹವಾಗುತ್ತವೆ. ನೀವು ಸ್ಪಷ್ಟವಾದ ನಿಯಮಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ. ನಂತರ ಅಗತ್ಯತೆಗಳು ಬದಲಾಗುತ್ತವೆ. ನಂತರ ಎಡ್ಜ್ ಕೇಸ್‌ಗಳು (edge cases) ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಶೀಘ್ರದಲ್ಲೇ, ನೀವು ಮಧ್ಯಕಾಲೀನ ಕಾನೂನುಗಳಂತೆ ಕಾಣುವ ನಿಯಮಗಳ ಸರಪಳಿಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ. ಒಂದು ಏಜೆಂಟ್ ಏಕೆ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಎಂಬುದನ್ನು ನೀವು ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಇದು 'ಕ್ಯಾಸ್ಕೇಡಿಂಗ್ ರೂಲ್ ಒಪಾಸಿಟಿ' (Cascading Rule Opacity) ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ನಿರ್ಧಾರಗಳು ನಿಯಮಗಳ ಪ್ರಕಾರ ಸರಿಯಾಗಿರುತ್ತವೆ, ಆದರೆ ಮನುಷ್ಯರಿಗೆ ಅವುಗಳನ್ನು ವಿವರಿಸುವುದು ಅಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಜಪಾನ್‌ನಲ್ಲಿ, ಡೆವಲಪರ್‌ಗಳು ಇದನ್ನು 'ರೂಲ್ ಪ್ರೆಸಿಡೆನ್ಸ್ ಹೆಲ್' (rule precedence hell) ಎಂದು ಕರೆಯುತ್ತಾರೆ. ನಿಯಮಗಳು ತಪ್ಪಾಗಿವೆ ಎಂದಲ್ಲ. ಒಂದು ನಿಯಮವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇಡೀ ಸರಪಳಿಯನ್ನೇ ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ എന്നതാണ് ಸಮಸ್ಯೆ. ಈ ಮಾನಸಿಕ ಹೊರೆ (cognitive load) ನಿಮ್ಮ ತಂಡದ ವೇಗವನ್ನು ಕುಂಠಿತಗೊಳಿಸುತ್ತದೆ.

Qiita ನಲ್ಲಿನ ಇತ್ತೀಚಿನ ವಿಶ್ಲೇಷಣೆಯು ಇದನ್ನು ನಿರ್ವಹಿಸಲು ಮೂರು ಹಂತದ ಚೌಕಟ್ಟನ್ನು (three tier framework) ಸೂಚಿಸುತ್ತದೆ:

  • ಮೂಲಭೂತ ನಿಯಮಗಳು (Foundational Rules): ಬದಲಾಯಿಸಲಾಗದ ಮತ್ತು ಆವೃತ್ತೀಕರಿಸಲ್ಪಟ್ಟವು (Immutable and versioned).
  • ಸಂದರ್ಭೋಚಿತ ನಿಯಮಗಳು (Contextual Rules): ಡೊಮೇನ್ ನಿರ್ದಿಷ್ಟ ಹೊಂದಾಣಿಕೆಗಳು.
  • ರನ್‌ಟೈಮ್ ರೆಸಲ್ಯೂಶನ್ (Runtime Resolution): ಸ್ಪಷ್ಟವಾದ ಲಾಗಿಂಗ್‌ನೊಂದಿಗೆ ಡೈನಾಮಿಕ್ ಮೌಲ್ಯಮಾಪನ.

ಈ ರಚನೆಯು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ಇದು ಹೆಚ್ಚಿನ ಮಾನವ ವೆಚ್ಚವನ್ನು ಹೊಂದಿದೆ. ಒಂದು ತಂಡವು ಫೀಚರ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವ ಬದಲು ಕೇವಲ ನಿಯಮಗಳನ್ನು ನಿರ್ವಹಿಸಲು ತಮ್ಮ ಇಂಜಿನಿಯರಿಂಗ್ ಸಮಯದ ಶೇಕಡಾ 30 ರಷ್ಟನ್ನು ವ್ಯಯಿಸುವುದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ. ನೀವು ಒಂದು ಮೆಟಾ-ರೂಲ್ (meta-rule) ಅನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಉಳಿಸುವ ಪ್ರತಿ ಗಂಟೆಗೆ, ನಂತರ ನಿರ್ವಹಣೆಯಲ್ಲಿ 4 ಗಂಟೆಗಳನ್ನು ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ.

ನಿಜವಾದ ಸಮಸ್ಯೆ ಪದರಗಳಲ್ಲ. ಸಮಸ್ಯೆ ಏನೆಂದರೆ, ತಂಡಗಳು ವಿವೇಚನೆಯನ್ನು (judgment) ಸೇರಿಸುವ ಬದಲು ನಿಯಮಗಳನ್ನು ಸೇರಿಸುತ್ತಿವೆ.

ಮೆಟಾ-ಪ್ಯಾಟರ್ನ್‌ಗಳು (Meta-patterns) ಹೆಚ್ಚಾಗಿ ದುರ್ಬಲ ಏಜೆಂಟ್ ಮಾದರಿಗಳಿಗೆ ಪರಿಹಾರಗಳಾಗಿರುತ್ತವೆ. ಅಸ್ಪಷ್ಟತೆಯನ್ನು (ambiguity) ನಿಭಾಯಿಸುವ ಏಜೆಂಟ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವ ಬದಲು, ನಾವು ಅನುಸರಣೆಯನ್ನು ಒತ್ತಾಯಿಸಲು ಬೃಹತ್ ನಿಯಮಗಳ ಸರಪಳಿಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ.

ಈ ಬಲೆಯಿಂದ ತಪ್ಪಿಸಿಕೊಳ್ಳಲು, ಈ ಹಂತಗಳನ್ನು ಅನುಸರಿಸಿ:

  • ನಿಮ್ಮ ನಿಯಮಗಳ ಸರಪಳಿಯನ್ನು ಪ್ರತಿ ತ್ರೈಮಾಸಿಕದಲ್ಲಿ ಆಡಿಟ್ ಮಾಡಿ. ನಿಯಮಗಳು ಫೀಚರ್‌ಗಳಿಗಿಂತ ವೇಗವಾಗಿ ಬೆಳೆಯುತ್ತಿದ್ದರೆ, ನೀವು ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು (technical debt) ಹೊಂದಿದ್ದೀರಿ ಎಂದರ್ಥ.
  • 'ರೂಲ್ ಕಿಲ್ ಕಲ್ಚರ್' (rule kill culture) ಅನ್ನು ಬೆಳೆಸಿ. ಪ್ರತಿಯೊಂದು ಹೊಸ ನಿಯಮವು ಹಳೆಯದನ್ನು ಬದಲಾಯಿಸಬೇಕು.
  • ನಿಯಮದ ಪರಿಹಾರವನ್ನು (rule resolution) ಲಾಗ್ ಮಾಡಿ. ಯಾವ ನಿಯಮವು ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಎಂಬುದನ್ನು ನೀವು ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಡಿಬಗ್ (debug) ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
  • ಏಜೆಂಟ್ ವಿವೇಚನೆಯಲ್ಲಿ (agent judgment) ಹೂಡಿಕೆ ಮಾಡಿ. ಗೆಲ್ಲುವ ತಂಡಗಳು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಕಡಿಮೆ ನಿಯಮಗಳ ಅಗತ್ಯವಿರುವ ಏಜೆಂಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ.

ನಿಯಮ ನಿರ್ವಹಣೆಯನ್ನು ತಾತ್ಕಾಲಿಕ ಆಧಾರವಾಗಿ (temporary scaffolding) ಪರಿಗಣಿಸಿ. ಅದು ನಿಮ್ಮ ಶಾಶ್ವತ ಮೂಲಸೌಕರ್ಯವಾಗಲು ಬಿಡಬೇಡಿ.

AI ಏಜೆಂಟ್ ನಿರ್ಧಾರಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವಲ್ಲಿ ನಿಮ್ಮ ಅನುಭವವೇನು? ನಿಮ್ಮ ನಿಯಮಗಳ ಪಟ್ಟಿ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗದಷ್ಟು ವೇಗವಾಗಿ ಬೆಳೆದಿದೆಯೇ?

Source: https://qiita.com/shatolin/items/5c18619d3474b7962021

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