SchemaRouter: πώς οι AI agents βρίσκουν τα σωστά δεδομένα χωρίς περιττό context

Το SchemaRouter δείχνει πώς οι AI agents επιλέγουν σωστά εργαλεία και πεδία, μειώνουν context και διατηρούν προέλευση, μονάδες και άδειες χρήσης.

Απάντηση πρώτα: το SchemaRouter δείχνει ότι ένας AI agent δεν χρειάζεται να βλέπει ολόκληρο τον κατάλογο APIs ούτε να ανακτά όλα τα διαθέσιμα πεδία για να απαντήσει σωστά. Χρειάζεται ένα μικρό, εκτελέσιμο πλάνο που επιλέγει τα σωστά εργαλεία, διατηρεί τα κρίσιμα πεδία και μεταφέρει μαζί τους μονάδες, προέλευση και άδεια χρήσης.

Στο benchmark της εργασίας, η προσέγγιση πέτυχε answer accuracy 0,71 με 227 retrieved-context tokens, έναντι 2.066 tokens για το fetch-all με accuracy 0,70. Το αποτέλεσμα αφορά 110 ερωτήματα επιστήμης υλικών και δεν αποδεικνύει καθολική υπεροχή. Προσφέρει όμως ένα συγκεκριμένο αρχιτεκτονικό μάθημα για agents που συνδέονται με CRM, analytics, e-commerce catalogs, databases και εξωτερικά APIs.

Съдържание

Το κρυφό κόστος πίσω από ένα agentic RAG workflow

Όσο περισσότερα εργαλεία αποκτά ένας AI agent, τόσο δυσκολότερη γίνεται μια φαινομενικά απλή απόφαση: ποιο εργαλείο πρέπει να καλέσει, με ποιες παραμέτρους και ποια ακριβώς πεδία χρειάζεται να επιστρέψει; Σε ένα απλό chatbot, το μοντέλο απαντά από το context που του δίνεται. Σε ένα agentic RAG σύστημα, πρέπει πρώτα να αποφασίσει πού θα ψάξει και μετά να μετατρέψει αυτή την επιλογή σε έγκυρη κλήση.

Ένα ερώτημα μπορεί να απαιτεί συνδυασμό από εσωτερική βάση δεδομένων, vector store, graph store και εξωτερικό API. Η επιλογή δεν τελειώνει στο όνομα του εργαλείου: κάθε endpoint έχει διαφορετικές υποχρεωτικές παραμέτρους, response fields, μονάδες, πηγές και περιορισμούς χρήσης. Αν ένα από αυτά χαθεί, το πλάνο μπορεί να είναι σημασιολογικά σχετικό αλλά τεχνικά μη εκτελέσιμο.

Η ερευνητική εργασία SchemaRouter: Field-Aware Tool Routing for Efficient Heterogeneous Agentic RAG, που δημοσιεύτηκε στο arXiv στις 3 Ιουλίου 2026, προτείνει μια ενδιάμεση στρώση δρομολόγησης. Ένα μικρό LLM εξάγει την πρόθεση και τις βασικές έννοιες· στη συνέχεια, ντετερμινιστικοί κανόνες πάνω σε schema graph επιλέγουν εργαλεία και πεδία. Η διάκριση είναι κρίσιμη, επειδή η διάγνωση μιας αποτυχίας AI agent απαιτεί να ξέρουμε αν έφταιξε η κατανόηση, το πλάνο, η κλήση εργαλείου ή ο downstream reader.

Γιατί prompt-all, over-fetch και under-fetch δημιουργούν διαφορετικά προβλήματα

Η στρατηγική prompt-all τοποθετεί όλες τις περιγραφές εργαλείων και πεδίων μέσα στο routing prompt. Μπορεί να είναι αποτελεσματική με ισχυρό μοντέλο, αλλά το schema επαναλαμβάνεται σε κάθε κλήση και μεγαλώνει μαζί με το inventory. Στη μελέτη, ο κατάλογος είχε 19 εργαλεία και 166 response fields. Μόνο το schema segment είχε 5.042 χαρακτήρες, δηλαδή περίπου 1.260 tokens με την απλοποιημένη παραδοχή τεσσάρων χαρακτήρων ανά token.

