Hybrid Search a Reranking pro AI chatboty: lepší výsledky RAG

Weboví chatboti málokdy selžou kvůli tomu, že by báze znalostí vůbec neobsahovala potřebné informace. Častěji krok vyhledávání (retrieval) nenajde pasáž, která odpovídá dotazu a konkrétnímu kontextu. Návštěvníci používají názvy produktů, chybové hlášky a čísla artiklů, ale zároveň se ptají velmi volně: „Proč chatbot zobrazuje špatný tarif?“ nebo „Mohu ještě změnit již odeslanou objednávku?“ Pro tuto směs nestačí jako univerzální odpověď ani čistě klíčové slovo, ani čistě vektorové vyhledávání. Hybrid Search kombinuje oba signály, aby RAG chatbot získal do kontextu své odpovědi spolehlivější zdroje.

Vyhledávání podle klíčových slov a vektorové vyhledávání plní různé úkoly

Vyhledávání podle klíčových slov je silné, pokud se slova musejí shodovat přesně. To platí pro čísla objednávek, označení produktů, konkrétní chybové hlášky, názvy smluv nebo verze jako „2.4“. Dokáže přehledně ukázat, proč daný dokument odpovídá: Hledané slovo se nachází v názvu, v nadpisu nebo v dané pasáži. Jeho slabina se projevuje u běžného jazyka, synonym a neúplných formulací. Dotaz návštěvníka na „kopii faktury“ pak nemusí nutně najít stránku, která hovoří pouze o „stažení dokladu“.

Vektorové vyhledávání tuto mezeru doplňuje. Reprezentuje dotaz a obsah jako sémantickou blízkost, a proto dokáže najít podobné záměry, i když chybí stejné pojmy. To pomáhá u přirozeně formulovaných dotazů podpory, cizojazyčných variant a různých označení pro stejný postup. Sémantická blízkost však sama o sobě není volnou vstupenkou: Pasáž sice může být tématu podobná, ale může se týkat jiné verze produktu, jiného trhu nebo neplatného pravidla. Přesně proto patří kontrola kontextu do retrieval pipeline a ne až k jazykovému modelu.

Proč je Hybrid Search smysluplným výchozím bodem

Microsoft popisuje Hybrid Search jako společný dotaz s celotextovou a vektorovou částí. Oba dotazy probíhají paralelně a jejich seznamy výsledků se následně sloučí. To je pro firemní weby atraktivní, protože zůstávají zachována přesná označení a zároveň jsou dostupné příbuzné, dobře formulované obsahy. Chatbot nemusí nechat návštěvníky vybírat mezi „technickým“ a „sémantickým“ vyhledáváním. Výběr probíhá v pozadí a lze jej pro všechny dotazy kontrolovat stejným procesem kvality.

Hybrid Search zlepšuje množinu kandidátů; nevytváří však absolutní pravdu. Chatbot smí používat pouze obsah, který je schválen pro konkrétní situaci. Veřejné webové stránky, interní koncepty a chráněná zákaznická data nepatří do jednoho nekontrolovaného kontextu. Stejně důležité je jasné chování v případě, kdy není k dispozici žádný vhodný zdroj: Doplňující dotaz, odkaz na kontaktní stránku nebo Human Handoff jsou bezpečnější než plynule formulovaná domněnka.

RRF srozumitelně: Slučování pořadí

Skóre z celotextového a vektorového vyhledávání mají různé významy a měřítka. Jejich přímé sčítání nebo vymýšlení pevné mezní hodnoty často vede k nestabilním výsledkům. Reciprocal Rank Fusion, zkráceně RRF, proto pracuje s pozicí dokumentu v jednotlivých žebříčcích. Dokument, který se v obou seznamech objeví vysoko, získá silný kombinovaný signál. Dokument, který je viditelný pouze v jednom seznamu, může být také zohledněn, ale nemůže automaticky vytlačit vše ostatní.

RRF není magická výchozí hodnota ani náhradní vzorec pro odborné testy. Kolik kandidátů z každého vyhledávání se dostane do fúze, které filtry zaberou předem a kdy je výsledek vůbec považován za použitelný, závisí na obsahu a riziku. Pro časté dotazy k produktům může mít smysl malé, zaměřené okno. Pro složité návody nebo diagnostiku chyb může být potřeba více kandidátů. Rozhodující je porovnat změnu s reálnými dotazy oproti testovací sadě, místo přebírání univerzálního parametru z nějakého příkladu.

Sémantický Reranking jako druhý, omezený stupeň

