Πώς να υλοποιήσετε δρομολόγηση LLM και προστατευτικά όρια; Παράδειγμα συνεργασίας του Jev με μεγάλα γλωσσικά μοντέλα

Αποκάλυψη συμφερόντων και τεκμηρίων: Η PandaNpc αναπτύσσει ένα επίπεδο αποφάσεων Agent που χρησιμοποιεί το Jev. Στη συνέχεια παραπέμπουμε αντίστοιχα στην επίσημη τεκμηρίωση του TypeSafe, στο επίσημο cookbook, καθώς και σε πραγματικές κλήσεις Jev και βαθμονόμηση συνθετικών σεναρίων στο αποθετήριό μας. Η βαθμονόμησή μας χρησιμοποιεί scripted fake LLM provider και δεν μπορεί να αντιπροσωπεύσει την πραγματική κίνηση χρηστών ή την απόδοση ολόκληρης της παραγωγικής αλυσίδας.

Η δρομολόγηση LLM μπορεί να γίνει ως εξής: πρώτα το Jev κρίνει σε ποια κατηγορία ανήκει το αίτημα και πόσο υψηλός είναι ο κίνδυνος, και μετά ο κώδικας αποφασίζει αν το αναθέσει σε μια συνηθισμένη συνάρτηση, σε ένα εξειδικευμένο LLM ή σε ανθρώπινη αναθεώρηση. Το Jev μπορεί επίσης να τοποθετηθεί ανάμεσα στην ανάκτηση και τη δημιουργία για να φιλτράρει τεκμήρια, ή μετά την έξοδο του LLM για να ελέγχει τα αποτελέσματα. Επιστρέφει κλειστές επιλογές, βαθμολογίες και πιθανότητες· οι ανοιχτές απαντήσεις, η παραγωγή κώδικα και η μακρά συλλογιστική εξακολουθούν να γίνονται από το LLM. Η εξήγηση του TypeSafe για τους πράκτορες κωδικοποίησης δηλώνει ρητά ότι το Jev δεν μπορεί να αντικαταστήσει απευθείας το μοντέλο συνομιλίας πίσω από το Claude Code ή το Codex.

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

Τι μπορεί να κρίνει το Jev και τι συνεχίζει να αναλαμβάνει το LLM;

Από τις 23 Σεπτεμβρίου 2026, το μοντέλο στη σελίδα του TypeSafe που αναφέρεται ως σταθερό είναι το jev-1.13.0. Το API δέχεται ένα state και ένα σύνολο από questions, και μέσω POST /v1/systemone επιστρέφει τα αντίστοιχα δομημένα answers. Το jev-latest εκείνη την ημέρα έδειχνε στο 1.13.0, αλλά το alias αλλάζει με την έκδοση· τα συστήματα με βαθμονομημένα κατώφλια καλό είναι να καθηλώνουν την έκδοση και να καταγράφουν το πραγματικό αναγνωριστικό μοντέλου στην απάντηση.

Το Noul δεν έχει ανεξάρτητο πεδίο confidence· δεν πρέπει να γράφετε απευθείας μια πιθανότητα Noul ως «βεβαιότητα μοντέλου». Το Score επίσης δεν πρέπει να χρησιμοποιείται για τον υπολογισμό ακριβών ποσών. Ποσά, συγκρίσεις ημερομηνιών, ποσοστώσεις και έλεγχοι δικαιωμάτων θα πρέπει να παραμένουν σε ντετερμινιστικά προγράμματα, και τα όρια αυτά του Jev 1.13 έχουν καταγραφεί επίσημα.

Η ελάχιστη μορφή μιας κλήσης

Το παρακάτω σχήμα αιτήματος συμφωνεί με την επίσημη αναφορά API· οι ερωτήσεις του παραδείγματος είναι επεξηγηματική διαμόρφωση που κατασκευάστηκε για αυτό το άρθρο και δεν έχουν δοκιμαστεί online σε αυτό το άρθρο:

