ನಾನು ಒಂದು RAG ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಿದೆ, ನಂತರ ನಾನು ಯಾವ ಕಾರನ್ನು ಇಷ್ಟಪಡುತ್ತೇನೆ ಎಂದು ಕೇಳಿದೆ. ಅದಕ್ಕೆ ಗೊತ್ತಿರಲಿಲ್ಲ.

ನಾನು Kenning ಎಂಬ ಡಾಕ್ಯುಮೆಂಟ್-ಚಾಟ್ ಟೂಲ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೇನೆ. ಬಳಕೆದಾರರು ಅಪ್‌ಲೋಡ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲು ಇದು RAG (Retrieval-Augmented Generation) ಅನ್ನು ಬಳಸುತ್ತದೆ.

ನಾನು ಇಡೀ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಬಳಸಿ ಮೊದಲಿನಿಂದಲೇ ನಿರ್ಮಿಸಿದ್ದೇನೆ:

  • Java 21 ಮತ್ತು Spring Boot
  • Spring AI
  • PostgreSQL ಜೊತೆಗೆ pgvector
  • Ollama (llama3.2:3b ಮತ್ತು nomic-embed-text ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ)
  • Docker Compose

ಪೈಪ್‌ಲೈನ್ ಈ ರೀತಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಫೈಲ್ ಅಪ್‌ಲೋಡ್ ಮಾಡುವುದು → ಪಠ್ಯವನ್ನು ಹೊರತೆಗೆಯುವುದು (Extract text) → ಪಠ್ಯವನ್ನು ಚಂಕ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸುವುದು (Chunk text) → ಚಂಕ್‌ಗಳನ್ನು ವೆಕ್ಟರ್‌ಗಳಾಗಿ ಪರಿವರ್ತಿಸುವುದು → pgvector ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದು → ಸಮಾನವಾದ ಚಂಕ್‌ಗಳಿಗಾಗಿ ಹುಡುಕುವುದು → ಚಂಕ್‌ಗಳು + ಪ್ರಶ್ನೆಯನ್ನು ಮಾಡೆಲ್‌ಗೆ ಕಳುಹಿಸುವುದು → ಮೂಲಗಳೊಂದಿಗೆ (sources) ಉತ್ತರ ಪಡೆಯುವುದು.

ಸಿಸ್ಟಮ್ ಕೆಲಸ ಮಾಡಿತು, ಆದರೆ ನಾನು ಎರಡು ವಿಭಿನ್ನ ವೈಫಲ್ಯಗಳನ್ನು ಎದುರಿಸಿದೆ. ಅವು ನೋಡಲು ಒಂದೇ ರೀತಿ ಇದ್ದವು, ಆದರೆ ಕಾರಣಗಳು ಬೇರೆಯಾಗಿದ್ದವು.

ವೈಫಲ್ಯ 1: ಮಾಡೆಲ್ ಗೊಂದಲಕ್ಕೀಡಾಯಿತು. ನಾನು ಕೇಳಿದೆ: "ಈ ಪ್ರಾಜೆಕ್ಟ್ ಯಾವ ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್ ಅನ್ನು ಬಳಸುತ್ತದೆ?" ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ಉತ್ತರ ಸ್ಪಷ್ಟವಾಗಿತ್ತು. ಮಾಡೆಲ್ ಸರಿಯಾದ ಪಠ್ಯವನ್ನು ಪಡೆದುಕೊಂಡಿತು. ಆದರೂ, ಮುಂದಿನ ವಾಕ್ಯದಲ್ಲಿ ಸರಿಯಾದ ಮಾಡೆಲ್ ಹೆಸರನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತಲೇ, ತನಗೆ ಗೊತ್ತಿಲ್ಲ ಎಂದು ಉತ್ತರಿಸಿತು.

ನನ್ನ ಸಿದ್ಧಾಂತ: 3B ಮಾಡೆಲ್ ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ. ಅದು ಸರಿಯಾದ ಡೇಟಾವನ್ನು ಪಡೆದುಕೊಂಡಿತು ಆದರೆ ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ದೊಡ್ಡ ಮಾಡೆಲ್ ಬಳಸಿದರೆ ಬಹುಶಃ ಇದು ಸರಿಹೋಗಬಹುದು.