Po dobrém předvýběru může reranker užší množinu kandidátů ještě jednou vyhodnotit vůči celému dotazu. Microsoft zařazuje sémantické rankování jako sekundární rankování nad již předběžně seřazeným seznamem výsledků. Amazon Bedrock popisuje reranking odpovídajícím způsobem jako hodnocení textových dokumentů z hlediska jejich relevance k dotazu. Tento druhý stupeň je vhodný pro dotazy s více podmínkami: Například zda je možná změna tarifu poté, co již byla objednávka odeslána a jedná se o určitý typ smlouvy.

Reranking by měl být vědomě omezen. Zvyšuje latenci a v závislosti na službě může být zpoplatněný. Nedávejte proto rerankeru celou bázi znalostí, ale pouze již vyfiltrovanou a sloučenou top množinu. Definujte časový rozpočet a fallback. Pokud je rozpočet překročen, může chatbot například zobrazit nejspolehlivější seznam zdrojů, požádat o upřesnění nebo předat konverzaci týmu podpory. Reranker neopraví zastaralý, chybějící nebo neschválený obsah.

Filtry metadat chránící kontext

Metadata často rozhodují o kvalitě odpovědi více než další možnost v nastavení modelu. Udržujte u každého zdroje minimálně jazyk, produkt nebo službu, verzi, trh, cílovou skupinu a platnost, pokud jsou tyto údaje pro použití relevantní. Filtr na správného klienta nebo oblast oprávnění musí zabrat ještě před výstupem. Na veřejném webu může chatbot načítat pouze veřejný obsah; pro přihlášenou oblast platí navíc ověřitelná oprávnění.

I čas je otázkou metadat. Ceníky, dodací podmínky a návody by měly mít jasné datum aktualizace nebo kontrolovaný stav platnosti. Pokud zdroj již není důvěryhodný, patří pryč z indexu nebo do samostatného schvalovacího procesu. Filtry musejí odrážet požadavky, které jsou pro návštěvníky pochopitelné, nikoli tajně manipulovat s pořadím. Dokumentujte proto, které filtry platí pro které třídy dotazů a jak tým kontroloval změny.

Konkrétní pipeline od dotazu po kontext

1. Normalizujte dotaz: Rozpoznejte jazyk a zjevný kontext, aniž byste zbytečně ukládali nebo měnili osobní údaje.
2. Zkontrolujte přístup a metadata: Pustíte-li se do retrievalu, určete předem, které zdroje jsou povoleny pro daný produkt, trh, roli a období platnosti.
3. Paralelní načtení: Proveďte celotextové a vektorové vyhledávání nad stejnou množinou povolených zdrojů.
4. Sloučení pořadí: Skombinujte seznamy pomocí RRF a u každého kandidáta zachovejte původní signály pro debugging.
5. Omezený reranking: Hodnocení relevance provádějte pouze na malé top množině a měřte latenci.
6. Zabezpečte kontext: Zkontrolujte duplicitu, stav zdrojů a přiměřenou délku, než pasáže pošlete do modelu pro generování odpovědi.
7. Odpověď s hranicemi: Dokládejte zdroje, označte nejistotu a v případě potřeby použijte bezpečné předání na člověka.

Příklad z praxe: Stav zásilky a změna tarifu

Předpokládejme, že se návštěvník ptá: „Mohu ještě změnit svůj tarif, i když je balíček již na cestě?“ Vyhledávání podle klíčových slov možná najde stránku „Změnit tarif“ a článek podpory s textem „Balíček na cestě“. Vektorové vyhledávání najde průvodce, který tento postup popisuje jako změnu po odeslání. RRF posune nahoru dokumenty, které propojují oba aspekty. Reranker pak může zkontrolovat, zda relevantní pasáž skutečně obsahuje kombinaci tarifu a dopravy.

Před odpovědí vyfiltrujte výsledky podle dotčeného trhu, produktové řady a aktuálního stavu platnosti. Pokud si zdroje protiřečí nebo chybí potřebné detaily, chatbot by neměl vyvozovat závěry z podobných případů. Může transparentně říci, která podmínka zůstává otevřená, a navést návštěvníka na vhodnou, ověřenou možnost kontaktu. Konverzace tak zůstane užitečná, aniž by si vymýšlela nepodložené přísliby.

Případy No-Result a debugging skóre