Το παρακάτω JSON χρησιμοποιεί ένα αγγλικό μήνυμα πελάτη· στα ελληνικά, ο πελάτης θα έλεγε “Έγινε διπλή χρέωση στην παραγγελία μου, παρακαλώ να μου επιστρέψετε τα χρήματα.”

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

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

Χρήση του Jev για δρομολόγηση LLM: τρεις διαδρομές παράδοσης

Το επίσημο παράδειγμα δρομολόγησης προθέσεων του TypeSafe αναθέτει πρώτα το αίτημα εξυπηρέτησης πελατών στο Jev για να κρίνει την πρόθεση και την πολυπλοκότητα, και μετά ο κώδικας το δρομολογεί: ο έλεγχος κατάστασης παραγγελίας πηγαίνει σε συνάρτηση βάσης δεδομένων· τα ερωτήματα προϊόντων και οι επιστροφές/ανταλλαγές πηγαίνουν σε εξειδικευμένα LLM φορτωμένα με διαφορετικό υλικό· τα σύνθετα παράπονα ή τα αποτελέσματα χαμηλής βεβαιότητας μπαίνουν σε ανθρώπινη ουρά. Αυτή είναι η πιο κατανοητή συνεργασία μεταξύ Jev και LLM: το πρώτο δίνει δομημένες κρίσεις, το δεύτερο εμφανίζεται μόνο όταν χρειάζεται να παραγάγει εξήγηση ή διάλογο.

Κατά την υλοποίηση, μπορείτε να σχεδιάσετε με την παρακάτω σειρά, αντί να αφήνετε το μοντέλο να αποφασίζει ελεύθερα όλες τις ενέργειες:

1. Ορίστε πρώτα τις διαδρομές: Καταγράψτε με σαφήνεια ποια αιτήματα μπορούν να χειριστούν οι συνηθισμένες συναρτήσεις, τα διάφορα εξειδικευμένα LLM και η ανθρώπινη αναθεώρηση, και αφήστε για το Choice μια επιλογή other ή παρόμοια εφεδρική επιλογή.
2. Βάλτε τα γεγονότα στο state: Τα αρχικά λόγια του χρήστη, η κατάσταση λογαριασμού και οι εγγραφές παραγγελιών γίνονται ξεχωριστά πεδία· μην αντιμετωπίζετε κείμενο από ιστοσελίδες άγνωστης προέλευσης ως οδηγία συστήματος.
3. Ρωτήστε στενές ερωτήσεις μία φορά: Για πρόθεση χρησιμοποιήστε Choice, για κίνδυνο ή επείγον Score, για ένα μεμονωμένο γεγονός που χρειάζεται επιβεβαίωση Noul. Η επίσημη σύσταση είναι πολλαπλές ανεξάρτητες ερωτήσεις για το ίδιο state να αξιολογούνται παράλληλα στο ίδιο αίτημα.
4. Ο κώδικας κάνει την τελική δρομολόγηση: Ελέγξτε πρώτα δικαιώματα και άκαμπτους κανόνες, και μετά τις πιθανότητες του Jev και τα κατώφλια που έχουν βαθμονομηθεί για τη δική σας επιχείρηση· αιτήματα χαμηλής βεβαιότητας ή χωρίς τεκμήρια πηγαίνουν σε άνθρωπο ή σε συμπληρωματική ερώτηση.
5. Καταγράψτε τα αποτελέσματα και επανελέγξτε: Αποθηκεύστε την έκδοση μοντέλου, την έκδοση ερωτήσεων, τις πιθανότητες, τον τελικό προορισμό και τα αποτελέσματα ανθρώπινης διόρθωσης, για να μπορείτε να κρίνετε αν τα κατώφλια είναι κατάλληλα.

Πηγή γραφήματος: TypeSafe AI, «Introducing System One Models & Jev», 2026-09-15. Τα τέσσερα workflows κατασκευάστηκαν από την TypeSafe, και οι μετρικές συγκεντρώνονται με ίσα βάρη ανά workflow· η μέθοδος αξιολόγησης βρίσκεται στις Αξιολογήσεις ροών εργασίας TypeSafe.

