ಹೆಚ್ಚಿನ RAG ಟ್ಯುಟೋರಿಯಲ್‌ಗಳು ಪ್ರೊಡಕ್ಷನ್ (production) ಆರಂಭವಾಗುವ ಸ್ಥಳದಲ್ಲೇ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. ನೀವು ನಿಮ್ಮ ದಾಖಲೆಗಳನ್ನು 512-ಟೋಕನ್ ಚಂಕ್‌ಗಳಾಗಿ (chunks) ವಿಂಗಡಿಸುತ್ತೀರಿ, ಅವುಗಳನ್ನು ಒಂದೇ ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್ (embedding model) ಮೂಲಕ ಕಳುಹಿಸುತ್ತೀರಿ ಮತ್ತು ಸರಳ top-k ರಿಟ್ರಿೀವಲ್ (retrieval) ಬಳಸಿ ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಕರೆಯುತ್ತೀರಿ. ಒಂದು ಡೆಮೊದಲ್ಲಿ, ಇದು ನಂಬಲರ್ಹವಾಗಿ ಕಾಣುತ್ತದೆ. ಬಾಟ್‌ಗೆ ನಿಮ್ಮ ಕಂಪನಿಯ ರಜೆ ನೀತಿಯ ಬಗ್ಗೆ ಕೇಳಿದರೆ ಅದು ಸುಸಂಬದ್ಧವಾದ ಪ್ಯಾರಾಗ್ರಾಫ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ಎಲ್ಲರೂ ತಲೆಯಾಡಿಸುತ್ತಾರೆ. ದುರದೃಷ್ಟವಶಾತ್, ಡೆಮೋಗಳು ಸುಳ್ಳು ಹೇಳುತ್ತವೆ.

ಪ್ರೊಡಕ್ಷನ್ ಪ್ರತಿಯೊಂದು ಶಾರ್ಟ್‌ಕಟ್ ಅನ್ನು ಬಯಲಿಗೆಳೆಯುತ್ತದೆ. ನಿಗದಿತ ಚಂಕ್‌ಗಳು ಕಾನೂನು ಒಪ್ಪಂದಗಳಲ್ಲಿನ (legal contracts) ಪರಿಹಾರದ ಕಲಮುಗಳ (indemnification clauses) ಮಧ್ಯದಲ್ಲೇ ಕತ್ತರಿಸುತ್ತವೆ. API ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಅತಿಯಾದ ಗೊಂದಲದ ಶಬ್ದವಾಗಿ (overlapping noise) ಬದಲಾಗುತ್ತದೆ, ಇದು ನಿಮಗೆ ನಿಜವಾಗಿಯೂ ಬೇಕಾದ ಮಾಹಿತಿಯನ್ನು ಮರೆಮಾಚುತ್ತದೆ. ಉತ್ತರ ಬರುವ ಮೊದಲೇ ಬಳಕೆದಾರರು ಪ್ರಶ್ನೆಯನ್ನು ಕೈಬಿಡುವವರೆಗೆ ವಿಳಂಬ (latency) ಹೆಚ್ಚಾಗುತ್ತಾ ಹೋಗುತ್ತದೆ. ನಾವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಬೇಕಾಯಿತು ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಮರುನಿರ್ಮಾಣ ಮಾಡಬೇಕಾಯಿತು. ನಮ್ಮ ರಿಟ್ರಿೀವಲ್ ಲೇಯರ್ "ಸೆಮ್ಯಾಂಟಿಕ್ ಸರ್ಚ್ ಮತ್ತು ಭರವಸೆ"ಯಿಂದ ಅಳೆಯಬಹುದಾದ ಮತ್ತು ವ್ಯವಸ್ಥಿತವಾದ ಪೈಪ್‌ಲೈನ್‌ ಆಗಿ ವಿಕಸನಗೊಂಡಿತು. ಇದರ ಫಲಿತಾಂಶವು 95% ರಿಕಾಲ್ (recall) ಮತ್ತು 40% ವಿಳಂಬದ ಕಡಿತವಾಗಿತ್ತು. ನಿಜವಾಗಿಯೂ ಯಾವುದು ಕೆಲಸ ಮಾಡಿತು ಎಂಬುದು ಇಲ್ಲಿದೆ.

