ಕೋಡ್ ಜನರೇಷನ್ ಆಗಿ ಹುಡುಕಾಟವನ್ನು ಮರುಚಿಂತನೆ ಮಾಡುವುದು

AI ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಹುಡುಕಾಟವು (Search) ಪ್ರಮುಖ ಮೂಲಭೂತ ಅಂಶವಾಗಿದೆ. ಫ್ರಾಂಟಿಯರ್ ಮಾದರಿಗಳು (Frontier models) ಪ್ರತಿ ತಿಂಗಳು ಹೆಚ್ಚು ಸಾಮರ್ಥ್ಯವನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತಿವೆ, ಆದರೆ ವಿಶಾಲ ಜಗತ್ತಿನಿಂದ ತಾಜಾ, ನಿಖರವಾದ ಮತ್ತು ಉತ್ತಮವಾಗಿ ಸಂಗ್ರಹಿಸಲಾದ ಜ್ಞಾನಕ್ಕೆ ಅವುಗಳಿಗೆ ಇನ್ನೂ ಪ್ರವೇಶದ ಅಗತ್ಯವಿದೆ. AI ವ್ಯವಸ್ಥೆಗಳು ಆ ಜ್ಞಾನವನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ಹುಡುಕಾಟವೇ ಪ್ರಾಥಮಿಕ ಮಾರ್ಗವಾಗಿದೆ, ಮತ್ತು ಹೀಗಾಗಿ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು, ಕ್ರಮಗಳನ್ನು ಕೈಗೊಳ್ಳಲು ಮತ್ತು ನೈಜ-ಪ್ರಪಂಚದ ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸಲು ಅಗತ್ಯವಿರುವ ಯಾವುದೇ ಉತ್ಪನ್ನದ ಮೂಲಭೂತ ಘಟಕವಾಗಿದೆ.

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

ಈ ಜಗತ್ತಿನಲ್ಲಿ, ಹುಡುಕಾಟದ ನಿರ್ಮಾಣ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಏಜೆಂಟ್ ಹಾರ್ನೆಸ್ ಒಳಗೆ SDK ಗಳಾಗಿ ನೇರವಾಗಿ ಪ್ರವೇಶಿಸಬಹುದಾದ ಮೂಲಕ ಹುಡುಕಾಟವೇ ಏಜೆಂಟ್ ಆಗಬೇಕು. Perplexity ಯ ಹೊಸ ಉಲ್ಲೇಖ ಹುಡುಕಾಟ ಆರ್ಕಿಟೆಕ್ಚರ್ ಆಗಿ ನಾವು Search as Code (SaC) ಅನ್ನು ಪರಿಚಯಿಸುತ್ತಿದ್ದೇವೆ.

Perplexity ಯ ಹುಡುಕಾಟ ಸ್ಟ್ಯಾಕ್ ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು API ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸಾವಿರಾರು ಪ್ರಶ್ನೆಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ. ಸೆಪ್ಟೆಂಬರ್ 2025 ರಲ್ಲಿ, ನಮ್ಮ ಹುಡುಕಾಟ ವ್ಯವಸ್ಥೆಗಳ ಮೊದಲ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಅವಲೋಕನವನ್ನು ನಾವು ಪ್ರಕಟಿಸಿದ್ದೇವೆ. ಈ ವ್ಯವಸ್ಥೆಗಳೊಳಗಿನ ನಿರಂತರ ನಾವೀನ್ಯತೆಯು Search API, Agent API, ಮತ್ತು Computer ನಂತಹ ಹೊಸ ಕೊಡುಗೆಗಳ ಬಿಡುಗಡೆಗೆ ಬೆಂಬಲ ನೀಡಿದೆ, ಜೊತೆಗೆ ಪ್ರತಿ ದಿನ ಕಳೆಯುತ್ತಿದ್ದಂತೆ ಬಳಕೆದಾರರಿಗೆ ಉತ್ತಮವಾಗಿ ಸೇವೆ ಸಲ್ಲಿಸಲು ಹುಡುಕಾಟ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡುವ ಸ್ವಯಂ-ಸುಧಾರಣಾ ಲೂಪ್‌ಗಳನ್ನು ಹೊಂದಿದೆ.

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

ಸಾಂಪ್ರದಾಯಿಕ ಹುಡುಕಾಟ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು ಮಾದರಿಗಳು ಸರಣಿ ರೂಪದಲ್ಲಿ ಕರೆಯುವ ಏಕೈಕ ಸ್ಥಿರ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತವೆ, ಆದರೆ Search as Code ಯು ಉತ್ಪತ್ತಿಯಾದ ಕೋಡ್ ಮೂಲಕ ಏಜೆಂಟ್‌ಗಳು ರಚಿಸುವ ಪರಮಾಣು ಹುಡುಕಾಟ ಪ್ರಿಮಿಟಿವ್‌ಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ.

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

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

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

ಈ ಅಗತ್ಯವನ್ನು ಪೂರೈಸಲು, ನಾವು ನಮ್ಮ ಉತ್ಪನ್ನಗಳಲ್ಲಿ ಹೊಸ ಹುಡುಕಾಟ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಪರಿಚಯಿಸುತ್ತಿದ್ದೇವೆ: Search as Code (SaC). ಈ ಹೊಸ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮಾದರಿಗಳಿಗೆ ಅದರ ಅಂತಿಮ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಕೇವಲ ಬಳಸಿಕೊಳ್ಳುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಹುಡುಕಾಟ ಸ್ಟ್ಯಾಕ್ ಒಳಗೆ ತಲುಪಲು ಅಧಿಕಾರ ನೀಡುತ್ತದೆ. ಪ್ರಮುಖ ಕಲ್ಪನೆಯು ನೇರವಾಗಿರುತ್ತದೆ: ನಾವು ಹುಡುಕಾಟ ಸ್ಟ್ಯಾಕ್‌ನ ಘಟಕಗಳನ್ನು SDK ಒಳಗೆ ಪ್ರಿಮಿಟಿವ್‌ಗಳಾಗಿ ಬಹಿರಂಗಪಡಿಸುತ್ತೇವೆ. ಹುಡುಕಾಟದ ಅಗತ್ಯವಿರುವ ಯಾವುದೇ ವಿನಂತಿಗಾಗಿ, ಮಾದರಿಯು ಈ ಪ್ರಿಮಿಟಿವ್‌ಗಳನ್ನು ಆನ್-ಡಿಮ್ಯಾಂಡ್ ಆಗಿ ನಿರ್ದಿಷ್ಟ ವಿನಂತಿಗೆ ತಕ್ಕಂತೆ ರೂಪಿಸಲಾದ ಮರುಪಡೆಯುವಿಕೆ ಪೈಪ್‌ಲೈನ್‌ಗೆ ಜೋಡಿಸುತ್ತದೆ.

ಈ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಜೋಡಿಸುವುದನ್ನು ಸುರಕ್ಷಿತ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಕೋಡ್ ಜನರೇಷನ್ ಮತ್ತು ಎಕ್ಸಿಕ್ಯೂಷನ್ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ. ಹುಡುಕಾಟಕ್ಕಾಗಿ ಇತರ codegen-ಚಾಲಿತ ವಿಧಾನಗಳಂತೆ, ನಾವು ಕೇವಲ ಶೆಲ್ ಅಥವಾ ಭಾಷೆಯ ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಸಾಂಪ್ರದಾಯಿಕ ಹುಡುಕಾಟ API ಅನ್ನು ಅಂಟಿಸುವುದಿಲ್ಲ. ಬದಲಿಗೆ, ನಾವು ಅತ್ಯಂತ ಪರಮಾಣು ಮಟ್ಟದಲ್ಲಿ ಹುಡುಕಾಟದ ಪ್ರತ್ಯೇಕ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ಏಜೆಂಟ್ ಹುಡುಕಾಟ SDK (Agentic Search SDK) ಅನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದೇವೆ.

Search as Code (SaC) ವಿವಿಧ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳ ಸೂಟ್‌ನಲ್ಲಿ ಏಜೆಂಟ್ ಹುಡುಕಾಟದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಗಡಿಯನ್ನು ಮುನ್ನಡೆಸುತ್ತದೆ.

ಈ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳೊಂದಿಗೆ ಸಜ್ಜುಗೊಂಡಿರುವ SaC, ಮಾದರಿಗಳಿಗೆ ಪ್ರತಿಯೊಂದು ವೈಯಕ್ತಿಕ ಹುಡುಕಾಟ ಹಂತದ ಮೇಲೆ ನೇರ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುತ್ತದೆ: ಮರುಪಡೆಯುವಿಕೆ (retrieval), ಶ್ರೇಯಾಂಕ (ranking), ಫಿಲ್ಟರಿಂಗ್, ಫ್ಯಾನ್‌ಔಟ್‌ಗಳು, ರೆಂಡರಿಂಗ್ ಮತ್ತು ಇನ್ನಷ್ಟು. ಇದು ಅಭ್ಯರ್ಥಿ ಪಟ್ಟಿಗಳು ಮತ್ತು ಶ್ರೇಯಾಂಕದ ಸಂಕೇತಗಳಂತಹ ಮಧ್ಯಂತರ ಸ್ಥಿತಿಗೆ ಮಾದರಿಗೆ ಸಮರ್ಥ ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತದೆ. ಒಟ್ಟಾಗಿ, ನಿಯಂತ್ರಣ ಮತ್ತು ಓದುವಿಕೆಯ ಈ ಅವಳಿ ಲಿವರ್‌ಗಳು ಏಜೆಂಟ್‌ಗಳಿಗೆ ಸಾವಿರಾರು ಮರುಪಡೆಯುವಿಕೆ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ವ್ಯಾಪಿಸಿರುವ ಬೆಸ್ಪೋಕ್ ಹುಡುಕಾಟ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲು, ಫ್ಲೈನಲ್ಲಿ ಆ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು ಮತ್ತು ಮಾದರಿ ಸಂದರ್ಭವಾಗಿ ಅತ್ಯಂತ ಉಪಯುಕ್ತವಾದ ಮಾಹಿತಿಯನ್ನು ಮಾತ್ರ ಸೇವಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

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

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

