LLM-First ή Code-First; Πού ανήκει η νοημοσύνη στην παραγωγική AI

Πώς να αποφασίσετε τι πρέπει να διαχειρίζεται το μοντέλο, τι πρέπει να διαχειρίζεται ο κώδικάς σας, και πώς να συνδέσετε τα δύο.

Μερικά χρόνια πριν, η αρχιτεκτονική μιας εφαρμογής AI έμοιαζε: στέλνεις μια προτροπή σε ένα μεγάλο γλωσσικό μοντέλο -> λαμβάνεις μια απάντηση -> την εμφανίζεις στον χρήστη. Αυτό δεν είναι πια η πλήρης εικόνα. Τα μοντέλα καλούνται να ερμηνεύσουν πρόθεση, να ανακτήσουν πληροφορίες, να επιλέξουν εργαλεία, να καλέσουν APIs, να κάνουν σχέδια και να εκτελούν πολυβήματικές ροές εργασίας.

Αυτή η μετατόπιση έχει διαιρέσει το πεδίο σε δύο – LLM-First ή Code-First

Σε μια αρχιτεκτονική LLM-first, το μοντέλο βρίσκεται στο κέντρο και αποφασίζει τι θα συμβεί στη συνέχεια. Διαβάζει το αίτημα, επιλέγει ένα εργαλείο, αποφασίζει τη σειρά των λειτουργιών, ελέγχει τα ενδιάμεσα αποτελέσματα και αλλάζει πορεία όταν χρειάζεται.

Σε μια αρχιτεκτονική code-first, το λογισμικό/κώδικας παραμένει υπεύθυνο για την ακολουθία, τους επιχειρηματικούς κανόνες, την επικύρωση, τα δικαιώματα και την εκτέλεση. Το LLM εδώ λειτουργεί ως ειδικός που καλεί ο κώδικας όταν απαιτείται κατανόηση ή παραγωγή γλώσσας.

Οι άνθρωποι αγαπούν να συζητούν ποιο είναι καλύτερο. Νομίζω ότι αυτό είναι το λάθος επιχείρημα. Η καλύτερη ερώτηση είναι πού ανήκει κάθε είδος νοημοσύνης. Τα πιο ισχυρά συστήματα παραγωγής που έχω δει σπάνια είναι καθαρά το ένα ή το άλλο. Συνδυάζουν πιθανοκρατική λογική με ντετερμινιστικό έλεγχο, και το κάνουν σκόπιμα.

Γιατί το LLM-First είναι τόσο ελκυστικό

Το παραδοσιακό λογισμικό λειτουργεί άψογα όταν μπορείτε να ορίσετε σαφώς τις απαιτήσεις. Για παράδειγμα, ένας χρήστης επιλέγει ένα προϊόν, εισάγει ένα ποσό και υποβάλλει μια πληρωμή. Ορίζετε τις επιτρεπτές καταστάσεις, τους κανόνες επικύρωσης, τις συνθήκες σφάλματος και τη σειρά των συναλλαγών στον κώδικα. Έτοιμο.

Η φυσική γλώσσα δεν συνεργάζεται έτσι. Φανταστείτε έναν χρήστη που πληκτρολογεί: “Βρείτε τις συναλλαγές που φαίνονται ασυνήθιστες, εξηγήστε τι συνέβη και πείτε μου τι πρέπει να ερευνήσω πρώτα.”

Δεν υπάρχει σταθερή διαδρομή μέσα σε αυτό το αίτημα. Εδώ το σύστημα πρέπει να αποφασίσει τι σημαίνει «ασυνήθιστο», να προσδιορίσει ποια δεδομένα έχουν σημασία, ίσως να καλέσει πολλά εργαλεία, να ζυγίσει την απάντηση και να γράψει μια εξήγηση που μπορεί να χρησιμοποιήσει κάποιος. Κανένας ομάδα μηχανικών/κανένας κώδικας δεν θα προβλέψει κάθε διατύπωση και κάθε συνδυασμό αιτημάτων εκ των προτέρων.

