ಈ 7 ತಪ್ಪುಗಳನ್ನು ಸರಿಪಡಿಸುವ ಮೊದಲು ನಾನು RAG ಮೂಲಸೌಕರ್ಯಕ್ಕಾಗಿ (Infrastructure) $500 ಖರ್ಚು ಮಾಡಿದೆ
ನಾನು ಖಾಸಗಿ ದಾಖಲೆಗಳ ಹುಡುಕಾಟಕ್ಕಾಗಿ (private document search) ಒಂದು RAG ಪೈಪ್ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸಿದೆ. ಇದಕ್ಕೆ ಕಂಪ್ಯೂಟ್ ವೆಚ್ಚದಲ್ಲಿ $500 ಮತ್ತು ವಾರಗಟ್ಟಲೆ ಡಿಬಗ್ಗೆ (debugging) ತಗುಲಿತು. ಫಲಿತಾಂಶಗಳು ಕಳಪೆಯಾಗಿದ್ದವು. ಬಳಕೆದಾರರಿಗೆ ತಪ್ಪು ಉತ್ತರಗಳು ಸಿಗುತ್ತಿದ್ದವು ಮತ್ತು ಕ್ವೇರಿಗಳು (queries) ನಿಧಾನವಾಗಿದ್ದವು.
ನಾನು ಪೈಪ್ಲೈನ್ ಅನ್ನು ಆಡಿಟ್ ಮಾಡಿದೆ. ಅದರಲ್ಲಿ 7 ತಪ್ಪುಗಳನ್ನು ಕಂಡುಕೊಂಡೆ. ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಿದ್ದು ಎಲ್ಲವನ್ನೂ ಬದಲಿಸಿತು.
- ಫಿಕ್ಸ್ಡ್ ಟೋಕನ್ ಚಂಕಿಂಗ್ (Fixed Token Chunking) ನಾನು ದಾಖಲೆಗಳನ್ನು 512 ಟೋಕನ್ಗಳ ಮೂಲಕ ವಿಂಗಡಿಸಿದೆ. ಇದು ಸಂದರ್ಭವನ್ನು (context) ಹಾಳುಮಾಡಿತು. ಉದಾಹರಣೆಗೆ, ಒಂದು API ವಿವರಣೆಯು ವಾಕ್ಯದ ಮಧ್ಯದಲ್ಲೇ ವಿಭಜನೆಯಾಗುತ್ತಿತ್ತು. LLM ಕೇವಲ ತುಣುಕುಗಳನ್ನು ಪಡೆದು ಕಳಪೆ ಉತ್ತರಗಳನ್ನು ನೀಡುತ್ತಿತ್ತು. ಪರಿಹಾರ: ಸೆಮ್ಯಾಂಟಿಕ್ ಚಂಕಿಂಗ್ (semantic chunking) ಬಳಸಿ.
- ಪ್ಯಾರಾಗ್ರಾಫ್ಗಳು ಅಥವಾ ಹೆಡರ್ಗಳಂತಹ ನೈಸರ್ಗಿಕ ಗಡಿಗಳ ಮೂಲಕ ವಿಭಜಿಸಿ.
- ಪೇರೆಂಟ್-ಡಾಕ್ಯುಮೆಂಟ್ ರಿಟ್ರಿವಲ್ (parent-document retrieval) ಬಳಸಿ.
- ಹುಡುಕಾಟಕ್ಕಾಗಿ ಸಣ್ಣ ಚೈಲ್ಡ್ ಚಂಕ್ಗಳನ್ನು (child chunks) ರಚಿಸಿ.
- ಪೂರ್ಣ ಪೇರೆಂಟ್ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು LLM ಗೆ ಕಳುಹಿಸಿ.
- ಚಂಕ್ಗಳ ನಡುವೆ 10-20% ಓವರ್ಲ್ಯಾಪ್ (overlap) ಸೇರಿಸಿ.
- ಕೆಟ್ಟ ಹೈಬ್ರಿಡ್ ಸರ್ಚ್ ವೇಟ್ಸ್ (Bad Hybrid Search Weights) ನಾನು ವೆಕ್ಟರ್ ಮತ್ತು ಕೀವರ್ಡ್ ಸರ್ಚ್ಗಾಗಿ 50/50 ವಿಭಜನೆಯನ್ನು ಬಳಸಿದೆ. ಇದು ತಾಂತ್ರಿಕ ದಾಖಲೆಗಳಿಗೆ (technical docs) ವಿಫಲವಾಯಿತು. ತಾಂತ್ರಿಕ ಬಳಕೆದಾರರಿಗೆ ನಿಖರವಾದ ಕೀವರ್ಡ್ ಹೊಂದಾಣಿಕೆಗಳು ಬೇಕಾಗುತ್ತವೆ. ಪರಿಹಾರ: ಡೈನಾಮಿಕ್ ವೇಟ್ಸ್ (dynamic weights) ಬಳಸಿ.
- ಸತ್ಯಾಂಶದ ಕ್ವೇರಿಗಳು (Factual queries): 35% ವೆಕ್ಟರ್, 65% ಕೀವರ್ಡ್.
- ಸೆಮ್ಯಾಂಟಿಕ್ ಕ್ವೇರಿಗಳು (Semantic queries): 75% ವೆಕ್ಟರ್, 25% ಕೀವರ್ಡ್.
- ಸಾಮಾನ್ಯ ಕ್ವೇರಿಗಳು (General queries): 60% ವೆಕ್ಟರ್, 40% ಕೀವರ್ಡ್.
- HNSW ಪ್ಯಾರಾಮೀಟರ್ಗಳನ್ನು ಅತಿಯಾಗಿ ಟ್ಯೂನ್ ಮಾಡುವುದು (Over-tuning HNSW Parameters)
ನಾನು
ef_constructionಅನ್ನು ಗರಿಷ್ಠ ಮಟ್ಟಕ್ಕೆ ಹೊಂದ设置 ಮಾಡಿದೆ. ಇದು ನನ್ನ ಸರ್ವರ್ ಅನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡಿತು. ಇದು ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ RAM ಅನ್ನು ಬಳಸಿಕೊಂಡಿತು. ಪರಿಹಾರ: ಸೂಕ್ತವಾದ ಪ್ಯಾರಾಮೀಟರ್ಗಳನ್ನು ಬಳಸಿ.
Mಅನ್ನು 8 ಮತ್ತು 32 ರ ನಡುವೆ ಹೊಂದಿಸಿ.ef_constructionಅನ್ನು 200 ಕ್ಕೆ ಹೊಂದಿಸಿ.ef_searchಅನ್ನು 50 ಕ್ಕೆ ಹೊಂದಿಸಿ. ಮೆಮೊರಿ ಬಳಕೆ 70% ರಷ್ಟು ಕಡಿಮೆಯಾಯಿತು.
ಸಾಮಾನ್ಯ ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್ಗಳು (General Embedding Models) ನಾನು ವಿಕಿಪೀಡಿಯಾದ ಮೇಲೆ ತರಬೇತಿ ಪಡೆದ ಮಾಡೆಲ್ ಅನ್ನು ಬಳಸಿದೆ. ನನ್ನ ದಾಖಲೆಗಳು ತಾಂತ್ರಿಕ ಇಂಜಿನಿಯರಿಂಗ್ ರನ್ಬುಕ್ಗಳಾಗಿದ್ದವು. ಮಾಡೆಲ್ ನನ್ನ ಡೊಮೇನ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲಿಲ್ಲ. ಪರಿಹಾರ: ತಾಂತ್ರಿಕ ಅಥವಾ ಕೋಡ್ ವಿಷಯಕ್ಕಾಗಿ ಫೈನ್-ಟ್ಯೂನ್ ಮಾಡಲಾದ (fine-tuned) ಮಾಡೆಲ್ ಬಳಸಿ.
ಕ್ವೇರಿ ರಿರೈಟಿಂಗ್ ಇಲ್ಲದಿರುವುದು (No Query Rewriting) ಬಳಕೆದಾರರು ನೈಸರ್ಗಿಕ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತಾರೆ. ತಾಂತ್ರಿಕ ದಾಖಲೆಗಳು ಔಪಚಾರಿಕ ಪದಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಅವುಗಳು ಹೊಂದಾಣಿಕೆಯಾಗುವುದಿಲ್ಲ. ಪರಿಹಾರ: ಕ್ವೇರಿಗಳನ್ನು ಮರುಬರೆಯಲು (rewrite) ಲೈಟ್ವೇಯ್ಟ್ LLM ಹಂತವನ್ನು ಸೇರಿಸಿ.
- ಬಳಕೆದಾರರು ಕೇಳುತ್ತಾರೆ: "why is my build slow"
- ಸಿಸ್ಟಮ್ ಇದನ್ನು ಹೀಗೆ ಮರುಬರೆಯುತ್ತದೆ: "CI pipeline performance optimization"
- ಇದು ರಿಕಾಲ್ (recall) ಅನ್ನು 40% ಸುಧಾರಿಸಿತು.
ಅನಗತ್ಯ ಫಲಿತಾಂಶಗಳು (Redundant Results) ಟಾಪ್-10 ಚಂಕ್ಗಳನ್ನು ಪಡೆಯುವಾಗ ಹೆಚ್ಚಾಗಿ ಒಂದೇ ಪ್ಯಾರಾಗ್ರಾಫ್ ಮೂರು ಬಾರಿ ಬರುತ್ತಿತ್ತು. LLM ತನ್ನನ್ನೇ ತಾನು ಪುನರಾವರ್ತಿಸುತ್ತಿತ್ತು. ಪರಿಹಾರ: ಫಲಿತಾಂಶಗಳಲ್ಲಿ ವೈವಿಧ್ಯತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು Maximal Marginal Relevance (MMR) ಬಳಸಿ.
ತಪ್ಪು ವಿಷಯವನ್ನು ಪರೀಕ್ಷಿಸುವುದು (Testing the Wrong Thing) ನಾನು ಇಡೀ ಪೈಪ್ಲೈನ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ಪರೀಕ್ಷಿಸಿದೆ. ಸಮಸ್ಯೆ ರಿಟ್ರಿವಲ್ (retrieval) ಅಥವಾ LLM ಇರಬಹುದು ಎಂದು ನನಗೆ ತಿಳಿದಿರಲಿಲ್ಲ. ಪರಿಹಾರ: ರಿಟ್ರಿವಲ್ ಮೌಲ್ಯಮಾಪನವನ್ನು (retrieval evaluation) ಪ್ರತ್ಯೇಕಿಸಿ.
- ಹಿಟ್ ರೇಟ್ (hit rate) ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ.
- Mean Reciprocal Rank (MRR) ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ.
- 100 ಕ್ವೇರಿ-ಡಾಕ್ಯುಮೆಂಟ್ ಜೋಡಿಗಳ ಟೆಸ್ಟ್ ಸೆಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿ.
ತಿದ್ದುಪಡಿಗಳ ನಂತರದ ಫಲಿತಾಂಶಗಳು:
- ಉತ್ತರದ ಪ್ರಸ್ತುತತೆ: 45% ರಿಂದ 85%
- Latency: 3.2s ರಿಂದ 1.8s
- ಮಾಸಿಕ ವೆಚ್ಚ: $180 ರಿಂದ $95
ಮೊದಲು chunking ಅನ್ನು ಸರಿಪಡಿಸಿ. ನಂತರ weights. ನಂತರ embedding quality.