ಪ್ರತಿಯೊಂದು Agent API ಪ್ರಯತ್ನ ಮಟ್ಟಕ್ಕೂ ಸುಧಾರಣೆಗಳು

Perplexity Agent API ನಲ್ಲಿನ ಪ್ರಯತ್ನ ಮಟ್ಟಗಳು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಪ್ರತಿ ಕಾರ್ಯಕ್ಕೂ ವೆಚ್ಚ, ವೇಗ ಮತ್ತು ಸಂಶೋಧನಾ ಆಳದ ಸಮತೋಲನವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತವೆ. ಇಂದು, ಪ್ರತಿಯೊಂದು ಪ್ರಯತ್ನ ಮಟ್ಟವೂ ಪ್ರತಿ ಕ್ವೆರಿಗೆ ಕಡಿಮೆ ವೆಚ್ಚವಾಗುತ್ತದೆ, ಮತ್ತು ಸಂಶೋಧನಾ ಗುಣಮಟ್ಟ ಹೆಚ್ಚಾಗಿದೆ ಅಥವಾ ಬದಲಾಗದೆ ಉಳಿದಿದೆ. ಅತ್ಯಂತ ವ್ಯಾಪಕ ಮತ್ತು ಸಮಗ್ರ ಸಂಶೋಧನೆಗಾಗಿ ಹೊಸ ultra ಮಟ್ಟ ಲಭ್ಯವಿದೆ. effort="fast", ನಂತೆ ಮಟ್ಟವನ್ನು ಹೆಸರಿನಿಂದ ಆಯ್ಕೆ ಮಾಡುವ ಯಾವುದೇ ವಿನಂತಿಯು ನವೀಕರಿಸಿದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪಡೆಯುತ್ತದೆ.

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

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

medium ಕಾರ್ಯಕ್ಷಮತೆಯು BrowseComp ಮತ್ತು DSQA ನಲ್ಲಿ 55% ರಿಂದ 77% ಕ್ಕೆ ಸುಧಾರಿಸಿತು, ಅದೇ ವೇಳೆ ವೆಚ್ಚಗಳು ಸುಮಾರು 90% ರಷ್ಟು ಕಡಿಮೆಯಾದವು. BrowseComp ಮತ್ತು DSQA ಸಾರ್ವಜನಿಕ ಸಂಶೋಧನಾ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳಾಗಿವೆ; WANDR ಎಂಬುದು ದೀರ್ಘ, ಬಹು-ಘಟಕ ಸಂಶೋಧನಾ ಕಾರ್ಯಗಳ Perplexity ಬೆಂಚ್‌ಮಾರ್ಕ್ ಆಗಿದೆ. xhigh ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಕೋಡ್ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು, ದೀರ್ಘ ಟೂಲ್-ಬಳಕೆಯ ಲೂಪ್‌ಗಳನ್ನು ಮುಂದುವರಿಸುವುದು ಮತ್ತು ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ಮೂಲಗಳಾದ್ಯಂತ ಕೆಲಸ ಮಾಡುವಂತಹ ಏಜೆಂಟಿಕ್ ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. xhigh ಆಗಸ್ಟ್ 2026ರ ಕಾನ್ಫಿಗರೇಶನ್‌ನ ವೆಚ್ಚದ ಸುಮಾರು 25% ರಷ್ಟರಲ್ಲಿ ಚಲಿಸುತ್ತಾ ತನ್ನ WANDR ಸ್ಕೋರ್ ಅನ್ನು 76.5% ನಲ್ಲಿ ಉಳಿಸಿಕೊಂಡಿತು.

ಆಳಗಿನ ಸಂಶೋಧನೆಯ ವಿನಂತಿಯೊಂದು ಉತ್ತರಿಸುವ ಮೊದಲು ಡಜನ್‌ಗಟ್ಟಲೆ ಹುಡುಕಾಟಗಳನ್ನು ನಡೆಸಬಹುದು, ನೂರಾರು ಪುಟಗಳನ್ನು ಓದಬಹುದು ಮತ್ತು ಸಾಕ್ಷ್ಯವನ್ನು ಪರಿಶೀಲಿಸಬಹುದು. ಆ ಪ್ರತಿಯೊಂದು ಕ್ರಿಯೆಯೂ ಕಾಂಟೆಕ್ಸ್ಟ್‌ಗೆ ಟೋಕನ್‌ಗಳನ್ನು ಮತ್ತು ಬಿಲ್‌ಗೆ ಡಾಲರ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. ಮಿತಿಗಳಿಲ್ಲದಿದ್ದರೆ, ಏಜೆಂಟ್ ಉತ್ತರವನ್ನು ಸುಧಾರಿಸದೆಯೇ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುವ ಮತ್ತು ಕಾಂಟೆಕ್ಸ್ಟ್ ಅನ್ನು ತುಂಬುವ ಕ್ರಿಯೆಗಳನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಆ ವೆಚ್ಚದ ಬಹುಪಾಲನ್ನು ಐದು ಅಂಶಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ:

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

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