Το επίσημο γράφημα μπορεί να βοηθήσει στην κατανόηση του γιατί δίνεται έαση στο «να τοποθετούνταιλλαπλές στενές κρίσεις μέ σε μια ροή εργασίας προράμματος». Ο κατακόρυφος άξονας στο γράφημα ακολουθεί την ονομασία «accuracy» του κατασκευαστή, αλλά η απάντηση αναφοράς του προέρχεται από τη συναίνεση των προβλεπόμενων πιθανοτήτων δύο μεγάλων μοντέλων, δεν είναι η μοναδική σωστή απάντηση που έχει επαληθευτεί από άνθρωπο· το κόστος και οι μετρικές εξαρτώνται επίσης από αυτά τα τέσσερα workflows και τη μέθοδο αξιολόγησης του κατασκευαστή, και δεν μπορούν να μετατραπούν σε «πόσα μπορεί να εξοικονομήσει οποιοδήποτε σενάριο».

Παραγωγή επαυξημένη με ανάκτηση: Το Jev φιλτράρει τεκμήρια πριν απαντήσει το LLM

Το cookbook αποσπασμάτων RAG του TypeSafe παρέχει ένα πιο συγκεκριμένο παράδειγμα πολλαπλών μοντέλων: το OpenAI embedding ανακτά πρώτα παραγράφους, το Jev ρωτά τέσσερα Noul για κάθε «ερώτηση + παράγραφο» — αν είναι σχετική, αν περιέχει τεκμήριο που μπορεί να χρησιμοποιηθεί για απάντηση, αν αντικρούει την υπόθεση της ερώτησης, αν προσπαθεί να δώσει οδηγίες στο μοντέλο απάντησης. Ο κώδικας επεξεργάζεται τις τέσσερις πιθανότητες με σειρά και αποφασίζει αν θα βάλει την παράγραφο στην περιοχή τεκμηρίων, στην περιοχή αντικρουόμενων τεκμηρίων ή αν θα την απορρίψει· στο τέλος το Claude Sonnet 5 γράφει την απάντηση.

Αυτό το βήμα λύνει ένα σύνηθες πρόβλημα: οι παράγραφοι με υψηλή διανυσματική ομοιότητα δεν είναι κατ' ανάγκη αξιοποιήσιμες. Μπορεί να χρησιμοποιούν μόνο παρόμοιες λέξεις, ή μπορεί μέσα σε ένα forum post να περιέχουν prompt injection του τύπου «αγνόησε τα προηγούμενα». Το παράδειγμα του cookbook βάζει τον έλεγχο injection στην αρχή των κανόνων δρομολόγησης, και ταυτόχρονα υπενθυμίζει ότι τα κατώφλια είναι ένα σημείο εκκίνησης επιλεγμένο για εκείνο το σώμα κειμένου, όχι προεπιλεγμένες τιμές για όλες τις εφαρμογές RAG. Τα demo νούμερα προέρχονται από το jev-1.12 της 27ης Αυγούστου 2026 και δεν μπορούν να θεωρηθούν νέα αποτελέσματα αξιολόγησης του τρέχοντος jev-1.13.0.

Μετά τη δημιουργία μπορεί να γίνει και ένα ακόμη επίπεδο επαλήθευσης. Το cookbook ελέγχου παραπομπών του TypeSafe βρίσκει πρώτα με πρόγραμμα το πρωτότυπο της παραπομπής και μετά χρησιμοποιεί το Jev για να κρίνει αν το απόσπασμα υποστηρίζει, αντικρούει ή δεν αναφέρει τον ισχυρισμό που δημιουργήθηκε. Μπορεί να ξεχωρίσει παραπομπές που αξίζει να επανελεγχθούν· η κρίση του μοντέλου μπορεί και η ίδια να κάνει λάθος, και το «πέρασε τον έλεγχο» δεν πρέπει να γράφεται ως εγγύηση γεγονότος.