ಚಂಕಿಂಗ್ ಸ್ಟ್ರಾಟಜಿಯನ್ನು (Chunking Strategy) ದಾಖಲೆಗೆ ಅನುಗುಣವಾಗಿ ಹೊಂದಿಸಿ

512-ಟೋಕನ್ ಡಿಫಾಲ್ಟ್ ಅನ್ನು ಬಳಸುತ್ತಿರುವುದು ಅದು ಸುಲಭ ಎಂಬ ಕಾರಣಕ್ಕೇ ಹೊರತು ಅದು ಸರಿಯಾಗಿದೆ ಎಂಬ ಕಾರಣಕ್ಕಲ್ಲ. ವಿಭಿನ್ನ ದಾಖಲೆಗಳು ವಿಭಿನ್ನ ಅರ್ಥಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ ಮತ್ತು ನಿಮ್ಮ ಚಂಕಿಂಗ್ ಸ್ಟ್ರಾಟಜಿಯು ಅದನ್ನು ಪ್ರತಿಬಿಂಬಿಸಬೇಕು.

ಕಾನೂನು ಒಪ್ಪಂದಗಳಿಗಾಗಿ (legal contracts), ರಚನಾತ್ಮಕ ಗಡಿಗಳನ್ನು ಗೌರವಿಸುವ 'ರಿಕರ್ಸಿವ್ ಚಂಕಿಂಗ್' (recursive chunking) ಬಳಸಿ. ಕಾನೂನು ಭಾಷೆಯು ಒಂದರೊಳಗೆ ಒಂದು ಅಡಕವಾಗಿರುತ್ತದೆ (nested). ಒಂದು ಕಲಮು (clause) ಅದರ ಮೇಲಿನ ವಿಭಾಗದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ ಮತ್ತು ವಾಕ್ಯದ ಮಧ್ಯದಲ್ಲಿ ನಿಗದಿತ ಕಡಿತವು ಬಾಧ್ಯತೆಯ ತರ್ಕವನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ. ರಿಕರ್ಸಿವ್ ಚಂಕಿಂಗ್ ಮೊದಲು ನೈಸರ್ಗಿಕ ವಿಭಜಕಗಳ ಮೇಲೆ—ಪ್ಯಾರಾಗ್ರಾಫ್‌ಗಳು, ನಂತರ ವಾಕ್ಯಗಳು—ಕಡಿತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ನಂತರ ಟೋಕನ್ ಮಿತಿಯನ್ನು ಹೇರುತ್ತದೆ. ಇದು ಪರಿಹಾರ ಅಥವಾ ಹೊಣೆಗಾರಿಕೆಯ ಕಲಮುಗಳನ್ನು ಅಖಂಡವಾಗಿಡುತ್ತದೆ.

API ಡಾಕ್ಯುಮೆಂಟೇಶನ್‌ಗಾಗಿ, ಫಂಕ್ಷನ್-ಅವೇರ್ ಚಂಕಿಂಗ್ (function-aware chunking) ಬಳಸಿ. ಡೆವಲಪರ್‌ಗಳು ಯಾದೃಚ್ಛಿಕ ಪ್ಯಾರಾಗ್ರಾಫ್‌ಗಳಿಗಾಗಿ ಹುಡುಕುವುದಿಲ್ಲ; ಅವರು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು (endpoints), ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು ಮತ್ತು ಎರರ್ ಸಿಗ್ನೇಚರ್‌ಗಳಿಗಾಗಿ ಹುಡುಕುತ್ತಾರೆ. ಒಂದು ಚಂಕ್ ಸಂಪೂರ್ಣ ಫಂಕ್ಷನ್ ಸಿಗ್ನೇಚರ್, ಅದರ ವಿವರಣೆ ಮತ್ತು ರಿಟರ್ನ್ ಸ್ಕೀಮಾವನ್ನು ಒಂದೇ ತಾರ್ಕಿಕ ಘಟಕವಾಗಿ ಹೊಂದಿರಬೇಕು. ಒಂದು ವೇಳೆ ನೀವು ಆ ಬ್ಲಾಕ್ ಅನ್ನು ಅರ್ಧಕ್ಕೆ ವಿಂಗಡಿಸಿದರೆ, ರಿಟ್ರಿೀವಲ್ ಸಿಸ್ಟಮ್ ಅರ್ಧದ ಮಾಹಿತಿಯನ್ನು ಮಾತ್ರ ನೀಡುತ್ತದೆ ಮತ್ತು ಜನರೇಷನ್ ಮಾಡೆಲ್ ಉಳಿದದ್ದನ್ನು ಕಲ್ಪಿತವಾಗಿ (hallucinates) ಹೇಳುತ್ತದೆ.

