ai-agents-for-beginners

Ανάπτυξη Κλιμακούμενων Πρακτόρων με το Microsoft Foundry

Ανάπτυξη Κλιμακούμενων Πρακτόρων

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

Αυτό το μάθημα αφορά το χάσμα μεταξύ του “λειτουργεί στον υπολογιστή μου” και του “λειτουργεί αξιόπιστα και οικονομικά στην παραγωγή”. Κλείνουμε αυτό το χάσμα χρησιμοποιώντας το Microsoft Foundry και την Υπηρεσία Πρακτόρων του Microsoft Foundry, και το κάνουμε δημιουργώντας έναν πραγματικό πελατειακό πράκτορα υποστήριξης που διαθέτει εργαλεία, ανάκτηση, μνήμη, αξιολόγηση και παρακολούθηση.

Εισαγωγή

Αυτό το μάθημα θα καλύψει:

Στόχοι Μάθησης

Μετά την ολοκλήρωση αυτού του μαθήματος, θα γνωρίζετε πώς να:

Προαπαιτούμενα

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

Θα χρειαστείτε επίσης:

Από το Πρωτότυπο στην Παραγωγή: Τι Αλλάζει Πραγματικά

Ένας πρωτότυπος πράκτορας και ένας παραγωγικός πράκτορας μοιράζονται τον ίδιο βασικό βρόχο — συλλογισμός, κλήση εργαλείων, απόκριση. Αυτό που αλλάζει είναι όλα όσα περιβάλλουν αυτόν τον βρόχο. Το μοντέλο ίσως αποτελεί το 20% ενός παραγωγικού πράκτορα· το υπόλοιπο 80% είναι ο λειτουργικός σκελετός.

Θέμα Πρωτότυπο Παραγωγή
Φιλοξενία Τρέχει στο τετράδιό σας Τρέχει ως φιλοξενούμενη υπηρεσία, με έκδοση και εισαγωγή
Ταυτότητα Το διακριτικό az login σας Διαχειριζόμενη ταυτότητα με RBAC περιορισμένη
Κατάσταση Στη μνήμη, χάνεται σε επανεκκίνηση Εξωτερικοποιημένη (κατάστημα threads, υπηρεσία μνήμης)
Σφάλμα Βλέπετε το traceback Επανεκκινήσεις, εναλλακτικές λύσεις, dead-letter, ειδοποιήσεις
Κόστος “Είναι λίγα λεπτά” Παρακολουθείται ανά αίτημα, δρομολογείται, προσωρινά αποθηκεύεται, προϋπολογίζεται
Ποιότητα Κρίνετε οπτικά το αποτέλεσμα Αξιολογείται αυτόματα πριν από κάθε έκδοση
Εμπιστοσύνη Εγκρίνετε κάθε ενέργεια Πολιτική + άνθρωπος στη ροή για επικίνδυνες ενέργειες

Κρατήστε αυτό τον πίνακα στο μυαλό. Κάθε ενότητα παρακάτω αντιστοιχεί σε μία από αυτές τις γραμμές.

Πρότυπα Ανάπτυξης Πρακτόρων

Υπάρχουν τρία πρότυπα που θα χρησιμοποιήσετε, συχνά σε συνδυασμό.

1. Πράκτορες που Φιλοξενούνται από τον Πελάτη

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

2. Φιλοξενούμενοι Πράκτορες (Foundry Agent Service)

Ο πράκτορας καταχωρείται ως πόρος στο Microsoft Foundry. Το Foundry φιλοξενεί τον βρόχο συλλογισμού, αποθηκεύει threads, επιβάλλει ασφάλεια περιεχομένου και RBAC, και κάνει τον πράκτορα ορατό στην πύλη Foundry. Η εφαρμογή σας γίνεται ένας λεπτός πελάτης που δημιουργεί threads και διαβάζει απαντήσεις.

3. Ροές Εργασίας Πρακτόρων