ಪರಿಣಾಮವಾಗಿ, ಮಾನವ-ಮುಖಿ ಹುಡುಕಾಟ ಎಂಜಿನ್‌ಗಳು ಸಾಮಾನ್ಯ ಏಕಶಿಲೆಯ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಒಮ್ಮುಖವಾದವು, ಇನ್‌ಪುಟ್ ಪ್ರಶ್ನೆಗೆ ಅಗ್ರ n ಹಿಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಮಾನವ-ಸ್ನೇಹಿ ಹುಡುಕಾಟ ಎಂಜಿನ್ ಫಲಿತಾಂಶ ಪುಟಗಳನ್ನು (SERP ಗಳು) ಉತ್ಪತ್ತಿ ಮಾಡುವತ್ತ ಗಮನಹರಿಸಿದವು. ಈ ಮಾದರಿಯು ಗ್ರಾಹಕ ಹುಡುಕಾಟದಲ್ಲಿ ದಶಕಗಳ ಪ್ರಗತಿಗೆ ಶಕ್ತಿ ತುಂಬಿದೆ. ಇದು ಮಾನವ ಬ್ರೌಸಿಂಗ್‌ಗೆ ವೇಗವಾದ, ಪರಿಚಿತ ಮತ್ತು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ.

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

ಆದಾಗ್ಯೂ, AI-ಆಪ್ಟಿಮೈಸ್ಡ್ ವ್ಯವಸ್ಥೆಗಳು ಸಹ ಸಾಂಪ್ರದಾಯಿಕ ಹುಡುಕಾಟ ಎಂಜಿನ್‌ಗಳ ಅದೇ ಮೂಲಭೂತ ಒಪ್ಪಂದವನ್ನು ದೊಡ್ಡ ಮಟ್ಟದಲ್ಲಿ ಆನುವಂಶಿಕವಾಗಿ ಪಡೆದಿವೆ: ಪ್ರಶ್ನೆಯನ್ನು ಸ್ವೀಕರಿಸಿ, ಪೂರ್ವನಿರ್ಧರಿತ ಹುಡುಕಾಟ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ರನ್ ಮಾಡಿ, ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ಫಲಿತಾಂಶಗಳ ಸಮೂಹವನ್ನು ಹಿಂತಿರುಗಿಸಿ. ಸರಳ ವಿನಂತಿಗಳಿಗಾಗಿ, ಈ ವಿಧಾನವು ಚೆನ್ನಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ವಿನಂತಿಗಳಿಗಾಗಿ, ಇದು ಕಾರ್ಯಕ್ಷಮತೆ, ಸುಪ್ತತೆ (latency) ಮತ್ತು ವೆಚ್ಚವನ್ನು ಹದಗೆಡಿಸುವ ಹೆಚ್ಚು ಮಿತಿಗೊಳಿಸುವ ಅಡಚಣೆಯಾಗುತ್ತದೆ.

ಸಾಂಪ್ರದಾಯಿಕ ಹುಡುಕಾಟ ವ್ಯವಸ್ಥೆಗಳು ಮಾದರಿ-ಗೋಚರ ತಿರುವುಗಳ ಮೂಲಕ ಹುಡುಕಾಟವನ್ನು ಅನುಕ್ರಮಗೊಳಿಸಲು ಏಜೆಂಟ್ ಕಾರ್ಯಪ್ರವಾಹಗಳನ್ನು ಒತ್ತಾಯಿಸುತ್ತವೆ. ಮಾದರಿಗಳು ವಿಭಿನ್ನ ಪ್ರಶ್ನೆ ನಿಯರಾಚನೆಗಳಲ್ಲಿ ಒಂದೇ ಹುಡುಕಾಟ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಪುನರಾವರ್ತಿತವಾಗಿ ಕರೆಯಬೇಕು ಮತ್ತು ಎಲ್ಲಾ ಫಲಿತಾಂಶಗಳನ್ನು ಮಾದರಿ ಸಂದರ್ಭಕ್ಕೆ ಪರಿಚಯಿಸಬೇಕು.

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

ಗ್ರಾಹಕರು ಲಿಂಕ್‌ಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ಮಾನವರಾಗಿರುವಾಗ ಇದು ಸಂವೇದನಾಶೀಲ ಗಡಿಯಾಗಿದೆ. ಗ್ರಾಹಕರು ಮುಚ್ಚಿದ ಲೂಪ್‌ನಲ್ಲಿ ಜ್ಞಾನ-ತೀವ್ರ ಕಾರ್ಯಗಳನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ AI ಮಾದರಿಯಾಗಿರುವಾಗ ಇದು ಕಳಪೆ ಗಡಿಯಾಗಿದೆ. ನಮ್ಮ ಅನುಭವದಲ್ಲಿ, ಈ ಬಿಗಿತವು ಮೂರು ಮರುಕಳಿಸುವ ವಿಫಲತೆಯ ವಿಧಾನಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ:

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

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

ಅಕಾರ್ಯಕ್ಷಮ ನಿಯಂತ್ರಣ ಪ್ರವಾಹ ಮತ್ತು ಸಂದರ್ಭ ಮಾಲಿನ್ಯ. ಬಹುತೆಕ ಹುಡುಕಾಟ ಕಾರ್ಯಪ್ರವಾಹಗಳು ಸಹಜವಾಗಿ ಕ್ರಮಬದ್ಧವಾಗಿರುವುದಿಲ್ಲ. ಅವುಗಳಿಗೆ ಪ್ರಶ್ನೆಯ ರೂಪಾಂತರಗಳ ಮೇಲೆ fan-out, ಸಮಾಂತರ ಪಡೆಯಿಕೆ, deduplication, ಮತ್ತು ರೇಖೀಯವಲ್ಲದ ಹಾಗೂ ಅಸಮಯೋಚಿತ ನಿಯಂತ್ರಣ ಪ್ರವಾಹವನ್ನು ಅಗತ್ಯಪಡಿಸುವ ಇತರ ಕಾರ್ಯಾಚರಣೆಗಳು ಬೇಕಾಗಿರಬಹುದು. ಈ ಹಂತಗಳನ್ನು ಪುನರಾವರ್ತಿತ ಮಾದರಿ ತಿರುವುಗಳ ಮೂಲಕ ಕಡ್ಡಾಯಗೊಳಿಸುವುದು ವಿಳಂಬವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಪ್ರವಾಹವನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ. ಇದು ಮಾದರಿಯ reasoningಗೆ ಉಪಯುಕ್ತವಾಗದಿರಬಹುದಾದ ಶಬ್ದಯುಕ್ತ ಮಧ್ಯಂತರ ಸ್ಥಿತಿಯಿಂದ ಮಾದರಿಯ ಸಂದರ್ಭವನ್ನು ಕೂಡ ಕಲುಷಿತಗೊಳಿಸುತ್ತದೆ; ಇದರ ಪರಿಣಾಮವಾಗಿ ಕಾರ್ಯಕ್ಷಮತೆ ಕೆಡುತ್ತದೆ ಮತ್ತು compactionಗಳು ಹೆಚ್ಚು ಸಂಭವಿಸುತ್ತವೆ.

AI ನ ಕಾರ್ಯ ಕರೆಯುವಿಕೆ & MCP ಯುಗಗಳಲ್ಲಿ ಈ ಸವಾಲುಗಳ ಬಗ್ಗೆ ಹೆಚ್ಚು ಮಾಡಲು ಸಾಧ್ಯವಿರಲಿಲ್ಲ. ಪ್ರತಿ ಹುಡುಕಾಟ ಕಾರ್ಯಾಚರಣೆಗೆ LLM ಅನುಮಾನಕ್ಕೆ (inference) ತನ್ನದೇ ಆದ ರೌಂಡ್‌ಟ್ರಿಪ್ ಅಗತ್ಯವಿರುವಾಗ, ಡೆವಲಪರ್‌ಗಳು ಸ್ವಾಭಾವಿಕವಾಗಿ ಆ ರೌಂಡ್‌ಟ್ರಿಪ್‌ನಲ್ಲಿ ಸಾಧ್ಯವಾದಷ್ಟು ಹೆಚ್ಚಿನ ಕೆಲಸವನ್ನು ಮಾಡಲು ಬಯಸುತ್ತಾರೆ. ಇದರರ್ಥ ಮಾದರಿಯಿಂದ ನೇರ ಬಳಕೆಗಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ಫಲಿತಾಂಶ ಸಮೂಹಗಳನ್ನು ಹಿಂತಿರುಗಿಸುವ ಎಂಡ್-ಟು-ಎಂಡ್ ಹುಡುಕಾಟ ಪೈಪ್‌ಲೈನ್‌ಗಳು.

