ಹೆಚ್ಚಿನ RAG ಪ್ರೊಟೊಟೈಪ್ಗಳು ಒಳಗಿನಿಂದ ನೋಡಿದಾಗ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ. ಯಾರೋ ಒಬ್ಬರು ಒಂದು PDF ಅನ್ನು ಪೈಪ್ಲೈನ್ಗೆ ಹಾಕುತ್ತಾರೆ, ಪಠ್ಯವನ್ನು 512-ಟೋಕನ್ ಚಂಕ್ಗಳಾಗಿ (chunks) ವಿಭಜಿಸುತ್ತಾರೆ, ಅವುಗಳನ್ನು ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ಗೆ ಹಾಕುತ್ತಾರೆ ಮತ್ತು ಕೆಲಸ ಮುಗಿದಿದೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಒಂದು ಪ್ರಾಥಮಿಕ ಪ್ರದರ್ಶನಕ್ಕೆ (hallway demo) ಇದು ಆಕರ್ಷಕವಾಗಿ ಕಾಣಬಹುದು. ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಇದು ವಿಫಲವಾಗುತ್ತದೆ.
ಒಂದು ಸ್ಥಿರವಾದ ಚಂಕ್ (fixed chunk) ಅದು ಏನನ್ನು ಕತ್ತರಿಸುತ್ತಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ತಲೆಕೆಡಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಅದು ಕಾನೂನು ಒಪ್ಪಂದವನ್ನು (legal contract) ಇಂಡೆಮ್ನಿಟಿ ಕ್ಲಾಸ್ನ (indemnity clause) ಮಧ್ಯದಲ್ಲೇ ವಿಭಜಿಸಬಹುದು. ಇದು ಐದು ಸಂಬಂಧವಿಲ್ಲದ API ಎಂಡ್ಪಾಯಿಂಟ್ಗಳನ್ನು ಒಂದೇ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋಗೆ ತುಂಬಿ ಮಾಡೆಲ್ ಅನ್ನು ಗೊಂದಲಕ್ಕೆ ದೂಡಬಹುದು. ಇದು ಅಗತ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಫ್ರಾಗ್ಮೆಂಟ್ಗಳನ್ನು (fragments) ಹುಡುಕುವಂತೆ ಮಾಡುತ್ತದೆ, ಇದರಿಂದ ಲೇಟೆನ್ಸಿ (latency) ಹೆಚ್ಚಾಗುತ್ತದೆ ಮತ್ತು ಟೋಕನ್ಗಳು ವ್ಯರ್ಥವಾಗುತ್ತವೆ. ಇದರ ಪರಿಣಾಮವೆಂದರೆ ಅರ್ಧಂಬರ್ಧ ಉತ್ತರಗಳು, ಹ್ಯಾಲ್ಯುಸಿನೇಷನ್ಗಳು (hallucinations) ಮತ್ತು ಅಸಮಾಧಾನಗೊಂಡ ಬಳಕೆದಾರರು.
ನಾವು ನಮ್ಮ ರಿಟ್ರಿೀವಲ್ ಲೇಯರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮರುನಿರ್ಮಿಸಿದೆವು. ಇದರ ಫಲಿತಾಂಶವೆಂದರೆ 40 ಪ್ರತಿಶತಷ್ಟು ಲೇಟೆನ್ಸಿಯನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಮೂಲಕ 95 ಪ್ರತಿಶತದಷ್ಟು ರಿಕಾಲ್ (recall) ಸಾಧಿಸಿದ ವ್ಯವಸ್ಥೆ. ನಾವು ಇದನ್ನು ನಿಖರವಾಗಿ ಹೇಗೆ ಮಾಡಿದೆವು ಎಂಬುದು ಇಲ್ಲಿದೆ.
ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಸ್ಥಿರ ಚಂಕ್ಗಳು (Fixed Chunks) ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ
512-ಟೋಕನ್ ಡಿಫಾಲ್ಟ್ ಎಂಬುದು ಯಾವುದೇ ವಿನ್ಯಾಸದ ಆಯ್ಕೆಯಲ್ಲ. ಇದು ಆರಂಭಿಕ ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋಗಳು ಮತ್ತು ಲೈಬ್ರರಿ ಡಿಫಾಲ್ಟ್ಗಳ ಉಪ ಉತ್ಪನ್ನವಾಗಿದೆ. ಇದನ್ನು ಅಳವಡಿಸುವುದು ಸುಲಭ, ಆದರೆ ಇದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗುವುದು ಅಪಾಯಕಾರಿ.
ದಾಖಲೆಗಳು ಏಕರೂಪವಾಗಿರುವುದಿಲ್ಲ. ಒಂದು ಕಾನೂನು ಕ್ಲಾಸ್ (legal clause) ಯಾವುದೇ ಸ್ಪಷ್ಟ ವಿರಾಮವಿಲ್ಲದೆ ಏಳು ನೂರು ಟೋಕನ್ಗಳವರೆಗೆ ಇರಬಹುದು. ಅದನ್ನು 512 ಟೋಕನ್ಗಳಲ್ಲಿ ವಿಭಜಿಸಿದರೆ, ನೀವು ಎರಡು ಅನಾಥ ಫ್ರಾಗ್ಮೆಂಟ್ಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತೀರಿ. ವಕೀಲರು ಅಥವಾ ಕಾಂಪ್ಲೈಯನ್ಸ್ ಆಫೀಸರ್ ಹೊಣೆಗಾರಿಕೆಯ ಮಿತಿಗಳ (liability caps) ಬಗ್ಗೆ ಕೇಳಿದಾಗ, ಸಿಸ್ಟಮ್ ಅರ್ಧದಷ್ಟು ಬಾಧ್ಯತೆಯನ್ನು ಮಾತ್ರ ನೀಡುತ್ತದೆ. ಭಾಷಾ ಮಾಡೆಲ್ (language model) ಕಣ್ಮರೆಯಾದ ಅರ್ಧದ ಭಾಗವನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳುತ್ತದೆ (hallucinates), ಅಥವಾ ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿ, ಅಂತಹ ಮಿತಿ ಅಸ್ತಿತ್ವದಲ್ಲೇ ಇಲ್ಲ ಎಂದು ನಿರಾಕರಿಸುತ್ತದೆ.
API ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಇದಕ್ಕೆ ವಿರುದ್ಧವಾದ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತದೆ. ಐದ ನೂರು ಟೋಕನ್ ಚಂಕ್ ಇಡೀ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ನುಂಗಬಹುದು: ಅಥೆಂಟಿಕೇಶನ್ ಹೆಡರ್ಗಳು (authentication headers), ಎರರ್ ಕೋಡ್ಗಳು, ರೇಟ್ ಲಿಮಿಟ್ಗಳು ಮತ್ತು ವೆಬ್ಹುಕ್ ಸ್ಕೀಮಾಗಳು. ಒಬ್ಬ ಡೆವಲಪರ್ AUTH_4027 ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಬೇಕೆಂದು ಕೇಳಿದಾಗ, ರಿಟ್ರೈವರ್ ಸಂಬಂಧವಿಲ್ಲದ ಫಂಕ್ಷನ್ಗಳ ಮಿಶ್ರಣವನ್ನು ನೀಡುತ್ತದೆ. ಮಾಡೆಲ್ಗೆ ಅವುಗಳನ್ನು ಸಾಮಾನ್ಯವಾದ ಗೊಂದಲವನ್ನಾಗಿ (generic mush) ಪರಿವರ್ತಿಸುವುದನ್ನು ಹೊರತುಪಡಿಸಿ ಬೇರೆ ದಾರಿಯಿಲ್ಲದಂತಾಗುತ್ತದೆ.
ಕೆಟ್ಟ ಚಂಕಿಂಗ್ ಲೇಟೆನ್ಸಿಯನ್ನು ಕೂಡ ಹೆಚ್ಚಿಸುತ್ತದೆ. ದುರ್ಬಲ ಫ್ರಾಗ್ಮೆಂಟ್ಗಳមាន ಅಂದರೆ ಒಂದು ವಿಷಯವನ್ನು ಕವರ್ ಮಾಡಲು ನಿಮಗೆ ದೊಡ್ಡ top-k ಅಗತ್ಯವಿರುತ್ತದೆ. ಹೆಚ್ಚು ಚಂಕ್ಗಳು ಎಂದರೆ ದೀರ್ಘವಾದ ಪ್ರಾಂಪ್ಟ್ಗಳು (prompts). ದೀರ್ಘವಾದ ಪ್ರಾಂಪ್ಟ್ಗಳು ಎಂದರೆ ನಿಧಾನವಾದ ಜನರೇಷನ್ ಮತ್ತು ಹೆಚ್ಚಿನ ಬಿಲ್ಗಳು. ಬಳಕೆದಾರರ ಅನುಭವವು ಹಂತಹಂತವಾಗಿ ಕುಸಿಯುತ್ತದೆ.
ಚಂಕ್ ಅನ್ನು ದಾಖಲೆಗೆ ಅನುಗುಣವಾಗಿ ಹೊಂದಿಸಿ
ನಾವು ಟೋಕನ್ಗಳನ್ನು ಎಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ ವಿಷಯವನ್ನು ಓದಲು ಪ್ರಾರಂಭಿಸಿದೆವು. ಸರಿಯಾದ ಚಂಕಿಂಗ್ ತಂತ್ರವು ಮೂಲದ ರಚನೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.
ಕಾನೂನು ದಾಖಲೆಗಳಿಗೆ (Legal documents) ಕ್ಲಾಸ್-ಅರಿವಿರುವ (clause-aware) ಗಡಿಗಳೊಂದಿಗೆ ರಿಕರ್ಸಿವ್ ಕ್ಯಾರೆಕ್ಟರ್ ಚಂಕಿಂಗ್ ಅಗತ್ಯವಿದೆ. ಸ್ಪ್ಲಿಟರ್ ಶ್ರೇಣೀಕೃತ ವ್ಯವಸ್ಥೆಯನ್ನು ಗೌರವಿಸುತ್ತದೆ: ಇದು ಮೊದಲು ಸೆಕ್ಷನ್ ಹೆಡರ್ಗಳನ್ನು, ನಂತರ ಸಂಖ್ಯೆಯುಳ್ಳ ಪ್ಯಾರಾಗಳನ್ನು ಮತ್ತು ನಂತರ ನೈಸರ್ಗಿಕ ವಾಕ್ಯ ವಿರಾಮಗಳನ್ನು ಹುಡುಕುತ್ತದೆ. ಇದು ಎಂದಿಗೂ ಸಬ್-ಕ್ಲಾಸ್ ಅನ್ನು ಕತ್ತರಿಸುವುದಿಲ್ಲ ಅಥವಾ ಒಂದು ಬಾಧ್ಯತಾ ವಾಕ್ಯವನ್ನು ಚಂಕ್ಗಳ ನಡುವೆ ವಿಭಜಿಸುವುದಿಲ್ಲ. ನೀವು ಇಂಡೆಮ್ನಿಫಿಕೇಶನ್ ಬಗ್ಗೆ ಒಂದು ಭಾಗವನ್ನು ರಿಟ್ರೀವ್ ಮಾಡಿದಾಗ, ನೀವು ಪೂರ್ಣ ಕ್ಲಾಸ್, ಮಿತಿ ಮತ್ತು ವಿನಾಯಿತಿಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ.
API ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ರಚನೆ-ಅರಿವಿರುವ (structure-aware) ಚಂಕಿಂಗ್ ಅನ್ನು ಬಯಸುತ್ತದೆ. ನಾವು ಟೋಕನ್ ಬಜೆಟ್ ಮೂಲಕ ಅಲ್ಲದೆ, ಫಂಕ್ಷನ್ ವ್ಯಾಖ್ಯಾನದ (function definition) ಮೂಲಕ ಪಾರ್ಸ್ ಮಾಡುತ್ತೇವೆ. ಪ್ರತಿ ಚಂಕ್ ಸಂಪೂರ್ಣ ಫಂಕ್ಷನ್ ಸಿಗ್ನೇಚರ್, ಅದರ ಪ್ಯಾರಾಮೀಟರ್ ವಿವರಣೆಗಳು ಮತ್ತು ತಕ್ಷಣದ ಎರರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ನೋಟ್ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಒಬ್ಬ ಡೆವಲಪರ್ ನಿರ್ದಿಷ್ಟ ಮೆಥಡ್ ಅನ್ನು ಹುಡುಕಿದಾಗ, ಅವರು ಇಡೀ ಒಪ್ಪಂದವನ್ನು ಪಡೆಯುತ್ತಾರೆ, ಕೇವಲ ಯಾವುದೋ ಒಂದು ವಿಭಜನೆಯಲ್ಲಿ ಸಿಲುಕಿದ ಫ್ರಾಗ್ಮೆಂಟ್ ಅನ್ನು ಅಲ್ಲ.
ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ಗಳು (Support tickets) ಗೊಂದಲಮಯ ಮತ್ತು ಅಸಂಗತವಾಗಿರುತ್ತವೆ. ಒಂದು ಥ್ರೆಡ್ ಬಗ್ ವರದಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗಿ, ಒಂದು ಪರಿಹಾರವನ್ನು (workaround) ಪರಿಚಯಿಸಿ, ಆಂತರಿಕ ಎಸ್ಕಲೇಶನ್ ನೋಟ್ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳಬಹುದು. ಸೆಮ್ಯಾಂಟಿಕ್ ಚಂಕಿಂಗ್ ವಾಕ್ಯಗಳ ನಡುವಿನ ಎಂಬೆಡ್ಡಿಂಗ್ ಸಾಮ್ಯತೆಯನ್ನು ಅಳೆಯುವ ಮೂಲಕ ವಿಷಯದ ಬದಲಾವಣೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ. ನಾವು ನೈಸರ್ಗಿಕ ವಿಷಯದ ಗಡಿಗಳಲ್ಲಿ ಮಾತ್ರ ವಿಭಜನೆಗೆ ಅವಕಾಶ ನೀಡುತ್ತೇವೆ, ಇದರಿಂದಾಗಿ ಲಾಗಿನ್ ವೈಫಲ್ಯಗಳ ಬಗ್ಗೆ ಇರುವ ಸಂಭಾಷಣೆಯು ಬಿಲ್ಲಿಂಗ್ ಸೈಕಲ್ಗಳ ಬಗ್ಗೆ ಇರುವ ಫಾಲೋ-ಅಪ್ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿರುತ್ತದೆ.
ವಿಕis (Wikis) ಅತ್ಯಂತ ಕಷ್ಟಕರವಾಗಿದ್ದವು. ಅವು ವಿಸ್ತಾರವಾಗಿವೆ, ಪರಸ್ಪರ ಲಿಂಕ್ ಆಗಿವೆ ಮತ್ತು ಸಡಿಲವಾದ ಸಂಘಟನೆಯನ್ನು ಹೊಂದಿವೆ. ನಾವು ಏಜೆಂಟಿಕ್ ಚಂಕಿಂಗ್ (agentic chunking) ಅನ್ನು ಬಳಸಿದೆವು, ಅಲ್ಲಿ ಲೈಟ್ವೇಯ್ಟ್ LLM ಒಂದು ಪುಟವನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ವಿಷಯದ ಸುಸಂಬದ್ಧತೆಯ ಆಧಾರದ ಮೇಲೆ ವಿಭಜನೆಗಳನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಇದು ಇಂಜೆಸ್ಟಿನ್ ಸಮಯದಲ್ಲಿ (ingestion time) ಸ್ವಲ್ಪ ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುತ್ತದೆ, ಆದರೆ ಪರಿಣಾಮಕಾರಿ ಚಂಕ್ಗಳು ಸ್ವಯಂ-ಸಂಪೂರ್ಣವಾಗಿರುತ್ತವೆ ಮತ್ತು ರಿಟ್ರಿೀವಲ್ ಮಾಡಲು ಸಿದ್ಧವಾಗಿರುತ್ತವೆ. ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಬೆಸ್ಟ್ ಪ್ರ್ಯಾಕ್ಟಿಸಸ್ ಬಗ್ಗೆ ಇರುವ ಒಂದು ಪುಟವು ಯಾವುದೋ ಅನಿರೀಕ್ಷಿತ ಪಠ್ಯ ಬ್ಲಾಕ್ಗಳ ಬದಲಾಗಿ ತಾರ್ಕಿಕ ಘಟಕಗಳಾಗಿ ವಿಭಜನೆಯಾಗುತ್ತದೆ: ಪ್ರಿ-ಫ್ಲೈಟ್ ಚೆಕ್ಗಳು, ರೋಲ್ಬ್ಯಾಕ್ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಮಾನಿಟರಿಂಗ್ ಸೆಟಪ್.
ಹೈಬ್ರಿಡ್ ರಿಟ್ರಿೀವಲ್: ಕೀವರ್ಡ್ಗಳು ಮತ್ತು ವೆಕ್ಟರ್ಗಳು ಒಟ್ಟಿಗೆ
ಡೆನ್ಸ್ ವೆಕ್ಟರ್ ಸರ್ಚ್ (Dense vector search) ಅರ್ಥವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. ಆದರೆ ನಿಖರವಾದ ಸ್ಟ್ರಿಂಗ್ಗಳ (exact strings) ವಿಷಯದಲ್ಲಿ ಇದು ಕಳಪೆ. ಬಳಕೆದಾರರು AUTH_4027 ನಂತಹ ನಿಖರವಾದ ಎರರ್ ಕೋಡ್ ಅಥವಾ "Stark Industries" ನಂತಹ ಗ್ರಾಹಕರ ಹೆಸರನ್ನು ಹುಡುಕಿದಾಗ, ವೆಕ್ಟರ್ ಎಂಬೆಡ್ಡಿಂಗ್ಗಳು ಗುರಿಯನ್ನು ತಪ್ಪಿಸಬಹುದು ಏಕೆಂದರೆ ಅವು ಕ್ಯಾರೆಕ್ಟರ್-ಮಟ್ಟದ ನಿಖರತೆಗಿಂತ ಹೆಚ್ಚಾಗಿ ಪರಿಕಲ್ಪನಾ ಸಮೀಪತೆಯನ್ನು (conceptual proximity) ಆಪ್ಟಿಮೈಸ್ ಮಾಡುತ್ತವೆ.
BM25 ಮೂಲಕ ಮಾಡುವ ಕೇವಲ ಕೀವರ್ಡ್ ಸರ್ಚ್ ವಿರುದ್ಧದ ದೋಷವನ್ನು ಹೊಂದಿದೆ. ಇದು AUTH_4027 ಅನ್ನು ಪರಿಪೂರ್ಣವಾಗಿ ಕಂಡುಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ "authorization failure" ಮತ್ತು "login denied" ನಡುವಿನ ಪರಿಕಲ್ಪನಾ ಸಂಬಂಧವನ್ನು ಇದು ಕಳೆದುಕೊಳ್ಳಬಹುದು.
ನಾವು ಎರಡನ್ನೂ ಸಮಾನಾಂತರವಾಗಿ ನಡೆಸುತ್ತೇವೆ. BM25 ಮತ್ತು vector search ಒಂದೇ ಕಾರ್ಪಸ್ ಮೇಲೆ ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಅವುಗಳ ಫಲಿತಾಂಶದ ಪಟ್ಟಿಗಳನ್ನು Reciprocal Rank Fusion ಬಳಸಿ ವಿಲೀನಗೊಳಿಸಲಾಗುತ್ತದೆ, ಇದು ಅಭ್ಯರ್ಥಿಗಳ ಸ್ಥಾನದ ಶ್ರೇಣಿಗಳನ್ನು (positional ranks) ಸಮತೋಲನಗೊಳಿಸುವ ಮೂಲಕ ಅವುಗಳನ್ನು ಮರುಕ್ರಮಗೊಳಿಸುತ್ತದೆ. ನಿಮಗೆ ಕ್ಯಾಲಿಬ್ರೇಟ್ ಮಾಡಿದ ತೂಕಗಳ (calibrated weights) ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ಕೇವಲ ಒಂದು ಶ್ರೇಣೀಕೃತ ಪಟ್ಟಿಯಲ್ಲಿ ನಿಖರವಾದ ಹೊಂದಾಣಿಕೆಯ (exact match) ನಿಖರತೆಯನ್ನು ಮತ್ತು ಸೆಮ್ಯಾಂಟಿಕ್ ಸರ್ಚ್ನ (semantic search) ಅಂತಃಪ್ರಜ್ಞೆಯನ್ನು ಪಡೆಯುತ್ತೀರಿ.
ನಂತರ ನಾವು cross-encoder reranker ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ. ಇದು ಮೂಲ ಕ್ವೇರಿಯ ಎದುರು ಪ್ರತಿ ಪ್ಯಸೇಜ್ ಅನ್ನು ಸ್ಕೋರ್ ಮಾಡುವ ಪ್ರತ್ಯೇಕ ಮಾಡೆಲ್ ಆಗಿದ್ದು, ಯಾವುದೇ ಒಂದೇ ರಿಟ್ರೈವರ್ (retriever) ನೀಡುವതിಗಿಂತ ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮವಾದ ಪ್ರಸ್ತುತತೆಯ ಸಂಕೇತವನ್ನು (relevance signal) ನೀಡುತ್ತದೆ. ಇದು ಸುಮಾರು 50 ಮಿಲಿಸೆಕೆಂಡ್ಗಳ ವಿಳಂಬವನ್ನು (latency) ಸೇರಿಸುತ್ತದೆ. ಇದು ರಿಕಾಲ್ ಅನ್ನು (recall) ಶೇಕಡಾ 15 ರಷ್ಟು ಹೆಚ್ಚಿಸುತ್ತದೆ. ನೀವು ಉತ್ತರದ ಗುಣಮಟ್ಟದ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುವುದಾದರೆ, ಆ ವಿನಿಮಯವು ಅನಿವಾರ್ಯ.
ಕ್ವೇರಿ ಎಕ್ಸ್ಪ್ಯಾನ್ಶನ್ (Query Expansion): ಹುಡುಕಾಟ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲೇ ಅದನ್ನು ಸರಿಪಡಿಸಿ
ಕೆಟ್ಟ ಕ್ವೇರಿಗಳು ಪ್ರತಿಯೊಂದು ರಿಟ್ರಿವಾಲ್ ಸಿಸ್ಟಮ್ನ (retrieval system) ಗುಪ್ತ ಸಮಸ್ಯೆಯಾಗಿವೆ. ಬಳಕೆದಾರರು ನಿಮ್ಮ ಎಂಬೆಡ್ಡಿಂಗ್ ಸ್ಪೇಸ್ನಂತೆ (embedding space) ಬರೆಯುವುದಿಲ್ಲ. ಅವರು "it broke" ಎಂದು ಟೈಪ್ ಮಾಡುತ್ತಾರೆ. ಅವರು ಅಪೂರ್ಣವಾದ ಸ್ಟ್ಯಾಕ್ ಟ್ರೇಸ್ಗಳನ್ನು (stack traces) ಪೇಸ್ಟ್ ಮಾಡುತ್ತಾರೆ. ನಿಮ್ಮ ಇಂಡೆಕ್ಸ್ ಎಂದೂ ನೋಡದ ಆಂತರಿಕ ತಾಂತ್ರಿಕ ಪದಗಳನ್ನು (internal jargon) ಅವರು ಬಳಸುತ್ತಾರೆ.
ಕ್ವೇರಿಯು ಇಂಡೆಕ್ಸ್ ಅನ್ನು ತಲುಪುವ ಮೊದಲೇ ನಾವು ಅದನ್ನು ಪರಿವರ್ತಿಸುತ್ತೇವೆ. ಮೊದಲಿಗೆ, ನಾವು ಒಂದೇ ಕ್ವೇರಿಯನ್ನು ಮೂರುದಿಂದ ಐದು ವೈವಿಧ್ಯಮಯ ಸರ್ಚ್ ಟರ್ಮ್ಗಳಾಗಿ ವಿಸ್ತರಿಸುತ್ತೇವೆ. ಮೂಲವು "payment failed" ಎಂದಿದ್ದರೆ, ನಾವು "transaction error," "billing declined," ಮತ್ತು "charge unsuccessful" ಎಂದೂ ಹುಡುಕುತ್ತೇವೆ.