ಟೀಮ್‌ಗಳು Retrieval-Augmented Generation (RAG) ಅನ್ನು ಕೇವಲ ಒಂದು ಡೆಮೊದಿಂದ ಪ್ರೊಡಕ್ಷನ್ ಸೇವೆಯಾಗಿ ಬದಲಾಯಿಸುವಾಗ, ಒಂದು ಉಪಯುಕ್ತ ಸಹಾಯಕ ಮತ್ತು ಗೊಂದಲಮಯ ಸಹಾಯಕನ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ನಿರ್ಧರಿಸುವ ಕೆಲವು ಪ್ರಮುಖ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಐದು ವಿನ್ಯಾಸದ ಆಯ್ಕೆಗಳು—chunking, embedding model, vector store, hybrid search, ಮತ್ತು evaluation—ಬಳಕೆದಾರರು ಅನುಭವಿಸುವ precision, recall, ಮತ್ತು latency ಅನ್ನು ನಿಯಂತ್ರಿಸುತ್ತವೆ.

ಪ್ರೊಟೊಟೈಪ್‌ನಿಂದ ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ಬದಲಾಗುವುದು ಏಕೆ ಮುಖ್ಯ

ಹೆಚ್ಚಿನ ಟ್ಯುಟೋರಿಯಲ್‌ಗಳು ಕೆಲವು ಡಜನ್ ಸಾಲುಗಳ ಕೋಡ್‌ನಲ್ಲಿ RAG ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ರನ್ ಮಾಡಿಸುತ್ತವೆ, ಆದರೆ ಲೈವ್ ಟ್ರಾಫಿಕ್‌ಗೆ ಅಗತ್ಯವಿರುವ ಎಂಜಿನಿಯರಿಂಗ್ ಕಟ್ಟುನಿಟ್ಟನ್ನು ಅನುಸರಿಸದೆ ಅಲ್ಲಿಗೆ ನಿಲ್ಲುತ್ತವೆ.

1. Chunking strategy – ಮೊದಲ ಗುಣಮಟ್ಟದ ಹಂತ (quality gate)

Chunk ಗಾತ್ರವು ಅತ್ಯಂತ ಮುಖ್ಯವಾದುದು. ದೊಡ್ಡ ಚಂಕ್‌ಗಳು ಸಂಬಂಧವಿಲ್ಲದ ಪಠ್ಯದೊಂದಿಗೆ ಸಿಗ್ನಲ್ ಅನ್ನು ಮರೆಮಾಚುತ್ತವೆ; ಸಣ್ಣ ಚಂಕ್‌ಗಳು ಮಾಡೆಲ್ ಸುಸಂಬದ್ಧವಾದ ಉತ್ತರಗಳನ್ನು ನೀಡಲು ಅಗತ್ಯವಿರುವ ಸುತ್ತಮುತ್ತಲಿನ ಸಂದರ್ಭವನ್ನು (context) ಕಸಿದುಕೊಳ್ಳುತ್ತವೆ. ನಿಗದಿತ ಗಾತ್ರದ ವಿಭಜನೆಯು ಮೂಲ ವಿಷಯದ ನೈಸರ್ಗಿಕ ರಚನೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕ ನಿಯಮಗಳು (Practical rule-of-thumb)

  • ತಾರ್ಕಿಕ ಗಡಿಗಳ ಮೇಲೆ ವಿಭಜಿಸಿ: ದಾಖಲೆಗಳಲ್ಲಿನ ಹೆಡರ್‌ಗಳು, ಲೇಖನಗಳಲ್ಲಿನ ಪ್ಯಾರಾಗ್ರಾಫ್ ವಿಭಜನೆಗಳು, ಕೋಡ್‌ನಲ್ಲಿನ ಫಂಕ್ಷನ್ ವ್ಯಾಖ್ಯಾನಗಳು.
  • ಚಂಕ್‌ಗಳನ್ನು ನಿಖರವಾದ ರಿಟ್ರಿವಲ್‌ಗಾಗಿ (retrieval) ಚಿಕ್ಕದಾಗಿಡಿ, ಆದರೆ LLM ನ ಜನರೇಷನ್ ಹಂತಕ್ಕಾಗಿ ದೊಡ್ಡ ಪೋಷಕ ವಿಭಾಗವನ್ನು (parent section) ಉಳಿಸಿಕೊಳ್ಳಿ. ಈ “parent-child” ಮಾದರಿಯು ರಿಟ್ರೈವರ್ ಒಂದು ನಿಖರವಾದ ತುಣುಕನ್ನು ಹೊರತರುವಂತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಜನರೇಟರ್ ವಾಸ್ತವಿಕವಾಗಿರಲು ಸಾಕಷ್ಟು ಸಂದರ್ಭವನ್ನು (context) ನೋಡುವಂತೆ ಮಾಡುತ್ತದೆ.

