Όταν ένα σύστημα RAG δίνει λάθος ή μισή απάντηση, το μοντέλο συνήθως δεν φταίει. Φταίει το chunking. Αν το απόσπασμα που κρατά την απάντηση δεν φτάσει ποτέ στο ανακτημένο context, κανένα μοντέλο δεν μπορεί να απαντήσει από αυτό, και καμία ρύθμιση prompt δεν το αλλάζει αυτό. Το chunking αποφασίζει τι μπορεί να ανακτηθεί εν γένει, κάτι που το κάνει το πρώτο πράγμα που πρέπει να εξετάσεις και το τελευταίο που κοιτάζουν οι περισσότερες ομάδες.

Το Amazon Bedrock Knowledge Bases σου επιτρέπει να επιλέξεις μια στρατηγική chunking όταν δημιουργείς μια πηγή δεδομένων. Αυτή η μία επιλογή θέτει σιωπηλά το ταβάνι της ποιότητας ανάκτησής σου. Κάν' το λάθος και θα ξοδέψεις εβδομάδες κατηγορώντας το μοντέλο embedding, τον reranker ή το LLM για ένα πρόβλημα που ζει στο πώς κόβεις τα έγγραφα.

Γιατί το chunking είναι η φέρουσα απόφαση

Η ανάκτηση δουλεύει πάνω σε chunks, όχι έγγραφα. Κάθε chunk ενσωματώνεται σε ένα διάνυσμα, και τη στιγμή του ερωτήματος φέρνεις τα top-k chunks που είναι πλησιέστερα στην ερώτηση. Δύο μορφές αστοχίας προκύπτουν άμεσα από το μέγεθος του chunk.

Τα chunks που είναι πολύ μεγάλα αραιώνουν το embedding. Ένα chunk 2000 tokens που καλύπτει τέσσερα υποθέματα παράγει ένα διάνυσμα που είναι ο μέσος όρος και των τεσσάρων, οπότε ταιριάζει με όλα ασθενώς και με τίποτα δυνατά. Το σωστό chunk θάβεται κάτω από κοντινά-αλλά-όχι-ακριβώς ταιριάσματα. Τα chunks που είναι πολύ μικρά κόβουν το context. Ένας ορισμός χωρισμένος από το παράδειγμά του, ή ένα βήμα χωρισμένο από την προειδοποίησή του, ανακτάται καθαρά αλλά φτάνει χωρίς το περιβάλλον κείμενο που το έκανε χρήσιμο. Η απάντηση είναι τεχνικά παρούσα και πρακτικά ελλιπής.

Η δουλειά μιας στρατηγικής chunking είναι να κόβει σε ουσιαστικά όρια ώστε κάθε chunk να είναι μία συνεκτική ιδέα, αυτόνομη αρκετά για να απαντήσει και συγκεκριμένη αρκετά για να κατατάσσεται.

Οι τρεις στρατηγικές που σου δίνει το Bedrock

Fixed-size chunking

Χωρίζει κάθε N tokens με κάποια επικάλυψη. Είναι η προεπιλογή και η φθηνότερη, και είναι εντάξει για ομοιόμορφο, πεζολογικό περιεχόμενο όπου οι αλλαγές θέματος είναι σταδιακές. Είναι ενεργά κακή για δομημένα έγγραφα, γιατί κόβει όπου κι αν προσγειωθεί ο μετρητής tokens: στη μέση πίνακα, στη μέση λίστας, ανάμεσα σε επικεφαλίδα και την παράγραφο που εισάγει. Η επικάλυψη μαλακώνει τη ζημιά αλλά δεν την αφαιρεί. Χρησιμοποίησε fixed-size όταν το corpus σου είναι ομοιογενές και θέλεις μια βάση αναφοράς, όχι επειδή είναι η προεπιλογή.

Semantic chunking

Χωρίζει βάσει νοήματος. Το semantic chunking μετρά την ομοιότητα embedding ανάμεσα σε γειτονικές προτάσεις και ξεκινά νέο chunk εκεί όπου μετατοπίζεται το θέμα, οπότε τα όρια πέφτουν ανάμεσα σε ιδέες αντί σε σταθερό αριθμό tokens. Αυτή είναι η σωστή προεπιλογή για μεικτό περιεχόμενο: FAQ, άρθρα γνώσης, μεικτή πεζογραφία όπου κάθε απάντηση ή έννοια θέλει να παραμείνει ολόκληρη. Κοστίζει περισσότερο να χτίσεις τον δείκτη γιατί κάνει embedding ενώ κόβει, αλλά η διαφορά στην ποιότητα ανάκτησης σε ετερογενή corpora είναι ο λόγος να το πληρώσεις.

Hierarchical chunking