Πολλαπλοί πράκτορες (και εργαλεία) συντίθενται σε γράφο με ρητό έλεγχο ροής — διαδοχικά βήματα, διακλαδώσεις, κόμβοι ανθρώπινης έγκρισης, και ανθεκτικά σημεία ελέγχου που μπορούν να παγώσουν και να συνεχίσουν. Αυτή είναι η δυνατότητα Ροές Εργασίας του Microsoft Agent Framework που εφαρμόζεται σε κλίμακα ανάπτυξης.

flowchart TB
    subgraph P1[Φιλοξενούμενο από τον Πελάτη]
        A1[Διαδικασία Εφαρμογής Σας] --> M1[Πάροχος Μοντέλου]
    end
    subgraph P2[Φιλοξενούμενος Πράκτορας]
        A2[Λεπτός Πελάτης] --> F2[Υπηρεσία Πράκτορα Foundry]
        F2 --> M2[Μοντέλο + Εργαλεία + Αποθήκη Θεμάτων]
    end
    subgraph P3[Ροή Εργασίας Πράκτορα]
        A3[Ορχηστρωτής] --> S1[Πράκτορας Τριάς]
        S1 --> S2[Πράκτορας Επίλυσης]
        S2 --> H[Κόμβος Ανθρώπινης Έγκρισης]
        H --> S3[Πράκτορας Δράσης]
    end

Ο Κύκλος Ζωής του Πράκτορα στο Microsoft Foundry

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

flowchart LR
    Create[Δημιουργία / Συγγραφέας] --> Version[Έκδοση]
    Version --> Evaluate[Αξιολόγηση εκτός σύνδεσης]
    Evaluate -->|περνάει τη πύλη| Deploy[Ανάπτυξη φιλοξενούμενη]
    Evaluate -->|αποτυγχάνει στη πύλη| Create
    Deploy --> Observe[Παρατήρηση σε απευθείας σύνδεση]
    Observe --> Improve[Συλλογή αποτυχιών]
    Improve --> Create
    Deploy --> Retire[Απόσυρση παλιάς έκδοσης]

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

Στρατηγικές Κλιμάκωσης

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

Χειρισμός αιτήσεων χωρίς κατάσταση. Μην κρατάτε καθόλου κατάστασης ανά χρήστη στη μνήμη της διεργασίας. Αποθηκεύστε τα threads συνομιλίας στο κατάστημα threads του Foundry ή σε υπηρεσία μνήμης ώστε οποιαδήποτε περίπτωση να μπορεί να χειριστεί οποιοδήποτε αίτημα. Αυτό επιτρέπει οριζόντια κλιμάκωση — προσθέστε περιπτώσεις, χωρίς κολλημένες συνεδρίες.

Δρομολόγηση μοντέλου. Δεν χρειάζεται κάθε αίτημα το πιο ικανό (και ακριβό) μοντέλο σας. Δρομολογήστε απλά αιτήματα — ταξινόμηση προθέσεων, σύντομες απαντήσεις — σε μικρό και γρήγορο μοντέλο, και αφήστε το μεγάλο μοντέλο για τον πραγματικό συλλογισμό. Ο Model Router του Foundry το κάνει για εσάς, ή μπορείτε να υλοποιήσετε μόνοι σας έναν ελαφρύ ταξινομητή. Θα φτιάξετε την έκδοση DIY στο εργαστήριο.

Προσωρινή αποθήκευση απαντήσεων. Πολλές ερωτήσεις υποστήριξης είναι σχεδόν-διπλότυπες (“πώς επαναφέρω τον κωδικό μου;”). Αποθηκεύστε τις απαντήσεις σε συχνές ερωτήσεις και σερβίρετέ τις χωρίς να καλέσετε το μοντέλο καθόλου. Ακόμα και ένα μέτριο ποσοστό χτυπημάτων cache μειώνει σημαντικά κόστος και καθυστέρηση.