Οι συγγραφείς εκτιμούν αναλυτικά αύξηση περίπου 66 routing-prompt tokens ανά πρόσθετο εργαλείο: περίπου 6.600 tokens στα 100 εργαλεία και 33.000 στα 500. Πρόκειται για προβολή από το inventory των 19 εργαλείων, όχι για μέτρηση σε deployments αυτού του μεγέθους. Το prompt caching μπορεί να μειώσει το input κόστος ενός σταθερού schema, αλλά δεν καταργεί την προσοχή πάνω στο πλήρες prefix ούτε λύνει τις αλλαγές σε εργαλεία, εκδόσεις ή permissions.

Сайтът over-fetching είναι διαφορετικό πρόβλημα: ο agent καλεί περισσότερα εργαλεία ή επιστρέφει περισσότερα πεδία από όσα χρειάζονται. Αυξάνει payload, context και πιθανότητα να φτάσουν ευαίσθητα ή αντιφατικά δεδομένα στον reader. Το under-fetching αφήνει έξω ένα κρίσιμο πεδίο και μπορεί να οδηγήσει σε πειστική αλλά ελλιπή απάντηση. Η προστασία από indirect prompt injection σε εξωτερικές πηγές παραμένει ξεχωριστός έλεγχος· η μικρότερη ανάκτηση περιορίζει την επιφάνεια, αλλά δεν αποδεικνύει ότι το περιεχόμενο είναι αξιόπιστο.

Prompt-all

Δίνει στο μοντέλο ολόκληρο το tool schema σε κάθε routing call. Προσφέρει ευρεία ορατότητα, αλλά το prompt μεγαλώνει μαζί με το inventory.

Πλήρες schemaΥψηλό routing cost

Vector-only

Βρίσκει σημασιολογικά κοντινά εργαλεία, αλλά μπορεί να αστοχήσει σε required parameters, response fields και εκτελεσιμότητα.

SimilarityΚίνδυνος under-fetch

SchemaRouter

Χρησιμοποιεί μικρό LLM για κατανόηση και ντετερμινιστικό field projection για έγκυρα, metadata-aware tool plans.

Field-awareExecutable plan

Το schema graph μετατρέπει τα APIs σε λειτουργικό χάρτη

Ο SchemaRouter αναπαριστά ως κόμβους τα Tool, Endpoint, Parameter, ResponseField, DomainConcept, Unit, SourceType, LicensePolicy, FieldGroup και Intent. Οι ακμές συνδέουν endpoints με παραμέτρους και πεδία, πεδία με μονάδες, πηγές και έννοιες, και φυσικές εκφράσεις με τα canonical field names. Το σύστημα δεν κρατά μόνο περιγραφές κειμένου· αποθηκεύει τις σχέσεις που καθορίζουν ποιο αίτημα είναι έγκυρο και τι σημαίνει κάθε απάντηση.

Η ιδέα συγγενεύει με το schema linking από text-to-SQL, αλλά μεταφέρεται σε περιβάλλον πολλών ετερογενών εργαλείων. Δεν ευθυγραμμίζει λέξεις μόνο με στήλες μιας βάσης. Συνδέει ερωτήματα με πεδία πολλών APIs και διατηρεί metadata που ο downstream reader δεν είναι ασφαλές να ανακατασκευάσει από παραμετρική γνώση.

Το production graph που ενέπνευσε τη μελέτη είναι ιδιόκτητο. Το paper αναφέρει frozen JSON export, evaluation harness και repository για αναπαραγωγή των αποτελεσμάτων. Κατά τον έλεγχο στις 14 Σεπτεμβρίου 2026, όμως, ο δηλωμένος σύνδεσμος GitHub επέστρεφε HTTP 404. Επομένως, το άρθρο βασίζει τις μετρικές στο πλήρες paper και δεν παρουσιάζει το repository ως διαθέσιμο δημόσιο τεκμήριο.

