ಉತ್ತಮ ಸ್ನಿಪ್ಪೆಂಟ್‌ಗಳಿಗಾಗಿ ಪ್ರಶ್ನೆ-ಜಾಗೃತಿ ಸಂದರ್ಭ ಸಂಕೋಚನ

ಪ್ರತಿ ಉತ್ತರವು ಸಾಕ್ಷ್ಯದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಹುಡುಕಾಟ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಈ ಸಾಕ್ಷ್ಯವು ಸಾಮಾನ್ಯವಾಗಿ ದಾಖಲೆಗಳಿಂದ ಬರುತ್ತದೆ: ಶೀರ್ಷಿಕೆಗಳು, ಸಾರಾಂಶಗಳು, ತುಣುಕುಗಳು (chunks) ಮತ್ತು ಸ್ನಿಪ್ಪೆಂಟ್‌ಗಳು, ಇವುಗಳನ್ನು ಸಂದರ್ಭವಾಗಿ ಉತ್ತರ ಮಾದರಿ ಅಥವಾ ಏಜೆಂಟ್‌ಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ.

ಈ ಕಚ್ಚಾ ಸಂದರ್ಭವು ಗದ್ದಲಮಯವಾಗಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ವೆಬ್ ಪುಟವು ಬಳಕೆದಾರರ ವಿನಂತಿಗೆ ಅಗತ್ಯವಿರುವ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿರಬಹುದು, ಆದರೆ ಅದು ಅನಗತ್ಯ ಅಂಶಗಳನ್ನೂ ಹೊಂದಿರಬಹುದು. ಈ ಅನಗತ್ಯ ಅಂಶಗಳು ಮುಖ್ಯ ಭಾಗದಲ್ಲಿ ಮತ್ತು ನ್ಯಾವಿಗೇಷನ್ ಪಠ್ಯ ಅಂಶಗಳು, ಅಪ್ರಸ್ತುತ ಜಾಹೀರಾತುಗಳು, ಮೆಟಾಡೇಟಾ ಮುಂತಾದ ಸಹಾಯಕ ಅಂಶಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳಬಹುದು. ಈ ಅನಗತ್ಯ ಅಂಶಗಳನ್ನು ಮುಂದಿನ ಹಂತದ ಏಜೆಂಟ್‌ಗೆ ರವಾನಿಸುವುದರಿಂದ ಮೂರು ಸಮಸ್ಯೆಗಳು ಉಂಟಾಗುತ್ತವೆ.

ಮೊದಲು, ಇದು ನಿಖರತೆಯನ್ನು ಕುಗ್ಗಿಸುತ್ತದೆ. ಅತ್ಯಂತ ಶಕ್ತಿಶಾಲಿ ಮಾದರಿಗಳಿಗೂ ಸೀಮಿತ ಸಾಮರ್ಥ್ಯವಿದೆ. ಅನಾವಶ್ಯಕ ಮಾಹಿತಿಯ ದೀರ್ಘ ಹರಿವುಗಳು ಮಾದರಿಯ ಸಾಮರ್ಥ್ಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತವೆ; ಇದರ ಫಲವಾಗಿ “context rot” ಉಂಟಾಗುತ್ತದೆ, ಇದು ನಿಜವಾದ ಬಳಕೆದಾರರ ವಿನಂತಿಯನ್ನು ಪರಿಹರಿಸುವ ಮಾದರಿಯ ಸಾಮರ್ಥ್ಯವನ್ನು ಹಾನಿಗೊಳಿಸುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಅಂತಿಮ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಮುಖ್ಯ ಸಂಗತಿಗಳು ಕೈ ತಪ್ಪುವ, ಕಡಿಮೆ-ಗುಣಮಟ್ಟದ ಮಾಹಿತಿಗೆ ಅತಿಯಾದ ಮಹತ್ವ ಸಿಗುವ, ಅಥವಾ ಮೂಲದಲ್ಲಿ ಆಧಾರಗೊಳಿಸಲು ಕಷ್ಟವಾಗುವ ದಾವೆಗಳು ಉತ್ಪತ್ತಿಯಾಗುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು.

ಎರಡನೆಯದಾಗಿ, ಇದು ಲೇಟೆನ್ಸಿಯನ್ನು (latency) ಹಿಮ್ಮುಖಗೊಳಿಸುತ್ತದೆ. ದೀರ್ಘವಾದ ಸಂದರ್ಭ ಎಂದರೆ ಮುಂದಿನ ಹಂತದ ಮಾದರಿಯು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಹೆಚ್ಚಿನ ಟೋಕನ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ, ವಿಶೇಷವಾಗಿ ಪ್ರಶ್ನೆಗೆ ಅನೇಕ ಸಂಭಾವ್ಯ ಪುಟಗಳಿಂದ ಸಾಕ್ಷ್ಯದ ಅಗತ್ಯವಿರುವಾಗ. ಈ ಲೇಟೆನ್ಸಿ ವೆಚ್ಚದ ಒಂದು ಭಾಗವು ಪ್ರೀಫಿಲ್ ಹಂತದಲ್ಲಿ ಭರಿಸಲ್ಪಟ್ಟರೂ, ಹೆಚ್ಚು ಗಮನಾರ್ಹವಾದ ವೆಚ್ಚವು ತಾರ್ಕಿಕ (reasoning) ಹಂತದಲ್ಲಿ ಪಾವತಿಸಲ್ಪಡುತ್ತದೆ, ಅಪ್ರಸ್ತುತ ಸಂದರ್ಭವನ್ನು ಎದುರಿಸಲು ಮಾದರಿಗಳಿಗೆ ಹೆಚ್ಚಿನ ತಾರ್ಕಿಕ ಟೋಕನ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ.

ಮೂರನೆಯದಾಗಿ, ಇದು ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಮಾದರಿಗೆ ರವಾನಿಸುವ ಪ್ರತಿಯೊಂದು ಅನಗತ್ಯ ಟೋಕನ್ ಬಳಕೆದಾರರ ವಿನಂತಿಯನ್ನು ಪೂರೈಸುವುದನ್ನು ಹೆಚ್ಚು ವೆಚ್ಚದಾಯಕವನ್ನಾಗಿ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಗದ್ದಲದ ಸಂದರ್ಭದೊಂದಿಗೆ ಇನ್‌ಪುಟ್ ಟೋಕನ್ ಮತ್ತು ತಾರ್ಕಿಕ ಟೋಕನ್ ಬಳಕೆ ಎರಡೂ ಹೆಚ್ಚಾಗುತ್ತವೆ. ಅನಗತ್ಯ ಅಂಶಗಳು ಗುಣಮಟ್ಟವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಮಾತ್ರವಲ್ಲದೆ, ಆ ಕಳಪೆ ಗುಣಮಟ್ಟಕ್ಕಾಗಿ ನೀವು ಹೆಚ್ಚು ಹಣ ಪಾವತಿಸುವಂತೆ ಮಾಡುತ್ತವೆ.

ವಿಸ್ತರಿಸಿ