ಫಲವಾಗಿ, ಇಂದು ಬಹುಪಾಲು AI-ಮುಖಿ ಹುಡುಕಾಟ ವ್ಯವಸ್ಥೆಗಳು ಇನ್ನೂ ಈ ಏಕಘಟಕ ಒಪ್ಪಂದದ ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ. ಆದರೆ, ಮಾದರಿ ಬುದ್ಧಿಮತ್ತೆ ಮತ್ತು ಬಳಕೆದಾರ ಬೇಡಿಕೆಗಳ ನಿರಂತರ ಬೆಳವಣಿಗೆಯೊಂದಿಗೆ, ಆ ಒಪ್ಪಂದದ ದೋಷಗಳು ಇನ್ನಷ್ಟು ಸ್ಪಷ್ಟವಾಗುತ್ತಿವೆ. code-first harnesses ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಇಂದಿನ ಅತ್ಯಾಧುನಿಕ AI ವ್ಯವಸ್ಥೆಗಳು ನಿಮಿಷಕ್ಕೆ ಸಾವಿರಾರು ಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಕಾರ್ಯ-ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಪ್ರವಾಹಗಳನ್ನು ಸಂಯೋಜಿಸಬಹುದು. ಹುಡುಕಾಟ ವ್ಯವಸ್ಥೆಗಳು ಇನ್ನೂ ಈ ಸಾಮರ್ಥ್ಯವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸಾಕಾರಗೊಳಿಸಿಲ್ಲ.

AI-native ಹುಡುಕಾಟಕ್ಕೆ ಸರಿಯಾದ ಗಡಿ stack‌ನ ಇನ್ನೂ ಕೆಳಗೆ ಇದೆ ಎಂದು ನಾವು ಬಹಳ ಕಾಲದಿಂದ ಅನುಮಾನಿಸುತ್ತಿದ್ದೇವೆ. ಮಾದರಿಗಳು ಕೇವಲ ಹುಡುಕಾಟ ಎಂಜಿನ್ ಅನ್ನು ಕರೆಯುವುದಷ್ಟೇ ಮಾಡಬಾರದು. ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯದ ಬೇಡಿಕೆಗೆ ಅನುಗುಣವಾಗಿ, ಹುಡುಕಾಟ stack‌ನ ಪ್ರತ್ಯೇಕ ಭಾಗಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಸಾಮರ್ಥ್ಯ ಅವರಿಗೆ ಇರಬೇಕು. ಅದಕ್ಕೆ ಮೂಲಭೂತವಾಗಿ ಭಿನ್ನವಾದ ವಾಸ್ತುಶಿಲ್ಪ ಅಗತ್ಯವಾಗಿದೆ.

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

ನಮ್ಮ ಹೊಸ Search as Code (SaC) ಆರ್ಕಿಟೆಕ್ಚರ್ ಈ ತತ್ವವನ್ನು ಸಾಕಾರಗೊಳಿಸುತ್ತದೆ. SaC ನಲ್ಲಿ, ಫಂಕ್ಷನ್ कॉलिंग ಅಥವಾ MCP ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ಯಾವುದೇ ಏಕೈಕ ಮರುಪಡೆಯುವಿಕೆ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಕಳುಹಿಸಲಾಗುವುದಿಲ್ಲ. ಬದಲಿಗೆ ಎಲ್ಲಾ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾದರಿ-ಉತ್ಪಾದಿತ Python ಕೋಡ್ ಮೂಲಕ ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಲಾಗುತ್ತದೆ. ಸರಳವಾದ ಹುಡುಕಾಟ ಅಗತ್ಯಗಳಿಗಾಗಿ, ಈ ಕೋಡ್ ಉನ್ನತ ಮಟ್ಟದ ಹುಡುಕಾಟ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಕೆಲವೇ ವಿನಂತಿಗಳನ್ನು ಒಳಗೊಂಡಿರಬಹುದು. ಆದರೆ ಸಂಕೀರ್ಣ ಕಾರ್ಯಗಳಿಗಾಗಿ, ಕೋಡ್ ಅಗತ್ಯವಿರುವಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿರಬಹುದು, ಇದು ಷರತ್ತುಬದ್ಧ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ, ಅಸಮಕಾಲಿಕತೆ, ಸಮಾನಾಂತರತೆ ಮತ್ತು ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಕಡಿಮೆ-ಮಟ್ಟದ ಪ್ರಿಮಿಟಿವ್‌ಗಳಿಗೆ ಕರೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.

Search as Code (SaC) ಆರ್ಕಿಟೆಕ್ಚರ್ ಮಾದರಿಗಳು, ಕಂಪ್ಯೂಟ್ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ಗಳು ಮತ್ತು Perplexity ಯ ಹುಡುಕಾಟ ಮೂಲಸೌಕರ್ಯದ ಮೇಲಿರುವ ಏಜೆಂಟ್ ಹುಡುಕಾಟ SDK ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ.

SaC ಮೂರು ಬಿಗಿಯಾಗಿ ಜೋಡಿಸಲಾದ ಪದರಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

ಮಾದರಿಗಳು (Models) ನಿಯಂತ್ರಣ ಸಮತಳವಾಗಿ (control plane) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಅವು ಬಳಕೆದಾರರ (ಅಥವಾ ಮೂಲ ಏಜೆಂಟ್‌ನ) ನಿರ್ದೇಶನದ ಬಗ್ಗೆ ತಾರ್ಕಿಕತೆಯನ್ನು ಮಾಡುತ್ತವೆ, ನಿರ್ದೇಶನವನ್ನು ಕಾರ್ಯಗಳಾಗಿ ವಿಭಜಿಸುತ್ತವೆ, ಪ್ರತಿ ಕಾರ್ಯಕ್ಕೆ ಯಾವ ಮರುಪಡೆಯುವಿಕೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಿಕೆ ಪೈಪ್‌ಲೈನ್‌ಗಳು ಅಗತ್ಯವೆಂದು ನಿರ್ಧರಿಸುತ್ತವೆ ಮತ್ತು ಆ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕೋಡ್ ಅನ್ನು ಉತ್ಪತ್ತಿ ಮಾಡುತ್ತವೆ.

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

ನಮ್ಮ Agentic Search SDK Perplexity ಯ ಹುಡುಕಾಟ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಸಂಯೋಜಿಸಬಹುದಾದ ಪ್ರಿಮಿಟಿವ್‌ಗಳಾಗಿ ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ. ಇದು ಕಡಿಮೆ-ಮಟ್ಟದ ಮರುಪಡೆಯುವಿಕೆ ಕಾರ್ಯಾಚರಣೆಗಳಿಂದ ಉನ್ನತ ಮಟ್ಟದ ಶಾಸ್ರ್ತೀಯ ಪಾರ್ಸಿಂಗ್ ವರೆಗೆ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. SDK ಅನ್ನು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ಗಳ ಎಕ್ಸಿಕ್ಯೂಷನ್ ರನ್‌ಟೈಮ್‌ಗಳಲ್ಲಿ ಎಂಬೆಡ್ ಮಾಡಲಾಗಿದೆ, ಇದು ಮಾದರಿಗಳಿಗೆ ಒಂದೇ ಅನುಮಾನ ತಿರುವಿನಲ್ಲಿ (inference turn) ಸಾವಿರಾರು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ. ಕೆಳಗೆ, ಪ್ರತಿ ಪದರಕ್ಕೂ ನಮ್ಮ ವಿನ್ಯಾಸ ನಿರ್ಧಾರಗಳನ್ನು ನಾವು ಚರ್ಚಿಸುತ್ತೇವೆ.

Agentic Search SDK ಪ್ರೊಗ್ರಾಮ್ ಮಾಡಬಹುದಾದ ಹುಡುಕಾಟಕ್ಕಾಗಿ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಮುಖ್ಯವಾಗಿ, ನಮ್ಮ SDK ಲೈಬ್ರರಿಯಾಗಿ ಪ್ಯಾಕ್ ಮಾಡಲಾದ ಪೂರ್ವಪೀಠಿಕ ಹುಡುಕಾಟ API ಅಲ್ಲ. ಕಳೆದ ಕೆಲವು ತಿಂಗಳುಗಳಲ್ಲಿ, ನಮ್ಮ ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡವು ನಮ್ಮ ಹುಡುಕಾಟ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಮಾಡ್ಯುಲರ್, ಸಂಯೋಜಿಸಬಹುದಾದ ಪ್ರಿಮಿಟಿವ್‌ಗಳಾಗಿ ಮರು-ಆರ್ಕಿಟೆಕ್ಚರ್ ಮಾಡಿದೆ. ಮಾದರಿಯು ಕಾರ್ಯ-ನಿರ್ದಿಷ್ಟ ಮರುಪಡೆಯುವಿಕೆ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಬಹುದಾದ ಹೆಚ್ಚು ಶಕ್ತಿಶಾಲಿ ಕ್ಯಾನ್ವಾಸ್ ಅನ್ನು ಒದಗಿಸಲು ನಾವು Agentic Search SDK ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ.