Πώς παράγεται ένα εκτελέσιμο tool plan

Στο πρώτο βήμα, ένα μικρό LLM εξάγει intent, domain concepts, parameter values, source constraint και εργαλεία που αναφέρονται ρητά. Αν ο χρήστης κατονομάζει εργαλείο, αυτό υπερισχύει. Διαφορετικά, οι υποψήφιοι περιορίζονται με βάση το domain του intent και τις απαιτούμενες ομάδες πεδίων. Ένας source constraint μπορεί, για παράδειγμα, να ξεχωρίσει experimental, calculated ή literature data.

Η επιλογή πεδίων γίνεται έπειτα ντετερμινιστικά. Περιλαμβάνονται identifiers, concept-field matches και οι field groups που λειτουργούν ως recall safety net. Η alias layer γεφυρώνει τη γλώσσα του χρήστη με τα canonical field names: ένας domain όρος μπορεί να αντιστοιχιστεί στο ακριβές όνομα που καταλαβαίνει το API. Τέλος, το πλάνο επισυνάπτει unit, source type και license για κάθε σχετικό πεδίο.

Το «έγκυρο από κατασκευή» δεν σημαίνει ότι η επιχειρηματική πολιτική έχει αυτομάτως εφαρμοστεί. Σημαίνει ότι τα fields προέρχονται από το δηλωμένο schema και οι parameters από το σύνολο που δέχεται το endpoint. Authentication, authorization, consent, rate limits, data minimization και approval gates πρέπει να επιβληθούν από τα αντίστοιχα policy και execution layers. Η προστασία δεδομένων στο CRM χωρίς να μπλοκάρεται το marketing απαιτεί ακριβώς αυτόν τον διαχωρισμό ανάμεσα σε χρήσιμο πεδίο και επιτρεπτή πρόσβαση.

Τι μετρά πραγματικά το benchmark των 110 ερωτημάτων

Η αξιολόγηση περιλαμβάνει 110 ερωτήματα επιστήμης υλικών σε εννέα κατηγορίες: 36 single-tool property lookups, 12 chemical lookups, 12 provenance-sensitive αιτήματα, 10 multi-field queries, 10 literature searches, 8 cross-source comparisons, 8 unit-sensitive queries, 8 αρνητικά ερωτήματα χωρίς κατάλληλο εργαλείο και 6 ambiguous single-entity queries.

Το frozen inventory καλύπτει 19 ετερογενή εργαλεία και 166 response fields: βάσεις ιδιοτήτων υλικών, PubChem, βιβλιογραφικά APIs, μία πηγή επιχειρηματικών γνωστοποιήσεων και web ή Q&A fallbacks. Τα downstream δεδομένα είναι deterministic structured fixtures. Αυτή η επιλογή διευκολύνει την ελεγχόμενη σύγκριση, αλλά υποτιμά τον θόρυβο, την ακαταστασία και την πιθανή prompt injection που συναντά ένα πραγματικό corpus.

Η μελέτη δεν σταματά σε tool precision ή field F1. Μετρά parameter validity, executable-plan rate, retrieved-context tokens, end-to-end latency, τελική ακρίβεια απάντησης και αν η απάντηση μεταφέρει provenance και license. Αυτό είναι το σωστό επίπεδο για ένα production agent: ο router δεν είναι καλός επειδή παράγει «κομψό» πλάνο, αλλά επειδή βοηθά την τελική απάντηση να είναι σωστή, γρήγορη και ελέγξιμη.

Τα αποτελέσματα: ανταγωνιστική ακρίβεια με πολύ λιγότερο context