Η βαθμονόμηση του Agent μας: Πού κολλάει η αναβάθμιση χαμηλής βεβαιότητας;

Στο αποθετήριο της PandaNpc, ο client του Jev, η τράπεζα ερωτήσεων και ο orchestrator χρησιμοποιούν το Jev για την αναγνώριση πρόθεσης του Agent, τη βαθμολόγηση υποψήφιων τροποποιήσεων, τον έλεγχο συνθηκών ολοκλήρωσης και την απόφαση υποβολής. Ο client κάνει επίσης περιορισμένες επαναλήψεις σε timeout, 429 και 5xx, και θέτει όρια στον προϋπολογισμό αιτημάτων και στα ληγμένα αποτελέσματα· τα δικαιώματα εκτέλεσης τα κατέχουν ο orchestrator και το επίπεδο ελεγχόμενων εργαλείων, δεν τα παραχωρεί απευθείας μια κρίση του Jev.

Στις 2026-09-22 χρησιμοποιήσαμε το jev-1.13.0 για να τρέξουμε 19 συνθετικά turns από μία φορά σε shadow και μία σε enforce, συνολικά 38 εκτελέσεις, και καταγράψαμε 165 πραγματικές αποφάσεις Jev. Αυτή η εσωτερική έκθεση βαθμονόμησης και οι αποθηκευμένες αποκρίσεις πραγματικού μηχανήματος χρησιμοποιούν scripted fake LLM provider, επομένως αυτά τα δεδομένα δείχνουν μόνο τη συμπεριφορά αποφάσεων σε ελεγχόμενα σενάρια. Δεν μπορούν να αποδείξουν το συνολικό ποσοστό επιτυχίας, το ποσοστό εξοικονόμησης ή την end-to-end καθυστέρηση κάτω από πραγματικά αιτήματα χρηστών.

Το πιο πολύτιμο εύρημα δεν ήταν η μέση ταχύτητα, αλλά το ότι ένα κατώφλι που «φαινόταν ασφαλές» προκάλεσε συμφόρηση: από τα 19 turns σε enforce, τα 13 αναβαθμίστηκαν στο Q2 «αν οι πληροφορίες αρκούν για να ξεκινήσει η τροποποίηση», επειδή η πιθανότητα Noul έπεσε στο προκαθορισμένο διάστημα αβεβαιότητας 0,15–0,85· ο LLM Worker δεν είχε την ευκαιρία να εκτελέσει τα επόμενα βήματα. Το αρχείο βαθμονόμησης δείχνει ότι από 34 αποφάσεις Q2 που είχαν χαρακτηριστεί ως επαρκείς πληροφορίες, πολλές πιθανότητες βρίσκονταν στο μεσαίο διάστημα. Η έκθεση προτείνει να σπάσει το σύνθετο Q2 σε πιο ατομικές κρίσεις ή να ρυθμιστούν οι κανόνες αναβάθμισης· αυτές είναι προτάσεις, όχι κατώφλια που έχουν ήδη αναπτυχθεί.

Η τράπεζα ερωτήσεών μας κρίνει την είσοδο ως answer_only, inspect, modify ή out_of_scope· στη διαδρομή εγγραφής, οι υποψήφιες τροποποιήσεις που προτείνει ο Worker ταξινομούνται πρώτα με το Score, και στη συνέχεια το τελικό περιεχόμενο και η σύνοψη αλλαγών περνούν από αποδοχή και απόφαση υποβολής. Αυτά είναι μόνο σημεία απόφασης: το αν μπορούν πράγματι να διαβαστούν ή να γραφτούν αντικείμενα το αποφασίζει ο ελεγχόμενος executor παραχωρώντας δικαιώματα ανά φάση. Το Jev δεν έχει δικαίωμα να χαλαρώσει μόνο του τη λίστα επιτρεπόμενων εργαλείων, ούτε να παρακάμψει τον έλεγχο συνέπειας πριν από την υποβολή.