ಪ್ರತಿಯೊಂದು ಪ್ರಯತ್ನ ಮಟ್ಟವು ಮೂರು ಘಟಕಗಳನ್ನು ಹೊಂದಿರುವ ನಿಗದಿತ ಸಂಶೋಧನಾ ಬಜೆಟ್ ಅನ್ನು ಹೊಂದಿದೆ:

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

ಬಜೆಟ್ ಕೇಂದ್ರ ವಿನಿಮಯವಾಗಿದೆ: ಹೆಚ್ಚು ಹಂತಗಳು ಎಂದರೆ ಉತ್ತಮ ಉತ್ತರಗಳು, ಮತ್ತು ಪ್ರತಿ ಹಂತಕ್ಕೂ ವೆಚ್ಚ ತಗಲುತ್ತದೆ. openai/gpt-6-luna ನೊಂದಿಗೆ, ಹಂತದ ಮಿತಿಯನ್ನು 1 ರಿಂದ 15 ಕ್ಕೆ ಹೆಚ್ಚಿಸಿದಾಗ BrowseComp + DSQA ನಲ್ಲಿ ನಿಖರತೆ 41% ರಿಂದ 80% ಕ್ಕೆ ಏರುತ್ತದೆ, ಅದೇ ವೇಳೆ ಪ್ರತಿ ಕ್ವೆರಿಯ ವೆಚ್ಚ $0.0017 ರಿಂದ $0.0152 ಕ್ಕೆ ಏರುತ್ತದೆ, ಅಂದರೆ ಸುಮಾರು 2x ಸ್ಕೋರ್‌ಗಾಗಿ ಸುಮಾರು 9x ವೆಚ್ಚ.

ಕೇವಲ ಹಂತದ ಮಿತಿಯು ಸಂಶೋಧನಾ ವೆಚ್ಚವನ್ನು ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲ. ಅದೇ ಐದು-ಹಂತದ ಬಜೆಟ್‌ನಲ್ಲಿ, openai/gpt-6.1-terra ಮಾಡೆಲ್ openai/gpt-6-luna ಗಿಂತ ಹೆಚ್ಚು ಟೂಲ್ ಕರೆಗಳನ್ನು ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಹೆಚ್ಚು ಸಾಮರ್ಥ್ಯವುಳ್ಳ ಮಾಡೆಲ್‌ಗಳು ಒಂದೇ ಹಂತದಲ್ಲಿ ಹಲವಾರು ಕರೆಗಳನ್ನು ಮಾಡುವ ಪ್ರವೃತ್ತಿ ಹೊಂದಿವೆ. ಪ್ರಯತ್ನ ಮಟ್ಟಗಳು ಟೂಲ್ ಕರೆಗಳು ಮತ್ತು ಹಂತಗಳು ಎರಡಕ್ಕೂ ಮಿತಿ ವಿಧಿಸುತ್ತವೆ. ಈ ಮಾಡೆಲ್‌ಗಳಿಗೆ, ಟೂಲ್-ಕರೆ ಮಿತಿಯು ಹಂತದ ಮಿತಿಯಷ್ಟೇ ಮುಖ್ಯವಾಗಿದೆ.

ಪ್ರತಿಯೊಂದು ಪ್ರಯತ್ನ ಮಟ್ಟವೂ ಈ ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ, ಆದರೆ ವಿನಂತಿಯನ್ನು ಪೂರೈಸಲು ತನಗೆ ಇನ್ನೂ ಎಷ್ಟು ಹಂತಗಳು ಮತ್ತು ಕ್ರಿಯೆಗಳು ಉಳಿದಿವೆ ಎಂಬುದನ್ನು ಏಜೆಂಟ್ ಕೂಡ ತಿಳಿದಿರಬೇಕು. ಆ ಮಾಹಿತಿ ಇಲ್ಲದಿದ್ದರೆ, ಅದರ ಹಂತಗಳು ಅಥವಾ ಕ್ರಿಯೆಗಳು ಮುಗಿದುಹೋಗಿ, ಸಂಶೋಧನೆ ಪೂರ್ಣಗೊಳ್ಳುವ ಮೊದಲೇ ಉತ್ತರಿಸಬೇಕಾದ ಒತ್ತಡಕ್ಕೆ ಒಳಗಾಗಬಹುದು. ರನ್‌ನ ಆರಂಭದಲ್ಲಿ ಬಜೆಟ್ ಅನ್ನು ತಿಳಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಏಜೆಂಟ್ ತನ್ನ ಮಿತಿಗಳನ್ನು ಸಮೀಪಿಸಿದಂತೆ ಜ್ಞಾಪನೆಗಳು ಬರುತ್ತವೆ, ಇದರಿಂದ ಫಲಿತಾಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸಿ ತಲುಪಿಸಲು ಅವಕಾಶವಿರುತ್ತದೆ. high ಮಟ್ಟಕ್ಕೆ, ಜ್ಞಾಪನೆಗಳು ಹಂತದ ಬಜೆಟ್ ಮತ್ತು ಟೂಲ್-ಕರೆ ಬಜೆಟ್ ಎರಡನ್ನೂ ಒಳಗೊಳ್ಳುತ್ತವೆ.

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