Ο SchemaRouter πέτυχε answer accuracy 0,71 με 95% confidence interval 0,63–0,79, field recall 0,86, 227 retrieved-context tokens και end-to-end latency 5,5 δευτερόλεπτα. Το fetch-all είχε accuracy 0,70, αλλά χρησιμοποίησε 2.066 tokens και 4,9 δευτερόλεπτα. Το prompt-all είχε accuracy 0,66, 207 retrieved-context tokens και latency 15,1 δευτερόλεπτα.

Το operating point του SchemaRouter

Οι τιμές αφορούν αποκλειστικά το benchmark των 110 ερωτημάτων και δεν αποτελούν εγγύηση για κάθε agentic RAG deployment.

0,71answer accuracy με επικαλυπτόμενα CI
227retrieved-context tokens
0,93tool-exact rate στον βασικό πίνακα
62%απαντήσεις με schema-only license citation

Η καθαρότερη διαφοροποίηση βρίσκεται στην αποδοτικότητα και στην εγκυρότητα του πλάνου. Ο SchemaRouter είχε tool-exact rate 0,93 και parameter validity 1,00 στον βασικό πίνακα planning metrics. Χρησιμοποίησε περίπου εννέα φορές λιγότερα retrieved-context tokens από το fetch-all, χωρίς μετρήσιμη απώλεια accuracy στο συγκεκριμένο setup. Σε σχέση με το prompt-all, ο χρόνος end-to-end ήταν περίπου 2,7 φορές χαμηλότερος.

Γιατί το ελάχιστο πλήθος πεδίων είναι λάθος KPI

Ένα από τα πιο χρήσιμα ευρήματα είναι ότι η ακραία ελαχιστοποίηση πεδίων βλάπτει το downstream αποτέλεσμα. Στο minimal-field operating point, η accuracy έπεσε στο 0,56 με 188 retrieved-context tokens. Όταν προστέθηκαν intent-relevant field groups ως safety net για το recall, η accuracy ανέβηκε στο 0,71, ενώ τα tokens αυξήθηκαν μόνο στα 227.

Το μάθημα δεν είναι «φέρε περισσότερα δεδομένα». Είναι ότι το σωστό optimization target συνδυάζει ποιότητα απάντησης και πραγματικό κόστος context. Ένα field-count metric θεωρεί όλα τα πεδία ισοδύναμα, ενώ ένα σύντομο identifier και ένα μεγάλο textual field έχουν πολύ διαφορετικό token footprint. Το μικρότερο πλάνο μπορεί να φαίνεται αποδοτικό και ταυτόχρονα να λείπει το στοιχείο που επιτρέπει στον reader να απαντήσει.

Για product και data teams, τα dashboards πρέπει να συνδέουν routing metrics με answer success, latency, token usage, invalid calls και missing-field failures. Παρόμοια, οι multimodal AI agents χρειάζονται επαλήθευση μετά την αντίληψη: περισσότερα inputs δεν εγγυώνται σωστή δράση, αλλά ούτε η επιθετική αφαίρεση context εγγυάται ότι θα διατηρηθεί η κρίσιμη πληροφορία.

Provenance, άδειες και ασφάλεια δεδομένων

Η ισχυρότερη answer-level διαφορά αφορά την ιχνηλασιμότητα. Ο SchemaRouter συμπεριέλαβε schema-only license citations στο 62% των μη αρνητικών απαντήσεων. License mention και source-type statement έφτασαν και τα δύο στο 94%. Τα baselines είχαν περίπου μηδενικό schema-only citation rate, επειδή τα συγκεκριμένα license strings δεν υπήρχαν στο πλάνο που έλαβε ο reader.

Για marketing, e-commerce και content operations, αυτή η αρχή είναι ευρύτερη από την επιστήμη υλικών. Όταν ένας agent χρησιμοποιεί product feeds, DAM assets, customer data ή licensed market research, η προέλευση και οι όροι χρήσης δεν πρέπει να προστίθενται εκ των υστέρων ως υποσημείωση. Πρέπει να ταξιδεύουν μαζί με το πεδίο από το registry έως την τελική έξοδο. Πρόκειται για αρχιτεκτονική ερμηνεία, όχι για cross-domain αποτέλεσμα που απέδειξε το benchmark.