Ταυτόχρονη εκτέλεση και πίεση ροής. Οι πάροχοι μοντέλων έχουν όρια ρυθμού. Περιορίστε την ταυτόχρονη εκτέλεση, χρησιμοποιήστε επανεκκινήσεις με εκθετική απόσβεση, και αποτύχετε ομαλά (μια ουρά “το δουλεύουμε” κερδίζει έναν 500).

flowchart LR
    Q[Ερώτημα χρήστη] --> C{Επιτυχία στην προσωρινή μνήμη;}
    C -->|ναι| R[Επιστροφή αποθηκευμένης απάντησης]
    C -->|όχι| Router{Πολυπλοκότητα;}
    Router -->|απλή| SLM[Μικρό μοντέλο]
    Router -->|περίπλοκη| LLM[Μεγάλο μοντέλο]
    SLM --> Out[Απόκριση]
    LLM --> Out
    Out --> Store[Προσωρινή μνήμη + ιχνηλάτηση]

Παρατηρησιμότητα στην Παραγωγή

Δεν μπορείτε να λειτουργείτε κάτι που δεν βλέπετε. Όπως καλύφθηκε στο Μάθημα 10, το Microsoft Agent Framework εκπέμπει ιχνηλάτηση OpenTelemetry εγγενώς — κάθε κλήση μοντέλου, χρήση εργαλείου και βήμα ορχήστρωσης γίνεται μια διαστολή. Στην παραγωγή, εξάγετε αυτές τις διαστολές στο Microsoft Foundry (ή οτιδήποτε backend συμβατό με OTel) ώστε να μπορείτε:

from agent_framework.observability import get_tracer

tracer = get_tracer()

with tracer.start_as_current_span("support_request") as span:
    span.set_attribute("customer.tier", "enterprise")
    span.set_attribute("routed.model", "gpt-5-nano")
    # η εκτέλεση του πράκτορα παρακολουθείται αυτόματα μέσα σε αυτή τη χρονική περίοδο

Χαρακτηριστικά όπως customer.tier και routed.model μετατρέπουν έναν τοίχο ιχνών σε απαντήσιμες ερωτήσεις (“κατευθύνονται πολύ συχνά οι πελάτες επιχειρήσεων στο μικρό μοντέλο;”).

Βελτιστοποίηση Κόστους

Το κόστος στους παραγωγικούς πράκτορες κυριαρχείται από tokens. Τρεις μοχλοί, κατά σειρά επιρροής:

  1. Μεγέθυνση του σωστού μοντέλου. Ένα μικρό μοντέλο που περνάει την πύλη αξιολόγησής σας είναι σχεδόν πάντα φθηνότερο από ένα μεγάλο που επίσης περνάει. Χρησιμοποιήστε την αξιολόγηση για να αποδείξετε ότι το μικρό μοντέλο είναι αρκετά καλό αντί να επιλέξετε το μεγαλύτερο από προφύλαξη.
  2. Δρομολόγηση με βάση την πολυπλοκότητα. Όπως παραπάνω — πληρώστε τιμές μεγάλου μοντέλου μόνο για αιτήματα που χρειάζονται συλλογισμό μεγάλου μοντέλου.
  3. Επιθετική προσωρινή αποθήκευση. Η φθηνότερη κλήση μοντέλου είναι αυτή που δεν την κάνετε ποτέ.

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

Επιχειρησιακές Σκέψεις για Ανάπτυξη

Διακυβέρνηση. Οι Φιλοξενούμενοι Πράκτορες κληρονομούν το RBAC, την ασφάλεια περιεχομένου, και την καταγραφή ελέγχου του Foundry. Δώστε σε κάθε πράκτορα μια διαχειριζόμενη ταυτότητα με τα λιγότερα προνόμια που χρειάζεται — μόνο ανάγνωση στη βάση γνώσης, περιορισμένη πρόσβαση στο API καταγραφής εισιτηρίων, τίποτα παραπάνω.