2. Embedding models – ಸಾಮ್ಯತೆಯನ್ನು (similarity) ಹೇಗೆ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ

Embedding ಮಾಡೆಲ್ ಪಠ್ಯವನ್ನು ವೆಕ್ಟರ್‌ಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಇವುಗಳನ್ನು ಸಿಮಿಲಾರಿಟಿ ಸರ್ಚ್ ಎಂಜಿನ್ ಹೋಲಿಕೆ ಮಾಡುತ್ತದೆ. OpenAI ನ text-embedding-3-large ನಂತಹ ಬಲಿಷ್ಠವಾದ ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಮಾಡೆಲ್ ಹೆಚ್ಚಿನ ಡೊಮೇನ್‌ಗಳಿಗೆ ಒಂದು ಉತ್ತಮ ಅಡಿಪಾಯವನ್ನು ನೀಡುತ್ತದೆ. ಒಂದು ವೇಳೆ ನಿಮ್ಮ ಡೇಟಾ ಅತ್ಯಂತ ವಿಶೇಷವಾದ ಕ್ಷೇತ್ರಕ್ಕೆ (ಉದಾಹರಣೆಗೆ: ಕಾನೂನು ಅಭಿಪ್ರಾಯಗಳು, ವೈದ್ಯಕೀಯ ದಾಖಲೆಗಳು, ತಾಂತ್ರಿಕ ವಿವರಣೆಗಳು) ಸಂಬಂಧಿಸಿದ್ದಲ್ಲಿ, ನಿಮ್ಮ ಸ್ವಂತ ಡೇಟಾದ ಮೇಲೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಪರೀಕ್ಷಿಸಿದ ನಂತರ ಮಾತ್ರ ಡೊಮೇನ್-ನಿರ್ದಿಷ್ಟ ಮಾಡೆಲ್ ಅನ್ನು ಬಳಸಿ.

ಯಾವಾಗ ಬದಲಾಯಿಸಬೇಕು

  • ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಮುಖ್ಯವಾದ ರಿಲೆವೆನ್ಸ್ ಸ್ಕೋರ್‌ಗಳಲ್ಲಿ (ಉದಾಹರಣೆಗೆ: ಹೆಚ್ಚಿನ context precision) ಅಳೆಯಬಹುದಾದ ಸುಧಾರಣೆಯನ್ನು ಕಂಡಾಗ ಮಾತ್ರ ಬದಲಾಯಿಸಿ.

3. Vector database – ಸಂಗ್ರಹವನ್ನು ಸ್ಕೇಲ್ ಮಾಡುವುದು

ನಿಮ್ಮ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ನಿರೀಕ್ಷಿತ ವೆಕ್ಟರ್‌ಗಳ ಸಂಖ್ಯೆಗೆ ಹೊಂದಿಕೆಯಾಗುವ vector store ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿ.

  • pgvector PostgreSQL ಒಳಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಸುಮಾರು ಒಂದು ಮಿಲಿಯನ್ ವೆಕ್ಟರ್‌ಗಳನ್ನು ಸುಲಭವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಈಗಾಗಲೇ ರಿಲೇಶನಲ್ ಡೇಟಾಬೇಸ್ ಬಳಸುತ್ತಿರುವ ಮತ್ತು ಕಡಿಮೆ ನಿರ್ವಹಣೆಯ ಅಗತ್ಯವಿರುವ ತಂಡಗಳಿಗೆ ಸೂಕ್ತವಾಗಿದೆ.
  • Qdrant 1 M–100 M ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ದೊಡ್ಡ ಡೇಟಾ ಸೆಟ್‌ಗಳಿಗೆ ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ ಮತ್ತು ಕಡಿಮೆ લેಟೆನ್ಸಿಯನ್ನು ನೀಡುತ್ತದೆ.
  • Pinecone ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ವಹಿಸಲ್ಪಡುವ ಕ್ಲೌಡ್ ಸೇವೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ, ಇದು ಸೆಲ್ಫ್-ಹೋಸ್ಟಿಂಗ್‌ನ ನಿರ್ವಹಣಾ ಹೊರೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