Η μικρότερη απόκριση API μπορεί επίσης να μειώσει τον κίνδυνο excessive data exposure, αλλά μόνο αν η επιλογή πεδίων επιβάλλεται στην πλευρά του server και συνδέεται με object-property authorization. Ένας router που «ζητά» λιγότερα πεδία δεν αντικαθιστά τους ελέγχους πρόσβασης. Η MCP προδιαγραφή προειδοποιεί επίσης ότι τα tool annotations είναι hints και δεν πρέπει να θεωρούνται από μόνα τους αξιόπιστη περιγραφή συμπεριφοράς.

Production gate για field-aware agents

Το schema επιλέγει δεδομένα· η πολιτική αποφασίζει αν επιτρέπονται

Συνδέστε κάθε endpoint και response field με owner, sensitivity, επιτρεπτό purpose, role, source, unit, license και χρόνο διατήρησης. Εκτελέστε το plan μόνο αφού περάσει authorization και data-minimization check, και κρατήστε trace για το query, το επιλεγμένο schema version, τα returned fields και την τελική απάντηση.

Πού αποτυγχάνει ακόμη ο SchemaRouter

Τα υπόλοιπα σφάλματα χωρίζονται κυρίως σε λάθος επιλογή εργαλείου για αμφίσημες οντότητες και σε λάθη του reader. Στα ambiguous single-entity queries, το concept matcher δυσκολεύεται να αποφασίσει την κατάλληλη πηγή χωρίς ρητό όνομα. Η alias layer χρειάζεται ανθρώπινη συντήρηση καθώς μεγαλώνει ένα domain, επομένως η προσέγγιση δεν καταργεί τη schema governance.

Υπάρχουν ουσιαστικοί περιορισμοί εγκυρότητας. Το benchmark έχει 110 queries, είναι materials-science-centric, δημιουργήθηκε από έναν annotator και χρησιμοποιεί frozen structured fixtures αντί για πραγματικά documents. Η αξιολόγηση έγινε σε μία εκτέλεση με self-hosted Qwen-3.5 122B, θερμοκρασία μηδέν και reasoning απενεργοποιημένο. Ο ίδιος model family παρήγαγε και έκρινε τις απαντήσεις, ενώ έγινε cross-family spot review μόνο σε 40 δείγματα.

Οι μετρήσεις latency προέρχονται από κοινό, φορτωμένο server και είναι ενδεικτικές. Τα αποτελέσματα χρειάζονται multi-seed, multi-model και cross-domain replication. Επιπλέον, το paper υποστηρίζει schema-size-independent routing prompt, αλλά η συντήρηση του graph, των aliases, των field groups και των policies παραμένει πραγματικό οργανωτικό κόστος.

Τι σημαίνει για CRM, e-commerce και marketing agents

Ένας commerce agent μπορεί να συνδέεται με catalog, αποθήκη, pricing, orders, reviews και ad platforms. Το ερώτημα «ποιο προϊόν έχει περιθώριο για προώθηση;» χρειάζεται συγκεκριμένα πεδία και ίσως διαφορετικές άδειες πρόσβασης από το «ποια καμπάνια είχε καλύτερο ROAS;». Αν όλες οι περιγραφές και όλα τα δεδομένα φορτώνονται πάντα, το context μεγαλώνει. Αν επιλεγεί μόνο το σημασιολογικά κοντινότερο εργαλείο, μπορεί να λείψει το κόστος προϊόντος ή το attribution window.

Ένα field-aware registry μπορεί να δηλώνει ποια πεδία απαιτεί κάθε intent, τις μονάδες τους, την πηγή, τη φρεσκάδα και τους access constraints. Για ένα CRM query, για παράδειγμα, το πλάνο μπορεί να χρειάζεται lifecycle stage και τελευταία επιτρεπτή επαφή, αλλά όχι πλήρες ιστορικό notes ή στοιχεία που δεν σχετίζονται με τον σκοπό. Για product availability χρειάζεται SKU, stock status και timestamp, όχι ολόκληρο το αντικείμενο παραγγελίας.

