OpenSearch ಮತ್ತು CJK ಬಳಸಿ ನಾನು ಟೈಪೊ-ಟೋಲರೆಂಟ್ (Typo-Tolerant) ಸರ್ಚ್ ಅನ್ನು ಹೇಗೆ ಸೇರಿಸಿದೆ
ಯಾವುದೇ ಫಲಿತಾಂಶ ಬಾರದ ಸರ್ಚ್ಗಳು (Zero-result queries) ನಮ್ಮ ವಾಚ್ ಟೈಮ್ ಅನ್ನು ಕುಗ್ಗಿಸುತ್ತಿದ್ದವು.
ಒಂದು ವರ್ಷದವರೆಗೆ, TopVideoHub ಸರ್ಚ್ಗಾಗಿ SQLite FTS5 ಅನ್ನು ಬಳಸುತ್ತಿತ್ತು. ಇದು ನಿಖರವಾದ ಹೊಂದಾಣಿಕೆಗಳಿಗೆ (exact matches) ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು. ಆದರೆ ಬಳಕೆದಾರರು ಕಾಗುಣಿತ ತಪ್ಪುಗಳನ್ನು (typos) ಮಾಡಿದಾಗ ಇದು ವಿಫಲವಾಗುತ್ತಿತ್ತು.
ಜನರು "demon slayer" ಬದಲಿಗೆ "demon slyer" ಎಂದು ಹುಡುಕುತ್ತಿದ್ದರು. ಜಪಾನೀಸ್ ಅಥವಾ ಕೊರಿಯನ್ ಶೀರ್ಷಿಕೆಗಳಲ್ಲಿ ಅವರು ಅನಗತ್ಯ ಸ್ಪೇಸ್ಗಳನ್ನು ಸೇರಿಸುತ್ತಿದ್ದರು. FTS5 ನಿಖರವಾದ ಟೋಕನ್ಗಳನ್ನು (tokens) ಹೊಂದಾಣಿಕೆ ಮಾಡುವುದರಿಂದ, ಒಂದು ಸಣ್ಣ ಕಾಗುಣಿತ ತಪ್ಪೂ ಯಾವುದೇ ಫಲಿತಾಂಶ ಬರದಂತೆ ಮಾಡುತ್ತಿತ್ತು. ಬಳಕೆದಾರರು ಮತ್ತೆ ಹುಡುಕುತ್ತಿರಲಿಲ್ಲ. ಅವರು ಸುಮ್ಮನೆ ಹೊರಟು ಹೋಗುತ್ತಿದ್ದರು.
ನಾನು ನಮ್ಮ ಶೀರ್ಷಿಕೆ ಸರ್ಚ್ ಅನ್ನು OpenSearch ಗೆ ವರ್ಗಾಯಿಸಿದೆ. ಬಹುಭಾಷಾ ಪ್ರೇಕ್ಷಕರಿಗಾಗಿ ನಾನು ಇದನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಿದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ.
ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಫಜಿನೆಸ್ (Standard Fuzziness) ನಲ್ಲಿರುವ ಸಮಸ್ಯೆ
ಹೆಚ್ಚಿನ ಟ್ಯುಟೋರಿಯಲ್ಗಳು ಕಾಗುಣಿತ ತಪ್ಪುಗಳನ್ನು ಸರಿಪಡಿಸಲು "fuzziness" ಬಳಸಿ ಎಂದು ಹೇಳುತ್ತವೆ. ಇದು ಇಂಗ್ಲಿಷ್ಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಚೀನೀ, ಜಪಾನೀಸ್ ಮತ್ತು ಕೊರಿಯನ್ (CJK) ಪಠ್ಯಗಳಿಗೆ ಇದು ವಿಫಲವಾಗುತ್ತದೆ.
- ಎಡಿಟ್ ಡಿಸ್ಟೆನ್ಸ್ (Edit distance) CJK ಗೆ ಸರಿಯಲ್ಲ. CJK ನಲ್ಲಿ ಕಾಗುಣಿತ ತಪ್ಪು ಎಂದರೆ ಹೆಚ್ಚಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪು ಅಕ್ಷರವನ್ನು ಬಳಸು ಎಂದರ್ಥ.
- ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಫಜಿನೆಸ್ ಅರ್ಥಹೀನ ಫಲಿತಾಂಶಗಳನ್ನು (semantic garbage) ನೀಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, "fire" ಮತ್ತು "water" ಒಂದೇ ಎಡಿಟ್ ಅಂತರದಲ್ಲಿದ್ದರೆ ಅದು ಅವುಗಳನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡಬಹುದು.
- ಟೋಕನೈಸೇಶನ್ (Tokenization) ಕಷ್ಟಕರವಾಗಿದೆ. CJK ಭಾಷೆಗಳು ಪದಗಳ ನಡುವೆ ಸ್ಪೇಸ್ಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ.
ಪರಿಹಾರ: ಮಲ್ಟಿ-ಫೀಲ್ಡ್ ವಿಧಾನ (A Multi-Field Approach)
ನಾನು ಎಲ್ಲಾ ಪಠ್ಯಗಳನ್ನು ಒಂದೇ ರೀತಿ ಪರಿಗಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ. ನಾನು ಮೂರು ವಿಭಿನ್ನ ವಿಧಾನಗಳಲ್ಲಿ ಇಂಡೆಕ್ಸ್ ಮಾಡುವ ಒಂದು ಲಾಜಿಕಲ್ ಶೀರ್ಷಿಕೆ ಫೀಲ್ಡ್ ಅನ್ನು ರಚಿಸಿದೆ:
- ಲ್ಯಾಟಿನ್ ಮತ್ತು ರೋಮಾಜಿ (Latin and Romaji): ನಾನು ಫಜಿನೆಸ್ ಅನ್ನು ಎನೇಬಲ್ ಮಾಡಿ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಟೋಕನೈಸೇಶನ್ ಬಳಸಿದೆ. ನಾನು ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದವನ್ನು (prefix length) 1 ಎಂದು ನಿಗದಿಪಡಿಸಿದೆ. ಇದು "demon" ಎಂಬುದು "demn" ಗೆ ಹೊಂದಿಕೆಯಾಗುವಂತೆ ಮಾಡುತ್ತದೆ, ಆದರೆ "lemon" ಎಂಬುದು "demon" ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.
- CJK ಪಠ್ಯ: ನಾನು CJK bigram analyzer ಮತ್ತು ICU normalizer ಅನ್ನು ಬಳಸಿದೆ. ನಾನು ಫಜಿನೆಸ್ ಅನ್ನು ಆಫ್ (OFF) ಮಾಡಿದೆ. ಬದಲಾಗಿ, ನಾನು 70% ರಷ್ಟು ಕನಿಷ್ಠ ಹೊಂದಾಣಿಕೆಯ ಮಿತಿಯನ್ನು (minimum match threshold) ಬಳಸಿದೆ.
- ಆಟೋಕಂಪ್ಲೀಟ್ (Autocomplete): ಸರ್ಚ್-ಆಸ್-ಯೂ-ಟೈಪ್ (search-as-you-type) ಫಲಿತಾಂಶಗಳಿಗಾಗಿ ನಾನು
edge-ngramಫೀಲ್ಡ್ ಅನ್ನು ಬಳಸಿದೆ.
ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಡೇಟಾ ಸುರಕ್ಷತೆ (Architecture and Data Safety)
ನಾನು SQLite ಅನ್ನು ಏಕೈಕ ಮೂಲ ಸತ್ಯವಾಗಿ (single source of truth) ಇರಿಸಿಕೊಂಡೆ. OpenSearch ವೇಗವಾದ ಮತ್ತು ಮರುನಿರ್ಮಾಣ ಮಾಡಬಹುದಾದ ಇಂಡೆಕ್ಸ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
- ನಾನು ಬಲ್ಕ್ ಬ್ಯಾಚ್ಗಳಲ್ಲಿ (bulk batches) OpenSearch ಗೆ ಅಪ್ಡೇಟ್ಗಳನ್ನು ಕಳುಹಿಸಲು PHP ಬಳಸುತ್ತೇನೆ.
- ಬಳಕೆದಾರರ ವಿನಂತಿಯ (user request) ಸಮಯದಲ್ಲಿ ನಾನು ಎಂದಿಗೂ ಇಂಡೆಕ್ಸಿಂಗ್ ಮಾಡುವುದಿಲ್ಲ.
- "ಡ್ರಿಫ್ಟ್" (drift) ಅನ್ನು ಪರಿಶೀಲಿಸಲು ನಾನು ಪೈಥಾನ್ (Python) ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತೇನೆ. ಇದು OpenSearch ಸಂಖ್ಯೆಯು SQLite ಸಂಖ್ಯೆಗೆ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಫಲಿತಾಂಶಗಳು
ಬದಲಾವಣೆಯು ಭಾರಿ ಪ್ರಮಾಣದಲ್ಲಿತ್ತು:
- ಯಾವುದೇ ಫಲಿತಾಂಶ ಬಾರದ ಸರ್ಚ್ಗಳು 14% ರಿಂದ 3% ಕ್ಕಿಂತ ಕಡಿಮೆಗೆ ಇಳಿದವು.
- ಬಳಕೆದಾರರು ತಮಗೆ ಬೇಕಾದುದನ್ನು ತಕ್ಷಣವೇ ಕಂಡುಕೊಂಡಿದ್ದರಿಂದ ಸರ್ಚ್ ಸೆಷನ್ಗಳು ದೀರ್ಘವಾದವು.
- ಲೇಟೆನ್ಸಿ (Latency) ಸುಮಾರು 40ms ರಷ್ಟು ಕಡಿಮೆ ಇದೆ.
ನೀವು ಬಹುಭಾಷಾ ಪ್ರೇಕ್ಷಕರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತಿದ್ದರೆ, ನೆನಪಿಡಿ: ಟೈಪೊ ಟೋಲರೆನ್ಸ್ ಮತ್ತು CJK ಮ್ಯಾಚಿಂಗ್ ಎಂಬುದು ಎರಡು ವಿಭಿನ್ನ ಸಮಸ್ಯೆಗಳು. ನಿಮಗೆ ಎರಡು ವಿಭಿನ್ನ ಪರಿಹಾರಗಳ ಅಗತ್ಯವಿದೆ.