Χτίζει γονικά και θυγατρικά chunks. Τα μικρά θυγατρικά chunks γίνονται embed και ταιριάζονται για ακριβή ανάκτηση, αλλά το μεγαλύτερο γονικό chunk είναι αυτό που επιστρέφεται στο μοντέλο, οπότε κατατάσσεις με βάση την ειδικότητα και απαντάς με context. Αυτό ταιριάζει σε έγγραφα με πραγματική δομή, τεχνικά εγχειρίδια, νομικά συμβόλαια, οτιδήποτε έχει ενότητες και υποενότητες, όπου ένα ερώτημα χτυπάει μια στενή ρήτρα αλλά το μοντέλο χρειάζεται την περιβάλλουσα ενότητα για να τη χρησιμοποιήσει σωστά. Είναι το πιο περίπλοκο να το σκεφτείς και η καλύτερη επιλογή όταν τα έγγραφά σου έχουν γνήσια ιεραρχία προς αξιοποίηση.

Αξιολόγησε την ανάκτηση πριν κατηγορήσεις το μοντέλο

Η πιο χρήσιμη συνήθεια είναι να ξεχωρίσεις το ερώτημα ανάκτησης από το ερώτημα παραγωγής. Πριν αγγίξεις το prompt ή αλλάξεις μοντέλο, ρώτα ένα πράγμα: για ένα σύνολο πραγματικών ερωτήσεων, εμφανίστηκε το chunk που περιέχει την απάντηση στο ανακτημένο context;

  • Χτίσε ένα μικρό σύνολο αξιολόγησης: 30 έως 50 πραγματικές ερωτήσεις, καθεμία με το απόσπασμα πηγή που την απαντά.
  • Τρέξε μόνο την ανάκτηση. Για κάθε ερώτηση, έλεγξε αν το σωστό απόσπασμα εμφανίζεται στα top-k αποτελέσματα. Αυτό το ποσοστό επιτυχίας είναι το ταβάνι ανάκτησής σου.
  • Αν το σωστό απόσπασμα δεν ανακτάται, η ποιότητα παραγωγής είναι άσχετη. Η διόρθωση είναι στο chunking, στα embeddings ή στο top-k, όχι στο μοντέλο.
  • Μόνο αφού η ανάκτηση φέρνει αξιόπιστα το σωστό απόσπασμα, βγάζει νόημα να δουλέψεις στο πώς το χρησιμοποιεί το μοντέλο.

Οι περισσότερες ομάδες προσπερνούν αυτό και πηδάνε κατευθείαν στο prompt engineering, γι' αυτό ξοδεύουν τόσο χρόνο σε ένα πρόβλημα που μια μέτρηση ποσοστού επιτυχίας ανάκτησης θα εντόπιζε σε ένα απόγευμα. Αν η ανάκτηση χάνει την απάντηση στη μισή περίπτωση, έχεις πρόβλημα chunking ντυμένο σαν πρόβλημα μοντέλου.

Ένα πρακτικό σημείο εκκίνησης

Ξεκίνα με semantic chunking για γενικό περιεχόμενο γνώσης, πέρνα σε hierarchical όταν τα έγγραφά σου έχουν σαφή δομή ενοτήτων και οι απαντήσεις εξαρτώνται από το περιβάλλον context, και κράτα το fixed-size μόνο για μεγάλη, ομοιόμορφη πεζογραφία όπου θέλεις ταχύτητα και απλότητα. Μετά μέτρησε το ποσοστό επιτυχίας ανάκτησης, άλλαξε μία μεταβλητή, και μέτρησε ξανά. Το chunking δεν είναι μια ρύθμιση που ορίζεις μία φορά και ξεχνάς. Είναι το κουμπί με τη μεγαλύτερη επιρροή στο αν το σύστημα RAG σου αξίζει.

Το συμπέρασμα

Η ποιότητα του RAG αποφασίζεται πριν καν τρέξει το μοντέλο, τη στιγμή που κόβεις τα έγγραφά σου σε chunks. Το fixed-size είναι μια βάση αναφοράς, το semantic είναι η λογική προεπιλογή για μεικτό περιεχόμενο, και το hierarchical κερδίζει όταν η δομή έχει σημασία. Μέτρησε το ποσοστό επιτυχίας ανάκτησης πάνω σε ένα πραγματικό σύνολο ερωτήσεων πρώτα, γιατί αν η απάντηση δεν μπαίνει ποτέ στο context, το μοντέλο ποτέ δεν ήταν το πρόβλημα.

Διαβάστε στη συνέχεια

Για την πλευρά αποθήκευσης και υποδομής της εκτέλεσης vector search σε κλίμακα, οι σημειώσεις πεδίου cloud είναι στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.