Η παραγωγική εφαρμογή απαιτεί privacy και authorization enforcement που δεν αποτελούν αντικείμενο του paper. Χρειάζεται επίσης fallback όταν ένα endpoint αλλάξει schema, όταν η πηγή είναι stale ή όταν το plan δεν φτάνει ένα confidence threshold. Οι AI agents στην επιχείρηση πρέπει να αντιμετωπίζονται ως λογισμικό με όρια, όχι ως «συνάδελφοι» που συμπληρώνουν αυθαίρετα τα κενά.

Ένα pilot επτά βημάτων για field-aware routing

Το pilot πρέπει να ξεκινήσει από μία περιορισμένη απόφαση με μετρήσιμο κόστος λάθους, όχι από όλο το API inventory της επιχείρησης. Κατάλληλο πρώτο use case είναι ένα read-only ερώτημα σε catalog, analytics ή support knowledge base, όπου υπάρχουν γνωστές σωστές απαντήσεις και ασφαλές fallback.

Επτά βήματα από το inventory σε ασφαλές shadow run

  1. Стъпка 1Κλειδώστε ένα business intent

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

  2. Стъпка 2Χαρτογραφήστε εργαλεία και endpoints

    Καταγράψτε method, required parameters, response fields, rate limits, εκδόσεις και failure modes μόνο για τα συστήματα που χρειάζεται το συγκεκριμένο intent.

  3. Стъпка 3Επισυνάψτε metadata ανά πεδίο

    Δηλώστε canonical name, aliases, unit, source type, freshness, license, sensitivity και απαιτούμενο role. Μην αφήσετε permissions ως ελεύθερο κείμενο στο prompt.

  4. Стъпка 4Ορίστε recall-critical field groups

    Ξεχωρίστε identifiers και μικρές ομάδες πεδίων που χρειάζονται ως safety net, ώστε η ελαχιστοποίηση να μη μετατραπεί σε under-fetching.

  5. Стъпка 5Χτίστε gold query suite

    Προσθέστε απλά, multi-tool, provenance-sensitive, ambiguous και αρνητικά queries όπου η σωστή απόφαση είναι να μη γίνει ακατάλληλη κλήση.

  6. Стъпка 6Συγκρίνετε downstream baselines

    Μετρήστε prompt-all, similarity routing και ελεγχόμενο fetch-all με answer accuracy, valid execution, context tokens, latency, metadata completeness και data exposure.

  7. Стъпка 7Τρέξτε shadow mode και versioned monitoring

    Καταγράψτε query, schema version, tool plan, returned fields, answer και human correction πριν επιτρέψετε write actions ή αυτόνομη επίδραση σε πελάτες και budget.

Сайтът Αυτοματισμοί Επιχειρήσεων & AI της TWO DOTS ξεκινούν από τη χαρτογράφηση διαδικασιών, δεδομένων, owners και σημείων ελέγχου. Για ένα SchemaRouter-style pilot, η αξία δεν βρίσκεται στο να προστεθεί ακόμη ένα abstraction layer, αλλά στο να αποδειχθεί ότι το plan μειώνει περιττό context χωρίς να χάνει κρίσιμα πεδία ή να παρακάμπτει πολιτικές.

Η ουσία: το μικρότερο επαρκές και ελέγξιμο σύνολο

Ο SchemaRouter δεν αποδεικνύει ότι ένα schema graph είναι η καλύτερη λύση για κάθε agentic RAG σύστημα. Δείχνει όμως ότι η επιλογή response fields αξίζει να αντιμετωπίζεται ως ξεχωριστό αρχιτεκτονικό πρόβλημα. Στο συγκεκριμένο benchmark, η recall-preserving δρομολόγηση διατήρησε ανταγωνιστική accuracy με πολύ λιγότερο retrieved context από το fetch-all και με πλουσιότερη πληροφορία προέλευσης και αδειών.