Αυτή είναι η θέση όπου ένα LLM παίζει ζωτικό ρόλο, λειτουργώντας ως ευέλικτο επίπεδο λογικής μεταξύ της ανθρώπινης γλώσσας και των ντετερμινιστικών υπηρεσιών σας. Είναι επίσης ο λόγος που οι πράκτορες λαμβάνουν τόσο μεγάλη προσοχή. οδηγίες αρχιτεκτονικής agentic AI της Google Cloud περιγράφει έναν πράκτορα ως μια εφαρμογή όπου ένα μοντέλο AI λειτουργεί ως μηχανή λογικής, ενώ τα εργαλεία του επιτρέπουν να προσεγγίζει εξωτερικά συστήματα και δεδομένα.

Anthropic’s Building Effective AI Agents οδηγίες κάνει μια διάκριση που επανέρχομαι συνεχώς. Σε ένα workflow, τα μοντέλα και τα εργαλεία ακολουθούν διαδρομές που ορίζει ο κώδικάς σας. Σε ένα agent, το LLM καθοδηγεί τη δική του διαδικασία και αποφασίζει πώς να χρησιμοποιήσει τα εργαλεία του. Οι ίδιες οδηγίες συνιστούν να ξεκινάτε με την πιο απλή αρχιτεκτονική που λύνει το πρόβλημα, αντί να προσθέτετε πολύπλοκη λειτουργικότητα με αντανακλαστικό. Θα υπογράμμιζα αυτή τη συμβουλή δύο φορές.

Τα όρια του «Άφησε το μοντέλο να αποφασίσει»

Ένα μοντέλο μπορεί να λογιστεί τι πρέπει να συμβεί. Η λογική δεν είναι το ίδιο με την επιβολή ενός κανόνα.

Για παράδειγμα, πάρτε μια χρηματοοικονομική ροή εργασίας. Ένα LLM μπορεί να είναι εξαιρετικό στην κατανόηση του «στείλε το ίδιο ποσό που έστειλα τον προηγούμενο μήνα στον ίδιο προμηθευτή». Αλλά θα πρέπει επίσης να αποφασίζει αν η μεταφορά είναι εξουσιοδοτημένη, να υπολογίζει τα κανονιστικά όρια, να επαληθεύει την ιδιοκτησία του λογαριασμού, να παρακάμπτει μια πολιτική ασφαλείας και να εκτελεί τη συναλλαγή;

Πιθανότατα όχι. Αυτές οι εργασίες είναι ντετερμινιστικές, δοκιμαστέες, ελεγχόμενες και εφαρμόσιμες, και αυτό είναι ακριβώς αυτό στο οποίο είναι καλό το παραδοσιακό λογισμικό. Ο κίνδυνος αυξάνεται καθώς τα μοντέλα αποκτούν πρόσβαση σε εργαλεία. οδηγίες ασφαλείας γενετικής AI της OWASP επισημαίνει υπερβολική αυτονομία ως σημαντικό κίνδυνο: η παροχή σε ένα σύστημα βασισμένο σε LLM περισσότερων λειτουργιών, δικαιωμάτων ή αυτονομίας από ό,τι απαιτεί η εργασία του. Ένα παράξενο ή παραποιημένο αποτέλεσμα μοντέλου είναι ένα πράγμα όταν παράγει κείμενο. Είναι πολύ μεγαλύτερο πρόβλημα όταν το μοντέλο μπορεί να ενεργήσει στον πραγματικό κόσμο.

Τίποτα από αυτό δεν σημαίνει ότι τα μοντέλα δεν πρέπει ποτέ να αναλαμβάνουν δράση. Σημαίνει ότι η αυτονομία του μοντέλου πρέπει να περιορίζεται από ντετερμινιστική εξουσία.

Το Code-First εξακολουθεί να έχει σημασία

Με την AI να εξελίσσεται τόσο γρήγορα, είναι εύκολο να νιώθουμε ότι η συμβατική μηχανική έχει περάσει τη μόδα. Θα υποστήριζα το αντίθετο. Η AI κάνει τα καλά ντετερμινιστικά συστήματα πιο σημαντικά, όχι λιγότερο.

Ο κώδικας παραμένει η σωστή επιλογή όποτε μια εργασία απαιτεί ακριβή επαναληψιμότητα. Η ταυτοποίηση είναι το πιο απλό παράδειγμα. Ένα μοντέλο δεν πρέπει να «συλλογίζεται» αν κάποιος έχει δικαιώματα διαχειριστή. Η εφαρμογή σας πρέπει να ρωτά ένα αυθεντικό σύστημα διαχείρισης ταυτοτήτων και πρόσβασης. Το ίδιο ισχύει για χρηματικούς υπολογισμούς, ελέγχους δικαιωμάτων, επικύρωση δεδομένων, κανονιστικούς περιορισμούς, όρια συναλλαγών, επικύρωση σχήματος και οτιδήποτε μη αναστρέψιμο. Αυτά απαιτούν σαφείς συμβάσεις, όχι εικασίες.

