Ένα RAG chatbot μπορεί να διαθέτει όλα τα σωστά έγγραφα και παρ' όλα αυτά να απαντά λάθος επειδή ανακτά λάθος αποσπάσματα. Το πρόβλημα συχνά δεν βρίσκεται στο model αλλά στο πώς κόπηκε, περιγράφηκε και ταξινομήθηκε η γνώση.
Το chunking δεν είναι απλή διαίρεση κάθε 800 tokens. Είναι απόφαση για το ποια πληροφορία πρέπει να ταξιδεύει μαζί ώστε ένα search result να είναι κατανοητό χωρίς ολόκληρο το αρχείο. Το hybrid search και το reranking συμπληρώνουν αυτή τη δουλειά, αλλά δεν διορθώνουν κακή δομή από μόνα τους.
Τι πρέπει να διατηρεί ένα chunk
Ένα καλό chunk έχει μία συνεκτική ιδέα και αρκετό context για να ερμηνευτεί. Συνήθως χρειάζεται:
- τίτλο εγγράφου και section hierarchy,
- κύριο κείμενο χωρίς επαναλαμβανόμενα headers και footers,
- metadata όπως προϊόν, έκδοση, γλώσσα και ημερομηνία ισχύος,
- source ID και θέση για citation,
- permissions ή tenant scope,
- σχέση με πίνακες, λίστες ή γειτονικά sections.
Αν μια παράγραφος λέει «ισχύει για 30 ημέρες» χωρίς το heading «Επιστροφές», το chunk χάνει το νόημά του. Μπορείτε να prepend hierarchy ή να χρησιμοποιήσετε structure-aware splitter ώστε το context να παραμένει.
Fixed-size και structure-aware chunking
Το fixed-size chunking είναι απλό και σταθερό. Λειτουργεί ικανοποιητικά σε ομοιόμορφα κείμενα, αλλά μπορεί να κόψει πρόταση, πίνακα ή διαδικασία στη μέση.
Το structure-aware chunking χρησιμοποιεί headings, paragraphs, lists, table boundaries ή JSON fields. Σε manuals, policies και FAQs συνήθως δίνει πιο νοηματικές μονάδες. Χρειάζεται όμως fallback για μεγάλα sections που ξεπερνούν το επιτρεπόμενο μέγεθος.
Για code ή API docs, το boundary μπορεί να είναι function, class ή endpoint. Για συμβάσεις, άρθρο και παράγραφος. Για tickets, conversation turn ή resolution summary. Δεν υπάρχει ένα chunk size για κάθε corpus.
Η OpenAI Retrieval API, για παράδειγμα, παρέχει προεπιλεγμένο μέγεθος και overlap αλλά επιτρέπει προσαρμογή της chunking strategy. Αυτό πρέπει να αντιμετωπίζεται ως baseline για evaluation, όχι ως καθολικά βέλτιστη τιμή.
Overlap με σκοπό
Το overlap βοηθά όταν η απάντηση εξαρτάται από κείμενο κοντά στο boundary. Μεγάλο overlap όμως αυξάνει storage, κόστος και duplicate results. Μπορεί επίσης να γεμίσει το context με τρεις σχεδόν ίδιες εκδοχές.
Χρησιμοποιήστε μικρό overlap για συνεχή αφήγηση και λιγότερο ή καθόλου όταν τα sections είναι αυτοτελή. Εναλλακτικά, αποθηκεύστε parent-child σχέση: αναζητάτε μικρό child chunk για ακρίβεια και επιστρέφετε μεγαλύτερο parent section για synthesis.
Μετρήστε duplicate retrieval rate και context diversity. Αν τα top 5 αποτελέσματα είναι παραλλαγές της ίδιας παραγράφου, το overlap ή το deduplication χρειάζεται διόρθωση.
Semantic search και keyword search
Το semantic search βρίσκει νοηματικά παρόμοιο κείμενο ακόμη κι αν δεν μοιράζεται τις ίδιες λέξεις. Είναι χρήσιμο όταν ο πελάτης λέει «πώς παίρνω τα χρήματά μου πίσω;» και το έγγραφο γράφει «διαδικασία επιστροφής χρημάτων».
Το keyword ή sparse search είναι ισχυρό για ακριβείς όρους: SKU, κωδικούς σφάλματος, άρθρα νόμου, ονόματα προϊόντων και acronyms. Ένα embedding μπορεί να υποβαθμίσει τον μοναδικό κωδικό ERR-142 επειδή δεν έχει πλούσιο semantic νόημα.
Το hybrid search συνδυάζει τα δύο rankings. Η τεκμηρίωση της OpenAI περιγράφει βάρη για semantic και text match μέσω reciprocal rank fusion. Στην πράξη, τα βάρη πρέπει να ρυθμίζονται με queries του δικού σας domain.
Metadata filtering πριν από το ranking
Η αναζήτηση πρέπει πρώτα να περιορίζεται στο επιτρεπόμενο corpus. Φίλτρα μπορεί να είναι tenant, role, product, country, language, effective date και document status.
Το metadata filtering δεν είναι απλώς optimization. Είναι security και correctness boundary. Ένα permission-aware RAG δεν ανακτά απαγορευμένα chunks και μετά ζητά από το model να τα αγνοήσει.
Προσέξτε την ποιότητα metadata. Αν η γλώσσα ή έκδοση λείπει από πολλά αρχεία, το αυστηρό filter μπορεί να αποκλείσει σωστές απαντήσεις. Χρειάζονται ingestion validation και reports για missing attributes.
Reranking των candidates
Το πρώτο search stage πρέπει να έχει καλό recall και να φέρνει αρκετούς candidates. Το reranker αξιολογεί πιο ακριβά τη σχέση query και chunk και επιλέγει τα καλύτερα για το context.
Το threshold απορρίπτει άσχετα αποτελέσματα, αλλά αν είναι πολύ υψηλό μπορεί να αφήσει την εφαρμογή χωρίς χρήσιμη πηγή. Η σωστή συμπεριφορά τότε είναι abstention ή διευκρίνιση, όχι απάντηση χωρίς grounding.
Μετά το reranking, εφαρμόστε diversity και deduplication. Μπορεί να χρειάζονται δύο διαφορετικές πηγές που καλύπτουν προϋποθέσεις και εξαίρεση, όχι πέντε αποσπάσματα από το ίδιο section.
Queries που χρειάζονται decomposition
Μια σύνθετη ερώτηση μπορεί να ζητά «ποια προϊόντα καλύπτονται και ποια είναι η προθεσμία;». Ένα μόνο embedding query ίσως ανακτήσει μόνο το ένα μέρος.
Ο query planner μπορεί να δημιουργήσει υποερωτήματα, να αναζητήσει κάθε πτυχή και να συγχωνεύσει αποτελέσματα. Χρειάζεται όριο ώστε να μην πολλαπλασιάζεται το κόστος και trace που δείχνει ποιο subquery έφερε κάθε chunk.
Για follow-up ερωτήσεις, δημιουργήστε standalone retrieval query από το conversation context χωρίς να αλλοιώνεται η πρόθεση. Μην βάζετε ολόκληρη τη συνομιλία αυτούσια στη semantic search.
Retrieval evals πριν από answer evals
Αν η τελική απάντηση είναι λάθος, πρέπει να γνωρίζετε αν έφταιξε το retrieval ή το generation. Δημιουργήστε dataset με query και expected source chunks ή documents.
Μετρήστε recall@k, precision@k, mean reciprocal rank και permission violations. Προσθέστε hard negatives: έγγραφα με παρόμοιες λέξεις αλλά άλλη έκδοση, χώρα ή προϊόν.
Μετά αξιολογήστε grounded answer και citations. Ένα answer eval δεν αντικαθιστά retrieval eval, επειδή το model μπορεί περιστασιακά να απαντήσει σωστά από prior knowledge παρότι ανακτήθηκε λάθος πηγή.
Freshness και επανευρετηρίαση
Κάθε chunk χρειάζεται document version και effective dates. Όταν αλλάζει ένα αρχείο, η παλιά έκδοση πρέπει να αφαιρείται ή να μαρκάρεται μη ενεργή atomically, ώστε να μη συνυπάρχουν αντιφατικές πολιτικές.
Το ingestion pipeline καταγράφει parse errors, chunk counts και index status. Μέχρι να ολοκληρωθεί η νέα ευρετηρίαση, το production σύστημα πρέπει να γνωρίζει ποια έκδοση είναι ενεργή.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry ξεκινάμε από τα είδη εγγράφων και τις πραγματικές ερωτήσεις χρηστών. Σχεδιάζουμε structure-aware chunking, metadata schema και permission filters πριν επιλέξουμε vector store ή model. Δοκιμάζουμε διαφορετικά sizes και overlap με retrieval evals.
Συνδυάζουμε semantic και keyword search, reranking, deduplication και citations, με trace που δείχνει γιατί επιλέχθηκε κάθε πηγή. Προσθέτουμε ασφαλή ingestion, versioning και abstention όταν δεν υπάρχει επαρκές context. Έτσι η Ai Foundry δημιουργεί RAG συστήματα που βρίσκουν την κατάλληλη παράγραφο και όχι απλώς ένα σχετικό αρχείο.
Checklist βελτίωσης
- Τα chunks ακολουθούν τη δομή του corpus;
- Διατηρούν headings, source και version metadata;
- Το overlap μετριέται για duplicates και κόστος;
- Συνδυάζονται semantic και exact keyword signals;
- Τα permission filters εφαρμόζονται πριν από retrieval;
- Υπάρχει reranking, threshold και diversity;
- Αξιολογείται retrieval ανεξάρτητα από την απάντηση;
- Οι παλιές εκδόσεις αποσύρονται με συνέπεια;
Το καλό RAG δεν ξεκινά από το prompt. Ξεκινά από το πώς οργανώνεται η γνώση και αν η αναζήτηση μπορεί να φέρει το σωστό, επιτρεπόμενο και ισχύον context τη στιγμή που χρειάζεται.