RAG ವಿರುದ್ಧ LLM: ತಾಂತ್ರಿಕ ವಿವರಣೆ (ವ್ಯಾಖ್ಯಾನಗಳು, ವ್ಯತ್ಯಾಸಗಳು, ಬಳಕೆ ಸಂದರ್ಭಗಳು)

LLMಗಳು ತಮ್ಮ training data‌ನ ಮಾದರಿಗಳಿಂದ ಕಲಿತ parameters‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ರಚಿಸುತ್ತವೆ. ಆ parameters‌ಗಳು ಇತ್ತೀಚಿನ ಅಥವಾ ಸಂಪೂರ್ಣ ಮಾಹಿತಿಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸದಿರಬಹುದಾದ್ದರಿಂದ, retrieval-augmented generation ಎಂಬರ್ಥದ RAG, ಹೊರಗಿನ sources‌ನಿಂದ ಡೇಟಾವನ್ನು LLM‌ನ input context‌ಗೆ ಸೇರಿಸುವ ಮೂಲಕ ಪ್ರಕ್ರಿಯೆಗೆ ಪೂರಕವಾಗುತ್ತದೆ. AI tool retrieves ಹೊರಗಿನ ಮಾಹಿತಿಯನ್ನು ಬಳಸಿಕೊಂಡು LLM‌ನ generation ಪ್ರಕ್ರಿಯೆಯನ್ನು augment ಮಾಡುತ್ತದೆ.

ವಾಸ್ತವದಲ್ಲಿ, ನಿಮ್ಮ ಆಯ್ಕೆ RAG ಅಥವಾ LLM ನಡುವೆ ಅಲ್ಲ. ಅದು ಹೈಬ್ರಿಡ್ approach ಮತ್ತು ಕೇವಲ LLM ಬಳಸುವ approach ನಡುವೆ.

ಒಂದು LLM‌ಗೆ company documentation, databases, ಅಥವಾ ವೇಗವಾಗಿ ಬದಲಾಗುವ ಮಾಹಿತಿಗೆ ಪ್ರವೇಶ ಬೇಕಾದಾಗ RAG ಅಗತ್ಯವಾಗುತ್ತದೆ. ಎಲ್ಲಾ inputs ಅನ್ನು ಬಳಕೆದಾರನೇ ಒದಗಿಸಬಲ್ಲ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಕೆಲವು ಆಡಳಿತಾತ್ಮಕ, data processing, ಮತ್ತು content creation ಕಾರ್ಯಗಳಿಗೆ LLM-only approach ಸೂಕ್ತವಾಗಿದೆ.

RAG ವಿರುದ್ಧ LLM: ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸಗಳೇನು?

• RAG ಮತ್ತು LLMಗಳು ಪರಸ್ಪರ ಪೂರಕ ವ್ಯವಸ್ಥೆಗಳಾಗಿವೆ. ನೀವು RAG ಇಲ್ಲದೆ AI model ಅನ್ನು ಬಳಸಬಹುದು (ಅದು ತನ್ನ existing parameters‌ಗಳನ್ನೇ ಸಂಪೂರ್ಣವಾಗಿ ಅವಲಂಬಿಸಿರುತ್ತದೆ), ಆದರೆ model ಇಲ್ಲದೆ RAG system ಅನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
• LLMಗಳೊಂದಿಗೆ ಇದ್ದ ಮೂರು ಪ್ರಮುಖ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು RAG ಅನ್ನು ಪರಿಚಯಿಸಲಾಯಿತು: ಹಳೆಯ ಮಾಹಿತಿ, hallucinated responses, ಮತ್ತು third-party sources ವಿರುದ್ಧ ಪರಿಶೀಲನೆಯ ಕೊರತೆ.
• RAG, LLMಗಳನ್ನು verified internal documentation, databases, ಮತ್ತು API endpoints‌ಗಳೊಂದಿಗೆ ಸಂಪರ್ಕಿಸುವುದರಿಂದ, ನೈಜ-ಜಗತ್ತಿನ ವ್ಯವಹಾರ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ AI ಅನ್ನು ಬಹಳ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿಸುತ್ತದೆ.
• ಮೇಲ್ಭಾಗದ RAG ಬಳಕೆ ಸಂದರ್ಭಗಳಲ್ಲಿ customer support chatbots, ವೇಗವಾಗಿ ಬದಲಾಗುವ data ಆಧಾರಿತ queries (ಉದಾ., industry news), ಮತ್ತು ವೈದ್ಯಕೀಯ ಮತ್ತು ಕಾನೂನು ಮುಂತಾದ ವಿಶೇಷ ಕ್ಷೇತ್ರಗಳು ಸೇರಿವೆ, ಅಲ್ಲಿ ನಿಖರತೆ ಮತ್ತು source fact-checking ಪ್ರಮುಖವಾಗಿವೆ.
• RAG‌ನ ಮೂರು ಮುಖ್ಯ ಪ್ರಕಾರಗಳಿವೆ: ನೈವ್ RAG, ಮಾಡ್ಯುಲರ್ RAG, ಮತ್ತು ಸುಧಾರಿತ RAG. ನೈವ್ RAG ಅನ್ನು ಸರಳ ಮಾಹಿತಿಯ ಮರುಪಡೆತ ಎಂದು ಉತ್ತಮವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು; ಅದೇ ವೇಳೆ ಮಾಡ್ಯುಲರ್ ಮತ್ತು ಸುಧಾರಿತ RAG ಪ್ರಶ್ನೆ ಮರುಬರಹ ಮತ್ತು ಚಂಕ್ ಆಪ್ಟಿಮೈಜೇಶನ್‌ನಂತಹ ಹೆಚ್ಚುವರಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸೇರಿಸುತ್ತವೆ.

ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿ (LLM) ಎಂದರೇನು?