Perplexity‌ನ ಅನ್ವಯಿಕೆಗಳು ಮತ್ತು API Platform ಅಡ್ಡಲಾಗಿ ನಿಖರತೆ, ವೇಗ, ಹಾಗೂ ವೆಚ್ಚ-ಪರಿಣಾಮಕಾರಿತ್ವವನ್ನು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಮುಂದಕ್ಕೆ ಕೊಂಡೊಯ್ಯಲು, ನಾವು context precision ಅನ್ನು ಸುಧಾರಿಸುವಲ್ಲಿ ಭಾರೀ ಹೂಡಿಕೆ ಮಾಡುತ್ತೇವೆ. ಅದನ್ನು ನಾವು ಮಾಡುವ ಒಂದು ವಿಧಾನವೆಂದರೆ ನಮ್ಮ snippet generation ಆಲ್ಗೊರಿಥಮ್‌ಗಳನ್ನು ಪರಿಷ್ಕರಿಸುವುದು. ನಾವು snippet generation ಅನ್ನು context compression ಸಮಸ್ಯೆಯಾಗಿ ನೋಡುತ್ತೇವೆ. ನಿರ್ದಿಷ್ಟ ಮಾಹಿತಿಯನ್ನು ಹುಡುಕುವ ಮಾದರಿಗಳಿಗೆ ದಸ್ತಾವೇಜಿನ ಸಾಮಾನ್ಯ ಸಾರಾಂಶಗಳು ಅಥವಾ ಆಯ್ದ ಭಾಗಗಳಿಂದ ಲಾಭವಾಗುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ಬಳಕೆದಾರರ ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಅವರಿಗೆ ಮೂಲ ಮಾಹಿತಿಯಲ್ಲಿನ ಅತಿ ಚಿಕ್ಕ, ಅತ್ಯಂತ ನಿಖರವಾಗಿ ತೆಗೆದ ತುಣುಕು ಬೇಕಾಗುತ್ತದೆ. ಉಳಿದ ಎಲ್ಲವನ್ನೂ ತೆಗೆದುಹಾಕಬಹುದು ಮತ್ತು ತೆಗೆದುಹಾಕಲೇಬೇಕು.

ಆದ್ದರಿಂದ ಉತ್ತಮ ಸ್ನಿಪ್ಪೆಟ್ ಮೂರು ಕೆಲಸಗಳನ್ನು ಮಾಡಬೇಕು:

ಮಾದರಿಯ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಆಧರಿಸಲು ಅಗತ್ಯವಾದ ನಿಖರವಾದ ಸಾಕ್ಷ್ಯವನ್ನು ಒದಗಿಸುವ ಮೂಲಕ ನಿಖರತೆಯನ್ನು ಉತ್ತೇಜಿಸಿ.

LLM ಕರೆಯ ಮೊದಲು ಅಪ್ರಸ್ತುತ ಸಂದರ್ಭವನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ಲೇಟೆನ್ಸಿ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಿ.

ಉಲ್ಲೇಖದ ನಿಷ್ಠೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವ ಮೂಲಕ ಮತ್ತು ಮೂಲ ಪದಗಳನ್ನು ಹಾಗೆಯೇ ಉಳಿಸಿಕೊಳ್ಳುವ ಮೂಲಕ ಪತ್ತೆಹಚ್ಚುವಿಕೆಯನ್ನು (traceability) ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ಈ ತಿಂಗಳು, ನಾವು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು API Platform ಒಳಗೆ ಹೊಸ, ಅತ್ಯಾಧುನಿಕ ಸ್ನಿಪ್ಪೆಟ್ ಜನರೇಟರ್ ಅನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ. ಈ ಮಾಡ್ಯೂಲ್‌ನ ಪ್ರಮುಖ ಭಾಗವೆಂದರೆ ಪ್ರಶ್ನೆ-ಜಾಗೃತಿ ಸಂದರ್ಭ ಸಂಕೋಚನ ಮಾದರಿ (query-aware context compression model) ಇದು ಪ್ರತಿ ಪ್ರಶ್ನೆ ಮತ್ತು ಸಂಭಾವ್ಯ ಫಲಿತಾಂಶಕ್ಕಾಗಿ, ಯಾವ ವ್ಯಾಪ್ತಿಯನ್ನು (spans) ಸಂರಕ್ಷಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಈ ಲೇಖನವು ಈ ನಿರ್ಣಾಯಕ ಕಾರ್ಯದಲ್ಲಿ ಅತ್ಯುತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸಲು ಮಾದರಿಯನ್ನು ನಿರ್ಮಿಸುವ ಮತ್ತು ತರಬೇತಿ ನೀಡುವ ನಮ್ಮ ವಿಧಾನವನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಪ್ರಶ್ನೆ-ಜಾಗೃತಿ ಸಂಕೋಚನವಾಗಿ ಸ್ನಿಪ್ಪೆಟ್‌ಗಳು

ಮೊದಲನೆಯ ಕೆಲಸವೆಂದರೆ ಕಾರ್ಯವನ್ನೇ ವ್ಯಾಖ್ಯಾನಿಸುವುದು. ಈ ಮಾದರಿಯು ಏನು ಮಾಡಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ, ಮತ್ತು ಇನ್‌ಪುಟ್ ಮತ್ತು ಔಟ್‌ಪುಟ್ ಸ್ಕೀಮಾವನ್ನು ನಾವು ಹೇಗೆ ವ್ಯಾಖ್ಯಾನಿಸಬೇಕು?

ಸ್ನಿಪ್ಪೆಟ್ ವಿಧಾನಗಳು ಎರಡು ವಿಶಾಲವಾದ ವರ್ಗಗಳಿಗೆ ಸೇರುತ್ತವೆ. ಮೊದಲನೆಯದು ಆಯ್ಕೆ-ಆಧಾರಿತ (selection-based): ಪ್ರಸ್ತುತ ವಿಂಡೋ, ತುಣುಕು (chunk), ವಾಕ್ಯ ಅಥವಾ ಭಾಗವನ್ನು ಹುಡುಕಿ ಮತ್ತು ಅದನ್ನು ಮುಂದಿನ ಹಂತಕ್ಕೆ ರವಾನಿಸಿ. ಎರಡನೆಯದು ಉತ್ಪಾದನಾ-ಆಧಾರಿತ (generation-based): ಪುಟದಿಂದ ಪ್ರಶ್ನೆ-ಕೇಂದ್ರಿತ ಸಾರಾಂಶವನ್ನು ಬರೆಯಲು ಮಾದರಿಯನ್ನು ಕೇಳಿ.

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

ಬದಲಿಗೆ, ನಾವು ನಮ್ಮ ಕಾರ್ಯವನ್ನು ಪ್ರಶ್ನೆ-ಜಾಗೃತಿ ಹೊರತೆಗೆಯುವ ಸಂಕೋಚನವಾಗಿ (query-aware extractive compression) ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೇವೆ: ಮರುಪಡೆಯಲಾದ ಸಂದರ್ಭದ ಸಹಾಯಕ ಭಾಗಗಳನ್ನು ಗಮನ ವಿಚಲನಗೊಳಿಸುವ ಭಾಗಗಳಿಂದ ಬೇರ್ಪಡಿಸುವುದು. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಮ್ಮ ಮಾದರಿಯು ಪ್ರಶ್ನೆ ಮತ್ತು ಸಂಭಾವ್ಯ ಫಲಿತಾಂಶವನ್ನು ಸ್ವೀಕರಿಸಬೇಕು, ಮತ್ತು ಯಾವ ವ್ಯಾಪ್ತಿಗಳನ್ನು ಸಂರಕ್ಷಿಸಬೇಕು - ಪ್ರಶ್ನೆಯನ್ನು ಉತ್ತಮವಾಗಿ ಬೆಂಬಲಿಸುವವುಗಳು - ಮತ್ತು ಉಳಿದವುಗಳನ್ನು ಯಾವವುಗಳನ್ನು ಕೈಬಿಡಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬೇಕು. ಮಾದರಿಯ ಔಟ್‌ಪುಟ್ ಮೂಲ ಪಠ್ಯವನ್ನು ಮರುಬರೆಯುವ ಬದಲು ಅದನ್ನು ಸಂರಕ್ಷಿಸುತ್ತದೆ. ಇದು ಫಲಿತಾಂಶವನ್ನು ಉಲ್ಲೇಖಿಸಲು ಸುಲಭ, ಪರಿಶೀಲಿಸಲು ಸುಲಭ ಮತ್ತು ಮುಂದಿನ ಹಂತಕ್ಕೆ ರವಾನಿಸಲು ಹೆಚ್ಚು ವೆಚ್ಚ-ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ.

