Tvoj RAG store hnije — a oprava je čo si necháš, nie lepšie vyhľadávanie

Tvrdenie. Väčšina RAG systémov je vyladená na vyhľadávanie a potichu zanedbáva rozpad — a práve to, nie embedding model, ich v produkcii kazí. Vektorový store, ktorý si navždy drží každý chunk, vyhadzuje minuloštvrťročné ceny, servíruje zmazanú politiku a účet rastie aj na nezmenených dátach. Ale riešením nie je ani lepší vyhľadávací model: je to čo si necháš. Rankuj čo si nechať podľa hodnoty a udržíš takmer všetku hodnotu, na ktorej záleží; čisti len podľa recency a necháš si sotva viac než polovicu.

Čo sme odmerali. Postavili sme najmenší poctivý model toho rozhodnutia a spustili férový súboj na store s 1 000 chunkami so známou skutočnou hodnotou, pri tesnom 50 % keep-budgete (každá stratégia nechá presne 500). Skóre je % oproti „nechaj najlepšie podľa skutočnej hodnoty" oracle, priemer cez 20 seedov (sd ~1–2 %). Hlavný režim je realistický: vek obsahu sleduje hodnotu (čerstvejší obsah býva hodnotnejší).

Tým rozdielom je vedomie hodnoty, nie čerstvosť. Hodnotovo-vedomá keep-politika udrží zhruba 1,5–1,8× toľko hodnoty, na ktorej záleží, ako len-recency čistenie (t. j. o ~50–80 % viac). A všimni si, že čerstvosť keep-rankovaniu sotva pomáha: len-hodnota (100 %) je už na strope a pridanie čerstvostného člena (95 %) je neutrálne až mierne záporné. V najhoršom režime, kde je vek obsahu nezávislý od hodnoty, len-recency spadne na 56 % — štatisticky na úrovni náhody — kým len-hodnota ostáva 100 % a hits-proxy drží ~90 %.

Priznaj oracle. Čísla ~95–100 % „s labelmi" predpokladajú, že vieš oskórovať skutočnú hodnotu chunku. V produkcii to zvyčajne nevieš. Takže realistické, pozorovateľné číslo je hits-proxy na ~90–91 % — tlmený náhradník počtu prístupov, takmer taký dobrý ako len-hodnotové optimum. V skoršej verzii tohto textu sme sa mýlili, keď sme access-frequency nazvali „nesprávnym signálom": benchmark to vyvracia. Keď nemáš hodnotové labely, tlmený hit-count je silný proxy — presne to je LFU-s-agingom / LFUDA. Poctivá výhrada: hit-count sleduje hodnotu len keď popularita koreluje s hodnotou (často áno, nie vždy).

Kde si čerstvosť reálne zaslúži miesto. Nie v keep-rankovaní — na dvoch iných miestach. (a) Staleness multiplikátor pri dopyte: rankuj čerstvé chunky nad stale pri vyhľadávaní, bez mazania čohokoľvek. (b) Životný cyklus: označ orphan vektory (zmazaný zdroj) na odstránenie a stale-ale-hodnotné chunky na refresh — zlyhania, ktoré čisté ladenie vyhľadávania nikdy nezachytí. Ber čerstvosť ako vrstvu pri dopyte a životnom cykle, nie ako to, čo vyhráva keep-benchmark.

Druhý, samostatný výsledok: naplánuj čistenie. Spúšťaj ho ako periodickú dávku, nie per-write hook. V samostatnom spustiteľnom labe kontinuálne per-write prerezávanie kúpi len ~8 % náskok v kvalite vyhľadávania (signál vs balast), ale platí ~25× viac pruning eventov, takže keď má pruning event akúkoľvek réžiu, naplánovaný prechod vyhráva na net (analytický crossover ≈ 0,07 réžie/event). Toto je merané oddelene od keep-ranking benchmarku.

FalzifikátorKeby len-recency politika udržala rovnako veľa skutočnej hodnoty ako hodnotovo-vedomá politika pri tesnom budgete, rankovanie podľa hodnoty by bolo zbytočné. Nedrží: 62 % (a 56 % v najhoršom prípade) vs 100 % pri 50 % budgete. A keby kontinuálne per-write prerezávanie porazilo periodickú dávku na net keď má pruning réžiu, pravidlo „naplánuj to" by bolo zlé — merané, prehráva.