LLM, ಅಥವಾ ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿ, fine-tuned parametersಗಳನ್ನು ಬಳಸಿಕೊಂಡು content ಅನ್ನು ರಚಿಸುವ ಒಂದು system. ಈ parameters‌ಗಳು LLM vocabularyಯಲ್ಲಿರುವ ಎಲ್ಲಾ tokens‌ಗಳಿಗೆ ನಿಯೋಜಿಸಲಾದ probabilities ಅನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ, ಮತ್ತು ಯಾವ token ಮುಂದಿನದಾಗಿ ಬರುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತವೆ.

RAG ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (ಮತ್ತು LLMಗಳಿಗಿಂತ ಹೇಗೆ ಭಿನ್ನವಾಗಿದೆ) ಎಂಬುದನ್ನು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, generative AI ಮೂಲಭೂತ ಮಟ್ಟದಲ್ಲಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಸಹಾಯಕವಾಗಿದೆ:

1. Tokenization: ಬಳಕೆದಾರರ prompt ಅನ್ನು tokens‌ಗಳಾಗಿ ವಿಭಜಿಸಲಾಗುತ್ತದೆ, ಅವು ಪದಗಳು, ಪದಗಳ ಭಾಗಗಳು, ಅಥವಾ ಏಕ ಅಕ್ಷರಗಳಾಗಿರಬಹುದು.
2. Embedding: Tokens ಅನ್ನು embeddings‌ಗಳಾಗಿ, ಅಂದರೆ numerical representations (ಸಂಖ್ಯೆಗಳ ಸರಣಿಗಳು) ಆಗಿರುವ vectors ಎಂದು ಪರಿವರ್ತಿಸಲಾಗುತ್ತದೆ; decoder ಒಳಗೊಂಡ neural network ಅವುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು.
3. Decoding: decoder‌ನ layers (ಇವು LLM‌ನ neural network‌ನ ದೊಡ್ಡ ಭಾಗವನ್ನು ರಚಿಸುತ್ತವೆ) ಈ vectors ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ, ಮತ್ತು ಅರ್ಥವನ್ನು ಸೆರೆಹಿಡಿಯಲು attention ಎಂಬ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬಳಸುತ್ತವೆ. ಈ ಪ್ರಕ್ರಿಯೆ sequence‌ನಲ್ಲಿರುವ ಇತರ tokens‌ಗಳಿಗೆ ಪ್ರತಿ token ಎಷ್ಟು ಬಲವಾಗಿ ಸಂಬಂಧಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
4. Scoring: model ತನ್ನ ಪೂರ್ವ-ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ vocabularyಯ ಪ್ರತಿಯೊಂದು token‌ಗೆ ಹೊಂದಾಣಿಕೆ probability ಅನ್ನು ನಿಯೋಜಿಸಿ, sequence‌ಗಾಗಿ ಮುಂದಿನ ಸಾಧ್ಯತೆಯ token ಅನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ.

ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ, LLM ತನ್ನ existing parameters ಮತ್ತು ತನ್ನ context window‌ನಲ್ಲಿರುವ tokens ಆಧರಿಸಿ ಮಾತ್ರ outputs ಅನ್ನು ರಚಿಸಬಹುದು. Training ವೇಳೆ, LLM ಅನ್ನು incomplete text‌ನ ಭಾಗಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಶತಕೋಟಿ ಬಾರಿ prompt ಮಾಡಲಾಗುತ್ತದೆ, ಮತ್ತು ಅದು tokens‌ಗಳಿಗೆ probabilities ಅನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ನಿಯೋಜಿಸುವ ತನಕ ಅದರ parameters ಹೊಂದಿಸಲಾಗುತ್ತವೆ (ಮತ್ತು ಆ ಮೂಲಕ ಪಠ್ಯವನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ).

