Ένα μεγάλο context window είναι ένα όριο χωρητικότητας, όχι μια στρατηγική retrieval. Το ότι ένα μοντέλο δέχεται αρκετές εκατοντάδες χιλιάδες tokens δεν σημαίνει ότι τα διαβάζει με ομοιόμορφη προσοχή, και σίγουρα δεν σημαίνει ότι πρέπει να πληρώνεις για να τα στέλνεις. Κάθε long-context benchmark που μπήκε στον κόπο να μετρήσει θέση και μήκος λέει το ίδιο πράγμα: η ακρίβεια πέφτει καθώς μεγαλώνει η είσοδος, και τα στοιχεία που είναι θαμμένα στη μέση ενός prompt χρησιμοποιούνται λιγότερο.

Η επανατοποθέτηση που αξίζει να εσωτερικεύσεις: το context window είναι ένα budget που ξοδεύεις, όχι μια βάση δεδομένων που κάνεις query. Οι ομάδες που το αντιμετωπίζουν σαν αποθήκευση χτίζουν συστήματα πιο αργά, πιο ακριβά και λιγότερο ακριβή από το retrieval pipeline που παρέκαμψαν.

Οι δύο τρόποι αποτυχίας είναι διαφορετικοί

Αυτά συχνά μπερδεύονται, και έχουν διαφορετικές λύσεις.

  • Υποβάθμιση θέσης. Το φαινόμενο lost-in-the-middle από τους Liu et al. (2023): η ακρίβεια είναι υψηλότερη όταν το σχετικό απόσπασμα βρίσκεται στην αρχή ή στο τέλος της εισόδου και βουλιάζει στη μέση, παράγοντας μια καμπύλη σχήματος U. Μετακίνησε το ίδιο γεγονός από την άκρη στο κέντρο και η ποιότητα της απάντησης πέφτει, παρόλο που τίποτα άλλο δεν άλλαξε.
  • Υποβάθμιση μήκους. Η ακρίβεια μειώνεται όσο μεγαλώνει η είσοδος, ακόμα κι όταν τα στοιχεία είναι σταθερά και ευνοϊκά τοποθετημένα. Επακόλουθη έρευνα όπως το RULER (Hsieh et al., 2024) δοκίμασε long-context μοντέλα σε εργασίες multi-needle και reasoning-over-context και διαπίστωσε ότι το πραγματικό μήκος context είναι σταθερά μικρότερο από τον διαφημιζόμενο αριθμό.

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

Γιατί ο αριθμός του benchmark παραπλανεί

Το τεστ needle-in-a-haystack κέρδισε τη δημοτικότητά του επειδή είναι εύκολο να τρέξει και εύκολο να περάσει. Κρύβεις μια εκτός τόπου πρόταση σε διάφορα βάθη μέσα σε ένα μεγάλο έγγραφο, ζητάς από το μοντέλο να την επαναλάβει, σχεδιάζεις ένα πράσινο grid. Ένα μοντέλο μπορεί να σκοράρει σχεδόν τέλεια σε αυτό και παρόλα αυτά να αποτύχει σε αυτό που πραγματικά χρειάζεσαι, γιατί οι πραγματικές ερωτήσεις δεν είναι λεξικές αναζητήσεις.

Οι χρήστες σου ρωτούν πράγματα που απαιτούν να βρεις τέσσερα σχετικά γεγονότα διάσπαρτα σε ένα corpus, να παρατηρήσεις ότι δύο από αυτά έρχονται σε αντίθεση, και να συλλογιστείς πάνω στα υπόλοιπα. Αυτό είναι το task που μετράει το RULER, και εκεί είναι που το διαφημιζόμενο window και το χρησιμοποιήσιμο window αποκλίνουν. Αντιμετώπισε την ανάκληση single-needle σαν smoke test, όχι σαν απόδειξη ότι το window δουλεύει.

Η πλευρά του κόστους δεν είναι λεπτή

Η υποβάθμιση του retrieval είναι συζητήσιμη. Ο λογαριασμός δεν είναι. Τα input tokens χρεώνονται ανά κλήση, οπότε ένας σχεδιασμός που στριμώχνει 200.000 tokens context σε κάθε αίτημα πληρώνει και τα 200.000 κάθε φορά, είτε η απάντηση χρειαζόταν δώδεκα από αυτά είτε κανένα.

# Stuff-the-window: whole handbook, every turn
200,000 input tokens x 50,000 calls/month = 10,000,000,000 tokens

# Retrieve-then-answer: system prompt + 6 chunks
  3,000 input tokens x 50,000 calls/month =    150,000,000 tokens

Αυτό είναι παράγοντας εξήντα έξι στη γραμμή εισόδου, πριν καν υπολογίσεις το latency. Το time to first token κλιμακώνεται ανάλογα με το πόσο πρέπει να διαβάσει το μοντέλο, οπότε το στριμωγμένο prompt είναι και το πιο αργό. Πληρώνεις περισσότερο για μια χειρότερη απάντηση, που παραδίδεται αργότερα. Δεν υπάρχει άξονας στον οποίο αυτό κερδίζει.