ದೀರ್ಘಕಾಲ ನಡೆಯುವ ಸಂಶೋಧನಾ ಕಾರ್ಯಗಳು ಮಾಡೆಲ್‌ನ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋವನ್ನು ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳು, ಪಡೆದ ಪುಟಗಳು ಮತ್ತು ಮಧ್ಯಂತರ ಟಿಪ್ಪಣಿಗಳಿಂದ ತುಂಬುತ್ತವೆ. ಅದು ತುಂಬಿದ ನಂತರ, ಏಜೆಂಟ್ ಕೆಲಸವನ್ನು ನಿಲ್ಲಿಸಬೇಕಾಗುತ್ತದೆ.

ಕಾಂಪ್ಯಾಕ್ಷನ್ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋವನ್ನು ತುಂಬದೆಯೇ ದೀರ್ಘ ರನ್‌ಗಳು ಕೆಲಸ ಮುಂದುವರಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. ಕಾಂಟೆಕ್ಸ್ಟ್ ಒಂದು ಮಿತಿಯನ್ನು ಮೀರಿದಾಗ, ಏಜೆಂಟ್ ಇದುವರೆಗಿನ ಕೆಲಸವನ್ನು ತಾನು ಕಂಡುಕೊಂಡಿದ್ದು ಮತ್ತು ಉಳಿದಿರುವುದರ ಕುರಿತಾದ ಚಿಕ್ಕ ಸಾರಾಂಶದೊಂದಿಗೆ ಬದಲಾಯಿಸಿ, ನಂತರ ಮುಂದುವರಿಯುತ್ತದೆ.

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

ಏಜೆಂಟ್ ಓದುವ ಪ್ರತಿಯೊಂದು ಪುಟವೂ ಅದರ ಕಾಂಟೆಕ್ಸ್ಟ್‌ಗೆ ಸೇರುತ್ತದೆ, ಮತ್ತು ಏಜೆಂಟ್ ಅದನ್ನು ನಂತರದ ಪ್ರತಿಯೊಂದು ಹಂತದಲ್ಲೂ ಹೊತ್ತೊಯ್ಯುತ್ತದೆ. ವೆಬ್ ಪುಟವು ನ್ಯಾವಿಗೇಶನ್, ಬಾಯ್ಲರ್‌ಪ್ಲೇಟ್ ಮತ್ತು ಇತರ ವಿಷಯದಂತಹ ಪ್ರಶ್ನೆಗೆ ಸಂಬಂಧವಿಲ್ಲದ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.

ಏಜೆಂಟ್‌ಗೆ ಸಂಪೂರ್ಣ ಪುಟವನ್ನು ನೀಡುವ ಬದಲು, fetch_url ಮೊದಲು ಹೊರತೆಗೆಯುವಿಕೆಯ ಸುತ್ತನ್ನು ನಡೆಸುತ್ತದೆ. ಪುಟದ ಪಠ್ಯವನ್ನು ಏಜೆಂಟ್‌ನ ಪ್ರಸ್ತುತ ಕಾರ್ಯದೊಂದಿಗೆ ಚಿಕ್ಕ ಮಾಡೆಲ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಮಾಡೆಲ್ ಸಂಬಂಧಿತ ಭಾಗಗಳನ್ನು ಮಾತ್ರ, ಏಜೆಂಟ್ ಅವುಗಳನ್ನು ಉಲ್ಲೇಖಿಸುವಂತೆ ಯಥಾವತ್ತಾಗಿ ಉದ್ಧರಿಸಿ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಒಂದು ಮೌಲ್ಯಮಾಪನದ ಸಮಯದಲ್ಲಿ, 5,561-ಟೋಕನ್ ಪುಟವನ್ನು 293 ಟೋಕನ್‌ಗಳಿಗೆ ಇಳಿಸಲಾಯಿತು, ಇದರಿಂದ ಹೆಚ್ಚುವರಿ ಸಂಬಂಧಿತ ಕಾಂಟೆಕ್ಸ್ಟ್‌ಗೆ ಸ್ಥಳಾವಕಾಶ ದೊರೆಯಿತು.