Άνθρωπος στη ροή. Ορισμένες ενέργειες είναι πολύ σημαντικές για να αυτοματοποιηθούν πλήρως — επιστροφή χρημάτων, διαγραφή λογαριασμού, κλιμάκωση σε νομική ομάδα. Το Microsoft Agent Framework υποστηρίζει εργαλεία που απαιτούν έγκριση: ο πράκτορας προτείνει την ενέργεια, η εκτέλεση παγώνει, ένας άνθρωπος εγκρίνει ή απορρίπτει, και η ροή εργασίας συνεχίζεται. Είδατε τον πρωταρχικό μηχανισμό στο Μάθημα 6· εδώ τον αναπτύσσετε.

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

flowchart TB
    subgraph Dev[Αρχιτεκτονική Ανάπτυξης]
        D1[Τετράδιο] --> D2[Πλαίσιο Πράκτορα]
        D2 --> D3[Πάροχος Μοντέλου]
        D2 --> D4[Τοπικά εργαλεία]
    end
    subgraph Deploy[Αρχιτεκτονική Ανάπτυξης]
        E1[Γραμμή CI] --> E2[Πύλη Αξιολόγησης]
        E2 -->|πέρασμα| E3[Υπηρεσία Πράκτορα Foundry]
        E3 --> E4[Φιλοξενούμενος πράκτορας με εκδόσεις]
    end
    subgraph Run[Αρχιτεκτονική Εκτέλεσης]
        F1[Εφαρμογή πελάτη] --> F2[Φιλοξενούμενος πράκτορας]
        F2 --> F3[Δρομολογητής Μοντέλου]
        F2 --> F4[Αναζήτηση Azure AI RAG]
        F2 --> F5[Υπηρεσία μνήμης]
        F2 --> F6[Εργαλεία MCP]
        F2 --> F7[OTel -> ανίχνευση Foundry]
        F2 --> F8[Ανθρώπινη έγκριση]
    end

Αυτά τα τρία διαγράμματα — ανάπτυξη, υλοποίηση, εκτέλεση — είναι ο ίδιος πράκτορας σε τρία στάδια της ζωής του. Το εργαστήριο που ακολουθεί σας περνάει από τη δημιουργία του.

Πρακτικό Εργαστήριο: Ένας Πράκτορας Υποστήριξης Πελατών Έτοιμος για Παραγωγή

Ανοίξτε το code_samples/16-python-agent-framework.ipynb και επεξεργαστείτε το από την αρχή μέχρι το τέλος. Θα συναρμολογήσετε έναν πράκτορα υποστήριξης πελατών Contoso με κάθε παραγωγικό θέμα ενσωματωμένο:

  1. Κλήση εργαλείων — έλεγχος κατάστασης παραγγελίας και άνοιγμα εισιτηρίων υποστήριξης.
  2. RAG — απαντήσεις σε ερωτήσεις πολιτικής από μια βάση γνώσης (Azure AI Search, με εφεδρική μνήμη στη μνήμη ώστε το τετράδιο να λειτουργεί χωρίς πόρο Search).
  3. Μνήμη — θυμάται τον πελάτη μέσα στη συνομιλία.
  4. Δρομολόγηση μοντέλου — ένας ταξινομητής πολυπλοκότητας δρομολογεί κάθε αίτημα σε μικρό ή μεγάλο μοντέλο.
  5. Προσωρινή αποθήκευση απαντήσεων — επαναλαμβανόμενες ερωτήσεις εξυπηρετούνται από την cache.
  6. Ανθρώπινη έγκριση — επιστροφές πάνω από ένα όριο παγώνουν για υπογραφή από άνθρωπο.
  7. Γραμμή αξιολόγησης — ένα μικρό σετ δοκιμών εκτός σύνδεσης βαθμολογεί τον πράκτορα και λειτουργεί ως πύλη έκδοσης.
  8. Παρατηρησιμότητα — OpenTelemetry ανίχνευση γύρω από κάθε αίτημα.

Οδηγός

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

