ನಾಲ್ಕು ತಿಂಗಳ ಕಾಲ ಒಂದು Retrieval-Augmented Generation (RAG) ಪೈಪ್ಲೈನ್ ಅನ್ನು Jupyter notebook ನಿಂದ ಲೈವ್ ಸರ್ವಿಸ್ಗೆ ಪರಿವರ್ತಿಸಿದ ನಂತರ, ಲೇಖಕರು ಒಂದು ಪ್ರದರ್ಶನ ಮಾದರಿಯನ್ನು (demo) ಬಳಕೆದಾರರು ನಂಬಬಹುದಾದ ವ್ಯವಸ್ಥೆಯನ್ನಾಗಿ ಪರಿವರ್ತಿಸಿದ ಐದು ನಿರ್ಣಾಯಕ ಆಯ್ಕೆಗಳನ್ನು ಗುರುತಿಸಿದ್ದಾರೆ. ಈ ವ್ಯತ್ಯಾಸವು ಅಂಕಿಅಂಶಗಳಲ್ಲಿ ಕಂಡುಬರುತ್ತದೆ: ಪಠ್ಯವನ್ನು ವಿಭಜಿಸುವ ವಿಧಾನದಲ್ಲಿ ಮಾಡಿದ ಒಂದು ಸಣ್ಣ ಬದಲಾವಣೆಯು retrieval hit rate ಅನ್ನು 61% ರಿಂದ 83% ಕ್ಕೆ ಏರಿಸಿತು, ಮತ್ತು 200 ನೈಜ ಪ್ರಶ್ನೆಗಳ ಒಂದು ಸಣ್ಣ ಮೌಲ್ಯಮಾಪನ ಸೆಟ್ (evaluation set) ಈಗ ಗ್ರಾಹಕರಿಗೆ ತಲುಪುವ ಮೊದಲೇ ಹೆಚ್ಚಿನ ತಪ್ಪುಗಳನ್ನು (regressions) ಪತ್ತೆಹಚ್ಚುತ್ತದೆ.
Why it matters
RAG ಡೆಮೋಗಳು ಆಕರ್ಷಕವಾಗಿ ಕಾಣುತ್ತವೆ – ಅವು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಒಂದು ಭಾಗವನ್ನು ಹುಡುಕಿ ಸಮಂಜಸವಾದ ಉತ್ತರವನ್ನು ನೀಡುತ್ತವೆ. ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ, ಅದೇ ವಿಧಾನವು ಹಳೆಯ ಮಾಹಿತಿ, ತಪ್ಪಾದ ಎರರ್ ಕೋಡ್ಗಳು ಅಥವಾ ಮುರಿದುಹೋದ ವಾಕ್ಯಗಳನ್ನು ನೀಡಬಹುದು, ಇದು ಬಳಕೆದಾರರ ನಂಬಿಕೆಯನ್ನು ಕುಗ್ಗಿಸುತ್ತದೆ. ಇಲ್ಲಿ ಅಡಚಣೆಯು ಭಾಷಾ ಮಾದರಿಯಲ್ಲಲ್ಲ (language model); ಬದಲಾಗಿ ವಿಷಯವನ್ನು ಹೇಗೆ ಪಡೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ (ingested), ಇಂಡೆಕ್ಸ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ನೀಡಲಾಗುತ್ತದೆ ಎಂಬುದರಲ್ಲಿದೆ. ಪೈಪ್ಲೈನ್ ಅನ್ನು ಸರಿಯಾಗಿ ರೂಪಿಸುವುದು ಒಂದು ಮೌಲ್ಯಯುತ ಉತ್ಪನ್ನ ಮತ್ತು ಹೊರೆಯಾಗುವ ಉತ್ಪನ್ನದ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
1. Stop using fixed-size chunks
ಅನೇಕ ಪ್ರೊಟೊಟೈಪ್ಗಳು ಪ್ರತಿಯೊಂದು ದಾಖಲೆಯನ್ನು 512-ಟೋಕನ್ ಬ್ಲಾಕ್ಗಳಾಗಿ ಕಡಿಯುತ್ತವೆ. ಇದು ಸಣ್ಣ ಪಠ್ಯಗಳಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ ತಾಂತ್ರಿಕ ಕೈಪಿಡಿಗಳು, ಸಪೋರ್ಟ್ ಥ್ರೆಡ್ಗಳು ಮತ್ತು ಕೋಡ್ ಸ್ನಿಪ್ಪೆಟ್ಗಳನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ. ವಾಕ್ಯಗಳು ವಿಭಜನೆಗೊಳ್ಳುತ್ತವೆ, ಹೆಡಿಂಗ್ಗಳು ಮಾಯವಾಗುತ್ತವೆ ಮತ್ತು ರಿಟ್ರಿவல் ಇಂಜಿನ್ ಬಳಕೆದಾರರು ನಿರೀಕ್ಷಿಸುವ ಸಂದರ್ಭವನ್ನು (context) ಹೊಂದಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
ರಚನೆ-ಅರಿವಿರುವ ಚಂಕಿಂಗ್ (structure-aware chunking) ಬಳಸಿ—ಹೆಡಿಂಗ್ಗಳು, ಸಂಭಾಷಣೆಯ ಗಡಿಗಳು ಅಥವಾ ಕೋಡ್ ಫೆನ್ಸ್ಗಳಲ್ಲಿ ವಿಭಜಿಸಿ—ಇದರಿಂದ ಅರ್ಥಪೂರ್ಣ ಘಟಕಗಳನ್ನು (semantic units) ಉಳಿಸಿಕೊಳ್ಳಬಹುದು. ಲೇಖಕರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಇದು ಮಾತ್ರ ರಿಲೆವೆಂಟ್ ಪ್ಯಸೇಜ್ ಕಂಡುಹಿಡಿಯುವ ಪ್ರಶ್ನೆಗಳ ಪ್ರಮಾಣವನ್ನು 61% ರಿಂದ 83% ಕ್ಕೆ ಹೆಚ್ಚಿಸಿತು. ಈ ಸುಧಾರಣೆಯು ಡೇಟಾ-ಫಾರ್ಮ್ಯಾಟ್ ಬದಲಾವಣೆಯಿಂದ ಬಂದಿದೆ; ಮೂಲ ಮಾದರಿಯು (underlying model) ಬದಲಾಗಿಲ್ಲ.
2. Use hybrid search
ಕೇವಲ ವೆಕ್ಟರ್ ಸರ್ಚ್ (embedding-based similarity) ಒಂದೇ ರೀತಿಯ ಅರ್ಥವಿರುವ ಭಾಗಗಳನ್ನು ಹುಡುಕುವಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿದೆ, ಆದರೆ ಅದು ಎರರ್ ಕೋಡ್ಗಳು, ವರ್ಷನ್ ಸಂಖ್ಯೆಗಳು ಅಥವಾ ಪ್ರತ್ಯೇಕ ತಾಂತ್ರಿಕ ಪದಗಳಂತಹ ನಿಖರವಾದ ಗುರುತಿಸುವಿಕೆಗಳಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು. "ERR-XXXX" ನಂತಹ ಎರರ್ ಕೋಡ್ ಹುಡುಕುತ್ತಿರುವ ಬಳಕೆದಾರರಿಗೆ, ಆ ಕೋಡ್ ಇಲ್ಲದಿದ್ದರೂ ಅರ್ಥಕ್ಕೆ ಹತ್ತಿರವಿರುವ ಪ್ಯಾರಾಗ್ರಾಫ್ ಸಿಗಬಹುದು.
ಹೈಬ್ರಿಡ್ ಸರ್ಚ್ ಒಂದು ಡೆನ್ಸ್ ವೆಕ್ಟರ್ ಇಂಡೆಕ್ಸ್ ಅನ್ನು ಸಾಂಪ್ರದಾಯಿಕ BM25 ಇಂಡೆಕ್ಸ್ನೊಂದಿಗೆ (term-frequency ಆಧಾರಿತ) ಸಂಯೋಜಿಸುತ್ತದೆ. ಈ ಎರಡೂ ಸ್ಕೋರ್ಗಳಿಗೆ ತೂಕ ನೀಡುವ ಮೂಲಕ, ವ್ಯವಸ್ಥೆಯು ಬಳಕೆದಾರರು ಟೈಪ್ ಮಾಡಿದ ನಿಖರ ಪದಗಳನ್ನು ಹೊಂದಿರುವ ಮತ್ತು ಅರ್ಥಕ್ಕೆ ಹತ್ತಿರವಿರುವ ಐಟಂಗಳನ್ನು ಹುಡುಕುತ್ತದೆ. ಪ್ರೊಡಕ್ಷನ್ಗಾಗಿ, ಹೈಬ್ರಿಡ್ ಸರ್ಚ್ ಎಂಬುದು ಕೇವಲ ಒಂದು ಆಯ್ಕೆಯಲ್ಲ, ಅದು ಮೂಲಭೂತ ಅಗತ್ಯವಾಗಿದೆ.
3. Handle stale data
ಹಳೆಯದಾದ ಬೆಲೆ ಪಟ್ಟಿಗಳು, ನೀತಿ ದಾಖಲೆಗಳು ಅಥವಾ ಫರ್ಮ್ವೇರ್ ರಿಲೀಸ್ ನೋಟ್ಗಳು ವ್ಯವಸ್ಥೆಯ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಕ್ಷಣಾರ್ಧದಲ್ಲಿ ನಾಶಮಾಡಬಹುದು. ಇಂಡೆಕ್ಸ್ ಅನ್ನು ತಾಜಾವಾಗಿಡಲು ಮೂರು ಪ್ರಾಯೋಗಿಕ ಹಂತಗಳು ಇಲ್ಲಿವೆ:
- ಪ್ರತಿಯೊಂದು ದಾಖಲೆಗೆ ವರ್ಷನ್ ಸ್ಟ್ಯಾಂಪ್ ಅಥವಾ ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ನೀಡಿ.
- ಸ್ಕೋರಿಂಗ್ ಮಾಡುವಾಗ 'recency boost' ಅನ್ವಯಿಸಿ, ಇದರಿಂದ ಹೊಸ ಐಟಂಗಳು ಹಳೆಯ ಪ್ರತಿಗಳಿಗಿಂತ ಮೇಲೆಯೇ ಇರುತ್ತವೆ.
- ಮೂಲ ವ್ಯವಸ್ಥೆಗಳಿಂದ ಬದಲಾವಣೆಗಳನ್ನು ಪಡೆಯಲು ಪ್ರತಿದಿನ ರಾತ್ರಿ ಇನ್ಕ್ರೀಮೆಂಟಲ್ ರೀ-ಇಂಡೆಕ್ಸಿಂಗ್ (incremental re-indexing) ಮಾಡಿ.
ಈ ಸುರಕ್ಷತಾ ಕ್ರಮಗಳು ವ್ಯವಸ್ಥೆಯು ಕಳೆದ ತ್ರೈಮಾಸಿಕದಲ್ಲಿ ಅನ್ವಯವಾಗಿದ್ದ ಬೆಲೆಯನ್ನು ಅಥವಾ ಈಗಾಗಲೇ ಬದಲಾಗಿರುವ ನೀತಿಯನ್ನು ನೀಡದಂತೆ ತಡೆಯುತ್ತವೆ.
4. Rerank instead of upgrading models
ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್ ಅನ್ನು ಅಪ್ಗ್ರೇಡ್ ಮಾಡುವುದರಿಂದ ಗುಣಮಟ್ಟದಲ್ಲಿ ಸಣ್ಣ ಸುಧಾರಣೆ ಮಾತ್ರ ಸಿಗುತ್ತದೆ, ಆದರೆ ಕ್ರಾಸ್-ಎನ್ಕೋಡರ್ ರೀರ್ಯಾಂಕರ್ (cross-encoder reranker) ಅನ್ನು ಸೇರಿಸುವುದರಿಂದ ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲಿ ಹೆಚ್ಚಿನ ಸುಧಾರಣೆ ಸಿಗುತ್ತದೆ.
ಪ್ರೊಡಕ್ಷನ್ ಫ್ಲೋ ಹೈಬ್ರಿಡ್ ಸರ್ಚ್ ಬಳಸಿ 20 ಅಗ್ಗದ ಅಭ್ಯರ್ಥಿಗಳನ್ನು (candidates) ಪಡೆಯುತ್ತದೆ, ನಂತರ ಅವುಗಳಲ್ಲಿ ಅತ್ಯುತ್ತಮ ಐದನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ರೀರ್ಯಾಂಕರ್ ಮೂಲಕ ಕಳುಹಿಸುತ್ತದೆ. ಈ ಎರಡು ಹಂತದ ವಿಧಾನವು ಪೂರ್ಣ ಮಾದರಿ ಅಪ್ಗ್ರೇಡ್ನ ವೆಚ್ಚದ ಒಂದು ಸಣ್ಣ ಭಾಗದಲ್ಲಿ ಹೆಚ್ಚಿನ ಗುಣಮಟ್ಟದ ಸುಧಾರಣೆಯನ್ನು ನೀಡುತ್ತದೆ.
5. Build a real evaluation set
ನೀವು ಅಳೆಯದಿದ್ದಲ್ಲಿ ಸುಧಾರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಲೇಖಕರು 200 ನೈಜ ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗಳ ಒಂದು ಟೆಸ್ಟ್ ಸೂಟ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಿದ್ದಾರೆ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ತಜ್ಞರು ಸಿದ್ಧಪಡಿಸಿದ ಉತ್ತರವನ್ನು ಜೋಡಿಸಲಾಗಿದೆ. ಪ್ರತಿಯೊಂದು ಕೋಡ್ ಬದಲಾವಣೆಯೂ ಈ ಸೂಟ್ ಮೂಲಕ ಪರೀಕ್ಷಿಸಲ್ಪಡುತ್ತದೆ; ಯಾವುದೇ ಹಿನ್ನಡೆ (regression) ನಿಯೋಜನೆಗಿಂತ ಮೊದಲೇ ಪತ್ತೆಯಾಗುತ್ತದೆ.
ಬಳಕೆದಾರರು ತಪ್ಪು ಉತ್ತರವನ್ನು ವರದಿ ಮಾಡಿದಾಗ, ತಕ್ಷಣ ಆ ಪ್ರಶ್ನೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಸೆಟ್ಗೆ ಸೇರಿಸಿ, ಇದರಿಂದ ನೈಜ ಪ್ರಪಂಚದ ವೈಫಲ್ಯಗಳನ್ನು ಭವಿಷ್ಯದ ಸುರಕ್ಷತಾ ಕ್ರಮಗಳನ್ನಾಗಿ ಪರಿವರ್ತಿಸಬಹುದು. ಪ್ರತಿ ಜನರೇಟೆಡ್ ಉತ್ತರದ ನಿರಂತರ ಲಾಗಿಂಗ್ (logging) ಮೌಲ್ಯಮಾಪನ ಲೂಪ್ಗೆ ಪೂರಕವಾಗುತ್ತದೆ, ಇದು ವ್ಯವಸ್ಥೆಯನ್ನು ನೈಜ ಬಳಕೆಗೆ ಅನುಗುಣವಾಗಿ ಇರಿಸುತ್ತದೆ.
The production pipeline in practice
- Ingest: ರಚನೆ-ಅರಿವಿರುವ ಚಂಕಿಂಗ್ ಹೆಡಿಂಗ್ಗಳು, ಕೋಡ್ ಬ್ಲಾಕ್ಗಳು ಮತ್ತು ಸಂಭಾಷಣೆಯ ಹಂತಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ.
- Index: ಡೆನ್ಸ್ ಎಂಬೆಡ್ಡಿಂಗ್ಗಳು ಮತ್ತು BM25 ಟರ್ಮ್ ಸ್ಟ್ಯಾಟಿಸ್ಟಿಕ್ಸ್ ಎರಡನ್ನೂ ಸಂಗ್ರಹಿಸಿ.
- Retrieve: ಹೈಬ್ರಿಡ್ ಸರ್ಚ್ ಅರ್ಥದ ಸಾಮ್ಯತೆ ಮತ್ತು ನಿಖರ ಪದಗಳ ಹೊಂದಾಣಿಕೆಯನ್ನು ಸಮತೋಲನಗೊಳಿಸಿ 20 ಅಭ್ಯರ್ಥಿಗಳನ್ನು ನೀಡುತ್ತದೆ.
- Rerank: ಕ್ರಾಸ್-ಎನ್ಕೋಡರ್ ಪಟ್ಟಿಯನ್ನು ಅತ್ಯಂತ ಭರವಸೆಯ ಐದು ಪ್ಯಸೇಜ್ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ.
- Generate: ಅಂತಿಮ ಉತ್ತರವನ್ನು ರೂಪಿಸಲು LLM ಈ ಟಾಪ್ ಚಂಕ್ಗಳು ಮತ್ತು ಅವುಗಳ ಮೆಟಾಡೇಟಾವನ್ನು ಪಡೆಯುತ್ತದೆ.
- Evaluate: ಪ್ರತಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಲಾಗ್ ಮಾಡಲಾಗುತ್ತದೆ; ವೈಫಲ್ಯಗಳನ್ನು 200-ಪ್ರಶ್ನೆಗಳ ಟೆಸ್ಟ್ ಸೆಟ್ಗೆ ಮರಳಿ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.
Stakes and trade-offs
ಸರಿಯಾಗಿ ಹೊಂದಾಣಿಕೆಯಾದ ಪೈಪ್ಲೈನ್ ಭ್ರಮೆಗಳನ್ನು (hallucinations) ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಉತ್ತರದ ಪ್ರಸ್ತುತತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ ಮತ್ತು ಅತಿಯಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿರುವ ಮಾಡೆಲ್ಗಳ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಇದರ ಪ್ರಯೋಜನವೆಂದರೆ ಹೆಚ್ಚಿನ ಬಳಕೆದಾರರ ತೃಪ್ತಿ ಮತ್ತು ಕಡಿಮೆ ಬೆಂಬಲ ವೆಚ್ಚ (support overhead). ಈ ಹಂತಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು ಬ್ರ್ಯಾಂಡ್ ಮೇಲಿನ ನಂಬಿಕೆಯನ್ನು ಕುಗ್ಗಿಸುವ ಮತ್ತು ದುಬಾರಿ ತುರ್ತು ಪರಿಹಾರ ಕ್ರಮಗಳಿಗೆ (firefighting) ಒತ್ತಾಯಿಸುವ ಅಸ್ಥಿರವಾದ ಸೇವೆಯನ್ನು ನೀಡುತ್ತದೆ.
ಮುಂದೆ ಗಮನಿಸಬೇಕಾದ ಅಂಶಗಳು
ಓಪನ್-ಸೋರ್ಸ್ ಎಂಬೆಡ್ಡಿಂಗ್ಸ್ ಮತ್ತು ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ಗಳು ಪ್ರೌಢ ಹಂತಕ್ಕೆ ತಲುಪಿದಂತೆ, "ಡೆನ್ಸ್" (dense) ಮತ್ತು "ಸ್ಪಾರ್ಸ್" (sparse) ರಿಟ್ರಿ越ಲ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು ಅಸ್ಪಷ್ಟವಾಗಬಹುದು, ಆದರೆ ಸೆಂಮ್ಯಾಂಟಿಕ್ (semantic) ಮತ್ತು ನಿಖರವಾದ ಮ್ಯಾಚಿಂಗ್ ಅನ್ನು ಸಂಯೋಜಿಸುವ ತತ್ವವು ಹಾಗೆಯೇ ಇರುತ್ತದೆ.
ಮುಖ್ಯ ಅಂಶ: RAG ಸಿಸ್ಟಮ್ನಲ್ಲಿ, ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ ಅಪರೂಪಕ್ಕೆ ಮಾತ್ರ ಅಡಚಣೆಯ ಕೇಂದ್ರಬಿಂದುವಾಗಿರುತ್ತದೆ. ನಿಜವಾದ ಕೆಲಸವು ನೀವು ಮೂಲ ವಿಷಯವನ್ನು ಹೇಗೆ ವಿಂಗಡಿಸುತ್ತೀರಿ (slice), ಇಂಡೆಕ್ಸ್ ಮಾಡುತ್ತೀರಿ ಮತ್ತು ಪ್ರದರ್ಶಿಸುತ್ತೀರಿ (surface) ಎಂಬುದರಲ್ಲಿದೆ. ಈ ನಿರ್ಧಾರಗಳನ್ನು ಸರಿಯಾಗಿ ತೆಗೆದುಕೊಳ್ಳುವುದು ಒಂದು ಆಕರ್ಷಕ ಡೆಮೊವನ್ನು ನಂಬಿಕಾರ್ಹ ಉತ್ಪನ್ನವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.