ಉದಾಹರಣೆಗೆ, ಈ ಪ್ರಶ್ನೆ ಮತ್ತು ಮರುಪಡೆಯಲಾದ ಫಲಿತಾಂಶವನ್ನು ಪರಿಗಣಿಸಿ:

ವಿಸ್ತರಿಸಿ

ಸಂಭಾವ್ಯ ಮಾದರಿಯ ಔಟ್‌ಪುಟ್ ದಪ್ಪಗಿನ ವಾಕ್ಯವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು: “In Comet, the assistant can ...”.

ಉತ್ಪಾದನಾ ಹುಡುಕಾಟ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸ್ನಿಪ್ಪೆಟ್ ಉತ್ಪಾದನೆಗಾಗಿ ಅಳವಡಿಸಲಾದ FliCo, Provence, ಮತ್ತು LooComp ನಂತಹ ಹಿಂದಿನ ಸಂದರ್ಭ-ಸಂಕೋಚನ ಕೆಲಸದಂತೆ ನಮ್ಮ ವಿಧಾನವು ಅದೇ ವಿಶಾಲವಾದ ಕಲ್ಪನೆಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಮುಖ್ಯವಾಗಿ, ನಮ್ಮ ಕಚ್ಚಾ ಮರುಪಡೆಯುವಿಕೆ ಹಂತದ ನಂತರ ಮಾದರಿಯು ನಿಖರತಾ ಹಂತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಮ್ಮ ಹಿಂದಿನ Perplexity ರಿಸರ್ಚ್ ಲೇಖನದಲ್ಲಿ ಚರ್ಚಿಸಿದಂತೆ, Introducing the Perplexity Search API, ನಾವು ಉಪ-ದಾಖಲೆ ಅಥವಾ ಸ್ನಿಪ್ಪೆಟ್ ಮಟ್ಟದಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ನಮ್ಮ ಮರುಪಡೆಯುವಿಕೆ ವ್ಯವಸ್ಥೆಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುತ್ತೇವೆ, ಇದು ಈಗಾಗಲೇ ನಿಖರತೆ ಮತ್ತು ಮರುಪಡೆಯುವಿಕೆಯನ್ನು (recall) ಸಾಕಷ್ಟು ಉತ್ತಮವಾಗಿ ಸಮತೋಲನಗೊಳಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಪ್ರಶ್ನೆ-ಜಾಗೃತಿ ಸಂದರ್ಭ ಸಂಕೋಚನ ಮಾದರಿಯನ್ನು ಪರಿಚಯಿಸುವುದರಿಂದ ನಿಖರತೆ-ಮರುಪಡೆಯುವಿಕೆ ಪ Pareto ಗಡಿಯನ್ನು ಇನ್ನಷ್ಟು ಹೊರಗೆ ತಳ್ಳುತ್ತದೆ.

ಸಂದರ್ಭ ಸಂಕೋಚನ ಮಾದರಿಯನ್ನು ನಿರ್ಮಿಸುವುದು ಮತ್ತು ತರಬೇತಿ ನೀಡುವುದು

ನಾವು ಮೂರು ಮುಖ್ಯ ಪರಿಗಣನೆಗಳನ್ನು ಗಮನದಲ್ಲಿಟ್ಟುಕೊಂಡು ನಮ್ಮ ಮಾದರಿಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೇವೆ: ಪ್ರಶ್ನೆ ಮತ್ತು ಸಂದರ್ಭದ ಜಂಟಿ ತಿಳುವಳಿಕೆ, ಸೂಕ್ಷ್ಮ-ಧಾನ್ಯದ ವಾಕ್ಯ-ಮಟ್ಟದ ಆಯ್ಕೆ, ಮತ್ತು ಅತ್ಯಂತ ಕಟ್ಟುನಿಟ್ಟಾದ ಲೇಟೆನ್ಸಿ ಬಜೆಟ್‌ನಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳುವ ದಕ್ಷತೆ.

ಮಾದರಿ ಆರ್ಕಿಟೆಕ್ಚರ್

ನಾವು ಬೆನ್ನೆಲುಬಾಗಿ (backbone) pplx-diffusion ಮಾದರಿಯನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದು pplx-embed-v1 ನ ಹಿಂದಿನ ಅದೇ ಮಾದರಿ ಕುಟುಂಬವಾಗಿದೆ, ಮತ್ತು ನಮ್ಮ ಹಿಂದಿನ ಶೈಕ್ಷಣಿಕ ಕೆಲಸವಾದ Diffusion-Pretrained Dense and Contextual Embeddings, ಮತ್ತು ನಮ್ಮ ಉತ್ಪಾದನಾ ಮಾನದಂಡಗಳು (benchmarks) ಇದು ಪ್ರಶ್ನೆ-ಸಂದರ್ಭ ಜೋಡಿಗಳಿಗೆ ಬಲವಾದ ದ್ವಿಮುಖ ಎನ್‌ಕೋಡರ್ ಎಂದು ದೃಢಪಡಿಸುತ್ತವೆ. ಈ ಮಾದರಿ ಕುಟುಂಬದ ಪ್ರಮುಖ ಗುಣಲಕ್ಷಣಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ ದ್ವಿಮುಖ ಸಂದರ್ಭ: ಮಾದರಿಯು ಏನು ಇರಿಸಿಕೊಳ್ಳಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುವ ಮೊದಲು ಪ್ರತಿಯೊಂದು ಟೋಕನ್ ಪ್ರತಿನಿಧಿತ್ವವು ಸಂಪೂರ್ಣ ಪ್ರಶ್ನೆ ಮತ್ತು ಸಂಪೂರ್ಣ ಸಂಭಾವ್ಯ ಸಂದರ್ಭವನ್ನು ಗಮನಿಸಬಹುದು.

ಈ ಆಧಾರದ ಮೇಲೆ, ಯಾವ context ಭಾಗಗಳನ್ನು ಉಳಿಸಬೇಕು ಎಂದು ಊಹಿಸುವ ಒಂದು lightweight compression head ಅನ್ನು ನಾವು ತರಬೇತಿ ಮಾಡುತ್ತೇವೆ. ಇಲ್ಲಿ generation ಯಾವುದೇ ಒಳಗೊಳ್ಳದಿರುವುದರಿಂದ, ಈ ಊಹೆಗಳು ಸಂಪೂರ್ಣ context ಅಡ್ಡಲಾಗಿ ಸಮಾಂತರವಾಗಿ ಮಾಡಲ್ಪಡುತ್ತವೆ. ಸೇವೆ ನೀಡುವ ಸಮಯದಲ್ಲಿ, snippet engine ಈ ಊಹೆಗಳನ್ನು ವಾಕ್ಯ ಮಟ್ಟದಲ್ಲಿ ಒಟ್ಟುಗೂಡಿಸಿ, threshold ಅನ್ವಯಿಸಿ, ಫಲಿತಾಂಶವನ್ನು ವಿನಂತಿಸಿದ token budget‌ಗೆ ಹೊಂದಿಕೊಳ್ಳುವಂತೆ ಕಡಿತಗೊಳಿಸುತ್ತದೆ.