fetch_url ಅನ್ನು ಹೊರತೆಗೆಯುವಿಕೆಯೊಂದಿಗೆ high ಪ್ರಯತ್ನ ಮಟ್ಟದಲ್ಲಿ ಬಳಸಿದಾಗ ಪ್ರತಿ ಕ್ವೆರಿಗೆ ಇನ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳು ಸುಮಾರು 50% ರಷ್ಟು ಕಡಿಮೆಯಾದವು. ಹೊರತೆಗೆಯುವಿಕೆಯು ಬೆಂಚ್‌ಮಾರ್ಕ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನೂ ಸುಧಾರಿಸಿತು: ಹೊರತೆಗೆಯುವಿಕೆ ಇಲ್ಲದೆ ಪ್ರತಿ ಕ್ವೆರಿಗೆ $0.094 ವೆಚ್ಚದಲ್ಲಿ 83.5% ಇದ್ದುದಕ್ಕೆ ಹೋಲಿಸಿದರೆ, ಪ್ರತಿ ಕ್ವೆರಿಗೆ $0.073 ವೆಚ್ಚದಲ್ಲಿ 88.0% ಸಾಧಿಸಿತು.

ವೆಬ್ ಹುಡುಕಾಟವು ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ ಸಂಶೋಧನಾ ವಿನಂತಿಯ ಕೇಂದ್ರಬಿಂದುವಾಗಿದೆ. ಏಜೆಂಟ್‌ಗಳು ಹುಡುಕುವ ವಿಧಾನದಲ್ಲಿ ಮೂರು ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲಾಗಿದೆ:

ಪ್ರತಿ ಹುಡುಕಾಟಕ್ಕೆ ಹೆಚ್ಚು ಕಾಂಟೆಕ್ಸ್ಟ್: ಪ್ರತಿಯೊಂದು ಹುಡುಕಾಟವು ಈಗ 2K ಬದಲಿಗೆ 4K ವರೆಗಿನ ಟೋಕನ್‌ಗಳಷ್ಟು ಫಲಿತಾಂಶಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಏಜೆಂಟ್ ತನಗೆ ಬೇಕಾದುದನ್ನು ಬೇಗನೆ ಕಂಡುಕೊಳ್ಳುತ್ತದೆ, ಇದರಿಂದ ಹುಡುಕಾಟಗಳು ಕಡಿಮೆಯಾಗುತ್ತವೆ ಮತ್ತು ವೆಚ್ಚವೂ ಕಡಿಮೆಯಾಗುತ್ತದೆ.

ಹೊಸ ಸ್ನಿಪೆಟ್ ಎಂಜಿನ್: ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳು ಕ್ವೆರಿಗೆ ಹೆಚ್ಚು ಹೊಂದಿಕೆಯಾಗುವ ಸ್ನಿಪೆಟ್‌ಗಳನ್ನು ಪಡೆಯುತ್ತವೆ, ಇದರಿಂದ ಏಜೆಂಟ್ ಅಪ್ರಸ್ತುತ ಪಠ್ಯದಿಂದ ಹೊರೆಯಾಗುವುದಿಲ್ಲ.
Fast Search: ಪ್ರತಿ 1K ವಿನಂತಿಗಳಿಗೆ $1.00 ದರದಲ್ಲಿ, Fast Search ಪ್ರತಿ ಹುಡುಕಾಟ ಕರೆಯ ವೆಚ್ಚ ಮತ್ತು ಲೇಟೆನ್ಸಿ ಎರಡನ್ನೂ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

Perplexity Search ತಂಡವು ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಕಾರ್ಯಗಳಾದ್ಯಂತ ಹಿಂಪಡೆಯುವಿಕೆಯ ಗುಣಮಟ್ಟವನ್ನು ನಿರಂತರವಾಗಿ ಸುಧಾರಿಸುತ್ತದೆ. ಇತ್ತೀಚಿನ ನವೀಕರಣಗಳು ಕೋಡ್, ಡೆವಲಪರ್ ಡಾಕ್ಯುಮೆಂಟೇಶನ್, ಉಲ್ಲೇಖ ಪುಟಗಳು, ಕಾನೂನು ಮತ್ತು ನಿಯಂತ್ರಕ ವಿಷಯಗಳಾದ್ಯಂತ ಲಾಭಗಳನ್ನು ತಂದಿವೆ.