async def handle_support_request(query: str, customer_id: str) -> str:
    # 1. Εξυπηρετήστε από την cache όταν μπορούμε.
    cached = response_cache.get(normalize(query))
    if cached:
        return cached

    # 2. Κατευθύνετε ανάλογα με την πολυπλοκότητα για να ελέγξετε το κόστος.
    model = "gpt-5-nano" if is_simple(query) else "gpt-5-mini"

    # 3. Εκτελέστε τον πράκτορα μέσα σε ένα trace span για παρατηρησιμότητα.
    with tracer.start_as_current_span("support_request") as span:
        span.set_attribute("routed.model", model)
        span.set_attribute("customer.id", customer_id)
        response = await support_agent.run(query, model=model)

    # 4. Κάντε cache και επιστρέψτε.
    response_cache.set(normalize(query), response.text)
    return response.text

Η πύλη αξιολόγησης που φυλάει μια έκδοση μοιάζει με αυτό:

async def evaluation_gate(agent, test_cases, threshold: float = 0.8) -> bool:
    passed = 0
    for case in test_cases:
        result = await agent.run(case["input"])
        if score_response(result.text, case["expected"]) >= 0.8:
            passed += 1
    pass_rate = passed / len(test_cases)
    print(f"Evaluation pass rate: {pass_rate:.0%} (gate: {threshold:.0%})")
    return pass_rate >= threshold  # ανάπτυξη μόνο εάν η πύλη περάσει

Διαβάστε κάθε γραμμή — το τετράδιο κρατά τα πρωταρχικά στοιχεία σκόπιμα μικρά ώστε τίποτα να μην κρύβεται πίσω από μια κλήση framework.

Επικύρωση Αναπτυγμένου Πράκτορα με Έλεγχους Smoke

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

Η “επιτυχημένη” ανάπτυξη αποδεικνύει μόνο ότι το control plane αποδέχτηκε τον ορισμό — δεν αποδεικνύει ότι ο πράκτορας απαντά. Μια ελλιπής εξάρτηση, μια κακή δρομολόγηση μοντέλου, ή μια ληγμένη σύνδεση μπορεί να αφήσουν μια πράσινη ανάπτυξη που δεν επιστρέφει τίποτα. Ένας έλεγχος smoke το εντοπίζει αυτό μέσα σε δευτερόλεπτα, σε κάθε ανάπτυξη, χωρίς το κόστος μιας ολοκληρωμένης αξιολόγησης.

Αυτό το αποθετήριο παρέχει ένα έτοιμο προς χρήση pipeline ελέγχου smoke βασισμένο στο AI Smoke Test GitHub Action:

- name: Smoke-test hosted agent
  uses: JFolberth/ai-smoketest@v1
  with:
    project_endpoint: $
    agent_name: ContosoSupportAgent
    tests_file: tests/lesson-16-smoke-tests.json

Εκτελέστε το από την καρτέλα Actions μόλις αναπτυχθεί ο agent σας, παρέχοντας το endpoint του έργου Foundry και το όνομα του agent. Η ομοσπονδιακή ταυτότητα χρειάζεται το ρόλο Azure AI User στο επίπεδο του έργου Foundry. Σκεφτείτε τις στρώσεις σαν μια πυραμίδα: δοκιμές καπνού (προσβάσιμο και ανταποκρίνεται;) εκτελούνται σε κάθε ανάπτυξη, offline αξιολόγηση (αρκετά καλή για κυκλοφορία;) εκτελείται πριν την προώθηση, και online αξιολόγηση (πώς τα πάει σε πραγματικό περιβάλλον;) εκτελείται συνεχώς.

Έλεγχος Γνώσεων

Δοκιμάστε την κατανόησή σας πριν προχωρήσετε στην ανάθεση.

1. Περίπου πόσο από έναν παραγωγικό agent είναι “το μοντέλο”, και τι είναι το υπόλοιπο;