ಮೇಲ್ವಿಚಾರಣಾ ಪೈಪ್‌ಲೈನ್

ಈ compressor ಅನ್ನು ತರಬೇತಿಗೊಳಿಸಲು ಸರಿಯಾದ granularity ಮಟ್ಟದಲ್ಲಿ supervision ಅಗತ್ಯವಿದೆ. ದಸ್ತಾವೇಜು-ಮಟ್ಟದ relevance label ನಮ್ಮ extractive compression ಕಾರ್ಯಕ್ಕೆ ಸ್ಪಷ್ಟವಾಗಿ ಸೂಕ್ತವಲ್ಲ. supervised learningಗಾಗಿ ಸಾಕಷ್ಟು ಸೂಕ್ಷ್ಮವಾದ ಡೇಟಾವನ್ನು ಸೃಷ್ಟಿಸಲು, ನಾವು queryಗೆ ಸಂಬಂಧಿಸಿದ evidence spanಗಳನ್ನು ಗುರುತಿಸುವ ಮತ್ತು ಜೊತೆಗೆ ತೆಗೆದುಹಾಕಬೇಕಾದ distractor spanಗಳನ್ನು ಗುರುತಿಸುವ span labeling pipeline ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ.

ನಮ್ಮ ಪೈಪ್‌ಲೈನ್ LLM-as-a-judge ಸೆಟಪ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆ ಮತ್ತು ಅದರ ಲಿಂಕ್, ಶೀರ್ಷಿಕೆ ಮತ್ತು ಸಾರಾಂಶದೊಂದಿಗೆ ಸಂಭಾವ್ಯ ವೆಬ್ ಪುಟವನ್ನು ನೀಡಿದರೆ, ನ್ಯಾಯಾಧೀಶರು ಮೊದಲು ಪ್ರಶ್ನೆಯನ್ನು ವಿಶ್ಲೇಷಿಸುವ ಮತ್ತು ಸಂಭಾವ್ಯ ಬಳಕೆದಾರರ ಉದ್ದೇಶಗಳ ಪಟ್ಟಿಯನ್ನು ಉತ್ಪಾದಿಸುವ ಮೂಲಕ ಪ್ರಶ್ನೆ ತಿಳುವಳಿಕೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತಾರೆ. ಈ ಉದ್ದೇಶಗಳ ಮೇಲೆ ಆಧಾರವಾಗಿಟ್ಟುಕೊಂಡು, ನ್ಯಾಯಾಧೀಶರು ನಂತರ ಸಂಭಾವ್ಯ ಸಂದರ್ಭವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಾರೆ ಮತ್ತು ಲೇಬಲ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಸುಲಭವಾಗುವಂತೆ ಪ್ರತಿ ವ್ಯಾಪ್ತಿಗೆ ಒಂದು ವರ್ಗದೊಂದಿಗೆ ಪಠ್ಯದಿಂದ ಅಕ್ಷರಶಃ ನಕಲಿಸಲಾದ ವ್ಯಾಪ್ತಿಗಳನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತಾರೆ.

ನಂತರ ನಾವು ಹಿಂದಿರುಗಿದ ವ್ಯಾಪ್ತಿಗಳನ್ನು ಮೂಲ ಪಠ್ಯಕ್ಕೆಹೊಂದಾಣಿಕೆ ಮಾಡಿದ್ದೇವೆ. ಆಶ್ಚರ್ಯಕರವಾಗಿ, ಹೆಚ್ಚಿನ ನ್ಯಾಯಾಧೀಶರ ಔಟ್‌ಪುಟ್‌ಗಳು ಈಗಾಗಲೇ ನಿಖರವಾದ ನಕಲುಗಳಾಗಿವೆ: ಸರಳವಾದ ಸ್ಟ್ರಿಂಗ್ ಹೊಂದಾಣಿಕೆಯು 98% ವ್ಯಾಪ್ತಿಗಳನ್ನು ಮರುಪಡೆಯಿತು. ಸರಳವಾದ ರೆಜೆಕ್ಸ್-ಆಧಾರಿತ ಹೊಂದಾಣಿಕೆಯ ಹ passagem ಅನ್ನು ಸೇರಿಸುವುದರಿಂದ ವ್ಯಾಪ್ತಿ ಮರುಪಡೆಯುವಿಕೆ 100% ತಲುಪಿತು. ಇದು ನಮಗೆ ವಿಶ್ವಾಸಾರ್ಹ, ಗ್ರ್ಯಾನುಲರ್ ವ್ಯಾಪ್ತಿಗಳನ್ನು ನೀಡಿತು, ಅದನ್ನು ಟೋಕನ್-ಮಟ್ಟದ ಇರಿಸಿಕೊಳ್ಳಿ/ಕೈಬಿಡಿ ಮೇಲ್ವಿಚಾರಣೆಯಾಗಿ ಪರಿವರ್ತಿಸಬಹುದು.

ಕೈಯಾರೆ ಲೇಬಲ್ ಮಾಡಲಾದ spanಗಳನ್ನು ಹೊಂದಿರುವ ಸಣ್ಣ curated dataset ಅನ್ನು ಬಳಸಿ ನಾವು ಈ supervision pipeline ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದೆವು, ಚಿಕ್ಕ judge models, ವಿಭಿನ್ನ prompts, ಹಾಗೂ ವಿಭಿನ್ನ step configurations ಗಳನ್ನು ಹೋಲಿಸಿ. ಅತ್ಯುತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದ ವ್ಯವಸ್ಥೆ ಎರಡು ಹಂತಗಳ pipeline ಆಗಿತ್ತು: ಮೊದಲು query understanding, ನಂತರ categorized span labeling. ಜೊತೆಗೆ, BrowseComp ಮತ್ತು SimpleQA ಮುಂತಾದ downstream verifiable evaluations ಮೂಲಕ ಹೊರತೆಗೆದ spanಗಳ ಸಮೂಹವನ್ನು ನಾವು ಮಾನ್ಯಗೊಳಿಸಿದ್ದೇವೆ; ಅಲ್ಲಿ ಉಳಿಸಲಾದ evidence spanಗಳನ್ನು ಮಾತ್ರ ಬಳಸುವುದರಿಂದ ಬಲವಾದ ಅಂಕಗಳನ್ನು ಕಾಯ್ದುಕೊಂಡು, input tokenಗಳನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡಲಾಯಿತು.

ಈ ಪೈಪ್‌ಲೈನ್ ಬಳಸಿ, ನಾವು 750k ಪ್ರಶ್ನೆ-ದಾಖಲೆ ಜೋಡಿಗಳನ್ನು ಲೇಬಲ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಬೈನರಿ ಕ್ರಾಸ್-ಎಂಟ್ರಪಿಯೊಂದಿಗೆ ಸಂಕೋಚನ ಹೆಡ್‌ಗೆ ತರಬೇತಿ ನೀಡಲು ಫಲಿತಾಂಶದ ವ್ಯಾಪ್ತಿಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ಈ ಪ್ರಕ್ರಿಯೆಯು ನಮ್ಮ ಪ್ರಶ್ನೆ-ಜಾಗೃತಿ ಸಂಕೋಚನ ಮಾದರಿಗೆ ಮೂಲ ಪಠ್ಯವನ್ನು ಹಾಗೆಯೇ ಇರಿಸಿಕೊಳ್ಳಲು ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ಮುಂದಿನ ಹಂತದ ಮಾದರಿಯು ಬಳಕೆದಾರರ ವಿನಂತಿಯನ್ನು ಪೂರೈಸಲು ಸಹಾಯ ಮಾಡುವ ಸಾಧ್ಯತೆಯಿಲ್ಲದ ಸಂದರ್ಭವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