ಸಪೋರ್ಟ್ ಟಿಕೆಟ್‌ಗಳಿಗಾಗಿ (support tickets), ಸಂಭಾಷಣೆಯ ಹಂತಗಳನ್ನು (conversation turns) ಅನುಸರಿಸುವ ಸೆಮ್ಯಾಂಟಿಕ್ ಚಂಕಿಂಗ್ ಮೇಲೆ ಅವಲಂಬಿಸಿ. ಸಪೋರ್ಟ್ ಥ್ರೆಡ್‌ಗಳು ಲೀನಿಯರ್ ಮತ್ತು ಪುನರಾವರ್ತಿತವಾಗಿರುತ್ತವೆ. ಗ್ರಾಹಕರು ಸಮಸ್ಯೆಯನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತಾರೆ, ಏಜೆಂಟ್ ಲಾಗ್‌ಗಳನ್ನು ಕೇಳುತ್ತಾರೆ, ಗ್ರಾಹಕರು ಅವುಗಳನ್ನು ಲಗತ್ತಿಸುತ್ತಾರೆ. ಪ್ರತಿ ಹಂತವೂ ತನ್ನದೇ ಆದ ಸೆಮ್ಯಾಂಟಿಕ್ ಘಟಕವಾಗಿದೆ. ಹಂತಗಳ ಮೂಲಕ ಚಂಕಿಂಗ್ ಮಾಡುವುದರಿಂದ ಯಾರು, ಏನು ಮತ್ತು ಯಾವಾಗ ಹೇಳಿದರು ಎಂಬುದು ಉಳಿಯುತ್ತದೆ, ಇದು ಬಳಕೆದಾರರು "ಮಂಗಳವಾರ ಏಜೆಂಟ್ ಏನು ಸೂಚಿಸಿದರು?" ಎಂದು ಕೇಳಿದಾಗ ಮುಖ್ಯವಾಗುತ್ತದೆ.

ಆಂತರಿಕ ವಿಕisಗಳಿಗಾಗಿ (internal wikis), ಏಜೆಂಟಿಕ್ ಚಂಕಿಂಗ್ (agentic chunking) ಪ್ರಯತ್ನಿಸಿ. ಒಂದು ವಿಭಾಗವನ್ನು LLM ಗೆ ನೀಡಿ ಮತ್ತು ಒಂದು ವಿಷಯ ಎಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು ಎಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಕೇಳಿ. ಇದು ಇಂಜೆಸ್ಟ್ ಸಮಯದಲ್ಲಿ (ingest time) ಹೆಚ್ಚು ವೆಚ್ಚದಾಯಕವಾಗಬಹುದು, ಆದರೆ ವಿಕisಗಳು ಅಸ್ತವ್ಯಸ್ತವಾಗಿರುತ್ತವೆ. ಪುಟಗಳು ವಿವಿಧ ತಂಡಗಳಿಂದ ಬಂದ ಸಂಬಂಧವಿಲ್ಲದ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ ಮತ್ತು ಮಾನವ ನಿರ್ಧರಿಸಿದ ಗಡಿಗಳು ಅಪರೂಪವಾಗಿ ಸಹಾಯ ಮಾಡುತ್ತವೆ. ವಿಷಯದ ಬದಲಾವಣೆಗಳ ಆಧಾರದ ಮೇಲೆ ಮಾಡೆಲ್ ಗಡಿಗಳನ್ನು ಹಾಕಲು ಬಿಡುವುದರಿಂದ ಗೊಂದಲವು (noise) ಗಣನೀಯವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ.

ಒಂದೇ ಪೈಪ್‌ಲೈನ್‌ಯಲ್ಲಿ ಹಲವಾರು ಸ್ಟ್ರಾಟಜಿಗಳನ್ನು ಚಲಾಯಿಸಲು ಇಂಜೆಸ್ಟ್ ಸಮಯದಲ್ಲಿ ದಾಖಲೆಗಳನ್ನು ವಿಧಗಳ ಮೂಲಕ ಟ್ಯಾಗ್ ಮಾಡುವುದು ಅಗತ್ಯವಾಗಿದೆ. ಆ ಸಣ್ಣ ಸ್ಕೀಮಾ ಶಿಸ್ತು ತಕ್ಷಣವೇ ಪ್ರಯೋಜನ ನೀಡುತ್ತದೆ.