ಉದಾಹರಣೆಗೆ, ನೀವು ಒಂದು AI model‌ಗೆ “ನಮ್ಮ ಕಂಪನಿಯ 2026 refund policy ಏನು ಹೇಳುತ್ತದೆ?” ಎಂದು ಕೇಳುತ್ತೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. LLM ತನ್ನ existing parameters ಆಧರಿಸಿ ಮುಂದಿನ tokens ಅನ್ನು ಮಾತ್ರ ಮುನ್ಸೂಚಿಸಬಲ್ಲದು; ಅವುಗಳನ್ನು ನಿಮ್ಮ support documentation ಬಳಸಿ fine-tune ಮಾಡಿಲ್ಲ. ಯಾವುದೇ ಹೆಚ್ಚುವರಿ context ಇಲ್ಲದೆ ನೀವು ಈ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಿದರೆ, ಅದು ಅರ್ಥಪೂರ್ಣವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸಂಪೂರ್ಣವಾಗಿ ಅಸಮರ್ಥವಾಗಿರುತ್ತದೆ ಅಥವಾ ತಪ್ಪಾದ ಉತ್ತರವನ್ನು hallucinate ಮಾಡುತ್ತದೆ.

Retrieval-augmented generation (RAG) ಎಂದರೇನು?

RAG (retrieval-augmented generation) ಎಂದರೆ external systems‌ನಿಂದ ಮಾಹಿತಿ LLM prompt‌ನಲ್ಲಿ ಸೇರಿಸಲ್ಪಡುವ ಪ್ರಕ್ರಿಯೆ.

ಮೂಲ LLM process, embedding ಮತ್ತು probabilistic token matching ಅನ್ನು ಒಳಗೊಂಡಿದ್ದು, ಅದೇ ರೀತಿಯಲ್ಲೇ ಉಳಿಯುತ್ತದೆ. RAG ಒಂದು ಪ್ರಾಥಮಿಕ ಹಂತವನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ, ಅದರಲ್ಲಿ ಬಳಕೆದಾರರ prompt ಅನ್ನು ಹೆಚ್ಚುವರಿ ಡೇಟಾದೊಂದಿಗೆ ವಿಸ್ತರಿಸಲಾಗುತ್ತದೆ.

RAG ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದರ ಅವಲೋಕನ ಇಲ್ಲಿದೆ:

1. Knowledge preparation: ಒಂದು knowledge source ಅನ್ನು ಸಿದ್ಧಪಡಿಸಲಾಗುತ್ತದೆ. ಇದು documentsಗಳ ಗುಚ್ಛ, vector database, knowledge graph, ಅಥವಾ live index (ಉದಾ., AI searchಗಾಗಿ) ಆಗಿರಬಹುದು.
2. Prompting: ಬಳಕೆದಾರನು ಒಂದು prompt ಅನ್ನು ನಮೂದಿಸುತ್ತಾನೆ, ಉದಾಹರಣೆಗೆ, “Should I go for a walk in London today?”
3. Retrieval: ಹೊರಗಿನ information source ಅನ್ನು AI tool‌ನ retriever ಪ್ರಶ್ನಿಸುತ್ತದೆ. ಅದು prompt ಅನ್ನು embed ಮಾಡಿ, ಅದನ್ನು vector ಆಗಿ ಪರಿವರ್ತಿಸಿ, ನಂತರ vector database ಅನ್ನು query ಮಾಡಬಹುದು. ಇಲ್ಲವೇ API call, keyword matching, ಅಥವಾ knowledge graph traversal‌ನಂತಹ ಪರ್ಯಾಯ ವಿಧಾನವನ್ನು ಬಳಸಬಹುದು.
4. Insertion: ಈ ಮಾಹಿತಿಯನ್ನು ಬಳಕೆದಾರರ ಮೂಲ prompt‌ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ. ಲಂಡನ್‌ನಲ್ಲಿ ನಡೆಯುವ ಕುರಿತ ಪ್ರಶ್ನೆಯ ಉದಾಹರಣೆಯಲ್ಲಿ, ಇದರಲ್ಲಿ ಲಂಡನ್‌ನ ಹವಾಮಾನ ಮಾಹಿತಿ ಮತ್ತು ಜನಪ್ರಿಯ ನಡೆಯುವ ಮಾರ್ಗಗಳ ಇತ್ತೀಚಿನ ಪ್ರವೇಶಸಾಧ್ಯತೆ ಸೇರಿರಬಹುದು.
5. Answer generation: LLM ವಿಸ್ತರಿಸಿದ prompt ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸಾಮಾನ್ಯ ರೀತಿಯಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ರಚಿಸುತ್ತದೆ.

ಹಿನ್ನೆಲೆಯಲ್ಲಿ, ಪಡೆದುಕೊಂಡ ಪಠ್ಯವನ್ನು input context‌ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ, tokenized ಮಾಡಲಾಗುತ್ತದೆ, ಮತ್ತು embedded ಮಾಡಲಾಗುತ್ತದೆ. ನಂತರ model ತನ್ನ decoder ಮೂಲಕ ಆ ಹೆಚ್ಚುವರಿ context ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಇದು output token probabilities ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.