Απάντηση Το μοντέλο είναι μια μικρή μειονότητα του συστήματος — συχνά αναφέρεται περίπου στο 20%. Το υπόλοιπο είναι ο λειτουργικός σκελετός: φιλοξενία και διαχείριση εκδόσεων, ταυτότητα και RBAC, εξωτερική κατάσταση, διαχείριση αποτυχιών, παρακολούθηση κόστους, αξιολόγηση, και έλεγχοι με ανθρώπινη παρέμβαση. Η μετάβαση στην παραγωγή αφορά κυρίως την κατασκευή όλων *γύρω* από τον κύκλο λογικής.

2. Πότε θα επιλέγατε Hosted Agent αντί για agent που φιλοξενείται από τον πελάτη;

Απάντηση Όταν θέλετε ένα διαχειριζόμενο runtime με ενσωματωμένη ανθεκτικότητα (νήματα που διατηρούνται και μπορούν να συνεχιστούν), παρατηρησιμότητα, ασφάλεια περιεχομένου, και RBAC, και είστε διατεθειμένοι να ανταλλάξετε κάποιον λεπτομερή έλεγχο του κύκλου λογικής για λιγότερη λειτουργική επιφάνεια. Το client-hosted είναι προτιμητέο όταν χρειάζεστε πλήρη έλεγχο του κύκλου ή ενσωματώνετε τον agent σε υπάρχον backend.

3. Γιατί ένας agent που κλιμακώνεται πρέπει να είναι stateless στη δική του μνήμη διεργασίας;

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

4. Ποιο πρόβλημα επιλύει το routing μοντέλου και πώς σχετίζεται με την αξιολόγηση;

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

5. Τι είναι “evaluation gate” και πού βρίσκεται στον κύκλο ζωής;

Απάντηση Ένα evaluation gate εκτελεί ένα offline σύνολο δοκιμών σε μια νέα έκδοση agent και εμποδίζει την ανάπτυξη αν το ποσοστό επιτυχίας δεν ξεπερνά ένα όριο. Βρίσκεται ανάμεσα στο "version" και το "deploy" στον κύκλο ζωής, κάνοντας την ποιότητα προϋπόθεση για κυκλοφορία και όχι κάτι που ελέγχεται μετά την αποστολή.

6. Γιατί ένας διακομιστής MCP πρέπει να θεωρείται ως μη αξιόπιστο όριο στην παραγωγή;

Απάντηση Επειδή είναι εξωτερική εξάρτηση που καλεί ο agent σας. Πρέπει να σταθεροποιήσετε την έκδοσή του, να τον τρέχετε με scoped ταυτότητα, να ελέγχετε τα αποτελέσματά του, να περιορίζετε τον ρυθμό κλήσεων και να μην αποκαλύπτετε ποτέ μυστικά σε αυτόν — την ίδια πειθαρχία που εφαρμόζετε σε κάθε τρίτη εξάρτηση. Τα αποτελέσματά του εισρέουν στη λογική του agent σας, οπότε η μη επικυρωμένη εμπιστοσύνη αποτελεί κίνδυνο ασφαλείας.

7. Ποια μεμονωμένη αλλαγή έχει συνήθως το μεγαλύτερο αντίκτυπο στο κόστος παραγωγικού agent, και γιατί;

Απάντηση Η κατάλληλη επιλογή μεγέθους μοντέλου — η χρήση του μικρότερου μοντέλου που περνά ακόμα το evaluation gate. Το κόστος κυριαρχείται από tokens, και ένα μικρότερο μοντέλο που πληροί το επίπεδο ποιότητας είναι σχεδόν πάντα φθηνότερο από ένα μεγαλύτερο. Η προσωρινή αποθήκευση και το routing μειώνουν περαιτέρω το κόστος, αλλά η επιλογή του κατάλληλου βασικού μοντέλου έχει το μεγαλύτερο πρωτογενή αντίκτυπο.

8. Τι ρόλο παίζουν τα attributes span όπως customer.tier και routed.model στην παρατηρησιμότητα;