Για τις επιχειρήσεις, ο ώριμος στόχος δεν είναι ούτε «όλα τα δεδομένα» ούτε «όσο λιγότερα γίνεται». Είναι το μικρότερο επαρκές, εκτελέσιμο, επιτρεπτό και ελέγξιμο σύνολο που επιτρέπει σωστή απάντηση. Αυτό απαιτεί metrics που ακολουθούν ολόκληρη τη διαδρομή: intent, tool selection, parameter validation, field projection, authorization, retrieval, answer και ανθρώπινη επαλήθευση.

Αν το schema graph παραμένει versioned, οι aliases συντηρούνται από domain owners και τα permissions επιβάλλονται έξω από το μοντέλο, η προσέγγιση μπορεί να γίνει χρήσιμο control point. Αν αντιμετωπιστεί μόνο ως τεχνική μείωσης tokens, κινδυνεύει να βελτιστοποιήσει το λάθος metric και να μεταφέρει την πολυπλοκότητα σε ένα registry που κανείς δεν αναλαμβάνει να διατηρεί.

Από το API inventory σε ελέγξιμο pilot

Σχεδιάστε AI agents που ζητούν τα σωστά δεδομένα

Η TWO DOTS χαρτογραφεί intents, εργαλεία, response fields, permissions, validation και monitoring, ώστε ένα AI workflow να μειώνει περιττό context χωρίς να χάνει κρίσιμη πληροφορία ή έλεγχο.

Често задавани въпроси

Τι είναι ο SchemaRouter;

Είναι μια ερευνητική routing layer που οργανώνει εργαλεία, endpoints, παραμέτρους, response fields και metadata σε schema graph και παράγει εκτελέσιμα tool plans.

Ποιο πρόβλημα προσπαθεί να λύσει;

Προσπαθεί να περιορίσει τόσο το over-fetching, που φέρνει περιττά εργαλεία ή πεδία, όσο και το under-fetching, που αφήνει έξω πληροφορία απαραίτητη για σωστή απάντηση.

Ποια διαφορά έχει από το vector similarity routing;

Η similarity μπορεί να βρει σχετικό εργαλείο, αλλά δεν εγγυάται έγκυρες παραμέτρους ή επαρκή response fields. Ο SchemaRouter εφαρμόζει ντετερμινιστική επιλογή πεδίων πάνω στο graph.

Τι αποτελέσματα πέτυχε στο benchmark;

Σε 110 ερωτήματα πέτυχε answer accuracy 0,71 με 227 retrieved-context tokens, tool-exact rate 0,93 και parameter validity 1,00 στον βασικό πίνακα της εργασίας.

Αποδεικνύεται ότι είναι ο πιο ακριβής router;

Όχι. Τα confidence intervals των κορυφαίων routers επικαλύπτονται. Η εργασία στηρίζει κυρίως πλεονέκτημα σε context efficiency, executable plans και provenance ή license metadata.

Γιατί το ελάχιστο πλήθος πεδίων είναι λάθος KPI;

Επειδή στο minimal-field operating point η accuracy έπεσε στο 0,56. Η προσθήκη recall-critical field groups την επανέφερε στο 0,71 με μικρή αύξηση από 188 σε 227 tokens.

Επιβάλλει ο SchemaRouter permissions και privacy;

Όχι από μόνος του. Το schema μπορεί να μεταφέρει σχετικά metadata, αλλά authorization, consent, data minimization και approval gates πρέπει να επιβάλλονται από policy και execution layers.

Ποιο είναι το πρώτο βήμα για ένα επιχειρηματικό pilot;

Επιλέξτε ένα περιορισμένο read-only intent, καταγράψτε τα απαραίτητα endpoints και fields και δημιουργήστε gold queries με σωστές απαντήσεις, αμφίσημες περιπτώσεις και ασφαλή αρνητικά παραδείγματα.

Информационен бюлетин

Въведете имейл адреса си по-долу, за да се абонирате за нашия бюлетин