ಕೆಲವು ಕಾರ್ಯಗಳಿಗೆ ಅನೇಕ ಹುಡುಕಾಟಗಳು ಸಮಾನಾಂತರವಾಗಿ ನಡೆಯಬೇಕಾಗುತ್ತದೆ; ಇನ್ನು ಕೆಲವಕ್ಕೆ ಕೆಲವು ದೀರ್ಘ ದಾಖಲೆಗಳ ಸೂಕ್ಷ್ಮ ಓದು ಬೇಕಾಗುತ್ತದೆ.

ಆದರೆ, ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಪ್ರವಾಹವನ್ನೂ ಏಜೆಂಟ್‌ನ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್‌ಗೆ ಲೋಡ್ ಮಾಡುವುದು ಕಾಂಟೆಕ್ಸ್ಟ್ ಹೊರೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ಸರಳ ಕಾರ್ಯಗಳಲ್ಲಿ ಮಾಡೆಲ್ ಕಳಪೆ ಕಾರ್ಯಕ್ಷಮತೆ ತೋರುವಂತೆ ಮಾಡಬಹುದು. ಬದಲಾಗಿ, ಕೌಶಲ್ಯಗಳನ್ನು ಹಂತಹಂತದ ಪ್ರಕಟಣೆಯೊಂದಿಗೆ (progressive disclosure) ಒಂದು ಟ್ರೀ ರೂಪದಲ್ಲಿ ಸಂಘಟಿಸಲಾಗಿದೆ. ಮಾಡೆಲ್ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಂತೆ ಸಂಬಂಧಿತ ಕೌಶಲ್ಯಗಳು ಮತ್ತು ಸೂಚನೆಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ, ಸಂಬಂಧವಿಲ್ಲದ ಮಾಹಿತಿಯನ್ನು ತನ್ನ ಕಾಂಟೆಕ್ಸ್ಟ್‌ನಿಂದ ಹೊರಗಿಡುತ್ತದೆ. ಮಾಡೆಲ್ ಒಂದು ಕೌಶಲ್ಯವು ಕಾರ್ಯಕ್ಕೆ ಸೂಕ್ತವೆಂದು ನಿರ್ಧರಿಸಿ ಅದನ್ನು ಲೋಡ್ ಮಾಡುವವರೆಗೆ, ಆ ಕೌಶಲ್ಯಕ್ಕೆ ಅದರ ಹೆಸರು ಮತ್ತು ವಿವರಣೆಯಷ್ಟೇ ವೆಚ್ಚವಾಗುತ್ತದೆ; ಲೋಡ್ ಮಾಡಿದ ನಂತರ ಪೂರ್ಣ ಸೂಚನೆಗಳನ್ನು ಕಾಂಟೆಕ್ಸ್ಟ್‌ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಮಾಡೆಲ್ ನಿಗದಿತ ಕಾರ್ಯಪ್ರವಾಹವನ್ನು ಅನುಸರಿಸುತ್ತದೆ.

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

ಕೆಳಗಿನ WANDR ಬೆಂಚ್‌ಮಾರ್ಕ್ ರನ್‌ಗಳು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಗಳಿಗೆ ಏಜೆಂಟ್‌ಗಳು ಸರಿಯಾದ ಕಾರ್ಯಪ್ರವಾಹಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದನ್ನು ತೋರಿಸುತ್ತವೆ. ಅನೇಕ ಘಟಕಗಳನ್ನು ತನಿಖೆ ಮಾಡುವ ಅಗತ್ಯವನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತಾ, ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಕ್ಕೂ wide-search ಮತ್ತು fanout ಮಾರ್ಗದರ್ಶನವನ್ನು ಲೋಡ್ ಮಾಡಲಾಯಿತು. people-search ಅನ್ನು ಕೇವಲ 6% ಕಾರ್ಯಗಳಿಗೆ ಮಾತ್ರ, ಅದೂ ಪ್ರಶ್ನೆಗಳು ಜನರನ್ನು ಒಳಗೊಂಡಿದ್ದಾಗ ಮಾತ್ರ ಲೋಡ್ ಮಾಡಲಾಯಿತು.

