ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಾನು Python ನಲ್ಲಿ ಶೂನ್ಯದಿಂದಲೇ RAG ಅನ್ನು ನಿರ್ಮಿಸಿದೆ

ನಾನು ಆರು ತಿಂಗಳ ಕಾಲ production ನಲ್ಲಿ LangChain ಅನ್ನು ಬಳಸಿದೆ. ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ನನಗೆ ವಿವರಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ನಾನು ನಿರ್ದಿಷ್ಟ metrics ಅನ್ನು ಏಕೆ ಆರಿಸಿಕೊಂಡೆ ಅಥವಾ ಪಠ್ಯವು (text) vectors ಆಗಿ ಹೇಗೆ ಬದಲಾಯಿತು ಎಂಬುದು ನನಗೆ ತಿಳಿದಿರಲಿಲ್ಲ. ಆ library ತರ್ಕವನ್ನು (logic) ಮರೆಮಾಚುತ್ತಿತ್ತು.

ಇದನ್ನು ಸರಿಪಡಿಸಲು, ನಾನು framework ಅನ್ನು ತೆಗೆದುಹಾಕಿದೆ. ನಾನು 500 ಸಾಲುಗಳ ಸರಳ Python ಬಳಸಿ ಶೂನ್ಯದಿಂದಲೇ ಒಂದು RAG pipeline ಅನ್ನು ಬರೆದೆ.

ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ ನಿರ್ಮಿಸುವುದರಿಂದ ನಾನು ಕಲಿತ ವಿಷಯಗಳು ಇಲ್ಲಿವೆ.

Black Boxes ಗಳ ಸಮಸ್ಯೆ

ನೀವು high-level libraries ಬಳಸಿದಾಗ, ನೀವು ನಿಯಂತ್ರಣವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ಮಾಡೆಲ್‌ಗಳು ತಪ್ಪು ಮಾಹಿತಿ ನೀಡುತ್ತಿರುವುದನ್ನು (hallucinate) ಅಥವಾ ತಪ್ಪಾದ ಉಲ್ಲೇಖಗಳನ್ನು (citations) ನೀಡುತ್ತಿರುವುದನ್ನು ನಾನು ನೋಡಿದೆ. ಆ ದೋಷವು chunker ನಲ್ಲಿ ಇದೆಯೇ, embedding model ನಲ್ಲಿ ಇದೆಯೇ ಅಥವಾ prompt ನಲ್ಲಿ ಇದೆಯೇ ಎಂದು ನನಗೆ ತಿಳಿಯಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.

ನೀವು ಅದನ್ನು ಸ್ವತಃ ನಿರ್ಮಿಸಿದಾಗ, ಪ್ರತಿಯೊಂದು ಪದರವನ್ನು (layer) ಪರೀಕ್ಷಿಸಬಹುದು. LLM ಗೆ ಕಳುಹಿಸಲಾದ ನಿಖರವಾದ chunks ಅನ್ನು ನೀವು ಪ್ರಿಂಟ್ ಮಾಡಬಹುದು. ಒಂದು ವಾಕ್ಯ ಎಲ್ಲಿ ವಿಭಜನೆಯಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನಿಖರವಾಗಿ ನೋಡಬಹುದು.

RAG ನ ಐದು ಪದರಗಳು

RAG ಎಂಬುದು ಕೇವಲ ಒಂದು ಅಲ್ಗಾರಿದಮ್ ಅಲ್ಲ. ಇದು ಒಟ್ಟಿಗೆ ಸೇರಿಸಲಾದ ಐದು ವಿಭಿನ್ನ ಪ್ರಕ್ರಿಯೆಗಳಾಗಿವೆ:

  • Chunking: ಪಠ್ಯವನ್ನು ಹೇಗೆ ವಿಭಜಿಸಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುವುದು.
  • Embedding: ಪಠ್ಯವನ್ನು ಗಣಿತದ ರೂಪಕ್ಕೆ ಪರಿವರ್ತಿಸುವುದು.
  • Retrieval: ಸರಿಯಾದ ಭಾಗಗಳನ್ನು ಹುಡುಕುವುದು.
  • Prompt Construction: ಮಾಡೆಲ್ ಹೇಗೆ ವರ್ತಿಸಬೇಕು ಎಂದು ತಿಳಿಸುವುದು.
  • Generation: ಅಂತಿಮ ಉತ್ತರವನ್ನು ಪಡೆಯುವುದು.