ಸರ್ಚ್ ವಿಧಾನಗಳನ್ನು ಸಂಯೋಜಿಸಿ, ಒಂದನ್ನು ಮಾತ್ರ ಆರಿಸಿಕೊಳ್ಳಬೇಡಿ

ವೆಕ್ಟರ್ ಸರ್ಚ್ ಉದ್ದೇಶವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ನಿಖರವಾದ ಹೊಂದಾಣಿಕೆಗಳ (exact matches) ವಿಷಯದಲ್ಲಿ ಇದು thường ವಿಫಲವಾಗುತ್ತದೆ. ERR_CONNECTION_REFUSED ಎಂಬ ಎರರ್ ಕೋಡ್ ಅಥವಾ ನಿರ್ದಿಷ್ಟ SKU ಬಗ್ಗೆ ಕೇಳಿದಾಗ, ಡೆನ್ಸ್ ಎಂಬೆಡ್ಡಿಂಗ್‌ಗಳು (dense embeddings) ಪರಿಕಲ್ಪನಾತ್ಮಕವಾಗಿ ಸಮಾನವಾದ ಆದರೆ ವಾಸ್ತವಿಕವಾಗಿ ತಪ್ಪು ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡಬಹುದು. BM25, ಅಂದರೆ ಕ್ಲಾಸಿಕ್ ಕೀವರ್ಡ್ ಸ್ಪಾರ್ಸ್ ರಿಟ್ರಿೀವಲ್ ವಿಧಾನವು ನಿಖರವಾದ ಸ್ಟ್ರಿಂಗ್‌ಗಳನ್ನು ಸುಂದರವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ ಆದರೆ ಸೆಮ್ಯಾಂಟಿಕ್ ಸೂಕ್ಷ್ಮತೆಯನ್ನು (semantic nuance) 놓ಕುತ್ತದೆ. ನಿಮಗೆ ಎರಡೂ ಬೇಕು.

ಹೈಬ್ರಿಡ್ ರಿಟ್ರಿೀವಲ್ (hybrid retrieval) ಬಳಸಿ. ವೆಕ್ಟರ್ ಸರ್ಚ್ ಮತ್ತು BM25 ಅನ್ನು ಸಮಾಂತರವಾಗಿ ಚಲಾಯಿಸಿ. ನಂತರ ಅವುಗಳನ್ನು Reciprocal Rank Fusion (RRF) ಮೂಲಕ ಸಂಯೋಜಿಸಿ. RRF ಎರಡೂ ವಿಧಾನಗಳು ಸಂಬಂಧಿತ ಎಂದು ಒಪ್ಪುವ ದಾಖಲೆಗಳಿಗೆ ಹೆಚ್ಚಿನ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ, ಹಾಗೆಯೇ ಯಾವುದಾದರೂ ಒಂದು ವಿಧಾನದಿಂದ ಬರುವ ಬಲವಾದ ಅಭ್ಯರ್ಥಿಗಳನ್ನು ಎತ್ತಿ ತೋರಿಸುತ್ತದೆ. ಇದರ ಗಣಿತ ಸರಳವಾಗಿದೆ ಮತ್ತು ಫಲಿತಾಂಶವು ಸ್ಥಿರವಾಗಿದೆ: ಯಾವುದೇ ಒಂದೇ ರಿಟ್ರಿೀವಲ್ ವಿಧಾನವು ಅಂತಿಮ ರ್ಯಾಂಕಿಂಗ್ ಮೇಲೆ ಪ್ರಾಬಲ್ಯ ಸಾಧಿಸುವುದಿಲ್ಲ.