Το prompt caching περιπλέκει την αριθμητική σε μία συγκεκριμένη περίπτωση: ένα γνήσια σταθερό prefix που επαναλαμβάνεται σε κάθε κλήση μπορεί να διαβαστεί με μεγάλη έκπτωση. Αυτό είναι πραγματικό, και αξίζει να το χρησιμοποιείς. Όμως σώζει το κόστος ενός στατικού preamble, όχι την ανάκληση μιας πρησμένης θημωνιάς. Ένα cached κακό prompt είναι απλώς ένα φθηνότερο κακό prompt.

Τι να κάνεις αντ' αυτού

Η πειθαρχία είναι άχαρη και δουλεύει.

  • Κάνε retrieve, μετά απάντησε. Βάλε ένα βήμα retrieval μπροστά από το μοντέλο και πέρασε τα λίγα καλύτερα chunks. Ένα Bedrock Knowledge Base το κάνει αυτό χωρίς να χρειάζεται να διαχειρίζεσαι εσύ ένα index. Έξι καλά chunks νικούν εξακόσια μέτρια, κάθε φορά.
  • Κάνε rank, και εννόησέ το. Αν περνάς δέκα chunks, η σειρά έχει σημασία γιατί η θέση έχει σημασία. Βάλε το ισχυρότερο στοιχείο στην κορυφή και το επόμενο ισχυρότερο στο κάτω μέρος, εκεί όπου η προσοχή είναι καλύτερη. Γέμισε τη μέση με το οριακό υλικό, όχι με το γεγονός που κρατάει το βάρος.
  • Βάλε όριο σε ό,τι μπορεί να δει κάθε βήμα. Ένα αυστηρό ανώτατο όριο tokens ανά κλήση αναγκάζει το retrieval layer να είναι επιλεκτικό. Χωρίς όριο, το context μεγαλώνει μέχρι να σπάσει κάτι, συνήθως τη χειρότερη στιγμή.
  • Κάνε cache το σταθερό prefix, όχι το μεταβλητό σώμα. Το system prompt και τα tool schemas είναι ίδια σε κάθε κλήση και ανήκουν στο cache. Τα ανακτημένα στοιχεία αλλάζουν ανά ερώτηση και δεν ανήκουν.
  • Μέτρα την ανάκληση στις δικές σου ερωτήσεις. Τρέξε τα πραγματικά σου queries πάνω στο πραγματικό σου corpus και βαθμολόγησε τις απαντήσεις. Οι ισχυρισμοί των προμηθευτών για το μήκος context είναι ένας αριθμός marketing· το δικό σου eval είναι το μόνο που περιγράφει το δικό σου σύστημα.

Πότε το μεγάλο window είναι η σωστή απάντηση

Υπάρχουν περιπτώσεις όπου το να γεμίσεις το window είναι σωστό, και το να αρνηθείς από αρχή είναι το δικό σου λάθος. Η σύνοψη ενός μοναδικού εγγράφου από την αρχή ως το τέλος χρειάζεται ολόκληρο το έγγραφο· δεν υπάρχει τίποτα να κάνεις retrieve γιατί όλα είναι σχετικά. Ο συλλογισμός που απαιτεί να κρατάς ολόκληρη μια codebase ή ένα συμβόλαιο υπόψη ταυτόχρονα χρειάζεται γνήσια αυτό το εύρος. Η εφάπαξ ανάλυση όπου το να μηχανικοποιήσεις ένα retrieval pipeline κοστίζει περισσότερο από τα tokens είναι μια καλή περίπτωση για να είσαι σκόπιμα τεμπέλης.

Το τεστ είναι αν μπορείς να ονομάσεις το υποσύνολο που έχει σημασία. Αν μπορείς, κάνε το retrieve. Αν γνήσια δεν μπορείς, επειδή η εργασία αφορά ολόκληρο το corpus και όχι ένα κομμάτι του, τότε το window κάνει πραγματική δουλειά και πρέπει να το χρησιμοποιήσεις.

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

Τα μεγαλύτερα context windows είναι ένα πραγματικό επίτευγμα μηχανικής, και συνεχίζουν να μεγαλώνουν. Είναι επίσης ο πιο ακριβός τρόπος να αποφύγεις να γράψεις ένα βήμα retrieval. Η ανάκληση υποβαθμίζεται με το μήκος και με τη θέση, ο λογαριασμός κλιμακώνεται με κάθε token που στέλνεις, και το latency ακολουθεί το μέγεθος του prompt. Αποφάσισε τι χρειάζεται να δει το μοντέλο, στείλε αυτό, και σταμάτα να μπερδεύεις τη χωρητικότητα με την επάρκεια.

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

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