Αυτό ευθυγραμμίζεται με ευρύτερη σκέψη διακυβέρνησης. NIST AI Risk Management Framework ζητά από τις οργανώσεις να διαχειρίζονται τον κίνδυνο AI σε όλη τη σχεδίαση, ανάπτυξη, υλοποίηση και χρήση. Generative AI Profile προσθέτει ότι τα γενετικά συστήματα μπορεί να χρειάζονται πρόσθετη επίβλεψη, τεκμηρίωση, ανασκόπηση και ελέγχους, ανάλογα με τον κίνδυνο που εμπλέκεται.

Βρίσκω χρήσιμο να χωρίζω κάθε σχεδιαστική απόφαση σε δύο ερωτήσεις:

Τι πρέπει να συμβεί;

και

Τι επιτρέπεται να συμβεί;

Ένα LLM μπορεί συχνά να βοηθήσει με το πρώτο. Τα ντετερμινιστικά συστήματα θα πρέπει συνήθως να διαχειρίζονται το δεύτερο.

Το Υβριδικό Μοτίβο: Συλλογισμός Πιθανοκρατικά, Εκτέλεση Ντετερμινιστικά

Για τις περισσότερες επιχειρησιακές εφαρμογές, η πρακτική λύση είναι ένα υβρίδιο. Το LLM λειτουργεί ως στρώση ερμηνείας και συλλογισμού. Οι ντετερμινιστικές υπηρεσίες λειτουργούν ως στρώση εκτέλεσης και επιβολής.

Ένα παράδειγμα. Ας πούμε ότι ένας βοηθός AI βοηθά τους προγραμματιστές να δημιουργούν προσωρινά περιβάλλοντα δοκιμών API, και ένας προγραμματιστής πληκτρολογεί: “Δώσε μου ένα sandbox για τη ροή ενσωμάτωσης πελάτη”.

Το LLM μπορεί να το ερμηνεύσει, να καταλάβει ποια ροή εργασίας προτίθεται, να διαβάσει την τεκμηρίωση και να προτείνει ποια API είναι πιθανώς σχετικές. Ωστόσο, η πραγματική δημιουργία του περιβάλλοντος δεν πρέπει να εξαρτάται από ελεύθερο κείμενο που παράγεται. Ο κώδικας μπορεί να επιβεβαιώσει ότι τα ζητούμενα API υπάρχουν, να επικυρώσει τις συμβάσεις τους, να ελέγξει την εξουσιοδότηση, να επιβάλει όρια πόρων, να δημιουργήσει μια εγκεκριμένη διαμόρφωση και να εκτελέσει την ανάπτυξη.

Η ενδεικτική διαίρεση είναι η εξής:

• Το LLM: κατανοεί, συλλογίζεται, ταξινομεί, προτείνει, συνοψίζει.
• Ο κώδικας: επικυρώνει, εξουσιοδοτεί, υπολογίζει, αποθηκεύει, επιβάλλει, εκτελεί.

Κάθε πλευρά εκτελεί το έργο στο οποίο είναι καλύτερη, και καμία δεν καλείται να μιμηθεί τις δυνάμεις της άλλης.

Τα Όρια Έχουν Μεγαλύτερη Σημασία Καθώς οι Πράκτορες Γίνονται Πιο Ισχυροί

Αυτός ο διαχωρισμός γίνεται πιο σημαντικός καθώς προχωράμε από βοηθούς σε πράκτορες. Ένας βοηθός που δίνει λανθασμένη απάντηση ενοχλεί κάποιον. Ένας πράκτορας με δικαίωμα εγγραφής στην παραγωγή μπορεί να προκαλέσει πολύ μεγαλύτερο χάος.

