ದೊಡ್ಡ ಪ್ರಮಾಣದ Production RAG: ಪ್ರತಿದಿನ 10,000+ ಲಿಸ್ಟಿಂಗ್ಗಳಿಂದ ಕಲಿತ ಪಾಠಗಳು
ನಾನು ಒಂದು ಜಾಬ್ ಬೋರ್ಡ್ಗಾಗಿ RAG ಪೈಪ್ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸಿದೆ. ಇದು ಸ್ಟೇಜಿಂಗ್ನಲ್ಲಿ (staging) ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡಿತು ಆದರೆ ನೈಜ ಲೋಡ್ (real load) ಬಂದಾಗ ಕಷ್ಟವಾಯಿತು. ಪ್ರತಿದಿನ ಸಾವಿರಾರು ಲಿಸ್ಟಿಂಗ್ಗಳನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡಲು ಕೇವಲ ಉತ್ತಮ ವೆಕ್ಟರ್ ಸ್ಟೋರ್ (vector store) ಇದ್ದರೆ ಸಾಲದು. ಸಿಸ್ಟಮ್ ಎಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
ಚಂಕಿಂಗ್ (chunking), ಎಂಬೆಡ್ಡಿಂಗ್ಸ್ (embeddings), ವೆಚ್ಚಗಳು ಮತ್ತು ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ (observability) ಬಗ್ಗೆ ನನ್ನ ಕಲಿಕೆಗಳು ಇಲ್ಲಿವೆ.
1. ನಿಮ್ಮ ಚಂಕಿಂಗ್ ಸ್ಟ್ರಾಟಜಿಯನ್ನು ಕೇವಲ ಊಹಿಸಬೇಡಿ
ಹೆಚ್ಚಿನ ಟ್ಯುಟೋರಿಯಲ್ಗಳು ಚಂಕಿಂಗ್ ಅನ್ನು ಒಂದು ಸರಳ ಸೆಟ್ಟಿಂಗ್ ಎಂದು ಪರಿಗಣಿಸುತ್ತವೆ. ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ, ನಿಮ್ಮ ಸ್ಟ್ರಾಟಜಿಯು ನಿಖರತೆ ಮತ್ತು ವೆಚ್ಚವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
ನಾನು ಜಾಬ್ ಲಿಸ್ಟಿಂಗ್ಗಳಿಗಾಗಿ ಮೂರು ವಿಧಾನಗಳನ್ನು ಪರೀಕ್ಷಿಸಿದೆ:
- Fixed-size chunks: ಇವು ವಿಫಲವಾದವು. ಇವು "requirements" ಮತ್ತು "benefits" ನಂತಹ ವಿಭಾಗಗಳನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ (random) ವಿಭಜಿಸಿದವು. ಇದು ಅಸ್ಪಷ್ಟವಾದ ರಿಟ್ರಿೀವಲ್ (noisy retrieval) ಅನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
- Semantic chunking: ಇದು ಉತ್ತಮವಾಗಿತ್ತು ಆದರೆ ಅಸ್ಥಿರವಾಗಿತ್ತು. ಕೆಲವು ಚಂಕ್ಗಳು ತುಂಬಾ ಉದ್ದವಾಗಿದ್ದವು ಮತ್ತು ಇತರವುಗಳು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದ್ದವು.
- Recursive character splitting with overlap: ಇದು ಅತ್ಯುತ್ತಮವಾಗಿ ಕೆಲಸ ಮಾಡಿತು. ನಾನು ಹೊಸ ಸಾಲುಗಳು (newlines) ಮತ್ತು ವಾಕ್ಯಗಳ ಆಧಾರದ ಮೇಲೆ ವಿಭಜಿಸಿದೆ. ನಾನು 50 ಟೋಕನ್ ಓವರ್ಲ್ಯಾಪ್ನೊಂದಿಗೆ 400 ಟೋಕನ್ ಗಾತ್ರವನ್ನು ಬಳಸಿದೆ. ಇದು ಎರಡು ಚಂಕ್ಗಳ ನಡುವೆ ಹರಡಿರುವ ವಾಕ್ಯಗಳು ಸಂಪರ್ಕದಲ್ಲಿರುವಂತೆ ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಪ್ರೊ ಟಿಪ್ (Pro tip): ಚಂಕಿಂಗ್ ಮಾಡುವ ಮೊದಲು ನಿಮ್ಮ ಡೇಟಾವನ್ನು ನಾರ್ಮಲೈಸ್ (Normalize) ಮಾಡಿ. Greenhouse ಅಥವಾ Lever ನಂತಹ ವಿವಿಧ ಮೂಲಗಳು ವಿಭಿನ್ನ ಫಾರ್ಮ್ಯಾಟ್ಗಳನ್ನು ನೀಡುತ್ತವೆ. ನಿಮ್ಮ ಚಂಕಿಂಗ್ ಮಾಡಿಗೆ (chunker) ಸ್ಥಿರವಾದ ರಚನೆ ಕಾಣಿಸುವಂತೆ ಮೊದಲು ಪಠ್ಯವನ್ನು (text) ಕ್ಲೀನ್ ಮಾಡಿ.
2. ಎಂಬೆಡ್ಡಿಂಗ್ಸ್: ವೆಚ್ಚ vs ನಿಖರತೆ
ನಾನು Ollama ಮೂಲಕ Llama 3.1 ಅನ್ನು OpenAI text-embedding-3-small ಗೆ ವಿರುದ್ಧವಾಗಿ ಪರೀಕ್ಷಿಸಿದೆ. ಲೋಕಲ್ ಮಾಡೆಲ್ ಉಚಿತವಾಗಿತ್ತು ಆದರೆ "equity compensation" ನಂತಹ ಡೊಮೇನ್-ನಿರ್ದಿಷ್ಟ ಪದಗಳೊಂದಿಗೆ ಕಷ್ಟಪಟ್ಟಿತು. ಇದು ಅಸ್ಪಷ್ಟ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡಿತು. OpenAI ಹೆಚ್ಚು ವೆಚ್ಚದಾಯಕವಾಗಿತ್ತು ಆದರೆ ನಿಖರವಾದ ಹೊಂದಾಣಿಕೆಗಳನ್ನು ನೀಡಿತು. ನಾನು OpenAI ಅನ್ನು ಆರಿಸಿಕೊಂಡೆ ಏಕೆಂದರೆ ಕೆಟ್ಟ ರಿಟ್ರಿೀವಲ್ ನಂತರದ LLM ಕರೆಗಳಲ್ಲಿ ಹೆಚ್ಚು ವೆಚ್ಚವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಸಮಯ ಉಳಿಸಲು, ನಾನು ನನ್ನ ವಿನಂತಿಗಳನ್ನು ಬ್ಯಾಚ್ (batch) ಮಾಡುತ್ತೇನೆ. ನಾನು ಒಂದೇ ಕರೆಯಲ್ಲಿ 100 ಚಂಕ್ಗಳವರೆಗೆ ಕಳುಹಿಸುತ್ತೇನೆ. ಇದು ವಿಳಂಬವನ್ನು (latency) ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪೈಪ್ಲೈನ್ ಅನ್ನು ವೇಗವಾಗಿಡುತ್ತದೆ.
3. ವೆಕ್ಟರ್ ಸ್ಟೋರ್ನ ವಹಿವಾಟು (The Vector Store Trade-off)
ನಾನು ಪ್ರೊಟೊಟೈಪಿಂಗ್ಗಾಗಿ Pinecone ಅನ್ನು ಬಳಸಿದೆ ಏಕೆಂದರೆ ಅದನ್ನು ಸೆಟಪ್ ಮಾಡುವುದು ಸುಲಭ ಮತ್ತು ವೇಗವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಬಳಸಿದಾಗ ವೆಚ್ಚಗಳು ತುಂಬಾ ಹೆಚ್ಚಾದವು.
ನಾನು PostgreSQL ಒಳಗಿನ pgvector ಗೆ ಬದಲಾಯಿಸಿದೆ.
- ಇದನ್ನು ಸೆಟಪ್ ಮಾಡಲು ಹೆಚ್ಚು ಕೆಲಸ ಬೇಕಾಯಿತು.
- ಇದು ಅಪಾರ ಹಣವನ್ನು ಉಳಿಸಿತು.
- ಇದು ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಕನ್ಸಿಸ್ಟೆನ್ಸಿಯನ್ನು (transactional consistency) ಒದಗಿಸಿತು.
ಎಂಬೆಡ್ಡಿಂಗ್ಗಳು ಜಾಬ್ ಡೇಟಾ ಇರುವ ಅದೇ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಇರುವುದರಿಂದ, ನಿಮ್ಮ ಬಳಿ ಒಂದು ಮೂಲ ಸತ್ಯ (source of truth) ಇರುತ್ತದೆ. ನೀವು ಎರಡು ವಿಭಿನ್ನ ಸಿಸ್ಟಮ್ಗಳನ್ನು ಸಿಂಕ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ.
4. LLM ವೆಚ್ಚಗಳನ್ನು ನಿಯಂತ್ರಿಸುವುದು
ಪ್ರತಿಯೊಂದು ಲಿಸ್ಟಿಂಗ್ ಅನ್ನು GPT-4o ಮೂಲಕ ಸ್ಕೋರ್ ಮಾಡುವುದು ದುಬಾರಿಯಾಗಿದೆ. ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾನು ಮೂರು ತಂತ್ರಗಳನ್ನು ಬಳಸಿದೆ:
- OpenAI Batch API: ನಾನು ಸ್ಕೋರ್ ಮಾಡುವ ಕೆಲಸಗಳನ್ನು ರಾತ್ರಿ ಸಮಯದಲ್ಲಿ ಪ್ರೊಸೆಸ್ ಮಾಡುತ್ತೇನೆ. ಇದು ದೊಡ್ಡ ಮಟ್ಟದ ರಿಯಾಯಿತಿಯನ್ನು ನೀಡುತ್ತದೆ.
- Caching: ಪುನರಾವರ್ತಿತ ಅಭ್ಯರ್ಥಿ ಪ್ರೊಫೈಲ್ಗಳಿಗಾಗಿ ನಾನು ಫಲಿತಾಂಶಗಳನ್ನು ಕ್ಯಾಶ್ (cache) ಮಾಡುತ್ತೇನೆ.
- Model tiering: "Sales Representative" ನಂತಹ ಸಾಮಾನ್ಯ ಪಾತ್ರಗಳಿಗಾಗಿ ನಾನು GPT-4o-mini ಅನ್ನು ಬಳಸುತ್ತೇನೆ. ನಿಖರತೆ ಅತ್ಯಗತ್ಯವಾಗಿರುವ ನಿಶ್ಚಿತ (niche) ಪಾತ್ರಗಳಿಗಾಗಿ ಮಾತ್ರ ನಾನು GPT-4o ಅನ್ನು ಬಳಸುತ್ತೇನೆ.
5. ಮೊದಲು ಅಬ್ಸರ್ವೇಬಿಲಿಟಿಯನ್ನು ನಿರ್ಮಿಸಿ
ನನ್ನ ಪೈಪ್ಲೈನ್ ಒಮ್ಮೆ ಯಾವುದೇ ಎಚ್ಚರಿಕೆ ನೀಡದೆ ವಿಫಲವಾಯಿತು. ತಪ್ಪಾದ ಡೇಟಾ (malformed data) ಖಾಲಿ ಚಂಕ್ಗಳಿಗೆ ಕಾರಣವಾಯಿತು, ಅದನ್ನು ಸಿಸ್ಟಮ್ ಯಾವುದೇ ದೋಷವಿಲ್ಲದೆ ಬಿಟ್ಟುಬಿಟ್ಟಿತು.
ನಾನು ಇದನ್ನು ಕೊರಿಲೇಷನ್ ಐಡಿ (correlation ID) ಜೊತೆಗೆ ಸ್ಟ್ರಕ್ಚರ್ಡ್ ಲಾಗಿಂಗ್ ಅನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಸರಿಪಡಿಸಿದೆ. ಇದು ಇಂಜೆಸ್ಟಿನ್ (ingestion) ನಿಂದ ಸ್ಕೋರ್ ಮಾಡುವವರೆಗೆ ಒಂದು ಲಿಸ್ಟಿಂಗ್ ಅನ್ನು ಟ್ರೇಸ್ ಮಾಡಲು ನನಗೆ ಅನುಮತಿಸಿತು. ಯಾವ ಡೇಟಾ ಮೂಲಗಳು ವಿಫಲತೆಗೆ ಕಾರಣವಾಗುತ್ತಿವೆ ಎಂಬುದನ್ನು ನಾನು ಅಂತಿಮವಾಗಿ ನೋಡಲು ಸಾಧ್ಯವಾಯಿತು.
ದೊಡ್ಡ ಪಾಠ: ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳು ಅಸ್ತವ್ಯಸ್ತವಾದ ಡೇಟಾದಿಂದ ಬರುತ್ತವೆ, AI ನಿಂದಲ್ಲ. ಮೊದಲು ನಿಮ್ಮ ಡೇಟಾ ಪ್ಲಂಬಿಂಗ್ ಅನ್ನು ಸರಿಪಡಿಸಿ.
Optional learning community: https://t.me/GyaanSetuAi