Řeší ještě někdo zastaralé odpovědi v RAG systémech? Jak zvládáte aktuálnost informací?

Tohle je jeden z nejčastějších problémů při implementaci RAG. Tohle jsem se naučila z desítek podnikových nasazení:

Jádro problému: Embedding modely samy o sobě čas nechápou. Dokument z roku 2023 a 2026 může mít téměř shodné embeddingy, pokud se týkají stejného tématu, i když se informace úplně liší.

Co skutečně funguje:

1. Hybridní skórování – Kombinujte sémantickou podobnost (cosinová vzdálenost) s funkcí poklesu podle času. Obvykle používáme: final_score = semantic_score * (0.7 + 0.3 * recency_score)

2. Verzování dokumentů – Při aktualizaci dokumentu jej nepřepisujte, ale ponechte verze a poslední výslovně označte jako “aktuální” pomocí filtrování v metadatech.

3. Časové členění chunků – Přidejte datum dokumentu ke každému chunku, nejen k hlavnímu dokumentu. LLM tak získá časový kontext.

Váš postup s metadaty s časovým razítkem funguje jen tehdy, pokud je vaše retrieval pipeline skutečně využívá pro filtrování nebo přeskórování. Mnohé výchozí konfigurace je ignorují.

Pohled z pohledu obsahu, nikoliv techniky.

Měli jsme stejný problém a zjistili jsme, že částečně je to organizační otázka, nejen technická. Naši autoři sice aktualizovali dokumenty, ale ne podle konzistentního procesu, který by RAG systém mohl sledovat.

Co jsme zavedli:

• Každý dokument má povinné pole “naposledy ověřeno” (oddělené od “naposledy upraveno”)
• Vlastníci obsahu dostávají automatická připomenutí na čtvrtletní ověření správnosti
• Dokumenty starší než 6 měsíců bez ověření jsou označeny a při retrievalu znevýhodněny
• Přidali jsme explicitní vztahy typu “nahrazuje”, když je obsah aktualizován

Technické řešení je důležité, ale pokud nemáte pevné řízení obsahu, budete mít problémy s aktuálností pořád.

Klíčová metrika: Sledujeme “míru zastaralých retrievalů” – procento retrievalů, kdy existoval novější obsah, ale nebyl vrácen. Snížili jsme to z 23 % na 4 % za tři měsíce.

U nás se osvědčil tento vzorec:

Dvoufázové vyhledávání:

Fáze 1: Tradiční sémantické hledání pro top-K kandidátů (K=50-100) Fáze 2: Re-ranker, který zohledňuje relevanci I aktuálnost

Re-ranker je malý jemně doladěný model, který se učí z uživatelské zpětné vazby, které výsledky byly skutečně užitečné. Postupně se sám naučí, které typy obsahu musí být aktuální a které tolik ne.

Zavedli jsme také dashboard na audit aktuálnosti, který ukazuje:

• Průměrné stáří získaných dokumentů
• Témata, kde je často získáván starý obsah
• Dokumenty, které jsou často retrievalovány, ale málokdy označeny jako užitečné

Díky tomu jsme problémová místa odhalili proaktivně, místo abychom čekali na stížnosti uživatelů.

Pohled z menší firmy – jsme 20členný startup bez dedikované ML infrastruktury.

Šli jsme jednoduchou cestou: vynucená re-indexace přes webhooky při změně obsahu místo plánovaných batch jobů. Jakmile se v našem CMS aktualizuje dokument, okamžitě se spustí re-embedding a aktualizace indexu.

Pro náš rozsah (5 000 dokumentů) je to dostatečně rychlé a zajišťuje nulové zpoždění mezi aktualizací obsahu a retrievalem.

Zjistili jsme také, že výslovné verzování přímo v obsahu pomáhá LLM. Přidáním “Aktualizováno leden 2026” do prvního odstavce dokumentu LLM ví, že může jít o starší verzi, a zmíní případnou nejistotu.

Ve velkém podnikovém měřítku to řešíme jinak:

Skutečný problém není retrieval – je to zjištění, kdy je obsah opravdu neaktuální. Dokument z roku 2020 může být stále správný, zatímco ten z minulého měsíce už ne.

Náš postup: Automatizované ověřování platnosti obsahu

Každou noc spouštíme joby, které:

1. Porovnávají získaný obsah s autoritativními zdroji
2. Označí dokumenty, kde se změnila klíčová fakta
3. Automaticky upozorní vlastníky obsahu
4. Dočasně znevýhodní označený obsah při retrievalu

U produktového obsahu jsme se napojili přímo na produktovou databázi. Jakákoliv změna v databázi, ceny nebo funkcích automaticky spustí revizi obsahu.

Náklady na špatné informace pro zákazníky mnohonásobně převyšují investici do monitoringu aktuálnosti.

Tohle téma je velmi aktuální i u externích AI systémů.

Pokud řešíte aktuálnost ve svém interním RAG, zamyslete se, co se děje s ChatGPT, Perplexity a Google AI Overviews, které citují váš veřejný obsah.

Výzkumy ukazují, že ChatGPT cituje obsah, který je v průměru o 393 dní aktuálnější než tradiční výsledky Google. Pokud je váš veřejný obsah zastaralý, AI systémy buď:

1. Necitují vás vůbec
2. Citují zastaralé informace o vaší firmě

Já k monitoringu využívám Am I Cited, kde sleduji, kdy AI systémy citují obsah našich klientů a které stránky. Bylo šokující vidět, jak přímo aktuálnost ovlivňuje AI viditelnost.

U veřejného obsahu platí stejné principy – AI systémy preferují aktuálnost a zastaralý obsah postupně přichází o citace.

Praktický tip, který nám pomohl: logujte vše.

Přidali jsme logování, které sleduje:

• Stáří každého retrievalnutého dokumentu
• Zda byl dokument označen jako “aktuální” nebo “archivovaný”
• Spokojenost uživatelů v závislosti na stáří obsahu

V Grafaně máme dashboard se všemi těmito daty. Ukázalo se, že problém zastaralého obsahu byl koncentrován jen ve 3 produktových oblastech, kde autoři už ve firmě nebyli. Neměli jsme systémový problém retrievalu – měli jsme problém s vlastnictvím obsahu.

Data nám pomohla prosadit nábor člověka na údržbu obsahu.

Tahle diskuze mi neskutečně pomohla. Shrnu, co si odnáším:

Technická zlepšení:

1. Zavést hybridní skórování s poklesem podle času
2. Přidat verzování dokumentů s explicitními “aktuálními” flagy
3. Zvážit dvoufázové vyhledávání s re-rankingem
4. Vytvořit dashboardy pro monitoring aktuálnosti

Procesní zlepšení:

1. Workflow ověřování obsahu odděleně od editace
2. Automatická detekce zastaralosti proti autoritativním zdrojům
3. Jasné vlastnictví obsahu a zodpovědnosti za aktualizace
4. Re-indexace přes webhooky pro rychlejší propagaci změn

Měřené metriky:

• Míra zastaralých retrievalů
• Průměrné stáří získaných dokumentů
• Korelace spokojenosti uživatelů se stářím obsahu

Začnu hybridním skórováním a workflow ověřování obsahu. Za pár týdnů podám report, jaké to má výsledky.