ಮತ್ತೊಂದು WANDR ಕಾರ್ಯವನ್ನು ಪರೀಕ್ಷಿಸುವಾಗ, ಲಂಡನ್‌ನಲ್ಲಿರುವ ಇನ್ಫರೆನ್ಸ್ ಎಂಜಿನಿಯರ್‌ಗಳನ್ನು ಹುಡುಕಲು ಏಜೆಂಟ್ ಫ್ಯಾನ್‌ಔಟ್ ಮಾದರಿಯೊಂದಿಗೆ people-search ಕೌಶಲ್ಯವನ್ನು ಲೋಡ್ ಮಾಡಿತು. ಅದು 39 ಪಾತ್ರ ಪದಗಳನ್ನು 117 ಕ್ವೆರಿಗಳಾಗಿ ವಿಸ್ತರಿಸಿತು, ನಂತರ ಹೆಚ್ಚಿನ ಸ್ಕ್ರೀನಿಂಗ್‌ಗಾಗಿ ಮೊದಲ ಸುತ್ತಿನ ಫಲಿತಾಂಶಗಳನ್ನು 43 ಅನನ್ಯ ಪ್ರೊಫೈಲ್‌ಗಳಾಗಿ ವಿಲೀನಗೊಳಿಸಿತು. people-search ಕೌಶಲ್ಯವು ಅಪ್ರಸ್ತುತ ಕಾಂಟೆಕ್ಸ್ಟ್ ಸೇರಿಸದೆಯೇ ಈ ವಿಸ್ತರಣೆಯ ಮೂಲಕ ಏಜೆಂಟ್‌ಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡಿತು. ಕೆಳಗಿನ ಆಯ್ದ ಭಾಗವನ್ನು ಏಜೆಂಟ್‌ನ ಸ್ಕ್ರಿಪ್ಟ್‌ನಿಂದ ಅಳವಡಿಸಿಕೊಳ್ಳಲಾಗಿದೆ; ಸಹಾಯಕ ಫಂಕ್ಷನ್‌ಗಳ ಹೆಸರುಗಳು ಕೇವಲ ದೃಷ್ಟಾಂತಕ್ಕಾಗಿ.

code1

text

Python

# roles contains the 39 role variants selected by the agent.
queries = []
for role in roles:
    queries.extend([
        {"query": f"Google DeepMind {role} London"},
        {"query": f"Google {role} London"},
        {"query": role, "company": "Google", "location": "London"},
    ])

results = pplx_sdk.search.people_many(
    queries, limit_per_query=50, concurrency=8
)

profiles = {}
for result in results:
    if not result.ok:
        continue
    for profile in result.result:
        if "linkedin.com/in/" not in profile.url:
            continue
        url = profile.url.split("?")[0].rstrip("/")
        previous = profiles.get(url, {})
        if url not in profiles or len(profile.summary or "") > len(
            previous.get("summary") or ""
        ):
            profiles[url] = {
                "url": url,
                "title": profile.title,
                "summary": profile.summary,
            }

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

ಮತ್ತೊಂದು WANDR ಕಾರ್ಯದಲ್ಲಿ, ಏಜೆಂಟ್ 188 ಎಂಜಿನಿಯರ್‌ಗಳ ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಸ್ಕ್ರೀನ್ ಮಾಡಬೇಕಾಗಿತ್ತು. ಕೆಲಸ ಮಾಡುತ್ತಿರುವಂತೆಯೇ ಪ್ರತಿ ಫಲಿತಾಂಶವನ್ನು ದಾಖಲಿಸಲು ಅದು ಚೆಕ್‌ಪಾಯಿಂಟ್ ಮಾದರಿಯನ್ನು ಲೋಡ್ ಮಾಡಿತು. ಮೊದಲ ಸುತ್ತು 160 ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಹೊರತೆಗೆಯಿತು ಆದರೆ 28 ರಲ್ಲಿ ವಿಫಲವಾಯಿತು. ಏಜೆಂಟ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿದಾಗ, ಅದು ಈಗಾಗಲೇ ದಾಖಲಾಗಿದ್ದ ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಬಿಟ್ಟು ಉಳಿದ 28 ಅನ್ನು ಮಾತ್ರ ಮರುಪ್ರಯತ್ನಿಸಿತು. ಚೆಕ್‌ಪಾಯಿಂಟ್ ಇಲ್ಲದಿದ್ದರೆ, ಒಂದೇ ಒಂದು ದೋಷಪೂರಿತ ದಾಖಲೆಯಿಂದಲೂ ಎಲ್ಲಾ 188 ಅನ್ನು ಮತ್ತೆ ಪಡೆಯಬೇಕಾಗುತ್ತಿತ್ತು.ಅಳವಡಿಸಿದ Python ಆಯ್ದ ಭಾಗ; ಇನ್‌ಪುಟ್ ಪುಟಗಳು, ಸ್ಕ್ರೀನಿಂಗ್ ಸೂಚನೆ, ಸ್ಕೀಮಾ ಮತ್ತು ಇಂಪೋರ್ಟ್‌ಗಳನ್ನು ಬಿಡಲಾಗಿದೆ; ಸಹಾಯಕ ಫಂಕ್ಷನ್‌ಗಳ ಹೆಸರುಗಳು ಕೇವಲ ದೃಷ್ಟಾಂತಕ್ಕಾಗಿ.

code 2

text

Python