ಫ್ಯೂಷನ್ ನಂತರ, ಕ್ರಾಸ್-ಎನ್‌ಕೋಡರ್ ರೀರಾಂಕರ್ (cross-encoder reranker) ಅನ್ನು ಸೇರಿಸಿ. ಮೊದಲ ಹಂತ — ವೆಕ್ಟರ್ ಪ್ಲಸ್ ಸ್ಪಾರ್ಸ್ ರಿಟ್ರಿೀವಲ್ — ವೇಗವಾಗಿ ಮತ್ತು ವ್ಯಾಪಕವಾಗಿರುತ್ತದೆ. ನಂತರ ಕ್ರಾಸ್-ಎನ್‌ಕೋಡರ್ ಪ್ರತಿ ಕ್ವೇರಿ-ಡಾಕ್ಯುಮೆಂಟ್ ಜೋಡಿಯನ್ನು ಪೂರ್ಣ ಗಮನದೊಂದಿಗೆ ಸ್ಕೋರ್ ಮಾಡುತ್ತದೆ, ಅಂದರೆ ಅದು ಮೂಲ ಪ್ರಶ್ನೆಯ ಎದುರು ಅಭ್ಯರ್ಥಿಯನ್ನು ವಾಸ್ತವವಾಗಿ ಓದುತ್ತದೆ. ಹೌದು, ಇದು ವಿಳಂಬವನ್ನು (latency) ಹೆಚ್ಚಿಸುತ್ತದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಅಂದಾಜು ಐವತ್ತು ರಿಂದ ನೂರು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳು. ಆದರೆ ನಿಖರತೆಯಲ್ಲಿನ (precision) ಲಾಭವು ಎಷ್ಟು ಹೆಚ್ಚಿದೆಯೆಂದರೆ ಆ ಬದಲಾವಣೆ ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣುತ್ತದೆ. ನೀವು ರಿಕಾಲ್ ಬಗ್ಗೆ ಕಾಳಜಿ ಹೊಂದಿದ್ದರೆ ಇದನ್ನು ಬಿಟ್ಟುಬಿಡಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಇಂಡೆಕ್ಸ್ ಅನ್ನು ಸರಿಪಡಿಸುವ ಮೊದಲು ಕ್ವೇರಿಯನ್ನು ಸರಿಪಡಿಸಿ

ಬಳಕೆದಾರರು ನಿಮ್ಮ ಸರ್ಚ್ ಇಂಜಿನ್‌ಗಾಗಿ ಕ್ವೇರಿಗಳನ್ನು ಬರೆಯುವುದಿಲ್ಲ. ಅವರು ಮನುಷ್ಯರಿಗಾಗಿ ಬರೆಯುತ್ತಾರೆ. “ಇದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ” ಎಂಬುದು ಸಾಮಾನ್ಯ ಸಪೋರ್ಟ್ ಕ್ವೇರಿ. ಅಸ್ಪಷ್ಟ ಫೀಚರ್ ವಿವರಣೆಯು ಸಾಮಾನ್ಯ ಆಂತರಿಕ ವಿಕಿ ಸರ್ಚ್ ಆಗಿದೆ. ನೀವು ಆ ಕಚ್ಚಾ ಇನ್‌ಪುಟ್‌ನೊಂದಿಗೆ ಇಂಡೆಕ್ಸ್ ಅನ್ನು ಹುಡುಕಿದರೆ, ನಿಮಗೆ ಕಸದಂತಹ (garbage) ಫಲಿತಾಂಶಗಳು ಸಿಗುತ್ತವೆ.

ಕ್ವೇರಿ ರಿಟ್ರೀವರ್ ಅನ್ನು ತಲುಪುವ ಮೊದಲು ಅದನ್ನು ಪರಿವರ್ತಿಸಿ.

ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಯ ಅನೇಕ ಆವೃತ್ತಿಗಳನ್ನು ರಚಿಸಲು query expansion ಬಳಸಿ. ಯಾರಾದರೂ “server down” ಎಂದು ಟೈಪ್ ಮಾಡಿದರೆ, ನಿಮ್ಮ ಸಿಸ್ಟಮ್ “service unavailable,” “502 error,” ಮತ್ತು “connection timeout” ಅನ್ನು ಸಹ ಹುಡುಕಬೇಕು. ಈ ಇಂಟೆಂಟ್ ವ್ಯತ್ಯಾಸಗಳನ್ನು (intent variants) ಒಳಗೊಳ್ಳುವುದರಿಂದ ನಮ್ಮ ರಿಕಾಲ್ (recall) 78% ರಿಂದ 96% ಕ್ಕೆ ಏರಿದೆ. ಇದು ಒಂದು ಹಂತದ ಪ್ರಕ್ರಿಯೆಯಾಗಿದ್ದು, ಇದರಿಂದ ಆಗುವ ಲಾಭಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಇದರ ವೆಚ್ಚ ಬಹುತೇಕ ಶೂನ್ಯವಾಗಿದೆ.