ವಿಸ್ತೃತವಾಗಿ ಹೇಳುವುದಾದರೆ, RAG ಅನ್ನು ಮೂರು ಉಪಪ್ರಕಾರಗಳಾಗಿ ವಿಭಜಿಸಬಹುದು. Naive RAG ಮೂಲಭೂತ RAG ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅನುಸರಿಸಿ, ಮಾಹಿತಿಯನ್ನು ಪಡೆದು ಅದನ್ನು prompt‌ಗೆ ನೀಡುತ್ತದೆ. Advanced RAG query rewriting ಮತ್ತು multiple query passes‌ನಂತಹ ಹೆಚ್ಚುವರಿ ಕಾರ್ಯಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. Modular RAG ಎಂದರೆ ವಿಭಿನ್ನ advanced functionalities‌ಗಳನ್ನು components ಆಗಿ ಪರಿಗಣಿಸಿ, ಅಗತ್ಯವಿದ್ದಂತೆ ಸಂಯೋಜಿಸಬಹುದಾದ ಒಂದು ರೀತಿಯ architecture ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ.

RAG ವಿರುದ್ಧ LLM: ಬಳಕೆ ಸಂದರ್ಭಗಳ ಅವಲೋಕನ

RAG ಬಳಕೆದಾರರಿಗೆ ಇತ್ತೀಚಿನ ಡೇಟಾಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದರ ಫಲವಾಗಿ LLM outputs‌ನಲ್ಲಿ hallucinations ಮತ್ತು ಮಾಹಿತಿ ಖಾಲಿತನಗಳು ಕಡಿಮೆಯಾಗುವ ಸಾಧ್ಯತೆ ಇರುತ್ತದೆ. output‌ನಲ್ಲಿ ಬಳಸಲಾದ ಮಾಹಿತಿಯ ಮೂಲಗಳನ್ನು ನೀವು ನೋಡಬೇಕಾದರೆ, RAG ಕೂಡ ಅಗತ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ grounded ಅಲ್ಲದ LLM ಉತ್ತರಗಳೊಂದಿಗೆ attributions ಬರುತ್ತಿಲ್ಲ.

ವಿಸ್ತರಿಸಿ

RAG ಬಳಕೆ ಸಂದರ್ಭಗಳು

• ಸಮಯ-ಸಂವೇದನಾಶೀಲ ಮಾಹಿತಿಗಾಗಿ ವಿನಂತಿಗಳು: ತ್ವರಿತವಾಗಿ ಹಳೆಯದಾಗುವ ಮಾಹಿತಿಗಾಗಿ ಯಾವುದೇ queries, ಅದು weather forecast‌ನಷ್ಟು ಸರಳವಾಗಿರಬಹುದು ಅಥವಾ emerging news story‌ನ ವಿವರವಾದ ವಿಶ್ಲೇಷಣೆಯಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿರಬಹುದು, validated third-party sources ಆಧರಿಸಿರಬೇಕು.
• Company documentation: ಬಳಕೆದಾರರು company ಅಥವಾ product documentation‌ಗೆ ಸಂಬಂಧಿಸಿದ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುವ internal ಅಥವಾ customer-facing AI chatbots RAG-enabled ಆಗಿರಬೇಕು, ವಿಶೇಷವಾಗಿ documentation ಆಗಾಗ್ಗೆ ನವೀಕರಿಸಲ್ಪಡುತ್ತಿದ್ದರೆ.
• Customer support: ಗ್ರಾಹಕ ಚಾಟ್‌ಬಾಟ್‌ಗಳಿಗೆ ನಿಖರ ಉತ್ತರಗಳನ್ನು ನೀಡಲು ಇತ್ತೀಚಿನ, ವಿವರವಾದ support documentation‌ಗೆ ಪ್ರವೇಶ ಬೇಕಾಗುತ್ತದೆ.
• ವಿಶೇಷ ಕ್ಷೇತ್ರಗಳು (ವೈದ್ಯಕೀಯ, ಕಾನೂನು, ಹಣಕಾಸು, ಇತ್ಯಾದಿ): domain-specific corporaಗಳ ಮೇಲೆ ತರಬೇತಿ ಪಡೆದಿಲ್ಲದ LLMಗಳು (ವಿಶೇಷವಾಗಿ mainstream models) ಸಾಮಾನ್ಯವಾಗಿ specialized prompts‌ನ ಸೂಕ್ಷ್ಮತೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಕಷ್ಟಪಡುತ್ತವೆ.

LLM ಬಳಕೆ ಸಂದರ್ಭಗಳು