Nie nová metóda. Jednotlivé nápady sú zavedené: GDSF cost-aware caching, LFU-aging pre zlyhanie frekvencia-vs-hodnota a temporal-RAG / staleness decay. Pridávame integrovaný nástroj bez závislostí a meranú porovnávaciu štúdiu. Pozri prior art nižšie.

Nástroj. Zabalili sme to ako ragfresh — jeden súbor bez závislostí, ktorý zoberie metadáta tvojich chunkov (kedy bol aktualizovaný, naposledy použitý, počet zásahov, či zdroj ešte existuje) a vráti per-chunk plán: keep, down-weight, refresh, alebo prune — plus query-time staleness multiplikátor, aby čerstvé chunky rankovali nad stale bez mazania. Je to decay/konsolidačné jadro, ktoré beží našej vlastnej výskumnej pamäti nad ~5 800 poznámkami, nasmerované na vektorové stores. Open-core; jadro ostáva zadarmo. Keep-ranking benchmark vyššie (arms hodnota / recency / hits) reprodukuješ jedným príkazom (python ragfresh.py); číslo batch-vs-hook je samostatný lab. Čísla si over sám — o to ide.

FAQ

Prečo sa môj RAG systém zhoršuje v produkcii? Zvyčajne rozkladom, nie embedding modelom. Vektorový store, ktorý si necháva každý chunk navždy, vynáša ceny spred štvrťroka, podáva zmazanú politiku a naháňa účet, ktorý rastie aj na nezmenených dátach — osirené vektory, zastarané odpovede, nafúknuté náklady.

Je pákou čerstvosť, alebo lepší vyhľadávací model? Ani jedno — je to vedomie hodnoty v tom, čo si necháš. Rankovanie čoho si nechať podľa hodnoty udrží ~100 % dosiahnuteľnej hodnoty pri 50 % budgete; hodnotovo-slepé len-recency čistenie udrží len ~56–62 % (blízko náhody, keď vek obsahu nesleduje hodnotu). To je porovnanie keep/eviction, nie tvrdenie o kvalite vyhľadávania či embeddingov. Čerstvosť samotná keep-rankovanie sotva mení (len-hodnota ~100 % vs blend hodnota+čerstvosť ~95 %).

Nie je access-frequency nesprávny signál? Nie — to bolo zle a opravili sme to. Tlmený hit-count proxy udrží ~90–91 % (surový hit-count ~92 %), blízko len-hodnotového optima, takže keď nemáš hodnotové labely, je to silný náhradník (to je LFU-s-agingom / LFUDA). Výhrada: hit-count sleduje hodnotu len keď popularita koreluje s hodnotou — zvyčajne áno, nie vždy.

Čo mám reálne zmeniť? Rankuj čo si nechať podľa hodnoty (alebo tlmeného hit-count proxy, ak nemáš hodnotové labely) namiesto ponechávania všetkého alebo čistenia len podľa recency. Čerstvosť používaj ako staleness multiplikátor pri dopyte a na označenie osirených vektorov (zmazaný zdroj) a stale-ale-hodnotných chunkov na refresh. Pozn.: čísla ~90–100 % s labelmi predpokladajú, že vieš oskórovať hodnotu chunku; v produkcii je realistické, pozorovateľné číslo hit-count proxy ~90–91 %.

Súvisiaci výskum

• Zabíja dlhý kontext RAG? Odmerali sme to
• Čo má AI agent zabudnúť? Dve vrstvy bijú každé jediné pravidlo
• Multi-hop recall na LoCoMo: daj model do vyhľadávacej slučky

Prior art

Eviction hodnota+čerstvosť v ragfresh je rodina GreedyDual-Size-Frequency (GDSF) / cost-aware caching; zlyhanie „frekvencia ≠ hodnota" je učebnicový problém LFU cache-pollution a opravou je LFU-Aging / LFUDA. Pozri Cao & Irani (1997, GreedyDual-Size, USENIX); Cherkasova (1998, GDSF, HP Labs); Young (2002, GreedyDual); Arlitt et al. (2000, LFU-DA, „Evaluating content management techniques for web proxy caches"). Pre vrstvu čerstvosti/decay pozri literatúru temporal-RAG / staleness — FreshLLMs / FreshQA (Vu et al. 2023, arXiv:2310.03214). ragfresh je zabalená, spustiteľná aplikácia cost-aware (GDSF) eviction + temporal decay na vektorové stores — nie nová metóda. Jednotlivé nápady sú zavedené (GDSF cost-aware caching; LFU-aging; temporal-RAG); pridávame integrovaný nástroj bez závislostí a meranú porovnávaciu štúdiu.