ಸಂಕೀರ್ಣ ಪ್ರಶ್ನೆಗಳಿಗಾಗಿ query decomposition ಬಳಸಿ. ಬಳಕೆದಾರರು “How do I migrate from the legacy billing API to the new one and what breaking changes affect enterprise accounts?” ಎಂಬಂತಹ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಿದಾಗ, ಅದನ್ನು ಉಪ-ಪ್ರಶ್ನೆಗಳಾಗಿ ವಿಂಗಡಿಸಿ. ಒಂದು ಉಪ-ಪ್ರಶ್ನೆಯು ಮೈಗ್ರೇಷನ್ ಹಂತಗಳನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡಿದ್ದರೆ, ಇನ್ನೊಂದು ಎಂಟರ್‌ಪ್ರೈಸ್-ನಿರ್ದಿಷ್ಟ ಬ್ರೇಕಿಂಗ್ ಚೇಂಜಸ್‌ಗಳನ್ನು (breaking changes) ಗುರಿಯಾಗಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಪ್ರತಿಯೊಂದೂ ಇಂಡೆಕ್ಸ್‌ನ ವಿಭಿನ್ನ ಭಾಗವನ್ನು ತಲುಪುತ್ತದೆ. ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಲँगವೇಜ್ ಮಾಡೆಲ್ ಗೊಂದಲಮಯ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋದಲ್ಲಿ ಊಹಿಸುವ ಬದಲು, ಸರಿಯಾಗಿ ರಿಟ್ರೀವ್ ಮಾಡಲಾದ ಚಂಕ್‌ಗಳಿಂದ ಅಂತಿಮ ಉತ್ತರವನ್ನು ಸಂಶ್ಲೇಷಿಸುತ್ತದೆ.

ಹೈಪರ್‌ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಊಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ

ನಿಮ್ಮ ಬಳಿ ಹಲವಾರು ಚಂಕಿಂಗ್ ಸ್ಟ್ರಾಟಜಿಗಳು (chunking strategies), ಹೈಬ್ರಿಡ್ ರಿಟ್ರಿವಲ್ ಮತ್ತು ಕ್ವೇರಿ ಟ್ರಾನ್ಸ್‌ಫರ್ಮೇಷನ್ ಇದ್ದ ನಂತರ, ನೀವು ಒಂದು ಕಾಂಬಿನೇಟೋರಿಯಲ್ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತೀರಿ. ಚಂಕ್ ಸೈಜ್, ಓವರ್‌ಲ್ಯಾಪ್, ಫ್ಯೂಷನ್ ವೇಟ್ಸ್, ರೀರಾಂಕರ್ ಡೆಪ್ತ್ ಮತ್ತು ಎಕ್ಸ್‌ಪಾನ್ಶನ್ ಕೌಂಟ್ ಎಲ್ಲವೂ ಒಂದಕ್ಕೊಂದು ಸಂಬಂಧಿಸಿರುತ್ತವೆ. ಒಂದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಬದಲಾಯಿಸುವುದು ಇನ್ನೊಂದನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ. ಈ ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಗ್ರಿಡ್ ಸರ್ಚ್ (Grid search) ಮಾಡುವುದು ವ್ಯರ್ಥ ಮತ್ತು ನಿಧಾನಗತಿಯ ಕೆಲಸ.

ಅದಕ್ಕೆ ಬದಲಾಗಿ ಬೇಯೇಶಿಯನ್ ಆಪ್ಟಿಮೈಸೇಶನ್ (Bayesian optimization) ಬಳಸಿ. ಇದನ್ನು ಒಂದು ಮೆಷಿನ್ ಲರ್ನಿಂಗ್ ಟ್ಯೂನಿಂಗ್ ಕೆಲಸದಂತೆ ಪರಿಗಣಿಸಿ. ನಿಮ್ಮ ಉದ್ದೇಶವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಿ: ಲೇಟೆನ್ಸಿಯನ್ನು (latency) ಒಂದು ಮಿತಿಯಲ್ಲಿ ಇಡುತ್ತಾ ರಿಕಾಲ್ ಅನ್ನು ಗರಿಷ್ಠಗೊಳಿಸಿ. ಒಂದು ಗೋಲ್ಡನ್ ಡೇಟಾಸೆಟ್ (golden dataset) ಅನ್ನು ನಿರ್ಮಿಸಿ — ಅಂದರೆ ಯಾವ ಚಂಕ್‌ಗಳನ್ನು ರಿಟ್ರೀವ್ ಮಾಡಬೇಕು ಎಂಬುದು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿದಿರುವ ಕೆಲವು ನೂರಾರು ಪ್ರತಿನಿಧಿ ಪ್ರಶ್ನೆಗಳು. ನಂತರ ಬೇಯೇಶಿಯನ್ ಸರ್ಚ್ ಅನ್ನು ಕಾನ್ಫಿಗರೇಶನ್ ಸ್ಪೇಸ್ ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಅನ್ವೇಷಿಸಲು ಬಿಡಿ. ಇದು ಯಾವುದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದರ ಪ್ರೊಬಾಬಿಲಿಸ್ಟಿಕ್ ಮಾಡೆಲ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಅತ್ಯಂತ ಭರವಸೆಯ ಪ್ರದೇಶಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ.