• Administrative tasks: LLMಗಳು ಕನಿಷ್ಠ latency‌ನೊಂದಿಗೆ ಮೂಲಭೂತ ಕಾರ್ಯಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಬಹುದು. spelling-checking ಅಥವಾ summarization‌ನಂತಹ ಮೂಲಭೂತ writing ಮತ್ತು admin tasks‌ಗಳಿಗೆ, ಹೊರಗಿನ ಮಾಹಿತಿಯ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರಣ RAG ಅನಗತ್ಯವಾಗಿದೆ.
• ಸೃಜನಾತ್ಮಕ ಕಾರ್ಯಗಳು: ಚಿಕ್ಕ ಕಥೆ ಅಥವಾ ಚಿತ್ರವನ್ನು ರಚಿಸುವಂತಹ ಕೆಲವು ಸೃಜನಾತ್ಮಕ ಕಾರ್ಯಗಳಿಗೆ ಮೂಲ prompt‌ನಲ್ಲಿ ನೀಡಿದ ಮಾಹಿತಿಯಷ್ಟೇ ಬೇಕಾಗುತ್ತದೆ.
• ರೀಜನಿಂಗ್ ಮತ್ತು ಡೇಟಾ-ಆಧಾರಿತ ಕಾರ್ಯಗಳು: ನೀವು ದೊಡ್ಡ dataset‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ರೀಜನಿಂಗ್ ಮತ್ತು ವಿಶ್ಲೇಷಣಾ ಕಾರ್ಯಗಳನ್ನು ಅನ್ವಯಿಸಲು LLM‌ಗೆ ಹೊರಗಿನ ಮಾಹಿತಿಗೆ ಪ್ರವೇಶ ಅಗತ್ಯವಿಲ್ಲ.
• ಸಾಮಾನ್ಯ ಕೋಡಿಂಗ್: ಒಂದು coding workflow‌ಗೆ private codebase ಅಥವಾ documentationಗೆ ಪ್ರವೇಶ ಬೇಕಾಗಿರಬಹುದು, ಆದರೆ LLMಗಳು ಸಾಮಾನ್ಯ coding ಕಾರ್ಯಗಳನ್ನು, ಉದಾ., bugs ಸರಿಪಡಿಸುವುದು ಮತ್ತು functions ಸೃಷ್ಟಿಸುವುದು, ಹೊರಗಿನ sources‌ಗೆ ಮೊರೆಹೋಗದೆ ಅತ್ಯಂತ ಸಮರ್ಥವಾಗಿ ನಿರ್ವಹಿಸಬಲ್ಲವು.

RAG ವಿರುದ್ಧ long-context LLM, agentic AI, ಮತ್ತು grounding

RAG ಮತ್ತು LLMಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಮೂರು ಸಂಬಂಧಿತ conceptsಗಳಿವೆ. ಅವು long-context LLMs, agentic AI, ಮತ್ತು grounding.

Long-context LLMಗಳನ್ನು ಕೆಲವೊಮ್ಮೆ RAG-enabled systems‌ಗಳ ಬದಲಿಗೆ ಬಳಸಬಹುದು, ಆದರೆ agentic AI ಮತ್ತು grounding ಅವುಗಳೊಂದಿಗೆ ಸಮಾನಾರ್ಥಕವಾಗಿವೆ ಅಥವಾ ಅವುಗಳ ಜೊತೆಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.

Long-context LLMಗಳು

ಇವು ದೊಡ್ಡ context windows ಇರುವ models ಆಗಿದ್ದು, ಕೆಲವು ವ್ಯಾಪಕವಾಗಿ ಲಭ್ಯವಿರುವ commercial models ಒಂದು million tokens ತನಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.

ಸಂಬಂಧಿತ material model‌ನ context window‌ನಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳಬಲ್ಲದಾದರೆ ಮತ್ತು text format‌ನಲ್ಲಿ ಲಭ್ಯವಿದ್ದರೆ, LLM-only approach ಬಳಸುವುದರಿಂದ ಕೆಲವು ಲಾಭಗಳಿವೆ. ಇದು retrieval errors ಸಂಭವಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು, ಇನ್ನಷ್ಟು ಸಮಗ್ರ context ಒದಗಿಸಬಹುದು, ಮತ್ತು ವಿಶಾಲವಾದ RAG architecture setup‌ನ ಅಗತ್ಯವನ್ನು ನಿವಾರಿಸಬಹುದು.

ಏಜೆಂಟಿಕ್ AI

ಒಂದು agent ಎಂದರೆ RAG ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಹಲವಾರು tools‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಕೀರ್ಣ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಒಂದು system. RAG agentic AI‌ನ ಒಂದು ಅಂಗವಾಗಿದ್ದು, prompt‌ನ ವಿಷಯವನ್ನು ಅವಲಂಬಿಸಿ ಒಂದು agent ಸಾಮಾನ್ಯವಾಗಿ ವಿಭಿನ್ನ ರೀತಿಯ retrieval methods‌ಗಳನ್ನು (ಉದಾ., web search ವಿರುದ್ಧ vector search) ಬಳಸುತ್ತದೆ.

Grounding

