Πώς να δημιουργήσετε αξιόπιστο RAG: επτά σημεία αποτυχίας και πλαίσια αξιολόγησης

Retrieval-Augmented Generation (RAG) είναι κρίσιμο για τη σύγχρονη αρχιτεκτονική AI, λειτουργώντας ως απαραίτητο πλαίσιο για τη δημιουργία πρακτόρων που λαμβάνουν υπόψη τα συμφραζόμενα.

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

Αυτό το άρθρο εξετάζει σε βάθος επτά τυπικά σημεία αποτυχίας RAG και τις μετρικές αξιολόγησης με πρακτικά παραδείγματα κώδικα.

Η Ανατομία της Αποτυχίας του RAG – 7 Σημεία Αποτυχίας (FPs)

Σύμφωνα με τους ερευνητές Barnett και συνεργάτες, συστήματα Retrieval Augmented Generation (RAG) αντιμετωπίζουν επτά συγκεκριμένα Σημεία Αποτυχίας (FPs) καθ’ όλη τη διάρκεια του pipeline.

Το παρακάτω διάγραμμα εικονογραφεί αυτά τα στάδια:

Σχήμα A. Διαδικασίες ευρετηρίασης και υποβολής ερωτημάτων για τη δημιουργία συστήματος RAG. Η ευρετηρίαση γίνεται κατά την ανάπτυξη και τα ερωτήματα κατά την εκτέλεση. Τα σημεία αποτυχίας της μελέτης εμφανίζονται σε κόκκινα πλαίσια (πηγή)

Ας εξετάσουμε κάθε FP με τη σειρά, ακολουθώντας την προοδευτική σειρά από την πάνω αριστερή προς την κάτω δεξιά που εμφανίζεται στο Σχήμα A.

FP1. Ελλιπές περιεχόμενο

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

Η αποτυχία συμβαίνει όταν ένα LLM παρέχει μια απάντηση που ακούγεται πιθανή αλλά λανθασμένη αντί να δηλώσει δεν ξέρει.

FP2. Το σωστό έγγραφο δεν εμφανίζεται στις πρώτες θέσεις

Αυτή είναι μια κατάσταση όπου ένα σωστό έγγραφο υπάρχει στο διανυσματικό αποθετήριο, αλλά ο retriever αποτυγχάνει να το κατατάξει αρκετά ψηλά για να το συμπεριλάβει στα top-k έγγραφα που παρέχονται σε ένα LLM ως πλαίσιο.

Ως αποτέλεσμα, η σωστή πληροφορία δεν φτάνει ποτέ στο LLM.

FP3. Εκτός πλαισίου (περιορισμοί της στρατηγικής ενοποίησης)

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

Αυτό συμβαίνει όταν επιστρέφονται υπερβολικά πολλά έγγραφα και το σύστημα πρέπει να τα περιορίσει ώστε να τηρούνται το παράθυρο πλαισίου του LLM, τα όρια token ή τα όρια ρυθμού κλήσεων.

FP4. Η πληροφορία δεν εξάγεται

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

Αυτό συμβαίνει όταν το πλαίσιο περιέχει υπερβολικό θόρυβο ή αντιφατικές πληροφορίες που μπερδεύουν το LLM.

FP5. Λανθασμένη μορφή

Αυτή είναι μια κατάσταση όπου η αποθήκευση, η ανάκτηση, η ενοποίηση και η ερμηνεία του LLM είναι επιτυχείς, αλλά το LLM αποτυγχάνει να ακολουθήσει συγκεκριμένες οδηγίες μορφοποίησης που παρέχονται στην προτροπή, όπως έναν πίνακα, μια λίστα με κουκκίδες ή ένα σχήμα JSON.

FP6. Ακατάλληλο επίπεδο λεπτομέρειας

Το LLM παράγει πράγματι έξοδο, αλλά αυτή είναι είτε πολύ γενική είτε πολύ σύνθετη σε σύγκριση με τις ανάγκες του χρήστη.

Για παράδειγμα, το LLM δίνει απλές απαντήσεις σε ερώτηση χρήστη που επιδιώκει σύνθετο επαγγελματικό στόχο.

FP7. Ελλιπείς απαντήσεις

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

Για παράδειγμα, όταν ο χρήστης θέτει μια σύνθετη ερώτηση όπως «Ποια είναι τα κύρια σημεία στα έγγραφα A, B και C;», το LLM καλύπτει μόνο μία ή δύο από τις πηγές.

Πώς τα FPs επηρεάζουν την Απόδοση του RAG Pipeline

Κάθε ένα από αυτά τα FPs επηρεάζει την απόδοση του RAG pipeline:

Αποτυχίες ακεραιότητας δεδομένων και εμπιστοσύνης