ಪ್ರತಿ ಕಾಂಡಿಡೇಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ಕೂಡ ಸ್ಟೇಜಿಂಗ್ (staging) ತಲುಪುವ ಮೊದಲು ಗೋಲ್ಡನ್ ಡೇಟಾಸೆಟ್ ಅನ್ನು ಪಾಸಾಗಬೇಕು. ಹೊಸ ಚಂಕ್ ಸೈಜ್ ರಿಕಾಲ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಿದರೆ ಅಥವಾ ಹೆಚ್ಚು ಭಾರವಾದ ರೀರಾಂಕರ್ ಲೇಟೆನ್ಸಿ ಬಜೆಟ್ ಅನ್ನು ಮೀರಿಸಿದರೆ, ಆಪ್ಟಿಮೈಸೇಶನ್ ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪತ್ತೆಹಚ್ಚುತ್ತದೆ. ಇದು ಚರ್ಚೆ ಮತ್ತು ವಾದಗಳನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. 256 ಅಥವಾ 512 ಟೋಕನ್‌ಗಳು ಯಾವುದು "ಉತ್ತಮ" ಎಂಬ ಬಗ್ಗೆ ಚರ್ಚಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಓದಲು ಪ್ರಾರಂಭಿಸಿ.

ಫಲಿತಾಂಶ

ನಾವು ನಿರೀಕ್ಷಿಸಿದಂತೆಯೇ ಪೈಪ್‌ಲೈನ್ ಬದಲಾವಣೆಗಳು ಸಂಯೋಜಿತವಾಗಿ ಕೆಲಸ ಮಾಡಿದವು.

  • Recall@10 78% ರಿಂದ 95% ಕ್ಕೆ ಏರಿತು.
  • P95 latency 850 ms ನಿಂದ 320 ms ಕ್ಕೆ ಇಳಿಯಿತು.
  • Hallucination rate 12% ರಿಂದ 3% ಕ್ಕೆ ಇಳಿಯಿತು.
  • Cost per query 38% ರಷ್ಟು ಇಳಿಕೆಯಾಯಿತು, ಏಕೆಂದರೆ ಉತ್ತಮ ರಿಟ್ರಿವಲ್ ನಮಗೆ ಸಣ್ಣ ಜನರೇಷನ್ ಮಾಡೆಲ್ ಮತ್ತು ಕಡಿಮೆ ಪ್ರಾಂಪ್ಟ್ ಟೋಕನ್‌ಗಳನ್ನು ಬಳಸಲು ಅನುವು ಮಾಡಿಕೊಟ್ಟಿತು.

ಲೇಟೆನ್ಸಿ ಇಳಿಕೆಯು ತಂಡದ ಕೆಲವು ಜನರನ್ನು ಆಶ್ಚರ್ಯಚಕಿತಗೊಳಿಸಿತು. ರೀರಾಂಕರ್‌ಗಳು ಮತ್ತು ಕ್ವೇರಿ ಎಕ್ಸ್‌ಪಾನ್ಶನ್ ಅನ್ನು ಸೇರಿಸುವುದು ಕೆಲಸವನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ ಎಂದು ಕೇಳಿಸುತ್ತದೆ. ಆದರೆ ರಿಟ್ರಿವಲ್ ಗುಣಮಟ್ಟ ಸುಧಾರಿಸಿದ್ದರಿಂದ, ಜನರೇಷನ್ ಮಾಡೆಲ್‌ಗೆ ಕಡಿಮೆ ಪ್ರಾಂಪ್ಟಿಂಗ್, ಕಡಿಮೆ ಊಹೆ ಮತ್ತು ಕಡಿಮೆ ರಿಟ್ರೈಗಳ ಅಗತ್ಯವಿತ್ತು. ಉತ್ತಮ ರಿಟ್ರಿವಲ್ ಎಲ್ಲವನ್ನೂ ಡೌನ್‌ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಅಗ್ಗವಾಗಿಸುತ್ತದೆ.