ಉನ್ನತ ಮಟ್ಟದ, ಎಂಡ್-ಟು-ಎಂಡ್ ಹುಡುಕಾಟ ಪೈಪ್‌ಲೈನ್‌ಗಳು SDK ಒಳಗೆ ಇನ್ನೂ ಲಭ್ಯವಿವೆ, ಆದರೆ ಅವು ಇನ್ನು ಮುಂದೆ ಏಕೈಕ ಆಯ್ಕೆಯಲ್ಲ. ಬದಲಿಗೆ, ಅವು ಸಾಮಾನ್ಯ ಹುಡುಕಾಟ ಮಾದರಿಗಳಿಗೆ ಶಾರ್ಟ್‌ಹ್ಯಾಂಡ್ ರೂಪವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಕಾರ್ಯದ ಬೇಡಿಕೆಗೆ ತಕ್ಕಂತೆ ಮಾದರಿಯು ಅವುಗಳನ್ನು ಬಳಸಲು ಅಥವಾ ಬೈಪಾಸ್ ಮಾಡಲು ಮುಕ್ತವಾಗಿದೆ.

ರನ್‌ಟೈಮ್ ಆಯ್ಕೆ: ನಾವು SDK ರನ್‌ಟೈಮ್ ಆಗಿ Python, Rust, TypeScript, ಮತ್ತು Bash ಅನ್ನು ಪರಿಗಣಿಸಿದ್ದೇವೆ. ಅದರ ವ್ಯಾಪಕ ಬಳಕೆ ಮತ್ತು ಡೇಟಾ ಸಂಸ್ಕರಣಾ ಲೈಬ್ರರಿಗಳ ಪರಿಸರವನ್ನು ಗಮನಿಸಿದರೆ, Python ಅತ್ಯಂತ ಸಹಜವಾದ ಆಯ್ಕೆ ಎಂದು ನಾವು ಅನುಮಾನಿಸಿದ್ದೆವು. ಆಂತರಿಕ ಪರೀಕ್ಷೆಗಳು ಇದನ್ನು ದೃಢಪಡಿಸಿದವು, ಮತ್ತು ಇಂದು ಹೊರಬರುತ್ತಿರುವ SDK ಆವೃತ್ತಿ Python ಆಧಾರಿತವಾಗಿದೆ. ಅದು ಅತ್ಯುತ್ತಮ ಏಜೆಂಟ್ ಅನುಭವವನ್ನು ನೀಡುತ್ತಲೇ ಇರುವುದನ್ನು ಖಚಿತಪಡಿಸಲು, ನಾವು ನಿಯಮಿತವಾಗಿ ರನ್‌ಟೈಮ್ ಆಯ್ಕೆಯನ್ನು ಪುನಃ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ನಿರೀಕ್ಷೆಯಲ್ಲಿದ್ದೇವೆ.

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

ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ಗಳು SaC ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು ಮತ್ತು ರನ್ ಮಾಡಲು ಸುರಕ್ಷಿತ ಪರಿಸರವನ್ನು ಒದಗಿಸುತ್ತವೆ. ಅವು ವೈಯಕ್ತಿಕ ಹುಡುಕಾಟ ಪ್ರಿಮಿಟಿವ್‌ಗಳೊಂದಿಗೆ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಸುಲಭಗೊಳಿಸಲು Agentic Search SDK ಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುವ ಮೂಲಕ ಮಾದರಿ-ಉತ್ಪಾದಿತ ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತವೆ.

ನಮ್ಮ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡುವಲ್ಲಿ ಮತ್ತು ಗಟ್ಟಿಗೊಳಿಸುವಲ್ಲಿ ನಾವು ಗಮನಾರ್ಹ ಹೂಡಿಕೆಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ, ಮತ್ತು ಅವುಗಳ ಒಟ್ಟಾರೆ ವ್ಯವಸ್ಥೆಯ ವಿನ್ಯಾಸವು ತನ್ನದೇ ಆದ ಲೇಖನಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ. ಇಲ್ಲಿ, ನಾವು SaC ಗೆ ಹೆಚ್ಚು ಸಂಬಂಧಿಸಿದ ವಿನ್ಯಾಸ ಪರಿಗಣನೆಯ ಮೇಲೆ ಗಮನ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇವೆ: ಮಧ್ಯಂತರ ರಾಜ್ಯಗಳನ್ನು (intermediate states) ನಿರ್ವಹಿಸುವುದು.

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

ತಿರುವುಗಳಾದ್ಯಂತ ಮಧ್ಯಂತರ ರಾಜ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಲು ನಾವು ಎರಡು ವಿಧಾನಗಳನ್ನು ಪರಿಗಣಿಸಿದ್ದೇವೆ:

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

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

ನಾವು ಎರಡೂ ವಿಧಾನಗಳನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ, ಮತ್ತು ಸಾಮಾನ್ಯ ಬಳಕೆಯಲ್ಲಿ ಅವು ಸಮಾನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದರೂ, filesystem-based serde ವಿಶೇಷವಾಗಿ ದೀರ್ಘ trajectoriesಗಳಲ್ಲಿ ಉತ್ತಮ ನಂಬಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ. ಆದ್ದರಿಂದ ನಾವು filesystem-based serde ಅನ್ನು ನಮ್ಮ ಪರಿಹಾರವಾಗಿ ಅಂಗೀಕರಿಸುತ್ತೇವೆ. ಮಾದರಿಗಳು ಸ್ಥಿತಿಯನ್ನು ಅಪ್ರತ್ಯಕ್ಷವಾಗಿ ಅಲ್ಲದೆ ಸ್ಪಷ್ಟವಾಗಿ ವಿವರಿಸುವಂತೆ ಕಡ್ಡಾಯಗೊಳಿಸುವುದರಿಂದ ಅವರು ಆ ಸ್ಥಿತಿಯನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿರ್ವಹಿಸಲು ಸಹಾಯವಾಗುತ್ತದೆ ಎಂದು ನಾವು ಊಹಿಸುತ್ತೇವೆ. ಇದು ತಾತ್ಕಾಲಿಕವಾದ ಕಂಡುಹಿಡಿತವಾಗಿದ್ದು, ನಾವು ಎರಡೂ ವಿಧಾನಗಳ ಮೇಲೂ ಮುಂದುವರೆದು ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ.

ಏಜೆಂಟ್ ಹಾರ್ನೆಸ್‌ಗಳಿಗೆ ಶಕ್ತಿ ತುಂಬುವ ಮಾದರಿಗಳು SaC ನ ನಿಯಂತ್ರಣ ಸಮತಳವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ: ಪ್ರತಿ ಕಾರ್ಯದ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸಲು Agentic Search SDK ಯ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳಿಂದ ಹುಡುಕಾಟ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಜೋಡಿಸುವುದು, ನಂತರ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಎಕ್ಸಿಕ್ಯೂಷನ್‌ಗಾಗಿ ಆ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಕೋಡ್ ಆಗಿ ಕಳುಹಿಸುವುದು.

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

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

ಈ ಸವಾಲನ್ನು ಪರಿಹರಿಸಲು, ನಮ್ಮ SDK ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಿಕೊಳ್ಳಲು ಮಾದರಿಗಳಿಗೆ ಕಲಿಸಲು ನಾವು ಹೆಚ್ಚು-ಟ್ಯೂನ್ ಮಾಡಲಾದ ಏಜೆಂಟ್ ಕೌಶಲ್ಯಗಳನ್ನು (Agent Skills) ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ. ಆರಂಭಿಕ ಆವೃತ್ತಿಗಳನ್ನು ಕೌಶಲ್ಯಗಳಿಗಾಗಿ Perplexity ಯ ವಿನ್ಯಾಸ ತತ್ವಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ, ಮತ್ತು ನಂತರ SDK ಆಪ್ಟಿಮೈಸೇಶನ್‌ನಲ್ಲಿ ಬಳಸಲಾದ ಅದೇ ಮೆಟ್ರಿಕ್‌ಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿದ ಸಮರ್ಪಿತ ಆಟೋರಿಸರ್ಚ್ ಲೂಪ್ ಮೂಲಕ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾಗಿದೆ. ಸಂದರ್ಭದ ಉಬ್ಬಿಕೊಳ್ಳುವಿಕೆಯಿಂದ ರಕ್ಷಿಸಲು ನಾವು ಕೌಶಲ್ಯದ ಗಾತ್ರವನ್ನು ಸಹ ಸೀಮಿತಗೊಳಿಸುತ್ತೇವೆ, ಮತ್ತು ನಮ್ಮ ಅಂತಿಮ ಆವೃತ್ತಿಗಳು ಅವುಗಳ ಮೂಲ SKILL.md ಫೈಲ್‌ಗಳಲ್ಲಿ 2000 ಕ್ಕಿಂತ ಕಡಿಮೆ ಟೋಕನ್‌ಗಳನ್ನು ಹೊಂದಿವೆ.

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

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

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

ಉದಾಹರಣೆಗೆ, ಹುಡುಕಾಟ ವ್ಯವಸ್ಥೆಯ ಸ್ವಂತ ಪ್ರಶ್ನೆ ಸಿಂಟ್ಯಾಕ್ಸ್ ಮೂಲಕ ಸಮರ್ಥವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗದ ಸಂಕೀರ್ಣ regex ಅನ್ನು ಪರಿಗಣಿಸಿ. ಕೋಡಿಂಗ್ ಸಾಮರ್ಥ್ಯಗಳಿಲ್ಲದೆ, ಮಾದರಿಯು ತನ್ನ ಅತ್ಯುತ್ತಮ ಅಂದಾಜನ್ನು ಉತ್ಪತ್ತಿ ಮಾಡಲು, ಪ್ರಶ್ನೆಯನ್ನು ಮಾಡಲು ಮತ್ತು ಬಹಳ ಗದ್ದಲದ ಫಲಿತಾಂಶ ಸಮೂಹದ ಮೇಲೆ ಟೋಕನ್-ಸ್ಪೇಸ್ ಫಿಲ್ಟರಿಂಗ್ ಮಾಡಲು ಒತ್ತಾಯಿಸಲ್ಪಡುತ್ತದೆ. SaC ನೊಂದಿಗೆ, ಬಯಸಿದ regex ನ ಫಲಿತಾಂಶ ಸಮೂಹದ ಸೂಪರ್‌ಸೆಟ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಮಾನಾಂತರ SDK ಕರೆಗಳನ್ನು ಮಾಡುವ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಮಾದರಿಯು ಬದಲಿಗೆ ಉತ್ಪತ್ತಿ ಮಾಡಬಹುದು. SDK ಮೂಲಕ deduping ಮಾಡಿದ ನಂತರ, ಫಲಿತಾಂಶಗಳನ್ನು ನಿಖರವಾದ regex ಗೆ ನಿರ್ಣಾಯಕವಾಗಿ ಕಿರಿದಾಗಿಸಲು ಮಾದರಿಯು ಹೆಚ್ಚುವರಿ ಕೋಡ್ ಅನ್ನು ಬರೆಯಬಹುದು. ಈ ರೀತಿಯಲ್ಲಿ, SDK ಅನ್ನು ಅತಿಯಾದ ವಿಶೇಷ ಉಪದಳಗಳೊಂದಿಗೆ ಉಬ್ಬಿಸದೆ ಕಸ್ಟಮ್ ಹುಡುಕಾಟ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಏಜೆಂಟ್‌ಗಳು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು.

ನಾವು ನಮ್ಮ ಪರೀಕ್ಷಾ ಸ್ಯೂಟ್‌ನೊಳಗಿನ ನೈಜ-ಜಗತ್ತಿನ ಕಾರ್ಯದ ಮೇಲೆ ಆಧಾರಿತ ಒಂದು case study ಅನ್ನು ಮಂಡಿಸುತ್ತೇವೆ. ಈ ಕಾರ್ಯವು 2023–2025ರ 200ಕ್ಕೂ ಹೆಚ್ಚು ಉನ್ನತ-ತೀವ್ರತೆಯ CVEಗಳನ್ನು ಗುರುತಿಸಿ ಅವುಗಳ ಲಕ್ಷಣಗಳನ್ನು ವಿವರಿಸಲು ಒಂದು ಏಜೆಂಟ್ ಅನ್ನು ಕೇಳುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ದಾಖಲೆಗೂ ಪರಿಣಾಮಿತ vendor‌ನ ಸ್ವಂತ advisory ಅನ್ನು ಉಲ್ಲೇಖಿಸಬೇಕು, ಉತ್ಪನ್ನ ಮತ್ತು fix version ಅನ್ನು ಹೆಸರಿಸಬೇಕು, ಮತ್ತು fix version ನಿರ್ದಿಷ್ಟ CVEಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸಬೇಕು.

SaC ನ ಉತ್ತರವು ನಿಖರತೆಯಲ್ಲಿ 100% ಗಳಿಸಿತು, ನಾನ್-SaC ಬೇಸ್‌ಲೈನ್‌ಗೆ ಹೋಲಿಸಿದರೆ ಒಟ್ಟು ಟೋಕನ್ ಬಳಕೆ 85.1% ರಷ್ಟು ಕುಸಿಯಿತು (288.7K ಟೋಕನ್‌ಗಳಿಂದ 42.9K ಟೋಕನ್‌ಗಳಿಗೆ). ವಿಭಾಗ 4 ರಲ್ಲಿ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಚರ್ಚಿಸಲಾದ ಪರೀಕ್ಷಿತ ನಾನ್-Perplexity ವ್ಯವಸ್ಥೆಗಳು, ಎಲ್ಲವೂ 25% ಕ್ಕಿಂತ ಕಡಿಮೆ ಗಳಿಸಿವೆ.

SaC ನ ಪ್ರೊಗ್ರಾಮಬಿಲಿಟಿ ಮಾದರಿಗೆ ಪರಿಣಾಮಕಾರಿ ತಂತ್ರಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಹೇಗೆ ಅನುಮತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಲು ನಾವು ಪಥದಿಂದ ಮೂರು ಶೈಲೀಕೃತ ಕೋಡ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತೇವೆ.

python

# Part 1 of 3: fan out over official advisory formats.
templates = [
    ("Mozilla",
     'site:mozilla.org/en-US/security/advisories/mfsa{year} '
     '"CVE-{year}-" "Fixed in" "Impact high"'),
    ("Jenkins",
     'site:jenkins.io/security/advisory/{year} '
     '"CVE-{year}" "Severity" "High" "Fix"'),
    ("Chrome",
     'site:chromereleases.googleblog.com/{year} '
     '"High CVE-{year}" "Stable channel has been updated"'),
    ("Android",
     'source.android.com/docs/security/bulletin/{year}-{month:02d}-01 '
     '"High" "CVE-{year}"'),
    ...
]

queries = [
    {"vendor": vendor, "query": pattern.format(year=year, month=month)}
    for year in [2023, 2024, 2025]
    for vendor, pattern in templates
    for month in ([1] if "{month" not in pattern else range(1, 13))
]

seed_hits = sdk.search.web_many(queries, limit_per_query=8, concurrency=12)

pages = [
    {"vendor": q["vendor"], "url": h.url, "text": join_result_fields(h)}
    for q, hits in zip(queries, seed_hits)
    for h in hits
    if official_vendor_advisory(h.url, q["vendor"])
]

ಈ ಮೊದಲ ಬ್ಲಾಕ್ ಶುದ್ಧ ಆರ್ಕೆಸ್ಟ್ರೇಷನ್ ಆಗಿದೆ. ಉತ್ಪತ್ತಿಯಾದ ಪ್ರೋಗ್ರಾಂ ಮೂಲ-ವರ್ಗದ ನಿಯಮವನ್ನು ನೇರವಾಗಿ ಪ್ರಶ್ನೆ ಯೋಜನೆಯಲ್ಲಿ ಎನ್ಕೋಡ್ ಮಾಡುವ ಮೂಲಕ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ: ವೆಂಡರ್-ಮಾಲೀಕತ್ವದ ಸಲಹಾ ಸ್ವರೂಪಗಳು ಮಾತ್ರ ಪ್ರಸ್ತುತವಾಗಿವೆ. NVD, MITRE, CVE Details, ಸುದ್ದಿ ಕಥೆಗಳು, CERT ಪುಟಗಳು ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ವೆಂಡರ್-ಅಲ್ಲದ ಮೂಲಗಳು ರಚನಾತ್ಮಕವಾಗಿ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿವೆ. ನಿಖರ-ನುಡಿಗಟ್ಟು ನಿರ್ಬಂಧಗಳು ಸಹ ಹುಡುಕಾಟವನ್ನು ಸೂಚ್ಯಂಕಿತ ಪಠ್ಯವು ಈಗಾಗಲೇ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಅಗತ್ಯವಿರುವ ನಿಖರವಾದ CVE ವಿವರಗಳನ್ನು ಹೊಂದಿರುವ ಪುಟಗಳ ಕಡೆಗೆ ತಳ್ಳುತ್ತವೆ.

python

# Part 2 of 3: synthesize refinements for sparse vendor-years.
coverage = summarize(pages, by=["vendor", "year", "url_kind"])

prompt = """
Goal: 230+ high or critical CVEs from official vendor advisories.
Avoid aggregators, CERTs, news, NVD, MITRE, and CVE databases.
Current coverage:
{coverage}
Suggest more site-scoped exact-phrase queries for sparse vendor-years.
Prefer per-advisory pages over archive or month-index pages.
Return JSON lines with vendor and query.
""".format(coverage=coverage)

raw = query_llm(prompt)

expanded_queries = [
    row for row in parse_jsonl(raw)
    if official_scope(row["query"]) and mentions_cve_year(row["query"])
]

expanded_hits = sdk.search.web_many(
    unique(expanded_queries),
    limit_per_query=8,
    concurrency=12,
)

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

python

# Part 3 of 3: verify CVE-to-version binding.
all_hits = dedupe_by_url(flatten(seed_hits) + flatten(expanded_hits))

items = [
    {"url": h.url, "vendor_hint": infer_vendor(h.url),
     "text": join_result_fields(h)}
    for h in all_hits
    if official_vendor_advisory(h.url, infer_vendor(h.url))
]

verified = sdk.llm.extract_many(
    items,
    instruction=(
        "Keep only vendor advisories where the page ties a high or critical "
        "CVE to a specific fixed version, build, patch, or security level."
    ),
    schema={
        "matches": bool,
        "cve": str,
        "vendor": str,
        "product": str,
        "fix_version": str,
        "severity": str,
        "source_url": str,
        "evidence": str,
        "version_bound_to_cve": bool,
        "confidence": float,
    },
)

records = [
    to_cve_record(x) for x in verified
    if x.matches and x.version_bound_to_cve
    if high_or_critical(x.severity) and x.confidence > 0.75
]
records = dedupe_by(records, key="cve")

ಅಂತಿಮ ಬ್ಲಾಕ್ ಏಜೆಂಟ್ codegen ಮೂಲಕ ಸಂಪೂರ್ಣವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಿರುವ ಒಂದು result verifier ಆಗಿದೆ. search ಉಪಕ್ರಮಗಳು ಸಮಂಜಸವಾದ advisory ಪುಟಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದಾದರೂ, ಈ ಕಾರ್ಯಕ್ಕೆ ಇನ್ನೂ ಕಠಿಣವಾದ ಸಂಬಂಧ ಅಗತ್ಯವಿದೆ: vendor ಬರೆದ ಪಠ್ಯದಲ್ಲಿ advisory ಒಂದು CVE ಅನ್ನು ಒಂದು ಪರಿಣಾಮಿತ ಉತ್ಪನ್ನ ಮತ್ತು ಒಂದು fix version‌ಗೆ ಬಂಧಿಸಬೇಕು. schema ಆ ಸಂಬಂಧವನ್ನು ಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ downstream ಕೋಡ್ CVE ಆಧಾರದಲ್ಲಿ dedupe ಮಾಡಬಹುದು, aggregator URLs ಅನ್ನು ನಿರಾಕರಿಸಬಹುದು, ದುರ್ಬಲ version ಸಾಕ್ಷ್ಯವನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು, ಮತ್ತು ದಾಖಲೆ-ಎಣಿಕೆಯ ಕನಿಷ್ಠ ಮಟ್ಟ ಪೂರೈಸುವವರೆಗೆ backfilling ಮುಂದುವರಿಸಬಹುದು.

ಸಂಪೂರ್ಣ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಸೂಟ್‌ನಲ್ಲಿ ನಾವು SaC ನ ಪರಿಣಾಮಕಾರಿತ್ವವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ, ಸಂಪೂರ್ಣ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ವೆಚ್ಚ-ಕಾರ್ಯಕ್ಷಮತೆಯ ಗಡಿ ಎರಡರ ಮೇಲೂ ಗಮನ ಹರಿಸುತ್ತೇವೆ.

ನಮ್ಮ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಸೂಟ್ ಒಟ್ಟು ಐದು ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಇವು ವಿವಿಧ ಡೊಮೇನ್‌ಗಳು, ಕಾರ್ಯ ಸ್ವರೂಪಗಳು ಮತ್ತು ಸಂಕೀರ್ಣತೆಯ ಮಟ್ಟಗಳಲ್ಲಿ ಹುಡುಕಾಟ-ಅವಲಂಬಿತ AI ಕಾರ್ಯಪ್ರವಾಹಗಳನ್ನು ಒತ್ತಡ ಪರೀಕ್ಷಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ನಾವು ನಾಲ್ಕು ಪೂರ್ವಪೀಠಿಕ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳನ್ನು ಬಳಸುತ್ತೇವೆ: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE), ಮತ್ತು WideSearch. ಮೊದಲ ಮೂರು ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳಿಗಾಗಿ (DSQA, BrowseComp, ಮತ್ತು HLE), ನಾವು ಟಾಪ್‌ಲೈನ್ ಮೆಟ್ರಿಕ್ ಆಗಿ ನಿಖರತೆಯನ್ನು ವರದಿ ಮಾಡುತ್ತೇವೆ. WideSearch ಗಾಗಿ, ನಾವು ಸಾಲಿನಿಂದ F1 ಸ್ಕೋರ್ ಅನ್ನು ವರದಿ ಮಾಡುತ್ತೇವೆ.

ನಾವು ಹೊಸದಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾದ WANDR benchmark‌ನನ್ನೂ ಬಳಸುತ್ತೇವೆ, ಇದು ಹುಡುಕಾಟ, compute, ಮತ್ತು ಮಾದರಿ ರೀಜನಿಂಗ್‌ನ ಎಚ್ಚರಿಕೆಯ ಸಂಯೋಜನೆಯನ್ನು ಅಗತ್ಯಪಡಿಸುವ ಕಷ್ಟಸಾಧ್ಯ “wide research” ಕಾರ್ಯಗಳ ಮೇಲೆ ಗಮನಹರಿಸುತ್ತದೆ. WANDR ಅನ್ನು Perplexity Computer ಬಳಕೆದಾರರಿಗಾಗಿ ನಿರ್ವಹಿಸುವ ಜ್ಞಾನ-ತೀವ್ರ ವೃತ್ತಿಪರ ಕಾರ್ಯಗಳಿಂದ ಪ್ರೇರಣೆ ಪಡೆದಿದೆ. ಇದು WideSearch ಹಾಗೂ ಸಮಾನ benchmarkಗಳನ್ನು ಆಧರಿಸಿ ಮುಂದುವರಿದಿದೆ, ಆದರೆ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಕಾರ್ಯಗಳು ಮತ್ತು ಕಾರ್ಯರಚನೆಗಳನ್ನು ಒತ್ತಿಹೇಳುತ್ತದೆ. ನಾವು ಮುಂದಿನ ವಾರಗಳಲ್ಲಿ WANDR benchmark ಅನ್ನು ಪ್ರಕಟಿಸುವೆವು.

ನಾವು ಐದು ಏಜೆಂಟ್-ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ. ಸಮಾನಾಂತರತೆಯ ಪ್ರಯೋಜನಗಳಿಗಿಂತ ಅಂತರ್ಗತ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ನಾವು “ಅತ್ಯುತ್ತಮ-N” ಸ್ಕೋರ್‌ಗಳ ಬದಲಿಗೆ ಪ್ರತ್ಯೇಕ ರನ್‌ಗಳನ್ನು ಪರಿಗಣಿಸುತ್ತೇವೆ. ಪ್ರತಿಯೊಂದು ವ್ಯವಸ್ಥೆಯ ಸಂರಚನೆಯನ್ನು ಕೆಳಗೆ ವಿವರಿಸಲಾಗಿದೆ:

Perplexity (SaC): Perplexity ಯ ಪ್ರೊಡಕ್ಷನ್ Agent API ಒಳಗೆ ನಾವು SaC ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ. GPT 5.5 (ಹೆಚ್ಚಿನ ತಾರ್ಕಿಕತೆ) ಅಡಿಯಲ್ಲಿರುವ ಮಾದರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

OpenAI: ಹುಡುಕಾಟ (web_search) ಮತ್ತು Python ರನ್‌ಟೈಮ್ (code_interpreter) ಎರಡನ್ನೂ ಸಕ್ರಿಯಗೊಳಿಸಿ ನಾವು OpenAI Responses API ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ. GPT 5.5 (ಹೆಚ್ಚಿನ ತಾರ್ಕಿಕತೆ) ಅಡಿಯಲ್ಲಿರುವ ಮಾದರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

Anthropic: 20260401 ಏಜೆಂಟ್ ಟೂಲ್‌ಸೆಟ್ ಮತ್ತು ಆಟೋ-ಅಲೋಡ್ ಆಜ್ಞೆಗಳೊಂದಿಗೆ ನಾವು Anthropic Managed Agents ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ. Opus 4.7 (ಹೆಚ್ಚಿನ ತಾರ್ಕಿಕತೆ) ಅಡಿಯಲ್ಲಿರುವ ಮಾದರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

Exa: ಪ್ರೊಡಕ್ಷನ್ API ಮೂಲಕ ನಾವು Exa Agent ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ, ಪ್ರಯತ್ನವನ್ನು ಹೆಚ್ಚಿಸಲಾಗಿದೆ.

Parallel: ಪ್ರೊಡಕ್ಷನ್ API ಮೂಲಕ ನಾವು Parallel Tasks ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ, ಪ್ರೊಸೆಸರ್ ಅನ್ನು ultra4x ಗೆ ಹೊಂದಿಸಲಾಗಿದೆ.

ಟೇಬಲ್ 1 ಪ್ರತಿ ವ್ಯವಸ್ಥೆಗೆ benchmark ಅಂಕಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಐದು benchmarkಗಳಲ್ಲಿ ನಾಲ್ಕರಲ್ಲಿ SaC ಇತರ ಎಲ್ಲ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಮೀರಿಸುತ್ತದೆ. ಉಳಿದ benchmark (HLE)ನಲ್ಲಿ, SaC OpenAI Responses ಜೊತೆ ಮೂಲತಃ ಮೊದಲ ಸ್ಥಾನಕ್ಕೆ ಸಮವಾಗಿದೆ. ಪರಿಚಯದಲ್ಲಿನ ಚಿತ್ರ 2 ಈ ಅಂಕಗಳನ್ನು ಗ್ರಾಫಿಕಲ್ ರೂಪದಲ್ಲಿ ದೃಶ್ಯೀಕರಿಸುತ್ತದೆ.

ಬೆಂಚ್‌ಮಾರ್ಕ್	Perplexity (SaC)	OpenAI	Anthropic	Exa	Parallel
DSQA	0.871	0.733	0.815	0.530	0.810
BrowseComp	0.805	0.720	0.598	0.380	0.560
HLE	0.612	0.614	0.566	0.387	0.515
WideSearch	0.651	0.522	0.590	0.471	0.584
WANDR	0.386	0.130	0.152	0.057	0.126

ಕೋಷ್ಟಕ 1 | ಮೌಲ್ಯಮಾಪನಗೊಂಡ ಪ್ರತಿಯೊಂದು ವ್ಯವಸ್ಥೆಗೆ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಸ್ಕೋರ್‌ಗಳು. ಪ್ರತಿ ಸಾಲಿಗೆ ಉತ್ತಮ ಸ್ಕೋರ್ ಬೋಲ್ಡ್‌ನಲ್ಲಿದೆ.

SaC benchmark ಸಮೂಹದಾದ್ಯಂತ state-of-the-art ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸಿದರೂ, ಅದರ ಮೇಲುಗೈ WANDR‌ನಲ್ಲಿ ವಿಶೇಷವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿದೆ. ಚಿತ್ರ 5 WANDR ಅಂಕಗಳನ್ನು ವಿಭಜಿಸಿ ತೋರಿಸುತ್ತದೆ; ಅದರಲ್ಲಿ Perplexity‌ನ SaC ಅನುಷ್ಠಾನವು ಮುಂದಿನ ಅತ್ಯುತ್ತಮ ವ್ಯವಸ್ಥೆಯನ್ನು 2.5× ಅಂತರದಿಂದ ಮೀರಿಸುತ್ತದೆ ಎಂದು ಕಾಣುತ್ತದೆ. ಈ ದೊಡ್ಡ ಅಂತರದ ಹೊರತಾಗಿಯೂ, WANDR ಇನ್ನೂ saturation ಆಗಿಲ್ಲ ಮತ್ತು SaC‌ಗೆ ಸಹ ಸವಾಲಾಗಿಯೇ ಉಳಿದಿದೆ. WANDR‌ನ ಕಾರ್ಯಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ಸಂಕೀರ್ಣ, ಅತ್ಯಂತ horizontal ಹುಡುಕಾಟ ಕಾರ್ಯಪ್ರವಾಹಗಳಿಗೆ ಸಂಶೋಧನೆ ಮತ್ತು ಹುಡುಕಾಟ engineeringನಲ್ಲಿ ಇನ್ನಷ್ಟು ಮುಂದುವರೆದ ಬೆಳವಣಿಗೆಗಳು ಅಗತ್ಯವಾಗುತ್ತವೆ ಎಂದು ನಾವು ನಂಬುತ್ತೇವೆ, ಆಗ ಮಾತ್ರ ಸತತವಾಗಿ ಉನ್ನತ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸಬಹುದು.

ಮೌಲ್ಯಮಾಪನಗೊಂಡ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ WANDR ಸ್ಕೋರ್‌ಗಳು. Perplexity Agent API ಮುಂದಿನ ಅತ್ಯುತ್ತಮ ವ್ಯವಸ್ಥೆಗಿಂತ 2.5× ರಷ್ಟು ಮುಂಚೂಣಿಯಲ್ಲಿದೆ.

ಅಂತಿಮವಾಗಿ, ಅದೇ Perplexity ಹುಡುಕಾಟ ಮೂಲಸೌಕರ್ಯವನ್ನು ಬಳಸಿಕೊಳ್ಳುವ ಹೆಚ್ಚು ಸಾಂಪ್ರದಾಯಿಕ ಹುಡುಕಾಟ ಪೈಪ್‌ಲೈನ್‌ಗೆ ವಿರುದ್ಧವಾಗಿ SaC ನ ಸಾಪೇಕ್ಷ ಲಾಭಗಳನ್ನು ನಾವು ಅಳೆಯುತ್ತೇವೆ. ಚಿತ್ರ 6 ಪ್ರತಿಯೊಂದು ಬೆಂಚ್‌ಮಾರ್ಕ್‌ನಲ್ಲಿ SaC ಮತ್ತು ನಾನ್-SaC ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳ ನಡುವಿನ ಸ್ಕೋರ್‌ಗಳಲ್ಲಿನ ವ್ಯತ್ಯಾಸವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಎಲ್ಲೆಡೆಯೂ, SaC ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಗಣನೀಯ ವರ್ಧನೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ, DSQA (+19.77 pp, 29%) ನಲ್ಲಿ ಅತಿ ದೊಡ್ಡ ಸಂಪೂರ್ಣ ಲಾಭ ಮತ್ತು WANDR (+12.00 pp, 45%) ನಲ್ಲಿ ಅತಿ ದೊಡ್ಡ ಸಾಪೇಕ್ಷ ಲಾಭವನ್ನು ಹೊಂದಿದೆ.

ಪ್ರತಿ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ನಲ್ಲಿ Perplexity ಬೇಸ್‌ಲೈನ್ vs. SaC ಸ್ಕೋರ್, ಸಂಪೂರ್ಣ ಮತ್ತು ಸಾಪೇಕ್ಷ ಡೆಲ್ಟಾಗಳೊಂದಿಗೆ ಟಿಪ್ಪಣಿ ಮಾಡಲಾಗಿದೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಬಳಕೆದಾರರು ವೆಚ್ಚಕ್ಕೆ ಹೋಲಿಸಿದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುತ್ತಾರೆ. ಆದ್ದರಿಂದ ನಾವು DSQA ಮತ್ತು WideSearch‌ನಲ್ಲಿ cost-performance frontier ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ. ಕಡಿಮೆ, ಮಧ್ಯಮ, ಮತ್ತು ಹೆಚ್ಚಿನ ಮಾದರಿ ರೀಜನಿಂಗ್ ಮಟ್ಟಗಳಾದ್ಯಂತ SaC‌ನ ವೆಚ್ಚ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು, ಇತರ ವ್ಯವಸ್ಥೆಗಳ ಜೊತೆಗೆ, ನಾವು ಅಳೆಯುತ್ತೇವೆ. ಚಿತ್ರಗಳು 7 ಮತ್ತು 8 benchmark ಅಂಕವನ್ನು ಪ್ರತಿ ಕಾರ್ಯದ ಬೆಲೆಯ ವಿರುದ್ಧ ಚಿತ್ರಿಸುತ್ತವೆ; x-ಅಕ್ಷವನ್ನು ಹಿಮ್ಮುಖಗೊಳಿಸಲಾಗಿದ್ದು, ಬಲಕ್ಕೆ ದೂರವಿರುವ ಬಿಂದುಗಳು ಅಗ್ಗವಾಗಿರುತ್ತವೆ ಮತ್ತು ಮೇಲಿರುವ ಬಿಂದುಗಳು ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ.

DSQA ಸ್ಕೋರ್ ವಿರುದ್ಧ ಪ್ರತಿ-ಕಾರ್ಯ ಬೆಲೆ. ಡ್ಯಾಶ್ ಮಾಡಿದ ಸಾಲು SaC ಮಾದರಿ ತಾರ್ಕಿಕತೆಯ ಸಂರಚನೆಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ.

DSQA ನಲ್ಲಿ, ಎಲ್ಲಾ ಮೂರು SaC ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮೇಲಿನ-ಬಲ ಗಡಿಯಲ್ಲಿ ಇರುತ್ತವೆ. ಕಡಿಮೆ ತಾರ್ಕಿಕತೆಯ ಸೆಟ್ಟಿಂಗ್ ಇತರ ಎರಡು ವ್ಯವಸ್ಥೆಗಳಿಗಿಂತ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವಾಗ ಎಲ್ಲಾ ಇತರ ವ್ಯವಸ್ಥೆಗಳಿಗಿಂತ ಅಗ್ಗವಾಗಿದೆ. ಮಧ್ಯಮ ತಾರ್ಕಿಕತೆಯ ಸೆಟ್ಟಿಂಗ್ ಪ್ರತಿ ಕಾರ್ಯಕ್ಕೆ $1 ಗಿಂತ ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲಿ ಎಲ್ಲಾ ನಾನ್-SaC ವ್ಯವಸ್ಥೆಗಳಿಗಿಂತ ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆ ನೀಡುತ್ತದೆ. ಹೆಚ್ಚಿನ ತಾರ್ಕಿಕತೆಯ ಸೆಟ್ಟಿಂಗ್ ಸ್ಪರ್ಧಾತ್ಮಕ ವೆಚ್ಚದೊಂದಿಗೆ ಉನ್ನತ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸುತ್ತದೆ.

WideSearch ಸ್ಕೋರ್ ವಿರುದ್ಧ ಪ್ರತಿ-ಕಾರ್ಯ ಬೆಲೆ. ಡ್ಯಾಶ್ ಮಾಡಿದ ಸಾಲು SaC ಮಾದರಿ ತಾರ್ಕಿಕತೆಯ ಸಂರಚನೆಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ.

WideSearch ಇದೇ ರೀತಿಯ ಆಕಾರದ ಗಡಿಯನ್ನು ತೋರಿಸುತ್ತದೆ. DSQA ಯಂತೆ, ಕಡಿಮೆ ತಾರ್ಕಿಕತೆಯ ಸೆಟ್ಟಿಂಗ್ ಎಲ್ಲಾ ನಾನ್-SaC ವ್ಯವಸ್ಥೆಗಳಿಗಿಂತ ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲಿ ಸ್ಪರ್ಧಾತ್ಮಕ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸುತ್ತದೆ, ಆದರೆ ಮಧ್ಯಮ ಮತ್ತು ಹೆಚ್ಚಿನ ತಾರ್ಕಿಕತೆ ಎರಡೂ ಕಾರ್ಯ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ನಾನ್-SaC ವ್ಯವಸ್ಥೆಗಳಿಗಿಂತ ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆ ನೀಡುತ್ತವೆ.

Search as Code ಸಾಫ್ಟ್‌ವೇರ್ ವಿನ್ಯಾಸದಲ್ಲಿ ವಿಶಾಲವಾದ ಬದಲಾವಣೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ. ದಶಕಗಳಿಂದ, ಸಾಫ್ಟ್‌ವೇರ್ ವ್ಯವಸ್ಥೆಗಳನ್ನು CPU ಗಳಲ್ಲಿ ಸಾಂಪ್ರದಾಯಿಕ ರನ್‌ಟೈಮ್‌ಗಳಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸಲಾದ ನಿರ್ಣಾಯಕ ಸೂಚನೆಗಳ ಸುತ್ತ ಆಯೋಜಿಸಲಾಗಿದೆ. ಫ್ರಾಂಟಿಯರ್ ಮಾದರಿಗಳು ಕಂಪ್ಯೂಟ್‌ನ ಹೊಸ ರೂಪವನ್ನು ಪರಿಚಯಿಸುತ್ತವೆ: ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸಲು ಮತ್ತು ಉತ್ಪತ್ತಿ ಮಾಡಲು ಎರಡನ್ನೂ ಮಾಡಬಹುದಾದ ಟೋಕನ್-ಸ್ಪೇಸ್ ತಾರ್ಕಿಕತೆ. ಅತ್ಯಂತ ಸಮರ್ಥ ಕಂಪ್ಯೂಟೇಶನಲ್ ವ್ಯವಸ್ಥೆಗಳು ಅವುಗಳ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುವ ಬದಲು ಕಂಪ್ಯೂಟ್‌ನ ಈ ಎರಡು ರೂಪಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತವೆ.

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

ಈ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅನ್‌ಲಾಕ್ ಮಾಡಲು ಈ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಪ್ರತಿಯೊಂದು ಭಾಗವೂ ಅವಶ್ಯಕವಾಗಿದೆ. ಬುದ್ಧಿವಂತ ಮಾದರಿಗಳಿಲ್ಲದೆ, ವ್ಯವಸ್ಥೆಯು ಹುಡುಕಾಟ ತಂತ್ರದ ಮೇಲೆ ತಾರ್ಕಿಕತೆಯನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ಗಳಿಲ್ಲದೆ, ಮಾದರಿಗಳು ಸರಣಿ I/O ಮತ್ತು ಅಸಮರ್ಥ ಟೋಕನ್-ಸ್ಪೇಸ್ ಪ್ರಕ್ರಿಯೆಗೆ ಒತ್ತಾಯಿಸಲ್ಪಡುತ್ತವೆ. ಮತ್ತು ಪರಮಾಣು ಹುಡುಕಾಟ ಸ್ಟ್ಯಾಕ್ ಇಲ್ಲದೆ, ಮಾದರಿಗೆ ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಲು ಏನೂ ಇರುವುದಿಲ್ಲ. SaC ಕೆಲಸ ಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ತಾರ್ಕಿಕತೆ, ನಿರ್ಣಾಯಕ ಕಂಪ್ಯೂಟ್ ಮತ್ತು I/O ಪ್ರತಿ ಪದರದ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಒತ್ತುಹೇಳಲು ಜಂಟಿಯಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.

ನಿರಂತರ ಸುಧಾರಣಾ ಲೂಪ್‌ಗಳ ಅಭಿವೃದ್ಧಿಯ ಮೂಲಕ ಈ ಕೋಡಿಸೈನ್ ಅನ್ನು ಇನ್ನಷ್ಟು ಮುಂದುವರಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, Agentic Search SDK ಮತ್ತು SaC Agent Skills ಅನ್ನು ಸಾಮಾನ್ಯ ಆಟೋರಿಸರ್ಚ್ ಲೂಪ್‌ನಲ್ಲಿ ಜಂಟಿಯಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬಹುದು. ಹೆಚ್ಚು ಮಹತ್ವಾಕಾಂಕ್ಷೆಯೆಂದರೆ, SDK ಆಗಿ ಬಹಿರಂಗಪಡಿಸಲಾದ ಕಡಿಮೆ-ಮಟ್ಟದ ಹುಡುಕಾಟ ಪ್ರಿಮಿಟಿವ್‌ಗಳ ಲಾಭ ಪಡೆಯಲು ಮಾದರಿಗಳಿಗೆ ತರಬೇತಿ ನೀಡಬಹುದು. ಮಾದರಿ ತರಬೇತಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿಯೇ SDK ವಿನ್ಯಾಸವನ್ನು ಸಹ-ವಿಕಾಸಗೊಳಿಸಲು ಸಹ ಪ್ರಯತ್ನಿಸಬಹುದು. ಭವಿಷ್ಯದ ಕೆಲಸದಲ್ಲಿ ಹೆಚ್ಚು ಆಕ್ರಮಣಕಾರಿ ಕೋಡಿಸೈನ್ ತಂತ್ರಗಳನ್ನು ಮುಂದುವರಿಸಲು ನಾವು ಎದುರು ನೋಡುತ್ತಿದ್ದೇವೆ.

ಕೇವಲ ಫಲಿತಾಂಶಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳುವ ಬದಲು ಹುಡುಕಾಟ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು ಮಾದರಿಗಳಿಗೆ ಅನುಮತಿಸಲು ನಾವು SaC ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ. ನಮ್ಮ ಫಲಿತಾಂಶಗಳು ಈ ನಿಯಂತ್ರಣದ ಶಕ್ತಿಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ: SaC ಜ್ಞಾನ-ತೀವ್ರ ಏಜೆಂಟ್ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳಲ್ಲಿ ಸಂಪೂರ್ಣ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ವೆಚ್ಚ-ಕಾರ್ಯಕ್ಷಮತೆಯ ಗಡಿ ಎರಡನ್ನೂ ಮುನ್ನಡೆಸುತ್ತದೆ. Perplexity Computer ಮತ್ತು Agent API ನೊಂದಿಗೆ ಇಂದಿನಿಂದ ಪ್ರಾರಂಭಿಸಿ, SaC ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ತರಲು ನಾವು ಉತ್ಸುಕರಾಗಿದ್ದೇವೆ. ನಮ್ಮ ಬಳಕೆದಾರರಿಗೆ (ಮತ್ತು ಅವರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವ ಏಜೆಂಟ್‌ಗಳಿಗೆ) ಸಾಧ್ಯವಾದಷ್ಟು ಶಕ್ತಿಶಾಲಿ ಮತ್ತು ಸಮರ್ಥ ಹುಡುಕಾಟ ಸಾಮರ್ಥ್ಯಗಳು ಇರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸ್ಟ್ಯಾಕ್‌ನ ಎಲ್ಲಾ ಪದರಗಳಲ್ಲಿ SaC ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ನಾವು ಆಪ್ಟಿಮೈಸ್ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ.

BibTeX

@online{perplexity2026RethinkingSearchAsCodeGeneration,
  author = {{Perplexity} and Denis Bykov and Aleksandr Nikolenko and Artur Zayats and Maksim Gaiduk and Vitalii Polshkov and Akshay Nair and James Liounis and Kirill Priemko and Ryan Buchmayer and Phi Hoang and Jerry Ma},
  title = {{Rethinking search as code generation}},
  date = {2026-06-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/rethinking-search-as-code-generation}
}

ಪರಿಚಯ

ಸಾಂಪ್ರದಾಯಿಕ ಹುಡುಕಾಟದ ಬಿಗಿತ

ಬಿಗಿತದಿಂದ ವಿಫಲತೆಯ ವಿಧಾನಗಳು

ಪ್ರೊಗ್ರಾಮ್ ಮಾಡಬಹುದಾದ ಹುಡುಕಾಟ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದು

Agentic Search SDK

ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ಗಳು

ಮಾದರಿಗಳು

ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಮತ್ತು ಗ್ಯಾಪ್ ಫಿಲ್ಲರ್ ಆಗಿ ಕೋಡ್

ಕೇಸ್ ಸ್ಟಡಿ: CVE ವೆಂಡರ್ ಸಲಹೆಗಳು

ಮೌಲ್ಯಮಾಪನ ಫಲಿತಾಂಶಗಳು

ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳು ಮತ್ತು ವ್ಯವಸ್ಥೆಗಳು

ಹೋಲಿಕೆಯ ಕಾರ್ಯಕ್ಷಮತೆ

ವೆಚ್ಚ-ಕಾರ್ಯಕ್ಷಮತೆಯ ಗಡಿ

ಕಂಪ್ಯೂಟಿಂಗ್‌ನ ಹೊಸ ಆರ್ಕಿಟೆಕ್ಚರ್ ಕಡೆಗೆ

ಉಲ್ಲೇಖ