Όταν οι πληροφορίες λείπουν ή είναι λανθασμένες, το σύστημα παύει να αποτελεί αξιόπιστη πηγή πληροφοριών. Τα κύρια FPs περιλαμβάνουν:

• FP1 (Ελλιπές περιεχόμενο): Η απάντηση δεν είναι στο έγγραφο από την αρχή.
• FP4 (Η πληροφορία δεν εξάγεται): Το LLM αποφασίζει να αγνοήσει τη σωστή απάντηση στο έγγραφο.
• FP7 (Ελλιπές): Το LLM παρέχει μισές αλήθειες και παραλείπει σημαντικές πληροφορίες.

Σημεία συμφόρησης στην ανάκτηση και την αποδοτικότητα

Το RAG pipeline μπορεί να είναι αναποτελεσματικό όταν λείπουν κρίσιμες πληροφορίες στη διαδικασία ανάκτησης και ενοποίησης. Τα κύρια FPs περιλαμβάνουν:

• FP2 (Ανεπαρκής κατάταξη): Το μοντέλο ενσωμάτωσης δεν επιλέγει τις top-k διανυσματικές αναπαραστάσεις.
• FP3 (Στρατηγική ενοποίησης): Το script που περικόπτει τα έγγραφα ώστε να χωρούν στα όρια του LLM απορρίπτει τα σημαντικότερα τμήματα.

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

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

• FP5 (Λανθασμένη μορφή): Το LLM δεν ακολουθεί τη συγκεκριμένη μορφή εξόδου, όπως JSON.
• FP6 (Ακατάλληλο επίπεδο λεπτομέρειας): Το LLM παράγει μια εκτεταμένη έξοδο για μια απλή ερώτηση ναι/όχι, ή αντίστροφα (πολύ σύντομη απάντηση σε μια σύνθετη ερώτηση).

Το Πλαίσιο Αξιολόγησης: Πλαίσια για την Μείωση των FPs

Οι μετρικές αξιολόγησης έχουν σχεδιαστεί για να μειώσουν συστηματικά αυτά τα FPs.
Αυτή η ενότητα εξετάζει τις κύριες μετρικές αξιολόγησης RAG με πρακτικά παραδείγματα.

Κύριες μετρικές αξιολόγησης RAG:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Ο έλεγχος μονάδας πριν από τη διάθεση σε παραγωγή

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

Ένα LLM-as-a-judge (π.χ. GPT-4o) αξιολογεί κάθε κριτήριο έναντι της εξόδου του LLM:

Το DeepEval αξιοποιεί το G-eval, ένα πλαίσιο chain-of-thought (CoT) που ακολουθεί προσέγγιση πολλών βημάτων για την αξιολόγηση της εξόδου:

1. Ορίστε ένα κριτήριο για μέτρηση (π.χ. “συνέπεια”, “γλωσσική ευχέρεια” ή “συνάφεια”).
2. Δημιουργήστε βήματα αξιολόγησης (χρησιμοποιώντας ένα LLM αξιολογητή).
3. Ακολουθήστε τα βήματα αξιολόγησης και αναλύστε την είσοδο και την έξοδο του LLM.
4. Υπολογίστε ένα αναμενόμενο σταθμισμένο άθροισμα του σκορ κάθε κριτηρίου.

Κοινή Περίπτωση στην Πραγματικότητα

• Περίπτωση: Ένας βοηθός τεχνικής τεκμηρίωσης (bot) για ένα σύνθετο προϊόν λογισμικού φαίνεται να λειτουργεί κάθε φορά που η ομάδα μηχανικών ενημερώνει τη βάση κώδικα.
• Πρόβλημα: Δεν υπάρχει ποσοτική απόδειξη αν ο βοηθός μπορεί ακόμα να απαντήσει στην ερώτηση του χρήστη (Απλά “πιστεύετε” ότι λειτουργεί…).
• Λύση: Εισαγάγετε μια συνάρτηση PyTest ως σύνολο παλινδρόμησης CI/CD στο GitHub Actions όπου το DeepEval εκτελεί G-Eval και άλλες μετρικές πάνω σε ένα σενάριο δοκιμής:

• Αναμενόμενα αποτελέσματα: Αν το σκορ οποιασδήποτε μετρικής πέσει κάτω από το όριο (0,85), το PyTest εγείρει AssertionError – προκαλώντας άμεσα αποτυχία του CI build και αποτρέποντας μια απαρατήρητη υποβάθμιση από το να φτάσει στην παραγωγή.

Σημείωση προγραμματιστή – Το σύνολο δοκιμών για το DeepEval
Ένα σύνολο αντικειμένων LLMTestCase ορίζει το σύνολο δοκιμών που εκτελεί το DeepEval.

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

