Συνεντεύξεις
Ivan Nikitin, διευθύνων σύμβουλος και συνιδρυτής της Fortytwo – Σειρά συνεντεύξεων

Ο Ivan Nikitin είναι διευθύνων σύμβουλος και συνιδρυτής της Fortytwo, όπου αναπτύσσει τεχνολογία συλλογικού συμπερασμού, η οποία συνδυάζει πολλαπλά μοντέλα τεχνητής νοημοσύνης, ώστε να συλλογίζονται και να αξιολογούν το ένα τη δουλειά του άλλου. Η επαγγελματική του πορεία εκτείνεται στον χώρο των παιχνιδιών, της συνομιλιακής τεχνητής νοημοσύνης, της παραγωγικής τεχνητής νοημοσύνης και των διαδραστικών συστημάτων, στις Temporal και Sensorium. Συνίδρυσε την Temporal το 2011 μαζί με τον Vlad Larin, ο οποίος είναι σήμερα συνιδρυτής και διευθυντής τεχνολογίας της Fortytwo, αποκτώντας εμπειρία στην ανάπτυξη πληθυσμών πρακτόρων και συστημάτων που συνδυάζουν εξειδικευμένα μοντέλα.
Η Fortytwo αναπτύσσει υποδομή τεχνητής νοημοσύνης που επιτρέπει στα μοντέλα να συνεργάζονται κατά τη διαδικασία συμπερασμού. Το Fortytwo Engine χρησιμοποιεί έναν Swarm Decoder για να καθοδηγεί μια κοινή διαδικασία συλλογισμού καθώς εξελίσσεται, με στόχο τη βελτίωση της ακρίβειας και τον περιορισμό της περιττής παραγωγής διακριτικών σε εργασίες μεγάλης διάρκειας. Η εταιρεία προσφέρει στους προγραμματιστές ένα API μέσω του Fortytwo Engine, καθώς και δυνατότητα εγκατάστασης στις εγκαταστάσεις τους μέσω του Fortytwo Harbor.
Πριν συνιδρύσετε τη Fortytwo, περάσατε χρόνια αναπτύσσοντας προϊόντα στον χώρο της συνομιλιακής και της παραγωγικής τεχνητής νοημοσύνης, καθώς και των διαδραστικών συστημάτων, στις Sensorium και Temporal. Πώς διαμόρφωσαν αυτές οι εμπειρίες την άποψή σας για τις αδυναμίες των μεμονωμένων μεγάλων γλωσσικών μοντέλων και πώς σας οδήγησαν τελικά στην προσέγγιση που βασίζεται σε σμήνος και βρίσκεται πίσω από τη Fortytwo;
Ένα μεγάλο μέρος της ομάδας μας, μαζί κι εγώ, ήρθε στον χώρο της τεχνητής νοημοσύνης μέσω των παιχνιδιών. Τα παιχνίδια υπήρξαν το λίκνο της προσωπικής υπολογιστικής και της σύγχρονης τεχνητής νοημοσύνης: χάρη σε αυτά υπάρχει η GPU, ενώ τα παιχνίδια αποτέλεσαν το πρώτο σοβαρό πεδίο δοκιμών για την ενισχυτική μάθηση. Οι κόσμοι των παιχνιδιών μάς έδωσαν ένα πρακτικό περιβάλλον για να αναπτύξουμε πράκτορες που μπορούσαν να μαθαίνουν, να προσαρμόζονται και να ανταγωνίζονται. Στην Temporal, την οποία συνίδρυσα το 2011 μαζί με τον Vlad Larin, σήμερα συνιδρυτή και διευθυντή τεχνολογίας της Fortytwo, ξεκινήσαμε με την εξελισσόμενη νοημοσύνη: πληθυσμούς πρακτόρων που ανταγωνίζονταν υπό την πίεση της επιλογής. Μας ενδιέφερε πώς ένας πληθυσμός θα μπορούσε να πετύχει περισσότερα από έναν μεμονωμένο πράκτορα, εφόσον υπήρχε ένας καλός μηχανισμός για τον εντοπισμό των ισχυρότερων συνεισφορών του και την αξιοποίησή τους. Η επιλογή και η αξιολόγηση έγιναν κεντρικά στοιχεία της αντίληψής μας για τη νοημοσύνη.
Όταν εμφανίστηκαν τα μοντέλα μετασχηματιστών, επεκταθήκαμε στη συνομιλιακή τεχνητή νοημοσύνη και δημιουργήσαμε μια πλατφόρμα για χαρακτήρες που βασίζονταν στην τεχνητή νοημοσύνη και μπορούσαν να συμμετέχουν σε ανοιχτές, αυτοσχέδιες συνομιλίες, με μνήμη και προσωπικότητα. Αυτό συνέβη μερικά χρόνια πριν από το ChatGPT, και τα μοντέλα με τα οποία εργαζόμασταν είχαν παράθυρα συμφραζομένων μόλις 512 έως 1.024 διακριτικών. Δεν υπήρχε περίπτωση να περιμένουμε από ένα πρώιμο γλωσσικό μοντέλο να ανταποκρίνεται αξιόπιστα σε όλες τις διαφορετικές απαιτήσεις αυτής της εμπειρίας. Χρειάστηκε να δημιουργήσουμε μια προσαρμοσμένη αλυσίδα επεξεργασίας από εξειδικευμένα μοντέλα, καθένα με πιο περιορισμένη αρμοδιότητα, καθώς και τη λογική για τον συνδυασμό της συνεισφοράς τους. Η κατάταξη και η επιλογή απαντήσεων έγιναν απαραίτητες για να λειτουργήσει συνολικά η εμπειρία. Έτσι μάθαμε πόσες δυνατότητες μπορούσαν να προκύψουν από τον συνδυασμό περιορισμένων μοντέλων σε ένα καλά σχεδιασμένο σύστημα.
Το άλλο δίδαγμα ήταν η αποδοτικότητα. Μάθαμε ότι τα εξειδικευμένα μοντέλα μπορούσαν να εκπαιδεύονται και να λειτουργούν με μεγαλύτερη αποδοτικότητα για σαφώς καθορισμένες εργασίες, επιτρέποντάς μας να πετυχαίνουμε περισσότερα με περιορισμένους υπολογιστικούς πόρους. Ωστόσο, η κλιμάκωση του συμπερασμού παρέμενε πρόκληση: από τη μία υπήρχαν τα όρια χρήσης των API και από την άλλη το κόστος της αυτοφιλοξενίας σε μεγάλη κλίμακα. Χωρίς πρόσβαση σε υπολογιστικούς πόρους αιχμής, έπρεπε να σκεφτούμε προσεκτικά πώς θα αξιοποιούσαμε καλύτερα τους διαθέσιμους πόρους. Η Fortytwo συνδύασε αυτά τα διδάγματα στο όραμα του συλλογικού συμπερασμού: πολλαπλά μοντέλα ή πολλαπλές παρουσίες του ίδιου μοντέλου συνεισφέρουν στη διαδικασία συλλογισμού, αξιολογώντας παράλληλα τη δουλειά των υπόλοιπων. Έτσι, το σύνολο είναι ακριβέστερο από κάθε μέλος του.
Το Fortytwo Engine χρησιμοποιεί αρκετά μοντέλα με ανοικτά βάρη για να καθοδηγεί μία ενιαία διαδικασία συλλογισμού και να ελέγχει τα ίδια τα μοντέλα το ένα το άλλο καθώς παράγεται η απάντηση. Σε τι διαφέρει αυτή η προσέγγιση από τα συμβατικά συστήματα πολλαπλών πρακτόρων, τα σύνολα μοντέλων ή την απλή εκτέλεση πολλών μοντέλων και την επιλογή της καλύτερης απάντησης εκ των υστέρων;
Η βασική διαφορά είναι ότι ο συλλογικός συμπερασμός είναι ενσωματωμένος απευθείας στη μηχανή συμπερασμού που αναπτύξαμε. Τον ονομάζουμε Swarm Decoder: πολλοί συμμετέχοντες-μοντέλα διαμορφώνουν συνεχώς μια ενιαία πορεία συλλογισμού καθώς αυτή παράγεται. Η αξιολόγηση και η καθοδήγηση πραγματοποιούνται μέσα σε αυτή τη διαδικασία, επιτρέποντας στα μοντέλα να επηρεάζουν την κατεύθυνσή της πριν ολοκληρωθεί η απάντηση.
Οι εναλλακτικές προσεγγίσεις λειτουργούν διαφορετικά. Σε ένα σύνολο μοντέλων που αξιολογεί απαντήσεις, τα μοντέλα παράγουν ξεχωριστές απαντήσεις, οι οποίες στη συνέχεια κατατάσσονται, επιλέγονται ή συνδυάζονται. Η αρχική αρχιτεκτονική της Fortytwo, που υλοποιήθηκε το 2025, χρησιμοποιούσε κατάταξη ολοκληρωμένων απαντήσεων από ομότιμα μοντέλα. Αυτό βελτίωσε σημαντικά την ακρίβεια των απαντήσεων, αλλά είχε ως κόστος την αυξημένη καθυστέρηση και την επιβάρυνση των υπολογιστικών πόρων. Πολλά συμβατικά συστήματα πολλαπλών πρακτόρων κατανέμουν την εργασία μεταξύ πρακτόρων, χρησιμοποιώντας έναν συντονιστή και μηνύματα σε φυσική γλώσσα για τη διαχείριση της συνεισφοράς τους. Αυτές οι μεταβιβάσεις μπορεί να απαιτούν πρόσθετες κλήσεις για συμπερασμό, επανάληψη των συμφραζομένων και αποφάσεις σχετικά με το ποιες πληροφορίες θα περάσουν από τον έναν πράκτορα στον άλλο. Στον Swarm Decoder δεν υπάρχουν μεταβιβάσεις: οι συμμετέχοντες εργάζονται πάνω σε μία ενιαία πορεία και ανταλλάσσουν μόνο κρίσεις σχετικά με το ποια κατεύθυνση είναι καλύτερη.
Ο Swarm Decoder έχει σχεδιαστεί ώστε να εντοπίζει αδύναμες παραδοχές κατά τη διαδικασία παραγωγής, πριν δαπανηθεί σημαντική προσπάθεια για την ανάπτυξη συλλογισμών που βασίζονται σε αυτές. Στόχος είναι να μειωθούν τα λάθη, η ανάγκη αναδίπλωσης και η περιττή παραγωγή· το όφελος στην αποδοτικότητα προκύπτει όταν ο έλεγχος αποτρέπει περισσότερη δουλειά από όση προσθέτει. Γι’ αυτό, επίσης, δεν υπάρχει επιβάρυνση στην καθυστέρηση: η εκτέλεση ακολουθεί πιο άμεση διαδρομή, οπότε το Engine ολοκληρώνει τις εργασίες ταχύτερα από το ίδιο μοντέλο όταν λειτουργεί μόνο του και χρησιμοποιώντας συνολικά λιγότερα διακριτικά, συνυπολογίζοντας κάθε συμμετέχον μοντέλο.
Έχετε επισημάνει ότι η μετατόπιση της συμπεριφοράς των μοντέλων κατά τη διάρκεια εργασιών μεγάλης διάρκειας αποτελεί σημαντικό πρόβλημα. Τι προκαλεί στην πραγματικότητα αυτή τη μετατόπιση και πώς εκδηλώνεται σε πρακτικές εφαρμογές, όπως η μηχανική λογισμικού, η έρευνα ή οι αυτόνομοι πράκτορες τεχνητής νοημοσύνης;
Η μετατόπιση συμβαίνει όταν το πλαίσιο του μοντέλου σταδιακά παύει να αφορά την εργασία. Σε μια εκτέλεση μεγάλης διάρκειας, το πλαίσιο γεμίζει με το ίδιο το παραγόμενο περιεχόμενο του μοντέλου, τα αποτελέσματα των εργαλείων, τα περιεχόμενα των αρχείων και τις επαναλήψεις. Η αρχική οδηγία καταλαμβάνει όλο και μικρότερο μέρος της προσοχής του μοντέλου, ενώ τα προηγούμενα λάθη του ενσωματώνονται πλέον στα δεδομένα από τα οποία συλλογίζεται· έτσι, τα σφάλματα συσσωρεύονται αντί να αλληλοαναιρούνται. Επιπλέον, τα σημερινά μοντέλα συλλογισμού εκπαιδεύονται με ενισχυτική μάθηση ώστε να ολοκληρώνουν εργασίες και μαθαίνουν συντομεύσεις που δίνουν την εντύπωση ολοκλήρωσης: παραλείπουν την κλήση εργαλείου, δηλώνουν επιτυχία ή συνοψίζουν αντί να ελέγχουν. Αυτό το αποκαλούμε τεμπελιά, και τα μοντέλα αιχμής το κάνουν εξίσου συχνά με τα μοντέλα ανοικτών βαρών. Η βασική αιτία είναι ότι ένα μεμονωμένο μοντέλο δεν έχει εξωτερικό έλεγχο. Αξιολογεί το ίδιο τη δουλειά του, ενώ τα μοντέλα δεν είναι καλά στην ακριβή αυτοαξιολόγηση.
Στη μηχανική λογισμικού, αυτό εκδηλώνεται όταν ο πράκτορας διορθώνει το σφάλμα που περιγράψατε, αλλά παραβιάζει τον περιορισμό που αναφέρατε στο πρώτο μήνυμα, γράφει ένα τεστ που περνάει χωρίς ουσιαστικό έλεγχο ή διαβάζει το ίδιο αρχείο τέσσερις φορές, επειδή έχει χάσει τον ειρμό όσων έχει ήδη μάθει. Στην έρευνα, είναι η παρατεταμένη εκτέλεση που απομακρύνεται από το ερώτημα που θέσατε και στρέφεται σε εκείνο που απαντιέται ευκολότερα, καταλήγοντας σε μια γενικόλογη σύνοψη. Στους αυτόνομους πράκτορες, η εκδοχή αυτή κοστίζει ακριβά: παρεκκλίσεις, επαναλαμβανόμενες κλήσεις εργαλείων, πισωγυρίσματα και κόστος σε tokens πολλαπλάσιο από αυτό που απαιτούσε η εργασία.
Μπορούμε να το ποσοτικοποιήσουμε. Εκτελέσαμε το Qwen 3.8 27B σε 450 εργασίες DeepSWE —πραγματικές εργασίες μηχανικής λογισμικού με χρήση εργαλείων και εκτενή πλαίσια— μία φορά αυτόνομα και μία μέσω του Fortytwo Engine. Αυτόνομα, το μοντέλο χρησιμοποίησε κατά μέσο όρο 16,3 εκατομμύρια tokens ανά εκτέλεση και 7,4 δισεκατομμύρια συνολικά. Μέσω του Engine, το ίδιο μοντέλο χρησιμοποίησε κατά μέσο όρο 12,3 εκατομμύρια tokens ανά εκτέλεση και 5,6 δισεκατομμύρια συνολικά —24,7% λιγότερα— και έλυσε περισσότερες εργασίες: 47,8% έναντι 42,2%. Το μοντέλο δεν άλλαξε καθόλου. Τα τέσσερα εκατομμύρια tokens ανά εκτέλεση που εξοικονομήθηκαν ήταν αποτέλεσμα της μετατόπισης: της επαναλαμβανόμενης ανάγνωσης, των επαναλήψεων και των πισωγυρισμάτων που είναι αναγκασμένο να κάνει ένα μεμονωμένο μοντέλο, επειδή κανείς δεν εντοπίζει τις λανθασμένες επιλογές του την ώρα που τις κάνει. Το σμήνος τις εντοπίζει, οπότε το μοντέλο δεν χρειάζεται ποτέ να πληρώσει το κόστος τους.
Παλαιότερα, η Fortytwo έβαζε τα μοντέλα να αξιολογούν τις ολοκληρωμένες απαντήσεις το ένα του άλλου, ενώ η σημερινή αρχιτεκτονική τούς επιτρέπει να επηρεάζουν τη διαδικασία συλλογισμού όσο αυτή βρίσκεται ακόμη σε εξέλιξη. Τι μάθατε από την προηγούμενη προσέγγιση και γιατί η καθοδήγηση σε πραγματικό χρόνο είναι αποτελεσματικότερη;
Η αρχιτεκτονική του 2025 απέδειξε ότι μπορούμε να προσεγγίσουμε τις δυνατότητες των μοντέλων αιχμής μέσω οριζόντιας κλιμάκωσης —συμμετέχοντας με περισσότερα μοντέλα αντί να επιδιώκουμε να χρησιμοποιήσουμε το μεγαλύτερο. Ένα σμήνος μοντέλων ανοικτών βαρών που κατέτασσε τις ολοκληρωμένες απαντήσεις το ένα του άλλου ξεπέρασε το καλύτερο μεμονωμένο μοντέλο του σμήνους έως και κατά 17 ποσοστιαίες μονάδες. Παράλληλα, ήταν ανθεκτικό σε συνθήκες στις οποίες ένα μεμονωμένο μοντέλο δεν είναι: σε θορυβώδεις προτροπές, σε οδηγίες που είχαν εισαχθεί κακόβουλα και σε περιπτώσεις όπου η πλειονότητα των απαντήσεων ήταν λανθασμένη.
Αυτό που δεν μπορούσε να κάνει εκείνη η αρχιτεκτονική ήταν να παρέμβει. Η κατάταξη ολοκληρωμένων απαντήσεων λειτουργεί για μία μόνο ερώτηση, όμως οι εκτελέσεις πρακτόρων αποτελούνται από εκατοντάδες βήματα, με κλήσεις εργαλείων ανάμεσά τους, και τα καθοριστικά λάθη συμβαίνουν νωρίς και συσσωρεύονται. Αν η αξιολόγηση γίνει στο τέλος, κάθε μοντέλο έχει ήδη επιβαρυνθεί με το πλήρες κόστος των tokens, ενώ ο αξιολογητής μπορεί μόνο να επιλέξει ανάμεσα σε πορείες που έχουν ήδη αποκλίνει. Αυτό σήμαινε επίσης ότι το κόστος του σμήνους αυξανόταν ανάλογα με τον αριθμό των μοντέλων —κάτι αποδεκτό για μία δύσκολη ερώτηση, αλλά ακατάλληλο για έναν πράκτορα προγραμματισμού.
Η καθοδήγηση σε πραγματικό χρόνο αντιμετωπίζει και τα δύο προβλήματα. Η συνεχής κατάταξη ασκεί πίεση επιλογής σε όλη τη διάρκεια της εκτέλεσης, ώστε μια λανθασμένη πορεία να διορθώνεται στο σημείο όπου εμφανίζεται, προτού εξαπλωθεί. Το σμήνος δεν συμβιβάζεται ποτέ με μια πρόχειρη προσπάθεια, επειδή αυτή κατατάσσεται χαμηλότερα από μια πιο προσεκτική. Γι’ αυτό ο ίδιος μηχανισμός μάς προσφέρει πλέον ταυτόχρονα μεγαλύτερη ακρίβεια και λιγότερα tokens.
Στις δοκιμές σας με το Qwen 3.8 27B, η Fortytwo αναφέρει ότι χρησιμοποίησε 24,7% λιγότερα tokens σε 450 εκτελέσεις DeepSWE, βελτιώνοντας παράλληλα τα αποτελέσματα σε έξι σημεία αναφοράς. Τι συμβαίνει μέσα στο σμήνος και του επιτρέπει να βελτιώνει την απόδοση μειώνοντας ταυτόχρονα την κατανάλωση tokens;
Ο έλεγχος από το σμήνος έχει ένα μικρό, σταθερό κόστος· το κόστος της επανόρθωσης που αποτρέπει αυξάνεται όσο μεγαλώνει η εργασία, επειδή κάθε λανθασμένη πορεία που δεν διορθώνεται επιβαρύνει όλα όσα χτίζονται πάνω της. Επομένως, όσο μεγαλύτερη είναι η εργασία, τόσο περισσότερα μπορεί να εξοικονομηθούν. Το DeepSWE βρίσκεται στο άκρο των εργασιών μεγάλης διάρκειας, γι’ αυτό η εξοικονόμηση φτάνει σχεδόν το ένα τέταρτο του συνόλου των tokens.
Το σκέλος της ακρίβειας αφορά την ανομοιόμορφη νοημοσύνη. Οι βελτιώσεις στα μοντέλα είναι συνήθως άνισες: μπορεί να έχουν συλλογιστική επιπέδου διδακτορικού σε έναν τομέα και να παράγουν πλήρη ανοησία σε έναν άλλο, επειδή η λεπτορύθμιση, η ενισχυτική μάθηση και άλλες διαδικασίες μετεκπαίδευσης βελτιώνουν ένα μοντέλο στα δεδομένα με τα οποία εκπαιδεύτηκε, ενώ τα οφέλη μειώνονται όσο οι πραγματικές εργασίες απομακρύνονται από αυτά τα δεδομένα. Το Swarm Decoder δεν αλλάζει το μοντέλο. Βελτιώνει με συνέπεια τον ίδιο τον συλλογισμό, επομένως τα έξι σημεία αναφοράς δεν αντιστοιχούν σε έξι τομείς για τους οποίους κάναμε βελτιστοποίηση· είναι έξι σημεία στα οποία μετρήσαμε το ίδιο πράγμα. Συνολικά, το μοντέλο είναι πιο έξυπνο και πιο προσεκτικό, ενώ ο έλεγχος από ομότιμα μοντέλα σε κάθε βήμα δημιουργεί την αίσθηση ότι καταβάλλει πολύ μεγαλύτερη προσπάθεια για την εργασία σας. Αυτός είναι και ο λόγος που μπορούμε να χρεώνουμε το Engine με την τιμή ανά token του βασικού μοντέλου: ο πελάτης δεν πληρώνει για μεγαλύτερο προϋπολογισμό, αλλά για μια συντομότερη διαδρομή προς τη σωστή απάντηση.
Οι δημιουργοί τεχνητής νοημοσύνης ανησυχούν όλο και περισσότερο για το κόστος της εξαγωγής συμπερασμάτων, καθώς τα μοντέλα συλλογισμού παράγουν όλο και μεγαλύτερες ακολουθίες διακριτικών μονάδων (tokens). Πιστεύετε ότι η βελτίωση της αποδοτικότητας της ίδιας της διαδικασίας συλλογισμού θα μπορούσε τελικά να είναι εξίσου σημαντική με τη δημιουργία μικρότερων, ταχύτερων ή φθηνότερων μοντέλων;
Ναι, και θα έλεγα ότι αποτελεί ήδη τον σημαντικότερο μοχλό. Η δημιουργία μικρότερων, ταχύτερων και φθηνότερων μοντέλων μειώνει την τιμή κάθε διακριτικής μονάδας (token). Όμως κανείς δεν αγοράζει tokens. Οι χρήστες αγοράζουν την ολοκλήρωση μιας εργασίας και, στην εποχή των πρακτόρων, ο αριθμός των tokens ανά εργασία έχει εκτοξευθεί: ένα μοντέλο συλλογισμού που εκτελεί μια πραγματική εργασία προγραμματισμού καταναλώνει εκατομμύρια tokens, πολλά από τα οποία δαπανώνται για να επανέλθει σε προηγούμενα βήματα. Η μείωση των tokens ανά εργασία κατά 25% αξίζει ακριβώς όσο και μια μείωση της τιμής κατά 25%, με τη διαφορά ότι συνδυάζεται με κάθε βελτίωση στο υλικό, στην κβαντοποίηση και στους υπολογιστικούς πυρήνες, ενώ μπορούμε να την εφαρμόσουμε σε οποιοδήποτε μοντέλο ανοικτών βαρών κυκλοφορεί στην αγορά.
Ο κλάδος έχει τρεις μοχλούς. Καλύτερα μοντέλα, που προκύπτουν από την εκπαίδευση και κοστίζει ακριβά. Φθηνότερα tokens, χάρη στο υλικό και στην εξυπηρέτηση, όπου οι διαφορές μειώνονται, επειδή όλοι χρησιμοποιούν τις ίδιες GPU. Και λιγότερα tokens ανά εργασία, κάτι που εξαρτάται από τον τρόπο εκτέλεσης της εξαγωγής συμπερασμάτων και παραμένει σχεδόν ανεξερεύνητο. Μέχρι τώρα, η κλιμάκωση σήμαινε μεγαλύτερα μοντέλα και μακρύτερες αλυσίδες σκέψης, με αποτέλεσμα ένα μοντέλο να καλείται να κάνει τα πάντα σε μία διαδρομή. Πιστεύουμε ότι ο επόμενος άξονας είναι συλλογικός: πολλά μοντέλα συλλογίζονται από κοινού και η κρίση κατανέμεται μεταξύ τους, με αποτέλεσμα η ίδια η διαδρομή να γίνεται συντομότερη και πιο αξιόπιστη. Πρόκειται για διαφορετικό είδος κλιμάκωσης από την αύξηση των παραμέτρων ή του υπολογισμού κατά τον χρόνο δοκιμής, και σε αυτό ποντάρουμε. Το αποκαλούμε «ομότιμα μοντέλα αντί για παραμέτρους».
Το Fortytwo Engine είναι συμβατό με το OpenAI API και εκτελεί μοντέλα ανοικτών βαρών. Πόσο σημαντική ήταν η συμβατότητα με τις υπάρχουσες στοίβες ανάπτυξης τεχνητής νοημοσύνης και πόσο εύκολα μπορούν οι προγραμματιστές να μεταφέρουν μια εφαρμογή από ένα συμβατικό API ενός μοντέλου σε μια αρχιτεκτονική σμήνους;
Η συμβατότητα είναι απαραίτητη. Το οικοσύστημα των πρακτόρων —οι πράκτορες προγραμματισμού, τα περιβάλλοντα εκτέλεσης, τα πλαίσια και τα εργαλεία αξιολόγησης— βασίζεται στη μορφή του OpenAI API. Έτσι, για τους προγραμματιστές που χρησιμοποιούν το Fortytwo Engine, η μετάβαση μοιάζει με την αλλαγή παρόχου εξαγωγής συμπερασμάτων: σε μια συμβατή εφαρμογή, έναν πράκτορα, ένα περιβάλλον εκτέλεσης ή μια υπηρεσία, συνήθως αρκεί μία αλλαγή στις ρυθμίσεις: στο τελικό σημείο, στο κλειδί API και στην επιλογή μοντέλου.
Αυτό που αλλάζει είναι η συμπεριφορά, όχι η ενσωμάτωση. Η διαφορά φαίνεται σε εκτελέσεις πρακτόρων μεγάλης διάρκειας, όπου η κατανάλωση tokens και η ακρίβεια με την πρώτη προσπάθεια καθορίζουν το κόστος: το ίδιο μοντέλο, μέσω του Engine, ολοκληρώνει τις εργασίες ταχύτερα, χρησιμοποιεί λιγότερα tokens και πετυχαίνει σε περισσότερες από αυτές. Η συμβουλή μου είναι να το αντιμετωπίσετε όπως κάθε αλλαγή μοντέλου: εκτελέστε την αξιολόγηση που ήδη χρησιμοποιείτε για τον πράκτορά σας, συγκρίνετε τα tokens ανά εργασία και το ποσοστό επιτυχίας και κρατήστε όποια επιλογή αποδίδει καλύτερα.
Σας ευχαριστούμε για την εξαιρετική συνέντευξη. Οι αναγνώστες που θέλουν να εξερευνήσουν την εξαγωγή συμπερασμάτων μέσω σμήνους και το πώς η αξιολόγηση από ομότιμα μοντέλα μπορεί να βελτιώσει την αποδοτικότητα του συλλογισμού, μπορούν να επισκεφθούν τη Fortytwo.