Grounding ಎಂದರೆ ಸಾಕ್ಷ್ಯ ಅಥವಾ ಡೇಟಾವನ್ನು ಬಳಸಿಕೊಂಡು LLM‌ನ ಪ್ರತಿಕ್ರಿಯೆಯ ನಿಖರತೆಯನ್ನು ಸುಧಾರಿಸುವ (ಅಥವಾ ground ಮಾಡುವ) ವಿಶಾಲ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. RAG grounding‌ನ ಒಂದು ರೂಪವಾಗಿದೆ, ಆದರೆ context window‌ಗೆ technical document ಅನ್ನು ಸೇರಿಸುವುದೂ grounding ಆಗಿಯೇ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.

RAG ವಿರುದ್ಧ LLM: ನೈಜ-ಜಗತ್ತಿನ ಉದಾಹರಣೆಗಳು

Perplexity ಮತ್ತು vector database ಅನ್ನು ಬಳಸುವ ಕಲ್ಪಿತ enterprise case ಒಳಗೊಂಡ ಸರಳ ನೈಜ-ಜೀವನ ಉದಾಹರಣೆಯನ್ನು ನೋಡಿ, RAG ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು RAG ಇಲ್ಲದೆ LLM ಬಳಕೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.

ಸರಳ prompt‌ನೊಂದಿಗೆ RAG ವಿರುದ್ಧ LLM

Perplexityಗೆ “Should I go for a walk in London today?” ಎಂದು ಕೇಳಿದಾಗ AI web search (RAG‌ನ ಒಂದು ರೂಪ) ಅನ್ನು ಆಫ್ ಮಾಡಿದರೆ, ಇಲ್ಲಿದೆ ಎರಡು ವಾಕ್ಯಗಳಿಗೆ ಮಿತಿಗೊಳಿಸಿದ output:

ಹೌದು—ಹವಾಮಾನ ಸಮಂಜಸವಾಗಿ ಒಣವಾಗಿದ್ದರೆ ಮತ್ತು ನಿಮ್ಮ ಬಳಿ ಸಮಯವಿದ್ದರೆ, ಇಂದು ಲಂಡನ್‌ನಲ್ಲಿ ನಡೆಯುವುದು ದೃಶ್ಯ ಬದಲಾವಣೆಯಾಗಿ ತಾಜಾತನ ನೀಡಬಹುದು. South Bank, Regent’s Canal, ಅಥವಾ Hyde Park ಮೂಲಕ ಒಂದು ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆಮಾಡಿ, ಮತ್ತು ಮುಂಜಾಗ್ರತೆಯಾಗಿ ಹಗುರವಾದ waterproof ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಹೋಗಿ.

LLM ಹೊರಗಿನ sources ಅನ್ನು ಪರಿಶೀಲಿಸಬಹುದಾದಾಗ prompt ಅನ್ನು ಇದರೊಂದಿಗೆ ಹೋಲಿಸಿ:

ಹೌದು, ಇಂದು ಲಂಡನ್‌ನಲ್ಲಿ ನಡೆಯಲು ಒಳ್ಳೆಯ ದಿನ: ಮುನ್ಸೂಚನೆಯ ಪ್ರಕಾರ ಮೃದುವಾದ ತಾಪಮಾನಗಳು ಸುಮಾರು 19–21°C, ಬಿಸಿಲಿನ ವಿರಾಮಗಳು, ಮತ್ತು ಮಳೆ ಬೀಳುವ ಸಾಧ್ಯತೆ ಅತ್ಯಂತ ಕಡಿಮೆ. ಭಾಗಶಃ ಮೋಡಮೇಘಗಳ ಆಕಾಶ ಮತ್ತು ಸೌಮ್ಯ ಗಾಳಿಯೊಂದಿಗೆ, South Bank‌ನಂತಹ ಉದ್ಯಾನಗಳು ಅಥವಾ ನದಿತೀರ ಮಾರ್ಗಗಳನ್ನು ಅನ್ವೇಷಿಸಲು ಪರಿಸ್ಥಿತಿಗಳು ಆರಾಮದಾಯಕವಾಗಿವೆ.

ಈ ಎರಡರ ನಡುವೆ ಸಾಮ್ಯಗಳಿವೆ, ಏಕೆಂದರೆ LLM ಅದೇ ಮೂಲ token scoring process ಅನ್ನು ಬಳಸುತ್ತದೆ. ಆದರೆ, ಎರಡನೇ ಉದಾಹರಣೆಯಲ್ಲಿ ವಿವರವಾದ ಹವಾಮಾನ ಮಾಹಿತಿ ಸೇರಿದೆ, ಇದರಿಂದ ಅದು ಬಹಳ ಹೆಚ್ಚು ಉಪಯುಕ್ತವಾಗುತ್ತದೆ.

Enterprise vector database ಹೊಂದಿರುವ RAG ವಿರುದ್ಧ LLM

