ಹೆಚ್ಚಿನ RAG ಟ್ಯುಟೋರಿಯಲ್‌ಗಳು ಕೇವಲ ಡೆಮೊ ಹಂತದಲ್ಲೇ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. ನೀವು ಟೋಕನ್ ಸಂಖ್ಯೆಯ ಆಧಾರದ ಮೇಲೆ ಚಂಕ್‌ಗಳನ್ನು (chunks) ಮಾಡಿ, ಎಲ್ಲವನ್ನೂ ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್‌ಗೆ ತುಂಬಿಸಿ ಕೆಲಸ ಮುಗಿಸಿಬಿಡುತ್ತೀರಿ. ಬಳಕೆದಾರರು "ರಿಟರ್ನ್ ಪಾಲಿಸಿ ಏನು?" ಎಂಬಂತಹ ಸರಳ ಪ್ರಶ್ನೆಯನ್ನು FAQ ನಲ್ಲಿ ಕೇಳಿದಾಗ ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆದರೆ ಯಾರಾದರೂ ಅರ್ಧ ಕರಾರು ಪತ್ರವನ್ನು (contract) ಪೇಸ್ಟ್ ಮಾಡಿ ಮೂರನೇ ಕಲಾಸಿನ (clause three) ಬಗ್ಗೆ ಕೇಳಿದಾಗ ಅಥವಾ ಒಬ್ಬ ಡೆವಲಪರ್ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಸರ್ಚ್‌ನಲ್ಲಿ ಯಾವುದೋ ಅಸ್ಪಷ್ಟ ಎರರ್ ಕೋಡ್ ಅನ್ನು ಟೈಪ್ ಮಾಡಿದಾಗ ಇದು ವಿಫಲವಾಗುತ್ತದೆ.

ನಿಗದಿತ ಟೋಕನ್ ವಿಂಡೋಗಳು (Fixed token windows) ಕಾನೂನು ಒಪ್ಪಂದಗಳನ್ನು ವಾಕ್ಯದ ಮಧ್ಯದಲ್ಲೇ ಕತ್ತರಿಸುತ್ತವೆ. ದೊಡ್ಡ ಚಂಕ್‌ಗಳು API ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ಪ್ಯಾರಾಗ್ರಾಫ್‌ಗಳ ಗದ್ದಲದ ಅಡಿಯಲ್ಲಿ ಹೂತುಹಾಕುತ್ತವೆ. ಎಲ್ಲಕ್ಕಿಂತ ಕೆಟ್ಟದ್ದು, ನಿಧಾನಗತಿಯ ರಿಟ್ರಿೀವಲ್ (retrieval) ಮಾಡಲಾದ ಕಾರಣ, ಮಾಡೆಲ್ ಉತ್ತರವನ್ನು ತಯಾರಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲೇ ಬಳಕೆದಾರರು ತಮ್ಮ ಪ್ರಶ್ನೆಯನ್ನು ಕೈಬಿಡುತ್ತಾರೆ. ನಾವು ಇದನ್ನು ಕಷ್ಟಪಟ್ಟು ಕಲಿತೆವು. ನಮ್ಮ ರಿಟ್ರಿೀವಲ್ ಲೇಯರ್ ಅನ್ನು ಕೇವಲ ಅಂದಾಜಿನಿಂದ ಅಳತೆಗೋಲಿನ ಕಡೆಗೆ ಬದಲಾಯಿಸಿದಾಗ, ನಾವು ಲೇಟೆನ್ಸಿಯನ್ನು (latency) ಶೇಕಡಾ ನಲವತ್ತು ರಷ್ಟು ಕಡಿಮೆ ಮಾಡಿದೆವು ಮತ್ತು ರಿಕಾಲ್ ಅನ್ನು (recall) ಶೇಕಡಾ ತೊಂಬತ್ತೈದು ರಷ್ಟು ಹೆಚ್ಚಿಸಿದೆವು. ನಾವು ಮಾಡಿದ ಬದಲಾವಣೆಗಳು ಇಲ್ಲಿವೆ.