checkpoint = Checkpoint("research/profile-screening")
config = instruction + json.dumps(schema)
config_id = hashlib.md5(config.encode()).hexdigest()[:6]

def checkpoint_key(page):
    url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10]
    return config_id + url_id

pending = [
    page for page in pages if not checkpoint.has(checkpoint_key(page))
]
for offset in range(0, len(pending), 20):
    batch = pending[offset : offset + 20]
    inputs = [
        json.dumps({
            "url": page["url_in"], "content": page["content"][:30_000]
        })
        for page in batch
    ]
    results = pplx_sdk.llm.extract_many(
        inputs,
        instruction=instruction,
        output_schema=schema,
        chunk_size=5,
        concurrency=4,
    )
    for page, result in zip(batch, results):
        if not result.ok or result.result.error:
            continue
        checkpoint.record(
            checkpoint_key(page),
            [{"url": page["url_in"], **result.result.result}],
        )

ಚೆಕ್‌ಪಾಯಿಂಟ್ ಯಶಸ್ವಿ ಫಲಿತಾಂಶಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ; ಅದು ಮರುಪ್ರಯತ್ನಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ. ಕೀಯಲ್ಲಿ ಸೂಚನೆ ಮತ್ತು ಸ್ಕೀಮಾವನ್ನು ಸೇರಿಸುವುದರಿಂದ, ಸ್ಕ್ರೀನಿಂಗ್ ಮಾನದಂಡಗಳು ಬದಲಾದಾಗ ಮರುಸಂಸ್ಕರಣೆ ಪ್ರಚೋದಿತವಾಗುವುದು ಖಚಿತವಾಗುತ್ತದೆ.

ಪ್ರತಿಯೊಂದು ಪರೀಕ್ಷೆಯೂ ಗುಣಮಟ್ಟ ಮತ್ತು ದಕ್ಷತೆಯಲ್ಲಿ ಸುಧಾರಣೆ ತರಲಿಲ್ಲ. ಏಜೆಂಟ್ ತನ್ನ ಕಾರ್ಯವನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಎಲ್ಲಾ ಕೌಶಲ್ಯಗಳನ್ನು ಮುಂಚಿತವಾಗಿ ಲೋಡ್ ಮಾಡುವುದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಯಿತು. BrowseComp ಮತ್ತು DSQA ನಲ್ಲಿ, ಮುಂಚಿತ ಲೋಡಿಂಗ್ ವೆಚ್ಚವನ್ನು 13% ರಷ್ಟು ಹೆಚ್ಚಿಸಿತು. ದೀರ್ಘ ಸಂಶೋಧನಾ ಪಥಗಳಿಂದಾಗಿ ಹಿಂಪಡೆದ ವಿಷಯವು ಇನ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳ ದೊಡ್ಡ ಪಾಲಾಗುವ WANDR ನಲ್ಲಿ, ಮುಂಚಿತ ಲೋಡಿಂಗ್ ಸ್ಕೋರ್‌ಗಳನ್ನೂ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಈ ಫಲಿತಾಂಶಗಳು ಹಂತಹಂತದ ಪ್ರಕಟಣೆಯ (progressive disclosure) ಮುಂದುವರಿದ ಬಳಕೆಯನ್ನು ಬೆಂಬಲಿಸಿದವು.

ಮಾಡೆಲ್ ಸಾಮರ್ಥ್ಯಗಳು ಮುಂದುವರಿದಂತೆ, ಪ್ರತಿ ಪ್ರಯತ್ನ ಮಟ್ಟಕ್ಕೆ ಅತ್ಯುತ್ತಮ ಮಾಡೆಲ್ ಕೂಡ ಬದಲಾಗುತ್ತದೆ. ಹೊಸ ಮಾಡೆಲ್‌ಗಳ ಘೋಷಣೆಗಳು ಮತ್ತು ಲಭ್ಯತೆಯನ್ನು ಗಮನಿಸುವ ಸ್ವಯಂಚಾಲಿತ ಸಂಶೋಧನಾ ಲೂಪ್ ಅನ್ನು Perplexity ಬಳಸುತ್ತದೆ. ಮಾಡೆಲ್ ಲಭ್ಯವಾದ ತಕ್ಷಣ ಮೌಲ್ಯಮಾಪನಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ.

