ನಿಮ್ಮ RAG ಪೈಪ್ಲೈನ್ ಸಾಮಾನ್ಯ ಲೋಡ್ ಟೆಸ್ಟ್ ಅನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿ ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ. p95 latency ಆರೋಗ್ಯಕರವಾಗಿದೆ. ದೋಷದ ಪ್ರಮಾಣವು ಶೂನ್ಯಕ್ಕೆ ಹತ್ತಿರದಲ್ಲಿದೆ. ಆದರೂ ಬಳಕೆದಾರರು ಪ್ರಶ್ನೆಯನ್ನು ತಪ್ಪಿಸುವ, ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ದಾಖಲೆಗಳನ್ನು ಉಲ್ಲೇಖಿಸುವ ಅಥವಾ ಆರು ತಿಂಗಳ ಹಿಂದೆ ಅಪ್ಲೋಡ್ ಮಾಡಿದ ವೈಟ್ ಪೇಪರ್ನಿಂದ ಅಪ್ರಸ್ತುತ ಪ್ಯಾರಾಗ್ರಾಫ್ಗಳನ್ನು ಹೊರತೆಗೆಯುವ ಉತ್ತರಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತಾರೆ. ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಆದರೆ ಅನುಭವವು ಅದು ಕೆಟ್ಟದಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ.
ಈ ವ್ಯತ್ಯಾಸವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವುದು ಏಕೆಂದರೆ ಸಾಂಪ್ರದಾಯಿಕ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಟೆಸ್ಟಿಂಗ್ ಅನ್ನು ರಿಕ್ವೆಸ್ಟ್-ರಿಸ್ಪಾನ್ಸ್ ಸಿಸ್ಟಮ್ಗಳಿಗಾಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆಯೇ ಹೊರತು, ಯೋಚಿಸುವ ಸಿಸ್ಟಮ್ಗಳಿಗಾಗಿ ಅಲ್ಲ. ನೀವು ಒಂದು REST ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಸಾವಿರಾರು ಸಮಾಂತರ ರಿಕ್ವೆಸ್ಟ್ಗಳನ್ನು ಕಳುಹಿಸಿದಾಗ, ನಿಮ್ಮ ಸರ್ವರ್ಗಳು ಸ್ಥಿರವಾಗಿವೆ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದು ತಿಳಿಯುತ್ತದೆ. ಆದರೆ ನಿಮ್ಮ ರಿಟ್ರಿವಲ್ ಲೇಯರ್ ಸರಿಯಾದ ಚಂಕ್ಗಳನ್ನು ತರುತ್ತಿದೆಯೇ, ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ ಟೆಂಪ್ಲೇಟ್ ಸಂದರ್ಭವನ್ನು (context) ಉಳಿಸಿಕೊಳ್ಳುತ್ತಿದೆಯೇ ಅಥವಾ ವೆಕ್ಟರ್ ಸ್ಟೋರ್ ಖಾಲಿಯಾದಾಗ ಮಾಡೆಲ್ ತಾನಾಗಿಯೇ ಮೂಲಗಳನ್ನು (sources) ಸೃಷ್ಟಿಸುತ್ತಿದೆಯೇ ಎಂಬ ಬಗ್ಗೆ ನೀವು ಏನನ್ನೂ ತಿಳಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಲೋಡ್ ಟೆಸ್ಟಿಂಗ್ ವೇಗವನ್ನು ಅಳೆಯುತ್ತದೆ. ಆದರೆ RAG ಅಪ್ಲಿಕೇಶನ್ಗಳು ನೀವು ತಿಳುವಳಿಕೆಯನ್ನು (understanding) ಅಳೆಯಬೇಕೆಂದು ಬಯಸುತ್ತವೆ.
Beyond Status Code 200
ಒಂದು ಸಾಮಾನ್ಯ API ಲೋಡ್ ಟೆಸ್ಟ್ ಮೂರು ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ: ಲಭ್ಯತೆ (availability), ಲೇಟೆನ್ಸಿ (latency), ಮತ್ತು ಥ್ರೂಪುಟ್ (throughput). ಸರ್ವರ್ ಉತ್ತರಿಸಿದೆಯೇ, ಅದಕ್ಕೆ ಎಷ್ಟು ಸಮಯ ತಗುಲಿತು ಮತ್ತು ಅದು ಎಷ್ಟು ಏಕಕಾಲಿಕ ಬಳಕೆದಾರರನ್ನು ತಡೆದುಕೊಳ್ಳಬಲ್ಲದು ಎಂಬುದನ್ನು ಇದು ಕೇಳುತ್ತದೆ. ಒಂದು RAG ಅಪ್ಲಿಕೇಶನ್ಗೆ, ಆ ಸಂಖ್ಯೆಗಳು ಕೇವಲ ಪೂರ್ವಭಾವಿ ಅಗತ್ಯಗಳೇ ಹೊರತು ಅಂತಿಮ ತೀರ್ಮಾನಗಳಲ್ಲ. ವೇಗವಾದ ತಪ್ಪು ಉತ್ತರವು ಇನ್ನೂ ತಪ್ಪು ಉತ್ತರವೇ ಆಗಿರುತ್ತದೆ, ಮತ್ತು ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ತಪ್ಪು ಉತ್ತರಗಳು ನೀಡಿದಾಗ ಅದರ ವೆಚ್ಚವು ನಿಧಾನಗತಿಯ ಉತ್ತರಗಳಿಗಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ.
RAG ಪ್ರತಿ ರಿಕ್ವೆಸ್ಟ್ಗೆ ಎರಡು ವಿಭಿನ್ನ ಹಂತಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. ಮೊದಲನೆಯದಾಗಿ, ಸಿಸ್ಟಮ್ ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಯನ್ನು ಎಂಬೆಡ್ಡಿಂಗ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ವೆಕ್ಟರ್ ಸ್ಟೋರ್ ಅನ್ನು ಕ್ವೇರಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಂದರ್ಭದ ಚಂಕ್ಗಳ (context chunks) ಸೆಟ್ ಅನ್ನು ಹಿಂಪಡೆಯುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ, ಆ ಚಂಕ್ಗಳನ್ನು ಪ್ರಾಂಪ್ಟ್ಗೆ ತುಂಬುತ್ತದೆ, ಎಲ್ಲವನ್ನೂ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಪೂರ್ಣಗೊಳಿಸಿದ ಉತ್ತರವನ್ನು ಸ್ಟ್ರೀಮ್ ಮಾಡುತ್ತದೆ. ಸಾಂಪ್ರದಾಯಿಕ ಪರೀಕ್ಷೆಗಳು ಇವುಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಒಂದೇ "ರಿಸ್ಪಾನ್ಸ್ ಟೈಮ್" ಮೆಟ್ರಿಕ್ ಆಗಿ ನೋಡುತ್ತವೆ. ಅವು ರಿಟ್ರಿವಲ್ ಇಂಜಿನ್ ಮತ್ತು ಜನರೇಟರ್ ಅನ್ನು ಒಂದೇ ಬ್ಲಾಕ್ ಬಾಕ್ಸ್ ಆಗಿ ಪರಿಗಣಿಸುತ್ತವೆ.
ನೀವು ಆ ಬಾಕ್ಸ್ ಅನ್ನು ತೆರೆಯಬೇಕಾಗುತ್ತದೆ. ನಿಮ್ಮ ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ನಿಧಾನವಾದರೆ, ರಿಟ್ರಿವಲ್ ಲೇಟೆನ್ಸಿ ಹೆಚ್ಚಾಗುತ್ತದೆ. LLM ಇನ್ನೂ ವೇಗವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು, ಆದರೆ ಅದು ಅವಸರದಲ್ಲಿ ತರಿಸಿದ ಕಸದಂತಹ ಸಂದರ್ಭದ (garbage context) ಆಧಾರದ ಮೇಲೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿರುತ್ತದೆ. ಅಥವಾ, ವೆಕ್ಟರ್ ಸರ್ಚ್ ವೇಗವಾಗಿ ಇರುತ್ತದೆ ಆದರೆ LLM ಕ್ಯೂ (queue) ತುಂಬಿ ಹೋಗಬಹುದು, ಇದರಿಂದ ಬಳಕೆದಾರರು ಬ್ಲಿಂಕಿಂಗ್ ಕರ್ಸರ್ ಅನ್ನು ನೋಡುವವರೆಗೆ time-to-first-token ಹೆಚ್ಚಾಗುತ್ತದೆ. ಒಂದು ಏಕಕಾಲಿಕ ಎಂಡ್-ಟು-ಎಂಡ್ ಟೈಮರ್ ಈ ಎರಡೂ ವೈಫಲ್ಯಗಳನ್ನು ಮರೆಮಾಚುತ್ತದೆ.
Test the Retrieval, Not Just the Database
ಹೆಚ್ಚಿನ ತಂಡಗಳು ಒಂದು ವೇಗದ ವೆಕ್ಟರ್ ಸರ್ಚ್ ಬೆಂಚ್ಮಾರ್ಕ್ ಅನ್ನು ನಡೆಸುತ್ತವೆ ಮತ್ತು ರಿಟ್ರಿವಲ್ ಲೇಯರ್ ಪರೀಕ್ಷೆಯಾಗಿದೆ ಎಂದು ಹೇಳಿಕೊಳ್ಳುತ್ತವೆ. ಆ ಬೆಂಚ್ಮಾರ್ಕ್ ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ಆರಿಸಿದ ಕ್ವೇರಿಗಾಗಿ ಡೇಟಾಬೇಸ್ ಎಷ್ಟು ವೇಗವಾಗಿ ಹತ್ತಿರದ ನೆರೆಹೊರೆಯವರನ್ನು (nearest neighbors) ನೀಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅಳೆಯುತ್ತದೆ. ಆದರೆ ಆ ನೆರೆಹೊರೆಯರು ನಿಜವಾಗಿಯೂ ಉತ್ತರವನ್ನು ಹೊಂದಿದ್ದಾರೆಯೇ ಎಂಬುದನ್ನು ಅದು ಅಪರೂಪಕ್ಕೆ ಅಳೆಯುತ್ತದೆ.
ರಿಟ್ರಿವಲ್ ಗುಣಮಟ್ಟವು ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಸೂಕ್ಷ್ಮವಾಗಿ ಬದಲಾಗುತ್ತದೆ. ಏಕಕಾಲಿಕ ಒತ್ತಡದ ಅಡಿಯಲ್ಲಿ, approximate nearest neighbor indexesಗಳು ಪ್ರತ್ಯೇಕವಾಗಿ ಕೆಲಸ ಮಾಡುವಾಗ ಇರುವಂತೆ ವರ್ತಿಸುವುದಿಲ್ಲ. ನೋಟ್ಬುಕ್ನಲ್ಲಿ ಪರಿಪೂರ್ಣವಾಗಿ ಕಂಡ ಚಂಕಿಂಗ್ ಸ್ಟ್ರಾಟಜಿಗಳು, ಹತ್ತು ಸಾವಿರ ದಾಖಲೆಗಳು ಒಂದೇ ಎಂಬೆಡ್ಡಿಂಗ್ ಸ್ಪೇಸ್ಗಾಗಿ ಸ್ಪರ್ಧಿಸಿದಾಗ ಚಂಕ್ಗಳ ನಡುವಿನ ಸಂದರ್ಭವನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಶಾಂತ ಪರಿಸರದಲ್ಲಿ ಆದರ್ಶ ಪ್ಯಾರಾಗ್ರಾಫ್ ಅನ್ನು ನೀಡುವ ಕ್ವೇರಿಯು, ಇಂಡೆಕ್ಸ್ ಮರುನಿರ್ಮಾಣವಾಗುತ್ತಿರುವಾಗ ಅಥವಾ ಮೆಟಾಡೇಟಾ ಫಿಲ್ಟರಿಂಗ್ ರಿಕ್ವೆಸ್ಟ್ ಒತ್ತಡದ ಅಡಿಯಲ್ಲಿ ಇಲ್ಲದಾದಾಗ ತಪ್ಪು ಮಾರ್ಕೆಟಿಂಗ್ ಸ್ಲೈಡ್ ಅನ್ನು ತೋರಿಸಬಹುದು.
ಇದನ್ನು ಸರಿಯಾಗಿ ಪರೀಕ್ಷಿಸಲು, ನಿಮಗೆ ಒಂದು ಗ್ರೌಂಡ್-ಟ್ರೂತ್ ಡೇಟಾಸೆಟ್ ಬೇಕಾಗುತ್ತದೆ. ಯಾವ ಮೂಲ ದಾಖಲೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಬೇಕು ಎಂಬುದು ನಿಮಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ಪ್ರಶ್ನೆಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಿ. ಆ ಪ್ರಶ್ನೆಗಳನ್ನು ವಿವಿಧ ಏಕಕಾಲಿಕತೆಯ ಮಟ್ಟಗಳಲ್ಲಿ (concurrency levels) ಚಲಾಯಿಸಿ ಮತ್ತು ನಿರೀಕ್ಷಿತ ಚಂಕ್ಗಳು top-k ಫಲಿತಾಂಶಗಳಲ್ಲಿ ಇವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಕೇವಲ ಕ್ವೇರಿ ಅವಧಿಯನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಹಿಟ್ ರೇಟ್ (hit rate) ಅನ್ನು ಸಹ ಟ್ರ್ಯಾಕ್ ಮಾಡಿ. ನಿಮ್ಮ ಮೊದಲ ಐದು ಚಂಕ್ಗಳು ನಿರ್ಣಾಯಕ ಮೂಲವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸಿದರೆ, LLM ಎಚ್ಚರಗೊಳ್ಳುವ ಮೊದಲೇ ನಿಮ್ಮ ರಿಟ್ರಿವಲ್ ಪೈಪ್ಲೈನ್ ವಿಫಲವಾಗಿದೆ ಎಂದರ್ಥ.
ನೀವು ಅಂಚುಗಳನ್ನು (edges) ಸಹ ಸ್ಟ್ರೆಸ್-ಟೆಸ್ಟ್ ಮಾಡಬೇಕು. ಕಾರ್ಪಸ್ನಲ್ಲಿ ಉತ್ತರವಿಲ್ಲದ ಪ್ರಶ್ನೆಗಳನ್ನು ಸಲ್ಲಿಸಿ. ಅನೇಕ ಡೊಮೇನ್ಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗಬಹುದಾದ ಅಸ್ಪಷ್ಟ ಪ್ರಶ್ನೆಗಳನ್ನು ಸಲ್ಲಿಸಿ. ನಿಮ್ಮ ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್ನ ಟೋಕನ್ ಮಿತಿಯನ್ನು ಮೀರಿದ ಮತ್ತು ಸೈಲೆಂಟ್ ಆಗಿ ಕತ್ತರಿಸಲ್ಪಟ್ಟ (truncated) ಉದ್ದವಾದ ಪ್ರಶ್ನೆಗಳನ್ನು ಸಲ್ಲಿಸಿ. ರಿಟ್ರಿವಲ್ ಲೇಯರ್ ಏನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಪ್ರತಿ ಸಂದರ್ಭದಲ್ಲೂ, ಕಳೆದ ಮಿಲಿಸೆಕೆಂಡ್ಗಳಿಗಿಂತ ವೈಫಲ್ಯದ ವಿಧಾನವು (failure mode) ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದೆ.
When the Model Chokes Quietly
ಚಂಕ್ಗಳು LLM ಗೆ ತಲುಪಿದ ನಂತರ, ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಲೋಡ್ ಟೆಸ್ಟಿಂಗ್ ಸುಳ್ಳು ಹೇಳುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