Αυτά μπορούν να ανακτηθούν από ένα αρχείο JSON ή CSV.

RAGAS – Βελτιστοποίηση της αναζήτησης βελόνας στα άχυρα

Το Retrieval Augmented Generation Assessment (Ragas) επιδιώκει να αξιολογεί το RAG χωρίς σύνολο δεδομένων επισημασμένο από ανθρώπους, δημιουργώντας συνθετικά σύνολα δοκιμών.

Στη συνέχεια, υπολογίζει τις μετρικές:

Σχήμα B. Διάγραμμα της τριάδας αξιολόγησης RAGAS, που συνδέει Ερώτηση, Πλαίσιο και Απάντηση μέσω των μετρικών Ακρίβεια, Ανάκληση, Πιστότητα και Συνάφεια (δημιουργία: Kuriko IWAI)

Οι μετρικές κατηγοριοποιούνται σε τρεις ομάδες:

• Ροή ανάκτησης (μαύρη συνεχής γραμμή, Σχήμα B): Ακρίβεια του πλαισίου, ανάκληση του πλαισίου.
• Ροή παραγωγής (μαύρη διάστικτη γραμμή, Σχήμα B): Πιστότητα, συνάφεια της απάντησης.
• Δεδομένα αναφοράς (κόκκινο κουτί, Σχήμα B): Σημασιολογική ομοιότητα της απάντησης, ορθότητα απάντησης.

Κοινή Περίπτωση στην Πραγματικότητα

• Περίπτωση: Το σύστημα RAG για νομικές συμβάσεις παραλείπει κρίσιμες ρήτρες. Δεν είστε βέβαιοι αν το πρόβλημα είναι στην Αναζήτηση (Retriever) ή την Ανάγνωση (Generator).
• Πρόβλημα: Δεν υπάρχει ιδέα για το βέλτιστο top-k (αριθμός ανακτώμενων αποσπασμάτων).
• Λύση: Χρησιμοποιήστε το RAGAS για να δημιουργήσετε ένα συνθετικό σύνολο δοκιμών με 100 ζευγάρια ερωτήσεων και αποδείξεων. Στη συνέχεια, εκτελέστε το RAG pipeline στο σύνολο δοκιμών για να υπολογίσετε την ακρίβεια και την ανάκληση του πλαισίου:
• Αναμενόμενο αποτέλεσμα: Ανάλογα με τα αποτελέσματα της μετρικής, το σχέδιο δράσης μπορεί να είναι το ακόλουθο:

Πίνακας 1. RAGAS: Αντιστοίχιση διαγνωστικών βαθμολογιών σε σχέδιο δράσης – Χαρτογράφηση Σκορ σε Ρυθμίσεις Συστήματος.

TruLens – Ο ειδικός του βρόχου ανατροφοδότησης

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

Χρησιμοποιεί επίσης μια βαθμολογία που βασίζεται σε LLM που αντανακλά πόσο καλά η απάντηση ικανοποιεί την πρόθεση της ερώτησης, χρησιμοποιώντας μια τετραβάθμια κλίμακα Likert (0-3), καθιστώντας το ανώτερο για κατάταξη της ποιότητας των διαφορετικών αποτελεσμάτων αναζήτησης.

Κοινή Περίπτωση στην Πραγματικότητα

• Περίπτωση: Ένα bot ιατρικών συμβουλών απαντά σωστά στην ερώτηση του χρήστη, αλλά προσθέτει μια συμβουλή που δεν υπάρχει στην ελεγμένη συλλογή PDF.
• Πρόβλημα: Η πρόσθετη συμβουλή μπορεί να είναι χρήσιμη, αλλά δεν τεκμηριώνεται από τις πηγές.
• Λύση: Χρησιμοποιήστε το TruLens για να εφαρμόσετε μια συνάρτηση ανατροφοδότησης που ελέγχει την τεκμηρίωση στις πηγές με ένα όριο όπως score > 0.8.

• Αναμενόμενα αποτελέσματα: Όταν το LLM παράγει μια απάντηση που περιέχει πληροφορίες που δεν υπάρχουν στο ανακτημένο απόσπασμα, το TruLens επισημαίνει την εγγραφή στον πίνακα ελέγχου σας.

Arize Phoenix – Ο Χάρτης Αποτυχίας

Το Arize Phoenix είναι εργαλείο ανοικτού κώδικα για την παρατηρησιμότητα και την αξιολόγηση των εξόδων LLM, συμπεριλαμβανομένων σύνθετων συστημάτων RAG.

Χτισμένο στο OpenTelemetry από την Arize AI, εστιάζει στην παρατηρησιμότητα των LLM, αντιμετωπίζοντας την αξιολόγησή τους ως υποσύνολο των MLOps.