ರಿಯಲ್‌ಟೈಮ್ ಲೇಟೆನ್ಸಿಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು

ಸಂದರ್ಭ ಸಂಕೋಚನವು ಮುಂದಿನ ಹಂತದ ಮಾದರಿಯ ಮೊದಲು ಕುಳಿತುಕೊಳ್ಳುತ್ತದೆ, ಇದು ಬ್ಲಾಕಿಂಗ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನಾಗಿ ಮಾಡುತ್ತದೆ. ಮೇಲಾಗಿ, ಪ್ರತಿ ಸಂಕೋಚನವು ಪ್ರಶ್ನೆ-ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ, ಆನ್‌ಲೈನ್ ಮಾರ್ಗವು ನಿಖರವಾದ ಲೇಟೆನ್ಸಿ ಲಕೋಟೆಯೊಳಗೆ ಪ್ರತಿ ಸಂಭಾವ್ಯ ದಾಖಲೆಗೆ ಪ್ರಶ್ನೆ-ಸಂದರ್ಭ ಜೋಡಿಗಳನ್ನು ಸ್ಕೋರ್ ಮಾಡಬೇಕು. ನಿಧಾನವಾದ ಸಂಕೋಚನ ಮಾದರಿಯು ಸ್ವಯಂ-ಪರಾಜಯಗೊಳ್ಳುತ್ತದೆ, ಏಕೆಂದರೆ ಹೆಚ್ಚಿನ ನಿಖರತೆಯಿಂದ ಬರುವ ಲೇಟೆನ್ಸಿ ಪ್ರಯೋಜನಗಳನ್ನು ಸಂಕೋಚನ ಲೇಟೆನ್ಸಿಯಿಂದಲೇ ಅಳಿಸಿಹಾಕಲಾಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಕಡಿಮೆ ಬುದ್ಧಿವಂತ ಸಂಕೋಚನ ಮಾದರಿಯು ಏನು ಕತ್ತರಿಸಬೇಕು ಮತ್ತು ಉಳಿಸಿಕೊಳ್ಳಬೇಕು ಎಂಬುದರ ಕುರಿತು ಕಳಪೆ ನಿರ್ಧಾರಗಳನ್ನು ಮಾಡುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕ ಪ್ರಶ್ನೆಯೆಂದರೆ ಸಂಕೋಚನ ಗುಣಮಟ್ಟವು ಕ್ಷೀಣಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ನಾವು ಎಷ್ಟು ಮಾದರಿ ಸಾಮರ್ಥ್ಯವನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ತೆಗೆದುಹಾಕಬಹುದು. ನಾವು ಸಂಪೂರ್ಣ 28-ಪದರದ pplx-diffusion ಬೆನ್ನೆಲುಬನ್ನು ಲೇಯರ್ ಸಮತಟ್ಟುಗೊಳಿಸುವಿಕೆಯಿಂದ (layer pruning) ಉತ್ಪತ್ತಿಯಾದ 11-ಪದರ ಮತ್ತು 17-ಪದರದ ರೂಪಾಂತರಗಳಿಗೆ ವಿರುದ್ಧವಾಗಿ ಹೋಲಿಸುತ್ತೇವೆ ಮತ್ತು ಹುಡುಕಾಟ ಮಾರ್ಗವನ್ನು ಗುರಿಯಾಗಿರಿಸಿಕೊಳ್ಳುತ್ತೇವೆ. ಪ್ರತಿಯೊಂದಕ್ಕೂ, ನಾವು ಸಂಕೋಚನ ಮಿತಿಯ ಮೇಲೆ ಸ್ವೀಪ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಎರಡು ಪ್ರಮಾಣಗಳನ್ನು ಅಳೆಯುತ್ತೇವೆ: ಪ್ರತಿ ಪ್ರಶ್ನೆಗೆ ಕೆಳಹಂತಕ್ಕೆ ಕಳುಹಿಸಲಾದ ಸಂದರ್ಭ ಟೋಕನ್‌ಗಳ ಸರಾಸರಿ ಸಂಖ್ಯೆ, ಮತ್ತು ಸಂಕೋಚನದ ನಂತರ ಸಂರಕ್ಷಿಸಲ್ಪಟ್ಟ ಉಪಯುಕ್ತ ಸಾಕ್ಷ್ಯದ ಭಾಗ.

ಚಿತ್ರ 2 ಗುಣಮಟ್ಟ-ದಕ್ಷತೆ ಗಡಿಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಮಾದರಿಯು ಮೇಲಿನ ಎಡಭಾಗಕ್ಕೆ ಚಲಿಸಿದಾಗ ಉತ್ತಮವಾಗಿರುತ್ತದೆ: ಹೆಚ್ಚು ಉಪಯುಕ್ತ ಸಾಕ್ಷ್ಯದೊಂದಿಗೆ ಕಡಿಮೆ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಟೋಕನ್‌ಗಳು ಸಂರಕ್ಷಿಸಲ್ಪಟ್ಟಿರುತ್ತವೆ. 28-ಪದರದ ಮಾದರಿಯು ಗುಣಮಟ್ಟದ ಉಲ್ಲೇಖವನ್ನು ಒದಗಿಸುತ್ತದೆ. 11-ಪದರದ ಮಾದರಿಯು ಮಾದರಿಯನ್ನು ಹೆಚ್ಚು ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸುವ ಅಪಾಯಗಳನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ. ಕತ್ತರಿಸಿದ 17-ಪದರದ ಮಾದರಿಯು ಮಧ್ಯಮ ನೆಲವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ: ಇದು ಸ್ಯಾಚುರೇಟೆಡ್ ಆಡಳಿತದಲ್ಲಿ 28-ಪದರದ ಮಾದರಿಯನ್ನು ನಿಕಟವಾಗಿ ಅನುಸರಿಸುತ್ತದೆ, ಆದರೆ ಹೆಚ್ಚಿನ ಉತ್ಪಾದನಾ ದಟ್ಟಣೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ವಕ್ರತೆಯ ಕಡಿದಾದ ಭಾಗದಲ್ಲಿ ಸಣ್ಣ ಅಂತರವು ತೆರೆಯುತ್ತದೆ.

ಆ ಅಂತರವನ್ನು ಮುಚ್ಚಲು, ನಾವು ಟೋಕನ್-ಮಟ್ಟದ ಜ್ಞಾನ ಬ distillation (knowledge distillation) ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ನಮ್ಮ ವಿಧಾನವು ದಿನನಿತ್ಯದ್ದಾಗಿದೆ: ಡಿಸ್ಟಿಲೇಷನ್ ಗುಣಾಂಕದಿಂದ ತೂಕವಿರುವ ಶಿಕ್ಷಕ ಮಾದರಿಯ ಮುನ್ಸೂಚನೆಗಳ ಮೇಲೆ ಸಾಫ್ಟ್ ಕ್ರಾಸ್-ಎಂಟ್ರಪಿ ಪದದೊಂದಿಗೆ ನಾವು ಪ್ರಮಾಣಿತ ನಷ್ಟವನ್ನು ವರ್ಧಿಸುತ್ತೇವೆ. ವಿದ್ಯಾರ್ಥಿ ಮಾದರಿಯನ್ನು ಸಮಾನತೆಗೆ ತರಲು ಇದು ಸಾಕಾಗುತ್ತದೆ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಡಿಸ್ಟಿಲ್ ಮಾಡಿದ 17-ಪದರದ ಮಾದರಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈ ಹೊಸ ಉತ್ಪಾದನಾ ಮಾದರಿಯು 28-ಪದರದ ಶಿಕ್ಷಕರಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಗುಣಮಟ್ಟದ ಇಳಿಕೆ ಇಲ್ಲದೆ ಅನುಮಾನ ಲೇಟೆನ್ಸಿಯಲ್ಲಿ 35-40% ಇಳಿಕೆಯನ್ನು ಮತ್ತು ಒಟ್ಟು GPU ಕಂಪ್ಯೂಟ್‌ನಲ್ಲಿ 40-45% ಇಳಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ. ಉತ್ಪಾದನಾ ಲೇಟೆನ್ಸಿಯು 20 ms ಗಿಂತ ಕಡಿಮೆ (p99) ಗಡಿಯಾರ ಮಾಡುತ್ತದೆ: ಉತ್ತರ ಮಾದರಿಗೆ ರವಾನಿಸಲಾದ ಒಟ್ಟು ಟೋಕನ್‌ಗಳನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುವಾಗ ಸೇವಾ ಮಾರ್ಗಕ್ಕೆ ಸೇರಿಸಲು ಸಾಕಷ್ಟು ಚಿಕ್ಕದಾಗಿದೆ.