Απάντηση Μετατρέπουν ωμές παρακολουθήσεις σε απαντήσιμες επιχειρησιακές ερωτήσεις. Χωρίς attributes έχετε έναν τοίχο από spans· με αυτά μπορείτε να ρωτήσετε "κατευθύνονται οι πελάτες επιχειρήσεων πολύ συχνά στο μικρό μοντέλο;" ή "ποιο μοντέλο χειρίζεται τα πιο αργά αιτήματά μας;" Τα attributes είναι ο τρόπος με τον οποίο χωρίζετε την τηλεμετρία με βάση τις διαστάσεις που έχουν σημασία για τη λειτουργία σας.

Ανάθεση

Πάρτε τον agent υποστήριξης πελατών από το εργαστήριο και ενισχύστε τον για ένα συγκεκριμένο σενάριο: έναν agent υποστήριξης χρέωσης συνδρομών για μια εταιρεία SaaS.

Η υποβολή σας πρέπει να:

  1. Αντικαταστήσετε τα εργαλεία με εργαλεία σχετικά με τη χρέωση: get_subscription_status, get_invoice, και issue_credit (πιστώσεις άνω των $50 απαιτούν ανθρώπινη έγκριση).
  2. Προσθέσετε τρία RAG έγγραφα που καλύπτουν την πολιτική επιστροφής χρημάτων της εταιρείας, τον κύκλο χρέωσης και την πολιτική ακύρωσης.
  3. Επεκτείνετε το σύνολο αξιολόγησης σε τουλάχιστον οκτώ περιπτώσεις, συμπεριλαμβανομένων τουλάχιστον δύο που πρέπει να ενεργοποιούν το μονοπάτι ανθρώπινης έγκρισης, και επιβεβαιώστε ότι το evaluation gate περνά ή αποτυγχάνει σωστά.
  4. Προσθέστε μια αναφορά κόστους: μετά από εκτέλεση δέκα μικτών ερωτημάτων μέσω του agent, εκτυπώστε πόσα πήγαν στο μικρό μοντέλο, πόσα στο μεγάλο μοντέλο, και πόσα εξυπηρετήθηκαν από την cache.

Γράψτε μια σύντομη παράγραφο (σε ένα markdown κελί) που εξηγεί ποιο κανόνα routing μοντέλου επιλέξατε και πώς θα τον επικυρώνατε με πραγματική κίνηση. Δεν υπάρχει μία σωστή απάντηση — αξιολογείστε αν οι ανησυχίες παραγωγής συνδέονται συνεκτικά.

Περίληψη

Σε αυτό το μάθημα μεταφέρατε έναν agent από πρωτότυπο σε παραγωγή με το Microsoft Foundry:

Το επόμενο μάθημα ακολουθεί την αντίθετη πορεία: αντί να κλιμακώνετε agents στο cloud, θα τους κατεβάσετε κάτω σε έναν μόνο υπολογιστή προγραμματιστή και θα τους τρέχετε αποκλειστικά τοπικά.

Πρόσθετοι Πόροι

Προηγούμενο Μάθημα

Κατασκευή Agents Χρήσης Υπολογιστή (CUA)

Επόμενο Μάθημα

Δημιουργία Τοπικών AI Agents

Αποποίηση ευθυνών: Αυτό το έγγραφο έχει μεταφραστεί χρησιμοποιώντας την υπηρεσία μετάφρασης με τεχνητή νοημοσύνη Co-op Translator. Ενώ επιδιώκουμε την ακρίβεια, παρακαλούμε να έχετε υπόψη ότι οι αυτοματοποιημένες μεταφράσεις ενδέχεται να περιέχουν λάθη ή ανακρίβειες. Το πρωτότυπο έγγραφο στη μητρική του γλώσσα πρέπει να θεωρείται η αυθεντική πηγή. Για κρίσιμες πληροφορίες, συνιστάται επαγγελματική ανθρώπινη μετάφραση. Δεν φέρουμε ευθύνη για τυχόν παρεξηγήσεις ή λανθασμένες ερμηνείες που προκύπτουν από τη χρήση αυτής της μετάφρασης.

This site is open source. Improve this page.