Stav No-result je často signálem pro mezeru ve znalostech, nikoli pro nefunkční vyhledávání. Rozlišujte proto minimálně čtyři případy: Neexistuje žádný povolený zdroj, existují zdroje, ale žádný dostatečně odpovídající výsledek, dotaz je nejednoznačný, nebo technická chyba brání retrievalu. Každý případ vyžaduje vlastní, srozumitelnou reakci. „K tomuto tématu nenalézám ve schválených informacích žádnou spolehlivou odpověď“ je upřímnější než generická věta bez dalšího kroku.

Pro debugging samotná finální skóre nestačí. Pro každý testovací dotaz by týmy měly mít možnost vidět, které filtry zabraly, které dokumenty přišly z klíčových slov a z vektorového vyhledávání, jak byly sloučeny a zda reranking změnil pořadí. Ukládejte přitom pouze data nezbytná pro kvalitu a zpracovaná s ohledem na datovou úspornost. Hledejte vzorce: Chybí určitá synonyma? Překrývá starý zdroj nový obsah? Vybočuje některá lokalizace z logiky metadat? Teprve konkrétní příčina rozhodne o tom, zda je třeba změnit chunking, metadata, správu zdrojů nebo ranking.

Testovací sada, metriky a nákladový rozpočet

Malý Golden Set s 30 až 50 realistickými dotazy je dobrý začátek. U každého dotazu uveďte očekávané zdroje, neprípustné zdroje a požadovanou reakci při chybějících znalostech. Měřte odděleně, zda se správný zdroj nachází mezi kandidáty, zda je řazen dostatečně vysoko a zda finální odpověď používá pouze podložené informace. Vědomě doplňte překlepy, přesné pojmy, přirozené formulace, vícejazyčnost a kritické negativní případy.

Během jednoho testovacího běhu změňte pouze jednu proměnnou: filtr, počet kandidátů, hloubku rerankingu nebo strukturu chunků. Poznamenejte si také dobu odezvy a počet externích volání modelu. Vyšší hodnota relevance může být nepoužitelná, pokud odpověď přijde příliš pozdě nebo pokud vzrostou náklady na časté standardní dotazy. Definujte proto rozpočet na latenci a náklady pro každou třídu dotazů. Rychlé, dobře podložené standardní odpovědi a konzervativní předání na podporu mají pro mnoho webů větší hodnotu než maximálně složitý ranking.

Typické chyby při zavádění

• Přímé porovnávání surových skóre z klíčových slov a vektorů, přestože jejich měřítka nejsou stejná.
• Indexování konceptů, starých ceníků nebo chráněného obsahu bez filtrů stavu a oprávnění.
• Aplikace rerankingu na příliš mnoho kandidátů, což vedek neřízené latenci a nákladům.
• Považování dema s několika dobrými dotazy za dostatečný důkaz kvality.
• Při chybějícím zdroji vygenerování věrohodně znějící odpovědi namísto přiznání nejistoty, doplňujícího dotazu nebo předání na člověka (handoff).
• Absence verzování změn ve zdrojích, chunkingu a rankingu, což znemožňuje jejich pozdější vysvětlení.

Kontrolní seznam pro zavedení

• Před indexováním stanovte povolené zdroje a hranice oprávnění.
• Spravujte metadata pro jazyk, produkt, verzi, trh a platnost.
• Paralelně načítejte celotextové a vektorové vyhledávání, následně je slučujte pomocí RRF.
• Reranking používejte pouze pro malou, povolenou množinu kandidátů.
• V testovací sadě vyhodnocujte odkazy na zdroje, odpovědi typu No-result a Human Handoff.
• Při každé změně měřte latenci, náklady a kritické chybné odpovědi.

Závěr

Hybrid Search je robustní výchozí bod pro webové chatboty s různými typy dotazů. Vyhledávání podle klíčových slov zachovává přesné signály, vektorové vyhledávání zpřístupňuje podobné záměry, RRF propojuje jejich pořadí a omezený reranker může vylepšit užší výběr. Udržitelný nárůst kvality však vzniká díky udržovaným zdrojům, vhodným metadatům, sledovatelným testům a logice odpovědí, která přiznává své limity. Díky tomu se retrieval stává ověřitelným, nikoli pouze technicky působivým.

Zdroje a další informace

• Microsoft Learn: Hybrid Search
• Microsoft Learn: Relevance a RRF u Hybrid Search
• Microsoft Learn: Sémantické rankování
• Amazon Bedrock: Reranking
• ChatReact: RAG chunking pro AI chatboty
• ChatReact: Měření kvality odpovědí pomocí Golden Set
• ChatReact: Udržování aktuální báze znalostí