ಹೊಸ ಮಾಡೆಲ್ ಬಿಡುಗಡೆಯಾದಾಗ, ಸ್ವಯಂಚಾಲಿತ ಏಜೆಂಟ್‌ವೊಂದು ಅದನ್ನು ಮೌಲ್ಯಮಾಪನ harness ಮೂಲಕ ಪರೀಕ್ಷಿಸುತ್ತದೆ. ಅದು ರೀಜನಿಂಗ್ ಪ್ರಯತ್ನ, ಹಂತ ಮತ್ತು ಟೂಲ್-ಕರೆ ಬಜೆಟ್‌ಗಳು ಹಾಗೂ ಟೂಲ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ ವ್ಯಾಪ್ತಿಯನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ರನ್‌ಗೂ ಪ್ರಸ್ತುತ ಪ್ರಯತ್ನ ಮಟ್ಟಗಳಿಗೆ ಹೋಲಿಸಿ ಗುಣಮಟ್ಟ ಮತ್ತು ವೆಚ್ಚದ ಆಧಾರದ ಮೇಲೆ ಸ್ಕೋರ್ ನೀಡುತ್ತದೆ. ಯಾವುದಾದರೂ ರನ್ ಹಿನ್ನಡೆ ಕಂಡರೆ, ಏಜೆಂಟ್ ಅದಕ್ಕೆ ಕಾರಣವನ್ನು ಸಂಶೋಧಿಸಿ, ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹೊಂದಿಸಿ, ಮೌಲ್ಯಮಾಪನವನ್ನು ಮತ್ತೆ ನಡೆಸುತ್ತದೆ. ಅಭ್ಯರ್ಥಿ ಮಾಡೆಲ್ ಅದೇ ಅಥವಾ ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲಿ ಗುಣಮಟ್ಟದಲ್ಲಿ ಮೇಲುಗೈ ಸಾಧಿಸಿದಾಗ ಮಾತ್ರ ಪ್ರಸ್ತುತ ಮಾಡೆಲ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.

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

ಒಂದೇ ಏಜೆಂಟ್ ಒಂದು ಲೂಪ್‌ನಲ್ಲಿ ಸೀಮಿತ ಸಂಖ್ಯೆಯ ಮೂಲಗಳನ್ನು ಮಾತ್ರ ಒಳಗೊಳ್ಳಬಹುದು. ಸಂಕೀರ್ಣ ಕಾರ್ಯಗಳಿಗಾಗಿ, ಹಲವಾರು ಏಜೆಂಟ್‌ಗಳು ಸಮಾನಾಂತರವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಪ್ರತಿಯೊಂದೂ ಸಮಸ್ಯೆಯ ವಿಭಿನ್ನ ಭಾಗದ ಮೇಲೆ ಸಮನ್ವಯದಿಂದ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

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

Agent API ಪೂರ್ವನಿರ್ಧರಿತ ಏಜೆಂಟ್ ಪಾತ್ರಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಮತ್ತು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಕಸ್ಟಮ್ ಸೂಚನೆಗಳೊಂದಿಗೆ ಚೈಲ್ಡ್ ಏಜೆಂಟ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು.

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

WANDR ನಲ್ಲಿ, ultra ಪ್ರತಿ ಕಾರ್ಯಕ್ಕೆ $21.71 ವೆಚ್ಚದಲ್ಲಿ 85.9% ಸ್ಕೋರ್ ಮಾಡುತ್ತದೆ. ಪರೀಕ್ಷಿಸಲಾದ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಲ್ಲಿ ಇದು ಅತ್ಯಧಿಕ ಸ್ಕೋರ್ ಸಾಧಿಸುತ್ತದೆ.

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

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

Agent API ಅನ್ನು ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ವರ್ಕ್‌ಲೋಡ್‌ಗಳಲ್ಲಿ ಪ್ರಯತ್ನ ಮಟ್ಟಗಳನ್ನು ಹೋಲಿಸಿ. ಪ್ರಯತ್ನ ಮಟ್ಟದ ವಿವರಗಳನ್ನು ನಮ್ಮ Agent API ಪ್ರಯತ್ನ ದಸ್ತಾವೇಜಿನಲ್ಲಿ ಕಂಡುಕೊಳ್ಳಿ.

ಸಂಶೋಧನೆಯ ವೆಚ್ಚ

ಸಂಶೋಧನಾ ಬಜೆಟ್ ನಿಯಂತ್ರಣ

ಕಾಂಟೆಕ್ಸ್ಟ್ ನಿರ್ವಹಣೆ

ಕಾಂಪ್ಯಾಕ್ಷನ್

ಮುಖ್ಯವಾದುದನ್ನು ಮಾತ್ರ ಪಡೆಯುವುದು

ಕೇಂದ್ರೀಕೃತ ವೆಬ್ ಹುಡುಕಾಟ

ಸರಿಯಾದ ಕಾರ್ಯಪ್ರವಾಹವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು

ಮಾಡೆಲ್ ಆಯ್ಕೆ

ಬಹು-ಏಜೆಂಟ್ ಸ್ಕೇಲಿಂಗ್

ಮುಂದೇನು