ಒಂದು banking appಗಾಗಿ in-app chatbot‌ಗೆ ಬಳಕೆದಾರನು ಈ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುತ್ತಾನೆ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ: “ನನ್ನ ಇತ್ತೀಚಿನ statement ಅನ್ನು ನಾನು ಎಲ್ಲಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದು?”

ಆಪ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ bank ತನ್ನ ಇತ್ತೀಚಿನ product documentation‌ನ embeddings ಹೊಂದಿರುವ database ಅನ್ನು ಸೃಷ್ಟಿಸಿ, ಅದನ್ನು chatbot‌ನ RAG pipeline‌ಗೆ ಸಂಪರ್ಕಿಸಿದೆ. ಆ documentation ಸುಮಾರು 1,000 source documents‌ಗಳನ್ನು ಒಳಗೊಂಡಿದ್ದು, ಅವುಗಳನ್ನು ಚಿಕ್ಕ chunks‌ಗಳಾಗಿ ವಿಭಜಿಸಿ, retrievalಗಾಗಿ vectors‌ಗಳಾಗಿ ಪರಿವರ್ತಿಸಲಾಗಿದೆ.

ಬಳಕೆದಾರರ query ಅನ್ನು embedding model‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು application ಆ vector ಅನ್ನು database‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಅದು ಸಂಬಂಧಿತ chunks ಅನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ.

embedding model‌ಗೆ ಈ ರೀತಿಯ ವಿನಂತಿ ಬರಬಹುದು:

embedding model ಕೆಳಗಿನ vector embedding ಅನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ:

ನಂತರ vector database‌ಗೆ ಈ ರೀತಿಯ ವಿನಂತಿ ಹೋಗುತ್ತದೆ:

ಈ (ಬಹಳ ಸರಳೀಕರಿಸಿದ) ಉದಾಹರಣೆಯಲ್ಲಿ, database ಬಳಕೆದಾರರ queryಗೆ ಅತ್ಯಂತ ಸಂಬಂಧಿತವಾಗಿರುವ ಐದು chunks ಅನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ, ಅವುಗಳನ್ನು application‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು LLM prompt‌ನಲ್ಲಿ ಸೇರಿಸಲಾಗುತ್ತದೆ.

RAG ವಿರುದ್ಧ LLM ಅನ್ನು ಯಾವಾಗ ಆಯ್ಕೆಮಾಡಬೇಕು, ಮತ್ತು ಯಾವಾಗ ಸಂಯೋಜಿಸಬೇಕು

LLMಗಳು ಮತ್ತು RAG ಪರಸ್ಪರ ಪೂರಕ ವ್ಯವಸ್ಥೆಗಳಾಗಿವೆ. ಆದ್ದರಿಂದ, “ನಾನು ಯಾವಾಗ LLM ಆಯ್ಕೆಮಾಡಬೇಕು ಮತ್ತು ಯಾವಾಗ RAG?” ಎಂಬ ಪ್ರಶ್ನೆ ತಪ್ಪಾಗಿದೆ. ಬದಲಾಗಿ, “ಯಾವಾಗ LLM ಸಾಕಾಗುತ್ತದೆ ಮತ್ತು ಯಾವಾಗ RAG ಅತ್ಯುತ್ತಮ?” ಎಂದು ನೀವು ಕೇಳಬೇಕು.

RAG enabled ಇಲ್ಲದೆ LLM ಅನ್ನು ಯಾವಾಗ ಬಳಸಬೇಕು

• ನೀವು ಆಯ್ಕೆಮಾಡಿದ AI model‌ಗೆ ದೊಡ್ಡ context window ಇದೆ: ನಿಖರ ಉತ್ತರಕ್ಕಾಗಿ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಮಾಹಿತಿ ಅಥವಾ ಡೇಟಾವನ್ನು ನಿಮ್ಮ prompt‌ನಲ್ಲಿ, ಉದಾಹರಣೆಗೆ document ಅನ್ನು upload ಮಾಡುವ ಮೂಲಕ, ಸೇರಿಸುವುದು ಸುಲಭವಾಗಿದ್ದರೆ, ಹಾಗೆ ಮಾಡುವುದರಿಂದ latency ಕಡಿಮೆಯಾಗಬಹುದು ಮತ್ತು retrieval-ಸಂಬಂಧಿತ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಬಹುದು.
• ರೀಜನಿಂಗ್ ಮತ್ತು ಡೇಟಾ ವಿಶ್ಲೇಷಣೆಯ ಕಾರ್ಯಪ್ರವಾಹಗಳು: prompt‌ನಲ್ಲಿ ನೀಡಲಾದ ಡೇಟಾವನ್ನು ಮಾತ್ರ ಉಲ್ಲೇಖಿಸುವ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ರೀಜನಿಂಗ್ ಕಾರ್ಯಪ್ರವಾಹಗಳಿಗೆ RAG ಸಾಮರ್ಥ್ಯಗಳ ಅಗತ್ಯವಿಲ್ಲ.
• Code generation: ಸಾಮಾನ್ಯ ಕೋಡಿಂಗ್ ಕೆಲಸಕ್ಕೆ RAG ಸಾಮಾನ್ಯವಾಗಿ ಅಗತ್ಯವಿಲ್ಲ, ಆದರೆ ಹಿಂದಿನ fixes ಅಥವಾ vendor APIs ಮತ್ತು documentation ಅನ್ನು ಪಡೆಯುವಂತಹ project-specific ಕಾರ್ಯಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