ವೈಫಲ್ಯ 2: ಮಾಡೆಲ್‌ಗೆ ಏನೂ ಸಿಗಲಿಲ್ಲ. ನಾನು ಕೇಳಿದೆ: "ನಾನು ಯಾವ ಕಾರ್ ಬ್ರ್ಯಾಂಡ್ ಅನ್ನು ಇಷ್ಟಪಡುತ್ತೇನೆ?" ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ನಾನು BMW ಇಷ್ಟಪಡುತ್ತೇನೆ ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗಿತ್ತು. ಆದರೆ ಸಿಸ್ಟಮ್ ಯಾವುದೇ ಫಲಿತಾಂಶವನ್ನು ನೀಡಲಿಲ್ಲ. ಸಿಮಿಲಾರಿಟಿ ಸ್ಕೋರ್ (similarity score) ನನ್ನ ಮಿತಿಗಿಂತ (threshold) ತುಂಬಾ ಕಡಿಮೆ ಇತ್ತು.

ನನ್ನ ಸಿದ್ಧಾಂತ: ಚಂಕ್ ಡೈಲ್ಯೂಷನ್ (Chunk dilution). ನನ್ನ ಪರೀಕ್ಷಾ ಡಾಕ್ಯುಮೆಂಟ್ ಚಿಕ್ಕದಾಗಿತ್ತು. ಅದು Spring AI, OAuth2 ಮತ್ತು ನನ್ನ ಕಾರ್ ಇಷ್ಟದಂತಹ ಅನೇಕ ವಿಷಯಗಳನ್ನು ಒಂದೇ ಚಂಕ್‌ನಲ್ಲಿ ಬೆರೆಸಿದ್ದವು. ಆ ಚಂಕ್‌ನ ವೆಕ್ಟರ್ ಎಲ್ಲಾ ವಿಷಯಗಳ ನಡುವೆ ವಿಭಜನೆಯಾಯಿತು (diluted). ಕಾರುಗಳ ಬಗ್ಗೆ ಕೇಳಿದ ನಿರ್ದಿಷ್ಟ ಪ್ರಶ್ನೆಯು ಅಷ್ಟು ದೊಡ್ಡ ಚಂಕ್ ಎದುರು ತನ್ನ ಶಕ್ತಿಯನ್ನು ಕಳೆದುಕೊಂಡಿತು. ಉತ್ತಮ ಚಂಕಿಂಗ್ ಸ್ಟ್ರಾಟಜಿ (chunking strategy) ಬಳಸಿದರೆ ಇದನ್ನು ಸರಿಪಡಿಸಬಹುದು.

ಕಲಿತ ಪಾಠಗಳು:

  • ಸಣ್ಣ ಮಾಡೆಲ್‌ಗಳು ತಾರ್ಕಿಕ ಸಾಮರ್ಥ್ಯದಲ್ಲಿ ಮಿತಿಗಳನ್ನು ಹೊಂದಿವೆ.
  • ಸರಳವಾದ ಚಂಕಿಂಗ್ ವಿಧಾನವು ಮಾಹಿತಿಯನ್ನು ಹುಡುಕುವ ನಿಖರತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
  • ಕೇವಲ ದೋಷವನ್ನು ಸರಿಪಡಿಸುವುದಕ್ಕಿಂತ, ಅದು "ಏಕೆ" ಸಂಭವಿಸಿತು ಎಂಬುದನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದೆ.

ಆರ್ಕಿಟೆಕ್ಚರ್ ಸರಿಯಾಗಿದೆ. ಇದು ನಿಧಾನವಾಗಿದೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ತಪ್ಪಾಗಿದೆ, ಆದರೆ ಪ್ರಕ್ರಿಯೆಯು (loop) ಪೂರ್ಣಗೊಂಡಿದೆ.

ಮೂಲ: https://dev.to/mido-dev/i-built-a-rag-app-then-asked-it-what-car-i-like-it-didnt-know-583n

ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi