Επανεξέταση της αναζήτησης ως παραγωγής κώδικα
Εξέλιξη της αναζήτησης από μονολιθικές υπηρεσίες σε προγραμματιζόμενα δομικά στοιχεία για την εποχή των εργαλείων πρακτόρων.
Η αναζήτηση αποτελεί βασικό δομικό στοιχείο για τα συστήματα τεχνητής νοημοσύνης. Τα κορυφαία μοντέλα γίνονται πιο ικανά από μήνα σε μήνα, αλλά εξακολουθούν να χρειάζονται πρόσβαση σε φρέσκια, ακριβή και καλά επιμελημένη γνώση από τον ευρύτερο κόσμο. Η αναζήτηση είναι ο κύριος τρόπος με τον οποίο τα συστήματα τεχνητής νοημοσύνης αξιοποιούν αυτή τη γνώση και, επομένως, αποτελεί θεμελιώδες στοιχείο οποιουδήποτε προϊόντος χρειάζεται να εξάγει συμπεράσματα, να αναλαμβάνει δράσεις και να εκτελεί εργασίες στον πραγματικό κόσμο.
Πιστεύουμε ότι οι παραδοσιακές ροές εργασίας αναζήτησης καθίστανται όλο και πιο παρωχημένες στην εποχή των πρακτόρων. Η παραδοσιακή αναζήτηση απαντά σε ερωτήματα, αλλά οι σημερινοί πράκτορες ολοκληρώνουν εργασίες που μπορούν να πάρουν αμέτρητες μορφές. Αυτές οι εργασίες απαιτούν από τους πράκτορες να καθορίζουν στρατηγικές ανάκτησης ειδικές για κάθε εργασία απευθείας εντός των εργαλείων τους. Στο Perplexity Computer, έχουμε δει μεμονωμένες εργασίες να επικαλούνται εκατοντάδες ή ακόμα και χιλιάδες λειτουργίες ανάκτησης μέσα σε λίγα λεπτά: μια ροή εργασίας που είναι αδύνατη για τους ανθρώπους αλλά απολύτως φυσική για τους πράκτορες.
Σε αυτόν τον κόσμο, η ίδια η αναζήτηση πρέπει να γίνει προγραμματιζόμενη, με τα δομικά της στοιχεία να είναι προσβάσιμα απευθείας ως SDK εντός του εργαλείου του πράκτορα. Παρουσιάζουμε το Search as Code (SaC) ως τη νέα αρχιτεκτονική αναζήτησης αναφοράς της Perplexity.
Εισαγωγή
Η στοίβα αναζήτησης της Perplexity εξυπηρετεί χιλιάδες ερωτήματα κάθε δευτερόλεπτο στις εφαρμογές μας και στην πλατφόρμα API. Τον Σεπτέμβριο του 2025, δημοσιεύσαμε την πρώτη αρχιτεκτονική επισκόπηση των συστημάτων αναζήτησης μας. Η διαρκής καινοτομία εντός αυτών των συστημάτων έχει υποστηρίξει την κυκλοφορία νέων προσφορών όπως το Search API, το Agent API και το Computer, με βρόχους αυτοβελτίωσης να βελτιστοποιούν τη στοίβα αναζήτησης ώστε να εξυπηρετεί καλύτερα τους χρήστες μέρα με τη μέρα.
Παραδοσιακά, τα συστήματα AI αντιμετώπιζαν την αναζήτηση ως μονολιθικό σύνολο: ένα μοντέλο AI εκτελεί ένα ερώτημα, η μηχανή αναζήτησης τρέχει την προκαθορισμένη της διοχέτευση και το μοντέλο καταναλώνει τα αποτελέσματα ως συμφραζόμενα. Στις περισσότερες περιπτώσεις, αυτό λειτούργησε αρκετά καλά ώστε να καλύψει τις ανάγκες των πρώτων χρηστών AI. Δεδομένης της σχετικής απλότητας των αιτημάτων τους, δεν υπήρχε λόγος να ανησυχούμε για το πώς ακριβώς είχε σχεδιαστεί η διοχέτευση αναζήτησης ή αν η αρχιτεκτονική της διοχέτευσης ήταν βέλτιστη για την εκάστοτε εργασία. Θεωρούσαμε ότι οι προεπιλογές ήταν αρκετά καλές, όπως και οι προεπιλεγμένες διεπαφές (function calling και MCPs).
Ωστόσο, σήμερα αυτή η προσέγγιση καθίσταται όλο και πιο παρωχημένη με κάθε μήνα που περνά. Οι χρήστες απαιτούν πολύ περισσότερα από την απλή ανάλυση μίας κλήσης από την τεχνητή νοημοσύνη. Αναμένουν από τους πράκτορες να ολοκληρώνουν εργασίες από άκρη σε άκρη σε διάστημα ωρών ή ακόμα και ημερών. Αυτές οι εργασίες μπορεί να είναι σύνθετες, ανοιχτού τύπου και εξαιρετικά μεταβλητές στις ανάγκες τους σε πληροφορίες, και οι μονολιθικές αρχιτεκτονικές υποχωρούν κάτω από το βάρος αυτών των απαιτήσεων.
Το βασικό εμπόδιο είναι τελικά θέμα ελέγχου. Τα κορυφαία μοντέλα είναι ήδη αρκετά καλά στο να συλλογίζονται πάνω σε σταθερό πλαίσιο. Ωστόσο, τα πιο ισχυρά συστήματα τεχνητής νοημοσύνης θα απαιτήσουν τη δυνατότητα κατεύθυνσης του τρόπου με τον οποίο ανακτάται, επεξεργάζεται, συγκεντρώνεται και αποδίδεται αυτό το πλαίσιο στο μοντέλο.
Τα παραδοσιακά συστήματα αναζήτησης δεν σχεδιάστηκαν με αυτόν τον βαθμό ελέγχου κατά νου. Εξάλλου, δεν μπορεί να αναμένεται από τους ανθρώπινους χρήστες να ασκούν λεπτομερή έλεγχο στα εσωτερικά της διοχέτευσης αναζήτησης, ακόμη κι αν τους δινόταν αυτή η δυνατότητα. Τα πρώιμα μοντέλα AI μπορούν να ελέγχουν την αναζήτηση μόνο μέσω μιας γραμμικής αλληλουχίας κλήσεων συναρτήσεων και MCPs. Όμως τα σημερινά πρωτοποριακά μοντέλα, που τροφοδοτούνται από agent harnesses με δυνατότητα κώδικα, μπορούν να ασκούν λεπτομερή έλεγχο σε οποιαδήποτε υπολογιστικά θεμελιώδη στοιχεία μπορείτε να φανταστείτε, μέσω κώδικα υπολογιστή. Το καθήκον μας γίνεται να παρέχουμε τα σωστά θεμελιώδη στοιχεία.
Για να καλύψουμε αυτή την ανάγκη, εισάγουμε μια νέα αρχιτεκτονική αναζήτησης σε όλα μας τα προϊόντα: Search as Code (SaC). Αυτή η νέα αρχιτεκτονική δίνει στα μοντέλα τη δυνατότητα να φτάνουν στο εσωτερικό της ίδιας της στοίβας αναζήτησης αντί να καταναλώνουν απλώς τα τελικά της αποτελέσματα. Η βασική ιδέα είναι απλή: εκθέτουμε τα συστατικά της στοίβας αναζήτησης ως δομικά στοιχεία εντός ενός SDK. Για οποιοδήποτε αίτημα χρειάζεται αναζήτηση, ένα μοντέλο συναρμολογεί αυτά τα στοιχεία κατά παραγγελία σε μια ροή ανάκτησης προσαρμοσμένη στο συγκεκριμένο αίτημα.
Η συναρμολόγηση αυτής της ροής γίνεται μέσω παραγωγής και εκτέλεσης κώδικα εντός ενός ασφαλούς Sandbox. Σε αντίθεση με άλλες προσεγγίσεις αναζήτησης που βασίζονται στη δημιουργία κώδικα, δεν τοποθετούμε απλώς ένα παραδοσιακό API αναζήτησης μέσα σε ένα κέλυφος ή χρόνο εκτέλεσης γλώσσας. Αντίθετα, έχουμε σχεδιάσει προσεκτικά ένα Agentic Search SDK που εκθέτει τα μεμονωμένα δομικά στοιχεία της αναζήτησης στο πιο ατομικό επίπεδο δυνατό.
Οπλισμένο με αυτά τα δομικά στοιχεία, το SaC δίνει στα μοντέλα άμεσο έλεγχο σε κάθε επιμέρους βήμα αναζήτησης: ανάκτηση, κατάταξη, φιλτράρισμα, διακλαδώσεις, απόδοση και πολλά άλλα. Επίσης, παρέχει στο μοντέλο αποτελεσματική πρόσβαση σε ενδιάμες καταστάσεις, όπως λίστες υποψηφίων και σήματα κατάταξης. Μαζί, αυτοί οι διπλοί μοχλοί ελέγχου και αναγνωσιμότητας επιτρέπουν στους πράκτορες να σχεδιάζουν προσαρμοσμένες ροές αναζήτησης που εκτείνονται σε χιλιάδες λειτουργίες ανάκτησης, να βελτιστοποιούν αυτές τις ροές εν κινήσει και να καταναλώνουν μόνο τις πιο χρήσιμες πληροφορίες ως πλαίσιο μοντέλου.
Αυτό το άρθρο περιγράφει τα κίνητρα, τον σχεδιασμό και την υλοποίηση του SaC, παράλληλα με εμπειρικά αποτελέσματα σε υπάρχοντα αλλά και νέα κριτήρια αξιολόγησης. Το SaC καθιερώνει ένα νέο όριο κόστους-απόδοσης για την αναζήτηση πρακτόρων και είμαστε ενθουσιασμένοι που το μοιραζόμαστε με τους χρήστες μας και την ευρύτερη κοινότητα τεχνητής νοημοσύνης.
Η ακαμψία της παραδοσιακής αναζήτησης
Οι πρώτες μηχανές αναζήτησης στον κόσμο κατασκευάστηκαν για ανθρώπινους χρήστες. Αυτοί οι χρήστες ανέμεναν μια προβλέψιμη εμπειρία, η οποία συνήθως αποτελείτο από έναν σταθερό αριθμό εγγράφων ταξινομημένων κατά συνάφεια. Οι χρήστες δεν ήθελαν να διαχειρίζονται μικρολεπτομερώς τη διαδικασία αναζήτησης· ήθελαν να εισάγουν ένα ερώτημα και να βρίσκουν ένα χρήσιμο αποτέλεσμα.
Ως αποτέλεσμα, οι μηχανές αναζήτησης για ανθρώπους συγκλίνονταν σε μια κοινή μονολιθική αρχιτεκτονική, προσανατολισμένη στην παραγωγή φιλικών προς τον χρήστη σελίδων αποτελεσμάτων μηχανών αναζήτησης (SERP) που περιέχουν τα κορυφαία n αποτελέσματα για ένα ερώτημα εισόδου. Αυτό το μοτίβο έχει τροφοδοτήσει δεκαετίες προόδου στην καταναλωτική αναζήτηση. Είναι γρήγορο, οικείο και εξαιρετικά αποτελεσματικό για την ανθρώπινη περιήγηση.
Στη συνέχεια ήρθαν τα LLM, και τα συστήματα τεχνητής νοημοσύνης έγιναν επίσης καταναλωτές αναζήτησης. Η Perplexity πρωτοστάτησε σε αυτήν τη στροφή με την κυκλοφορία της μηχανής απαντήσεών μας το 2022. Έκτοτε, οι προσπάθειές μας στη μηχανική αναζήτησης έχουν επικεντρωθεί στο πώς να βελτιστοποιήσουμε την αξία των αποτελεσμάτων αναζήτησης για τα μοντέλα τεχνητής νοημοσύνης. Για να κατασκευάσουμε την πιο ακριβή και αξιόπιστη τεχνητή νοημοσύνη στον κόσμο, έπρεπε να σχεδιάσουμε ένα σύστημα αναζήτησης που εστιάζει στο να κάνει κάθε διακριτικό (token) όσο το δυνατόν πιο πυκνό σε πληροφορίες. Οι επακόλουθες καινοτομίες στην ανάκτηση υποεγγράφων, την αποδοτικότητα πλαισίου, τη σημασιολογική κατανόηση και άλλους βασικούς τομείς οδήγησαν σε δραματικές βελτιώσεις στη δυνατότητα των συστημάτων τεχνητής νοημοσύνης να ανακτούν πληροφορίες και να ενεργούν βάσει αυτών.
Ωστόσο, ακόμη και τα συστήματα που είναι βελτιστοποιημένα για τεχνητή νοημοσύνη έχουν σε μεγάλο βαθμό κληρονομήσει το ίδιο θεμελιώδες συμβόλαιο με τις παραδοσιακές μηχανές αναζήτησης: αποδοχή ενός ερωτήματος, εκτέλεση μιας προκαθορισμένης ροής αναζήτησης, επιστροφή ενός πλήρως επεξεργασμένου συνόλου αποτελεσμάτων. Για απλά αιτήματα, αυτή η προσέγγιση λειτουργεί καλά. Αλλά για πιο σύνθετα αιτήματα, αυτό γίνεται ένα ολοένα και πιο περιοριστικό εμπόδιο που υποβαθμίζει την απόδοση, την καθυστέρηση και το κόστος.
Λειτουργίες αποτυχίας λόγω ακαμψίας
Οι παραδοσιακές ροές αναζήτησης είναι σχεδιασμένες γύρω από ένα ενιαίο σημείο ελέγχου: τις παραμέτρους ερωτήματος. Η μηχανή αναζήτησης κατέχει την υπόλοιπη ροή σύμφωνα με την προκαθορισμένη λογική της και το μοντέλο πρέπει να προσαρμοστεί σε αυτήν. Για το μοντέλο, οτιδήποτε βρίσκεται μεταγενέστερα των παραμέτρων ερωτήματος είναι άκαμπτο — η μορφή του πραγματικού υπολογισμού είναι εκτός του ελέγχου του μοντέλου.
Αυτό είναι ένα λογικό όριο όταν ο καταναλωτής είναι ένας άνθρωπος που σαρώνει συνδέσμους. Είναι ένα κακό όριο όταν ο καταναλωτής είναι ένα μοντέλο τεχνητής νοημοσύνης που προσπαθεί να λύσει εργασίες έντασης γνώσης σε έναν κλειστό βρόχο. Κατά την εμπειρία μας, αυτή η ακαμψία δημιουργεί τρεις επαναλαμβανόμενες λειτουργίες αποτυχίας:
Χονδροειδές περιεχόμενο. Τα μοντέλα AI είναι ευαίσθητα στην ποιότητα και τη συμπαγή μορφή του περιεχομένου. Τόσο η ποιότητα όσο και η συμπαγής μορφή εξαρτώνται σε πολύ μεγάλο βαθμό από το ερώτημα, και οι μονολιθικές διοχετεύσεις αναζήτησης δεν έχουν σχεδιαστεί ώστε να αποδίδουν βέλτιστα σε όλα τα ερωτήματα. Για παράδειγμα, αν ένα μοντέλο χρειάζεται μία μόνο, εξαιρετικά στοχευμένη πληροφορία αλλά έχει πρόσβαση μόνο σε ένα end-to-end τελικό σημείο αναζήτησης που δίνει προτεραιότητα στην ανάκληση, η χρήση αυτού του τελικού σημείου θα εισαγάγει μεγάλη ποσότητα άσχετων πληροφοριών στο περιεχόμενο του μοντέλου. Από την άλλη πλευρά, αν ένα μοντέλο χρειάζεται πολλές πληροφορίες, καθεμία από τις οποίες απαιτεί διαφορετικές στρατηγικές αναζήτησης, μπορεί να αναγκαστεί να καλεί σειριακά την ίδια μη βέλτιστη διοχέτευση για όλες, με αποτέλεσμα αυξανόμενα κόστη και θορυβώδες περιεχόμενο.
Αδυναμία αξιοποίησης της γνώσης του πεδίου. Σε πολλές περιπτώσεις, το μοντέλο μπορεί να διαθέτει γνώση του πεδίου (από την εκπαίδευσή του, μια δεξιότητα Agent, τη μνήμη ή προηγούμενα tokens στην τροχιά του LLM) που θα έπρεπε να καθοδηγεί τη στρατηγική αναζήτησης. Ωστόσο, μια άκαμπτη διεπαφή αναζήτησης εμποδίζει το μοντέλο να αξιοποιήσει αυτή τη γνώση. Για παράδειγμα, το μοντέλο μπορεί να αντιληφθεί για ένα συγκεκριμένο αίτημα ότι θα πρέπει να συνδυάσει λεξικά και σημασιολογικά σήματα με έναν συγκεκριμένο τρόπο, να δώσει προτεραιότητα σε ορισμένες πηγές ή να ομαδοποιήσει τα αποτελέσματα με βάση ένα συγκεκριμένο κλειδί. Εκτός αν αυτές οι ιδέες μπορούν πράγματι να υλοποιηθούν μέσω παραμέτρων ερωτήματος, το μοντέλο δεν μπορεί να δράσει βάσει αυτών.
Ανεπαρκής ροή ελέγχου και ρύπανση του περιεχομένου. Πολλές ροές αναζήτησης δεν είναι εκ φύσεως σειριακές. Μπορεί να χρειάζονται διακλάδωση σε παραλλαγές ερωτημάτων, παράλληλη ανάκτηση, αποδιπλοποίηση και άλλες λειτουργίες που απαιτούν μη γραμμική και ασύγχρονη ροή ελέγχου. Η επιβολή αυτών των βημάτων μέσω επαναλαμβανόμενων γύρων του μοντέλου προσθέτει καθυστέρηση και δυσκολεύει τη βελτιστοποίηση της ροής εργασίας. Επίσης, ρυπαίνει το περιεχόμενο του μοντέλου με θορυβώδη ενδιάμεση κατάσταση που μπορεί να μην είναι χρήσιμη για τη συλλογιστική του μοντέλου, με αποτέλεσμα χαμηλότερη απόδοση και συχνότερες συμπτύξεις.
Δεν μπορούσαν να γίνουν πολλά για αυτές τις προκλήσεις κατά τις εποχές του function calling & MCP στην AI. Όταν κάθε λειτουργία αναζήτησης απαιτεί τη δική της επιστροφή στο LLM inference, οι προγραμματιστές προτιμούν φυσικά να ολοκληρώνουν όσο το δυνατόν περισσότερα σε αυτή την επιστροφή. Αυτό σημαίνει end-to-end διοχετεύσεις αναζήτησης που επιστρέφουν πλήρως επεξεργασμένα σύνολα αποτελεσμάτων για άμεση κατανάλωση από ένα μοντέλο.
Ως αποτέλεσμα, τα περισσότερα συστήματα αναζήτησης με προσανατολισμό στην τεχνητή νοημοσύνη εξακολουθούν να λειτουργούν υπό αυτό το μονολιθικό συμβόλαιο. Ωστόσο, με τη συνεχή αύξηση της ευφυΐας των μοντέλων και των απαιτήσεων των χρηστών, τα ελαττώματα αυτού του συμβολαίου γίνονται πιο έντονα. Τα πιο προηγμένα συστήματα τεχνητής νοημοσύνης σήμερα, χτισμένα πάνω σε εργαλεία πρώτου κώδικα, μπορούν να συνθέτουν ροές εργασίας ειδικές για κάθε εργασία που εκτελούν χιλιάδες ενέργειες κάθε λεπτό. Τα συστήματα αναζήτησης δεν έχουν ακόμη αξιοποιήσει πλήρως αυτή την προοπτική.
Υποψιαζόμαστε εδώ και καιρό ότι το σωστό όριο για την εγγενή στην τεχνητή νοημοσύνη αναζήτηση βρίσκεται χαμηλότερα στη στοίβα. Τα μοντέλα δεν θα έπρεπε απλώς να καλούν μια μηχανή αναζήτησης. Θα έπρεπε να μπορούν να ορχηστρώνουν τα επιμέρους κομμάτια της στοίβα αναζήτησης όπως απαιτεί η συγκεκριμένη εργασία. Αυτό απαιτεί μια θεμελιωδώς διαφορετική αρχιτεκτονική.
Σχεδιασμός μιας προγραμματιζόμενης αρχιτεκτονικής αναζήτησης
Η επόμενη γενιά αρχιτεκτονικών αναζήτησης θα βασιστεί σε μια βασική αρχή: η αναζήτηση θα πρέπει να είναι εγγενώς προγραμματιζόμενη από πράκτορες τεχνητής νοημοσύνης. Ένας πράκτορας δεν πρέπει να περιορίζεται σε ένα σύνολο προκαθορισμένων ροών αναζήτησης. Αντίθετα, ένας πράκτορας πρέπει να μπορεί να κατασκευάζει τη ροή που απαιτεί η συγκεκριμένη εργασία, χρησιμοποιώντας συνθέσιμα δομικά στοιχεία σχεδιασμένα σε διάφορα επίπεδα αφαίρεσης.
Η νέα μας αρχιτεκτονική Search as Code (SaC) ενσαρκώνει αυτή την αρχή. Στο SaC, ούτε μία λειτουργία ανάκτησης δεν αποστέλλεται μέσω διεπαφής function calling ή MCP. Αντίθετα, όλες οι λειτουργίες συντονίζονται μέσω κώδικα Python που παράγει το μοντέλο. Για τις απλούστερες ανάγκες αναζήτησης, αυτός ο κώδικας μπορεί να αποτελείται από λίγα αιτήματα προς ένα τελικό σημείο αναζήτησης υψηλού επιπέδου. Όμως για σύνθετες εργασίες, ο κώδικας μπορεί να είναι όσο περίπλοκος χρειάζεται, περιλαμβάνοντας υπό συνθήκη εκτέλεση, ασυγχρονία, παραλληλία και κλήσεις σε ένα ευρύ φάσμα θεμελιωδών στοιχείων χαμηλού επιπέδου.
Το SaC περιλαμβάνει τρία στενά συνδεδεμένα επίπεδα:
Τα μοντέλα χρησιμεύουν ως επίπεδο ελέγχου. Συλλογίζονται σχετικά με την οδηγία του χρήστη (ή του γονικού πράκτορα), αποσυνθέτουν την οδηγία σε εργασίες, αποφασίζουν ποιες ροές ανάκτησης και επεξεργασίας απαιτούνται για κάθε εργασία και παράγουν κώδικα για την υλοποίηση αυτών των ροών.
Τα Sandbox υπολογισμών παρέχουν ντετερμινιστικό υπολογισμό μέσω ενός ασφαλούς χρόνου εκτέλεσης κώδικα. Παρέχουν έναν καμβά για τα μοντέλα ώστε να υλοποιούν ροή ελέγχου, ομαδοποίηση, επαναλήψεις, φιλτράρισμα, συνένωση, συγκέντρωση και άλλες ντετερμινιστικές λειτουργίες.
Το Agentic Search SDK μας εκθέτει τη στοίβα αναζήτησης της Perplexity ως συνθέσιμα δομικά στοιχεία. Παρέχει δομικά στοιχεία από λειτουργίες ανάκτησης χαμηλού επιπέδου έως σημασιολογική ανάλυση υψηλού επιπέδου. Το SDK είναι ενσωματωμένο στους χρόνους εκτέλεσης των sandbox, επιτρέποντας στα μοντέλα να ορχηστρώνουν έως και χιλιάδες λειτουργίες μέσα σε μία μόλις στροφή συμπερασσολογίας. Παρακάτω, συζητάμε τις αποφάσεις σχεδιασμού μας για κάθε επίπεδο.
Το Agentic Search SDK
Το Agentic Search SDK καθορίζει τα δομικά στοιχεία για την προγραμματιζόμενη αναζήτηση. Σημαντικό είναι ότι το SDK μας δεν είναι ένα προϋπάρχον API αναζήτησης συσκευασμένο ως βιβλιοθήκη. Τους τελευταίους μήνες, η ομάδα μηχανικών μας έχει ανασχεδιάσει τη στοίβα αναζήτησης μας σε αρθρωτά, συνθέσιμα δομικά στοιχεία. Έχουμε κατασκευάσει το Agentic Search SDK για να παρέχει άμεση πρόσβαση σε αυτά τα δομικά στοιχεία, δημιουργώντας έναν πολύ πιο ισχυρό καμβά στον οποίο το μοντέλο μπορεί να ορχηστρώσει ροές ανάκτησης ειδικές για κάθε εργασία.
Οι υψηλού επιπέδου ροές αναζήτησης από άκρη σε άκρη εξακολουθούν να είναι διαθέσιμες εντός του SDK, αλλά δεν αποτελούν πλέον τη μοναδική επιλογή. Αντίθετα, χρησιμεύουν ως μια μορφή σύντμησης για συνήθη μοτίβα αναζήτησης. Το μοντέλο είναι ελεύθερο να τα χρησιμοποιήσει ή να τα παρακάμψει όπως απαιτεί η εργασία.
Επιλογή χρόνου εκτέλεσης: Εξετάσαμε την Python, τη Rust, την TypeScript και τη Bash ως τον χρόνο εκτέλεσης του SDK. Υποψιαζόμαστε ότι η Python θα ήταν η πιο φυσική επιλογή δεδομένης της πανταχού παρουσίας της και του οικοσυστήματος βιβλιοθηκών επεξεργασίας δεδομένων. Οι εσωτερικές δοκιμές επιβεβαίωσαν ότι αυτό ισχύει, και η έκδοση του SDK που κυκλοφορεί σήμερα βασίζεται στην Python. Αναμένουμε να επανεκτιμούμε περιοδικά την επιλογή του χρόνου εκτέλεσης για να διασφαλίσουμε ότι συνεχίζει να παρέχει την καλύτερη εμπειρία πράκτορα.
Συνεχής βελτίωση μέσω αυτόματης έρευνας (autoresearch): Έχουμε επίσης βελτιστοποιήσει τη δυνατότητα κατανάλωσης του SDK για κορυφαία LLM μέσω ενός επαναληπτικού βρόχου αυτόματης έρευνας. Αυτός ο βρόχος, που εκτελείται συνεχώς επί εβδομάδες, προτείνει και επικυρώνει βελτιώσεις του SDK έναντι μετρικών που περιλαμβάνουν την καθυστέρηση, την ποιότητα παραγωγής κώδικα και τη συνολική απόδοση εργασιών. Ο βρόχος αυτόματης έρευνας έχει ήδη κάνει πολυάριθμες αλλαγές τόσο στη δομή όσο και στην αισθητική του SDK, με σημαντικά κέρδη σε όλες τις διαστάσεις. Σχεδιάζουμε να βελτιώσουμε περαιτέρω το SDK μέσω αυτόματης έρευνας καθώς αναδύονται νέα κορυφαία μοντέλα και στοιχεία αναζήτησης.
Sandbox
Τα Sandbox παρέχουν ασφαλή περιβάλλοντα για τον καθρισμό και την εκτέλεση ροών SaC. Εκτελούν κώδικα που παράγεται από το μοντέλο, παρέχοντας πρόσβαση στο Agentic Search SDK για τη διευκόλυνση της αλληλεπίδρασης με μεμονωμένα δομικά στοιχεία αναζήτησης.
Έχουμε πραγματοποιήσει σημαντικές επενδύσεις στη βελτιστοποίηση και θωράκιση των sandbox μας, και ο συνολικός σχεδιασμός του συστήματός τους αξίζει ένα άρθρο από μόνος του. Εδώ, εστιάζουμε στη σχεδιαστική εκτίμηση που σχετίζεται περισσότερο με το SaC: τη διαχείριση ενδιάμεσων καταστάσεων.
Το SaC δίνει τη δυνατότητα στους πράκτορες να ορχηστρώνουν σύνθετες ροές μέσα σε μία μόνο στροφή συμπερασσολογίας. Ωστόσο, ορισμένες ενδιάμεσες καταστάσεις πρέπει να μεταφερθούν σε πολλαπλές στροφές. Για παράδειγμα, ένα μοντέλο μπορεί να θέλει να ανακτήσει ορισμένα έγγραφα στη στροφή 1, να επιθεωρήσει ένα υποδείγμα αυτών των εγγράφων στη στροφή 2 για να αποφασίσει τι να κάνει στη συνέχεια, και στη συνέχεια να αναπτύξει μια μεταγενέστερη ροή αναζήτησης για να διερευνήσει περαιτέρω αυτά τα έγγραφα από τη στροφή 3 και έπειτα. Όπως συζητήθηκε παραπάνω, η μεταβίβαση ενδιάμεσων καταστάσεων μέσω του Χώρος των διακριτικών δεν είναι αποτελεσματική στρατηγική.
Εξετάσαμε δύο προσεγγίσεις για τη διαχείριση ενδιάμεσων καταστάσεων σε πολλαπλές στροφές:
Επίμονο σύστημα αρχείων + ρητή σειριοποίηση/αποσειριοποίηση (serde): Τα sandbox μπορούν να εκθέτουν επίμονα συστήματα αρχείων για χρήση από τα μοντέλα σε πολλαπλές στροφές. Τα μοντέλα που επιθυμούν να διατηρήσουν την ενδιάμεση κατάσταση μπορούν να συμπεριλάβουν ένα βήμα σειριοποίησης στον παραγόμενο κώδικα για μια στροφή, μαζί με ένα βήμα αποσειριοποίησης σε μια μεταγενέστερη στροφή (είτε για δική τους επιθεώρηση είτε για μεταγενέστερη χρήση). Η προσέγγιση του συστήματος αρχείων επιτρέπει στα μοντέλα να ελέγχουν άμεσα και ρητά τον τρόπο με τον οποίο η ενδιάμεση κατάσταση μεταφέρεται σε πολλαπλές στροφές. Διασφαλίζει επίσης την ανιχνευσιμότητα επιβάλλοντας ρητή αναγνώριση και διατήρηση των πληροφοριών που χρησιμοποιούνται από το μοντέλο. Ένα μειονέκτημα είναι η καθυστέρηση & το επιπλέον κόστος πλαισίου που προκύπτει από τη δημιουργία του κώδικα serde, αν και οι καλά σχεδιασμένες λειτουργίες βοηθητικού προγράμματος μπορούν να μετριάσουν αυτό το κόστος.
REPL: Εναλλακτικά, ένα sandbox μπορεί να διατηρήσει τον ίδιο τον χρόνο εκτέλεσης σε πολλαπλές στροφές σε ένα περιβάλλον τύπου REPL. Αυτό επιτρέπει στα μοντέλα να διατηρούν την ενδιάμεση κατάσταση στη μνήμη χωρίς να χρειάζεται να τη σειριοποιήσουν καθόλου, καθώς οι μεταβλητές που ορίζονται ή τροποποιούνται σε προηγούμενες στροφές μπορούν απλώς να αναφερθούν με το όνομα σε επόμενες στροφές. Η προσέγγιση REPL είναι πιο αποδοτική σε διακριτικά, καθώς αποφεύγει την ανάγκη παραγωγής κώδικα serde. Ωστόσο, η απουσία ενός ρητού βήματος σειριοποίησης μπορεί να βλάψει τη μεταγενέστερη απόδοση για λόγους οικείους σε όποιον έχει εργαστεί με ένα σημειωματάριο Jupyter 100 κελιών: καθώς ο χώρος ονομάτων μεταβλητών γεμίζει, γίνεται δυσκολότερο να παρακολουθεί κανείς τι ακριβώς διατηρείται στις στροφές και γιατί.
Δοκιμάσαμε και τις δύο προσεγγίσεις και διαπιστώσαμε ότι, ενώ αποδίδουν παρόμοια στην κανονική χρήση, η σειριοποίηση βασισμένη σε σύστημα αρχείων παρέχει καλύτερη αξιοπιστία σε ιδιαίτερα μεγάλες τροχιές. Επομένως, υιοθετούμε τη σειριοποίηση βάσει συστήματος αρχείων ως λύση μας. Υποθέτουμε ότι η απαίτηση από τα μοντέλα να μεταφέρουν την κατάσταση δηλωτικά και όχι σιωπηρά τα βοηθά να διαχειρίζονται αυτή την κατάσταση πιο αποτελεσματικά. Αυτό είναι ένα προσωρινό εύρημα και θα συνεχίσουμε να επαναλαμβάνουμε και τις δύο προσεγγίσεις.
Μοντέλα
Τα μοντέλα που τροφοδοτούν τα εργαλεία πρακτόρων χρησιμεύουν ως επίπεδο ελέγχου του SaC: συναρμολογούν δυναμικά ροές αναζήτησης από τα δομικά στοιχεία του Agentic Search SDK για να καλύψουν τις ανάγκες κάθε εργασίας, αποστέλλοντας στη συνέχεια αυτές τις ροές ως κώδικα για εκτέλεση στο sandbox.
Η Perplexity απασχολεί μια ποικιλία μοντέλων εντός των εργαλείων πρακτόρων μας, και έχουμε διαπιστώσει ότι τα πιο πρόσφατα κορυφαία μοντέλα είναι αρκετά αποτελεσματικά σε όλο το φάσμα στη γενικής χρήσης παραγωγή κώδικα. Η κύρια πρόκληση είναι η προτροπή αποτελεσματικής παραγωγής κώδικα ειδικά για το Agentic Search SDK. Δηλαδή, πώς μπορούμε να κάνουμε τα μοντέλα να συνυφαίνουν αποτελεσματικά τα δομικά στοιχεία του SDK μας σε ροές βελτιστοποιημένες για την εργασία;
Σε αντίθεση με την τυπική βιβλιοθήκη μιας γλώσσας, ένα SDK προσαρμοσμένης κατασκευής είναι απίθανο να εκπροσωπείται στα δεδομένα προεκπαίδευσης. Ακόμη και με τις βελτιώσεις στη χρηστικότητα των SDK από το autoresearch, πολλά μοντέλα εξακολουθούν να εκπαιδεύονται να αλληλεπιδρούν με συστήματα αναζήτησης μέσω κλήσεων συναρτήσεων και άμεσης κλήσης MCP. Είναι απίθανο αυτά τα μοντέλα να χρησιμοποιήσουν με δεξιοτεχνία το SDK μόνο με πηγαίο κώδικα και αυτόματα παραγόμενη τεκμηρίωση.
Για να λύσουμε αυτή την πρόκληση, έχουμε αναπτύξει εξαιρετικά συντονισμένες δεξιότητες πράκτορα για να διδάξουμε στα μοντέλα να αξιοποιούν αποτελεσματικά το SDK μας. Οι αρχικές εκδόσεις αναπτύχθηκαν σύμφωνα με τις αρχές σχεδιασμού της Perplexity για δεξιότητες και στη συνέχεια βελτιστοποιήθηκαν μέσω ενός αφοσιωμένου βρόχου αυτόματης έρευνας που επικεντρώνεται στις ίδιες μετρικές που χρησιμοποιούνται στη βελτιστοποίηση του SDK. Περιορίζουμε επίσης το μέγεθος των δεξιοτήτων για προστασία από τη διόγκωση του πλαισίου, και οι τελικές μας εκδόσεις έχουν λιγότερα από 2000 διακριτικά στα βασικά τους αρχεία SKILL.md.
Οι βελτιστοποιημένες δεξιότητες υπερβαίνουν την απλή απαρίθμηση των διαθέσιμων δομικών στοιχείων του SDK (κάτι που μπορεί εξίσου εύκολα να αποκτηθεί μέσω ανάκλασης χρόνου εκτέλεσης). Ο κύριος όγκος των διακριτικών αφιερώνεται στην παροχή συνοπτικής, γενικεύσιμης καθοδήγησης και παραδειγμάτων λίγων λήψεων για τη σύνθεση αυτών των μπλοκ σε σύνθετα μοτίβα. Οπλισμένα με αυτές τις δεξιότητες, παρατηρούμε τα μοντέλα να αξιοποιούν αποτελεσματικά το SDK για να ορχηστρώνουν ροές αναζήτησης που κλιμακώνονται σε χιλιάδες διακριτές λειτουργίες.
Ο κώδικας ως ερχεστρωτής και συμπληρωτής κενών
Συνδυάζοντας αυτά τα επίπεδα, το SaC αλλάζει τη σχέση μεταξύ των μοντέλων και της στοίβας αναζήτησης. Στα συστήματα αναζήτησης σταθερής ροής, το μοντέλο κάθεται πάνω από την αναζήτηση και αλληλεπιδρά με αυτήν μέσω μιας στενής διαδοχικής διεπαφής κλήσης. Στο SaC, το μοντέλο γίνεται ενεργός συμμετέχων στην ορχήστρωση της ίδιας της διαδικασίας αναζήτησης. Όλα τα στοιχεία της στοίβας αναζήτησης γίνονται άμεσα προγραμματιζόμενα από το μοντέλο, με το sandbox και το Agentic Search SDK να παρέχουν τις απαραίτητες διεπαφές σε αυτά τα στοιχεία.
Τι γίνεται όμως με δυνατότητες που δεν υπάρχουν εγγενώς; Ο κώδικας είναι ένα ισχυρό μέσο για την ορχήστρωση προϋπάρχοντων δυνατοτήτων. Ωστόσο, η δύναμη του κώδικα υπερβαίνει την ορχήστρωση. Μπορεί επίσης να χρησιμεύσει ως συμπληρωτής κενών για δυνατότητες που δεν υπάρχουν στη στοίβα αναζήτησης ή στο SDK. Οι πράκτορες επωφελούνται από τη φειδωλότητα, και θα ήταν αναποτελεσματικό για το SDK να καλύπτει κάθε πιθανή λειτουργία με μια αποκλειστική συνάρτηση. Αντίθετα, το SDK παρέχει τα πιο θεμελιώδη δομικά στοιχεία και το μοντέλο μπορεί να κατασκευάσει τυχόν επιπλέον στοιχεία εν κινήσει με κώδικα.
Εξετάστε, για παράδειγμα, μια σύνθετη κανονική έκφραση (regex) που δεν μπορεί να υλοποιηθεί αποδοτικά μέσω της σύνταξης ερωτημάτων του ίδιου του συστήματος αναζήτησης. Χωρίς δυνατότητες κωδικοποίησης, το μοντέλο θα αναγκαζόταν να παράγει την καλύτερη προσέγγισή του, να κάνει ένα ερώτημα και να εκτελέσει φιλτράρισμα χώρου διακριτικών σε ένα πολύ θορυβώδες σύνολο αποτελεσμάτων. Με το SaC, το μοντέλο μπορεί αντίθετα να παράγει ένα πρόγραμμα που κάνει παράλληλες κλήσεις SDK για να συλλέξει ένα υπερσύνολο του συνόλου αποτελεσμάτων της επιθυμητής regex. Μετά την αποδιπλοίωση μέσω του SDK, το μοντέλο μπορεί στη συνέχεια να γράψει επιπλέον κώδικα για να περιορίσει ντετερμινιστικά τα αποτελέσματα στην ακριβή regex. Με αυτόν τον τρόπο, οι πράκτορες μπορούν να υλοποιήσουν προσαρμοσμένες δυνατότητες αναζήτησης χωρίς να διογκώνουν το SDK με υπερβολικά εξειδικευμένες υπορουτίνες.
Μελέτη περίπτωσης: Συμβουλευτικά δελτία προμηθευτών CVE
Παρουσιάζουμε μια μελέτη περίπτωσης βασισμένη σε μια πραγματική εργασία μέσα στη σουίτα δοκιμών μας. Αυτή η εργασία ζητά από έναν Πράκτορα να εντοπίσει και να χαρακτηρίσει πάνω από 200 CVEs υψηλής σοβαρότητας από το 2023–2025. Κάθε εγγραφή πρέπει να παραπέμπει στη δική του ανακοίνωση του επηρεαζόμενου προμηθευτή, να ονομάζει το προϊόν και την έκδοση επιδιόρθωσης και να δείχνει ότι η έκδοση επιδιόρθωσης συνδέεται με το συγκεκριμένο CVE.
Η απάντηση του SaC σημείωσε 100% στην ακρίβεια, με τη συνολική χρήση διακριτικών να μειώνεται κατά 85,1% σε σχέση με τη βασική γραμμή χωρίς SaC (από 288,7K διακριτικά σε 42,9K διακριτικά). Τα δοκιμασμένα συστήματα εκτός Perplexity, που συζητούνται πιο αναλυτικά στην Ενότητα 4, σημείωσαν όλα βαθμολογία χαμηλότερη από 25%.
Παρουσιάζουμε τρία τυποποιημένα μπλοκ κώδικα από την τροχιά για να δείξουμε πώς ο προγραμματισμός του SaC επιτρέπει στο μοντέλο να υλοποιεί αποτελεσματικές στρατηγικές.
# 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 που απαιτούνται παρακάτω.
# 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 ως ενδιάμεση υπορουτίνα σχεδιασμού. Ο κώδικας συνοψίζει ποια ζεύγη προμηθευτή-έτους παράγουν αρκετές σελίδες υποψηφίων, ζητά στοχευμένες βελτιώσεις και επικυρώνει κάθε προτεινόμενο ερώτημα πριν από την εκτέλεση. Αυτό διατηρεί χρήσιμα μοτίβα από την τροχιά, όπως ανιχνεύσεις ακριβούς φράσης με πεδίο ιστότοπου και προσαρμοστική συμπλήρωση, χωρίς να ενσωματώνεται σκληρά (hardcoding) ένα προσαρμοσμένο πρόγραμμα ανίχνευσης συμβουλευτικών δελτίων CVE στο SDK.
# 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")Το τελικό μπλοκ είναι ένας επαληθευτής αποτελεσμάτων του οποίου η λογική ορίζεται εξ ολοκλήρου από τον πράκτορα μέσω παραγωγής κώδικα. Ενώ οι υπορουτίνες αναζήτησης μπορούν να βρουν πιθανές σελίδες συμβουλευτικών δελτίων, η εργασία απαιτεί μια αυστηρότερη σχέση: το συμβουλευτικό δελτίο πρέπει να συνδέει ένα CVE με ένα επηρεαζόμενο προϊόν και μία έκδοση διόρθωσης σε κείμενο συνταγμένο από τον προμηθευτή. Το σχήμα καθιστά αυτή τη σχέση ρητή, ώστε ο μεταγενέστερος κώδικας να μπορεί να κάνει αποδιπλοίωση ανά CVE, να απορρίπτει διευθύνσεις URL aggregator, να απορρίπτει ασθενή αποδεικτικά στοιχεία έκδοσης και να συνεχίζει τη συμπλήρωση έως ότου επιτευχθεί το κατώτατο όριο πλήθους εγγραφών.
Αποτελέσματα αξιολόγησης
Αξιολογούμε την αποτελεσματικότητα του SaC σε μια ολοκληρωμένη σουίτα συγκριτικής αξιολόγησης, εστιάζοντας τόσο στην απόλυτη απόδοση όσο και στο όριο κόστους-απόδοσης.
Κριτήρια αξιολόγησης και συστήματα
Η σουίτα συγκριτικής αξιολόγησης περιλαμβάνει συνολικά πέντε κριτήρια αξιολόγησης, σχεδιασμένα να υποβάλλουν σε δοκιμασία καταπόνησης ροές εργασίας τεχνητής νοημοσύνης που εξαρτώνται από την αναζήτηση σε διάφορους τομείς, μορφές εργασιών και επίπεδα πολυπλοκότητας. Χρησιμοποιούμε τέσσερα προϋπάρχοντα κριτήρια αξιολόγησης: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE) και WideSearch. Για τα τρία πρώτα κριτήρια αξιολόγησης (DSQA, BrowseComp και HLE), αναφέρουμε την ακρίβεια ως βασική μέτρηση. Για το WideSearch, αναφέρουμε το σκορ F1 ανά γραμμή.
Χρησιμοποιούμε επίσης το νεοαναπτυχθέν κριτήριο αξιολόγησης WANDR, το οποίο εστιάζει σε δύσκολες εργασίες «ευρείας έρευνας» που απαιτούν προσεκτική ορχήστρωση αναζήτησης, υπολογισμών και συλλογισμού μοντέλου. Το WANDR εμπνέεται από τις επαγγελματικές εργασίες έντασης γνώσης που χειρίζεται το Perplexity Computer για τους χρήστες. Επαναλαμβάνει το WideSearch και παρόμοια κριτήρια αξιολόγησης, αλλά δίνει έμφαση σε πιο σύνθετες εργασίες και δομές εργασιών. Θα δημοσιεύσουμε το κριτήριο αξιολόγησης WANDR τις επόμενες εβδομάδες.
Αξιολογούμε πέντε συστήματα που βασίζονται σε πράκτορες. Εξετάζουμε μεμονωμένες εκτελέσεις παρά βαθμολογίες «καλύτερου από N» προκειμένου να απομονώσουμε την απόδοση της υποκείμενης αρχιτεκτονικής αντί των οφελών του παραλληλισμού. Η διαμόρφωση κάθε συστήματος περιγράφεται παρακάτω:
Perplexity (SaC): Αξιολογούμε την αρχιτεκτονική SaC εντός του API παραγωγής Agent API της Perplexity. Το GPT 5.5 (υψηλού συλλογισμού) χρησιμεύει ως το υποκείμενο μοντέλο.
OpenAI: Αξιολογούμε το Responses API της OpenAI με ενεργοποιημένη τόσο την αναζήτηση (web_search) όσο και τον χρόνο εκτέλεσης Python (code_interpreter). Το GPT 5.5 (υψηλού συλλογισμού) χρησιμεύει ως το υποκείμενο μοντέλο.
Anthropic: Αξιολογούμε τα Managed Agents της Anthropic με το σύνολο εργαλείων πράκτορα 20260401 και τις αυτόματα επιτρεπόμενες εντολές. Το Opus 4.7 (υψηλού συλλογισμού) χρησιμεύει ως το υποκείμενο μοντέλο.
Exa: Αξιολογούμε το Exa Agent μέσω του API παραγωγής, με την προσπάθεια ρυθμισμένη σε υψηλή.
Parallel: Αξιολογούμε τις Parallel Tasks μέσω του API παραγωγής, με τον επεξεργαστή ρυθμισμένο σε ultra4x.
Σγκριτική απόδοση
Ο Πίνακας 1 αναφέρει τις βαθμολογίες συγκριτικής αξιολόγησης για κάθε σύστημα. Το SaC ξεπερνά όλα τα άλλα συστήματα σε τέσσερα από τα πέντε κριτήρια αξιολόγησης. Στο υπόλοιπο κριτήριο αξιολόγησης (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 επιτυγχάνει κορυφαία απόδοση σε όλη τη σουίτα συγκριτικής αξιολόγησης, το πλεονέκτημά του είναι ιδιαίτερα έντονο στο WANDR. Το Σχήμα 5 αναλύει τις βαθμολογίες του WANDR, δείχνοντας ότι η υλοποίηση SaC της Perplexity ξεπερνά το αμέσως επόμενο καλύτερο σύστημα κατά συντελεστή 2,5×. Παρά αυτό το μεγάλο περιθώριο, το WANDR παραμένει ανεκκόρεστο και αποδεικνύεται προκλητικό ακόμη και για το SaC. Πιστεύουμε ότι οι σύνθετες, εξαιρετικά οριζόντιες ροές εργασίας αναζήτησης που απαιτούνται από τις εργασίες του WANDR θα απαιτήσουν πρόσθετες προόδους στην έρευνα και τη μηχανική αναζήτησης για την επίτευξη σταθερά υψηλής απόδοσης.
Τέλος, μετράμε τα σχετικά κέρδη του SaC σε σύγκριση με μια πιο παραδοσιακή ροή αναζήτησης που αξιοποιεί την ίδια υποδομή αναζήτησης της Perplexity. Το Σχήμα 6 αναφέρει τη διαφορά στις βαθμολογίες μεταξύ της αρχιτεκτονικής SaC και της μη SaC σε κάθε κριτήριο αξιολόγησης. Σε όλο το φάσμα, το SaC παρέχει μια ουσιαστική ώθηση στην απόδοση, με το μεγαλύτερο απόλυτο κέρδος στο DSQA (+19,77 ποσοστιαίες μονάδες, 29%) και το μεγαλύτερο σχετικό κέρδος στο WANDR (+12,00 ποσοστιαίες μονάδες, 45%).
Όριο κόστους-απόδοσης
Στην πράξη, οι χρήστες ενδιαφέρονται για την απόδοση σε σχέση με το κόστος. Επομένως, αξιολογούμε το όριο κόστους-απόδοσης στο DSQA και στο WideSearch. Μετράμε το κόστος και την απόδοση του SaC σε χαμηλά, μεσαία και υψηλά επίπεδα συλλογισμού μοντέλου, παράλληλα με τα άλλα συστήματα. Τα Σχήματα 7 και 8 σχεδιάζουν τη βαθμολογία συγκριτικής αξιολόγησης σε σχέση με την τιμή ανά εργασία, με τον άξονα x αντιστραμμένο έτσι ώστε τα σημεία πιο δεξιά να είναι φθηνότερα και τα σημεία ψηλότερα να αντιπροσωπεύουν καλύτερη απόδοση.
Στο DSQA, και οι τρεις ρυθμίσεις SaC βρίσκονται στο επάνω δεξιό όριο. Η ρύθμιση χαμηλού συλλογισμού είναι φθηνότερη από όλα τα άλλα συστήματα ενώ αποδίδει καλύτερα από δύο από αυτά. Η ρύθμιση μεσαίου συλλογισμού ξεπερνά όλα τα συστήματα μη SaC με κόστος κάτω από $1 ανά εργασία. Η ρύθμιση υψηλού συλλογισμού επιτυγχάνει κορυφαία απόδοση με ανταγωνιστικό κόστος.
Το WideSearch δείχνει ένα παρόμοιας μορφής όριο. Όπως και με το DSQA, η ρύθμιση χαμηλού συλλογισμού επιτυγχάνει ανταγωνιστική απόδοση με χαμηλότερο κόστος από όλα τα συστήματα μη SaC, ενώ τόσο ο μεσαίος όσο και ο υψηλός συλλογισμός ξεπερνούν τα συστήματα μη SaC στην απόδοση εργασιών.
Προς μια νέα αρχιτεκτονική υπολογισμών
Το Search as Code αντικατοπτρίζει μια ευρύτερη αλλαγή στον σχεδιασμό λογισμικού. Επί δεκαετίες, τα συστήματα λογισμικού οργανώνονταν γύρω από ντετερμινιστικές οδηγίες που εκτελούνταν από παραδοσιακούς χρόνους εκτέλεσης σε CPU. Τα κορυφαία μοντέλα εισάγουν μια νέα μορφή υπολογισμού: συλλογισμό στον χώρο των διακριτικών που μπορεί τόσο να ακολουθεί όσο και να παράγει οδηγίες. Τα πιο ικανά υπολογιστικά συστήματα θα συνδυάσουν αυτές τις δύο μορφές υπολογισμού αντί να επιλέξουν μεταξύ τους.
Η αναζήτηση είναι ένα φυσικό πεδίο δοκιμών για αυτή την υβριδική αρχιτεκτονική. Τα μοντέλα είναι κατάλληλα για να αποφασίζουν ποια αποδεικτικά στοιχεία απαιτούνται και πώς πρέπει να επιλύεται η αβεβαιότητα. Οι ντετερμινιστικοί χρόνοι εκτέλεσης είναι κατάλληλοι για ομαδοποίηση, παραλληλισμό, φιλτράρισμα, κατάταξη και συγκέντρωση. Η υποδομή αναζήτησης χρησιμεύει ως καθολικό επίπεδο I/O, παρέχοντας στον χρόνο εκτέλεσης χρήσιμες λαβές στις πληροφορίες του κόσμου που μπορούν να υποστηρίξουν χιλιάδες λειτουργίες ανά λεπτό. Όταν αυτά τα κομμάτια ενσωματωθούν, το προκύπτον σύστημα είναι πολύ πιο ισχυρό και αποδοτικό στην ολοκλήρωση εργασιών στον πραγματικό κόσμο.
Κάθε μέρος αυτής της αρχιτεκτονικής είναι απαραίτητο για το ξεκλείδωμα αυτών των δυνατοτήτων. Χωρίς έξυπνα μοντέλα, το σύστημα δεν μπορεί να συλλογιστεί σχετικά με τη στρατηγική αναζήτησης. Χωρίς sandbox, τα μοντέλα αναγκάζονται σε σειριακό I/O και αναποτελεσματική επεξεργασία στον χώρο των διακριτικών. Και χωρίς μια ατομική στοίβα αναζήτησης, το μοντέλο δεν έχει τίποτα να ορχηστρώσει. Το SaC λειτουργεί επειδή ο συλλογισμός, ο ντετερμινιστικός υπολογισμός και το I/O είναι από κοινού σχεδιασμένα για να αναδεικνύουν τα δυνατά σημεία κάθε επιπέδου.
Αυτός ο συν-σχεδιασμός μπορεί να προχωρήσει ακόμη παραπέρα μέσω της ανάπτυξης βρόχων συνεχιζόμενης βελτίωσης. Για παράδειγμα, το Agentic Search SDK και οι δεξιότητες πράκτορα SaC θα μπορούσαν να βελτιστοποιηθούν από κοινού σε έναν κοινό βρόχο αυτόματης έρευνας. Ακόμη πιο φιλόδοξα, τα μοντέλα μπορούν να εκπαιδευτούν να αξιοποιούν πρωτόγονες μονάδες αναζήτησης χαμηλού επιπέδου που εκθέτονται ως SDK. Θα μπορούσε κανείς ακόμη και να δοκιμάσει τη συν-εξέλιξη του σχεδιασμού του SDK κατά τη διάρκεια της ίδιας της διαδικασίας εκπαίδευσης του μοντέλου. Ανυπομονούμε να ακολουθήσουμε πιο επιθετικές στρατηγικές συν-σχεδιασμού σε μελλοντική εργασία.
Κατασκευάσαμε το SaC για να επιτρέψουμε στα μοντέλα να ελέγχουν τη διαδικασία αναζήτησης, αντί απλώς να καταναλώνουν τα αποτελέσματά της. Τα αποτελέσματά μας αποδεικνύουν τη δύναμη αυτού του ελέγχου: το SaC προωθεί τόσο την απόλυτη απόδοση όσο και το όριο κόστους-απόδοσης σε κριτήρια αξιολόγησης πρακτόρων έντασης γνώσης. Είμαστε ενθουσιασμένοι που φέρνουμε τις δυνατότητες του SaC στους χρήστες μας, ξεκινώντας σήμερα με το Perplexity Computer και το Agent API. Θα συνεχίσουμε να βελτιστοποιούμε την αρχιτεκτονική SaC σε όλα τα επίπεδα της στοίβας για να διασφαλίσουμε ότι οι χρήστες μας (και οι πράκτορες που τους εξυπηρετούν) διαθέτουν τις πιο ισχυρές και αποδοτικές δυνατότητες αναζήτησης.
Παραπομπή
@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}
}