4. Hybrid search ಮತ್ತು reranking – ಅರ್ಥ ಮತ್ತು ನಿಖರತೆಯ ನಡುವಿನ ಸಮತೋಲನ

ಶುದ್ಧ ವೆಕ್ಟರ್ ಸರ್ಚ್ ಸೆಮ್ಯಾಂಟಿಕ್ ಸಾಮ್ಯತೆಯಲ್ಲಿ (semantic similarity) ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಆದರೆ ಬಳಕೆದಾರರು ನಿರೀಕ್ಷಿಸುವ ನಿಖರವಾದ ಕೀವರ್ಡ್ ಹೊಂದಾಣಿಕೆಗಳನ್ನು (keyword matches) ತಪ್ಪಿಸಬಹುದು. Hybrid search ವೆಕ್ಟರ್ ಇಂಡೆಕ್ಸ್‌ನ ಮೇಲೆ ಸಾಂಪ್ರದಾಯಿಕ BM25 ಕೀವರ್ಡ್ ಇಂಡೆಕ್ಸ್ ಅನ್ನು ಅಳವಡಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಎರಡೂ ಫಲಿತಾಂಶಗಳ ಪಟ್ಟಿಯನ್ನು ವಿಲೀನಗೊಳಿಸುತ್ತದೆ. Reciprocal Rank Fusion (RRF) ಪ್ರತಿ ಅಭ್ಯರ್ಥಿಗೆ ಎರಡೂ ಪಟ್ಟಿಗಳಲ್ಲಿನ ಅದರ ರ್ಯಾಂಕ್ ಆಧಾರದ ಮೇಲೆ ಸ್ಕೋರ್ ನೀಡುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತದೆ, ಇದರಿಂದ ಯಾವುದಾದರೂ ಒಂದು ಪಟ್ಟಿಯಲ್ಲಿ ಉನ್ನತ ಸ್ಥಾನದಲ್ಲಿರುವ ಐಟಂಗಳಿಗೆ ಹೆಚ್ಚಿನ ಪ್ರಾಮುಖ್ಯತೆ ಸಿಗುತ್ತದೆ.

Reranking ಅಂತಿಮ ನಿಖರತೆಯ ಫಿಲ್ಟರ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ. Hybrid ರಿಟ್ರಿವಲ್ ನಂತರ, ಟಾಪ್-N (ಸಾಮಾನ್ಯವಾಗಿ 50) ಅಭ್ಯರ್ಥಿಗಳನ್ನು cross-encoder ಗೆ ಕಳುಹಿಸಿ—ಇದು ಕ್ವೆರಿ-ಡಾಕ್ಯುಮೆಂಟ್ ಜೋಡಿಯನ್ನು ಅಳೆಯುವ ಮಾಡೆಲ್ ಆಗಿದೆ. Cross-encoder ಸ್ಕೋರ್‌ಗಳು ಮೂಲ ಸಿಮಿಲಾರಿಟಿ ಸಂಖ್ಯೆಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ, ಇದು LLM ಗೆ ಕಳುಹಿಸುವ ಮೊದಲು ಅತ್ಯಂತ ಸಂಬಂಧಿತ ಚಂಕ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಈ ಹೆಚ್ಚುವರಿ ಹಂತವು, ವಿಶೇಷವಾಗಿ ಉದ್ದವಾದ ಅಥವಾ ಗೊಂದಲಮಯ ಡೇಟಾ ಸೆಟ್‌ಗಳಿಗಾಗಿ, ಉತ್ತರಗಳ ಗುಣಮಟ್ಟದಲ್ಲಿ ಗಮನಾರ್ಹ ಸುಧಾರಣೆಯನ್ನು ನೀಡುತ್ತದೆ.

5. Evaluation ಮತ್ತು abstention – ಮುಖ್ಯವಾದದ್ದನ್ನು ಅಳೆಯುವುದು

