Πώς να κατασκευάσετε ένα αξιόπιστο RAG: Ένας βαθύς καταδυσμός σε 7 σημεία αποτυχίας και πλαισιά για αξιολόγηση

Retrieval-Augmented Generation (RAG) είναι κρίσιμο για τη σύγχρονη αρχιτεκτονική AI, υπηρετώντας ως ένα απαραίτητο πλαίσιο για την κατασκευή με επίγνωση πλαισίου agents.

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

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

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

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

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

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

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

FP1. Λείπων Περιεχόμενο

Το λείπων περιεχόμενο συμβαίνει όταν το σύστημα ζητείται να απαντήσει σε μια ερώτηση που δεν μπορεί να απαντηθεί επειδή η σχετική πληροφορία δεν είναι παρόντα στο διαθέσιμο vector store από την αρχή.

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

FP2. Missed Top-Ranked Documents

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

FP3. Not in Context (Consolidation Strategy Limitations)

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

FP4. Not Extracted

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

FP5. Wrong Format

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

FP6. Incorrect Specificity

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

FP7. Incomplete Answers

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

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

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

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

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

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

Εμποδισμοί Ανάκτησης και Απόδοσης

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

• FP2 (Missed Top-Ranked): Το μοντέλο ανάκτησης αποτυγχάνει να επιλέξει τα top-k embeddings.
• FP3 (Consolidation Strategy): Το σενάριο για την ενοποίηση αποκλείει τα πιο σημαντικά μέρη.

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

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

• FP5 (Wrong Format): Το LLM αποτυγχάνει να ακολουθήσει συγκεκριμένες οδηγίες μορφοποίησης.
• FP6 (Incorrect Specificity): Το 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. Ορίστε ένα κριτήριο για μέτρηση (π.χ. “συνέπεια”, “ρευστότητα” ή “π pertinence”).
2. Γεννήστε βήματα αξιολόγησης (χρησιμοποιώντας ένα LLM αξιολογητή).
3. Ακολουθήστε το βήμα αξιολόγησης και αναλύστε την είσοδο και την έξοδο του LLM.
4. Υπολογίστε ένα αναμενόμενο σταθμισμένο άθροισμα του σκορ κάθε κριτηρίου.

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

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

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

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

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

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

RAGAS – Ο Βελτιωτής του Αγκάθι

Το RAGAS στοχεύει στην αξιολόγηση του RAG χωρίς ανθρώπινα ετικετες datasets δημιουργώντας συνθετικά σεναριά δοκιμής.

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

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

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

• Πipeline ανάκτησης (μαύρο, στερεό, Σχήμα B): Precision του πλαίσιο, recall του πλαίσιο.
• Πipeline γεννήσεων (μαύρο, στιγμιαίο, Σχήμα B): Faithfulness, relevancy της απάντησης.
• Επίπεδο αλήθειας (κόκκινο κουτί, Σχήμα B): Ομοιότητα σημασιολογικής απάντησης, ορθότητα απάντησης.

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

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

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

TruLens – Ο Ειδικός του Βρόχου Ανταπόκρισης

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

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

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

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

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

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

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

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

Στο πλαίσιο της αξιολόγησης RAG, το Phoenix excels στο embedding analysis, χρησιμοποιώντας Uniform Manifold Approximation and Projection (UMAP) για να μειώσει τις υψηλοδιάστατες vector embeddings σε 2D/3D χώρο.

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

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

• Περίπτωση: Ένας bot υποστήριξης πελατών λειτουργεί καλά για επιστροφές, αλλά δίνει ανοησίες για αξιώματα εγγύησης.
• Πρόβλημα: Κενό δεδομένων στο vector database (Δεν μπορείτε να το βρείτε στα logs).
• Λύση: Χρησιμοποιήστε το Arize Phoenix για να δημιουργήσετε eine Umap Embedding Visualization (UEV), ένα 3D χάρτη για το vector database – για να επικαλύψουν τις ερωτήσεις του χρήστη στα document chunks.
• Αναμενόμενα αποτελέσματα: Οπτικά δείτε μια ομάδα ερωτήσεων του χρήστη που προσγειώνονται στη ζώνη όπου δεν υπάρχουν έγγραφα, που δείχνει ότι κάποια έγγραφα έχουν ξεχαστεί να ανεβούν στο vector store.

Braintrust – Το Δίκτυο Ασφαλείας της Πτώσης της Πρόκλησης

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

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

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

• Αναμενόμενο αποτέλεσμα: Ένα αναφορά διαφορών που δείχνει ακριβώς ποια περιπτώσεις έγιναν καλύτερες/χειρότερες για κάθε ένα από τα χρυσά dataset (N = 50).

Σύνοψη

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

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

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

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

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

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

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

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