Η λύση δεν είναι απαραίτητα η αφαίρεση της αυτονομίας. Πρόκειται για την προσθήκη αυτονομίας σταδιακά, διατηρώντας τα σαφή σημεία ελέγχου στη θέση τους. οδηγίες της Google για συστήματα πολλαπλών πρακτόρων συνιστά τον συνδυασμό δυναμικής συμπεριφοράς AI με ντετερμινιστικούς ελέγχους ασφαλείας, παρατηρησιμότητα, σαφώς ορισμένη αυτονομία και ανθρώπινη επίβλεψη για επιχειρησιακά κρίσιμα σενάρια.

Η ανθρώπινη έγκριση μπορεί επίσης να ενσωματωθεί στην ίδια τη ροή εργασίας αντί να είναι ένα ανεπίσημο δίχτυ ασφαλείας. Microsoft’s agent framework documentation, για παράδειγμα, υποστηρίζει κλήσεις εργαλείων που παύουν μέχρι να εγκρίνει ρητά ένα άτομο τη ζητούμενη ενέργεια.

Η αρχή είναι απλή: όσο μεγαλύτερες είναι οι συνέπειες μιας ενέργειας, τόσο ισχυρότεροι πρέπει να είναι οι ντετερμινιστικοί έλεγχοι γύρω της.

Πέντε Ερωτήσεις που Πρέπει να Θέσετε Πριν Αναθέσετε Ένα Καθήκον σε ένα LLM

Όταν αποφασίζω αν ένα στοιχείο πρέπει να είναι LLM-first ή code-first, περνάω από αυτές:

1. Έχει η εργασία μία αντικειμενικά σωστή απάντηση; Αν ναι, προτιμήστε ντετερμινιστικό κώδικα. Οι υπολογισμοί φόρων, τα δικαιώματα και η επικύρωση σχήματος δεν πρέπει να αλλάξουν επειδή ένα μοντέλο τα διαβάζει διαφορετικά σήμερα.
2. Συμπεριλαμβάνει ασαφή γλώσσα ή αδόμητες πληροφορίες; Αν ναι, ένα LLM μπορεί να προσθέσει πραγματική αξία.
3. Τι συμβαίνει αν το μοντέλο κάνει λάθος; Η κατάλληλη αρχιτεκτονική για μια σύνοψη συνάντησης διαφέρει πολύ από αυτή για την έναρξη μιας πληρωμής.
4. Μπορεί το αποτέλεσμα να επικυρωθεί ανεξάρτητα; Τα σχέδια που παράγονται από LLM γίνονται πολύ πιο ασφαλή όταν ντετερμινιστικοί κανόνες μπορούν να ελέγξουν τη δράση πριν εκτελεστεί.
5. Χρειάζεται πραγματικά ένας πράκτορας; Αν γνωρίζετε ήδη τα βήματα, μια κανονική ροή εργασίας με λίγες στοχευμένες κλήσεις LLM είναι συνήθως πιο απλή, φθηνότερη, πιο εύκολη στη δοκιμή και στη λειτουργία.

Αυτή η τελευταία ερώτηση αξίζει ιδιαίτερη προσοχή. Οι πράκτορες είναι ισχυροί επειδή μπορούν να διαχειριστούν καταστάσεις όπου δεν μπορείτε να προβλέψετε κάθε βήμα. Αλλά αν μπορείτε να προβλέψετε τα βήματα, η μετατροπή τους σε ένα ανοιχτό πρόβλημα συλλογισμού συχνά προσθέτει μεταβλητότητα χωρίς να προσθέτει νοημοσύνη.

Η Αξιοπιστία Είναι Αρχιτεκτονική Ιδιότητα, Όχι Ένα Prompt

Πολλές ομάδες ξεκινούν προσπαθώντας να βελτιώσουν την αξιοπιστία σχεδόν εξ ολοκλήρου μέσω του prompt engineering. Τα prompts έχουν σημασία, αλλά δεν μπορούν να αναλάβουν όλη τη δουλειά.

Ένα παραγωγικό σύστημα πρέπει να υποθέτει ότι η έξοδος του μοντέλου θα είναι μερικές φορές ελλιπής, κακοδιατυπωμένη, απροσδόκητη ή απλώς λανθασμένη. Το OWASP Top 10 για εφαρμογές LLM καταγράφει κινδύνους όπως έγχυση προτροπής και ακατάλληλη διαχείριση εξόδου, το οποίο ενισχύει μια βασική συνήθεια: να αντιμετωπίζουμε την έξοδο του μοντέλου ως μη αξιόπιστη είσοδο για τα downstream συστήματα, όχι ως οδηγίες για αυτόματη εκτέλεση.

