Το Agentic RAG Είναι Ως Επί Το Πλείστον Latency Που Δεν Χρειάζεσαι
Το agentic RAG κάνει loop μέσα από hops ανάκτησης, καθένα round trip μοντέλου. Συνήθως κερδίζει ένα καλό query. Χρησιμοποίησε loop μόνο όταν αξίζει το latency.

Το agentic RAG αντικαθιστά μία ανάκτηση με ένα loop: το μοντέλο ανακτά, διαβάζει, αποφασίζει ότι χρειάζεται περισσότερα, ανακτά ξανά, και επαναλαμβάνει μέχρι να ικανοποιηθεί. Κάθε hop είναι ένα πλήρες round trip μοντέλου συν μια αναζήτηση, και τα hops είναι διαδοχικά επειδή το καθένα εξαρτάται από το προηγούμενο. Για τις περισσότερες ερωτήσεις, αυτό αγοράζει μια οριακά καλύτερη απάντηση σε πολλαπλάσιο latency, όταν ένα καλά κατασκευασμένο query θα είχε επιστρέψει το ίδιο context σε ένα μόνο πέρασμα. Η ανάκτηση πολλαπλών hops είναι ένα πραγματικό εργαλείο για μια στενή κατηγορία ερωτήσεων, και μια προεπιλογή που σιωπηλά τριπλασιάζει τον χρόνο απόκρισής σου παντού αλλού.
Το reframing: η agentic ανάκτηση ανταλλάσσει latency με την ικανότητα να αποσυνθέτεις μια ερώτηση την ώρα εκτέλεσης. Αυτή η ανταλλαγή αξίζει μόνο όταν η ερώτηση πραγματικά χρειάζεται αποσύνθεση. Οι περισσότερες δεν χρειάζονται, και το να πληρώνεις τον φόρο του loop σε ερωτήσεις που ένα μόνο query απαντά είναι ο πιο συχνός τρόπος τα συστήματα RAG να γίνονται αργά χωρίς κανένα όφελος.
Από πού προέρχεται το latency
Το single-pass RAG είναι ένα embedding, μία αναζήτηση vector, μία κλήση μοντέλου. Το agentic RAG είναι ένα loop, και το loop είναι σειριακό από κατασκευή: το μοντέλο δεν μπορεί να εκδώσει το δεύτερο query μέχρι να έχει διαβάσει τα αποτελέσματα του πρώτου. Οπότε το κόστος σε ρολόι τοίχου δεν είναι μία ανάκτηση συν μία παραγωγή, είναι το άθροισμα της αναζήτησης κάθε hop, της κλήσης μοντέλου κάθε hop για να αποφασίσει τι θα κάνει στη συνέχεια, και της τελικής παραγωγής. Τρία hops είναι περίπου τρεις φορές τα round trips, και επειδή κάθε κλήση μοντέλου ξαναδιαβάζει επίσης το συσσωρευμένο context, το κόστος ανά hop τείνει να μεγαλώνει αντί να μένει σταθερό.
Τίποτα από αυτά δεν είναι κρυφή δουλειά που ζήτησε ο χρήστης. Από τη δική του πλευρά είναι μία ερώτηση που τώρα διαρκεί οκτώ δευτερόλεπτα αντί για δύο. Αν αυτά τα οκτώ δευτερόλεπτα δεν αγόρασαν μια ουσιαστικά καλύτερη απάντηση, ξόδεψες το budget latency σου για το τίποτα.
Ένα καλό query νικά ένα έξυπνο loop, συνήθως
Ένα εκπληκτικό ποσοστό του agentic RAG υπάρχει για να αντισταθμίσει ένα αδύναμο πρώτο query. Αν η αρχική ανάκτηση τραβήξει τα λάθος κομμάτια, η δουλειά του loop γίνεται "παρατήρησε ότι το context είναι κακό και πήγαινε βρες καλύτερο context", που είναι ακριβή ανάκτηση από σφάλμα. Διόρθωσε το query και το loop συχνά δεν έχει τίποτα άλλο να κάνει.
Πριν στραφείς σε multi-hop, ξόδεψε την προσπάθεια στο μονό πέρασμα:
- Ξαναγράψε το query. Μία φθηνή κλήση μοντέλου για να μετατρέψεις μια ακατάστατη ερώτηση χρήστη σε ένα καθαρό query αναζήτησης βελτιώνει την ανάκτηση περισσότερο από ένα δεύτερο hop, με κλάσμα του latency.
- Ανάκτησε περισσότερα, μετά κάνε rerank. Τράβηξε ένα ευρύτερο σετ υποψηφίων σε μία αναζήτηση και κάνε rerank προς τα κάτω, αντί να κάνεις πολλές στενές αναζητήσεις στη σειρά.
- Διόρθωσε τα chunks. Η περισσότερη κακή ανάκτηση είναι πρόβλημα chunking. Καλύτερα chunks κάνουν το πρώτο query να πετύχει, και το loop γίνεται περιττό.
Αυτά είναι όλα βελτιώσεις μονού περάσματος. Ανεβάζουν την ποιότητα απάντησης χωρίς να προσθέτουν ένα σειριακό round trip, που είναι το αντίθετο από αυτό που κάνει το loop.
Πότε η agentic ανάκτηση πραγματικά κερδίζει
Το loop δικαιολογεί το latency του για ερωτήσεις που γνήσια δεν μπορούν να απαντηθούν από ένα query, γιατί το δεύτερο query εξαρτάται από την απάντηση του πρώτου. Η πιο ξεκάθαρη περίπτωση είναι το multi-hop reasoning πάνω σε γεγονότα που πρέπει να αλυσιδώσεις: "ποιοι από τους προμηθευτές μας στην περιοχή που επηρεάζεται από τον νέο κανονισμό είναι για ανανέωση αυτό το τρίμηνο" είναι στην πραγματικότητα τρία lookups όπου το καθένα στενεύει το επόμενο, και καμία μεμονωμένη ανάκτηση δεν κρατά την ενωμένη απάντηση.
Το πρότυπο που πρέπει να ψάξεις είναι μια γνήσια εξάρτηση ανάμεσα σε ανακτήσεις: δεν μπορείς να γράψεις το δεύτερο query μέχρι να ξέρεις το αποτέλεσμα του πρώτου. Όταν αυτή η εξάρτηση είναι πραγματική, το loop κάνει απαραίτητη δουλειά και το latency είναι το τίμημα μιας απάντησης που δεν θα μπορούσες να πάρεις αλλιώς. Όταν απουσιάζει, και συνήθως απουσιάζει, το loop είναι περίπλοκη μηχανική για μια ερώτηση που ένα μόνο query θα είχε κλείσει.
Αποφάσισε ανά ερώτηση, όχι ανά σύστημα
Η αποτυχία είναι να κάνεις την agentic ανάκτηση προεπιλογή για κάθε αίτημα. Ένας καλύτερος σχεδιασμός δρομολογεί: οι φθηνές ερωτήσεις παίρνουν το μονό πέρασμα, και μόνο ερωτήσεις που δείχνουν σήμα αποσύνθεσης, πολλαπλές οντότητες, μια αλυσιδωτή προϋπόθεση, ένα ρητό "σύγκρινε ανάμεσα σε", κλιμακώνονται στο loop. Ένας μικρός ταξινομητής ή ακόμα και μια ευρετική μπροστά από την ανάκτηση μπορεί να πάρει αυτή την απόφαση. Ο στόχος είναι να πληρώνεις τον φόρο multi-hop ακριβώς στις ερωτήσεις που τον ανταποδίδουν, και ποτέ σε αυτές που δεν τον ανταποδίδουν.
Το συμπέρασμα
Το agentic RAG δεν είναι λάθος, είναι υπερεφαρμοσμένο. Μετατρέπει την ανάκτηση σε ένα σειριακό loop από round trips μοντέλου, και για τη μεγάλη πλειοψηφία των ερωτήσεων που απαντά ένα καλό μονό query, αυτό το loop είναι καθαρό latency. Ξόδεψε την προσπάθειά σου πρώτα στο μονό πέρασμα: ξαναγράψε το query, ανάκτησε ευρύτερα και κάνε rerank, και διόρθωσε τα chunks. Κράτα το multi-hop για ερωτήσεις με πραγματική εξάρτηση ανάμεσα σε ανακτήσεις, και δρομολόγησε προς αυτό ανά ερώτηση αντί να κάνεις προεπιλογή ολόκληρο το σύστημα σε αυτό. Το ταχύτερο σύστημα RAG είναι αυτό που κάνει loop μόνο όταν η ερώτηση πραγματικά απαιτεί δεύτερη ματιά.
Διάβασε αυτό στη συνέχεια
- Knowledge Base Chunking Is Where Your RAG Quality Dies, για το πώς κάνεις το μονό πέρασμα αρκετά ισχυρό ώστε το loop να μην έχει τίποτα να διορθώσει.
- Semantic Caching: Two Different Questions, One Answer, για το πώς κόβεις εντελώς το round trip ανάκτησης για επαναλαμβανόμενες ερωτήσεις.
Για την υποδομή πίσω από ανάκτηση χαμηλού latency σε κλίμακα, οι σημειώσεις πεδίου cloud βρίσκονται στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.
Περισσότερα από τον Ercan
Δύο ακόμη ιστότοποι, ίδιος συγγραφέας, διαφορετικό έδαφος.
Cloud, AWS, EKS, Terraform, platform engineering.
Σημειώσεις πεδίου από συστήματα παραγωγής. EKS, IAM, Terraform σε κλίμακα οργανισμού, observability, βελτιστοποίηση κόστους.
Επισκεφθείτε ercan.cloud →Ο κόμβος. Σχετικά, συμβουλευτική, επικοινωνία.
Προσωπικός κόμβος και για τις δύο διαδρομές γραφής. Ποιος είμαι, πώς λειτουργεί η συμβουλευτική, πώς να επικοινωνήσετε.
Επισκεφθείτε ercanermis.com →