ಹೆಚ್ಚಿನ ತಂಡಗಳು ತಮ್ಮ ಮೊದಲ ರಿಟ್ರಿೀವಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಒಂದೇ ರೀತಿಯಲ್ಲಿ ನಿರ್ಮಿಸುತ್ತವೆ: ಪ್ರತಿಯೊಂದು ದಾಖಲೆಯನ್ನು 512-ಟೋಕನ್ನ ಸ್ಥಿರ ಚಂಕ್ಗಳಾಗಿ (fixed chunks) ವಿಭಜಿಸುವುದು, ಅವುಗಳನ್ನು ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ಗೆ ಕಳುಹಿಸುವುದು ಮತ್ತು ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್ ಕಠಿಣ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತದೆ ಎಂದು ಭಾವಿಸುವುದು. ಆ ಭರವಸೆಯು ಕೇವಲ ಡೆಮೊ ಮಟ್ಟದಲ್ಲಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಅದು ನೈಜ ಬಳಕೆದಾರರ ಬಳಿ ತಲುಪಿದಾಗ ವಿಫಲವಾಗುತ್ತದೆ.
ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ, ಒಂದು ಹೊಣೆಗಾರಿಕೆಯ ಕಲೌಸ್ ಅನ್ನು (liability clause) ಅದರ ವಿನಾಯಿತಿಗಳಿಂದ (exceptions) ಬೇರ್ಪಡಿಸಿದಾಗ ಕಾನೂನು ಒಪ್ಪಂದವು ಅರ್ಥಹೀನವಾಗುತ್ತದೆ. ಒಂದು ಕೋಡ್ ಸ್ಯಾಂಪಲ್ ಅನ್ನು ಅದರ ಫಂಕ್ಷನ್ ಸಿಗ್ನೇಚರ್ನಿಂದ ಬೇರ್ಪಡಿಸಿದಾಗ API ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಪ್ರಯೋಜನವಿಲ್ಲದಂತಾಗುತ್ತದೆ. ಒಂದು ದೂರು ಅಥವಾ ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸದಿಂದ ಕೇವಲ ಒಂದು ದೂರನ್ನು ಮಾತ್ರ ತೆಗೆದರೆ, ಕಸ್ಟಮರ್ ಸಪೋರ್ಟ್ ಥ್ರೆಡ್ ಕೇವಲ ಗೊಂದಲಮಯ ಮಾಹಿತಿಯಾಗುತ್ತದೆ. ಸಮಸ್ಯೆ ಹೆಚ್ಚಾಗಿ ಪೈಪ್ಲೈನ್ನ ಕೊನೆಯಲ್ಲಿರುವ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ ಅಲ್ಲ. ಸಮಸ್ಯೆ ನೀವು ಅದಕ್ಕೆ ನೀಡುವ ಮಾಹಿತಿಯಲ್ಲಿದೆ.
ನಾವು ಇದನ್ನು ಕಷ್ಟಪಟ್ಟು ಕಲಿತೆವು. ನಮ್ಮ ಆರಂಭಿಕ ರಿಟ್ರಿೀವಲ್ ಲೇಯರ್ ಸಾಮಾನ್ಯವಾಗಿ ಕಂಡರೂ ಅಸ್ಥಿರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿತ್ತು. ಆದ್ದರಿಂದ ನಾವು ಒಂದು ಸರಳ ಪರಿಕಲ್ಪನೆಯೊಂದಿಗೆ ಅದನ್ನು ಮರುನಿರ್ಮಿಸಿದೆವು: ರಿಟ್ರಿೀವಲ್ ಅನ್ನು ಮ್ಯಾಜಿಕ್ ಎಂದು ಭಾವಿಸದೆ, ಅದನ್ನು ಅಳೆಯಬಹುದಾದ ಮೂಲಸೌಕರ್ಯವಾಗಿ (measured infrastructure) ಪರಿಗಣಿಸುವುದು. ನಾವು ಏನು ಬದಲಾಯಿಸಿದೆವು ಮತ್ತು 95ನೇ ಪರ್ಸೆಂಟೈಲ್ ಲೇಟೆನ್ಸಿಯನ್ನು (95th-percentile latency) 850 ms ನಿಂದ 320 ms ಗೆ ಇಳಿಸುವಾಗ ರಿಕಾಲ್ ಅನ್ನು (recall) ಹೇಗೆ ಶೇಕಡಾ 95ಕ್ಕೆ ಏರಿಸಿದೆವು ಎಂಬ ವಿವರ ಇಲ್ಲಿದೆ.
ಸ್ಥಿರ ಚಂಕ್ಗಳ ಬಲೆ (The Fixed-Chunk Trap)
ಏಕರೂಪದ ಟೋಕನ್ ಸಂಖ್ಯೆಗಳನ್ನು ಕೋಡ್ ಮಾಡುವುದು ಮತ್ತು ವಿವರಿಸುವುದು ಸುಲಭ. ಆದರೆ ಆ ಅನುಕೂಲವು ಒಂದು ಮೂಲಭೂತ ಸತ್ಯವನ್ನು ಮರೆಮಾಚುತ್ತದೆ: ದಾಖಲೆಗಳು ಒಂದು ನಿರ್ದಿಷ್ಟ ರಚನೆಯನ್ನು ಹೊಂದಿರುತ್ತವೆ. ನೀವು ಆ ರಚನೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದಾಗ, ನೀವು ಮಾಹಿತಿಯ ಸಾರವನ್ನು (signal) ನಾಶಪಡಿಸುತ್ತೀರಿ.
ಹತ್ತು ಪುಟಗಳ ಮಾಸ್ಟರ್ ಸರ್ವಿಸ್ ಅಗ್ರಿಮೆಂಟ್ ಅನ್ನು ಪರಿಗಣಿಸಿ. 512-ಟೋಕನ್ನ ಸ್ಥಿರ ವಿಭಾಗವು ಒಂದು ಬಾಧ್ಯತೆಯ (obligation) ಮಧ್ಯಭಾಗದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳಬಹುದು, ಇದರಿಂದ ಒಂದು ಕಲೌಸ್ ಅನ್ನು ಅದನ್ನು ನಿಯಂತ್ರಿಸುವ ಕ್ಯಾಪ್ ಟೇಬಲ್ನಿಂದ ಬೇರ್ಪಡಿಸಬಹುದು. ಆಗ ರಿಟ್ರಿೀವಲ್ ಹಂತವು ಅರ್ಧಂಬರ್ಧ ಮಾಹಿತಿಯನ್ನು ಮಾತ್ರ ನೀಡುತ್ತದೆ. ನಂತರದ ಜನರೇಟರ್ ಉಳಿದ ಮಾಹಿತಿಯನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳುತ್ತದೆ (hallucinates). API ಡಾಕ್ಯುಮೆಂಟೇಶನ್ನಲ್ಲಿ, ಅತಿಯಾದ ದೊಡ್ಡ ಚಂಕ್ ಮಾಹಿತಿಯನ್ನು ಬೋರಿಪ್ಲೇಟ್ (boilerplate) ಹೆಡರ್ಸ್ಗಳೊಂದಿಗೆ ಬೆರೆಸಿಬಿಡುತ್ತದೆ, ಇದರಿಂದ ಡೆವಲಪರ್ಗೆ ಬೇಕಾದ ನಿರ್ದಿಷ್ಟ ಮೆಥಡ್ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ಗಳಲ್ಲಿ, ಸ್ಥಿರ ವಿಂಡೋವು ಸಂಭಾಷಣೆಯನ್ನು ಕೇವಲ ವಾಕ್ಯಗಳ ಗುಂಪಿನಂತೆ ಪರಿಗಣಿಸುತ್ತದೆ, ಇದರಿಂದ ವಾಸ್ತವವಾಗಿ ಏನು ತಪ್ಪಾಗಿದೆ ಎಂದು ತಿಳಿಸುವ ಸಂಭಾಷಣೆಯ ಹರಿವನ್ನು ಅದು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.
ನಾವು ಚಂಕ್ ಗಾತ್ರವನ್ನು ಕೇವಲ ಅಂದಾಜಿಸುವ ಹೈಪರ್ಪ್ಯಾರಾಮೀಟರ್ (hyperparameter) ಎಂದು ಪರಿಗಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆವು. ಬದಲಾಗಿ, ದಾಖಲೆಯ ಪ್ರಕಾರ ಮತ್ತು ಅದರೊಳಗಿನ ಮಾಹಿತಿ ವಿನ್ಯಾಸದ (information architecture) ನಡುವಿನ ಮ್ಯಾಪಿಂಗ್ ವ್ಯಾಯಾಮವಾಗಿ ಅದನ್ನು ನೋಡಲು ಪ್ರಾರಂಭಿಸಿದೆವು.
ನಿಮ್ಮ ಚಂಕಿಂಗ್ ಅನ್ನು ಡೇಟಾಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಹೊಂದಿಸಿ
ಪರಿಹಾರವು ಒಂದೇ ಒಂದು ಪರಿಪೂರ್ಣ ಚಂಕ್ ಗಾತ್ರದಲ್ಲಿಲ್ಲ. ಬದಲಾಗಿ, ಮೂರು ವಿಭಿನ್ನ ಡೇಟಾ ವಿನ್ಯಾಸಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ರೂಪಿಸಲಾದ ಮೂರು ವಿಭಿನ್ನ ತಂತ್ರಗಳಲ್ಲಿದೆ.
ಕಾನೂನು ದಾಖಲೆಗಳು (Legal documents) ಈಗ ರಿಕರ್ಸಿವ್ ಸ್ಪ್ಲಿಟಿಂಗ್ (recursive splitting) ಮೂಲಕ ಹಾದುಹೋಗುತ್ತವೆ. ಅಲ್ಗಾರಿದಮ್ ಮೊದಲು ದೊಡ್ಡ ನೈಸರ್ಗಿಕ ಗಡಿಗಳನ್ನು—ಸೆಕ್ಷನ್ಗಳು, ನಂತರ ಸಬ್ಸೆಕ್ಷನ್ಗಳು, ನಂತರ ಸಂಖ್ಯೆಯುಳ್ಳ ಕಲೌಸ್ಗಳನ್ನು—ಹುಡುಕುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ ಸಣ್ಣ ವಿಭಾಗಗಳಿಗೆ ಹೋಗುತ್ತದೆ. ಇದು ಒಂದು ಟರ್ಮಿನೇಷನ್ ಕಲೌಸ್ ಅನ್ನು ಅದರ ಅಸ್ತಿತ್ವದ ಷರತ್ತುಗಳೊಂದಿಗೆ ಜೋಡಿಸಿಡುತ್ತದೆ. ಇದರಿಂದ ರಿಟ್ರಿೀವಲ್ ಹಂತವು ಸಂಪೂರ್ಣ ತಾರ್ಕಿಕ ಘಟಕಗಳನ್ನು ನೋಡುತ್ತದೆ, ಇದು ಮಾಡೆಲ್ ತಪ್ಪು ಮಾಹಿತಿಯನ್ನು ಸೃಷ್ಟಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
API ಮತ್ತು ಕೋಡ್ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ರಚನೆಗೆ ಅರಿವಿರುವ ಚಂಕಿಂಗ್ (structure-aware chunking) ಅನ್ನು ಪಡೆಯುತ್ತವೆ. ಮಾರ್ಕ್ಡೌನ್ ಹೆಡರ್ಗಳು, ಕೋಡ್ ಫೆನ್ಸ್ಗಳು ಮತ್ತು ಪ್ಯಾರಾಮೀಟರ್ ಟೇಬಲ್ಗಳನ್ನು ಅಟಾಮಿಕ್ ಘಟಕಗಳಾಗಿ ವಿಶ್ಲೇಷಿಸಲಾಗುತ್ತದೆ. ನಾವು ಕೋಡ್ ಬ್ಲಾಕ್ನ ಒಳಗೆ ವಿಭಜಿಸುವುದಿಲ್ಲ. ನಾವು ಡಾಕ್ಸ್ಟ್ರಿಂಗ್ಗಳನ್ನು (docstrings) ಅವುಗಳ ಸಿಗ್ನೇಚರ್ಗಳ ಪಕ್ಕದಲ್ಲೇ ಇರಿಸುತ್ತೇವೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಒಂದು ನಿರ್ದಿಷ್ಟ ಕ್ಲಾಸ್ ಮೆಥಡ್ ಬಗ್ಗೆ ಕೇಳಿದಾಗ ಡೆವಲಪರ್ಗೆ ಬೇಕಾದ ಸಂಪೂರ್ಣ ಸಂದರ್ಭವನ್ನು (context) ಇದು ನೀಡುತ್ತದೆ: ವಿವರಣೆ, ಟೈಪ್ ಮಾಡಿದ ಪ್ಯಾರಾಮೀಟರ್ಗಳು ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ಉದಾಹರಣೆ.
ಸಪೋರ್ಟ್ ಮತ್ತು ಸಂಭಾಷಣಾ ಡೇಟಾ (Support and conversational data) ಸೆಮ್ಯಾಂಟಿಕ್ ಚಂಕಿಂಗ್ ಅನ್ನು ಬಳಸುತ್ತವೆ. ಟೋಕನ್ಗಳನ್ನು ಎಣಿಸುವ ಬದಲು, ನಾವು ವಿಷಯ ಅಥವಾ ಉದ್ದೇಶದ ಬದಲಾವಣೆಗಳನ್ನು ಗಮನಿಸುತ್ತೇವೆ. ಗ್ರಾಹಕರು ಮೂರನೇ ಸಂದೇಶದಲ್ಲಿ ಬಗ್ ಅನ್ನು ವಿವರಿಸಿದರೆ ಮತ್ತು ಏಳನೇ ಸಂದೇಶದಲ್ಲಿ ಸ್ಟ್ಯಾಕ್ ಟ್ರೇಸ್ ಅನ್ನು ಪೇಸ್ಟ್ ಮಾಡಿದರೆ, ನಾವು ಸಂದೇಶದ ಇಂಡೆಕ್ಸ್ ಮೂಲಕ ಅಲ್ಲದೆ, ಅರ್ಥದ ಮೂಲಕ ಚಂಕ್ ಮಾಡುತ್ತೇವೆ. ಆಗ ರಿಟ್ರಿೀವಲ್ ಲೇಯರ್ ಕೇವಲ ಒಂದು ವಾಕ್ಯವನ್ನು ನೀಡುವ ಬದಲು ಸಮಸ್ಯೆಯ ಸಂಪೂರ್ಣ ಚಿತ್ರಣವನ್ನು ನೀಡುತ್ತದೆ.
ಕೇವಲ ವೆಕ್ಟರ್ ಸರ್ಚ್ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ
ಪರಿಪೂರ್ಣ ಚಂಕ್ಗಳಿದ್ದರೂ ಸಹ ಕೇವಲ ವೆಕ್ಟರ್ ಸರ್ಚ್ನಲ್ಲಿ ಅವು ವಿಫಲವಾಗಬಹುದು. ಡೆನ್ಸ್ ಎಂಬೆಡ್ಡಿಂಗ್ಗಳು (Dense embeddings) ಅರ್ಥ ಮತ್ತು ಸಮಾನಾರ್ಥಕ ಪದಗಳನ್ನು ಹಿಡಿಯುವಲ್ಲಿ ಉತ್ತಮವಾಗಿವೆ, ಆದರೆ ನಿಖರವಾದ ಸ್ಟ್ರಿಂಗ್ಗಳ ವಿಷಯದಲ್ಲಿ ಅವು ಅಸ್ಪಷ್ಟವಾಗಿರುತ್ತವೆ. ಒಬ್ಬ ಇಂಜಿನಿಯರ್ ನಿಖರವಾದ ಎರರ್ ಕೋಡ್ ERR_CONNECTION_REFUSED ಅನ್ನು ಹುಡುಕಿದರೆ, ವೆಕ್ಟರ್ ಸಿಮಿಲಾರಿಟಿ ಹತ್ತר ಸಂಬಂಧವಿರುವ ಹನ್ನೆರಡು ವಿಷಯಗಳನ್ನು ನೀಡಬಹುದು ಮತ್ತು 14ನೇ ರ್ಯಾಂಕ್ನಲ್ಲಿರುವ ನಿಖರವಾದ ಹೊಂದಾಣಿಕೆಯನ್ನು ತಪ್ಪಿಸಬಹುದು.
BM25 ನೊಂದಿಗೆ ಕೀವರ್ಡ್ ಸರ್ಚ್ ಮಾಡುವುದರಿಂದ ವಿರುದ್ಧವಾದ ಸಮಸ್ಯೆ ಎದುರಾಗುತ್ತದೆ. ಇದು ನಿಖರವಾದ ಟೋಕನ್ಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ ಆದರೆ ಅರ್ಥದ ಉದ್ದೇಶವನ್ನು (semantic intent) ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತದೆ. "ನನ್ನ ಡೇಟಾಬೇಸ್ ಏಕೆ ಡೌನ್ ಆಗಿದೆ" ಎಂದು ಕೇಳುವ ಬಳಕೆದಾರರಿಗೆ "troubleshooting connection timeouts" ಎಂದು ಹೇಳುವ ದಾಖಲೆಯು ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.
ನಾವು ಈಗ ಎರಡನ್ನೂ ಬಳಸುತ್ತಿದ್ದೇವೆ. ವೆಕ್ಟರ್ ಮತ್ತು ಕೀವರ್ಡ್ ಫಲಿತಾಂಶಗಳನ್ನು Reciprocal Rank Fusion ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಇದು ಕ್ಯಾಲಿಬ್ರೇಟೆಡ್ ಸ್ಕೋರ್ಗಳ ಅಗತ್ಯವಿಲ್ಲದೆ ಎರಡು ರ್ಯಾಂಕ್ ಮಾಡಿದ ಪಟ್ಟಿಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತದೆ. ನಂತರ ಈ ಸಂಯೋಜಿತ ಪಟ್ಟಿಯನ್ನು cross-encoder reranker ಮೂಲಕ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಈ reranker ಆರಂಭಿಕ ರಿಟ್ರಿೀವಲ್ ಗಿಂತ ನಿಧಾನವಾಗಿದ್ದರೂ, ಇದು ಕಾಂಪ್ರೆಸ್ ಮಾಡಿದ ಎಂಬೆಡ್ಡಿಂಗ್ಗಳ ಮೂಲಕ ಅಲ್ಲದೆ, ಕ್ವೆರಿ-ಡಾಕ್ಯುಮೆಂಟ್ ಸಂಬಂಧವನ್ನು ನೇರವಾಗಿ ನಿರ್ಧರಿಸುವುದರಿಂದ ಹೆಚ್ಚು ನಿಖರವಾಗಿರುತ್ತದೆ. ಈ ಹೈಬ್ರಿಡ್ ಪೈಪ್ಲೈನ್ ನಮ್ಮ ರಿಕಾಲ್ ಅನ್ನು ಶೇಕಡಾ 15 ರಷ್ಟು ಹೆಚ್ಚಿಸಿತು.
ಕೆಟ್ಟ ಕ್ವೆರಿಗಳು ಇಂಡೆಕ್ಸ್ ತಲುಪುವ ಮೊದಲೇ ಅವುಗಳನ್ನು ಸರಿಪಡಿಸುವುದು
ಬಳಕೆದಾರರು ಆದರ್ಶದ ಹುಡುಕಾಟದ ಪ್ರಶ್ನೆಗಳನ್ನು (search queries) ಬರೆಯುವುದಿಲ್ಲ. ಅವರು ಅಪೂರ್ಣವಾದ ಲಾಗ್ ಸಾಲುಗಳನ್ನು (log lines) ಪೇಸ್ಟ್ ಮಾಡುತ್ತಾರೆ. "ಇದು ಕೆಟ್ಟುಹೋಗಿದೆ" ಎಂದು ಟೈಪ್ ಮಾಡುತ್ತಾರೆ. ನಿಮ್ಮ ದಾಖಲಾತಿಗಳಲ್ಲಿ (documentation) ಎಂದೂ ಬಳಸದ ತಾಂತ್ರಿಕ ಪದಗಳನ್ನು (jargon) ಬಳಸುತ್ತಾರೆ. ನೀವು ಕೇವಲ ಮೂಲ ಪ್ರಶ್ನೆಯನ್ನೇ ನಂಬಿದರೆ, ನೀವು ಕೇವಲ ಗೊಂದಲವನ್ನೇ (noise) ನಂಬಿದಂತಾಗುತ್ತದೆ.
ನಾವು ಈಗ ಪ್ರತಿಯೊಂದು ಬರುವ ಪ್ರಶ್ನೆಯನ್ನು ರಿಟ್ರಿವಲ್ ಲೇಯರ್ಗೆ (retrieval layer) ಕಳುಹಿಸುವ ಮೊದಲು ಮೂರುದಿಂದ ಐದು ವಿಧದ ರೂಪಾಂತರಗಳಾಗಿ ವಿಸ್ತರಿಸುತ್ತೇವೆ. ಒಂದು ರೂಪಾಂತರವು ನೇರವಾದ ಸಮಾನಾರ್ಥಕ ಪದಗಳಾಗಿರಬಹುದು (paraphrase). ಇನ್ನೊಂದು ಒಂದು ಕಾಲ್ಪನಿಕ ಆದರ್ಶ ದಾಖಲೆಯ ಶೀರ್ಷಿಕೆಯಾಗಿರಬಹುದು. ಮೂರನೆಯದು ಸಂಭಾಷಣೆಯ ಅನಗತ್ಯ ಪದಗಳನ್ನು ತೆಗೆದುಹಾಕಿ ತಾಂತ್ರಿಕ ಕೀವರ್ಡ್ಗಳನ್ನು (technical keywords) ಮಾತ್ರ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ರೂಪಾಂತರವನ್ನು ಎಂಬೆಡ್ (embed) ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಹುಡುಕಲಾಗುತ್ತದೆ. ನಂತರ ನಾವು ಅಭ್ಯರ್ಥಿ ಪಟ್ಟಿಯನ್ನು (candidate pools) ಡ್ಯೂಡ್ಯೂಪ್ಲಿಕೇಟ್ (deduplicate) ಮಾಡಿ ವಿಲೀನಗೊಳಿಸುತ್ತೇವೆ.
ಇದು ಉಚಿತವಲ್ಲ. ಆ ಹೆಚ್ಚುವರಿ ಎಂಬೆಡ್ಡಿಂಗ್ ಕರೆಗಳು (embedding calls) ಹಣವನ್ನು ಖರ್ಚು ಮಾಡುತ್ತವೆ ಮತ್ತು ಕೆಲವು ಮಿಲಿಸೆಕೆಂಡ್ಗಳನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ. ಆದರೆ ರಿಕಾಲ್ (recall) ಮೇಲೆ ಇದರ ಪರಿಣಾಮವು ಅದ್ಭುತವಾಗಿತ್ತು: ರಿಟ್ರಿವಲ್ ಮಾಡುವ ಮೊದಲು ಪ್ರಶ್ನೆಗಳನ್ನು ವಿಸ್ತರಿಸುವ ಮೂಲಕ ನಾವು 78 ಪ್ರತಿಶತದಿಂದ 96 ಪ್ರತಿಶತಕ್ಕೆ ಏರಿದೆವು. ಉತ್ತಮ ರಿಟ್ರಿವಲ್ ಮಾಡುವುದರಿಂದ ಜನರೇಷನ್ ವಿಂಡೋ (generation window) ಕಡಿಮೆಯಾಗುತ್ತದೆ ಮತ್ತು ಮಾಡೆಲ್ ಸರಿಯಾದ ಸಂದರ್ಭದಲ್ಲಿ (context) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದರಿಂದ ನಾವು ಮುಂದಿನ ಹಂತಗಳಲ್ಲಿ ಹಣವನ್ನು ಉಳಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಸ್ವಲ್ಪ ಹೆಚ್ಚು ವೆಚ್ಚದ ರಿಟ್ರಿವಲ್ ಹಂತವು, ದೀರ್ಘವಾದ ಮತ್ತು ತಪ್ಪು ಮಾಹಿತಿ ನೀಡುವ (hallucinated) ಜನರೇಷನ್ ಹಂತಕ್ಕಿಂತ ಹೆಚ್ಚು ಅಗ್ಗವಾಗಿದೆ.
ಊಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಹುಡುಕಾಟವನ್ನು ಪ್ರಾರಂಭಿಸಿ.
ನಾವು ಸರಿಯಾದ ಚಂಕಿಂಗ್ (chunking), ಹೈಬ್ರಿಡ್ ರಿಟ್ರಿವಲ್ (hybrid retrieval) ಮತ್ತು ಕ್ವೆರಿ ಎಕ್ಸ್ಪಾನ್ಶನ್ (query expansion) ಅನ್ನು ಅಳವಡಿಸಿಕೊಂಡ ನಂತರವೂ, ನಮಗೆ ಸಂಕೀರ್ಣವಾದ ಸಮಸ್ಯೆ ಎದುರಾಯಿತು. ಚಂಕ್ ಗಾತ್ರ (chunk size), ಚಂಕ್ ಓವರ್ಲ್ಯಾಪ್ (chunk overlap), top-k ರಿಟ್ರಿವಲ್ ಆಳ (depth), reranker ಕಟ್ಆಫ್ಗಳು ಮತ್ತು ಫ್ಯೂಷನ್ ತೂಕಗಳು (fusion weights) ಎಲ್ಲವೂ ಒಂದಕ್ಕೊಂದು ಸಂಬಂಧಿಸಿವೆ. ಮ್ಯಾನುಯಲ್ ಗ್ರಿಡ್ ಸರ್ಚ್ (manual grid search) ಮಾಡಲು ವಾರಗಟ್ಟಲೆ ಬೇಕಾಗುತ್ತಿತ್ತು ಮತ್ತು ಅದು ನಮಗೆ ಕೇವಲ ಸೀಮಿತ ಫಲಿತಾಂಶವನ್ನೇ ನೀಡುತ್ತಿತ್ತು.
ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ನಾವು ಬೇಯೇಶಿಯನ್ ಆಪ್ಟಿಮೈಸೇಶನ್ (Bayesian optimization) ಅನ್ನು ಬಳಸಿದೆವು. ಪ್ರತಿಯೊಂದು ಸಂಯೋಜನೆಯನ್ನು (combination) ಪರೀಕ್ಷಿಸುವ ಬದಲು, ಈ ಸರ್ಚ್ ಅಲ್ಗಾರಿದಮ್ ಯಾವ ಕಾನ್ಫಿಗರೇಶನ್ಗಳು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು ಎಂಬ ನಂಬಿಕೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಕ್ರಮೇಣ ಭರವಸೆಯಿರುವ ಪ್ರದೇಶಗಳತ್ತ ಗಮನಹರಿಸುತ್ತದೆ.
ಇದರ ಫಲಿತಾಂಶವು ಕೇವಲ ಒಂದು ಪರಿಪೂರ್ಣ ಸೆಟ್ಟಿಂಗ್ ಆಗಿರುವುದಿಲ್ಲ. ಇದು ಆಯ್ಕೆಗಳ ಪ್ಯಾರೆಟೊ ಫ್ರಾಂಟಿಯರ್ (Pareto frontier) ಆಗಿದೆ. ಒಂದು ಕಡೆ, ನಮ್ಮ ಹೈ-ಥ್ರೂಪುಟ್ API ಸಪೋರ್ಟ್ ಎಂಡ್ಪಾಯಿಂಟ್ಗಾಗಿ (high-throughput API support endpoint) ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾದ ಲೀನ್ ಕಾನ್ಫಿಗರೇಶನ್ ಇದೆ: ವೇಗದ ಇನ್ಫರೆನ್ಸ್ (inference), ಸಾಧಾರಣ ರಿಕಾಲ್ ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ವಿಳಂಬ (latency). ಇನ್ನೊಂದು ಕಡೆ, ಕಾನೂನು ವಿಮರ್ಶೆಗಾಗಿ (legal review) ಒಂದು ಅಗ್ರೆಸಿವ್ ಕಾನ್ಫಿಗರೇಶನ್ ಇದೆ: ಆಳವಾದ ರಿಟ್ರಿವಲ್, ಹೆಚ್ಚಿನ reranking ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಾದ ಓವರ್ಲ್ಯಾಪ್, ಅಂದರೆ ನಿಖರತೆಗಾಗಿ ನಾವು ಮಿಲಿಸೆಕೆಂಡ್ಗಳನ್ನು ಬಲಿದಾನ ಮಾಡುತ್ತೇವೆ. ಈ ಫ್ರಾಂಟಿಯರ್ ಸ್ಪಷ್ಟವಾಗಿರುವುದರಿಂದ, "ಎಲ್ಲರಿಗೂ ಒಂದೇ ಮಾದರಿ" ಎಂದು giả giả ಮಾಡಿಕೊಳ್ಳುವ ಬದಲು, ಉತ್ಪನ್ನಕ್ಕೆ ಸೂಕ್ತವಾದ ಪಾಯಿಂಟ್ ಅನ್ನು ನಾವು ಆಯ್ಕೆ ಮಾಡಬಹುದು.
ಅಂಕಿಅಂಶಗಳು ವಾಸ್ತವವಾಗಿ ಹೇಗಿವೆ
ಈ ಬದಲಾವಣೆಗಳು ವ್ಯವಸ್ಥೆಯನ್ನು ಅಸ್ಥಿರವಾದ ಪ್ರೊಟೊಟೈಪ್ನಿಂದ (prototype) ಅಳತೆ ಮಾಡಬಹುದಾದ ಪ್ರೊಡಕ್ಷನ್ ಪೈಪ್ಲೈನ್ಗೆ (production pipeline) ಬದಲಾಯಿಸಿದವು.
- 'Recall at ten' 78 ಪ್ರತಿಶತದಿಂದ 95 ಪ್ರತಿಶತಕ್ಕೆ ಸುಧಾರಿಸಿತು. ಅಂದರೆ ನಮ್ಮ ಕಾರ್ಪಸ್ನಲ್ಲಿ (corpus) ಸರಿಯಾದ ಉತ್ತರವಿದ್ದಾಗ, ನಾವು ಇಪ್ಪತ್ತರಲ್ಲಿ ಹತ್ತೊಂಬತ್ತು ಬಾರಿ ಅದನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ.
- 95ನೇ ಪರ್ಸೆಂಟೈಲ್ನಲ್ಲಿ (95th percentile) ವಿಳಂಬವು (latency) 850 ms ನಿಂದ 320 ms ಗೆ ಇಳಿಕೆಯಾಯಿತು. ಹೈಬ್ರಿಡ್ ಸ್ಟ್ಯಾಕ್ ಕಾಗದದ ಮೇಲೆ ಭಾರವಾಗಿ ಕಂಡರೂ, ಸ್ಮಾರ್ಟ್ ಇಂಡೆಕ್ಸಿಂಗ್, ಸಣ್ಣ rerankers ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ ಅಗ್ರೆಸಿವ್ ಚಂಕ್ಗಳನ್ನು ನೀಡುವ ಸಾಮರ್ಥ್ಯವು ಇಡೀ ವ್ಯವಸ್ಥೆಯನ್ನು ವೇಗಗೊಳಿಸಿತು.
- ಹ್ಯಾಲ್ಯುಸಿನೇಶನ್ ದರ (Hallucination rate)—ಇದನ್ನು ಗೋಲ್ಡನ್ ಡೇಟಾಸೆಟ್ನಲ್ಲಿ ಮಾನವ ಅಸೋಸಿಯೇಟರ್ಗಳು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತಾರೆ—12 ಪ್ರತಿಶತದಿಂದ 3 ಪ್ರತಿಶತಕ್ಕೆ ಇಳಿಕೆಯಾಯಿತು. ಮಾಡೆಲ್ಗೆ ಸಂಪೂರ್ಣ ಮತ್ತು ಸಂಬಂಧಿತ ಸಂದರ್ಭ (context) ಸಿಕ್ಕಾಗ, ಅದು ತಪ್ಪು ಮಾಹಿತಿಗಳನ್ನು ಸೃಷ್ಟಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.
- ಪ್ರತಿ ಕ್ವೆರಿ ವೆಚ್ಚವು $0.008 ರಿಂದ $0.005 ಕ್ಕೆ ಇಳಿಕೆಯಾಯಿತು. ಉತ್ತಮ ರಿಟ್ರಿವಲ್ ಎಂದರೆ ಚಿಕ್ಕದಾದ ಮತ್ತು ಹೆಚ್ಚು ಕೇಂದ್ರೀಕೃತವಾದ LLM ಪ್ರಾಂಪ್ಟ್ಗಳು ಮತ್ತು ಕಡಿಮೆ ರಿಕವರಿ ಪ್ರಯತ್ನಗಳು ಎಂದರ್ಥ. ಕ್ವೆರಿ ಎಕ್ಸ್ಪಾನ್ಶನ್ಗಾಗಿ ಮಾಡುವ ಹೆಚ್ಚುವರಿ ಎಂಬೆಡ್ಡಿಂಗ್ ವೆಚ್ಚವು, ಜನರೇಷನ್ನಲ್ಲಿ ಆಗುವ ಉಳಿತಾಯಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಅತ್ಯಲ್ಪವಾಗಿದೆ.
ಗೋಲ್ಡನ್ ಡೇಟಾಸೆಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿ ಮತ್ತು ರಿಟ್ರಿವಲ್ ಅನ್ನು ಕೋಡ್ನಂತೆ ಪರಿಗಣಿಸಿ
ನೀವು ಇದರಲ್ಲಿ ಒಂದು ವಿಷಯವನ್ನು ಕಲಿಯಬೇಕೆಂದರೆ, ಅದು ಅಳತೆ ಮಾಡುವ ಶಿಸ್ತು (discipline of measurement). ನಾವು ನೈಜ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ದೃಢೀಕರಿಸಿದ ಉತ್ತರಗಳ ಸ್ಥಳಗಳನ್ನು ಒಳಗೊಂಡ ಸಣ್ಣ ಗೋಲ್ಡನ್ ಡೇಟಾಸೆಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ. ಯಾವುದೇ ಬದಲಾವಣೆ ಪ್ರೊಡಕ್ಷನ್ಗೆ ಹೋಗುವ ಮೊದಲು, ಅದು ಆ ಡೇಟಾಸೆಟ್ ಮೇಲೆ ಪರೀಕ್ಷಿಸಲ್ಪಡುತ್ತದೆ. ರಿಕಾಲ್ ಮತ್ತು ವಿಳಂಬವನ್ನು (latency) ನೈಜ ಸಮಯದಲ್ಲಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುತ್ತದೆ, ಕೇವಲ ನೋಟ್ಬುಕ್ನಲ್ಲಿ ನೋಡಿ ನಿರ್ಧರಿಸಲಾಗುವುದಿಲ್ಲ.
ರಿಟ್ರಿವಲ್ ಎಂಬುದು ಕೇವಲ ಸಂಶೋಧನಾ ಪ್ರದರ್ಶನವಲ್ಲ (research demo). ಇದು ಮೂಲಸೌಕರ್ಯ (infrastructure). ನಿಮ್ಮ ಸ್ಟ್ಯಾಕ್ನ ಉಳಿದ ಭಾಗಗಳಂತೆ ಇದು ಕೂಡ ಯೂನಿಟ್ ಟೆಸ್ಟ್ಗಳು (unit tests), ರಿಗ್ರೆಷನ್ ಬೆಂಚ್ಮಾರ್ಕ್ಗಳು (regression benchmarks) ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಆಪ್ಟಿಮೈಸೇಶನ್ಗೆ ಅರ್ಹವಾಗಿದೆ. ಚಂಕ್ಗಳನ್ನು ಟೋಕನ್ ಆಧಾರದ ಮೇಲಿನ ಅಂಧಶ್ರದ್ಧೆಯ ಬದಲಿಗೆ ದಾಖಲೆಯ ರಚನೆಯ ಆಧಾರದ ಮೇಲೆ ಮಾಡಿ. ವೆಕ್ಟರ್ ಮತ್ತು ಕೀವರ್ಡ್ ಸರ್ಚ್ ಅನ್ನು reranker ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಿ. ನಿಮ್ಮ ಬಳಕೆದಾರರು ಬರೆಯುವ ಪ್ರಶ್ನೆಗಳನ್ನು ವಿಸ್ತರಿಸಿ. ನಂತರ ನಿಮ್ಮ ಅಂತಃಪ್ರಜ್ಞೆಯ ಬದಲಿಗೆ (intuition) ಒಂದು ಸರ್ಚ್ ಅಲ್ಗಾರಿದಮ್ ಮೂಲಕ ಅದನ್ನು ಟ್ಯೂನ್ ಮಾಡಿ.
ನಾವು ವಿವರಿಸಿದ ಪೈಪ್ಲೈನ್ ಕೇವಲ ಸೈದ್ಧಾಂತಿಕವಾದುದಲ್ಲ. ನೀವು ಮೂಲ ಲೇಖನವನ್ನು ಇಲ್ಲಿ ಓದಬಹುದು, ಮತ್ತು ನೀವು ಈ ವಿಷಯದಲ್ಲಿ ಆಸಕ್ತಿ ಇರುವ ಸಮುದಾಯದೊಂದಿಗೆ ರಿಟ್ರಿವಲ್ ಇಂಜಿನಿಯರಿಂಗ್ ಬಗ್ಗೆ ಚರ್ಚಿಸಲು ಬಯಸಿದರೆ, GyaanSetu AI group ತೆರೆದಿದೆ.