ನೀವು ಅಳೆಯದ ವ್ಯವಸ್ಥೆಯನ್ನು ಸುಧಾರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. RAGAS ಫ್ರೇಮ್‌ವರ್ಕ್ ನಾಲ್ಕು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪ್ರಸ್ತಾಪಿಸುತ್ತದೆ, ಇವು ಒಟ್ಟಾಗಿ RAG ಪೈಪ್‌ಲೈನ್‌ನ ಆರೋಗ್ಯವನ್ನು ಅಳೆಯುತ್ತವೆ:

  • Context Precision – ರಿಟ್ರೀವ್ ಮಾಡಲಾದ ಚಂಕ್‌ಗಳಲ್ಲಿ ನಿಜವಾಗಿಯೂ ಉತ್ತರವನ್ನು ಹೊಂದಿರುವ ಚಂಕ್‌ಗಳ ಪ್ರಮಾಣ.
  • Context Recall – ರಿಟ್ರೀವ್ ಮಾಡಲಾದ ಎಲ್ಲಾ ಸಂಬಂಧಿತ ಚಂಕ್‌ಗಳ ಪಾಲಿನ ಪ್ರಮಾಣ.
  • Faithfulness – ಜನರೇಟ್ ಮಾಡಲಾದ ಉತ್ತರವು ರಿಟ್ರೀವ್ ಮಾಡಲಾದ ಸಂದರ್ಭದ (context) ಮಿತಿಯಲ್ಲೇ ಇರುವುದು ಮತ್ತು ಭ್ರಮೆಗಳನ್ನು (hallucinations) ತಪ್ಪಿಸುವುದು.
  • Answer Relevance – ಅಂತಿಮ ಉತ್ತರವು ಮೂಲ ಪ್ರಶ್ನೆಯನ್ನು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ತೃಪ್ತಿಪಡಿಸುತ್ತದೆ ಎಂಬುದು.

ಈ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪ್ರೊಡಕ್ಷನ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವ ಟೆಸ್ಟ್ ಸೆಟ್‌ನಲ್ಲಿ ನಿರಂತರವಾಗಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಿ.

ಅಂತಿಮವಾಗಿ, ಹೆಚ್ಚಾಗಿ ನಿರ್ಲಕ್ಷಿಸಲ್ಪಡುವ ಸುರಕ್ಷತಾ ಕ್ರಮವೆಂದರೆ abstention. ಕಡಿಮೆ ವಿಶ್ವಾಸಾರ್ಹತೆಯೊಂದಿಗೆ (low confidence) ಮಾಡೆಲ್ ಉತ್ತರ ನೀಡಲು ಒತ್ತಾಯಿಸುವ ಬದಲು, faithfulness ಅಥವಾ relevance ಸ್ಕೋರ್ ಮೇಲೆ ಒಂದು ಮಿತಿಯನ್ನು (threshold) ನಿಗದಿಪಡಿಸಿ, ಇದು “ನನಗೆ ಗೊತ್ತಿಲ್ಲ” ಎಂಬ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುವಂತೆ ಮಾಡುತ್ತದೆ. ಬಳಕೆದಾರರು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಕೂಡಿದ ಆದರೆ ತಪ್ಪು ಉತ್ತರಕ್ಕಿಂತ, ಅನಿಶ್ಚಿತತೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳುವುದನ್ನೇ ಬಯಸುತ್ತಾರೆ ಮತ್ತು ಇದು ಮುಂದಿನ ಬೆಂಬಲ ವೆಚ್ಚಗಳನ್ನು (support costs) ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಈ ಐದು ಕ್ಷೇತ್ರಗಳ ಪ್ರತಿಯೊಂದನ್ನೂ ಕೇವಲ ಒಂದು ಬಾರಿ ಸೆಟ್ ಮಾಡಿದ ಕಾನ್ಫಿಗರೇಶನ್ ಎಂದು ಪರಿಗಣಿಸದೆ, ಒಂದು ನಿರ್ಧಾರದ ಹಂತವಾಗಿ ಪರಿಗಣಿಸಿ; ಆಗ ನೀವು RAG ಅನ್ನು ಕೇವಲ ಒಂದು ಪ್ರದರ್ಶನದಿಂದ (demo) ನಂಬಿಕಾರ್ಹ ಪ್ರೊಡಕ್ಷನ್ ಸೇವೆಯಾಗಿ ಬದಲಾಯಿಸಬಹುದು. ಇದರ ಫಲಿತಾಂಶ: ವೇಗವಾಗಿ ಉತ್ತರಿಸುವ, ವಿಷಯಕ್ಕೆ ಬದ್ಧವಾಗಿರುವ ಮತ್ತು ಯಾವಾಗ ಮೌನವಾಗಿರಬೇಕು ಎಂಬುದು ತಿಳಿದಿರುವ ಒಂದು ವ್ಯವಸ್ಥೆ.