ವಿಸ್ತರಿಸಿ

ಗುಣಮಟ್ಟ ಮತ್ತು ಟೋಕನ್ ದಕ್ಷತೆ

ಸಂದರ್ಭ ಸಂಕೋಚನದ ಪರಿಣಾಮಕಾರಿತ್ವವನ್ನು ವಿಶ್ಲೇಷಿಸಲು ನಾವು Perplexity ನ Agent API ಅನ್ನು ಟೆಸ್ಟ್‌ಬೆಡ್ ಆಗಿ ಬಳಸುತ್ತೇವೆ. ನಾವು ಮೂರು Agent API ಪೂರ್ವನಿಗದಿಗಳನ್ನು (presets) ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ:

ಪ್ರತಿ ಫಲಿತಾಂಶ ಸೆಟ್‌ಗೆ ಟೋಕನ್ ಬಜೆಟ್ ಅನ್ನು 1000 ಟೋಕನ್‌ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸುವ “ಕಡಿಮೆ” (low) ಸಂದರ್ಭ ಪೂರ್ವನಿಗದಿ.

ಪ್ರತಿ ಫಲಿತಾಂಶ ಸೆಟ್‌ಗೆ ಟೋಕನ್ ಬಜೆಟ್ ಅನ್ನು 4000 ಟೋಕನ್‌ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸುವ “ಮಧ್ಯಮ” (medium) ಸಂದರ್ಭ ಪೂರ್ವನಿಗದಿ.

ಪ್ರತಿ ಫಲಿತಾಂಶ ಸೆಟ್‌ಗೆ ಟೋಕನ್ ಬಜೆಟ್ ಅನ್ನು 10000 ಟೋಕನ್‌ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸುವ “ಹೆಚ್ಚಿನ” (high) ಸಂದರ್ಭ ಪೂರ್ವನಿಗದಿ.

ಪ್ರಮಾಣಿತ, ಸಂಕೋಚನ-ರಹಿತ ಮತ್ತು ಸಂಕೋಚನ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಈ ಟೋಕನ್ ಬಜೆಟ್‌ಗಳನ್ನು ಗೌರವಿಸಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ.

ಏಜೆಂಟಿಕ್ ಬಹು-ಹಂತದ ಹುಡುಕಾಟ (BrowseComp)

BrowseComp ಮಾನದಂಡದಲ್ಲಿ ಏಜೆಂಟಿಕ್ ಬಹು-ಹಂತದ ಹುಡುಕಾಟ ಕಾರ್ಯಪ್ರವಾಹಗಳ ಮೇಲೆ ಸಂಕೋಚನದ ಪ್ರಭಾವವನ್ನು ನಾವು ಮೊದಲು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ನಮ್ಮ ಓಪನ್-ಸೋರ್ಸ್ search_evals ಹಾರ್ನೆಸ್ ಬಳಸಿ ನಾವು ಈ ಮೌಲ್ಯಮಾಪನವನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ. OpenAI ನ ಕ್ಯಾನೋನಿಕಲ್ BrowseComp LLM judge prompt ಬಳಸಿ ಎಲ್ಲಾ ರನ್‌ಗಳಾದ್ಯಂತ ಗ್ರೇಡಿಂಗ್ ಒಂದೇ ಆಗಿರುತ್ತದೆ.

ಆಸಕ್ತಿಯ ಎರಡು ಆಯಾಮಗಳು benchmark accuracy ಮತ್ತು token usage. ಮುಖ್ಯವಾಗಿ, ನಿಜವಾಗಿ request lifecycle ಅಡ್ಡಲಾಗಿ ಉಂಟಾಗುವ token load ಅನ್ನು ಅಳೆಯಲು, ನಾವು token usage ಅನ್ನು individual step ಮಟ್ಟದಲ್ಲ değil, query ಮಟ್ಟದಲ್ಲಿ ಅಳೆಯುತ್ತೇವೆ. Figure 3 “score-token” frontier ಅನ್ನು ತೋರಿಸುತ್ತದೆ, accuracy score ವಿರುದ್ಧ token usage.

ವಿಸ್ತರಿಸಿ

ಸಂಕೋಚನವು ಬೋರ್ಡ್ জুড়ে ಹೊಸ Pareto ಗಡಿಯನ್ನು ತಲುಪಿಸುತ್ತದೆ. ಪ್ರತಿ ಸೆಟ್ಟಿಂಗ್‌ಗೆ, ಸಂಕೋಚನವನ್ನು ಪರಿಚಯಿಸುವುದರಿಂದ ಪ್ರಶ್ನೆ-ಮಟ್ಟದ ಟೋಕನ್ ಬಳಕೆಯು ಎಲ್ಲಿಯಾದರೂ 10% ರಿಂದ 70% ರಷ್ಟು ಕಡಿಮೆಯಾಗುತ್ತದೆ, ನಿಖರತೆಯ ಲಾಭಗಳು 4 ಮತ್ತು 4.81 ಶೇಕಡಾವಾರು ಅಂಕಗಳ ನಡುವೆ ಗಡಿಯಾರ ಮಾಡುತ್ತವೆ. ಸಂಕೋಚನವನ್ನು ಪರಿಚಯಿಸುವುದರಿಂದ ನಮ್ಮ “ಕಡಿಮೆ” ಪೂರ್ವನಿಗದಿಯು ಸಂಕೋಚನ-ರಹಿತ “ಹೆಚ್ಚಿನ” ಪೂರ್ವನಿಗಿಯನ್ನು ಮೀರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಅದೇ ಸಮಯದಲ್ಲಿ ಟೋಕನ್ ಬಳಕೆಯನ್ನು ಮೂರು ಪಟ್ಟು ಹೆಚ್ಚು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಸಂಕೋಚನದೊಂದಿಗೆ, ನಾವು ನಿರೀಕ್ಷಿಸಿದಂತೆ “ಹೆಚ್ಚಿನ” “ಮಧ್ಯಮ” ಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ನಿಖರತೆಯನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ನಾವು ಗಮನಿಸುತ್ತೇವೆ. ಆಸಕ್ತಿದಾಯಕವಾಗಿ, ಆದಾಗ್ಯೂ, ಇದು ಕಡಿಮೆ ಟೋಕನ್ ಬಳಕೆಯಲ್ಲಿ ಹಾಗೆ ಮಾಡುತ್ತದೆ. ಇದು ಸಂಕೋಚನದ ಸೂಕ್ಷ್ಮವಾದ ಆದರೆ ಪ್ರಮುಖ ಪರಿಣಾಮವನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ: ಸಂಕೋಚನದೊಂದಿಗೆ, ಪ್ರತಿ ಹಂತದ ಸಂದರ್ಭದ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸುವುದು ಸಹ ಸರಿಯಾದ ಫಲಿತಾಂಶವನ್ನು ತಲುಪಲು ಮಾದರಿಯು ಕಡಿಮೆ ಹಂತಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಈ ಏಕತಾನತೆಯಿಲ್ಲದ (non-monotonicity) ಅನ್ವೇಷಣೆಯು ಭವಿಷ್ಯದ ಕೆಲಸಕ್ಕೆ ಭರವಸೆಯ ದಿಕ್ಕಾಗಿದೆ.

