LangChain ή LlamaIndex για RAG: η προεπιλογή αλλάζει το latency

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

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

Γενική ενορχήστρωση ή αφετηρία από τα δεδομένα;

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

Στο LlamaIndex, το Document και τα Nodes δίνουν μια άμεση δομή για τη σχέση ανάμεσα στην πηγή και στα ανακτήσιμα τμήματά της. Η διαδρομή από τα δεδομένα προς το ερώτημα είναι κεντρική στον σχεδιασμό του, χωρίς αυτό να αποκλείει routers, σύνθετες στρατηγικές querying ή agents. Η χρήσιμη διάκριση, επομένως, είναι ποιο πρόβλημα χρειάζεται πρώτα να οργανώσεις: την προετοιμασία της γνώσης ή τη συμπεριφορά της συνολικής εφαρμογής.

Τι δείχνει —και τι δεν δείχνει— η μέτρηση χρόνου

Μια δημοσιευμένη δοκιμή της TildAlice αναφέρει μέσο χρόνο ερωτήματος 1,85 δευτερόλεπτα για διαμόρφωση LangChain 0.1.0 και 0,62 δευτερόλεπτα για διαμόρφωση LlamaIndex 0.9.28, σε σώμα 10.000 τεχνικών εγγράφων Markdown, με 94 επιτυχίες στις 100 ερωτήσεις για καθεμία. Οι αριθμοί αφορούν τις συγκεκριμένες ροές και τις παλιές εκδόσεις τους, όχι την αναμενόμενη επίδοση των σημερινών βιβλιοθηκών.

Στις ροές της δοκιμής χρησιμοποιήθηκαν το ίδιο μοντέλο embeddings και η ίδια μηχανή αναζήτησης FAISS, αλλά διαφορετικοί τρόποι σύνθεσης απάντησης: «stuff» και «compact». Ο συντάκτης αναφέρει ότι ο χρόνος της κλήσης στο γλωσσικό μοντέλο εξισώθηκε όταν περιόρισε το context της ροής LangChain. Αυτό αφορά εκείνο το επιμέρους βήμα· δεν τεκμηριώνει ότι εξαφανίστηκε και η διαφορά στον συνολικό χρόνο ερωτήματος.

Υπάρχει και ζήτημα συγκρισιμότητας στην περιγραφή του τεστ. Ο παρατιθέμενος κώδικας της μίας ροής χρησιμοποιεί το Python len για το μέγεθος των τμημάτων, ενώ η δημοσίευση περιγράφει τις ρυθμίσεις ως ίσες σε tokens. Επιπλέον, οι «επιτυχίες ανά ερώτηση» που περιγράφονται εκεί δεν αρκούν από μόνες τους για να υπολογιστεί το ποσοστό σχετικών αποτελεσμάτων σε κάθε πεντάδα. Τα στοιχεία είναι χρήσιμα ως υπόδειξη για το τι πρέπει να απομονωθεί σε μια νέα μέτρηση, όχι ως γενική κατάταξη ποιότητας ή ταχύτητας.

Η ποσότητα context δεν είναι απλή ρύθμιση ταχύτητας

Η τεκμηρίωση των response modes του LlamaIndex εξηγεί ότι το «compact» συσκευάζει ανακτημένο κείμενο στο διαθέσιμο παράθυρο context και, αν δεν χωρά σε ένα prompt, το χωρίζει για επεξεργασία με τη μέθοδο «refine». Δεν περιγράφεται ως απλή αποκοπή όλου του επιπλέον κειμένου. Αυτή η διάκριση έχει σημασία: η συσκευασία μπορεί να αλλάξει τόσο το μέγεθος του prompt όσο και τον αριθμό κλήσεων στο μοντέλο.

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

Πότε μετρά περισσότερο το ingestion και πότε οι agents

Όταν οι πηγές είναι PDF, ιστοσελίδες, βάσεις δεδομένων ή API, η δυσκολία συχνά εμφανίζεται πριν από την αναζήτηση. Τα έγγραφα πρέπει να μετατραπούν σε τμήματα που διατηρούν χρήσιμα μεταδεδομένα και σαφή σχέση με την πηγή τους. Σε τέτοιο έργο, το LlamaIndex είναι λογική πρώτη επιλογή για δοκιμή: η ποιότητα της ευρετηρίασης και η δυνατότητα να εντοπίσεις την προέλευση ενός ανακτημένου αποσπάσματος έχουν μεγαλύτερη σημασία από μια μικρή διαφορά στον χρόνο δημιουργίας του ευρετηρίου.

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

Η παρατηρησιμότητα είναι κριτήριο επιλογής και στις δύο περιπτώσεις. Η τεκμηρίωση παρατηρησιμότητας του LlamaIndex περιγράφει ίχνη για indexing και querying, καθώς και ενσωμάτωση με OpenTelemetry για επιμέρους στοιχεία της ροής RAG. Σε μια σύγκριση εργαλείων, σημασία έχει αν μπορείς να δεις τα ανακτημένα τμήματα, την είσοδο του μοντέλου και τον χρόνο κάθε βήματος: έτσι ξεχωρίζεις αστοχία ανάκτησης από καθυστέρηση στη σύνθεση της απάντησης.

Το πείραμα που βοηθά στην επιλογή

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

1. Χρησιμοποίησε τα ίδια έγγραφα και ένα σταθερό σύνολο ερωτήσεων με γνωστές σχετικές πηγές. Κατέγραψε τις εκδόσεις των πακέτων και τις συνθήκες εκτέλεσης, ώστε η σύγκριση να μπορεί να επαναληφθεί μετά από αναβάθμιση.
2. Κράτησε σταθερό το μοντέλο embeddings, την αποθήκη διανυσμάτων, τον τρόπο τεμαχισμού, την επικάλυψη και το πλήθος αποτελεσμάτων ανάκτησης. Αν μια ρύθμιση δεν αντιστοιχίζεται ακριβώς, δήλωσε τη διαφορά αντί να την αντιμετωπίσεις ως ισοδύναμη.
3. Χρησιμοποίησε το ίδιο γλωσσικό μοντέλο και αντίστοιχο prompt. Κατέγραψε τα tokens που στάλθηκαν πραγματικά, τα αποσπάσματα που ανακτήθηκαν και όσα μπήκαν τελικά στο context. Έλεγξε αν μια ταχύτερη απάντηση εξακολουθεί να στηρίζεται στις σωστές πηγές.
4. Μέτρησε χωριστά την εισαγωγή, την αναζήτηση, την προετοιμασία context και τις κλήσεις του μοντέλου. Παρουσίασε την ποιότητα ανάκτησης και απάντησης μαζί με τους χρόνους, ώστε η μείωση του latency να μην κρύβει απώλεια χρήσιμης πληροφορίας.

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

Διαβάστε επίσης:

• LangChain ή LlamaIndex: ο RAG κρίνεται πριν από το μοντέλο
• RAG ή fine-tuning: λάθος επιλογή αυξάνει και κόστος και λάθη
• Νέα ετικέτα για data centers: πάνω από 500 kW μπαίνουν σε αξιολόγηση