Στο πλαίσιο της αξιολόγησης RAG, το Phoenix υπερέχει στην ανάλυση ενσωματώσεων, χρησιμοποιώντας Uniform Manifold Approximation and Projection (UMAP) για να μειώσει τις διανυσματικές αναπαραστάσεις πολλών διαστάσεων σε χώρο δύο ή τριών διαστάσεων.

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

Κοινή Περίπτωση στην Πραγματικότητα

• Περίπτωση: Ένα bot υποστήριξης πελατών λειτουργεί καλά για επιστροφές, αλλά δίνει ανοησίες για αξιώσεις εγγύησης.
• Πρόβλημα: Κενό δεδομένων στη διανυσματική βάση δεδομένων (Δεν μπορείτε να το βρείτε στα logs).
• Λύση: Χρησιμοποιήστε το Arize Phoenix για να δημιουργήσετε μια οπτικοποίηση ενσωματώσεων UMAP (UEV), έναν τρισδιάστατο χάρτη της διανυσματικής βάσης δεδομένων, ώστε να τοποθετήσετε τις ερωτήσεις των χρηστών πάνω στα αποσπάσματα των εγγράφων.
• Αναμενόμενα αποτελέσματα: Εντοπίζετε οπτικά μια ομάδα ερωτήσεων χρηστών σε μια σκοτεινή ζώνη χωρίς έγγραφα, ένδειξη ότι ξεχάσατε να ανεβάσετε ορισμένα έγγραφα στο διανυσματικό αποθετήριο.

Braintrust – Το δίχτυ ασφαλείας κατά της υποβάθμισης των προτροπών

Το Braintrust έχει σχεδιαστεί για συχνούς κύκλους επανάληψης χρησιμοποιώντας συγκριτική ανάλυση μοντέλων.

Κοινή Περίπτωση στην Πραγματικότητα

• Περίπτωση: Μια ομάδα μηχανικών αναβαθμίζει την προτροπή από “Απάντηση στην ερώτηση” (Περίπτωση A) σε μια πιο σύνθετη οδηγία συστήματος 500 λέξεων (Περίπτωση B).
• Πρόβλημα: Η βελτίωση της προτροπής για την Περίπτωση B μπορεί να προκαλέσει αστοχία στην Περίπτωση A.
• Λύση: Χρησιμοποιήστε το Braintrust για να δημιουργήσετε ένα σύνολο δεδομένων αναφοράς με ένα σύνολο N τέλειων παραδειγμάτων (π.χ. N = 50). Βάλτε το Braintrust να εκτελεί σύγκριση δίπλα-δίπλα (SxS) κάθε φορά που η ομάδα αναβαθμίζει μια λέξη στην προτροπή:

• Αναμενόμενο αποτέλεσμα: Μια αναφορά διαφορών που δείχνει ακριβώς ποιες περιπτώσεις του συνόλου αναφοράς (N = 50) βελτιώθηκαν ή χειροτέρεψαν.

Σύνοψη

Με κατάλληλα πλαίσια αξιολόγησης, το RAG μπορεί να αποτελέσει ανταγωνιστικό εργαλείο για την παροχή σε ένα LLM του πιο σχετικού πλαισίου για την ερώτηση του χρήστη.

Στρατηγική Εφαρμογής: Αντιστοίχιση μετρικών σε Σημεία Αποτυχίας

Αν και δεν υπάρχει μια λύση που να ταιριάζει σε όλα, ο Πίνακας 2 δείχνει ποιες μετρικές αξιολόγησης να εφαρμόσετε για κάθε FP που καλύψαμε σε αυτό το άρθρο:

Πίνακας 2. Η Μήτρα Αποτυχίας – Ποιο Εργαλείο Λύνει Ποιο FP;

Το DeepEval και το RAGAS μπορούν να αξιοποιήσουν τις μετρικές πιστότητας για να μετρήσουν τις αποτυχίες ακεραιότητας δεδομένων (FP1, FP4, FP7).

Το TruLens αξιοποιεί την ακρίβεια / ανάκληση του πλαισίου για να μετρήσει τη συνάφεια του πλαισίου με την έξοδο – αποτελεσματικά αξιολογώντας FP2.

Το Arize Phoenix παρέχει έναν οπτικό χάρτη της διαδικασίας ανάκτησης, καθιστώντας εύκολο να δείτε αν το έγγραφο που ανακτήθηκε χάθηκε κατά τη διαδικασία ενοποίησης (FP3).

Για σφάλματα UX, το DeepEval δημιουργεί προσαρμοσμένες μετρικές για την αξιολόγηση σφαλμάτων UX, ενώ το Braintrust υπερέχει στη σύγκριση συνόλων δεδομένων αναφοράς.