ಸ್ಮಾರ್ಟ್ ಚಂಕಿಂಗ್ (Smart Chunking)

ಚಂಕ್ ಸೈಜ್ ಅನ್ನು ಒಂದು ಮ್ಯಾಜಿಕ್ ನಂಬರ್ ಎಂದು ಭಾವಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಒಂದು ಕ್ಲಾಸ್ (clause) ಹಲವಾರು ಪ್ಯಾರಾಗ್ರಾಫ್‌ಗಳವರೆಗೆ ವಿಸ್ತರಿಸಿರುವ ಕಾನೂನು ದಾಖಲೆಗೆ 512-ಟೋಕನ್ ವಿಂಡೋ ಯಾವುದೇ ಅರ್ಥ ನೀಡುವುದಿಲ್ಲ. ಹಾಗೆಯೇ, ಫಂಕ್ಷನ್ ಸಿಗ್ನೇಚರ್ (function signature) ಮತ್ತು ಅದರ ಎರಡು ಸಾಲಿನ ವಿವರಣೆಯು ಒಟ್ಟಿಗೆ ಇರಬೇಕಾದ API ಡಾಕ್ಯುಮೆಂಟೇಶನ್‌ಗೆ ಇದು ಅಷ್ಟೇ ಪ್ರಯೋಜನಕಾರಿಯಲ್ಲ. ನಾವು ಸ್ಟ್ರಕ್ಚರ್-ಅವೇರ್ ಸ್ಪ್ಲಿಟಿಂಗ್ (structure-aware splitting) ವಿಧಾನಕ್ಕೆ ಬದಲಾಯಿಸಿದೆವು.

ಕಾನೂನು ಪಠ್ಯಕ್ಕಾಗಿ, ರಿಕರ್ಸಿವ್ ಚಂಕಿಂಗ್ (recursive chunking) ದಾಖಲೆಯ ಶ್ರೇಣೀಕೃತ ವ್ಯವಸ್ಥೆಯನ್ನು (hierarchy) ಗೌರವಿಸುತ್ತದೆ. ಇದರಿಂದ ಕ್ಲಾಸ್‌ಗಳು ಅಖಂಡವಾಗಿ ಉಳಿಯುತ್ತವೆ. API ಡಾಕ್ಯುಮೆಂಟೇಶನ್‌ಗಾಗಿ, ನಾವು ಫಂಕ್ಷನ್-ಅವೇರ್ ಸ್ಪ್ಲಿಟಿಂಗ್ (function-aware splitting) ಬಳಸುತ್ತೇವೆ, ಇದು ಸಿಗ್ನೇಚರ್‌ಗಳು, ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು ಮತ್ತು ಉದಾಹರಣೆಗಳನ್ನು ಅಟಾಮಿಕ್ ಯೂನಿಟ್‌ಗಳಂತೆ (atomic units) ಒಟ್ಟಿಗೆ ಇರಿಸುತ್ತದೆ. ಸಪೋರ್ಟ್ ಟಿಕೆಟ್‌ಗಳು ಮತ್ತು ಸಂಭಾಷಣಾ ದತ್ತಾಂಶಗಳಿಗೆ (conversational data) ಸೆಮ್ಯಾಂಟಿಕ್ ಬೌಂಡರಿಗಳ ಅಗತ್ಯವಿದೆ; ಅಂದರೆ ಕೇವಲ ಅನಿಶ್ಚಿತ ಅಕ್ಷರಗಳ ಸಂಖ್ಯೆಯ ಬದಲಿಗೆ ವಿಷಯ ಬದಲಾಗುವಲ್ಲಿ ವಿಭಜನೆ ಮಾಡಬೇಕು. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಪ್ರತಿ ಚಂಕ್ ಉಪಯುಕ್ತವಾಗುವಷ್ಟು ಪೂರಕ ಸಂದರ್ಭವನ್ನು (context) ಹೊಂದಿರುತ್ತದೆ, ಆದರೆ ಮಾಹಿತಿಯ ಸ್ಪಷ್ಟತೆಯನ್ನು (signal) ಕಡಿಮೆ ಮಾಡುವುದಿಲ್ಲ. ನಿಮ್ಮ ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್‌ಗೆ (embedding model) ಸೀಮಿತ ಅಟೆನ್ಷನ್ ಬಜೆಟ್ ಇರುತ್ತದೆ. ಅದನ್ನು ವಿವೇಕದಿಂದ ಬಳಸಿ.