Τα δεδομένα βαθμονόμησης αποκάλυψαν ένα ακόμη δίλημμα. Στη λειτουργία shadow, το Jev δίνει απαντήσεις και πλήρη κατανομή, αλλά δεν αλλάζει την αρχική διαδρομή εκτέλεσης του Worker· στη λειτουργία enforce, η απάντηση επηρεάζει αν θα συνεχιστεί, θα αναβαθμιστεί ή θα απορριφθεί. Το να πάρετε την ακρίβεια του shadow ως ποσοστό ολοκλήρωσης του enforce θα σας κάνει να διαβάσετε λάθος το σύστημα: η αναβάθμιση στο Q2 σταματά την εργασία νωρίτερα και δεν αφήνει τις επόμενες ερωτήσεις βαθμολόγησης υποψηφίων, αποδοχής και υποβολής να εμφανιστούν καθόλου. Γι' αυτό η έκθεση διαβάζει χωριστά την κατανομή ανά ερώτηση, την κατεύθυνση αναβάθμισης και την τελική κατάσταση.

Στις υποψήφιες τροποποιήσεις υπήρχε μια συγκεκριμένη αντιπαράθεση: στο ίδιο turn, η υποψήφια που στόχευε με ακρίβεια την τροποποίηση πήρε 2,94 βαθμούς, ενώ η υποψήφια που αντικαθιστούσε ολόκληρο το αρχείο πήρε 0,38· επιλέχθηκε η υποψήφια με την υψηλότερη βαθμολογία. Αυτό το παράδειγμα δείχνει μόνο ότι στο συγκεκριμένο συνθετικό σενάριο η ερώτηση βαθμολόγησης ξεχώρισε τις δύο λύσεις. Αντίστροφα, μια υποψήφια της οποίας τα τεκμήρια ήταν κολοβωμένα πήρε 2,27 βαθμούς· δεν πρέπει να αγνοήσετε τη χαμηλή βεβαιότητα και τη σήμανση κολοβώματος επειδή η τιμή φαίνεται «καλή». Ο κώδικάς μας επισημαίνει χωριστά την ελλιπή τεκμηρίωση, ώστε το μοντέλο να μην βγάζει βέβαιη κρίση εγγραφής μόνο από το πρόθεμα που διατηρήθηκε.

Χωρίσαμε επίσης το «ποια υποψήφια θα επιλεγεί» και το «επιτρέπεται να γράψει» σε δύο διαφορετικά βήματα. Αφού η υποψήφια βαθμολογηθεί από το Jev, ο ελεγχόμενος executor ανοίγει εργαλεία εγγραφής μόνο στη φάση ACT/modify· το μίας χρήσης εισιτήριο που εκδίδεται συνδέει το ID κλήσης εργαλείου, τον τρέχοντα αριθμό αναθεώρησης, το hash του αντικειμένου-στόχου και τη σύνοψη παραμέτρων. Ακόμη κι αν το κείμενο της υποψήφιας παρασύρει το μοντέλο να «αγνοήσει τους περιορισμούς», δεν μπορεί να αποκτήσει δικαιώματα εργαλείου που παρακάμπτουν αυτούς τους ελέγχους. Αυτή είναι η εμπειρία μας από ενμάτωση σε επίπεδο κώδικα: η κρίση πιθανότητας καθορίζει ποια διαδρομή αξίζει να ακολουθηθεί, ενώ τα δικαιώματα παρενεργειών καθορίζονται από προγραμματιστικές συνθήκες που μπορούν να επανελεγχθούν.