RAG enabled ಆಗಿರುವ LLM ಅನ್ನು ಯಾವಾಗ ಬಳಸಬೇಕು

• ನೀವು ಇತ್ತೀಚಿನ ಮಾಹಿತಿಗೆ ಪ್ರವೇಶ ಅಗತ್ಯವಿದೆ: ಒಂದು AI application ನಿಖರ ಉತ್ತರವನ್ನು ರಚಿಸಲು ಇತ್ತೀಚಿನ ಮಾಹಿತಿಯ ಹೊರಗಿನ sources‌ಗೆ ಪ್ರವೇಶಿಸಬೇಕಾದರೆ, ಯಾವಾಗಲೂ RAG ಸಾಮರ್ಥ್ಯಗಳು enabled ಆಗಿರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
• ನೀವು ವಿಶೇಷ ಕ್ಷೇತ್ರದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೀರಿ: ವೈದ್ಯಕೀಯ, ಕಾನೂನು, ಶಿಕ್ಷಣ, ಇತ್ಯಾದಿ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ನಿಖರತೆ, ವಿವರ, ಮತ್ತು source ಪರಿಶೀಲನೆ ಮುಖ್ಯವಾಗಿರುವುದರಿಂದ, LLM-only ಬಳಕೆ ಬಹುಸಾ ಸಾಲುವುದಿಲ್ಲ.
• ಔಟ್‌ಪುಟ್‌ಗಳು internal company files ಅನ್ನು ಉಲ್ಲೇಖಿಸಬೇಕು: ನೀವು AI ಅನ್ನು, internal ಆಗಿರಲಿ ಅಥವಾ customer-facing app‌ನಲ್ಲಿ ಇರಲಿ, internal company documents, data, brand kit, documentation, ಅಥವಾ files‌ಗಳ ಆಧಾರದ ಮೇಲೆ content ರಚಿಸಲು ಬಳಸುತ್ತಿದ್ದರೆ, RAG ಆ ಮಾಹಿತಿಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುತ್ತದೆ.

RAG ಮತ್ತು LLMಗಳು ಪರಸ್ಪರ ಪೂರಕ, ನಿರಂತರವಾಗಿ ಅಭಿವೃದ್ಧಿಯಾಗುತ್ತಿರುವ ತಂತ್ರಜ್ಞಾನಗಳಾಗಿವೆ

AI ವಿಕಾಸದಲ್ಲಿ RAG ಪ್ರಮುಖ ಹೊಸತನವನ್ನು ಸೂಚಿಸಿತು. ಇದು ಮೂರು ಪ್ರಮುಖ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ: ಹಳೆಯ ಮಾಹಿತಿಗಳು, ಸೀಮಿತ model memory, ಮತ್ತು ಸಂಬಂಧಿತ training data ಕೊರತೆಯಿಂದ ಉಂಟಾಗುವ information gaps, ಇವು ಬಹುಸಾ hallucinations‌ಗೆ ಕಾರಣವಾಗುತ್ತವೆ. ಖಂಡಿತವಾಗಿಯೂ, LLMಗಳು ಇವುಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಜಯಿಸಿಲ್ಲ, ಆದರೆ RAG ಆಗಮನದೊಂದಿಗೆ ಅವುಗಳ ಸಂಭವ ಗಣನೀಯವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ.

RAG ಸ್ಥಿರ ತಂತ್ರಜ್ಞಾನವಲ್ಲ. reranking, retrieval ಸಮಯದ latency ಮತ್ತು token ಬಳಕೆ, ಅಪಾಯಕಾರಿಯಾದ data sources ವಿರುದ್ಧದ security defenses, ಹಲವು sources‌ನಿಂದ ಪಡೆಯಲಾದ data ಅನ್ನು ಒಗ್ಗೂಡಿಸುವುದು, ಮತ್ತು ಇನ್ನೂ ಅನೇಕ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಇದು ಉತ್ತಮವಾಗುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ. LLMಗಳು ಮತ್ತು agentic AI ಮುಂದುವರಿದು ಅಭಿವೃದ್ಧಿಯಾಗುತ್ತಿದ್ದಂತೆ, ಅವುಗಳನ್ನು ಬೆಂಬಲಿಸುವ RAG systems ಕೂಡ ಅಭಿವೃದ್ಧಿಯಾಗುತ್ತವೆ.