Large-language-model (LLM) ಏಜೆಂಟ್ಗಳು ಸಿದ್ಧಪಡಿಸುವ Oracle SQL ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಕಾಗದದ ಮೇಲೆ ಪರಿಪೂರ್ಣವಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು. 2.3 ಮಿಲಿಯನ್ ಸಾಲುಗಳ ಹಳೆಯ ಕೋಡ್ಬೇಸ್ನಲ್ಲಿ (legacy codebase), ಒಂದು AI-ಚಾಲಿತ ಏಜೆಂಟ್ ಪದೇ ಪದೇ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಐಡೆಂಟಿಫೈಯರ್ಗಳನ್ನು ಬಳಸುತ್ತಿತ್ತು – ಉದಾಹರಣೆಗೆ, ನೈಜ STATUS_CD ಕಾಲಮ್ ಬದಲಿಗೆ POLICY_STATUS ಬಳಸುವುದು ಅಥವಾ CUSTOMER ಬದಲಿಗೆ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ CUSTOMERS ಟೇಬಲ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುವುದು.
ಟೈಪೋಗಳನ್ನು (typo) ಪತ್ತೆಹಚ್ಚಲು UPDATE ಅಥವಾ DELETE ಸ್ಟೇಟ್ಮೆಂಟ್ಗಳನ್ನು ರನ್ ಮಾಡುವುದು ಸರಿಯಾದ ಆಯ್ಕೆಯಲ್ಲ. ಪ್ರೊಡಕ್ಷನ್ನಂತಹ ಡೇಟಾಸೆಟ್ನಲ್ಲಿ ಅವುಗಳನ್ನು ಚಲಾಯಿಸುವುದರಿಂದ ಲಾಕ್ಗಳು (locks) ಉಂಟಾಗಬಹುದು, ಸೀಕ್ವೆನ್ಸ್ ನಂಬರ್ಗಳು ವ್ಯಯವಾಗಬಹುದು ಮತ್ತು ಅನಿರೀಕ್ಷಿತ ಪರಿಣಾಮಗಳನ್ನು (cascading side-effects) ಉಂಟುಮಾಡಬಹುದು. ಡೆವಲಪರ್ಗಳಿಗೆ ಯಾವುದೇ ಡೇಟಾವನ್ನು ಮುಟ್ಟದೆ ಹೆಸರು ಮತ್ತು ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ವ್ಯಾಲಿಡೇಟ್ ಮಾಡಲು ಒಂದು ಮಾರ್ಗ ಬೇಕಿದೆ. ಇದಕ್ಕೆ ಅತ್ಯಂತ ಸರಳವಾದ ಉತ್ತರವೆಂದರೆ Oracle ನ EXPLAIN PLAN ಕಮಾಂಡ್ – ಇದನ್ನು ಲಿಂಟಿಂಗ್ ಹಂತವಾಗಿ (linting step) ಬಳಸಬಹುದು.
EXPLAIN PLAN ವೇಗದ ವ್ಯಾಲಿಡೇಟರ್ ಆಗಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ
Oracle ಒಂದು ಸ್ಟೇಟ್ಮೆಂಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಅದು ಮೊದಲು ಅದನ್ನು ಪಾರ್ಸ್ (parse) ಮಾಡುತ್ತದೆ. ಪಾರ್ಸಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯು ಉಲ್ಲೇಖಿಸಲಾದ ಪ್ರತಿಯೊಂದು ಟೇಬಲ್, ಕಾಲಮ್ ಮತ್ತು ಪ್ರಿವિલેಜ್ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ, ನಂತರ ಎಕ್ಸಿಕ್ಯೂಷನ್ ಪ್ಲಾನ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ ಮತ್ತು ಆ ಪ್ಲಾನ್ ಅನ್ನು ಸಿಸ್ಟಮ್ ಟೇಬಲ್ಗೆ ಬರೆಯುತ್ತದೆ. ಈ ಕಮಾಂಡ್ ಸ್ಟೇಟ್ಮೆಂಟ್ ಅನ್ನು ಎಂದಿಗೂ ರನ್ ಮಾಡುವುದಿಲ್ಲ: ಯಾವುದೇ ರೋಗಳು (rows) ಬದಲಾಗುವುದಿಲ್ಲ, ಯಾವುದೇ ಟ್ರಿಗರ್ಗಳು (triggers) ಕಾರ್ಯಗತಗೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಲಾಕ್ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗುವುದಿಲ್ಲ. ಪಾರ್ಸರ್ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಯಾವುದಾದರೂ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಕಂಡರೆ, ಅದು ಮಿಲಿಸೆಕೆಂಡುಗಳಲ್ಲಿ ಎರರ್ (error) ತೋರಿಸುತ್ತದೆ.
ಈ ವರ್ತನೆಯು AI-ಜನರೇಟೆಡ್ SQL ಗಾಗಿ EXPLAIN PLAN ಅನ್ನು ಪರಿಪೂರ್ಣವಾದ ಪ್ರಿ-ಫ್ಲೈಟ್ ಚೆಕ್ (pre-flight check) ಮಾಡುತ್ತದೆ. ಮಿಸ್ಸಿಂಗ್ ಟೇಬಲ್ ಅಥವಾ ಕಾಲಮ್ ಅನ್ನು ತಕ್ಷಣವೇ ವರದಿ ಮಾಡಲಾಗುತ್ತದೆ, ಇದರಿಂದ ಮನುಷ್ಯರು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ನೋಡುವ ಮೊದಲೇ ಜನರೇಷನ್ ಲೂಪ್ ತಪ್ಪುಗಳನ್ನು ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ನನ್ನ CI ಪೈಪ್ಲೈನ್ಗೆ ನಾನು ಅಳವಡಿಸಿದ ವರ್ಕ್ಫ್ಲೋ (workflow)
- ಬರುವ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಸ್ಟೇಟ್ಮೆಂಟ್ಗಳಾಗಿ ವಿಂಗಡಿಸಿ (Split).
- ಡೆವಲಪ್ಮೆಂಟ್ ಸ್ಕೀಮಾದ ವಿರುದ್ಧ
EXPLAIN PLAN FOR <statement>ಅನ್ನು ಚಲಾಯಿಸಿ (Run). - Oracle ನೀಡುವ ಯಾವುದೇ ಪಾರ್ಸಿಂಗ್ ಎರರ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ (Collect).
- ಮರುಪ್ರಯತ್ನಕ್ಕಾಗಿ (retry) ಆ ಎರರ್ಗಳನ್ನು LLM ಗೆ ತಿರುಗಿ ನೀಡಿ (Feed).
ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಒಂದು ಮರುಪ್ರಯತ್ನವು ಹೆಚ್ಚಿನ ಹೆಸರಿನ ಎರರ್ಗಳನ್ನು ನಿವಾರಿಸುತ್ತದೆ. AI ಸರಿಯಾದ ಸ್ಕೀಮಾವನ್ನು ಕಲಿಯುತ್ತದೆ ಮತ್ತು ತನ್ನ ಔಟ್ಪುಟ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಂದಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನಾನು ಏಜೆಂಟ್ ಅನ್ನು ರೀಡ್-ಓನ್ಲಿ ಮೋಡ್ನಲ್ಲಿ (read-only mode) ಲಾಕ್ ಮಾಡುತ್ತೇನೆ: ಅದು SELECT ಮತ್ತು EXPLAIN PLAN ಕರೆಗಳನ್ನು ಮಾಡಬಹುದು, ಆದರೆ DDL, DML ಮತ್ತು COMMIT ಅನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗುತ್ತದೆ. ಈ ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ (sandbox) AI ಅದರ ರಚನೆಯನ್ನು ಪರೀಕ್ಷಿಸುವಾಗ ಡೇಟಾಬೇಸ್ ಬದಲಾಗದಂತೆ ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಹೆಸರುಗಳ ಪರಿಶೀಲನೆಯನ್ನು ಮೀರಿ, ಜನರೇಟ್ ಆದ ಪ್ಲಾನ್ ಸ್ಪಷ್ಟವಾದ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ರೆಡ್ ಫ್ಲಾಗ್ಗಳನ್ನು (performance red flags) ತೋರಿಸುತ್ತದೆ. ಒಂದು ಸ್ಟೇಟ್ಮೆಂಟ್ ದೊಡ್ಡ ಟೇಬಲ್ ಮೇಲೆ ಫುಲ್-ಟೇಬಲ್ ಸ್ಕ್ಯಾನ್ (full-table scan) ಅನ್ನು ಉಂಟುಮಾಡಿದರೆ, ಯಾವುದೇ ರೋಗಳು ಬದಲಾಗುವ ಮೊದಲೇ ಪ್ಲಾನ್ ಅದನ್ನು ತೋರಿಸುತ್ತದೆ, ಇದು ಡೆವಲಪರ್ಗಳಿಗೆ ಇಂಡೆಕ್ಸ್ಗಳನ್ನು ಸೂಚಿಸಲು ಅಥವಾ ಪ್ರೆಡಿಕೇಟ್ ಅನ್ನು ಮರುಬರೆಯಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ.
ಈ ವಿಧಾನದ ಮಿತಿಗಳು
- ತಾರ್ಕಿಕ ನಿಖರತೆಯನ್ನು (Logical correctness) ಪರಿಶೀಲಿಸಲಾಗುವುದಿಲ್ಲ. ಸರಿಯಾದ ಕಾಲಮ್ಗಳನ್ನು ಉಲ್ಲೇಖಿಸುವ ಆದರೆ ತಪ್ಪು ಫಿಲ್ಟರ್ ಅನ್ನು ಅನ್ವಯಿಸುವ ಸ್ಟೇಟ್ಮೆಂಟ್ ಕೂಡ ಲಿಂಟ್ನಲ್ಲಿ ಪಾಸಾಗುತ್ತದೆ.
- PL/SQL ಬ್ಲಾಕ್ಗಳು ವ್ಯಾಪ್ತಿಯ ಹೊರಗಿವೆ. ಪಾರ್ಸರ್ ಕೇವಲ ವೈಯಕ್ತಿಕ SQL ಸ್ಟೇಟ್ಮೆಂಟ್ಗಳನ್ನು ಮಾತ್ರ ನಿರ್ವಹಿಸುತ್ತದೆ; ಪ್ರೊಸೀಜರಲ್ ಕೋಡ್ಗೆ ಪ್ರತ್ಯೇಕ ವ್ಯಾಲಿಡೇಶನ್ ಮಾರ್ಗ ಬೇಕಾಗುತ್ತದೆ.
- ಡೇಟಾ-ಮಟ್ಟದ ವ್ಯಾಲಿಡೇಶನ್ ಇಲ್ಲ. ಒಂದು ಲಿಟರಲ್ ವ್ಯಾಲ್ಯೂ ಕಾಲಮ್ನ ಡೊಮೇನ್ಗೆ ಅನುಗುಣವಾಗಿದೆಯೇ ಅಥವಾ ಫಾರಿನ್-ಕೀ ರೆಫರೆನ್ಸ್ ನಿಜವಾಗಿಯೂ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆಯೇ ಎಂದು ಲಿಂಟ್ ಹೇಳಲಾರದು.
- ಕೇವಲ ಡೆವ್ ಸ್ಕೀಮಾ (Dev schema). ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಮಾತ್ರ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಎರರ್ಗಳು - ಉದಾಹರಣೆಗೆ, ಡೆವ್ನಲ್ಲಿ ಇರುವ ಟೇಬಲ್ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಮರುನಾಮಕರಣಗೊಂಡಿದ್ದರೆ - ನಂತರದವರೆಗೆ ಕಾಣಿಸುವುದಿಲ್ಲ.
ಈ ಕೊರತೆಗಳು ವಿಧಾನದ ಉಪಯುಕ್ತತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವುದಿಲ್ಲ; ಅವು ಕೇವಲ ಅದರ ವ್ಯಾಪ್ತಿಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತವೆ. ಹೆಚ್ಚಿನ LLM-ಜನರೇಟೆಡ್ DML ಸ್ಕ್ರಿಪ್ಟ್ಗಳಲ್ಲಿ, ಸಾಮಾನ್ಯ ವೈಫಲ್ಯವು ಟೈಪೋ ಅಥವಾ ತಪ್ಪು ಆಬ್ಜೆಕ್ಟ್ ಹೆಸರಾಗಿರುತ್ತದೆ ಮತ್ತು EXPLAIN PLAN ಅದನ್ನು ನಿಖರವಾಗಿ ಪತ್ತೆಹಚ್ಚುತ್ತದೆ.
ಇತರ ಡೇಟಾಬೇಸ್ ಇಂಜಿನ್ಗಳಿಗೆ ಪೋರ್ಟಬಿಲಿಟಿ (Portability)
ಇದೇ ತತ್ವವು Oracle ಮೀರಿ ಅನ್ವಯಿಸುತ್ತದೆ. PostgreSQL ನ PREPARE ಸ್ಟೇಟ್ಮೆಂಟ್ ಅಥವಾ EXPLAIN ಕ್ಯುರಿಯನ್ನು ರನ್ ಮಾಡದೆ ಪಾರ್ಸ್ ಮಾಡಬಲ್ಲದು. SQL Server SET PARSEONLY ON ಅನ್ನು ನೀಡುತ್ತದೆ, ಇದು ವಾಸ್ತವ ಪ್ರೊಸೆಸಿಂಗ್ ಅನ್ನು ಬಿಟ್ಟು ಸಿಂಟ್ಯಾಕ್ಸ್ ಮತ್ತು ಆಬ್ಜೆಕ್ಟ್ ಹೆಸರುಗಳನ್ನು ವ್ಯಾಲಿಡೇಟ್ ಮಾಡಲು ಇಂಜಿನ್ ಅನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಪಾರ್ಸಿಂಗ್ ಅನ್ನು ಎಕ್ಸಿಕ್ಯೂಷನ್ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುವ ಯಾವುದೇ RDBMS ಲೈಟ್ವೇಯ್ಟ್ ಲಿಂಟಿಂಗ್ ಗೇಟ್ ಆಗಬಹುದು.
ಸಾರಾಂಶ (Takeaway)
ಪ್ರತಿಯೊಂದು AI-ಜನರೇಟೆಡ್ SQL ಸ್ಟೇಟ್ಮೆಂಟ್ ಮೇಲೆ EXPLAIN PLAN (ಅಥವಾ ಅದರ ಸಮಾನವಾದದ್ದನ್ನು) ರನ್ ಮಾಡುವುದು ಡೇಟಾಬೇಸ್ ಪಾರ್ಸರ್ ಅನ್ನು ಅಗ್ಗದ, ಶೂನ್ಯ-ಅಪಾಯದ ಲಿಂಟಿಂಗ್ ಗೇಟ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಯಾವುದೇ ಡೇಟಾ ಚಲಿಸುವ ಮೊದಲೇ ಇದು ಸಾಮಾನ್ಯ ಹೆಸರಿನ ಮತ್ತು ಸಿಂಟ್ಯಾಕ್ಸ್ ಎರರ್ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ, ಇದರಿಂದ ಡೆವಲಪರ್ಗಳು LLM-ಸಹಾಯದ ಕೋಡಿಂಗ್ನಿಂದ ಉತ್ಪಾದಕತೆಯನ್ನು ಪಡೆಯುವಾಗ ಹಳೆಯ ಸಿಸ್ಟಮ್ಗಳು ಸ್ಥಿರವಾಗಿರುತ್ತವೆ.