ಇತ್ತೀಚೆಗೆ RAGಗೆ ಕೆಲವೊಮ್ಮೆ ಕೆಟ್ಟ ಹೆಸರು ಬರುತ್ತಿದೆ. ಈಗ ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಸರಳವೆಂದು ಜನರು ಭಾವಿಸುವುದು ಇದಕ್ಕೆ ಒಂದು ಕಾರಣ (ಪ್ರಾರಂಭಿಸುವುದು ಸುಲಭ, ಆದರೆ ದೊಡ್ಡ ಪ್ರಮಾಣಕ್ಕೆ ವಿಸ್ತರಿಸುವುದು ಅಷ್ಟು ಸುಲಭವಲ್ಲ). ಇಲ್ಲವೇ, ‘ಏಜೆಂಟ್ ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಗಳು’ ಅದನ್ನು ಹಿಂದಿಕ್ಕಿವೆ ಎಂದು ಅವರು ಭಾವಿಸುತ್ತಾರೆ (ಆದರೆ ಅನೇಕ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸ್ವಲ್ಪ ಆಳವಾಗಿ ನೋಡಿದರೆ ಅವು ಬಹುಬೇಗ RAGನಂತೆಯೇ ಕಾಣಲಾರಂಭಿಸುತ್ತವೆ…).
ಕೆಲವು ಸಾಮಾನ್ಯ ಸವಾಲುಗಳನ್ನು ನಾವು ಹೇಗೆ ನಿಭಾಯಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ತೋರಿಸಲು ಈ ಬ್ಲಾಗ್ ಒಂದೆರಡು ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಗಳನ್ನು ನೀಡುತ್ತದೆ. ಅವುಗಳೆಂದರೆ:
ಪಠ್ಯ ಮತ್ತು ಸಂಖ್ಯಾತ್ಮಕ ದತ್ತಾಂಶದ ಮಿಶ್ರಣವನ್ನು ನಿಭಾಯಿಸುವುದು ಹಾಗೂ ಅದು ಸರಳ RAG ಅನ್ನು ಏಕೆ ವಿಫಲಗೊಳಿಸುತ್ತದೆ: ಕೀವರ್ಡ್ಗಳು ಒಂದಕ್ಕೊಂದು ಅಡ್ಡಿಯಾಗುತ್ತವೆ ಮತ್ತು ಸಂಖ್ಯೆಗಳಿಗೆ ಶಬ್ದಾರ್ಥವಿರುವುದಿಲ್ಲ.
ಮೊದಲು ಸಾರಾಂಶ ರಚಿಸುವ ಎಂಬೆಡಿಂಗ್ಗಳ ವಿನ್ಯಾಸ ಏಕೆ ಸಹಾಯಕ: ಪ್ರತಿ ತುಣುಕಿಗೆ ಚಿಕ್ಕ ವಿವರಣಾತ್ಮಕ ಸಾರಾಂಶವನ್ನು ರಚಿಸಿ, ನಂತರ ಆ ಸಾರಾಂಶವನ್ನು ಎಂಬೆಡ್ ಮಾಡಿ ಮತ್ತು ಅದರ ಮೇಲೆ ಪ್ರಶ್ನೆ ಚಲಾಯಿಸಿ.
ಸಂದರ್ಭಸಹಿತ ಸಾರಾಂಶಗಳನ್ನು ರಚಿಸುವುದು ಹೇಗೆ: ಒಂದೇ ರೀತಿಯ ಅಂಕಿಅಂಶಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಸ್ಪಷ್ಟವಾಗಿರಲು ಮೂಲ ದಾಖಲೆಯ ಸಂದರ್ಭವನ್ನು ಸೇರಿಸಿ.
ಕೋಡ್ ಮತ್ತು Pydantic ಮಾಡೆಲ್ಗಳನ್ನು ಯಾವಾಗ ಅವಲಂಬಿಸಬೇಕು: ವಿಷಯವನ್ನು ಯಥಾವತ್ತಾಗಿ ಉಳಿಸುವುದು ಮುಖ್ಯವಾದಲ್ಲಿ, ವಿಶ್ವಾಸಾರ್ಹತೆಗಾಗಿ ಕಸ್ಟಮ್ ಕೋಡ್ ಮತ್ತು/ಅಥವಾ Pydantic ಮಾಡೆಲ್ ಅನ್ನು LLM ಕರೆಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಿ.
ಮೂಲಭೂತ ಅಂಶಗಳು
ಬೆಂಬಲ ಬಾಟ್ಗಳಿಂದ ಹಿಡಿದು ಆಂತರಿಕ ಜ್ಞಾನ ಸಹಾಯಕರವರೆಗೆ ಅನೇಕ ಸಾಧನಗಳಿಗೆ RAG ವ್ಯವಸ್ಥೆಗಳು ಶಕ್ತಿ ನೀಡುತ್ತವೆ.
ಆಂತರಿಕವಾಗಿ ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಹೀಗೆ ಮಾಡುತ್ತೀರಿ:
ನಿಮ್ಮ ಮೂಲ ದಾಖಲೆಗಳನ್ನು ತುಣುಕುಗಳಾಗಿ ವಿಭಜಿಸಿ.
ಪ್ರತಿ ತುಣುಕನ್ನು ವೆಕ್ಟರ್ ಅವಕಾಶದಲ್ಲಿ ಎಂಬೆಡ್ ಮಾಡಿ.
ಪ್ರಶ್ನೆಯ ಸಮಯದಲ್ಲಿ ಅಗ್ರ-K ತುಣುಕುಗಳನ್ನು ಹಿಂಪಡೆಯಿರಿ.
ಆ ತುಣುಕುಗಳನ್ನು ಆಧರಿಸಿ ಉತ್ತರವನ್ನು ರಚಿಸಿ.
LangChain, LlamaIndex ಮತ್ತು OpenAIನ Filestoreನಂತಹ ಜನಪ್ರಿಯ ಪರಿಕರಗಳು ಆ ಹಂತಗಳನ್ನು ಬಹುತೇಕ ಸರಳಗೊಳಿಸುತ್ತವೆ. ಆದರೆ ವಾಸ್ತವಿಕ ಬಳಕೆಯ ಪೈಪ್ಲೈನ್ಗಳಲ್ಲಿ ಕೇವಲ ಸಾಂದ್ರ ಪಠ್ಯವಲ್ಲದ ದತ್ತಾಂಶವೂ ಎದುರಾಗುತ್ತದೆ ಮತ್ತು ಮೂಲಭೂತ RAG ಅದನ್ನು ನಿಭಾಯಿಸಲು ಕಷ್ಟಪಡಬಹುದು. ಮುಂದಿನ ವಿಭಾಗಗಳಲ್ಲಿ ದತ್ತಾಂಶದ ಸವಾಲುಗಳ ನೈಜ ಉದಾಹರಣೆಗಳನ್ನು ತೋರಿಸಿ, ಸಂಕೀರ್ಣತೆ ಹೆಚ್ಚಾದಂತೆ ಪರಿಹಾರವನ್ನು ಹಂತಹಂತವಾಗಿ ನಿರ್ಮಿಸುತ್ತೇವೆ.
ನಿಮ್ಮ ದತ್ತಾಂಶ ಕೇವಲ ಪಠ್ಯವಾಗಿಲ್ಲದಾಗ (ಇದು ನಿಜಕ್ಕೂ ಸಾಮಾನ್ಯ)
ಆಟದ ಸಂದರ್ಭದಲ್ಲಿ ಕೆಳಗಿನ ದತ್ತಾಂಶ ತುಣುಕನ್ನು ಪರಿಗಣಿಸಿ:
JSON
ಶಬ್ದಾರ್ಥ ಮತ್ತು ವ್ಯಾಕರಣದ ಮೂಲಕ ಪದಗಳ ನಡುವೆ ಕಲಿತ ಸಂಬಂಧಗಳಿಂದಾಗಿ ಎಂಬೆಡಿಂಗ್ಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಮೇಲಿನ ದತ್ತಾಂಶದಲ್ಲಿ ಪಠ್ಯ ಮತ್ತು ಸಂಖ್ಯೆಗಳು ಬೆರೆತಿವೆ. ಈ ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭದ ಹೊರಗೆ ಆ ಸಂಖ್ಯೆಗಳಿಗೆ ಪದಗಳೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ. ಹಾಗಾಗಿ ಈ ದತ್ತಾಂಶ ತುಣುಕು ಸ್ವಲ್ಪ ವಿವರಣಾತ್ಮಕ ಪದಗಳ ನಂತರ ಕೆಲವು ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಗಳು ಬರುವ ಸಂಯೋಜನೆ ಎಂದು ಹೇಳಬಹುದು.
ನಮ್ಮ ಬಳಿ ಇಂತಹ ದತ್ತಾಂಶ ಮಾತ್ರ ಇದ್ದಿದ್ದರೆ ಇದು ಸಮಸ್ಯೆಯಾಗುತ್ತಿರಲಿಲ್ಲ. ಏಕೆಂದರೆ ಲಭ್ಯವಿರುವ ಕೆಲವೇ ವಿವರಣಾತ್ಮಕ ಪದಗಳ ಎಂಬೆಡಿಂಗ್ಗಳ ಮೂಲಕವೂ ಅದನ್ನು ಹಿಂಪಡೆಯಬಹುದಿತ್ತು (ಅಥವಾ ಪಠ್ಯದಿಂದ-SQLಗೆ ಪರಿವರ್ತನೆಯನ್ನು ಬಳಸಬಹುದಿತ್ತು). ಆದರೆ ಇದೇ ಪದಗಳಿರುವ ಅನೇಕ ಸಾಂದ್ರ ಪಠ್ಯ ತುಣುಕುಗಳ ನಡುವೆ ಈ ತುಣುಕು ಹುದುಗಿದ್ದರೆ ಏನಾಗುತ್ತದೆ? ಉದಾಹರಣೆಗೆ:
JSON
ಈಗ ನಾವು “ಡ್ರಾಕಾನಿಕ್ ಅಸೆನ್ಷನ್ನೊಂದಿಗೆ ದಾಳಿಯ ವ್ಯಾಪ್ತಿ ಎಷ್ಟು?” ಎಂಬುದನ್ನು ಹಿಂಪಡೆಯಲು ಬಯಸುತ್ತೇವೆಂದು ಊಹಿಸಿ.ಬಹುಶಃ ನಮಗೆ ಬೇಕಾದ ಸಂಬಂಧಿತ ತುಣುಕನ್ನು ಹಿಂಪಡೆಯಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಏಕೆಂದರೆ ಅದೇ ಕೀವರ್ಡ್ಗಳನ್ನು ಹೊಂದಿರುವ ಇತರ ತುಣುಕುಗಳ ಗದ್ದಲದಲ್ಲಿ ಅದು ಹುದುಗಿರುತ್ತದೆ.
ಒಂದೇ ವಿಷಯದ ಕುರಿತು ವಿಭಿನ್ನ ರೀತಿಯ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿದ್ದರೂ ಈ ದತ್ತಾಂಶ ತುಣುಕುಗಳನ್ನು ಸರಿಯಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲು ಸಾಧ್ಯವಾಗದಿರುವುದೇ ಮೂಲ ಸಮಸ್ಯೆ. ನಾವು ಅದನ್ನು ಹೇಗಾದರೂ ಸಮೃದ್ಧಗೊಳಿಸಿ ಸುಧಾರಿಸಬಹುದೇ? ಖಂಡಿತ ಸಾಧ್ಯ :smile:
ನಿಮ್ಮ ದತ್ತಾಂಶವನ್ನು ಸಾರಾಂಶಗೊಳಿಸಿ ಸಮೃದ್ಧಗೊಳಿಸಿ. ಹೌದು, ನೀವು ಸರಿಯಾಗಿಯೇ ಓದಿದ್ದೀರಿ.
ತುಣುಕನ್ನೇ ನೇರವಾಗಿ ಎಂಬೆಡ್ ಮಾಡುವ ಬದಲು, ಮೊದಲು ಆ ದತ್ತಾಂಶ ಯಾವುದರ ಕುರಿತು ಇದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುವ ಸಾರಾಂಶ ರಚಿಸಬಹುದು. ನಂತರ ಆ ಸಾರಾಂಶವನ್ನು ಎಂಬೆಡ್ ಮಾಡಿ, ಅದರ ಆಧಾರದಲ್ಲಿ ಹಿಂಪಡೆಯಬಹುದು. ರಚನೆಯ ಹಂತದಲ್ಲಿ ಸಾರಾಂಶಕ್ಕೆ ಜೋಡಿಸಲಾದ ಮೂಲ ದತ್ತಾಂಶವನ್ನೇ ಬಳಸುತ್ತೇವೆ.
ಹಾಗಾಗಿ ಮೇಲೆ ತೋರಿಸಿದ ಎರಡು ತುಣುಕುಗಳಿಗಾಗಿ ಈ ರೀತಿಯ ಸಾರಾಂಶಗಳನ್ನು ರಚಿಸುತ್ತೇವೆ:
ವ್ಯಾಪ್ತಿ, ವೇಗ ಮತ್ತು ಹಾನಿಯ ದಾಳಿ ಅಂಕಿಅಂಶಗಳು (ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಮತ್ತು ಡ್ರಾಕಾನಿಕ್ ಅಸೆನ್ಷನ್ನೊಂದಿಗೆ).
ಸಕ್ರಿಯಗೊಳಿಸುವ ಷರತ್ತುಗಳು, ದೃಶ್ಯ ಪರಿಣಾಮಗಳು ಮತ್ತು ಹಿನ್ನೆಲೆ ಕಥೆ ಸೇರಿದಂತೆ ಡ್ರಾಕಾನಿಕ್ ಅಸೆನ್ಷನ್ನ ವಿವರಣೆ ಮತ್ತು ವಿವರಗಳು.
ನಂತರ ಸಾರಾಂಶದೊಂದಿಗೆ “ಹೊಂದಾಣಿಕೆ” ಆಗುವಂತೆ ಪ್ರಶ್ನೆಯನ್ನೂ ವಿಸ್ತರಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, “ಡ್ರಾಕಾನಿಕ್ ಅಸೆನ್ಷನ್ನೊಂದಿಗೆ ದಾಳಿಯ ವ್ಯಾಪ್ತಿ ಎಷ್ಟು?” ಎಂಬುದನ್ನು“ಡ್ರಾಕಾನಿಕ್ ಅಸೆನ್ಷನ್ನೊಂದಿಗೆ ದಾಳಿಯ ವ್ಯಾಪ್ತಿಯ ಅಂಕಿಅಂಶಗಳು ಯಾವುವು?” ಎಂದು ಬದಲಾಯಿಸುತ್ತೇವೆ.ತಾಂತ್ರಿಕ ಕ್ಷೇತ್ರಗಳಿಗೆ ಹೊರಗಿನ ಬಳಕೆದಾರರು ~~“ತಮ್ಮದೇ ಶೈಲಿಯಲ್ಲಿ”~~ ಸಹಜ ಮಾನವ ಭಾಷೆಯಲ್ಲಿ ಹಿಂಪಡೆಯುವಿಕೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುವಾಗ ಇದು ವಿಶೇಷವಾಗಿ ಮುಖ್ಯ. ಏಕೆಂದರೆ ನಿಖರತೆ ಮತ್ತು ಮರುಪಡೆಯುವಿಕೆಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಗರಿಷ್ಠಗೊಳಿಸಲು RAG ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದು ಅವರ ತಿಳಿವಳಿಕೆಯ ಅಥವಾ ಕಾಳಜಿಯ ವಿಷಯವಲ್ಲ.
ವಿಷಯಗಳನ್ನು ಸಂದರ್ಭದಿಂದ ಬೇರ್ಪಡಿಸಬೇಡಿ (ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಜೀವನಕ್ಕೂ ಅನ್ವಯಿಸುತ್ತದೆ)
ಮುಂದಿನ ಸನ್ನಿವೇಶದಲ್ಲಿ ಕೆಳಗಿನಂತೆ ಒಂದೇ ರೀತಿ ಕಾಣುವ ಅಪಾರ ಸಂಖ್ಯೆಯ ದತ್ತಾಂಶ ತುಣುಕುಗಳನ್ನು ನಿಭಾಯಿಸಬೇಕಾಗುತ್ತದೆ:
Plain Text
ಇದೇ ವಿಧಾನವನ್ನು ಮುಂದುವರಿಸಿದರೆ, “ಪಾತ್ರ Xನ ದಾಳಿಯ ವ್ಯಾಪ್ತಿ ಎಷ್ಟು?” ಎಂದು ಕೇಳುವುದನ್ನು ಊಹಿಸಿ.ನಾವು ಈಗಷ್ಟೇ ರಚಿಸಿದ ಸಾರಾಂಶಗಳೊಂದಿಗೆ ಅದೃಷ್ಟವನ್ನು ಅವಲಂಬಿಸಿದ ಊಹೆಯ ಆಟವಾಡಬೇಕಾಗುತ್ತದೆ. ಏಕೆಂದರೆ ಅವುಗಳೂ ಬಹಳ ಹೋಲಿಕೆಯಿಂದ ಕಾಣುತ್ತವೆ. ಹಾಗಾದರೆ ಅವುಗಳನ್ನು ಹೇಗೆ ಪ್ರತ್ಯೇಕಿಸಬಹುದು?
ಸರಳ ಉತ್ತರವೆಂದರೆ ಸಂದರ್ಭವನ್ನು ಒದಗಿಸುವುದು. ದತ್ತಾಂಶ ತುಣುಕಿನಲ್ಲಿ ಅದರ ಮೂಲ ದಾಖಲೆಯ ಉಲ್ಲೇಖವನ್ನು ಸರಳವಾಗಿ ಸೇರಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ {”ಪಾತ್ರ”: “X”}. ಹೀಗೆ ಪಾತ್ರ Y ಮತ್ತು Zಗೆ ಸಂಬಂಧಿಸಿದ ಅದೇ ದತ್ತಾಂಶ ನಮ್ಮಲ್ಲಿದ್ದರೂ ಪಾತ್ರ Xಗೆ ಸರಿಯಾದ ದತ್ತಾಂಶವನ್ನು ನಿಖರವಾಗಿ ಹಿಂಪಡೆಯಬಹುದು.
ಆದರೆ ತುಣುಕಿನ ಸಂದರ್ಭಸಹಿತ ಸಾರಾಂಶವನ್ನು ರಚಿಸುವುದು ಇನ್ನೂ ಉತ್ತಮ ಮತ್ತು ಹೆಚ್ಚು ಸಾಮಾನ್ಯೀಕರಿಸಬಹುದಾದ ವಿಧಾನ. ಅಂದರೆ, ಕೇವಲ ದತ್ತಾಂಶ ತುಣುಕಿನ ಸಾರಾಂಶವನ್ನು ರಚಿಸುವ ಬದಲು ಅದರ ಮೂಲ ದಾಖಲೆ ಮತ್ತು ತುಣುಕು ಎರಡನ್ನೂ ನೀಡಿ ಸಾಮಾನ್ಯ ಸಂದರ್ಭಸಹಿತ ಸಾರಾಂಶವನ್ನು ರಚಿಸಬಹುದು. ಈ ತುಣುಕು ತನ್ನ ಮೂಲ ದಾಖಲೆಗೆ ಹೇಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನೂ ಸಾರಾಂಶದಲ್ಲಿ ಸೇರಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ:
ಈ ತುಣುಕು ಪಾತ್ರ Xಗೆ ಸಂಬಂಧಿಸಿದ … ಕುರಿತು ವಿವರವಾದ ಅಂಕಿಅಂಶಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ದಾಳಿಯ ವೇಗದಲ್ಲಿ Xನ ಸಾಮರ್ಥ್ಯವನ್ನು ತೋರಿಸುವ ಮೂಲಕ ಈ ತುಣುಕು ಪೂರ್ಣ ದಾಖಲೆಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ…
ಈ ತುಣುಕು ಪಾತ್ರ Yಗೆ ಸಂಬಂಧಿಸಿದ … ಕುರಿತು ವಿವರವಾದ ಅಂಕಿಅಂಶಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. Yಯ ವಿಶೇಷ ಸಾಮರ್ಥ್ಯದಿಂದ ಹೆಚ್ಚಾಗುವ ಅಂಕಿಅಂಶಗಳನ್ನು ತೋರಿಸುವ ಮೂಲಕ ಈ ತುಣುಕು ಪೂರ್ಣ ದಾಖಲೆಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ…
ಈ ತುಣುಕು ಪಾತ್ರ Zಗೆ ಸಂಬಂಧಿಸಿದ … ಕುರಿತು ವಿವರವಾದ ಅಂಕಿಅಂಶಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ತಂಡದ ಪಂದ್ಯಗಳಲ್ಲಿ ಟ್ಯಾಂಕ್ ಪಾತ್ರಕ್ಕೆ ಸೂಕ್ತವಾದ Zನ ಅಂಕಿಅಂಶಗಳನ್ನು ತೋರಿಸುವ ಮೂಲಕ ಈ ತುಣುಕು ಪೂರ್ಣ ದಾಖಲೆಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ…
ಈ ವಿಧಾನವು (ಭಾಗಶಃ Anthropicನಿಂದ ಪ್ರೇರಿತವಾಗಿದೆ) ಮೇಲಿನ ಉದಾಹರಣೆಗೆ ಅಗತ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚೆಂದು ಕಾಣಬಹುದು. ಆದರೆ “ಸಂದರ್ಭದಿಂದ ಹೊರಗೆ” ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಬಹುದಾದ ತುಣುಕುಗಳಿಗೆ ಇದು ಬಹಳ ಪರಿಣಾಮಕಾರಿ. ಜೊತೆಗೆ, ಎಲ್ಲ ತುಣುಕುಗಳಿಗೂ ಅನ್ವಯಿಸುವ ಏಕರೂಪದ ವಿಧಾನವನ್ನು ಒದಗಿಸಿ, ಎಂಜಿನಿಯರಿಂಗ್ ಪೈಪ್ಲೈನ್ ಅನ್ನು ಅಚ್ಚುಕಟ್ಟಾಗಿ ಇಡುತ್ತದೆ.
ನೀವು ~~ಎಲ್ಲವನ್ನೂ ನಿಯಂತ್ರಿಸುವವರಾಗದೆ~~ ಕಟ್ಟುನಿಟ್ಟಾಗಿರಬೇಕಾದಾಗ
ಸಾಮಾನ್ಯವಾಗಿ ನಮಗೆ ದತ್ತಾಂಶ ಸಂಪೂರ್ಣ ಘಟಕಗಳಾಗಿ ಸಿಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು RAG ವ್ಯವಸ್ಥೆಗಾಗಿ ತುಣುಕುಗಳಾಗಿ ವಿಭಜಿಸುತ್ತೇವೆ. ಈ ಉದಾಹರಣೆಯಲ್ಲಿ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾದುದನ್ನು ತೋರಿಸುತ್ತೇವೆ. ದತ್ತಾಂಶವನ್ನು ತುಣುಕುಗಳಾಗಿ ವಿಭಜಿಸಲಾಗಿದೆ, ಆದರೆ ಅವು ಕಳಪೆ ತುಣುಕುಗಳು. ವಾಸ್ತವವಾಗಿ ಮತ್ತೆ ಒಟ್ಟುಗೂಡಿಸಬೇಕಾದ ತಾರ್ಕಿಕ ತುಣುಕಿನ ಯಾದೃಚ್ಛಿಕ ಭಾಗಗಳಾಗಿವೆ. ತಾರ್ಕಿಕ ತುಣುಕು ಎಂದರೆ ದಾಖಲೆಯ ಉಪವಿಭಾಗ ಅಥವಾ ಸುಸಂಬದ್ಧ ಪ್ಯಾರಾಗ್ರಾಫ್ನಂತೆ ಸಹಜವಾಗಿ ಒಟ್ಟಿಗೇ ಇರಬೇಕಾದ ವಿಷಯದ ಭಾಗ.
ಈ ದತ್ತಾಂಶದೊಂದಿಗೆ ನಮ್ಮ ಮೊದಲ ಪ್ರಯತ್ನವೆಂದರೆ ಎಲ್ಲವನ್ನೂ ಒಂದು LLM ಕರೆಗೆ ನೀಡಿ, ಅದು ಸೂಕ್ತವೆಂದು ಗ್ರಹಿಸುವಂತೆ ಅವುಗಳನ್ನು ಗುಂಪುಮಾಡಿ, ನಂತರ ಗುಂಪುಮಾಡಿದ ವಿಷಯವನ್ನು ಹಿಂತಿರುಗಿಸಲು ಕೇಳುವುದು. LLM ಇದನ್ನು ಚೆನ್ನಾಗಿ ಮಾಡಬೇಕಲ್ಲವೇ? ಹೌದು ಮತ್ತು ಇಲ್ಲ.
ಇತರ ಹಲವು ಸಂದರ್ಭಗಳಲ್ಲಿಯೂ ನಾವು ಗಮನಿಸಿದಂತೆ, ಸಂಪೂರ್ಣ ಮತ್ತು ನಿಖರವಾದ ವಿಷಯ ಅಗತ್ಯವಿದ್ದಾಗ LLMಗಳು ಸೋಮಾರಿತನ ತೋರಿಸುತ್ತವೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರುವುದಿಲ್ಲ. ವಿಶೇಷವಾಗಿ ಸಂದರ್ಭವು ದೀರ್ಘವಾಗಿರುವಾಗ ಇದು ಹೆಚ್ಚು ಕಾಣಿಸುತ್ತದೆ. ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಥವಾಗುವ ಸಂಗತಿ. ಆದರೆ ಈ ನಿರ್ದಿಷ್ಟ ಬಳಕೆಯ ಸನ್ನಿವೇಶದಲ್ಲಿ ಅದು ದೊಡ್ಡ ಅಡ್ಡಿಯಾಗಿತ್ತು. ಏಕೆಂದರೆ ನಮಗೆ ವಿಷಯವು ಪದಕ್ಕೆ ಪದ ನಿಖರವಾಗಿಯೇ ಬೇಕಿತ್ತು. ಸಾರಾಂಶ ಬೇಡ, ಮೂಲ ವಿಷಯದ ಯಾವ ಭಾಗವನ್ನೂ ಬಿಟ್ಟುಬಿಡುವಂತಿಲ್ಲ. ಯಾವುದೇ ವಿವರವನ್ನು ತಪ್ಪಿಸುವಂತಿಲ್ಲ.
ಆದರೆ “ಹೌದು” ಎನ್ನುವ ಅಂಶವೆಂದರೆ, ಮುರಿದ ತುಣುಕುಗಳ ಶಬ್ದಾರ್ಥ ಮತ್ತು ರಚನೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಲ್ಲಿ ಅದು ಅತ್ಯುತ್ತಮವಾಗಿ ಕೆಲಸ ಮಾಡಿತು. ನಿಖರವಾದ ವಿಷಯವನ್ನು ಯಥಾವತ್ತಾಗಿ ಉಲ್ಲೇಖಿಸಲು ಅದು ನಿರಾಕರಿಸದಿದ್ದರೆ ಮಾತ್ರ. ಛೇ :/
ಹಾಗಾದರೆ LLM ಉತ್ತಮವಾಗಿ ಮಾಡುವ ಕೆಲಸವನ್ನು ಬಳಸಿಕೊಂಡು, ಅದು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಕೆಲಸವನ್ನು ಹೇಗೆ ತಪ್ಪಿಸಬಹುದು? ನಾವು ನಮ್ಮ ಹಳೆಯ ಮಿತ್ರನಾದ ಕೋಡ್ನ ನೆರವು ಪಡೆದೆವು (ಇದನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡಿದ Python ಫಂಕ್ಷನ್ ಎಂದು ಓದಿ). ಜೊತೆಗೆ “ಇದಕ್ಕಿಂತ ಸರಳವಾಗಿರಲು ಸಾಧ್ಯವಿಲ್ಲ” ಎನ್ನುವಂತಹ Pydantic ಮಾಡೆಲ್ ಬಳಸಿದೆವು. ಪರಿಹಾರ ಹೀಗಿದೆ:
ಪ್ರಸ್ತುತ ತಾರ್ಕಿಕ ತುಣುಕನ್ನು ಉಳಿಸಿಕೊಂಡೇ ವಿಭಾಗಗಳ ಮೂಲಕ ಒಂದೊಂದಾಗಿ ಸಾಗಿರಿ.
ಪ್ರತಿ ವಿಭಾಗದಲ್ಲೂ LLMಗೆ ಹೀಗೆ ಕೇಳಿ: ಈ ವಿಭಾಗವು ಪ್ರಸ್ತುತ ತಾರ್ಕಿಕ ತುಣುಕಿಗೆ ಸೇರಿದ್ದೇ? Pydantic ಮಾಡೆಲ್ ಅನುಸರಿಸಿ ಹೌದು ಅಥವಾ ಇಲ್ಲ ಎಂದು ಉತ್ತರಿಸಿ.
ಹೌದಾದರೆ ವಿಭಾಗವನ್ನು ತುಣುಕಿಗೆ ಸೇರಿಸಿ. ಇಲ್ಲವಾದರೆ ಪ್ರಸ್ತುತ ತಾರ್ಕಿಕ ತುಣುಕು ಪೂರ್ಣಗೊಂಡಿರುವುದರಿಂದ ಅದನ್ನು ಯಥಾವತ್ತಾಗಿ ಹೊರತೆಗೆದು, ಆ ವಿಭಾಗದಿಂದ ಹೊಸ ತುಣುಕನ್ನು ಪ್ರಾರಂಭಿಸಿ.
ಪೂರ್ಣ ವಿಷಯವನ್ನು ಒಂದೇ ಬಾರಿ ಸಂಸ್ಕರಿಸುವುದಕ್ಕಿಂತ ಇಲ್ಲಿ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಟೋಕನ್ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ. ಆದರೆ ನಿಖರವಾದ ವಿಷಯವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದೇ ಅತಿ ಮುಖ್ಯವಾಗಿರುವ ಈ ನಿರ್ದಿಷ್ಟ ಬಳಕೆಗೆ ಆ ಅಲ್ಪ ಹೆಚ್ಚುವರಿ ವೆಚ್ಚ ಸಂಪೂರ್ಣವಾಗಿ ಸಾರ್ಥಕವಾಗಿತ್ತು.
ಇದು ಅತ್ಯಂತ ಸರಳ ಪರಿಹಾರವಾದರೂ ಒಂದು ಮುಖ್ಯ ತತ್ವವನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಕಟ್ಟುನಿಟ್ಟು ಅಗತ್ಯವಿರುವಾಗ ನಾವು ಕೇವಲ LLMಗಳನ್ನೇ ಅವಲಂಬಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅವು ಅಂತಿಮವಾಗಿ ಸಂಭವನೀಯತೆಯ ಆಧಾರದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ.
LLMಗಳ ಸಾಮರ್ಥ್ಯವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸಿಕೊಳ್ಳುತ್ತಲೇ ಊಹಿಸಬಹುದಾದ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಫಲಿತಾಂಶ ಪಡೆಯಲು ಕಸ್ಟಮ್ ಕೋಡ್ ಅಥವಾ ಫಂಕ್ಷನ್ಗಳು ಹಾಗೂ Pydantic ಮಾಡೆಲ್ಗಳನ್ನು ಬಳಸಬಹುದು.
ರಚನಾತ್ಮಕ AI ಪರಿಹಾರವನ್ನು ನಿರ್ಮಿಸುವುದು AI ಸವಾಲಾಗಿರುವಷ್ಟೇ ಎಂಜಿನಿಯರಿಂಗ್ ಸವಾಲೂ ಆಗಿದೆ. ನಿಮ್ಮದೇ ವಿಶಿಷ್ಟ ಸವಾಲುಗಳನ್ನು ಎದುರಿಸಲು ಈ ಉದಾಹರಣೆಗಳು ನಿಮಗೆ ಸ್ಫೂರ್ತಿ ನೀಡಿವೆ ಎಂದು ಆಶಿಸುತ್ತೇವೆ. ಎಂಜಿನಿಯರಿಂಗ್ಗೆ ಆದ್ಯತೆ ನೀಡುವ ರಚನಾತ್ಮಕ AI ಪರಿಹಾರಗಳ ಕುರಿತು ಇನ್ನಷ್ಟು ಓದಲು, ರೂಟರ್ ಆಧಾರಿತ ಏಜೆಂಟ್ ವ್ಯವಸ್ಥೆಯ ವಿನ್ಯಾಸದ ಕುರಿತ ನಮ್ಮ ಬ್ಲಾಗ್ ಲೇಖನವನ್ನು ನೋಡಿ.