ಹೈಬ್ರಿಡ್ ರಿಟ್ರಿೀವಲ್ (Hybrid Retrieval)

ವೆಕ್ಟರ್ ಸರ್ಚ್ (Vector search) ಪರಿಕಲ್ಪನಾತ್ಮಕವಾಗಿ ಹೋಲುವ ವಿಷಯಗಳನ್ನು ಹುಡುಕುವಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿದೆ. ನಿಧಾನಗತಿಯ ಡೇಟಾಬೇಸ್ ಕ್ವೇರಿಗಳ ಬಗ್ಗೆ ಕೇಳಿದರೆ, ಅದು ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಟ್ಯೂನಿಂಗ್ ಗೈಡ್‌ಗಳನ್ನು ತರುತ್ತದೆ. ಆದರೆ "Error 0x80070057" ಎಂದು ಕೇಳಿದಾಗ, ಸೆಮ್ಯಾಂಟಿಕ್ ಸರ್ಚ್ ಸಂಬಂಧವಿಲ್ಲದ ವಿಷಯಗಳ ಕಡೆಗೆ ಸಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಡೆನ್ಸ್ ಎಂಬೆಡ್ಡಿಂಗ್‌ಗಳು (dense embeddings) ನಿಖರವಾದ ಹೊಂದಾಣಿಕೆಗಳನ್ನು (exact matches) ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಇನ್ನೊಂದೆಡೆ, BM25 ನಿಖರವಾದ ಸ್ಟ್ರಿಂಗ್‌ಗಳು ಮತ್ತು ಅಪರೂಪದ ಪದಗಳನ್ನು ಸರಿಯಾಗಿ ಪತ್ತೆಹಚ್ಚುತ್ತದೆ, ಆದರೆ "latency" ಮತ್ತು "slow response time" ಎರಡೂ ಒಂದೇ ಅರ್ಥವನ್ನು ನೀಡುತ್ತವೆ ಎಂಬುದು ಅದಕ್ಕೆ ತಿಳಿದಿರುವುದಿಲ್ಲ.

ನಾವು ಇವೆರಡನ್ನೂ ಸಮಾಂತರವಾಗಿ (parallel) ಚಲಾಯಿಸುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು Reciprocal Rank Fusion (RRF) ಮೂಲಕ ವಿಲೀನಗೊಳಿಸುತ್ತೇವೆ. RRF ಸರಳ ಮತ್ತು ಪರಿಣಾಮಕಾರಿ. ಇದು ಪ್ರತಿ ವಿಧಾನದಿಂದ ಬಂದ ರ‍್ಯಾಂಕ್ ಮಾಡಲಾದ ಪಟ್ಟಿಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ಸ್ಥಾನದ ಆಧಾರದ ಮೇಲೆ ದಾಖಲೆಗಳಿಗೆ ಸ್ಕೋರ್ ನೀಡುತ್ತದೆ, ಇದರಿಂದ ಎರಡೂ ವ್ಯವಸ್ಥೆಗಳಿಂದ ಬಂದ ಬಲವಾದ ಅಭ್ಯರ್ಥಿಗಳಿಗೆ ಸಮಾನ ಅವಕಾಶ ಸಿಗುತ್ತದೆ. ವಿಲೀನದ ನಂತರ, ನಾವು ಸಂಯೋಜಿತ ಫಲಿತಾಂಶಗಳ ಮೇಲೆ cross-encoder reranker ಅನ್ನು ಚಲಾಯಿಸುತ್ತೇವೆ ಮತ್ತು ಕೇವಲ ಮೊದಲ ಐದು ಫಲಿತಾಂಶಗಳನ್ನು ಮಾತ್ರ ನೀಡುತ್ತೇವೆ. ಈ reranker ಸುಮಾರು ಐವತ್ತು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಷ್ಟು ಲೇಟೆನ್ಸಿಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ, ಆದರೆ ನಮ್ಮ ರಿಕಾಲ್ ಅನ್ನು ಶೇಕಡಾ ಹದಿನೈದು ರಷ್ಟು ಸುಧಾರಿಸುತ್ತದೆ. ಜನರೇಷನ್ ಗುಣಮಟ್ಟದಲ್ಲಿ (generation quality) ಸಿಗುವ ಲಾಭವು ಈ ಸಣ್ಣ ವಿಳಂಬವನ್ನು ಹಲವು ಪಟ್ಟು ಮೀರಿಸುತ್ತದೆ.

ಕ್ವೇರಿ ಎಕ್ಸ್‌ಪ್ಯಾನ್ಷನ್ (Query Expansion)

ಬಳಕೆದಾರರು ಕ್ವೇರಿ ಮಾಡುವಲ್ಲಿ ಅಷ್ಟು ನಿಖರರಲ್ಲ. ಅವರು ಪದಗಳನ್ನು ಸಂಕ್ಷೇಪಿಸುತ್ತಾರೆ, ತಪ್ಪಾಗಿ ಬರೆಯುತ್ತಾರೆ ಅಥವಾ ಮೂರು ಪ್ರಶ್ನೆಗಳನ್ನು ಒಂದೇ ಉದ್ದನೆಯ ವಾಕ್ಯದಲ್ಲಿ ಬೆರೆಸಿ ಕೇಳುತ್ತಾರೆ. ಅವರು ಟೈಪ್ ಮಾಡಿದಂತೆಯೇ ನೀವು ಹುಡುಕಿದರೆ, ಅವರಿಗೆ ನಿಜವಾಗಿಯೂ ಬೇಕಾದ ದಾಖಲೆಗಳನ್ನು ನೀವು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ.

ಈಗ ನಾವು ಪ್ರತಿಯೊಂದು ಕ್ವೇರಿಯು ಇಂಡೆಕ್ಸ್ ತಲುಪುವ ಮೊದಲು ಅದನ್ನು ರೂಪಾಂತರಗೊಳಿಸುತ್ತೇವೆ. ಮೊದಲನೆಯದಾಗಿ, ಸಮಾನಾರ್ಥಕ ಪದಗಳು ಮತ್ತು ಪರ್ಯಾಯ ಪದಬಳಕೆಯನ್ನು ಒಳಗೊಳ್ಳಲು ಮೂಲ ಪ್ರಶ್ನೆಯ ಅನೇಕ ಮರುರೂಪಿತ ಆವೃತ್ತಿಗಳನ್ನು (rephrased versions) ಸೃಷ್ಟಿಸುತ್ತೇವೆ. ಎರಡನೆಯದಾಗಿ, ಸಂಕೀರ್ಣ ಪ್ರಶ್ನೆಗಳನ್ನು ಸಣ್ಣ ಉಪ-ಪ್ರಶ್ನೆಗಳಾಗಿ (sub-questions) ವಿಭಜಿಸುತ್ತೇವೆ. "ಅಂತರಾಷ್ಟ್ರೀಯ ಗ್ರಾಹಕರಿಗೆ ರಿಫಂಡ್ ಏಕೆ ವಿಫಲವಾಗುತ್ತಿದೆ ಮತ್ತು ಅದನ್ನು ನಾನು ಹೇಗೆ ಸರಿಪಡಿಸುವುದು?" ಎಂಬ ಕ್ವೇರಿಯು ಎರಡು ವಿಭಿನ್ನ ಹುಡುಕಾಟಗಳಾಗಿ ಬದಲಾಗುತ್ತದೆ: ಒಂದು ಅಂತರಾಷ್ಟ್ರೀಯ ರಿಫಂಡ್ ವಿಫಲತೆಗಳ ಬಗ್ಗೆ ಮತ್ತು ಇನ್ನೊಂದು ಪರಿಹಾರ ಕ್ರಮಗಳ (remediation steps) ಬಗ್ಗೆ. ಕೇವಲ ಕ್ವೇರಿ ಎಕ್ಸ್‌ಪ್ಯಾನ್ಷನ್ ಮೂಲಕವೇ ನಮ್ಮ ರಿಕಾಲ್ ಶೇಕಡಾ ಎಪ್ಪತ್ತೆಂಟು‌ನಿಂದ ಶೇಕಡಾದೊಂಬತ್ತನಾಲ್ಕಕ್ಕೆ ಏರಿತು. ಪಾಠ ಸರಳವಾಗಿದೆ: ಬಳಕೆದಾರರ ಮೊದಲ ಕರಡನ್ನು (first draft) ನಂಬಬೇಡಿ. ಅವರಿಗೆ ಸಹಾಯ ಮಾಡಿ.

ಅಂದಾಜಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಹುಡುಕಲು ಪ್ರಾರಂಭಿಸಿ

ಚಂಕ್ ಸೈಜ್, ಓವರ್‌ಲ್ಯಾಪ್ ಪರ್ಸೆಂಟ್ (overlap percentage), top-k ಕಟ್‌ಆಫ್ ಮತ್ತು reranker ಆಳವು (depth) ಕೈಯಿಂದ ಟ್ಯೂನ್ ಮಾಡಲು ಅಸಾಧ್ಯವಾದ ರೀತಿಯಲ್ಲಿ ಪರಸ್ಪರ ಸಂಬಂಧ ಹೊಂದಿರುತ್ತವೆ. ನಾವು 256 ಟೋಕನ್‌ಗಳು 512 ಕ್ಕಿಂತ ಉತ್ತಮವೇ ಎಂದು ಚರ್ಚಿಸಲು ತುಂಬಾ ಸಮಯ ವ್ಯರ್ಥ ಮಾಡಿದೆವು, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಸಂಸಾರತೆಯನ್ನು (coherence) ಹಾಳುಮಾಡುತ್ತಿದ್ದ ಓವರ್‌ಲ್ಯಾಪ್ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದೆವು.

ನಾವು ಅಂತಃಪ್ರಜ್ಞೆಯ ಬದಲಿಗೆ (intuition) ಬೇಯೇಶಿಯನ್ ಆಪ್ಟಿಮೈಸೇಶನ್ (Bayesian optimization) ಅನ್ನು ಬಳಸಿದೆವು. ಸ್ಪಷ್ಟವಾಗಿ ಕೆಟ್ಟ ಪ್ರದೇಶಗಳ ಮೇಲೆ ಕಂಪ್ಯೂಟ್ ಶಕ್ತಿಯನ್ನು ವ್ಯರ್ಥ ಮಾಡುವ ಗ್ರ

The numbers speak plainly. Our Recall@10 climbed from seventy-eight percent to ninety-five percent. The p95 latency dropped from 850 milliseconds to 320 milliseconds. And because the model was finally receiving relevant context instead of noise, the hallucination rate fell from twelve percent to three percent. Better retrieval does not just make answers faster. It makes them true.

What to Do Next

If you are rebuilding your retrieval layer, start here:

  • Chunk by document structure, not token count. Match your splitting strategy to the shape of your data.
  • Use hybrid retrieval. Combine vector search and BM25, merge with Reciprocal Rank Fusion, and rerank before you generate.
  • Expand queries for better coverage. Rephrase and decompose before the search ever runs.
  • Build a golden dataset for testing. You cannot optimize what you do not measure.
  • Optimize parameters with automated tools. Bayesian search will find better settings than your gut.

Retrieval is not a configuration file you set once and forget. It is infrastructure, and infrastructure deserves the same rigor as production code: tests, measurements, and continuous optimization. Treat it that way, and your RAG system stops being a demo and starts being a product.

Optional learning community: GyaanSetu AI