Οι διαδρομές αποτυχίας πρέπει επίσης να σχεδιάζονται. Ο client κάνει περιορισμένες επαναλήψεις μόνο σε timeout, σφάλμα δικτύου, 429 ή 5xx· απαντήσεις μετά από ακύρωση ή πέρα από την προθεσμία του turn απορρίπτονται απευθείας. Αν το Jev δεν είναι διαθέσιμο σε λειτουργία enforce, δεν μπορείτε να συνεχίσετε χωρίς εξουσιοδότηση υποβάθμισης· όταν επιτρέπεται η πορεία llm_only, ο executor κλειδώνει σε μόνο ανάγνωση. Αν ο κλάδος έχει ήδη τροποποιηθεί και μετά χαθεί το Jev, ο orchestrator σημαίνει ολόκληρο τον γύρο ως αποτυχημένο, αντί να αφήσει το επόμενο LLM να συμπληρώσει εγγραφές χωρίς επίπεδο αποφάσεων. Αυτές οι διαδρομές έχουν κόστος στην εμπειρία χρήστη, αλλά κάνουν το «το μοντέλο δεν είναι προσωρινά διαθέσιμο» να μην μετατρέπεται σιωπηλά σε «τα δικαιώματα εγγραφής παραμένουν ως είχαν».

Η έκθεση βαθμονόμησης ξεχώρισε επίσης την «αναβάθμιση χαμηλής βεβαιότητας» από την «άρνηση εκτέλεσης». Για παράδειγμα, ένα σωστό discard, αν η βεβαιότητά του δεν φτάσει το ενιαίο κατώφλι 0,85, καταγράφεται ως ανάγκη εισόδου χρήστη· αυτό δεν ισοδυναμεί με λανθασμένη έγκριση. Με βάση αυτό, η έκθεση προτείνει να χωριστούν τα κατώφλια υποβολής και απόρριψης, αλλά προς το παρόν παραμένει πρόταση. Όταν γράφετε ροές εργασίας, πρέπει να ξεχωρίζετε τρία αποτελέσματα — λανθασμένη έγκριση, λανθασμένη άρνηση και εκκρεμότητα — αλλιώς το ίδιο σύνολο δεδομένων θα οδηγήσει σε λάθος συμπέρασμα για τα κατώφλια.

Αυτό το παράδειγμα μας δείχνει ότι η συνεργασία Jev και LLM δεν μπορεί να σχεδιαστεί μόνο ως «πρώτα κρίνει το Jev, μετά δουλεύει το LLM». Για κάθε κρίση πρέπει να ρωτάτε: πόσο πλατύ είναι το διάστημα αβεβαιότητας; Θα εμποδίσει τον επόμενο επεξεργαστή να αναλάβει ποτέ την εργασία; Αν τα τεκμήρια εισόδου είναι κολοβωμένα, μπορεί να γίνει σαφής αναβάθμιση αντί για εικασία; Στη δική μας υλοποίηση, ο builder του state καταγράφει το evidence_truncated και αφήνει τον καλούντα να θεωρεί τη διαδρομή έλλειψης τεκμηρίων ως αβέβαιη· ντετερμινιστικοί υπολογισμοί όπως μετρήσεις και ταξινομήσεις γίνονται πρώτα στον κώδικα, δεν ανατίθενται στο Jev για μαντεψιά. Οι επίσημοι γνωστοί περιορισμοί του Jev 1.13 συνιστούν επίσης να μένουν οι μετρήσεις και η αριθμητική στον κώδικα.

Πού πρέπει να τοποθετούνται τα προστατευτικά όρια LLM;

Το cookbook προστατευτικών ορίων LLM του TypeSafe τοποθετεί το Jev και στις δύο πλευρές — εισόδου και εξόδου — του LLM. Χρησιμοποιεί ένα σύνολο Noul για να αναγνωρίζει διαφορετικούς κινδύνους, Score για να μετρά τη σοβαρότητα, και μετά ο κώδικας αποφασίζει βάσει πολιτικής αν θα εγκρίνει, θα επανεξετάσει ανθρώπινα, θα αποκλείσει ή θα παραπέμψει στην υποστήριξη. Και η έξοδος πρέπει να ελέγχεται, γιατί ακόμη και μια συνηθισμένη είσοδος μπορεί να παραγάγει ακατάλληλο απολεσμα.