ರಿಟ್ರಿವಲ್ ಅನ್ನು ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್‌ನಂತೆ ಪರಿಗಣಿಸಿ

ರಿಟ್ರಿವಲ್ ಎಂಬುದು ನೀವು ಒಮ್ಮೆ ರನ್ ಮಾಡಿ ಮರೆತುಬಿಡುವ ನೋಟ್‌ಬುಕ್ ಅಲ್ಲ. ಇದು ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ (infrastructure), ಮತ್ತು ಇದನ್ನು ಕೋಡ್‌ನಂತೆ ನಿರ್ವಹಿಸಬೇಕು. ನಿಮ್ಮ ಚಂಕಿಂಗ್ ಸ್ಟ್ರಾಟಜಿಗಳಿಗೆ ವರ್ಷನ್ ನೀಡಿ. ಕಾನೂನು ತಂಡವು ಹೊಸ ಕಾಂಟ್ರಾಕ್ಟ್ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದಾಗ, ಅದು ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ತಲುಪುವ ಮೊದಲು ನಿಮ್ಮ ರಿಕರ್ಸಿವ್ ಸ್ಪ್ಲಿಟರ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ. ನಿಮ್ಮ ಗೋಲ್ಡನ್ ಡೇಟಾಸೆಟ್ ಅನ್ನು ಕಳೆದ ತ್ರೈಮಾಸಿಕದ ಸ್ಥಿರ CSV ಆಗಿ ಇಡದೆ, ಜೀವಂತ ದಾಖಲೆಗಳಾಗಿ ನಿರ್ವಹಿಸಿ. ನಿಮ್ಮ ಇವ್ಯಾಲ್ಯೂಯೇಷನ್‌ಗಳನ್ನು CI ಯಲ್ಲಿ ಆಟೊಮೇಷನ್ ಮಾಡಿ, ಇದರಿಂದ ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್ ಅಥವಾ ಫ್ಯೂಷನ್ ವೇಟ್ ಅನ್ನು ಮಾರ್ಪಡಿಸುವ ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ (pull request) ಮನುಷ್ಯರು ಪರಿಶೀಲಿಸುವ ಮೊದಲೇ ರಿಕಾಲ್ ಮತ್ತು ಲೇಟೆನ್ಸಿ ಸಂಖ್ಯೆಗಳೊಂದಿಗೆ ಕಾಮೆಂಟ್ ಪಡೆಯುತ್ತದೆ.

ನಿಮ್ಮ ಬಳಕೆದಾರರು ನೀವು ಯಾವ ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್ ಬಳಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಎಂದಿಗೂ ಕೇಳುವುದಿಲ್ಲ. ಅವರು ನಿಮ್ಮ ಚಂಕಿಂಗ್ ಹ್ಯೂರಿಸ್ಟಿಕ್ ಅಥವಾ ನಿಮ್ಮ ರೀರಾಂಕರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ. ಉತ್ತರ ಸರಿಯಾಗಿದೆಯೇ, ಅದು ವೇಗವಾಗಿ ಬರುತ್ತಿದೆಯೇ ಮತ್ತು ಅವರು ಅದನ್ನು ನಂಬಬಹುದೇ ಎಂಬುದರ ಬಗ್ಗೆ ಮಾತ್ರ ಅವರು ಕಾಳಜಿ ವಹಿಸುತ್ತಾರೆ. ಆ ನಂಬಿಕೆಯನ್ನು ಗಳಿಸುವ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸಿ, ಅದನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಅಳೆಯಿರಿ ಮತ್ತು ರಿಟ್ರಿವಲ್ ಅನ್ನು ಕೇವಲ ನಂತರದ ಆಲೋಚನೆಯಂತೆ (afterthought) ಪರಿಗಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ.

Source: Optimizing RAG At Scale
Join the discussion: GyaanSetu AI Community