Αυτό αλλάζει την ερώτηση που θέτετε. Αντί για «Πώς να γράψω μια προτροπή που πάντα κάνει το μοντέλο να ακολουθεί τον κανόνα;», ρωτήστε «Πώς να σχεδιάσω το σύστημα ώστε ο κανόνας να μην μπορεί να παραβιαστεί ακόμη και όταν το μοντέλο κάνει λάθος;»

Αυτό είναι πρόβλημα αρχιτεκτονικής λογισμικού, όχι πρόβλημα προτροπής. Μια προτροπή μπορεί να πει σε έναν πράκτορα να μην εκτελέσει μια μη εξουσιοδοτημένη ενέργεια. Μια υπηρεσία εξουσιοδότησης μπορεί πραγματικά να την σταματήσει. Αυτοί οι δύο έλεγχοι δεν είναι ισοδύναμοι.

Πέρα από τη Συζήτηση: Συστήματα Πρώτης Πρόθεσης

Σκεπτόμενος όλα αυτά, έχω καταλήξει στο συμπέρασμα ότι η συζήτηση LLM‑first έναντι code‑first οδηγεί σε μια τρίτη ιδέα: πρώτης πρόθεσης αρχιτεκτονική.

Σε ένα σύστημα πρώτης πρόθεσης, η εφαρμογή ξεκινά κατανοώντας τι προσπαθεί να επιτύχει ο χρήστης. Εκεί είναι που ένα LLM είναι πιο πολύτιμο, επειδή οι άνθρωποι σπάνια είναι ακριβείς σχετικά με το τι θέλουν. Από εκεί, το σύστημα σταδιακά μετατρέπει αυτή τη ασαφή κατάσταση σε δομημένες, ντετερμινιστικές λειτουργίες.

Ένα αίτημα όπως «Βοηθήστε με να επιλύσω το πρόβλημα πληρωμής του πελάτη» μπορεί να μετατραπεί σε μια αλυσίδα ενεργειών: κατανόηση πρόθεσης, ανάκτηση της συναλλαγής, ταυτοποίηση του λόγου αποτυχίας, πρόταση λύσης, αίτηση έγκρισης, εκτέλεση της εγκεκριμένης λειτουργίας.

Κάποια από αυτά τα στάδια ωφελούνται από τη λογική του μοντέλου γλώσσας. Άλλα πρέπει να είναι σταθερές υπηρεσίες. Η αρχιτεκτονική δεν ορίζεται από το αν η AI ή ο κώδικας «κερδίζει». Ορίζεται από το πού η αβεβαιότητα είναι αποδεκτή.

Το Συμπέρασμα

Καθώς τα μοντέλα βελτιώνονται, θα είναι δελεαστικό να τους δίνουμε έλεγχο σε όλο και μεγαλύτερα τμήματα της στοίβας. Μερικές φορές αυτή θα είναι η σωστή επιλογή. Σε άλλα συστήματα, ο πιο εξελιγμένος σχεδιασμός θα είναι αυτός που σκόπιμα δίνει στο μοντέλο λιγότερη εξουσία.

Η μηχανική παραγωγικής AI, στο τέλος, αφορά την τοποθέτηση της νοημοσύνης στο σωστό όριο. Χρησιμοποιήστε μοντέλα γλώσσας όπου η ερμηνεία, η λογική, η σύνθεση και η προσαρμογή δημιουργούν αξία. Χρησιμοποιήστε ντετερμινιστικό λογισμικό όπου η συνέπεια, η εξουσιοδότηση, η ακρίβεια και η επιβολή έχουν σημασία. Στη συνέχεια συνδέστε τα δύο μέσω στενών, παρατηρήσιμων, καλά δοκιμασμένων διεπαφών.

Το μέλλον της επιχειρηματικής AI πιθανότατα δεν είναι καθαρά LLM‑first ή καθαρά code‑first. Είναι LLM όπου η αβεβαιότητα απαιτεί νοημοσύνη, και κώδικας όπου η βεβαιότητα απαιτεί έλεγχο.

Αυτή η διάκριση μπορεί να έχει πολύ μεγαλύτερη σημασία από το ποιο μοντέλο θα επιλέξετε.