Τα όρια αυτού του είδους των προστατευτικών φραγμών είναι επίσης σαφή: το Jev μπορεί να ελέγχει περιεχόμενο με προκαθορισμένες ερωτήσεις, αλλά δεν αποτελεί παντοδύναμη απόδειξη ασφάλειας. Επίσημη τεκμηρίωση περιορισμών αναφέρει ρητά ότι κακόβουλο περιεχόμενο μπορεί να επηρεάσει την κρίση και απαιτεί να γράφετε με σαφήνεια τα criteria και να δοκιμάζετε τα όρια. Στα συνθετικά δείγματά μας κάναμε 16 δοκιμές injection κατά υποψήφιων παραμέτρων και καταγράψαμε 0 ανατροπές κατάταξης· το δείγμα είναι πολύ μικρό για να συμπεράνουμε ότι «η άμυνα κατά του prompt injection έχει λυθεί». Αυτό που πραγματικά καθορίζει τι μπορούν να κάνουν τα εργαλεία παραμένει η λίστα επιτρεπόμενων στον κώδικα, οι πύλες φάσεων και οι έλεγχοι πριν από την υποβολή.

Πότε είναι κατάλληλο και πότε δεν πρέπει να χρησιμοποιείται;

Το Jev είναι κατάλληλο όταν: το σύνολο υποψηφίων είναι γνωστό, η ερώτηση μπορεί να σπάσει σε λίγες σύντομες κρίσεις, και το λογισμικό χρειάζεται πιθανότητες για να αποφασίσει αυτόματη επεξεργασία ή αναβάθμιση σε άνθρωπο. Παραδείγματα: δρομολόγηση εξυπηρέτησης πελατών, φιλτράρισμα παραγράφων RAG, βαθμολόγηση υποψήφιων ενεργειών Agent, έλεγχος παραπομπών σε παραγόμενα αποτελέσματα. Αν η εργασία απαιτεί να γραφτεί μια απαντητική επιστολή, να τροποποιηθεί ένα απόσπασμα κώδικα ή να εξηγηθεί σύνθετη συλλογιστική, την αναλαμβάνει το LLM. Αν η εργασία είναι ακριβής υπολογισμός χρημάτων, σύγκριση ημερομηνιών ή έλεγχος πρόσβασης, το πρόγραμμα πρέπει να υπολογίζει απευθείας. Η σελίδα μοντέλου αναφέρει επίσης ότι το Jev δέχεται μόνο κείμενο και ότι τα αγγλικά είναι η γλώσσα εκπαίδευσης με την καλύτερη σημερινή απόδοση· τα κινεζικά σενάρια χρειάζονται αξιολόγηση με δικά σας δεδομένα και δεν μπορούν να αντιγράψουν τα κατώφλια ενός αγγλικού cookbook.

Αν θέλετε να παρατηρήσετε πώς ένας πραγματικός Agent χειρίζεται δικαιώματα και κλήσεις εργαλείων, μπορείτε να δείτε πρώτα το PandaNpc Agent· για τα όρια και τα σενάρια χρήσης ενός Agent κωδικοποίησης, μπορείτε επίσης να συμβουλευτείτε τη σύγκριση Claude Code και Codex.

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

Συχνές ερωτήσεις (FAQ)

Μπορεί το Jev να αντικαταστήσει το Claude Code, το Codex ή ένα μοντέλο συνομιλίας; Όχι. Η TypeSafe το τοποθετεί ως δομημένο μοντέλο αποφάσεων μέσα στο λογισμικό· η συνομιλία, η συγγραφή και η παραγωγή κώδικα εξακολουθούν να χρειάζονται LLM.

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

Πόσες ερωτήσεις μπορούν να τεθούν σε ένα αίτημα; Μπορείτε να βάλετε πολλαπλά ανεξάρτητα Choice, Score και Noul που μοιράζονται το ίδιο state σε ένα αίτημα. Κάθε ερώτηση αξιολογείται χωριστά, και οι σύνθετες κρίσεις θα πρέπει ακόμη να χωρίζονται και μετά να συνδυάζονται από τον κώδικα.

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