SimpleQA: single-step factuality

BrowseComp ಬಹು-ಹಂತದ ಸಂಶೋಧನೆಯನ್ನು ಒತ್ತಿಹೇಳುತ್ತದೆ, ಆದರೂ ಅನೇಕ ಉತ್ಪಾದನಾ ಕಾರ್ಯಪ್ರವಾಹಗಳು ಏಕ-ಹಂತದ ತಥ್ಯಾತ್ಮಕ ಲುಕ್ಅಪ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ಸಂಕೋಚನವು ಏಕ-ಹಂತದ ಆಡಳಿತದಲ್ಲೂ ಸಹಾಯ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಲು, ನಾವು SimpleQA, ಏಜೆಂಟಿಕ್ ಲೂಪ್ ಬದಲಿಗೆ ಒಂದೇ ಹುಡುಕಾಟ ಹಂತದಲ್ಲಿ ಉತ್ತರಿಸಬೇಕಾದ 4,326 ಪ್ರಶ್ನೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಮಾನದಂಡದಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ.

ಮೊದಲಿನಂತೆ, ಕ್ಯಾನೋನಿಕಲ್ ನ್ಯಾಯಾಧೀಶರ ಪ್ರಾಂಪ್ಟ್ ಬಳಸಿ ಪ್ರತಿ ಕಾರ್ಯಕ್ಕೆ ಸರಾಸರಿ ಒಟ್ಟು ಟೋಕನ್‌ಗಳ ವಿರುದ್ಧ ನಾವು ನಿಖರತೆಯನ್ನು ಪ್ಲಾಟ್ ಮಾಡುತ್ತೇವೆ. ಚಿತ್ರ 4 ಈ ಏಕ-ಹಂತದ ಸೆಟ್ಟಿಂಗ್‌ನಲ್ಲಿ ಸ್ಕೋರ್-ಟೋಕನ್ ಗಡಿಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಪರಿಣಾಮದ ಗಾತ್ರಗಳು ಏಕ-ಹಂತದ ಸೆಟ್ಟಿಂಗ್‌ನಲ್ಲಿ ಹೆಚ್ಚು ಸಂಕುಚಿತಗೊಂಡಿದ್ದರೂ, ಸಂಕೋಚನವು ಏಕಕಾಲದಲ್ಲಿ ಎಲ್ಲಾ ಪೂರ್ವನಿಗದಿಗಳಾದ್ಯಂತ ನಿಖರತೆ ಮತ್ತು ದಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ, ಹೀಗಾಗಿ ಹೊಸ Pareto ಗಡಿಯನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ ಎಂದು ನಾವು ಮತ್ತೊಮ್ಮೆ ಗಮನಿಸುತ್ತೇವೆ. ಸಂಕೋಚನವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ, ಮಧ್ಯಮ ಪೂರ್ವನಿಗದಿಯು ಪ್ರತಿ ದಾಖಲೆಗೆ ಸರಾಸರಿ ಕೇವಲ 200 ಟೋಕನ್‌ಗಳೊಂದಿಗೆ 95% ನಿಖರತೆಯನ್ನು ಸಾಧಿಸುತ್ತದೆ. 10,000 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಟೋಕನ್‌ಗಳ ಸರಾಸರಿ ದಾಖಲೆ ಉದ್ದವನ್ನು ನೀಡಿದರೆ, ಇದು 50 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಂಕೋಚನ ಅನುಪಾತದಲ್ಲಿ ಗಡಿ-ಮಟ್ಟದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ಸ್ನಿಪ್ಪೆಂಟ್‌ಗಳಲ್ಲಿ ಏನಾಗುತ್ತದೆ?

ವಿಭಾಗಗಳು 4.1 ಮತ್ತು 4.2 ರಲ್ಲಿನ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಲಾಭಗಳು ಎಂಡ್-ಟು-ಎಂಡ್ ಆಗಿವೆ. ಸಂಕೋಚನವು ವೈಯಕ್ತಿಕ ಸ್ನಿಪ್ಪೆಂಟ್‌ಗಳನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಮರುಪಡೆಯಲಾದ ಪ್ರತಿಯೊಂದು ಸ್ನಿಪ್ಪೆಂಟ್‌ನ ಪ್ರತಿಯೊಂದು ಟೋಕನ್ ಅನ್ನು ಆರು ವರ್ಗಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ವರ್ಗೀಕರಿಸಲು LLM ನ್ಯಾಯಾಧೀಶರನ್ನು ಬಳಸುವ ಪ್ರತ್ಯೇಕ ಮೌಲ್ಯಮಾಪನವನ್ನು ನಾವು ನಡೆಸುತ್ತೇವೆ:

ಪ್ರಮುಖ (Vital): ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಅತ್ಯಗತ್ಯವಾದ ಸಾಕ್ಷ್ಯ.

ವಿಷಯ-ಬಾಹಿರ (Off-topic): ಕೆಲವು ಇತರ ಉದ್ದೇಶಗಳಿಗೆ ಉಪಯುಕ್ತವಾಗಬಹುದಾದ ಆದರೆ ಕೈಯಲ್ಲಿರುವ ಪ್ರಶ್ನೆಗೆ ಸಂಬಂಧಿಸದ ಮಾಹಿತಿ.

ಜಾಹೀರಾತುಗಳು (Ads): ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವುದರಿಂದ ಗಮನ ಸೆಳೆಯುವ ಅಪ್ರಸ್ತುತ ಜಾಹೀರಾತು.

ಮೆಟಾಡೇಟಾ (Metadata): ದಾಖಲೆಯ ವಿಷಯಗಳ ಕುರಿತು ಮೆಟಾಡೇಟಾ.

UI ಮತ್ತು ನ್ಯಾವಿಗೇಷನ್ (UI & navigation): ಮುಂಭಾಗದ ಪ್ರದರ್ಶನ ಮತ್ತು ನ್ಯಾವಿಗೇಷನ್‌ಗಾಗಿ ಅಂಶಗಳು.

ನಕಲು (Duplicate): ಮೊದಲು ಸೇರಿಸಲಾದ ಮಾಹಿತಿಯ ಪುನರಾವರ್ತನೆ.

