ಎಂಟರ್ಪ್ರೈಸ್ ಮಟ್ಟದಲ್ಲಿ Text-to-SQL ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ?
ಹೆಚ್ಚಿನ Text-to-SQL ಪ್ರಾತ್ಯಕ್ಷಿಕೆಗಳು (demos) ಅತಿಯಾದ ಸರಳತೆಯನ್ನು ಹೊಂದಿರುತ್ತವೆ.
ಅವು ಸರಳ ಸ್ಕೀಮಾಗಳು ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ಟೇಬಲ್ ಹೆಸರುಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಒಂದು ಅಥವಾ ಎರಡು ಟೇಬಲ್ಗಳು ಪರಿಪೂರ್ಣವಾಗಿ ಸಂಪರ್ಕ ಹೊಂದಿವೆ ಎಂದು ಅವು ಭಾವಿಸುತ್ತವೆ. ಇದು ಪ್ರಾತ್ಯಕ್ಷಿಕೆಗಳಿಗೆ (demo) ಸರಿಹೊಂದಬಹುದು, ಆದರೆ ನೈಜ ಕಂಪನಿಗಳಲ್ಲಿ ಇದು ವಿಫಲವಾಗುತ್ತದೆ.
ಎಂಟರ್ಪ್ರೈಸ್ ಡೇಟಾಬೇಸ್ಗಳಲ್ಲಿ, ಕಷ್ಟದ ಭಾಗ SELECT clause ಅಲ್ಲ. ಕಷ್ಟದ ಭಾಗವೆಂದರೆ join path.
ಒಂದು ಮಾಡೆಲ್ ಗ್ರಾಹಕನ ಪ್ರಕಾರ ಆದಾಯವನ್ನು (revenue by customer) ತೋರಿಸಲು ಸರಿಯಾದ ಕ್ವೆರಿಯನ್ನು ಬರೆಯಬಹುದು. SQL ರನ್ ಆಗುತ್ತದೆ. ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಅಂಕಿಅಂಶಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಆದರೆ ಉತ್ತರ ತಪ್ಪಾಗಿರುತ್ತದೆ.
ಇದು ಏಕೆ ಸಂಭವಿಸುತ್ತದೆ?
- ಗ್ರಾಹಕರ ಟೇಬಲ್ ಅಧಿಕೃತ ಮಾಸ್ಟರ್ ಲಿಸ್ಟ್ ಆಗಿರುವುದಿಲ್ಲ.
- ಆದಾಯದ (revenue) ಫೀಲ್ಡ್ ಹಣಕಾಸು ವಿಭಾಗದಿಂದ ಅನುಮೋದಿಸಲ್ಪಟ್ಟ ಆವೃತ್ತಿಯಾಗಿರುವುದಿಲ್ಲ.
- ವಿವಿಧ ಪ್ರದೇಶಗಳಲ್ಲಿ ದಾಖಲೆಗಳು ಪುನರಾವರ್ತಿತವಾಗಿರುತ್ತವೆ (duplicated).
- join ಮಾಡುವುದರಿಂದ fanout ದೋಷಗಳು ಉಂಟಾಗುತ್ತವೆ.
- ಹಣಕಾಸು ಕ್ಯಾಲೆಂಡರ್ಗಳು (fiscal calendars) ಸಾಮಾನ್ಯ ಕ್ಯಾಲೆಂಡರ್ ವರ್ಷಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿರುತ್ತವೆ.
ವ್ಯಾಕರಣಬದ್ಧವಾಗಿ (syntactically) ಸರಿಯಾದ ಕ್ವೆರಿಯೆಂದರೆ ಅದು ನಂಬಲರ್ಹವಾದ ಕ್ವೆರಿ ಎಂದರ್ಥವಲ್ಲ.
ನೈಜ ಪ್ರೊಡಕ್ಷನ್ ಸಿಸ್ಟಮ್ಗಳು ಗೊಂದಲಮಯವಾಗಿರುತ್ತವೆ. ನೀವು ಮಿಸ್ಸಿಂಗ್ ಫಾರೆನ್ ಕೀಗಳು (missing foreign keys), ಹಳೆಯ ಟೇಬಲ್ಗಳು (legacy tables) ಮತ್ತು ಅಂಕಿಅಂಶಗಳನ್ನು ಅತಿಯಾಗಿ ತೋರಿಸುವ 'ಒನ್-ಟು-ಮನಿ' (one-to-many) ಸಂಬಂಧಗಳನ್ನು ಎದುರಿಸುತ್ತೀರಿ. ಮನುಷ್ಯರು ಕೂಡ ಒಂದು join ಅನ್ನು ನಂಬುವ ಮೊದಲು ಹಳೆಯ ವರದಿಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾಗುತ್ತದೆ ಅಥವಾ ಹಣಕಾಸು ವಿಭಾಗವನ್ನು ಕೇಳಬೇಕಾಗುತ್ತದೆ.
AI ಮಾಡೆಲ್ ಕೇವಲ ಹೆಸರುಗಳು ಮತ್ತು ಕಾಲಮ್ಗಳನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ. ಅದು ಊಹಿಸುತ್ತದೆ. ಕೆಲವೊಮ್ಮೆ ಆ ಊಹೆಯು ಅಪಾಯಕಾರಿಯಾಗಿರುತ್ತದೆ.
fanout ಅನ್ನು ಗಮನಿಸಿ. ನೀವು orders ಅನ್ನು order lines ಗೆ ಮತ್ತು ನಂತರ shipments ಗೆ join ಮಾಡಿದರೆ, ಒಂದು order ಅನ್ನು ಹಲವು ಬಾರಿ ಎಣಿಸಬಹುದು. SQL ಸರಿಯಾಗಿರುತ್ತದೆ, ಆದರೆ ಫಲಿತಾಂಶ ತಪ್ಪಾಗಿರುತ್ತದೆ.
ಮೆಟಾಡೇಟಾ (Metadata) ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ಅದು ಸಾಕಾಗುವುದಿಲ್ಲ. ಒಂದು ಸಂಬಂಧವು ಹಣಕಾಸಿನ ವರದಿಗಾಗಿ ಸುರಕ್ಷಿತವೇ ಎಂದು ಕಾಲಮ್ ಹೆಸರುಗಳು ನಿಮಗೆ ತಿಳಿಸುವುದಿಲ್ಲ. ಫಾರೆನ್ ಕೀಗಳು ಐತಿಹಾಸಿಕ ವಿನಾಯಿತಿಗಳನ್ನು (historical exceptions) ವಿವರಿಸುವುದಿಲ್ಲ.
Text-to-SQL ಗೆ ರಿಲೇಶನ್ಶಿಪ್ ಇಂಟೆಲಿಜೆನ್ಸ್ (relationship intelligence) ಅಗತ್ಯವಿದೆ.
ಒಂದು ವಿಶ್ವಾಸಾರ್ಹ ಸಿಸ್ಟಮ್ ಈ ಕೆಳಗಿನವುಗಳನ್ನು ತಿಳಿದಿರಬೇಕು:
- ನಿರ್ದಿಷ್ಟ ವ್ಯವಹಾರದ ಪ್ರಶ್ನೆಗಳಿಗೆ ಅನುಮೋದಿತ join paths.
- ರಿಲೇಶನ್ಶಿಪ್ ಕಾರ್ಡಿನಾಲಿಟಿ (Relationship cardinality).
- ತಿಳಿದಿರುವ fanout ಅಪಾಯಗಳು.
- ಯಾವ ಮಾರ್ಗಗಳು ಬಳಕೆಯಲ್ಲಿಲ್ಲ (deprecated).
ಕೇವಲ ಕೋಡ್ ಬರೆಯುವ ಬದಲು, ಸಿಸ್ಟಮ್ ಸುರಕ್ಷತೆಯ ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕು. ಅದು ನಂಬಲರ್ಹವಾದ ಮಾರ್ಗವನ್ನು ಆರಿಸಿಕೊಳ್ಳಬೇಕು ಅಥವಾ ಮಾರ್ಗಗಳು ಅಸ್ಪಷ್ಟವಾಗಿದ್ದಾಗ ಸಹಾಯ ಕೇಳಬೇಕು.
ಪ್ರಸ್ತುತ ಸಿಸ್ಟಮ್ಗಳಲ್ಲಿನ ಕೊರತೆಯೆಂದರೆ ಹೆಸರುಗಳನ್ನು ಮ್ಯಾಪ್ ಮಾಡುವುದರಿಂದ SQL ಅನ್ನು ರಚಿಸುವವರೆಗಿನ ಅಂತರ. ನೀವು ರಿಲೇಶನ್ಶಿಪ್ ಕಾನ್ಟೆಕ್ಸ್ಟ್ (relationship context) ಎಂಬ ಒಂದು ಪದರವನ್ನು ಸೇರಿಸಬೇಕು.
Text-to-SQL ಎಂಬುದು ಕೇವಲ ಭಾಷೆಯ ಸಮಸ್ಯೆಯಲ್ಲ. ಇದು ಕಾನ್ಟೆಕ್ಸ್ಟ್ (context) ಸಮಸ್ಯೆ.
ಯಾವ join ಗಳು ಸುರಕ್ಷಿತ ಎಂದು ಮಾಡೆಲ್ಗಳು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವವರೆಗೆ, ಅವು ಪ್ರಾತ್ಯಕ್ಷಿಕೆಗಳಲ್ಲಿ (demos) ಕೆಲಸ ಮಾಡುತ್ತವೆ ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ.
Source: https://dev.to/arisyndata/why-text-to-sql-breaks-when-the-join-path-is-not-obvious-3bk0
Optional learning community: https://t.me/GyaanSetuAi