ನಿರ್ಮಾಣದಿಂದ ಕಲಿತ ಪಾಠಗಳು

  1. Chunking ಅತ್ಯಂತ ಪ್ರಮುಖವಾದ ಹಂತವಾಗಿದೆ ಹೆಚ್ಚಿನ ಟ್ಯುಟೋರಿಯಲ್‌ಗಳು ಇದನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತವೆ. ನೀವು overlap ಬಳಸದಿದ್ದರೆ, ಗಡಿಭಾಗಗಳಲ್ಲಿ (boundaries) ಸಂದರ್ಭವನ್ನು (context) ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ನಾನು character-level overlap ಹೊಂದಿರುವ sliding window ಅನ್ನು ಬಳಸಿದೆ. ಇದು ಎರಡು chunks ನಡುವಿನ ಸಂಬಂಧವನ್ನು ಮಾಡೆಲ್ ನೋಡುವಂತೆ ಮಾಡುತ್ತದೆ.

  2. Distance metrics ಮುಖ್ಯವಾಗಿವೆ ಕೆಟ್ಟ ಸರ್ಚ್ ರಿಸಲ್ಟ್‌ಗಳನ್ನು ಡೀಬಗ್ ಮಾಡಲು ನಾನು ಗಂಟೆಗಟ್ಟಲೆ ಸಮಯ ವ್ಯಯಿಸಿದೆ. ಸಮಸ್ಯೆ ಡೇಟಾದಲ್ಲಿರಲಿಲ್ಲ, ಅದು metric ನಲ್ಲಿತ್ತು. ChromaDB mặc định ಆಗಿ L2 distance ಅನ್ನು ಬಳಸುತ್ತದೆ. Semantic search ಗಾಗಿ, ನಿಮಗೆ Cosine similarity ಬೇಕಾಗುತ್ತದೆ. ಕೇವಲ ಒಂದು ಸಾಲಿನ ಕೋಡ್ ಎಲ್ಲವನ್ನೂ ಬದಲಾಯಿಸಿತು.

  3. Prompts ಗಳಿಗೆ ನಿರ್ಬಂಧಗಳ ಅಗತ್ಯವಿದೆ LLM ಎಂಬುದು ಒಂದು ಪೂರಕ ಸಾಧನವೇ ಹೊರತು ಭವಿಷ್ಯ ನುಡಿಯುವ ವರನಲ್ಲ (oracle). ನೀವು ಅಸ್ಪಷ್ಟ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಿದರೆ, ಅದು ಉತ್ತರವನ್ನು ತಾನೇ ಸೃಷ್ಟಿಸುತ್ತದೆ. ನಾನು ಕಟ್ಟುನಿಟ್ಟಾದ refusal template ಬಳಸುವುದನ್ನು ಕಲಿತೆ. ನಾನು ಮಾಡೆಲ್‌ಗೆ ಹೀಗೆ ಹೇಳಿದೆ: "ಸಂದರ್ಭದಲ್ಲಿ (context) ಉತ್ತರ ಇಲ್ಲದಿದ್ದರೆ, ನಿಮಗೆ ತಿಳಿದಿಲ್ಲ ಎಂದು ಹೇಳಿ." ಇದು hallucinations ಅನ್ನು 40% ರಿಂದ 5% ಕ್ಕೆ ಇಳಿಸಿತು.

  4. ನಿಮ್ಮ ರಿಕ್ವೆಸ್ಟ್‌ಗಳನ್ನು batch ಮಾಡಿ ಪ್ರತಿ chunk ಗಾಗಿ ಒಂದು HTTP request ಕಳುಹಿಸುವುದು ನಿಧಾನವಾಗಿರುತ್ತದೆ. ಅವುಗಳನ್ನು batches ನಲ್ಲಿ ಕಳುಹಿಸುವುದು ಹೆಚ್ಚು ವೇಗವಾಗಿರುತ್ತದೆ. ಇದು ಲೋಕಲ್ ಮಾಡೆಲ್ ಕೆಲಸವನ್ನು pipeline ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

  5. ಕೆಳಗಿನಿಂದ ಮೇಲಕ್ಕೆ ಪರೀಕ್ಷಿಸಿ (Test from the bottom up) ಪರೀಕ್ಷೆಗಳನ್ನು ಕೊನೆಯಲ್ಲಿ ಬರೆಯಬೇಡಿ. ಮೊದಲು ನಿಮ್ಮ chunker ಅನ್ನು ಪರೀಕ್ಷಿಸಿ. ನಂತರ ನಿಮ್ಮ embedder ಅನ್ನು ಪರೀಕ್ಷಿಸಿ. ನಂತರ ನಿಮ್ಮ store ಅನ್ನು ಪರೀಕ್ಷಿಸಿ. ನೀವು ಕೊನೆಯಲ್ಲಿ ಪರೀಕ್ಷಿಸಿದರೆ, ನೀವು ತರ್ಕವನ್ನು (logic) ಪರೀಕ್ಷಿಸುವ ಬದಲು ಬಗ್‌ಗಳನ್ನು (bugs) ಪರೀಕ್ಷಿಸುತ್ತೀರಿ.

ನಿಮ್ಮ AI stack ಅನ್ನು ನೀವು ನಿಜವಾಗಿಯೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಿಲ್ಲ ಎಂದು ನಿಮಗೆ ಅನಿಸಿದರೆ, ಅದನ್ನು ನೀವೇ ನಿರ್ಮಿಸಿ. ಕೋಡ್ ಗುರಿಯಲ್ಲ, ಆಲೋಚನೆಯೇ ಗುರಿ.

Source: https://dev.to/avinash_zala_1c6f5e7c4af9/i-built-rag-from-scratch-in-python-to-understand-it-heres-what-i-learned-33kf

Optional learning community: https://t.me/GyaanSetuAi