ನಮ್ಮ ಮೌಲ್ಯಮಾಪನವು ನಮ್ಮ ಮೌಲ್ಯಮಾಪನ ಸೆಟ್‌ನಿಂದ 1,000 ಮಿಶ್ರ-ಡೊಮೇನ್ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ಚಲಿಸುತ್ತದೆ, ಸಂಕೋಚನವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ ಒಂದೇ ರೀತಿಯ ಬೇಸ್‌ಲೈನ್‌ಗೆ ಉತ್ಪಾದನಾ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಹೋಲಿಸುತ್ತದೆ. ಚಿತ್ರ 5 ರಲ್ಲಿ ತೋರಿಸಿರುವಂತೆ, ಸಂಕೋಚನವು ಸಂಕೋಚನ-ರಹಿತ ಬೇಸ್‌ಲೈನ್‌ಗಿಂತ ಪ್ರತಿ ಸ್ನಿಪ್ಪೆಂಟ್‌ಗೆ ಪ್ರಮುಖ ಟೋಕನ್‌ಗಳ ಅನುಪಾತವನ್ನು ಸರಾಸರಿ 63% ರಷ್ಟು ಹೆಚ್ಚಿಸುತ್ತದೆ. UI/ನ್ಯಾವಿಗೇಷನ್ (-58%), ಮೆಟಾಡೇಟಾ (-46%), ಮತ್ತು ಜಾಹೀರಾತುಗಳು (-43%) ಗಳಲ್ಲಿ ವಿಶೇಷವಾಗಿ ಕಡಿದಾದ ಕುಸಿತಗಳೊಂದಿಗೆ, ಅಪ್ರಸ್ತುತ ಟೋಕನ್‌ಗಳಲ್ಲಿ 29% ರಷ್ಟು ಅನುಗುಣವಾದ ಇಳಿಕೆಯನ್ನು ನಾವು ಗಮನಿಸುತ್ತೇವೆ. ಈ ಫಲಿತಾಂಶಗಳು ಮೇಲೆ ಚರ್ಚಿಸಿದ ಗುಣಮಟ್ಟ-ದಕ್ಷತೆಯ ಸುಧಾರಣೆಗಳಿಗೆ ಕಾರ್ಯವಿಧಾನವನ್ನು ದೃಢಪಡಿಸುತ್ತವೆ: ಪ್ರತಿ ಪ್ರತ್ಯೇಕ ಸ್ನಿಪ್ಪೆಂಟ್‌ನ ಸಿಗ್ನಲ್-ಟು-ನಾಯ್ಸ್ ಅನುಪಾತವನ್ನು ತೀವ್ರವಾಗಿ ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ಸಂಕೋಚನವು ಎರಡೂ ಆಯಾಮಗಳಾದ್ಯಂತ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ಚಿತ್ರ 6 ವೈಯಕ್ತಿಕ ಪ್ರಶ್ನೆಗೆ ಈ ಬದಲಾವಣೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. “6 day old newborn milk intake per feeding,” ಪ್ರಶ್ನೆಗಾಗಿ, ನಾವು ಸಂಕುಚಿತಗೊಳಿಸದ, ಬೇಸ್‌ಲೈನ್ ಮತ್ತು ಸಂಕುಚಿತ ಸ್ನಿಪ್ಪೆಂಟ್‌ಗಳನ್ನು ತೋರಿಸುತ್ತೇವೆ. ಸಂಕೋಚನವು ಅಪ್ರಮುಖ ವಿಷಯ ವರ್ಗಗಳನ್ನು ನಿವಾರಿಸುತ್ತದೆ ಮತ್ತು ನವಜಾತ ಶಿಶು-ಸಂಬಂಧಿತ ಆಹಾರ ಮಾಹಿತಿಯನ್ನು ಮಾತ್ರ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಮುಖ್ಯವಾಗಿ, ಸಂಕೋಚನವು ಪುಟಕ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ವಿಷಯ-ಬಾಹಿರವಾಗಿರಬಹುದಾದ ಆದರೆ ಈ ನಿರ್ದಿಷ್ಟ ನವಜಾತ-ಕೇಂದ್ರಿತ ಪ್ರಶ್ನೆಗೆ ವಿಷಯ-ಬಾಹಿರವಾಗಿರುವ ವಿಷಯವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ನಿವಾರಿಸುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ತೀರ್ಮಾನ

AI ವ್ಯವಸ್ಥೆಗಳು ಬಳಕೆದಾರರ ವಿನಂತಿಗಳಿಗೆ ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ಮತ್ತು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸೇವೆ ಸಲ್ಲಿಸಲು ಹೆಚ್ಚಿನ-ಸಿಗ್ನಲ್ ಮಾಹಿತಿಯನ್ನು ಅವಲಂಬಿಸಿವೆ. ಪ್ರತಿ ವಿನಂತಿಗೆ ಪ್ರಸ್ತುತತೆಯನ್ನು ಗರಿಷ್ಠಗೊಳಿಸಲು ಈ ಮಾಹಿತಿಯನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಶಸ್ತ್ರಚಿಕಿತ್ಸೆಯಂತೆ ಪ್ರಸ್ತುತಪಡಿಸಬೇಕು. ನಮ್ಮ ಹೊಸ ಪ್ರಶ್ನೆ-ಜಾಗೃತಿ ಸಂಕೋಚನ ಮಾದರಿಗಳು ಪ್ರತಿ ಸ್ನಿಪ್ಪೆಂಟ್‌ಗೆ ಆನ್-ಟೋಪಿಕ್ ಸಾಕ್ಷ್ಯವನ್ನು ಗರಿಷ್ಠಗೊಳಿಸುವ ಮೂಲಕ ಮತ್ತು ಅಪ್ರಸ್ತುತ ಗೊಂದಲಗಳನ್ನು ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ನಿವಾರಿಸುವ ಮೂಲಕ ನಿಖರವಾಗಿ ಇದನ್ನು ಮಾಡುತ್ತವೆ.

ನಮ್ಮ ಹುಡುಕಾಟ ಸ್ಟ್ಯಾಕ್ ಒಳಗೆ ಈ ಹೊಸ ಮಾದರಿಗಳನ್ನು ನಿಯೋಜಿಸುವ ಮೂಲಕ, ನಮ್ಮ ಉತ್ಪನ್ನಗಳು ಮತ್ತು API ಗಳನ್ನು ಅವಲಂಬಿಸಿರುವವರಿಗೆ ವೇಗವಾದ ಮತ್ತು ಉತ್ತಮ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಒದಗಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಗುತ್ತದೆ. ನಮ್ಮ ವಿಧಾನವು ಸರಳವಾದ ನಿಯಂತ್ರಣ ಮೇಲ್ಮೈಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಮರುಪಡೆಯುವಿಕೆ, ಲೇಟೆನ್ಸಿ ಮತ್ತು ವೆಚ್ಚದ ನಡುವೆ ಸಮತೋಲನಗೊಳಿಸಲು ಸಂಕೋಚನದ ಮಟ್ಟವನ್ನು ಟ್ಯೂನ್ ಮಾಡಲು ನಮ್ಮ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು API ಗ್ರಾಹಕರಿಗೆ ಅನುಮತಿಸುತ್ತದೆ.

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

ಉಲ್ಲೇಖಗಳು

N. Chirkova, T. Formal, V. Nikoulina, and S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Accepted to ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, and D. Kim. LooComp: Leverage Leave-One-Out Strategy to Encoder-only Transformer for Efficient Query-Aware Context Compression, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang, and D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez, and G. Neubig. Learning to Filter Context for Retrieval-Augmented Generation, 2023. arXiv:2311.08377.

ಉಲ್ಲೇಖ

@online{perplexity2026QueryAwareContextCompressionForBetterSnippets,
  author = {{Perplexity} and Bo Wang and Hao Zhang and Ismail Gadzhiev and Kirill Priemko and Markus Krimmel and Nandor Licker and Vitalii Polshkov and Sarah Eslami and Louis Milliken and Maksim Gaiduk and Nikita Kireev and Jerry Ma},
  title = {{Query-aware context compression for better snippets}},
  date = {2026-05-14},
  url = {https://www.perplexity.ai/hub/blog/query-aware-context-compression-for-better-snippets}
}